It seems that containers and Kubernetes orchestration have replaced DevOps and configuration management on everyone's lips. Are container tools ushering in the end of an era for DevOps tools?
DevOps tools for configuration management enable developers to communicate application deployment instructions to IT operations personnel. Containers strike at this DevOps setup in two ways: an inherent deployment model and a more complex orchestrated one. Container software, such as Docker, provides a simple, native model for deployment and redeployment of application code. For more complex deployment demands, containers are supplemented with an orchestration tool, such as Kubernetes. Kubernetes is such a runaway winner in the container space that it's become more familiar in IT circles than Docker. External configuration, automation and deployment DevOps tools are rarely needed.
But don't jump to the conclusion that container tools make relics of DevOps and leading products to support it, such as Chef, Puppet and Ansible.
Container orchestration extends the basic container model, wherein an application is hosted in an IP subnetwork that has a private IP address space to connect components. The connecting on- and off-ramps to the application for workers or other applications are exposed explicitly. Container tools, such as orchestrators, work within those IP subnetworks -- and, sometimes, among them -- but they are not designed to handle a company's entire IP network or all the hosts in its data center.
DevOps tools can do anything a human operator can do, except apply on-the-spot judgment. They deploy application code on bare metal, into VMs or into containers. They can even build container systems on top of VMs on top of bare metal. The operations professionals can change network configurations and hosting assignments and apply complicated policies to handle special conditions. The tools can tell the hosting stack how to respond to specific events based on administrator input so you can control how workload spikes or failures affect app deployment and redeployment.
Kubernetes and other container orchestration tools, such as Marathon, could probably be augmented to support the same features. However, the driving force behind containers is enterprise desire for a simple virtual hosting model. Adding all those granular infrastructure control features to containers would inevitably add complexity and devalue containers for enterprises that seek speedy changes from development to live production. There will surely be container enhancements as large-scale projects hit production, but they aren't going to create a complete replacement for DevOps tools in existing deployment conditions.
Nothing ever dies in enterprise IT
The real question is whether container tools need to supplant DevOps ones. Some of container deployments' simplicity come not from tools but from the assumptions container systems make about application deployment. If those assumptions were made universally, might the result be a simpler application hosting framework that didn't need special DevOps-related features?
Container deployment is based on two presumptions. All the hosts on which containerized apps will run are connected into a cluster based on the same container hosting software. All hosting is virtualized, and containerized apps can depend on that consistency. Other deployments don't require this level of uniformity, and so, DevOps tools are essential where you can't provide it.
The barrier to displacing traditional DevOps tools is the simple fact that many organizations -- in fact, most -- need to run applications in setups other than containers.
The second precondition is that all the applications are deployed inside private address IP subnets and made visible to the corporate virtual private network or the internet through an address translator. If these preconditions are not met, container tools alone will be problematic, and you'll need more.
If an enterprise deployed all its applications in containers, both in the data center and in the cloud, the IT team could probably use container orchestration tools instead of configuration management software. The barrier to displacing traditional DevOps tools is the simple fact that many organizations -- in fact, most -- need to run applications in setups other than containers. If you can eliminate heterogeneity and go 100% to containers, you can probably eliminate the need for additional DevOps tools. If everyone did this, then traditional DevOps would become a backwater.
Everyone isn't likely to switch every application to containers. There is a powerful IT mindset saying that, if it's not broken, don't fix it, and so, mission-critical applications are slow to migrate to containers. Some applications won't run easily in containers, and some can't meet compliance and governance policies if they're container-hosted. Larger enterprises with a lot of regulations are unlikely to eliminate DevOps tools that enforce configuration rules. This is particularly true in companies that use a lot of internally developed software and where continuous development practices are in use.
DevOps really started with development and operations integration. As long as an organization does a lot of development in rapid cycles, it will be difficult to eliminate traditional DevOps tools that unite application lifecycle management elements. If you fit this model, containers can't kill off Chef or Puppet, at least for now.
In the future, container management tools will enable as-a-service-level automation for container-based deployments. Kubernetes is advancing in capability as fast as it's advancing in popularity, adding features that facilitate DevOps integration. Enterprises should monitor the containers-as-a-service model in products such as Docker Enterprise Edition, with lifecycle management capabilities, but be sure to fully validate the strategy before making a move.
It may be that third-party software will decide the fate of configuration management tools and DevOps collaboration. Internal development almost demands DevOps for large-scale Agile IT, but third-party packaged off-the-shelf software separates development into a different company from operations. If software providers build applications for container deployment, then everyone except enterprises that write software will end up adopting containers, and DevOps automation and configuration tooling will fade. If not, DevOps is here to stay.
