PaaS Is Still Useful: Four Reasons It Survived the Container Era

Around 2017 a lot of people declared PaaS dead. Kubernetes was ascendant, containers were the new unit of deployment, and the narrative said that anybody serious would roll their own platform on top of k8s. Eight years later, Heroku-style PaaS products are still very much alive, App Service is arguably Azure's best product, Cloud Run is printing money for Google, and Fly.io exists because a bunch of engineers missed the Heroku experience enough to rebuild it.

Here is why PaaS survived — and why we still recommend it to customers more often than we recommend running their own Kubernetes cluster.

Reason One: The Economics of Platform Engineering Are Brutal

Kubernetes is not free. Not the software — the software is free. The people are not.

A production-grade Kubernetes platform requires, at minimum, a team that understands networking (CNI, ingress, mTLS), storage (CSI drivers, StorageClasses, backup), identity (RBAC, OIDC federation, workload identity), observability (Prometheus, Loki or equivalent, alerting), supply chain (image signing, SBOM, vulnerability scanning), and upgrades (cluster lifecycle, version skew policy, node pool rotation). That is not a one-person job. It is not a two-person job either, if you want the platform to survive somebody taking vacation.

The honest cost of a self-managed Kubernetes platform, in our experience, is three to five FTE for a mid-market customer. Fully loaded, that is $600K to $1.2M annually before you run a single workload. You can pay a PaaS vendor a lot of money before that becomes a worse deal.

We have helped customers unwind Kubernetes platforms that were started with enthusiasm by one engineer and then orphaned when that engineer left. Moving those workloads to Azure App Service or Cloud Run typically cut the operational overhead by 80 percent and cost less than the headcount that was freed up.

Reason Two: PaaS Is the Right Abstraction for Most Applications

Most applications are boring. They are a web tier, a database, a cache, a background job queue, and some scheduled tasks. Maybe a message bus. That is 80 percent of what we see in the wild.

A PaaS gives you exactly those primitives, pre-integrated, with sensible defaults. You push code, the platform builds it, deploys it, load-balances it, handles TLS termination, rotates secrets, and gives you logs. Everything you did not want to spend your time on is handled.

The gap between "boring web app" and "thing that needs Kubernetes" is wider than the container industrial complex would have you believe. If your application fits the PaaS model, PaaS is not a compromise — it is the correct level of abstraction for the problem.

We apply a rough test when advising customers. If the answer to all of these is yes, use PaaS:

• Is your application stateless at the process level, with state in a managed database and object store?
• Does horizontal scaling solve your scaling problem?
• Are your scheduled tasks simple enough for cron-style triggers?
• Can you tolerate a platform-managed TLS cert, a platform-managed load balancer, and a platform-managed runtime?

If any of those is no, you may genuinely need more control. If all of them are yes, Kubernetes is a tax you are paying for no reason.

Reason Three: The Security Posture Is Better Out of the Box

This one gets underweighted. A PaaS platform, properly configured, gives you:

• TLS certificates that renew themselves and are never on a developer's laptop
• Secret management that does not require anybody to know what a sealed-secrets controller is
• Network isolation that is the default, not an afterthought
• Patching of the underlying runtime, including the parts of the OS and the language runtime that every CVE report is full of
• Identity integration with the cloud provider's IAM system, which your auditors already understand

Contrast this with a DIY Kubernetes cluster, where every one of those items is an ongoing engineering project. We have done plenty of Kubernetes security audits where the problems were not exotic — they were missing network policies, stale base images, long-lived service account tokens, and unrotated secrets. PaaS platforms make most of those mistakes harder to make.

A PaaS is not a replacement for a security program. It is a much better starting posture than a half-built Kubernetes platform.

Reason Four: Vendor Lock-In Is Less Scary Than the Alternative

The main argument against PaaS has always been lock-in. Running on App Service or Heroku ties you to that vendor, while Kubernetes is "portable."

In 20 years of migrations we have concluded two things about this argument.

First, Kubernetes portability is real but overstated. Moving a non-trivial workload from EKS to GKE to AKS involves rewriting manifests, retesting networking, reconfiguring identity federation, rebuilding CI/CD, and working through provider-specific annotations and operators. It is easier than rewriting the application, but it is not "pick up and move."

Second, PaaS lock-in is real but recoverable. If you wrote your application as a web server listening on a port, reading config from environment variables, writing logs to stdout, and using a managed Postgres — the Twelve-Factor pattern — then moving from one PaaS to another is a dockerfile and a CI change. The actual lock-in comes from using proprietary services at the edges (platform-specific message buses, platform-specific auth, platform-specific data stores). Keep those at arm's length and your PaaS exit strategy is mostly a weekend of work, not a six-month project.

The customers who got burned by lock-in were not the ones who used PaaS. They were the ones who built deeply against proprietary runtime services without understanding the exit cost.

Where PaaS Is Genuinely Wrong

To be honest: PaaS is not the right answer for every workload.

• Stateful workloads with complex topology. A multi-master Cassandra cluster does not belong on App Service. A Kafka cluster does not either.
• Anything requiring custom kernel modules, custom syscalls, or unusual hardware. GPU workloads, eBPF tooling, specialty networking.
• Workloads where the per-request cost pricing model of PaaS is catastrophic. A batch job that runs at 100 percent CPU for 18 hours a day is much cheaper on a VM.
• Applications where you genuinely need to pin runtime behavior — specific kernel versions, specific libc, reproducible builds at the OS level.

For everything else, PaaS is still the most defensible default. The reason it survived the container era is that it was solving a different problem than Kubernetes was solving. Kubernetes is a toolkit for building platforms. PaaS is the platform, already built. Most customers need the latter.