Building a container strategy―13 potholes to avoid

July 13, 2020

Originally published on Hewlett Packard Enterprise’s Enterprise.nxt digital publication.

To pave the way to success, give developers flexibility, evolve your networking strategy, and set realistic expectations.

Containers and the rise of Kubernetes is the most talked-about, most impactful IT technology today. Containers give enterprises the ability to do amazing things, like build applications faster, move workloads between platforms, and optimize their environments.

Used correctly, containers open the agility doors of the organization and enable teams to build solutions faster than ever before. But, as anybody who’s implemented a new technology knows, pathways aren’t always smooth. Here are a few potholes to avoid as you embark on your road to containerization.

Don’t restrict your developers’ agility. Developers want to create great software, and they like to work in environments where they are comfortable. Rather than establish a structure for them to adapt to, give them the tools that give them the ability to create Kubernetesclusters on the public cloud, in their core data centers or at the edge.
Don’t treat containers like VMs. Containers may perform the same essential functions as virtual machines, but they present a different context that requires different skill sets. VMs aren’t going away. We will need to continue to manage them just like people still manage mainframes. They will continue to exist for many years. Containers are different from VMs and offer new ways of doing software development. Learn the important differences—between stateful and stateless apps, data persistence, and traditional versus cloud-native development processes—and leverage those differences in your organization.
Avoid vendor lock-in whenever possible. This may seem obvious, but hear me out. If your container strategy is written to a specific cloud service or using a cloud service as part of your strategy, try to minimize that exposure. Learn from the mistakes we all made when we adopted a single cloud platform. Embrace your open source community to leverage tools that enable application portability. Being able to move your application to another platform will be critical to your ability to stay agile in the future.
Don’t underestimate the volume of data your container platform will generate. The number of container nodes will dwarf the number of VMs you have under management. The sheer volume of telemetry data needed to manage and maintain compliance of your new container platform will require a different set of tools as well as a different set of data management capabilities.
Don’t expect your existing operating model to support the new container strategy. When you’re dealing with a significantly larger number of virtualization units (i.e., containers), your tried-and-true ticketing-based escalation process will not support the sheer volume of changes you need to put in place. You need automation to do that. Be prepared to build a team of site reliability engineers (SREs) that can write automation to support a new operating model.
Don’t expect your classic firewall networking segmentation strategy to work in the new container model. There will simply be too many nodes needing to talk to too many other nodes across too many different platforms for you to keep up with new firewall governance rules of legacy VM management. You need a new networking strategy that allows for a higher number of networking devices to communicate with each other.
Don’t expect your development teams to be consistent on their Kubernetes version adoption. Kubernetes is an open source platform that supports three curated versions at any given time. As the open source community releases newer versions, your previous versions will be out of date. You’ll need a plan to manage and control upgrade paths for each cluster independent of other development clusters. This requires you to have a control plane that knows how to manage multiple versions of multiple-platform Kubernetes distributions.
Don’t expect your teams to adopt just one cloud platform as a container strategy. Alliances have been formed. People have trained themselves to work on various cloud platforms or even to work on premises. You want to support their desire to have a Kubernetes container platform to run in whatever structure they would like. That means you will need a control plane to handle the task.
Don’t expect your executives to understand this new paradigm for some time. Containerization is a sophisticated technology. Although Kubernetes and containers have been around for a while, they’ve hit a tipping point in recent years. Executives may say they understand, but we’ve seen many executives ask for the basics first before they feel comfortable about establishing a strategy. Spend time with your executives. It will benefit you, them, and the teams.
Don’t expect Kubernetes to do it all. It doesn’t solve world peace, bake bread, babysit your kids, or solve your legacy IT problems. Set realistic expectations. A significant number of your legacy applications can run in a container, but a portion of them simply cannot and never will. The amount of money it takes to migrate them into a container will not be justified. Be prepared to maintain your VM-based infrastructure for quite some time for those legacy applications that you can’t invest the dollars in.
Don’t expect the adoption of Kubernetes to be easily scaled. Kubernetes is hard to scale and hard to manage. The amount of data it generates is significantly larger than what you’re used to, and you will want to push out your Kubernetes clusters to endpoint devices that may or may not be connected to your network. These are all new challenges. The Kubernetes ecosystem is still in its infancy.
Don’t expect container sprawl to slow down. Remember when public cloud was called shadow IT? Developers took out their credit cards and launched environments. Now, we are seeing this behavior on premises as well. Developers want to expand their use of containers. We need to embrace their desire to prop up and deploy Kubernetes clusters with containers where they want them, when they want them, on whatever platform they want them. You need a control plane and a data fabric that supports that direction. Be prepared for more container sprawl.
Don’t underestimate the size of your team’s skills gap. We can all agree: Containers are the future. But, at present, there’s still a serious lack of experienced resources to bring us forward to serve this next evolution of technology. Containers, Kubernetes at scale, and connected devices at the edge represent the last mile of your IT infrastructure. Organizations will struggle if they don’t invest the resources to not only attract workers who understand container-based technologies but also level up their existing staff’s skills in this important area.

Road map for success

Containerization is here―and it’s driving value for organizations across industries, throughout the world. Those who do the best job of embracing best practices and avoiding potholes along the way will gain a significant advantage over those who lag behind.