PE2-6.5 Cloud Platforms & Case Studies

What this is and why it exists

The concepts are now in place. This topic puts them on real platforms, and one comparison does most of the work.

Two products from the same provider, at different levels of abstraction, make the service model ladder something you can feel rather than recite.

The vocabulary

• Managed platform — one where the provider runs everything below your code.
• Virtual machine service — one where you are given machines to manage yourself.
• Version — one deployed revision of an application, which can coexist with others.
• Traffic management — controlling which version serves which requests.
• Traffic splitting — sending a chosen share of requests to a different version.
• Canary release — exposing a new version to a small share of users first.
• Vertical scaling — making a machine bigger.
• Horizontal scaling — adding more machines.
• Autoscaling — adding and removing machines automatically with demand.
• Private cloud platform — open source software for running the model on your own hardware.

The mental model

Start with the comparison, because it makes the ladder concrete.

A managed platform takes your code and runs it. You do not choose an operating system, apply its updates, or decide how many machines there are. In exchange you accept its constraints: supported languages, a particular way of handling requests, and limits on what a process may do.

A virtual machine service gives you machines. You choose the operating system, install what you like, and patch it forever. You can run anything, and everything above the hardware is yours to maintain.

Same provider, same data centres, opposite ends of the trade. Reading the two product descriptions side by side teaches the service models better than any diagram.

Traffic management is the feature that makes safe deployment possible, and it is worth knowing well beyond this course. Several versions of an application can be deployed at once, and the platform decides which requests reach which version.

That enables the practice large services actually use. Deploy the new version alongside the old, send a small share of requests to it, and watch. If the error rate rises or the response time worsens, send that share back to the old version. If it looks healthy, increase the share gradually until the new version carries everything.

That is a canary release, and it changes the character of deploying. Instead of one moment where everything switches and either works or does not, you have a dial you can turn back. The same mechanism performs comparison tests, sending different users to different versions deliberately to measure which performs better.

Scaling has two directions and the difference matters. Vertical scaling means a bigger machine: more processors, more memory. It is simple and it ends, because there is a largest machine. Horizontal scaling means more machines. It has no such limit, and it requires the application to tolerate running as several copies. That means keeping no important state in the memory of any one of them.

Horizontal scaling is what this environment is actually good at, and an application that cannot do it gains much less from being here.

Autoscaling adds and removes those machines automatically as demand moves. It is elasticity made concrete, and it has a limit worth knowing. A new machine takes time to start and become ready, so a faster demand spike is still felt.

The provider survey is best read for shape rather than names. All three large providers offer compute, storage, databases, networking, identity and monitoring, with different names for each. The useful exercise is mapping equivalent services across them, because the concepts transfer completely and the names do not. Reading a product catalogue as a list of names to memorise is wasted effort; reading it as one concept per category is not.

The open source platforms matter for two reasons. They are how a private cloud is actually built, which is the deployment model from the earlier topic made real. And they show the same architecture without the marketing. Reading how one is put together is the clearest way to see what a cloud is underneath.

What you should now be able to explain or do

Compare a managed platform with a virtual machine service and place both on the responsibility ladder. Explain traffic splitting and describe a canary release. Say why a dial you can turn back changes deployment. Distinguish vertical from horizontal scaling and say what horizontal scaling requires of an application. Say what autoscaling cannot protect against, and how to read a provider catalogue.

Check yourself