Containers are here to stay. The question is when will they become more widely used than virtual machines?
Containers are software designed to package an application and its dependencies (libraries, binaries, and configuration files) together so it can run quickly and reliably when a developer moves the application from one computing environment to another. They also provide smaller, more agile app deployments that enable teams to release code faster. Since most enterprises are taking steps to reduce the friction of app portability, containers are the next natural step in an enterprise transformation strategy.
Why containers are portable
Containers share a common lightweight Linux OS and only keep the different pieces unique to the application within the container, which makes them much more portable than VMs. When combined with an orchestration system, such as Kubernetes, you can run the same container (or code segment) on any Linux operating system.
For example, you can develop an app and take it from your desktop and move it to AWS, Google Cloud, or the Microsoft Azure container environment – all without needing to make significant adjustments to the code. Of course, no container today is purely portable; however, you can dramatically reduce the dependencies to the virtual machine by moving to a container strategy.
Containers gain ground in the enterprise
According to a recent Forbes article, container adoption is growing rapidly in the enterprise—much faster than expected. A new Gartner report agrees: “By 2023, more than 70% of global organizations will be running more than two containerized applications in production, up from less than 20% in 2019.”[i]
As I mentioned above, one reason for this growth is due to their portability – a definite plus in today’s hybrid cloud world. Containers allow developers to move applications faster and easier from one environment to the next. For example, you may want to create an applications in one public cloud, move it to another for testing, and then place it on premises for production.
Another benefit of containers is their efficiency due to microservices. Containers let developers create applications using small services instead of a monolithic architecture. When using this type of approach, developers can easily make a small change to an application and push it out immediately – without affecting other microservices. Microservices in containers let businesses create applications faster, which means they can be more responsive to market demands.
Another recent event that helped grow the popularity of containers is the rapid rise of Kubernetes, an open source, container orchestration tool. Kubernetes allows you to take containers and put them in the right place, manage them, and shut them down when they are not working or are having behavior problems. In the last two years, Kubernetes quickly displaced a number of other private orchestrators, becoming the platform of choice for containers.
How to start implementing containers in your enterprise
As the popularity of containers continues to grow, every enterprise should embrace a container initiative. To get started, I suggest the following:
- Get to know Kubernetes
Most likely your developers are already using Kubernetes, even if that information isn’t shared with the central IT team. Just like in the years when public cloud started, shadow IT was commonplace. The same thing is happening now with containers in enterprises. Find the people currently using Kubernetes and bring their work out into the open. Encourage a culture of learning and sharing knowledge about the Kubernetes stack in the public cloud.
- Find your hand raisers
If you can’t find anyone who is already working with containers, create a team to do just that. Look for individuals within your development group who believe in a container strategy and are eager to learn. These are your hand raisers, and once you find them, encourage them and provide resources. The team can start small with a self-contained environment not connected to your corporate network, which will allow them to learn in a low risk environment.
- Encourage participation and learning
Organizations such as Cloud Native Computing Foundation (CNCF) support Kubernetes and provide numerous opportunities for learning and support. Encourage your IT operators and developers to participate in these types of organizations. Your teams should also stay up-to-date on container-related offerings, as the industry is quickly changing.
- Analyze your current IT estate
Before implementing a container strategy, you must have a good idea of your current applications and what type of environments they are best suited for. Decide if you will build applications net new or if you will refactor them. If refactoring legacy workloads, look for ones that are standalone and don’t require other apps to run. These are the best candidates for containerizing.
- IMPORTANT – know where your data lives
The most important thing to consider when building a container strategy is to understand where your data lives. If the application you plan to containerize relies on data that lives on premises, you will need an on-premises solution for containers. Specifically, you will need a platform that handles both stateful and stateless environments at the same time. Since not all applications are going to be architected or written to the new cloud-native architectures, we must be mindful of the legacy world and understand that is where the majority of today’s workloads are running.
We are at the tipping point for container technology
Containers are becoming the next level of abstraction and virtualization necessary for application development to move faster. Adoption of containers and microservices is real and is transforming how enterprises are deploying IT infrastructure. We’ve reached a tipping point; it’s time for enterprises worldwide to embark on a container strategy, or they just may miss the boat.
To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.
