An internal platform offers one service on a rented machine, a managed runtime, or a whole managed capability — what does each rung take over?

## What a rung actually is A managed service tier is not a product category; it is an answer to one question: **how much of the stack does somebody else operate on your behalf?** The same ordinary service — say an internal API with a store behind it — can run at several heights, and the heights form a ladder because each one is the height below it plus one more layer handed over. The industry has names for the bands (**infrastructure as a service**, **platform as a service**, **software as a service**), and the names are the least useful part of the subject. What matters is the set of operational verbs that change hands at each step: *patch*, *resize*, *scale*, *back up*, *fail over*, *upgrade*. ## The bottom rung: you rent a machine You are handed a virtual machine and a network address. The provider is still doing a great deal you never see — the building, the power and cooling, the physical hardware and its replacement, the virtualization layer, the storage substrate and the network fabric — but everything from the **guest operating system** upward is yours: - you choose an image, and you patch the guest operating system on your own schedule; - you pick the size, and changing it is your action, usually with a restart; - you install and upgrade the runtime, the libraries and the service itself; - you arrange backups, and you find out the hard way whether they restore; - you notice that a machine has died, and you replace it. In exchange you get the one thing no rung above offers: a login, and full control of the box. Anything installable is installable. ## The middle rung: you rent a runtime You stop supplying a machine and start supplying a deployable artifact plus configuration and a declared target. The platform runs it. What it takes over: - the guest operating system and its patching, normally inside a **maintenance window** you can move but not postpone forever; - the runtime version, moved along a supported range with old versions retired on a published timetable; - placing copies on hosts, health-checking them, restarting them, and replacing a host that fails; - adding and removing copies to reach the target you declared. What stays yours: the artifact and everything inside it, the configuration, the data, and the target itself. What disappears: the host. There is no box to log into, because the box is not yours and the platform is free to replace it underneath you. ## The top rung: you rent a whole capability Here you stop supplying an artifact at all and consume a finished product through its interface. A managed data engine is the standard example: you get an endpoint, a version family, and the subset of settings the provider is willing to expose. It takes over: - patching both the operating system and the engine; - provisioning storage and growing it; - taking backups on a retention you choose, and offering restore to a point in time; - detecting that the primary has failed and promoting a **standby replica**, on its own timetable. What remains yours is the part no provider can own: what you put in, how you model it, how much of it you buy, and what you do when it is slow for your workload. ## The verbs, side by side | verb | rented machine | managed runtime | whole capability | |---|---|---|---| | patch the guest operating system | you | provider, in a window | provider, in a window | | upgrade the runtime or engine | you | provider, in a window | provider, in a window | | resize | you, by hand | you declare, platform performs | you declare, often online | | add or remove copies | you build and register them | platform reconciles to your target | usually invisible, priced by use | | take and keep backups | you | you, for your data | provider, on your retention | | fail over | you | platform replaces copies | provider promotes a standby | | log into the host | yes | no | no | ## What does not change as you climb 1. **What the service does for its users.** Same request, same response. A rung is an operations answer, not a product one. 2. **Your data and your model.** No rung writes a schema or decides what is stored in it. 3. **The demand.** A rung changes who adds capacity, never how much of it is needed. ## The sentence worth saying out loud Every rung that removes work removes access in the same step, and for the same reason: an outcome can only be promised over a substrate nobody edits by hand. That is why the ladder is a trade rather than a set of tiers in which higher is simply better. A team that wants both the guarantee and the login is asking for something no rung offers, and recognising that is the difference between reciting three acronyms and understanding the model.