What is the difference between Puppet / Chef / Ansible / Salt – and RapidDeploy?

One of the most common questions I am asked in the course of my work at MidVision is “What is the difference between [replace as appropriate] Puppet / Chef / Ansible / Salt – and RapidDeploy?” (It may also be followed by “We already use Puppet” i.e. we have an Automation capability already). Of course, the real question should be “What’s the difference between a Server Configuration Management Tool and an Application Release Automation Tool?”.

So the very short answer is – Puppet / Chef / Ansible and Salt are Server Configuration Management Tools. They are used for the provisioning and on going configuration management of servers. They can and are used to deploy and manage certain types of cloud native applications – but they are not designed for deploying many types of application runtime environments, especially those that currently exist in most Enterprise organisations.

RapidDeploy, and other mostly commercial toolsets, are Release Automation (or Application Release Automation – ARA) tools designed to support deployments to heterogeneous application runtimes.

So Configuration Management tools are ultimately designed to provision and manage servers – file systems, patches, packages installed, ssh keys, etc. Stand a server up, configure it as per a ‘Desired State’ definition and make sure it stays that way (so if anyone makes a manual change on a server that is not part of the ‘Desired State’, remediate it on the next run).

It is true that 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, which is it’s only function, 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 seen as one and the same. Many cloud native applications are designed in this way.

The short answer is that for most Enterprise Organisations today 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 it may have 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 co-ordination and orchestration that server Configuration Management tools were not designed to do and are not usually best suited to achieve.

Tools like RapidDeploy allow Application Release processes to be designed and orchestrated, building in dependencies and processes into the workflows, to support more sophisticated application deployments. It is not necessarily the automation they are better at doing – but the the co-ordination, orchestration and processes that they provide.

This comes to the heart of what I feel is often not a mature understanding of the tooling – I am certainly not saying RapidDeploy is better than Ansible, I am saying one is a Truck and one is a car – they are good at different things. RapidDeploy cannot effectively provision a 25,000 node cluster like Facebook do using Chef – nor can Chef effectively be used to manage most Enterprise Release Automation requirements.

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 point out is that in RapidDeploy 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.

At MidVision we have created 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, we allow users to do this visually. Now in the DevOps world the mention of a UI often gets people running – a lot of DevOps / 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 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 GPS’s 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 we would prefer to get something automated without having to do it, what we would call, the hard way. We absolutely allow and support our users writing scripts in Shell, Python, Ruby, PowerShell and almost any other language you would want to, but, in RapidDeploy for 80 percent of what you are likely to need to do you don’t need to write any scripts.

We have tasks, that can be orchestrated graphically, to create users or groups, do XPath find and replace, install packages, write to logs, call external REST services and thousands of other actions you might need to perform on Application Servers, Middleware and Databases that don’t require you to write a script. They are self explanatory and self documenting – and you don’t need to have years of experience to use it. We have put user experience and simplification at the heart of our product design.

If you are a system administrator this will allow you to focus on higher value activities. You can quickly automate the first 80 percent of what you need to do – and if your so inclined and technically competent you can call scripts or write actions to achieve more bespoke or less common activities.

If you’re a manager – then it should allow you to hire and onboard staff more easily, reduce reliance on key highly skilled individuals that normally take responsibility for scripting solutions, and have a greater level of transparency of the automation that has been created. I live and breath in the world of DevOps – and my friends and the community often struggle to read scripts they have written 6 months ago, let alone one someone else wrote two years ago. In my experience, what happens more often than not in the latter scenario is that the engineer picking up someone else’s work starts again.

To be clear though – I am absolutely not saying the way we do it is better than a more technical script based framework. In the same way I am not saying a self navigating trail run is better than a road marathon, but I am saying that different organisations should chose tooling appropriate to their requirements and skill sets.

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 is most likely to fit the bill.

However, if I worked in an Enterprise organisation, with 20 or 200 different applications to manage, with existing operations staff who are not programmers, then I would look at a tool that was more fit for my organisation. It is these organisations we have in mind when designing RapidDeploy.

Scaling DevOps projects and resourcing them is becoming increasingly problematic for organisations today – and one of the reason for this is that the most commonly used 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 – Citi Bank, Lloyds Banking Group, 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). Common Server Configuration Management tooling is probably appropriate to manage the hundreds or thousands of servers that exist in their entire estate – but they are not designed nor in my experience being implemented to manage the application tier within these organisations.