What Isn’t A PaaS

By: Matt Butcher

Heroku, CloudFoundry, Engine Yard, Deis Platform, AppEngine… a decade and a half ago, PaaS was a well-defined space with some major competition. 12-factor development was all the rage. Ruby-on-Rails was the poster child for developer experience. The operations pendulum had swung heavily in favor of the developer. But, as is the case with pendulums, they tend to swing back. DevOps, orchestrators, declarative infrastructure, Kubernetes, and then Platform Engineering pushed infrastructure management to the forefront. PaaS was out of style.

But developers have continued to hope for a PaaS-like experience that lets them focus more on code and less (or better, not at all) on infrastructure. Serverless functions are today’s antidote to thousand-line YAML configuration files. And some of us continue on the quest to make PaaS 2.0 happen.

For reasons I cannot fathom, we seem to be in a moment of retrograde motion, where certain tools claim to be a PaaS, but which don’t meet the “table stakes” features of early Heroku, AppEngine, CloudFoundery and so on.

PaaS, at its core, is really just a developer self-service platform that automates as much of the infrastructure deployment as possible. The promise of PaaS is that developers can build an app, and then deploy it without having to do any additional infrastructure configuration. But a few recent tools claim to be PaaS, yet force developers to do infrastructure engineering. These tools are not actually PaaSes.

Here are characteristics that disqualify an offering from meeting the definition of a PaaS.

If you can’t supply application configuration at deployment time, it isn’t a PaaS

This is absolutely the easiest and most obvious table-stakes feature. It was absolutely ingrained in the fabric of 12-factor that application configuration could and should be provided at deployment time.

Application configuration is limited to just the unique pieces of configuration that an application needs to be able to do its job. The easiest example is credentials for database access (or some other service). It should be possible to set application configuration at deployment time (or runtime), rather than having to provide it inside of an application package or via an infrastructure tool.

In PaaS v1, environment variables were de rigour. And that’s fine. But so are TOML, YAML, JSON… whatever. The important thing is that, as the 12-factor manifesto put it:

Code + Configuration = Deployment

Furthermore, the storage of configuration info must be secure (which means, at the very least, encrypted at rest and over the wire). Long gone are the days when it was fine to just circulate unencrypted config files through the PaaS backend.

There’s an anti-pattern here, too, which disqualifies a system from being a true PaaS: If application config can be provided, but only as a detail of larger deployment config (read: A Kubernetes manifest), then it’s not pure app config. It’s infra config. And that is a deal breaker.

If you have to configure an ingress (or proxy), it isn’t a PaaS

Nothing irks me more than a system claiming to be a PaaS, but then requiring me to configure the networking. I get super annoyed by this whole thing where an app is deployed “in the cluster” and then it is somehow my responsibility to figure out how to route traffic to my app. It is the opposite of developer self-service because it introduces low-level infrastructural changes that not only impact the PaaS and the underlying platform, but also the security of the broader network.

I think application developers, operations teams, platform engineers, and security folks will all agree: Nobody wants the app developer to be making networking choices.

If it doesn’t give you a DNS name, it isn’t a PaaS

Close on the heels of the ingress issue is the DNS issue. If I deploy an app and get back an IP address, I am immediately punted out of the “app developer” role and into operations. DNS is finicky, has security implications (often ones poorly understood by non-experts), and requires at least decent knowledge about networking. If a platform is foisting this work onto the user, it is not treating the user as an app developer, but as an infrastructure engineer.

This is not to say that every PaaS must be able to do full DNS management. I think that it is fair enough to consider the auto-issuance of a DNS name (like foo.example.com) to be enough. But I sure like it when bringing my own domain name is easy. And it’s even more delightful when a PaaS systems can automate the process from registering a domain name to attaching it to your app(s).

If it doesn’t generate SSL certificates, it isn’t a PaaS

SSL is a table stakes feature. It has been for a long, long time. With today’s tooling, it’s easy to automate, and one need look no further than Let’s Encrypt to find a free certificate authority. And any HTTP-based app must support TLS/SSL in order to gain acceptance. Unencrypted HTTP is just for testing.

If a system doesn’t issue certificates at app deployment, it’s not a PaaS. It is requiring the user to perform manual infrastructure configuration and solve problems (like CA issuer, certificate management, and so on) that are way beyond the scope of application development.

If it doesn’t provide a developer workflow, it isn’t a PaaS

There is a well understood lifecycle for PaaS-targeted applications:

1. Create a new app
2. Build and test it
3. Deploy it
4. Upgrade it
5. Delete it

Yes, there’s room for other steps in the workflow, but these 5 are what define a PaaS developer workflow.

Steps 1 and 2 seem to be ignored by some tools claiming to be PaaSes. The mantra seems to be, “Just give us a Docker container and we’ll run it.” To a degree, I am okay with this. I don’t like it, but I’m okay with it. This approach pushes some infrastructure requirements back to the user, since building a container involves making choices about operating system and architecture. But I think I am willing to let that slide.

When step 4 is missing, though, then I get worried. It looks simple on paper (we just rev a version number, right?). But as anyone who has done operations work will tell you, here is where be all the dragons. Infrastructure engines (devops, PE’s, whomever) have a specialized terminology for the various strategies used to handle deployments such that there is no downtime during an upgrade. If you’re an app developer and don’t know what a blue/green deployment is, then I’d say you are doing your job, and never should have to know. But it’s an important approach to the upgrade process. A tool that doesn’t automate upgrade deployments is just not a PaaS because it forces the developer to do the infrastructure finagling (whether in a proxy server or in an orchestrator) necessary to avoid downtime.

Conclusion

My goal in the post isn’t to point fingers and name names, but to equip us all in a common understanding of what a PaaS is. We, as an industry, do ourselves no favors when we play fast and loose with our terminology. It has been frustratingly common (to the dismay of developers and operations teams alike) to push application developers into making infrastructure decisions. If we are really building better developer self-service platforms, we cannot afford to take steps backward. We cannot afford to make today’s PaaSes a worse experience than the first wave. PaaS v1 did so many things right. Let’s not regress.

As one final point (and a self-own), a reader might point out that Fermyon (along with SUSE, MS, and LiquidReply) builds SpinKube, which does not do many of the things I say are required for a PaaS. This is why we tell people that SpinKube is not a PaaS. It is a Kubernetes serverless platform. It could be combined with something like KRO to build a PaaS, but it is not one on its own. That said, Fermyon Cloud is a PaaS, and doesn’t cross any of the lines enumerated above. From networking, DNS, and SSL on to configuration and deployments, Fermyon Cloud automates all of this so that developers can go from a blinking cursor to a deployed application in two minutes or less.