Blog post

Why Adopting Kubernetes for Application Portability Is Not a Good Idea

By Marco Meinardi | September 04, 2020 | 6 Comments

Infrastructure, Operations and Cloud Management for Technical Professionals

I often discuss with clients in infrastructure and operations on whether their organizations should adopt Kubernetes to make their applications portable. If you also have this question, the answer is: no.

Actually, the full story: adopt Kubernetes for the many benefits it provides to application development and architecture and get portability as a side effect. But do not make portability your primary driver for adopting the technology. This thesis is well expanded in the document that Richard Watson, Alan Waite and I have crafted during lockdown this spring: “Assessing Kubernetes for Hybrid and Multicloud Application Portability” (paywall).

Kubernetes or not, application portability always comes at a price that you must be willing to pay – the “portability tax”. Gartner’s advice is to make this decision application by application, based on the likelihood that it will be moved in the future, and how fast that needs to happen. In fact, non-portable applications may still be moved, it will just require more time to execute the transformation.

What is the likelihood that applications change infrastructure provider through their lifespan?

Inquiries show that this likelihood is actually very low. Once deployed in a provider, applications tend to stay there. This is due to data lakes being hard – and expensive – to port and, therefore, end up acting as centers of gravity. The figure below shows the Gartner pyramid of portability, which illustrates basic motivations (at the bottom) and more strategic ones (at the top) for designing portable applications.

The Pyramid of Portability and Multicloud Needs

For each of your application, ask yourself why portability is important to you. Is it to guarantee survivability? To increase your negotiation leverage with the cloud provider? To mitigate vendor lock-in? The higher you are in the pyramid, the least likely it is that you’ll have those needs.

Kubernetes facilitates portability because it helps standardize our software development life cycle and, most importantly, our operating model. However, it also adds management overhead to our organization, it forces us to engage with commercial vendors and to completely rearchitect our applications. Implementing portability with Kubernetes also requires avoiding any dependency that ties the application to the infrastructure provider, such as the use of cloud provider’s native services. Often, these services provide the capabilities that drove us to the cloud in the first place.

In conclusion, the portability tax is high. Make sure to pay it only for applications that truly need it and that are likely to switch infrastructure provider at some point. For all the others, don’t choose Kubernetes on the basis of a universal portability principle, just because it “sounds right”. On the contrary, adopt Kubernetes for agility, scalability and for modernizing your application architectures.

More on this topic in “Assessing Kubernetes for Hybrid and Multicloud Application Portability” (paywall). Should you want to discuss more, feel free to schedule an inquiry call with myself or Alan Waite by emailing or through your Gartner representative.

Follow me on Twitter (@meinardi) or connect with me on LinkedIn for further updates on my research. Looking forward to talking to you!

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Leave a Comment


  • You are right that Kubernetes enables modern, scalable applications and agile ways of working. It would be interesting to see data if you have gathered it from clients, quantifying these effects which are widely reported but sometimes anecdotal.

    Portability is really important. The point is “skills portability” due to using a standard operating model and tool chain. Large organisations want developers to use standard ways of working because this reduces training costs, and removes obstacles to staff moving from project to project. It also makes it easier and cheaper to apply policy if your “platform” (or platforms) are based on the same core set of cloud native tools.

    So: portability is flexibility.

    And yes you may want to move your app if GCP or AWS launches some great new chipset, but indeed, this is less common.

    Alexis Richardson, CEO Weaveworks

  • Anonymous says:

    What a weird article. It seems to try to argue choosing kubernetes for probability is a bad idea and then proceeds to list all the reasons why going they route is the right choice and all the benefits it can bring.

    Portability allows state replication where the docker file and database can bring a disaster back online instead of a full backup. It ties in with scalability as mentioned. High availability is closely related. Not to mention kubernetes itself is an ecosystem with a community sitting atop all the crowning goals of the enterprise industry.

    Like sure if you’re still growing an idea go with whatever is simplest. The value is in proving a product. But if you’ve already proved you have a product it just feels like the right direction to me.

  • Bert Laverman says:

    So: Kubernetes facilitates portability, but be aware you now have to manage a Kubernetes cluster?

    Quote: “it forces us to engage with commercial vendors and to completely rearchitect our applications”. This is kind of belaboring the obvious. If I _don’t_ go for k8s and host myself, I have to deal with vendors of hardware, operating systems, and virtualization software”. Completely re-architecting the application depends on your current architecture. If you have good Software Architects, it’ll be a very easy migration!

    I guess this article only makes sense for those with outdated architectures.

  • Gadi says:

    That is one big weird headline for a blog that glorify k8s.

    You should really write a blog on whether app portability is really needed.

  • Mijo Safradin says:

    As an enterprise architect for container infrastructure I came across the portability issues of Kubernetes quickly. On the other hand I am not aware that any project I’ve been involved did pick Kubernetes for application portability reasons. This fairy tale was only put on some sales slides in early days.
    Therefore the statement “get portability as a side effect” is confusing me – as I did never see any portability side effect out of the box. As you wrote, it’s a “portability tax” -> which means “no portability” to me. I am telling my customers, if they pick Kubernetes, they must be willing to pay the “Kubernetes tax” – to use your wording here. I could write a similar Blog post about why it’s also not a good idea to pick Kubernetes for agility, scalability and modernizing application architecture reasons. Kubernetes will luckily evolve further and get to the point where any type of “Kubernetes tax” is mitigated or resolved – but we are just at the beginning of this journey. Time to market looks different. Container technology is evolving and growing. The future is bright and anyone should adopt container technology, doesn’t matter what container tools or container ecosystem they pick, it’s a great investment in general and will build the required skill set and experience to master future IT stacks. This would be my selling point to companies if they still want to compete and exist in 2030.

    Application portability is actually a software engineering task and delegating this task to the infrastructure stack like a container platform should not be best practice. Also putting things into the right context is important when speaking about specific container technology aspects. As Kubernetes is just a small portion of a container stack – if given at all. By looking at the big picture, the application architect does build/select the tool landscape according to the problem statement not building the application around a given software like Kubernetes. Future developer and operation teams must adopt a new thinking pattern which can mostly be gained by experience only.

  • Vijay Chemuturi says:

    I completely disagree with the title of this article.
    Kubernetes is mainly for modernize the applications using containers and deploy containers at scale. Kubernetes is mainly for scalability, agility and recently large enterprise applications are considering the modernizing their existing legacy applications. I can understand “Portability” is one aspect that Enterprise Architects should consider but that is one of the important aspects that they consider along with many other aspects in their application modernization strategy. In recent years, Containers technology has improved a lot and almost all the major cloud providers are considering supporting Kubernetes. In my opinion, Enterprise architects should consider Kubernetes for their applications portability and other aspects of modernizing their applications.