Cloud vendor lock-in is shocking, but there's a get out of jail card
(2024/04/08)
- Reference: 1712565014
- News link: https://www.theregister.co.uk/2024/04/08/cloud_vendor_opinion_column/
- Source link:
Opinion 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 [1]intended spend on AWS/ is enough to gravely risk vendor lock-in. Nobody wants to be on the wrong end of that, but the danger is far worse if you're a state department having to comply with strict fairness rules on tendering and proposals.
Vendor lock-in isn't a binary, it's more of a sliding scale, from complete freedom to do what you like to complete dependence on a single supplier. The more widely you use a supplier, the harder it is to move away. It's a power dynamic over who controls your IT decisions, which is why an early warning like this report demands immediate attention. What you can do about it, though, isn't clear, especially if you're dealing with a Too Big To Care vendor. Given you're worried about a power struggle, you most probably are.
[2]
The downsides of software and service vendor lock-in are familiar to most long-timers: cost escalation, design constraints, stagnant roadmaps punctuated by unwelcome swamp gas bubbles of upgrade pressure. You're unlikely to get into a position where it can bring down your company or endanger your country. Hardware lock-in, not much encountered in corporate IT, has the potential to be that dangerous. That's why hardware companies in the danger zone have evolved shields against lock-in, one of which is so powerful it shaped the evolution of our entire sector. It could certainly guide cloud services into a fairer power dynamic than the way they're heading right now.
[3]
[4]
Let's say you're a major military radar maker, building essential fighter jet systems. Most of the components in those are industry standard with lots of suppliers competing for your business. A few are unique, new devices from one vendor. You need them, but if that vendor goes bankrupt or has a production crisis, you and the fighters are in real trouble. The solution is a policy: no single-sourcing.
[5]UK govt office admits ability to negotiate billions in cloud spending curbed by vendor lock-in
[6]Apple's GoFetch silicon security fail was down to an obsession with speed
[7]Fujitsu set to be preferred bidder in UK digital ID scheme
[8]RISE with SAP plan fails to hit go-live date in West of England council
Otherwise known as second-sourcing, this means you cannot build anything into your products that has come from only one place. Where a supplier has a unique, compelling technology, you make it a condition of purchase that they license the design to another company. If you're an important enough customer, they'll know what's good for them.
The same idea used to be more prevalent in the civilian end of the industry. It may return to fashion now the importance of diversified supply chains has been seared on our post-pandemic consciousness. IBM, in the days when it dominated computing, had a second-source policy that made a lot of sense when many semiconductor companies had the life expectancy of a prematurely hatched mayfly.
Thus, when the IBM PC design team settled on the Intel 8086 family for its processors, a condition of the deal was that Intel had to hand a license to a competitor. AMD became a second source supplier, and give or take a massive [9]antitrust lawsuit , Intel then found itself with a worthy competitor, and the industry got the benefit of what turned into decades of ferocious innovation. Intel wasn't a fan of the idea, but it got the benefits of a market on fire just the same.
[10]
Services aren't silicon, but the details don't matter. IBM didn't much care how the second source came to be, just that it did and would be reliable technically and commercially. The same can be applied to AWS or Azure or anyone: we will use service X only if a viable, compatible Y is available. Not possible, you say? Fine, we won't use it.
If even the UK government is worried about being at the mercy of Amazon, that would seem to indicate the equations of power have already gone too far for this to work. Amazon and its fellow cloud giants can call anyone's bluff. What they can't do is call everyone's bluff. Or at least, everyone who spends more than ten million a year on AWS. It would even work if it was just a public procurement policy adopted by multiple states with a three year implementation window. It doesn't matter how the industry complies, just that it does.
Creating a fully competitive market is absolutely the job of the state, and it doesn't have to be through regulators. Everyone will benefit, even the cloud vendors themselves, and it's not as if we don't need new models of getting power back from the monsters. Open source remodelled software, second-source can do the same for the cloud. ®
Get our [11]Tech Resources
[1] https://www.theregister.com/2024/04/04/uk_cddo_admits_cloud_spending_lock_issues_exclusive/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/publicsector&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZhPAO67PW82K8pazhErKYQAAAJU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/publicsector&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZhPAO67PW82K8pazhErKYQAAAJU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/publicsector&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZhPAO67PW82K8pazhErKYQAAAJU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2024/04/04/uk_cddo_admits_cloud_spending_lock_issues_exclusive/
[6] https://www.theregister.com/2024/04/02/apple_gofetch_opinion/
[7] https://www.theregister.com/2024/03/26/fujitsu_id_card_scheme/
[8] https://www.theregister.com/2024/03/15/rise_sap_delay_england/
[9] https://www.theregister.com/2009/11/12/intel_amd_settle_suits/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/publicsector&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZhPAO67PW82K8pazhErKYQAAAJU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
The CDDO keeps an eye on where the money's going in government IT projects – our money, our services. It has spotted that the [1]intended spend on AWS/ is enough to gravely risk vendor lock-in. Nobody wants to be on the wrong end of that, but the danger is far worse if you're a state department having to comply with strict fairness rules on tendering and proposals.
Vendor lock-in isn't a binary, it's more of a sliding scale, from complete freedom to do what you like to complete dependence on a single supplier. The more widely you use a supplier, the harder it is to move away. It's a power dynamic over who controls your IT decisions, which is why an early warning like this report demands immediate attention. What you can do about it, though, isn't clear, especially if you're dealing with a Too Big To Care vendor. Given you're worried about a power struggle, you most probably are.
[2]
The downsides of software and service vendor lock-in are familiar to most long-timers: cost escalation, design constraints, stagnant roadmaps punctuated by unwelcome swamp gas bubbles of upgrade pressure. You're unlikely to get into a position where it can bring down your company or endanger your country. Hardware lock-in, not much encountered in corporate IT, has the potential to be that dangerous. That's why hardware companies in the danger zone have evolved shields against lock-in, one of which is so powerful it shaped the evolution of our entire sector. It could certainly guide cloud services into a fairer power dynamic than the way they're heading right now.
[3]
[4]
Let's say you're a major military radar maker, building essential fighter jet systems. Most of the components in those are industry standard with lots of suppliers competing for your business. A few are unique, new devices from one vendor. You need them, but if that vendor goes bankrupt or has a production crisis, you and the fighters are in real trouble. The solution is a policy: no single-sourcing.
[5]UK govt office admits ability to negotiate billions in cloud spending curbed by vendor lock-in
[6]Apple's GoFetch silicon security fail was down to an obsession with speed
[7]Fujitsu set to be preferred bidder in UK digital ID scheme
[8]RISE with SAP plan fails to hit go-live date in West of England council
Otherwise known as second-sourcing, this means you cannot build anything into your products that has come from only one place. Where a supplier has a unique, compelling technology, you make it a condition of purchase that they license the design to another company. If you're an important enough customer, they'll know what's good for them.
The same idea used to be more prevalent in the civilian end of the industry. It may return to fashion now the importance of diversified supply chains has been seared on our post-pandemic consciousness. IBM, in the days when it dominated computing, had a second-source policy that made a lot of sense when many semiconductor companies had the life expectancy of a prematurely hatched mayfly.
Thus, when the IBM PC design team settled on the Intel 8086 family for its processors, a condition of the deal was that Intel had to hand a license to a competitor. AMD became a second source supplier, and give or take a massive [9]antitrust lawsuit , Intel then found itself with a worthy competitor, and the industry got the benefit of what turned into decades of ferocious innovation. Intel wasn't a fan of the idea, but it got the benefits of a market on fire just the same.
[10]
Services aren't silicon, but the details don't matter. IBM didn't much care how the second source came to be, just that it did and would be reliable technically and commercially. The same can be applied to AWS or Azure or anyone: we will use service X only if a viable, compatible Y is available. Not possible, you say? Fine, we won't use it.
If even the UK government is worried about being at the mercy of Amazon, that would seem to indicate the equations of power have already gone too far for this to work. Amazon and its fellow cloud giants can call anyone's bluff. What they can't do is call everyone's bluff. Or at least, everyone who spends more than ten million a year on AWS. It would even work if it was just a public procurement policy adopted by multiple states with a three year implementation window. It doesn't matter how the industry complies, just that it does.
Creating a fully competitive market is absolutely the job of the state, and it doesn't have to be through regulators. Everyone will benefit, even the cloud vendors themselves, and it's not as if we don't need new models of getting power back from the monsters. Open source remodelled software, second-source can do the same for the cloud. ®
Get our [11]Tech Resources
[1] https://www.theregister.com/2024/04/04/uk_cddo_admits_cloud_spending_lock_issues_exclusive/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/publicsector&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZhPAO67PW82K8pazhErKYQAAAJU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/publicsector&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZhPAO67PW82K8pazhErKYQAAAJU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/publicsector&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZhPAO67PW82K8pazhErKYQAAAJU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2024/04/04/uk_cddo_admits_cloud_spending_lock_issues_exclusive/
[6] https://www.theregister.com/2024/04/02/apple_gofetch_opinion/
[7] https://www.theregister.com/2024/03/26/fujitsu_id_card_scheme/
[8] https://www.theregister.com/2024/03/15/rise_sap_delay_england/
[9] https://www.theregister.com/2009/11/12/intel_amd_settle_suits/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/publicsector&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZhPAO67PW82K8pazhErKYQAAAJU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
Terraform
Steve Button
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.
Why not have cloud.gov.uk ?
alain williams
Surely the demand is big enough to do it ourselves ?
• Cheaper than paying a USA company
• Under UK control (more secure)
• Build up UK based skills
Whilst the author is undoubtably right...
Anonymous Coward
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.
Why stop at cloud?
I love this - not particularly new - idea.
But why not do the same for
- operating system
- office productivity : word/excel/ppt
- email
- ms teams?