Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

The killer combination of DevOps and containers

by David Linthicum

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.

Understanding the value of container deployments

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, what changes?

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.

How containers and DevOps can play well together.

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:

  • It needs to add container development tools to the DevOps tools mix, including coding integrated development environments, container image repository management, container staging, container deployment, container testing and so on. The types and brands of tools will depend on the existing DevOps environment and how they mix with existing tool sets and the types of platforms they deploy on.  
  • XYZ needs to consider changes to the process, if any.  When most DevOps organizations adopt containers, they often find the process changes little, but process changes are required for DevOps success.
  • Finally, XYZ must plan for the required new skills.  Training is often required, or the company could hire DevOps engineers who understand DevOps and containers.  Mostly this is just adapting to what’s needed, in terms of container development, including architecture, performance, security and stability testing.  

Steps to make containers and DevOps work the first time

While your mileage may vary in terms of what you need to do, here is some general guidance:

  • Set up a group of developers and operators to provide input on steps to take for a successful containers deployment.  This should include containers subject matter experts, either trained or hired from the outside.  
  • Suggest changes to the core DevOps processes to accommodate containers.  These will typically focus on tools needed and special considerations with testing and deployment.  
  • Test new tools as to function and fit.  Ensure that they work consistently, using repeatable and automated processes.  
  • Create a skills gap matrix and do training and hiring planning to ensure that you have the skills that you’ll need to be successful.  
  • Conduct several proof of concepts to ensure that you have the majority of planning right, with the understanding that you’ll continuously improve as time goes on.  
  • Set up a group of people in development and in operations to monitor the progress of your container development processes and tooling, ensuring that both teams have input into what needs to be improved.  

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

For more Cisco news:

For more Cisco resources:

David Linthicum

David Linthicum is the chief cloud strategy consultant and a longtime contributor to a variety of technology publications.