As companies develop new applications and move to cloud-based models, the marriage of DevOps and containers makes sense for data center modernization.
Despite the recent hype in technology press articles about the buzzwords containers and DevOps, most people still don’t understand their combined value. By bringing together containers and DevOps—the former a lightweight means of virtualizing applications and the latter a methodology to join IT siloed teams—the benefits of cloud increase exponentially.
Moreover, and more important, you need to know when to exploit containers and when not to, as well as how agile and DevOps methodologies need to change surrounding the use of containers, and how much cost and risk these changes introduce.
In this article, we’ll cover the basics of containers, including their existing and future value. Then we cover their use in enterprise development shops, and focus on how to bring containers together with automated DevOps processes. With this combination, we argue, there is real possibility for data center modernization.
Containers are a lightweight and portable way to bundle applications in which the operating system, libraries, and anything else that the application needs are part of a container.
This isolation means that applications are decoupled from the platform, which gives containers the ability to move from platform to platform or cloud to cloud without having to modify the application, meaning both code and binaries.
This isolation brings portability, standardization and flexibility to development environments. With containers, developers can spend less time debugging environments and assessing differences between environments and more time on development.
Moreover, containers can run within management and orchestration layers, such as Kubernetes, a platform to manage containerized workloads. These orchestration systems enable containers to scale because they can be replicated to support the processing power needed to run containers and the applications within these containers.
The true return on investment for containers involves new application development projects and application modernization. Thus, container deployments are most successful when applications are migrating to the cloud and need updates or when new applications are built from scratch and need portability and scalability.
DevOps is a methodology that enables developers and IT operations teams to work more closely and collaboratively. The result is shorter and more iterative development cycles, with a focus on delivering business needs.
With DevOps, the focus is on people and process more than tools and enabling technologies such as containers. It’s easy to adapt processes to deal with containers through the DevOps process, as well as update the tooling to support container deployments.
The real changes occur within continuous testing. Containers need to have their contained OSes tested along with the applications. The current instance of the OS running within containers needs to ensure that the dependences, such as the network connections, libraries, security subsystems, and data, are available and working and playing well with the contained OS.
Moreover, you need to test containers within any container orchestration systems where you may deploy. Kubernetes, for instance, should be considered in terms of the dependencies internal to that layer, as well as its ability to scale and provide the needed security.
These adaptations are not new to DevOps. Considering the number and types of technologies they leverage for both development and deployment, the ability to adapt to newer technology such as containers is old hat for most DevOps engineers.
Focus on the tooling and the people, more than the process. If you have a workable DevOps process where most on-premises and cloud deployments are successful, it’s just a matter of looking at what tools need to change and what skills need to be updated.
Case in point: Company XYZ has 10 years of experience with DevOps in support of LAMP stacks and no plan to move to containers when the company moves to the cloud. The company should consider a few things:
While your mileage may vary in terms of what you need to do, here is some general guidance:
While this seems like something that many DevOps shops have gone through, it’s not. Many have done container deployments as one-offs, and set up development away from the DevOps organization for now. The typical plan is to integrate DevOps and containers at some point in the future.
This is rarely the best approach since that delay typically doubles your workload. It’s better to start with DevOps and containers than try to retrofit the combination down the line. Integrating these teams and their joint input is one of the key paths to success as you bring DevOps process into your container deployments.
This article is part of our hybrid cloud strategy guide.
David Linthicum is the chief cloud strategy consultant and a longtime contributor to a variety of technology publications.