There are many areas of Development and Operations toolchains that are clear to understand and compartmentalize. CI/bBuild, source control, artifact repositories, log management, APM and others each are relative easy to comprehend what they do and what tools are available within each area. There may be debates about whether Git is better than Subversion, AppDynamics or New Relic, or whether to choose Splunk vs Elastic Stack, etc., but what the tools are used for is in little doubt.
I don’t think this is as clear for configuration management and application release automation areas. Both of these areas overlap in multiple areas—both are fundamentally providing automation capabilities, they share common taxonomy such as “desire state” and “declarative/imperative,” both are looking to achieve streamlining of system and application updates, and both are concerned with issues including reliability, audit and accelerating release cycles.
So what is the difference between them? This is what I intend to try to highlight in this post.
What Are Configuration Management Tools Best Used For?
So the very short answer is configuration management tools—Puppet, Chef, Ansible and Salt, for example—are server configuration management tools. They are primarily used for the provisioning and ongoing configuration management of servers. They apply changes to infrastructure using an “infrastructure as code” approach where the “desired state” of infrastructure is stored in a repository—usually a source control system—and updates are applied to managed systems to ensure they are in compliance with the infrastructure’s “desired state.”
Changes to these systems should be made using the config management tool interface/language, with the automation routines normally written in Ruby or Python and configurations exposed as properties in something like JSon or YAML. Any changes made directly on a target server, will likely be reverted to the “desired state” definition when the agents or systems next synchronize with the master.
They can also be used to deploy and manage certain types of applications very effectively. This is I believe is the route of much of the confusion, as some organizations/applications use configuration management systems for provisioning, infrastructure configuration and application deployments. They normally do this by deploying system and application changes in exactly the same way.
What is Application Release Automation, Then?
So the predominant difference in my opinion is that application release automation does not see an “application” and a “server” as the same thing. The application, rather than the server, is the core construct. An application is often made up of many components, each of which may run on the same or different servers; they may have relationships with each other or they may be version-dependent on other components.
Application release automation tools allow organizations to define the components and structure of an application within a deployment tool, often allowing components to be released together—in many cases, orchestrated in a specific order.
Why Are Configuration Management Tools Used to Manage Applications?
Configuration management tools can be used very effectively to manage certain types of application runtimes—predominantly those where the server and the application are synonymous. So, for example, if you have an Ubuntu server, which runs a stateless application or microservice and is not version-dependent or closely coupled with other applications components in your environment, it may be right to use a configuration management tool for the application as well. The server and the application in this sense are one—much in the same way a container and an application are often see as one and the same. Many cloud native applications are designed in this way.
How is Enterprise Release Automation Different?
The short answer is that today most enterprise organizations may have components of their infrastructure that are loosely coupled based on cloud native runtimes, but the majority of it has not been designed this way. Certain hubs within the organization may be architecting and designing much more contemporary cloud native architectures that require no orchestration, but much of services and core systems were implemented prior to this.
In these organizations, the server and the application are different things. They are not synonymous. A server will have:
- JBoss or WebSphere installed on it;
- Some configuration that joins it to a cluster or cell or domain;
- An application that is deployed to it via some external controller using a REST API, JMX or some proprietary API (not just by connecting to the underlying operating system and copying something onto it); and
- Some relationships with other components that make it not loosely coupled (web servers, databases, etc.).
These types of application deployments require a certain amount of coordination and orchestration, which server configuration management tools were not designed to do and are not usually best suited to achieve.
ARA tools generally allow application release processes to be designed and orchestrated, building in dependencies and processes into the workflows, to support more sophisticated (or complex!) application deployments. It is not the automation they are better at doing for enterprise releases but the the coordination, orchestration and processes they provide.
This comes to the heart of what I feel is often not a mature understanding of the tooling: One category of automation tooling is not applicable for all use cases. I am not saving any of the ARA tools are better than Ansible, Puppet or Chef; I am saying one is a truck and one is a car: They are good at different things. ARA tools won’t effectively provision a 25,000-node cluster like Facebook does using Chef, nor can Chef effectively be used to manage most enterprise release automation requirements that are not based on loosely coupled cloud-native applications.
Are There Other Differences?
The obvious answer is, of course, yes. There are many differences between the configuration management tools themselves, let alone between the server configuration management and application release automation tools. However, one noticeable difference I often point out is that in most ARA tools, users create their automation process in a graphical user interface, not using a scripting framework.
Server configuration management tools generally have a scripting framework, configured using a text editor with formats in Python, Ruby, YAML, etc. They require the user to have a significant experience and skills do this if they are to be effectively implemented.
Most ARA tools use a graphical editor to perform these activities. So, instead of writing scripts in shell with if, for and while loops, calling recipes in a Python script to install a product, users achieve much of this capability using a visual editor. Now in the DevOps world the mention of a UI often gets people running—a lot of DevOps or automation engineers like scripting, they are familiar with it and enjoy learning new languages. Much as they probably like using vi as a text editor. But having to know that “ESC, :, wq” is how you save and a close a document in vi is not for everybody. File, save or file, close works for other people.
I started Ultra Trail Running recently, and there is a lot of machismo about routes not being marked and GPSes not used. Part of the attraction is that you use a map and a compass. Well, personally I’d rather have a GPS and focus on just running. Much the same as I would prefer to get something automated without having to script it if I didn’t need to. Power capabilities are usually provided in ARA tools for people to invoke scripts in Shell, Python, Ruby, PowerShell, etc., but they attempt to cover the most common tasks without the need to script.
Let Your Requirements Determine Your Tooling
If I were building a next-generation platform as a service (PaaS) using Docker and Kubernetes, I would recruit a small number of highly skilled and highly paid individuals to do this and let them take a lead on the tools they chose to deliver that—accepting Ansible, Stackstorm or something similar most likely fits the bill.
However, if I worked in an enterprise organization with 20 or 200 different applications to manage and operations staff who are not programmers, then application release automation tools are probably more appropriate for the organization. It is these organizations that ARA tools are designed for.
Scaling DevOps projects and resourcing them is also becoming increasingly problematic for organizations today—and one of the reason for this is that the most commonly used configuration management tooling was designed by an extremely smart open-source community trying to address issues for technology startups looking to scale modern relatively homogenous technology stacks to often massive scale.
This, however, is not the problem for most enterprises. Citibank, Barclays, GlaxoSmithKline or other such companies are not deploying massive amounts of the same types of servers. They are deploying a large number of different applications, each with many different development and test instances, at a relatively small scale (perhaps in the hundreds for a particular type in production).
Server configuration management tooling is likely appropriate to manage the operating system and basic configuration of hundreds or thousands of servers that exist in these organizations, but they are not designed—nor, in my experience, being implemented—to manage the application that sit on top of them.
Summary
Server configuration management tooling was designed and is most effective at managing large homogeneous infrastructures. If you were designing a new application infrastructure today, then it would absolutely make sense to standardize on a small number of common runtimes with loosely coupled applications that can be released, scaled and managed independently. If your environment looks like this and you have or are willing to recruit a new breed of DevOps engineer that is technically competent with config management tooling, then open-source config management tools may be appropriate for both your infrastructure and your applications.
Application release automation tooling was designed to meet the release automation challenges that exist in most enterprise organizations—i.e. the ones that have a long established investment in technology services and are not able or willing to move to the most modern application and infrastructure design patterns. The problem statement here is not managing a small number of runtimes at scale, but instead they have a large number of disparate applications, each at relatively small scale. These heterogeneous environments often have relatively complex release processes that necessitate orchestration and coordination, which is what ARA tools are best suited for.
However, even organizations with the largest variety of application runtime have normally standardized the provisioning, operating system, storage, security and other things so the underlying infrastructure is relatively homogeneous. In this case, server configuration management tools are mostly likely the best choice to manage the infrastructure, combined with an application release automation tool to manage the applications that sit on top of them.