2.6 Managed application platforms

What this is and why it exists

Between "rent a machine and do everything yourself" and "write one function" sits the option most ordinary web applications should take: hand the platform your code or your container, and let it build, run, route and scale it. You get a deployed application without ever choosing an instance size or patching an operating system. The skill worth having is knowing what the convenience hides, and recognising the day it starts costing more than it saves.

The vocabulary

• Managed application platform — a service that runs your application without exposing the machines; Amazon offers App Runner and Elastic Beanstalk, Azure offers App Service and Container Apps, Google offers Cloud Run and App Engine.
• Buildpack — an automated builder that inspects your source, works out the language and dependencies, and produces a runnable image without a Dockerfile.
• Runtime version — the language version the platform runs your code on, which it chooses and updates unless you pin it.
• Deploy from repository — connecting the platform to your Git repository so that a push builds and releases.
• Scale to zero — running no copies at all when nobody is asking, and starting one when somebody does.
• Warm instance — a copy kept running so the next request does not wait for a start.
• Platform ceiling — the point where what you need is something the platform does not expose.

The mental model

The platform is doing four jobs you would otherwise do by hand: building an image from your source, running copies of it, putting a load balancer and a certificate in front, and adding or removing copies as traffic moves. Every one of those is a job you already understand from the previous topics — this is not new machinery, it is the same machinery with the handles removed.

The deploy-from-repository flow is what makes it feel different. You connect the platform to a repository, and from then on a push produces a build and a release, with the old version still serving until the new one is healthy. It is worth naming what that quietly gives you: the deployment becomes reproducible, because it is a commit rather than a person's afternoon, and it becomes reversible, because the previous release is still there.

Buildpacks are the largest piece of hidden work and the one to look at with clear eyes. They inspect your project, decide it is a Python or Node or Java application, install dependencies and produce an image — no Dockerfile, no base-image choice, no decisions. What they hide is exactly those decisions: which base image, which system libraries, which language patch version. That is a gift while the defaults suit you and a puzzle the day you need a specific library version and there is no obvious place to say so. The related trap is the runtime version: platforms update language versions on their own schedule and eventually retire old ones, so an application nobody touches for two years will one day be told to move. Pin the version when it matters, and treat the retirement notice as a real date rather than an email.

Scaling to zero is the same bargain as a serverless cold start, in a bigger box. Nobody asking means nothing running and nothing billed; the first request afterwards waits for a copy to start, which for a container image is typically longer than for a small function. That is fine for internal tools, staging environments and low-traffic sites, and it is not fine for anything a customer notices, so the setting to look for is a minimum of one warm copy — and to understand that keeping one warm is the moment you start paying continuously.

Then the ceiling. A managed platform is a set of decisions taken for you, and you meet the ceiling on the day you need one it did not offer: a background process that must run alongside your web process, a specific networking arrangement, a sidecar, a GPU, a filesystem that persists. The move at that point is usually to containers on a container platform, and it is a much smaller move if your application was already a container and already read its configuration from the environment. Which is the practical advice this topic ends on: use the platform, and stay portable while you do — no state on local disk, configuration from environment variables, and a Dockerfile in the repository even when the buildpack does not need one.

What you should now be able to explain or do

Name the four jobs a managed platform does for you and match each to the raw service it replaces. Describe the deploy-from-repository flow and say what it gives you beyond convenience. Explain what a buildpack hides and give one situation where that becomes a problem. Say who should scale to zero and who should keep a warm copy, with a reason. Recognise a platform ceiling from a requirement, and list two things you can do today to make the eventual move cheap.

Check yourself