10.6 Choosing a provider, and lock-in told honestly

What this is and why it exists

At some point somebody asks which provider to use, and the conversation usually becomes a comparison of feature lists nobody will read again. This lesson gives you a decision you can defend in a year: what genuinely differs between providers, what lock-in actually costs against what avoiding it costs, and the one document that turns the whole question from an argument into an agreement.

The vocabulary

• Lock-in — the work required to leave, measured in effort and time rather than in principle.
• Portability — designing so that moving would be cheaper, at some cost today.
• Exit criteria — written in advance: what would make us leave, and what we would do.
• Sovereignty — a requirement that data or operations stay under a jurisdiction's control.
• Procurement — the process by which an organisation is actually allowed to buy something.
• Institutional constraint — an existing agreement, credit or relationship that shapes the choice before anyone technical is asked.
• Managed service — the thing you adopt that creates most of the lock-in, and most of the value.

The mental model

Begin with what is the same everywhere, because it is nearly everything. Virtual machines, object storage, block storage, managed relational databases, load balancers, virtual networks, identity, functions, containers, a Kubernetes offering, monitoring, and a bill. The concepts you have learned in this subject transfer completely; what changes is names, console layout, defaults and the shape of the pricing. An engineer who understands one provider is productive on another within weeks, and this is worth saying to yourself before the comparison spreadsheet begins.

What genuinely differs is a shorter list, and it is where the decision actually lives. Which regions exist, and whether one is close to your users and inside your jurisdiction. The depth of a few specialised offerings — data analytics, machine learning, particular managed databases — where one provider is materially ahead. The service reputations that matter for your workload. The commercial arrangement available to you, including any credits and any existing relationship. And the skills you can hire in your city, which is a bigger factor for a small team than any feature.

Then lock-in, told honestly, because both fashionable positions are wrong. It is real: adopt a provider's managed database, identity model, messaging service and functions and you have a system that cannot be moved in a quarter. But avoiding it also costs, and continuously. The portable version means running things yourself that you could have rented, refusing managed services that would have removed operational work, and writing abstraction layers over two providers' interfaces — a cost paid every week, for a migration most organisations never perform. Meanwhile the deepest lock-in is rarely technical at all: it is your data's volume and the meter on the way out, your team's skills, and your compliance paperwork.

So the useful framing is not "avoid lock-in" but know what you are locking into and what leaving would cost. Adopt the managed services — they are usually the whole point of being there — and keep two habits that make the eventual door narrower: keep your data exportable in a format that is not the provider's own, and know roughly how long a migration would take, so the answer to "could we leave?" is a number rather than a mood.

Exit criteria are how that becomes a decision instead of a worry, and they are written before adoption, when nobody is upset. Three sentences will do: what would make us leave (a price change beyond this, a service withdrawn, a compliance ruling, a sustained reliability failure); what we would move to; and how long we estimate it would take. Written down in advance, it converts a vague fear into a plan with a trigger — and it usually reveals that the true dependency is the data volume rather than the code, which changes what you would do today.

Finally the constraints that decide most real choices before any of the above is considered, and it is worth being unembarrassed about them. An institution has an existing agreement. A grant came with credits. A regulator requires a region in-country. A procurement process only permits certain vendors. A partner requires you to be somewhere specific. These are not failures of engineering rigour; they are the actual conditions, and a recommendation that ignores them will be overruled by somebody who was not in the room. The engineer's job is to say clearly what each constraint costs technically, and then to build well inside it.

What you should now be able to explain or do

List what is the same across providers and say what that means for your own transferability. Name five things that genuinely differ, and say which matters most to a small team. Explain what lock-in costs and what avoiding it costs, and why "avoid lock-in" is the wrong instruction. Name the two habits that keep the door narrower. Write three-sentence exit criteria for a provider decision. Recognise the non-technical constraints that usually decide, and say what an engineer's job is inside them.

Check yourself