Containers are a hot topic these days. I have run a few workshops with clients, and one of the questions I get asked most frequently is “what are companies using containers for?” After answering this question a number of times, I thought I would share some common use cases with my readers.
Use Case #1: Continuous Integration
The most popular use of containers so far has been in the automation of the build pipeline. In the past, developers would automate their build process and then hand off their code to the Ops team, which would then deploy the code with its automated infrastructure scripts. The challenge that this presented is that there was often a disconnect between Dev and Ops, leading to deployment issues. Developers did not know the details of the target environment the code was being deployed to, and the Ops team did not know enough about the software it was deploying. This resulted in numerous meetings, checkpoints, review gates, and other wasteful processes that slowed down the flow of work.
With containers, the software build is deployed in a container with the infrastructure, which removes the handoff and extra steps. Now Ops can build standard images of the stack that developers can simply deploy their code to and test. That same image can be used across all environments (Dev, test, stage, prod), removing much of the risk of creating environmental issues every time the code is deployed. CI servers, such as Jenkins, have plugins for containers to make the build process very simple. The developer simply configures the CI server to use the appropriate container image and points to the location where the build is dropped, and the CI server does all the work. No more manual intervention, fewer meetings, and fewer issues. This improves the overall speed of the CI process while also improving the quality and reducing the risks.
Use Case #2: Containers as a Service
Another use case that is gaining traction is Containers as a Service. In this scenario, containers are used to create a platform for developers to build on. This is very similar to a PaaS but much more primitive. What I am seeing is that companies have complex environments with a mix of new and legacy technologies. Instead of reinventing the wheel across multiple applications and supporting many different web, application, caching, and database servers that need to be managed and patched, they create an abstraction layer using containers. Now they can manage and patch container images at a higher level and allow the application teams to consume those containers on demand.
Another advantage of containers in this scenario is that they allow the company to quickly add new technology components in a controlled and governed fashion. Let’s say a company wants to add MongoDB to its portfolio. The Mongo container and all of its components can be quickly built with the appropriate ports, firewall rules, and various policies. This container can then be offered to the developers for their consumption. The value here is the speed at which a new technology can be stood up and consumed. In the past, there was a steep learning curve for establishing these new environments. Now a certified image can be pulled down from Docker Hub and tweaked as needed, then quickly deployed.
Containers also allow for more experimentation. Since it is so easy to stand up and tear down containers, a developer can quickly compare the features of a stack component. For example, let’s say a developer wanted to test the performance of three different NoSQL database technologies to see which one best met the needs for a given use case. The developer could simply fire up the appropriate container for each NoSQL technology without having to deal with the complexity of managing the infrastructure and the underlying technology stack. The developer could then quickly run performance tests against each distinct container and select the technology deemed most appropriate for the use case.
Use Case #3: Application Modernization
Even though containers are best suited for modern microservice-based architectures, many enterprises are trying to figure out how to use containers with their legacy systems. In most cases, I would not recommend mixing legacy and containers, especially if the legacy system is tightly coupled with the infrastructure it runs on. But if it is a loosely coupled stateless application or can be modernized to be one without a great amount of effort, there is a good use case for containers.
Kubernetes and Mesos are very powerful tools for scaling and managing clusters of containers (both Docker and rkt containers). In many cases, precious IT resources are consumed building the IT plumbing required to make applications resilient, highly available, and highly scalable. A great way to modernize these applications as we move them to the cloud is to leverage technologies like Kubernetes and Mesos instead of building all of the nonfunctional requirements ourselves the hard way. Why not leverage Kubernetes, which Google uses to scale applications like YouTube and Gmail, or Mesos, which is used in large-scale implementations at companies like Twitter, Uber, eBay, and many others?
Summary
By now, everyone is aware of containers, but not everyone understands what the typical use cases are. The three I mentioned above are the ones I see the most, but many new use cases are evolving as the adoption of containers increases. Much of today’s container usage is in non-production environments, but that is quickly changing. As containers mature and the ecosystem around containers continues to grow, expect more use cases to evolve and more production success stories to emerge.