2.7 Case study — a platform service in depth

What this is and why it exists

Every managed platform is the same three ideas wearing different names: versions, traffic control between them, and a scaling mode you pick. This lesson takes one platform apart in detail so that the pattern becomes visible, then hands you the vocabulary to read the other two providers' documentation without starting again. Google App Engine is the worked example here because it is the one your textbooks use; the ideas are not Google's.

The vocabulary

• Version — one deployed build of your application, which continues to exist after the next one is deployed.
• Service — a named component of the application; versions belong to a service.
• Traffic splitting — sending a stated percentage of requests to each of two or more versions of a service.
• Split key — what the platform hashes to decide which version a given request goes to.
• Gradual rollout — moving traffic to a new version in steps, watching the errors between them.
• Rollback — sending the traffic back to the previous version, which is still deployed.
• Scaling type — the rule deciding how many copies run: automatic, basic, or manual.

The mental model

Start with the idea that makes all the rest work: deploying does not replace anything. A deploy creates a new version alongside the old ones, and a separate decision routes traffic. Separating "is it deployed" from "is it serving" is what turns a release from an event into a dial, and it is why rollback on these platforms is fast — the previous version is still sitting there, already built, already warm.

Traffic splitting is that dial. The documentation describes it as specifying "a percentage distribution of traffic across two or more of the versions within a service", and the interesting part is how a request is assigned, because it decides whether one user has a consistent experience. Splitting by IP address hashes the address to a number between 0 and 999 and routes on that; the documentation is careful to warn that sender addresses "are reasonably sticky, but are not permanent" — a user on a train changes networks and can change versions mid-session. Splitting by cookie looks for a cookie the platform sets, holding a value in the same range, and generates one when it is absent; it is both stickier and more precise, with the documentation putting the precision "close to 0.1% to the target split". The general lesson is portable: any traffic split needs a key, and the quality of the key decides whether your experiment measures anything.

That gives you a real rollout procedure rather than a hopeful one. Deploy the new version with no traffic and check it directly. Give it a small share — five percent is a common first step — and watch error rate and latency for the new version specifically, not for the service as a whole, since a small share hides in an average. Increase in steps. If something is wrong, set the split back to the old version, which takes effect immediately because nothing has to be rebuilt.

Scaling types are the third idea, and App Engine's three names are unusually clear about the trade. Automatic scaling "creates instances based on request rate, response latencies, and other application metrics", which is the default for anything user-facing. Basic scaling "creates instances when your application receives requests" and shuts each one down "when the application becomes idle" — cheap, with a start-up wait, and suited to intermittent internal work. Manual scaling "specifies the number of instances that continuously run regardless of the load level", which the documentation recommends for applications that need complex initialisation or that rely on state held in memory. Choosing between them is choosing what you want to pay for: responsiveness, thrift, or predictability.

Now what you gained and what you gave up against raw virtual machines. Gained: no operating system to patch, a build and release process you did not write, load balancing and certificates included, and rollback as a setting. Given up: choice of the machine underneath, some control over networking and start-up behaviour, direct access when you want to look at the process yourself, and portability — a version-and-split arrangement expressed in one provider's configuration does not travel.

Finally, the same three ideas elsewhere, which is the point of the case study. Azure App Service calls a version a deployment slot, and routes a traffic percentage to a slot; the "swap" that promotes a slot to production is the same separation of deployed from serving, with a different word. AWS reaches it through weighted target groups behind a load balancer, with the weights doing what the percentages do here — and App Runner and Elastic Beanstalk each offer their own version-and-release handling above that. Once you know to ask "where are versions kept, what is the split key, and which scaling modes exist", every one of these becomes a documentation lookup rather than a new subject.

What you should now be able to explain or do

Explain why deploying and serving are separate decisions, and what that buys. Describe two split keys and say which gives a user a consistent experience. Write out a five-step gradual rollout including what you watch and when you stop. Choose between automatic, basic and manual scaling for three different workloads and defend each. List two things a platform service gave you and two it took away. Find versions, traffic splitting and scaling modes in a provider's documentation you have never read.

Check yourself