Managed Services

Definition

A managed service takes operational responsibility for a component: patching, scaling, backup, failover, high availability. You pay a premium over raw compute in exchange for not doing it.

The default position

Use the managed service unless you can name the specific reason not to. The premium is usually less than a fraction of an engineer's time, and operational capacity is the scarcest resource in most teams. The instinct that self-managing is cheaper almost always omits on-call, upgrade projects, incident response and the opportunity cost of the engineers doing it.

The genuine reasons to self-manage

• A capability the managed version does not expose. A required extension, a specific version, a replication topology, a kernel parameter.
• Cost at a scale where the premium becomes material. This threshold is much higher than teams assume, and it is a calculation, not a feeling.
• Regulatory or residency constraints the provider cannot satisfy.
• You already have deep operational expertise in exactly this component and a team whose job it is.
• The managed service's failure modes are unacceptable — for example a failover time that exceeds your RTO.

Industry example

The most instructive public case runs the other way. Dropbox moved a large portion of file storage off a public cloud onto its own infrastructure, and it was economically correct — because storage was the dominant cost line of the business, the scale was enormous, and the workload was uniform enough to optimise deeply.

What makes it instructive is how narrow the conditions are. It applied to one component, the one that dominated cost, at a scale few organisations reach, and it required building a team to operate it. Cited as general support for repatriation, it proves considerably less than people claim; cited as an example of a specific calculation done honestly at a specific scale, it is exactly right.

Failure scenarios

• Self-managing to save money, without counting on-call, upgrades and incident time.
• Adopting a managed service without reading its failure behaviour, then discovering the failover time or the maintenance window in production.
• Assuming managed means backed up. Some services are; some retain snapshots only briefly; almost none are restore-tested by you.
• Lock-in through proprietary interfaces where an open one existed at similar cost.

Trade-offs

Bought: operational capacity, faster delivery, better reliability than most teams achieve alone. Sold: control, some cost efficiency at large scale, and portability. Manage the lock-in cost deliberately — prefer managed versions of open interfaces where they exist, so the migration path is a restore rather than a rewrite.

Interview question

"Under what circumstances would you self-manage a database rather than use the managed service, and how would you justify it financially?"