DevOps Landscape 2015: The Race to the Management Layer
There has been so much activity in DevOps tooling and best practices in the past few months that it has become difficult to understand the current and future state of the industry. This summary is the outcome of explaining HashiCorp’s thoughts on the current DevOps landscape and future roadmap.
The Goal of DevOps is to Turn Application Code Into a Running Application Through a Repeatable, Safe Process
“DevOps” as a term has many meanings, but for the purposes of this summary “DevOps” will be defined by its goal. Across organizations, the goal of DevOps is to turn application code into a running application through a repeatable, safe process.
The Road to a Complete DevOps Management Layer: Configuration Management vs Immutable Infrastructure
There are two paradigms to provide a complete management layer for delivering applications:
- Paradigm 1: Runtime Configuration. In this view, the workflow from application code to running application is provision a server; configure the server with dependencies and application code; and monitor application and server health with scheduled, continuous configuration management runs.
- Paradigm 2: Immutable Infrastructure. In this view, the workflow from application code to running application code is to package the application into a deployable artifact, such as a Docker container, AMI, jar, etc; then provision the server in the likeness of that artifact; and finally, monitor application and server health. It is very important to note that immutable infrastructure and configuration management are not mutually exclusive. Configuration management tools are often used to configure build-time artifacts.
The key difference between immutable infrastructure and configuration management paradigms is at what point configuration occurs. In the immutable infrastructure view configuration happens at build-time, before deployment. In the configuration management view configuration happens at runtime, after deployment. To make a service change in the immutable infrastructure world, a new artifact is built, the old service is destroyed, and a new service is brought up using the new artifact. The service is never changed once it has been deployed, and thus why this paradigm is called “immutable” infrastructure. To make a service change in the configuration management world, the same server is updated with new service code. Again, these paradigms are not mutually exclusive, as configuration management tools are often used to help build build-time artifacts.
There’s arguably a nascent third paradigm, which treats servers as a generic resource pool which heterogeneous workloads are scheduled on top of. This technically fits under the immutable infrastructure paradigm, but is unique enough to define independently. This paradigm is in active development as Mesos, Kubernetes, Docker Swarm, and various other schedulers gain in popularity.
The Management Layer is the Revenue Opportunity in DevOps
There are three basic layers in DevOps — infrastructure, tooling, and management:
- The infrastructure layer is comprised of technology that provides virtualization functionality to physical hardware to make compute, network and storage easily accessible. Example technologies are Amazon’s EC2 and Google Compute Engine in the public cloud arena, along with VMware and OpenStack in the private cloud arena.
- The tooling layer is comprised of technologies that make access and configuration of the infrastructure layer an easier process. These tools still require functional knowledge of the underlying infrastructure. Examples here are the open source tools by HashiCorp, Mesos, Docker, Puppet, Chef, Jenkins and many, many more. It’s interesting that the majority of the tooling layer is comprised of open source software.
- The management layer is at the top and has the goal of abstracting away both the tooling and infrastructure layers into one common workflow for turning application code into a running application. An example end goal would be to just package your application — potentially as a Docker container, rkt container, jar or binary — and have it be able to run on any cloud or physical infrastructure. Ideally, no knowledge of the infrastructure itself is necessary and all the logic is held at the application level.
The infrastructure layer is facing a wave of competition and commoditization, and we now see the companies in this space trying to move up the stack into tooling and management. Amazon Web Services (AWS) has released tools like EC2 Container Service (ECS) and AWS CodeDeploy, which allow users to simply package their applications and ignore the infrastructure configuration and provisioning processes. Google Cloud Platform has similarly released Google App Engine and Google Container Service, as well as sponsoring open source projects such as Kubernetes. VMware has moved into tooling and management with heavy support for Pivotal’s Cloud Foundry. These tools make it easier for users to deploy applications and allow infrastructure providers to lock users into their platforms.
The tooling layer is more difficult to monetize as the tools themselves solve pieces of the greater DevOps goal. It’s difficult to charge at enterprise levels for tools that package applications or provision infrastructure. Enterprises pay for tools that reduce costs through employee timesavings or material savings. These tools still require significant employee effort and are difficult to tie to material savings, thus are harder to monetize. It is certainly possible to monetize this layer through support and services; however, those are more difficult to scale.
The management layer presents the most significant monetization opportunity as it presents a full solution for turning application code into a running application. The employee investment is significant in the implementation phase, but relatively minimal for upkeep. If the management level can get into material cost savings, such as reducing the size of server fleets, there will be tremendous opportunities for revenue.
DevOps companies are racing to the management layer; however, several tools are necessary to have a complete DevOps management offering.
Three Types of DevOps Companies: Infrastructure Providers, Configuration Management Companies, and Immutable Infrastructure Companies
Given that the management layer has the greatest revenue potential, the active players in the space are all battling to capture the opportunity. The interesting aspect of this battle is that the different types of companies in DevOps are approaching it from unique vantage points. These organizations can be categorized as either infrastructure providers, configuration management companies, or companies that favor immutable infrastructure. Amazon Web Services, Google Cloud Platform, OpenStack and VMware are the major players in the infrastructure provider space. Ansible, Chef, Puppet and Salt are the leaders in configuration management. HashiCorp, CoreOS, Docker and Mesosphere are the leaders in the nascent immutable infrastructure space.
All of these companies must have solutions for infrastructure provisioning and application packaging or configuration in order to have a viable chance in winning the battle at the management layer. Historically, VMware is a great example of owning the entire tooling stack to win the datacenter virtualization market. If you look at the current product development across the companies, you can see that each is building tooling around these essentials. Chef has Chef Provisioning to provision infrastructure, and Chef configuration management to configure the application. HashiCorp has Terraform to provision infrastructure and Packer to package applications and build machine images. Docker has Docker Machine to provision infrastructure and Docker to package applications.
These tools are then combined into a dashboard or common workflow to provide a management layer. For example, Mesosphere bundles Mesos, Marathon and Chronos to create the Mesosphere Datacenter Operating System. HashiCorp unites Packer, Terraform and Consul to create Atlas. CoreOS recently released Tectonic to bundle etc, rkt and flannel into a management layer. The infographic below shows the tooling portfolios for the major players in these categories and how those tools are starting to develop into a management layer.
Predictions for the Next 12 Months
This summary identified infrastructure provisioning and application packaging or configuration as essential tools to build the management layer for DevOps. This conclusion leads to a few predictions:
- All companies in the immutable infrastructure space will have tools to provision infrastructure, package applications, schedule applications and monitor applications.
- Configuration management companies will get the majority of enterprise budgets. It will take the immutable infrastructure companies more than 12 months to make significant progress with enterprises.
- AWS will grow by 50 percent plus and soak up a larger percentage of overall infrastructure budgets. The AWS tooling ecosystem is significantly more mature than competitors and more companies are moving away from on-premises datacenters.
How to Choose a DevOps Management Layer
The purpose of this summary is to shed light on the crowded and opaque DevOps landscape. However, the obvious next question is, “How do I choose a DevOps management layer?” This question has many moving parts, and the best we can do is try to simplify some of the choices by answering a few questions:
Are two or more individuals working on your team’s infrastructure (part-time contributors are counted)?
- If no, the two best options are either Amazon Web Services or Heroku. If no one has ops experience, Heroku is the best choice. If someone does have ops experience, AWS is the most full-featured option.
- If yes, your team needs a way to manage the complexity of collaborating on infrastructure. Move on to the next question.
Do you want to do build-time or runtime configuration?
- If you want to do runtime configuration, use a configuration management tool such as Ansible, Puppet, Chef or Salt. If you want agent-based configuration management, use Puppet or Chef. If you want ssh-based configuration management, use Ansible or Salt.
- If you want to do build-time configuration, which means building images and immutable infrastructure, use Atlas by HashiCorp, Mesosphere, Tectonic by CoreOS, or Docker Hub. Move on to the next question to select between these options.
Do you want to automate the infrastructure provisioning process?
- If yes, Atlas by HashiCorp is the only option. Atlas uses Terraform to layout infrastructure as code and automate the provisioning process. Docker does have Docker Machine to provision Docker hosts; however, it is currently a command-line tool that only manages hosts, not a complete infrastructure.
- If no, any of the options by HashiCorp, Mesosphere, Docker, and CoreOS can be considered. However it is difficult to deploy applications without a means to automate and reliably provision infrastructure.
This basic decision tree is by no means exhaustive, but should help in the initial decision process for selecting a DevOps management tool.
