back to article No, Kubernetes doesn’t make applications portable, say analysts. Good luck avoiding lock-in, too

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 …

  1. A Non e-mouse Silver badge

    It's turtles all the way down....

  2. Warm Braw Silver badge

    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.

  3. AMBxx Silver badge
    Joke

    Abstractions

    But, what if we had another abstraction layer on top of the layer on top of the original abstractions.

    Oh.

    1. IT's getting kinda boring

      Re: Abstractions

      Before you know it, there will be so many abstraction layers you'll probably find your workload is running on a cloud connected fridge in Alabama.

      1. Jim Mitchell

        Re: Abstractions

        Well, that explains how cloud providers are adding ARM to their cloud. Fridge owner pays the cooling bill, too

  4. Mike 137 Silver badge

    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.

    1. Robert Grant Silver badge

      Re: Not just Kubernetes

      SAAS is genuine lockin, for sure.

  5. Gaius

    Was this not obvious to everyone from the start? How did you think any provider would commoditise their service and still make money?

  6. Robert Grant Silver badge

    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.

    1. werdsmith Silver badge

      I think if the deployment is planned and built and maintained with portability in mind then it's not such a problem.

      If people do their deployments quick and dirty and take the easy options then they will more likely find themselves in locking quicksand.

    2. 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.

  7. Anonymous Coward
    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.

    1. 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.

  8. Gonzo wizard Bronze badge
    Meh

    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.

    1. DCFusor Silver badge
      Happy

      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".

      Common sense....isn't.

  9. Dinanziame Bronze badge

    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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020