Guess what? Ask clouds to behave like old-school vendors, they will – and you lose Analyst firm Gartner has observed its clients asking hyperscale cloud vendors to behave more like legacy tech vendors – and feels that might not be the worst thing to happen to organizations seeking to tap into the value of multi-cloud. Speaking at the advisory org's Symposium in Australia yesterday, VP analyst Michael …
by the short and curlies when it comes to wanting to leave. The costs of the divorce would make Kanye/Kim blush, they are that high.
I think of them as being like drug dealers. "here, come and try my wares". Then you are hooked and bound and gagged to their service for eternity.
Those heavy rainstorms we are now getting is just a sign of a cloud provided shitting on a customer.
Before long, those providers and we all know who the major ones are will start taking over the businesses of their clients. That is step 2 in the 'Guide to Borg Assimilation'. You have been warned for years and years but the dumb FSKERS still keep on coming. Cloudy anything should carry a warning 'This is addictive as Fentanyl and as dangerous'.
Lock in for any Software system has always been a thing - cloud no exception. You'd just as easy get "locked in" to Lotus 1-2-3 or Excel, or a specific C compiler...
IaaS looks on face to be "safe" but VM drivers, networking setup, agents for monitors... PaaS, SaaS, on site systems, etc nearly always a lock in as soon as you start using the useful unique functionality that you bought the thing for!
On one hand, "Warrilow nonetheless advocated planning for multi-cloud adoption ... so you can diversify and avoid lock-in" and on the other, "Warrilow also advocated going cloud-native".
How can you avoid lock in when you've gone native on 2 disparate platforms?
I have yet to encounter a client that has made multi-cloud work as anything other than a toilet they can flush their budget down. Every analogue between providers works somewhat differently, and tools to try and abstract away those (like Serverless) don't work in practice without significantly customising their naive default configurations or adding in numerous third party plugins that aren't portable between clouds.
You need twice the number of skills in-house, pay through the nose for cross-cloud traffic, and can't shift workloads between providers without a lot of effort and testing. Even vendor-neutral technologies like Kubernetes have significant variances in the way they work out of the box if you use the one supplied by the provider.
There will be a tiny fraction of tech businesses for whom the total failure of an entire cloud provider is an existential risk, where going multi-cloud for resilience is the necessary mitigation. There will be a slightly larger one which need certain services and facilities that are not available from a single provider that may need multiple clouds in a rational hub-and-spoke model. But for everyone else, getting it working per the board's vision is a costly pipe dream that'll never be realised.
It's not very hard to migrate to public cloud providers with a suitable abstraction to enable porting between them, if/when needed, using Terraform or Palumi.
What does need to be understood is that on-prem technical architectures that depend on availability capabilities of hardware need to be redesigned, and, fairly obviously, moving from a large capex model to opex requires financial discipline. This latter point seems to be a surprise. However, I've yet to see an org that had a very good grip on the capex costs of IT systems, which tend to suffer similar issues to poorly managed supply chains: demand isn't well understood at initiation, but spend commitments are made then, and, since the buyer gets more grief for not meeting demand than for over-spending, too much is bought, which then leads to wasted efforts selling the excess supply in subsequent years.
I don't think there is a good understanding of the concept of vendor lock in. Vendor lock in is intentional, when you as a client agree to a contract that has punitive clauses in it in case you want to leave.
Getting into using a product because it is technically apealing, has features you can't build yourself, has security you can't build yourself etc. is not lock in.
Imagine a small company that creates the new youtube. They did not have to build datacenters, extremely performant technologies for fast scale up and down and yet they get to use that for a few hundred dollars during development and then scale as needed. Of course the cost scales too, you get to use shit you would have not invented yourself in 50 years, to run your app at global adoption rates of today.
Lock in is not providing good, innovative services, technology etc.; it is signing contracts on the golf courts and then finding out that you need to pay fines to get away!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
