Managed Services
Running a database is a real job, not just a thing you switch on. Someone has to install it, back it up so data isn't lost, apply security patches, and keep it online at three in the morning. For a team like Maya and Sam's, that's hours of careful work that has nothing to do with making Pageturn better — and most teams would happily hand it off if they could.
The cloud lets them. Alongside bare servers, the cloud rents whole capabilities ready-made. A managed service is a capability — a database, for instance — that the cloud provider runs for you: they handle the setup, the backups, the updates, and the uptime, so your team doesn't. It's the ultimate version of "let someone else run it."
Bare Server vs Managed Service
There are two ways to get a piece of infrastructure in the cloud. You can rent a bare server and set up the software yourself — full control, and full responsibility for keeping it healthy. Or you can rent the same capability as a managed service, where the provider has already set it up and runs it for you. What stays with you is the data and the decisions: you still choose the settings, control who is allowed to connect, and own everything stored inside — "managed" means someone else runs it, not that responsibility disappears.
The difference is who does the operating. With a bare server, Sam installs the database and owns every part of keeping it alive. With a managed service, the provider's team does that, and Sam just connects Pageturn to it and uses it.
Example: A Managed Database
Make it concrete with the database Pageturn uses to store everyone's book lists. A database, recall, is the organized store an app keeps its data in. Run it yourself and you're on the hook for installing it, scheduling backups, patching it when a security flaw appears, and getting paged when it falls over.
As a managed service, all of that operating work moves to the provider. You're given a ready database to point Pageturn at; behind the scenes the provider keeps it patched, backed up, and online. It's the same database doing the same job — the only thing that changed is who runs it.
The Trade
This isn't free in either sense. You still pay for a managed service — often more per unit than the raw server underneath it, because you're paying for the operating work too. And you give up some control: you typically can't tweak every low-level setting, and your app becomes tied to that one provider's particular service, which is a mild form of lock-in — moving away later takes effort.
Compare it to owning a car versus taking taxis. Own the car and you control everything, but you handle the fuel, the repairs, and the inspections. Take a taxi and you give up that control and pay per ride — but you just get in and go, and someone else maintains the vehicle. A managed service is the taxi: less control, none of the upkeep.
Why Teams Choose It
So why hand off control and pay a premium? Because a small team's attention is its scarcest resource, and operating a database well is a deep skill that has nothing to do with Pageturn. Every hour Sam spends patching a database is an hour not spent improving the actual product.
Managed services let a team spend its effort where it's distinctive — on their own software — and rent the rest. They're a huge part of how real cloud systems are built and a central question in what the cloud costs, which is exactly the ground the cloud courses cover: Cloud from Zero, and the AWS, GCP, and Azure courses with their large catalogs of managed services. Next, Chapter 12 ties this whole course together, following one change to Pageturn through every stage you've learned.
- "Managed means free." You still pay — often more per unit than the bare server underneath, because the price includes the provider doing the operating work for you. What you save is your team's time, not money outright.
- "Managed means you give up all control." You give up some control, not all. You usually can't change every low-level setting, but you still decide how your app uses the service. It's a trade, not a total surrender.
- "A managed database is a different kind of database." It's the same kind of database doing the same job. The only thing that's different is who runs it — the provider instead of your team.
- "Managed services are always the right choice." Often they're worth it, but not always. The trade — less control and some lock-in to one provider — can matter when you need fine-grained control or want to stay portable. It's a judgment call.
- Managed services are a huge part of how real cloud systems are built — most teams rent databases, queues, and storage rather than operate them.
- The control-versus-work trade is one of the most common architecture and cost decisions a team makes in the cloud.
- It explains a phrase you'll hear everywhere: "we use a managed X" — meaning the provider runs that piece so the team doesn't.
- It's the clearest example of DevOps's instinct to automate and offload toil — here, by letting someone else run the parts that aren't your product.
Knowledge Check
What is a managed service?
- A capability, like a database, that the provider runs for you
- A bare server you rent and then install and maintain yourself
- An app bundled with its environment so it runs the same anywhere
- A file that describes the servers a team wants the cloud to create
What is the main trade-off a team accepts when it uses a managed service?
- Less control and some lock-in, in exchange for far less work to run
- You get the same capability completely free instead of paying for it
- You receive a weaker, less capable version of the database
- Your team takes on extra operating work it didn't have before
Why do teams often pick a managed database even though it can cost more per unit?
- It frees the team to spend its time on its own product, not on running a database
- A managed database is always far faster than one you run yourself
- It removes any tie to the provider and keeps the team fully portable
- It gives the team much more low-level control over nearly every individual database setting
You got correct