Cloud vendor lock-in is shocking, but there's a get out of jail card The Sleepwalking Into Disaster klaxon is echoing through the corridors of power. Again. This time, the corridors are British and the klaxonner is the Cabinet Office's Central Digital & Data Office. The CDDO keeps an eye on where the money's going in government IT projects – our money, our services. It has spotted that the …
Linux is available, and there are many competing vendors. So choose linux as the OS.
Office productivity - LO is available. Use MS products and/or OO as competing alternatives (with some rules about the permitted complexity of documents)
Email is standards-driven anyway so there's no problem there.
ms teams? what's that?
I don't think all of those have the same lock-in potential.
Operating system: I'll grant there is a tendency to rely on software which doesn't support all ones, but that's more on the writers of software who choose not to make builds for other OSes than on Microsoft or Apple. You can always install another one, and they don't prevent it from doing what you want.
Office: Not really. The file formats are understood by other applications. When I stopped having Microsoft Office and started having LibreOffice, there was little change for me and no change for anyone I interacted with because I could still open their Office-generated files and send them ones they could open. I know that complex spreadsheets can be an exception to this, but that affects a smaller proportion of users and is something they can try to resolve by considering other programs, one of which probably supports them better than LibreOffice Calc.
Email: Moving email suppliers can be tricky, and it's one that fits somewhat better, but it's also where the protocol should make it straightforward if you control the important things like the domain and the configuration. Porting from one supplier becomes more work, but not one that will cause chaos for users if you do it right.
Teams: There are lots of videoconference programs out there. Many of my employers have picked a non-Teams option. It doesn't have that much lock-in potential, especially as multiple such programs can be installed simultaneously, making it possible to gradually switch over.
In the real world it’s not that simple. Many customers would love to use an office alternative, but user familiarity, 3rd party application integration requirements, Microsoft ‘every desktop’ EA licensing dictats, lack of feature parity and existing sunk investment in processes and assets that require Office to operate are huge blockers to change.
I think my view is based on a narrower definition of lock in. Some of those, including licensing, sunk investment, and integration I file under lock in. Feature parity, on the other hand, doesn't really count for me. If you use a program because it has a feature you want and others don't, that's not lock in, that's a product being better for your use case. I count something as lock in if you would prefer to use something else but it is either impossible or impractical because of your previous use of the first option.
Operating System: already done, it’s called POSIX and was mandated by the US Department of Defence decades ago. And it still applies for non-corporate IT (ie radars, sensors, the lot).
Office Productivity: already done. MS’s xml doc formats are now public standards. Some of the things you can embed in them aren’t, such as Visual Basic blobs. Understanding the standard and reimplementing it is another matter but LibreOffice isn’t having to start from scratch. It can get the xml schema from the Library of Congress.
Email: long done. We’ve had multiple implementations of servers and clients for decades.
MS Teams: granted this is an area where things are disappointing. There is SIP. There is also RCS. There are standard for these things but the successful products have avoided them.
This is why Terraform is so important. It doesn't get you all the way to independence, but at least you'll have some chance of changing vendors. Steer clear of Cloud Formation, etc.
If I was running things I'd split my projects amongst the big three.
Oh, and I would not touch Oracle. Just don't.
When it became popular, Terraform was open source, so you couldn't get that locked in, and now you'd probably use OpenTofu instead. In both cases, the software runs on your equipment by default, meaning that you're not locked in to any particular external provider to keep information about your system state. Most deployments I've seen store that data in the cloud somewhere, but that is a cloud location of your choosing, under your control, and not under Hashicorp's control (maybe they have a managed version, but I've never seen it).
That's not really the point I was making. It's more about the expertise. If you are proficient in Terraform (or OpenTofu) then you can reasonably easily transfer stuff from AWS <-> Azure <-> GCP.
If you are proficient in Cloud Formation, that's a totally different format and skill and libraries, etc.
That's literally my job, and I could not manage thousands of instances without it (or similar). That would require a massive team of Sys Admins, instead of a small team of Platform Engineers.
I don't know why you got thumbs up for that statement, I can only assume that's commentards who don't know what the hell they are talking about. Perhaps they retired 15 years ago, and are living in the past?
I had to go and look up Logic Apps. Looks like an Azure thing for integrating Mainframe and Midrange systems. I don't see many (any) job adverts for it, and I'd never heard of it until yesterday (from you).
This might be being pushed my MS as the next great thing, but I don't tend to drink that particular kool aid.
It did get my attention because Scott Hanselman was in the video, who I respect a lot, but he did look a bit like a hostage being told what to say. ;-)
I don't tend to use the word "expert" ever (except in a derogatory way), I feel that word is overloaded. I just say I've got experience in this or that technology.
We have 21st century marketing techniques! Old school stale and curled up British Rail sandwiches would be "lovingly matured" and "organically shaped" and praised by influencers. They would sell in their millions. (Mainly because a government run industry wouldn't allow competition and you'd need sustenance when the train was stopped for hours.)
The British Leyland fiasco was a case of the government trying to revive an industry that was truly f****d by years of private sector under investment, asset stripping and appalling labour relations. At least they had a go.
The private sector were the ones who priced their best selling car to make a loss on each sale, the private sector management approved th design of the Austin Allegro ………
It was under state ownership that worse decisions (price of the mini was set without know production costs) were made. Typical example of merging basket cases with reasonable businesses so that they all failed.
I'm not a fan of privatisation but we should remember how shit governments are at running companies that have to compete in markets.
"Because of your Point 3 we can't do it"
Are you really saying that there are no longer any skilled IT people in the UK to run data centres?
The reason we won't do it - as opposed to can't - is that the Civil Service has an aversion to paying market rate salaries for people with actual skills relating to their jobs and that HMRC has seriously damaged the freelance market.
Were that not the case CDDO - or individual departments - could tender for premises, assuming HMG doesn't have any - and tender for H/W and everything else needed and run things themselves.
"...the Civil Service has an aversion to paying market rate salaries for people with actual skills relating to their jobs..."
Not a UK-specific issue. Civil service unions insist on pay scales that are based mostly on seniority / years in service without reference to market rates. It's pretty impossible to properly match pay rates not only across large institutions but also across highly variable domains eg developer vs teacher vs nurse. What is really nuts is that the civil service would rather pay Capita, TCS etc £500++/day for a developer (who is going to pocket £200-£250 of that) rather than directly employ the developer at an equivalent of £200-£250/day, just because nurses or teachers are paid the equivalent of £100-£150/day. The civil service unions fail to see that allowing civil service to hire highly-paid jobs at market rates will actually free up civil service budget that could then be used for better pay for nurses and teachers (and *deity* knows they deserve it)
"... and that HMRC has seriously damaged the freelance market."
Not difficult to look at the whole IR35 fiasco and think this was purposely done to benefit Capita, ZCS etc
https://en.m.wikipedia.org/wiki/Central_Computer_and_Telecommunications_Agency
We used to…
Over a number of successive Tory and Government Administrations it was turned from a generator of standards, a provider of infrastructure and comms, a provider of solutions, a hosting provider, and so on …
… into what is now CDDO and part of the Cabinet Offices Team of Procurement monkeys who just seem to generate endless round of procurement framework - inc. ones with vendor lock in and rampant overcharging.
Funny that no-one (but the redundant and people ‘who were not supporters of change’) could see that coming.
Oh it’s where ITIL was born too.
Would be amazing, and would work too. K8s for containers, postgres as rdbms, mongo for nosql, kafka for streaming.... open source has everything people need.
Only problem is when azure goes down everyone studiously ignores it, but if cloud.gov.uk had an outage the UK press would be screaming with made-up billion dollar figures for "damage to the economy".
The first part is just a list of products or services, they all have to run on something,
The second part is correct, if any commercial cloud provider has a glitch people just accept it and post on Facebook/Twitter.
The difference is that when you use Amazon AWS/Microsoft Azure/Oracle you buy a service, have an account manager and when it goes wrong, just ring you account manager and put your feet up. Responsibility ends there.
If a UK Government Cloud service were to be provided the finger pointing and ranting that it did not work would be endless, even if it were better than the alternatives.
Account manager for Azure, AWS or Google? You must be joking! All automated systems which invariably show that the customer is always wrong.
Government run systems can hide behind crown immunity and force majeure: it was the wrong sort of bytes…
Mine's the one with the British Rail Bumper Book of Excuses in the pocket.
If you buy enough stuff from them, you move from the basic customer to one who does get specific contacts and priority support. I can't promise that those things are as good as they sound, but I can virtually guarantee that, if the UK government buys a lot of services from AWS, they have someone at AWS they can complain to and get responses from quickly.
Again, I don't know how useful that point of contact is. I do know, from experience, that they do have those points of contact and that initial messages get responses. Fortunately, as a programmer, I've rarely had to get any more connected than that. I am responsible for making sure that the cloud bills shouldn't be very high. Once I've done that, making sure they send us the right bill is someone else's job, so if any interaction is needed, they do it. Maybe the communication will still be fragmentary, but it won't be a forum topic alone.
The difference is that when you use Amazon AWS/Microsoft Azure/Oracle you buy a service, have an account manager and when it goes wrong, just ring you account manager and put your feet up. Responsibility ends there.
If by account manager you mean a status page, a forum where threads which get too uncomfortable are locked, and they let you up/downvote proposed features but they end up doing what they want anyway, then yes.
Despite all evidence to the contrary you think the state could manage to run a sovereign cloud when they barely manage anything else?
It'd end up an expensive, underperforming white elephant.
And more likely than not still run by one of the usual crowd of suppliers, so single sourced for 5 years then roll to a new contract with the same or one of their competitors. No doubt swapping the basic platform each time.
And the really fun bit would be all those who'd previously loudly pushed for switching to it would then be busy arguing about why we weren't using the cheaper, better commercial alternative instead of some special UK specific thing.
Well it seems Sweden's already done it, based on open source.
Tele2 secure collaboration hub for public sector keeps Swedish data in Sweden
They didn't get pushed from S4B to Teams, instead they used the time to build a platform for the public sector.
"Despite all evidence to the contrary you think the state could manage to run a sovereign cloud when they barely manage anything else?"
You would need to do something unusual. Just let the competent people do the job. Keep the meddling ministers, their SPADs and all the Modern Greats, Classicists, music degrees, etc of the Civil Service management grades out of it.
Yanis Varoufakis explains why you can't have a non-US major cloud company in his book "Technofeudalism" although his commentary is actually about Tiktoc. He's the first person to coherently articulate why the US government has gone after ByteDance, Huawei and other non-captive tech firms and ( surprise!) its nothing to do with "national security". Put simply, its all about the balance of payments; we need revenue inflows to counter the outflows due to our import inbalance and anything that threatens key companies gets hit.
This type of protectionism isn't new; what's novel is the revenue extraction model where the monopoly is in the tools needed for others to actually do the productive work. Its like sharecropping but in the cyber world.
We are far too late. It's all very well obsessing over chips and whatever. But as soon as you get a PC, the process stopped. And we are too far down the line to reverse that,
The result being no matter how many competing vendors you had for your hardware, you ended up with a single supplier for the OS, and most software.
The very last time I was aware of any conscious effort to second source was a major UK financial institution that was running SQL Server and Oracle as a deliberate strategic move after acquisitions.
The author seems to believe that second source is a lot more common than it actually is, especially when referencing military bits.
Apart from the true commodity bits very little military kit is second sourced. The more common solution to specialty bits was & is to buy all the production & spares required to fulfil the contract in one go and leave it at that; the future is dealt with via updates & redesign which you'd need anyway due to inevitable obsolescence.
Even if setting up second sourcing wasn't likely to be horrifically expensive & complex for the contracts & duplication (as the US govt found more than once) there's nothing to stop the supplier just saying 'no', leaving you with either accepting single source, trying to find an alternative, or just getting nothing.
If your supplier is reliable & unlikely to go pop then single source isn't the end of the world, assuming the contracts are written properly. Commercial risk will exist but no more than for any customer, and at that point you fall back on making sure your contract is robust - plus as a government you always have the option of arm twisting.
I recall a situation, around 30 years ago where a major North Sea player had a production installation where there were some single source flexible pipes. They were critical to the operation and, to minimise the risk of unplanned shutdowns (that would have got quite expensive - think >$1m per day) from leaks, they were replaced annually. The supplier (in Germany) was struggling for work at one point so the operator ordered several years worth of spares - it provided a degree of security for them and helped the supplier stay in business.
The supplier recognised and appreciated the support and ensured any of the operator's future calls for supplies or services were given priority.
In the North Sea oil and gas sector, supply chain assurance is critical, although not all players seem to recognise it. I found that corporate memory rarely goes past 15 years and past experience doesn't prevent a reoccurrence of past problems (and it kept me in work well into retirement)...
You seem to presuppose the second source going broke but provide no real argument for this. In fact, the more companies that stipulate second source policies, the more choice we're all likely to have.
When it comes to services, it should be possible to draft contracts that facilitate switching. This might actually be an area where legislation for standard contracts could help. However, this can itself be a prelude to musical chair for service providers. I happen to know someone working for an outsourcer at DWP and they've just been moved kit and caboodle from one shyster to another "in accordance with policies to put services reguarly out to tender…" Another reminders at how shit governments tend to be at procurement, as if anyone who used the railways in the last twenty years can confirm.
When I had the misfortune to temporarily become a "client", as I'm sure their preferred trun goes nowadays, of a past incarnation of the DWP I quickly gained the view that the unemployables were on the wrong side of the counter. That was in the 1960s. A brief encounter when an actual client of mine did some work for them left me assured little had changed and I'r be surprised if anything has changed since then. How DWP goes about things is probably about the worst guide as to what could be achieved by using s modicum of competence.
"You seem to presuppose the second source going broke but provide no real argument for this. In fact, the more companies that stipulate second source policies, the more choice we're all likely to have."
I'm not 'presupposing' anything, don't be daft. Companies go bust every day, and there's absolutely nothing guaranteeing that YOUR favourite supplier du jour is exempt in any way. Even Critical Vendor status is no guarantee.
If you want real arguments, how about this: US bankruptcies in 2023 were the highest in fifty years; across practically all industries, including Aerospace, IT and Manufacturing.
Having a competitive market doesn't mean there wouldn't be any lock in. The only way to avoid technical lock in is to never use some technology/service that isn't replicated identically by someone else (which in reality means having a significant reduction in choice and banning "new stuff" that does something different). Even if you do avoid technical lock-in, you can still be locked in due to the price being so awesome that you'd never leave it behind, or the effort to change (for whatever reason e.g. due to the need to move lots of data from old provider to new) might feel too much. Eyes wide open peeps...
Some standards have become very successful. Second sourcing is just a way of ensuring one comes about.
Just look at the PC hardware architecture. IBM accidentally created an open hardware standard that anyone could copy (once BIOS clones had been black box written), and even ensured that the CPU became something of a standard too.
POSIX has been a very successful standard too. As has Ethernet, TCP/IP, email; the list is endless.
The most successful standards are the ones that industry players agree to create amongst themselves. Even POSIX, though driven by DoD, was largely a combination of the various flavours of *nix that were around at the time.
The XKCD cartoon is amusing and applies to the phase when individual companies think they can get the whole market. Fast forward a bit and there’s only one effective standard left. Just look at networking. There used to be DECNet, Token Ring, Token Bus, Ethernet, TCP/IP, OSI, etc. Look what’s left…
The best thing governments can do is to refuse to buy any of it until it has become an open standard making second sourcing possible. If gov waits until the vendors are deeply invested and getting very keen on winning gov business, at that point it should refuse point blank until it is possible to second source. That would force the companies to share software and hardware designs, standardise overnight or they’ll all lose. If government refusal were public, that might attract other large companies to take the same position.
That only works if companies can’t afford to lose the business. But with AWS for Amazon and Azure for MS, they’re both becoming dependent on these products.
The trick to portable cloud services is to script the entire setup and configuration of your VMs such that you can (re)create them on a bare-metal VM without relying on the cloud provider's lock-in services, save for their OAuth2 framework (which really shouldn't require vendor specific code if it is following the standards properly.)
People get locked in because they start using the "tuned" and rebranded (LOL) versions of open source products provided by the big clouds, and only later to they bother to find out that the "tuning" makes it incompatible with standard releases.
I have my doubts on that point.
The way I see market conditions these days, having an open-source based second-source supplier that becomes successful is going to entail two things :
1) open-source developers are going to attack the company to get what they consider is their "fair share" of the spoils, and
2) AWS, Azure or any other multi-billion behemoth is going to lavish the company board in boatloads of billions to buy them out, and they will fold
So, short or medium term, any successful open-source-based company with big government contracts is going to disappear, either because of lawsuits, or because of bagfulls of money.
Return to step one.
Second sourcing cloud services, ie building your services in a cloud-agnostic way, means you only use the least common denominator of their features. So no use of fully managed higher-level services such as databases or messaging that are available without ever having to worry about resilience, building, maintaining, testing, upgrading or scaling them. Those that allow you to build complex systems in no time.
Second sourcing gives you all of the costs and few of the benefits. Not a great deal.
Great article! TIL "second sourcing". I've been selling IT for nearly 40 years and I'm aware that every other technology introduces some degree of vendor lockin. But I felt cloud raised vendor lockin to the next level since it's the only technology that can literally be turned off by the vendor unilaterally and without any back-and-forth with the customer. I wondered whether customers, including government agencies, who moved to the cloud didn't realize this risk. The first time I read that this is a risk worth taking was in a McKinsey article but it didn't say how it can be mitigated, just that it can. This is the second time I'm reading how the risk can be mitigated. While you yourself admit that the details are sketchy, I do believe that your idea of "second sourcing" sounds promising and worth exploring in futher detail.
In production, having a feature cut off is rarely the lock in concern. Cloud providers do discontinue things, but they usually start by cutting them off for new customers, then a few months to a year delay, then they prevent existing customers from starting new instances, then another year or two, then maybe they'll do something to existing instances. That maybe is truly a maybe; I've seen cloud providers offering services that have been discontinued for ten years because someone is still paying for them. This kind of lock in is not that different from a software provider that has ceased offering a certain feature in their next version. It is troubling, but it's the kind of thing that IT departments have to deal with anyway.
The things that create greater lock in risk are services which cannot be simply deployed somewhere else. If I build something using what they sometimes call "cloud native design", for example using a providers serverless functions system for computing and message passing system, then I cannot simply pick it up and put it somewhere else. A different provider probably has both of those, but they don't work the same way, so I can't remove and replace like I can if it's a binary on top of an OS. Another lock in mechanism is data transfer costs. If I stored a ton of archival data in one cloud, it will cost quite a lot to transfer it out to another one. Another is integrated features. If I have linked all my systems together using a virtual network, it requires a lot of changes to get it running over the open internet instead, especially as any data-intensive features will now start to cost me significantly in bandwidth charges. These things make moving cloud providers costly.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
