Whatever Happened To PaaS?

In 2009 I discovered Google App Engine and fell in love. Its promise: any software developer could build web apps available to anyone, anywhere, 24/7, without having to worry about server configuration, or database setup, or OS versioning, or security patches, or load balancing, or scaling. Automatic scaling! All we had to do was write our code; App Engine would handle everything else.

It seemed obvious to me in 2009 that by 2015 the vast majority of web code would run on similar platforms. Who wants to wrestle with configurations and operations? Sysadmins would at last be liberated from their gruelling yoke. (By which I mean: turned into developers, hired by the platform providers, or fired.) At last we would be free to write our code without having to worry about how or where it was executed. The scales would fall from our eyes, and we would be unleashed from the chains of operations, and our future would be bright and free of implementation details.

…Yeah, so it hasn’t exactly worked out like that.

Why not?

This was no “write once, run anywhere.” App Engine actually fulfilled, and continues to fulfil, that initial promise. (And much more, which is why I still use App Engine for my side projects.) Granted, you trade it for a sea of asterisks and fine print, “exploding indexes” and “sharded counters” and occasional inexplicable memory leaks and wait times; but as a Googler friend once said, “App Engine is quite amazing, it runs equally slowly for every user, no matter how many there are.”

And there are plenty of other platform-as-a-service (PaaS) contenders. Even Amazon, the undisputed king of dumb virtual computing infrastructure, provides a PaaS with its Elastic Beanstalk. I frequently use Heroku professionally, and you know what, they’re pretty terrific too: not as good as App Engine at asynchronous tasks or automatic load balancing, but much better at git-push-to-deploy, and PostgreSQL databases, and, well, not providing a sea of APIs whose equivalents are completely unavailable anywhere else. Through Google’s APIs are often far better than those available anywhere else. That’s what you gain, and lose, for running your code on (more or less) Google’s own platform–

–but even Google itself seems less enamored of that notion than they did in 2009. In 2012, presumably dissatisfied with App Engine’s success, they launched Google Compute Engine, a direct competitor to Amazon Web Services. Both of which are vastly more convenient than purchasing and provisioning your own services, of course; but both of which still seem a distinct step back, in terms of ease and flexibility and development time, from their PaaS counterparts. Why was I so wrong? Why has PaaS not conquered all?

It’s had its successes. Snapchat, famously, runs atop App Engine, as does Khan Academy. Genius and Product Hunt run on Heroku. Both also host countless other startups and more established companies. But if PaaS were more successful, Google wouldn’t have bothered with Compute Engine. If PaaS were more successful, Docker would not be the new hotness. If PaaS were more successful, DevOps would not be (as much of) a thing.

So why do people still spin up and set up their own AWS and Compute Engine instances? Why have App Engine and Heroku and Elastic Beanstalk not conquered all? Is fine-grained control really that important?

I suspect the reason is three-pronged: cost, lock-in, and culture.

App Engine’s prices drop regularly, but they’re voluminous and confusing, and a single instance — a pretty puny virtual machine — costs more than a dollar day, not counting storage or bandwidth. Same for Heroku. You get more bang-per-buck by simply buying and running your own servers. You also get enormously larger headaches, and significantly slower development time; but that tradeoff isn’t worth it for many.

Then there’s lock-in. Once you build your app atop App Engine’s custom APIs, you’re committed; there’s no easy way to back away and go to another provider. The lock-in is less for other PaaS providers, but it’s still there. There is no universal PaaS equivalent of de facto IaaS (infrastructure-as-a-service) standards such as OpenStack or Docker.

The third, least valid, and arguably most powerful reason is culture. Companies don’t want to give up perceived control over their systems–even if that control is never worth its associated complexity–and sysadmins, understandably, don’t want to evolve themselves out of a job.

The thing about all three of those reasons not to go PaaS, however, is that they’re temporary. Costs keep dropping. Culture keeps changing. And there are signs of slow movement towards interchangeable PaaS services and standards. (You could argue that Docker itself is a stride in that direction.)

In the early days of electricity, factories all had their own generators; then, eventually, they moved to the grid. IaaS is the equivalent of every individual company getting their raw electrical power from the grid … but stepping it down with their own transformers and converting from three-phase to one-phase in-house. I suspect we’re still en route towards a largely PaaS world where server code mostly just runs, without developers knowing or caring about the servers in question. It’s just happening a little slower than I’d like.