It's turtles all the way down....
Do not make application portability your primary driver for adopting Kubernetes, say Gartner analysts Marco Meinardi, Richard Watson and Alan Waite, because while the tool theoretically improves portability in practice it also locks you in while potentially denying you access to the best bits of the cloud. The three advance …
Tuesday 8th September 2020 06:54 GMT Warm Braw
Most applications won’t migrate between cloud providers
It's not so much the technical lock-in that's the problem as the financial lock-in that accompanies it. Especially if, long-term, the trend to "cloud" means that you can no longer get hold of the kit you would need to revert to on-premises operations because it's all being custom-made for proprietary bit barns.
Tuesday 8th September 2020 07:05 GMT AMBxx
Tuesday 8th September 2020 07:28 GMT Mike 137
Not just Kubernetes
Once you're committed to any cloud technology or provider it's remarkably difficult to extricate yourself. It's not just a matter of contractual tie-ins - it's about actually recovering your data and ensuring your processes continue to operate. Some time back I investigated two mainstream cloud based SaaS "office services" and found that their internal data formats were sufficiently different that you couldn't transfer files between them without utterly corrupting the presentation of documents.
"When you've got them by the balls their hearts and minds will follow" Charles Wendell Colson
Equally, their wallets.
Tuesday 8th September 2020 07:40 GMT Gaius
Tuesday 8th September 2020 09:12 GMT Robert Grant
This seems a bit unfair. I've moved an app between two of the big three, and also a third provider, and it's been relatively painless. All terraform, all kubectl and helm for deployments - just change URLs and secrets. All logging and most monitoring goes to Datadog anyway. Network setup, non-Datadog monitoring and IAM, sure. They need to be redone. But it was pretty painless.
Tuesday 8th September 2020 10:59 GMT werdsmith
Wednesday 9th September 2020 08:59 GMT Throwexception0
Only certain kinds of application would deploy painlessly.
Only certain kinds of application would deploy painlessly. I suspect the kinds of application that would deploy painlessly would have another design/architecture that doesn't assume k8 is in the foreground, and that design would be able to simplify itself even further.
Thus the authors point about the "tax".
K8 forced a certain (high) level of operational overhead, additional security gymnastics, log collection, specialty tools to deal with tracing and secret vaulting, special sauce to deal with data/mounts and stateful across crash fault lines.
Sometimes, after you peel away the layers, it comes down to the core developer still want to write applications "the old way", with packages, libraries and dependencies that "look like client server".
Truly "cloud freedom to dream" solutions are thus hidden if we have to translate everything back to client/server, code-packages-os paradigm. It's like trying to be cloud modern, but without really doing it, abstracting every thing back to what a kernel understands.
On the absolute opposite of k8s, are event based customizations for a series of AWS data-exchange, s3, sns, step functions; or the no code platforms that customize business tables and logic; or the Azure functions you add to SharePoint or office workflows. None of these examples, warts or not, demands the reduction of application back into "code-packages-os", but instead forces a different way to think about solutions.
That's what cloud should be.
Tuesday 8th September 2020 14:00 GMT Anonymous Coward
Simon, this is ridiculous on so many levels
First: You are basing an entire opinion of Kubernetes on a Gartner report. Did you even try to talk to a user for another opinion? Most Reg articles do a good job of contrasting what analysts say vs the real world, rooted in people who actually USE the technology. You know like everyone here that Gartner doesn't actually use the tools they cover.
Second: If you had actually talked to a user, you probably would have learned that one of the big advantage of K8s is that you can build locally, deploy anywhere. That's not the same as moving between public clouds - which isn't the common use. It's a 'plan b' if you need to move but that's NOT why you should adopt or use K8s. Cloud-native works for some but it's not the ONLY way to build and deploy.
Wednesday 9th September 2020 14:47 GMT Lord Baphomet
Re: Simon, this is ridiculous on so many levels
I totally agree. The guys who wrote this report are full of sh1t and have no idea what they are talking about. It reads like it was funded by VMWare in a desperate attempt to convince people that their product is still relevant.
Portability doesn't even mean the things they're suggesting it means. Portability is about maintaining control of your own business rather than ceding it to a vendor. Kubernetes is not a vendor technology, it's an open-standard, and adopting a popular open-standard with support from this many organisations, and vendors, is a very good idea and cannot in any way be considered 'lock-in'.
I demand that you rewrite this article pointing out that the three authors clearly have no understanding of that of which they speak, and that they clearly belong to the 95% of the industry that is incompetent and without whom we would all be a lot more productive. These guys should be fired, and the author of the article should be castigated for repeating such tosh.
Tuesday 8th September 2020 15:39 GMT Gonzo wizard
Tradeoffs are a constant, getting them right is the key
The most frustrating thing about what I've just read is that every time we choose to use one service or piece of software over another, we are making a decision that involves tradeoffs. Every. Single. Time. Kubernetes is no different and neither is choosing a cloud to run on. What's important for one company is not necessarily as important to another. If a company doesn't get right what is important for it in any of these decisions then it is liable to get it wrong.
In short, this Gartner thing feels like it is stating the obvious.
Tuesday 8th September 2020 16:51 GMT DCFusor
Re: Tradeoffs are a constant, getting them right is the key
Yup. But given much of what I see reported here, as well as observe on my own, restating the obvious can easily be a positive service to many.
There are whole columns here on The Reg that are, roughly speaking, about "oops of the dumbest sort".
Wednesday 9th September 2020 11:39 GMT Dinanziame
Sounds logical to me
The trade-off is that either you choose vendor-specific solutions with additional features which lock you in with that vendor, or you choose vendor-agnostic solutions which lock you out from vendor-specific features. Vendor-agnostic solutions may gain additional features, but more slowly because most vendors need to implement them.
I think the main question is, how sure are you what you want? If you are very sure, and you have the expertise, go for the exact solution you want. If you don't, go for vendor-agnostic. Wait until you understand the trade-offs before committing to a vendor, because going in is much easier than going out.
And no matter what you do, don't choose Oracle.