Defining the Roles of DevOps Deployment Tools
With so many DevOps deployment tools serving this market, the differences between them can be unclear. This article explores a few of the different DevOps deployment tool that talk about deployments and explains their function. Infrastructure Deployments, Kubernetes Deployment, Application Release Automation and Continuous Delivery Orchestration will be the focus.
Infrastructure and Kubernetes DevOps Deployment Tools
If we don’t have an infrastructure, we don’t have anything. When we read about DevOps deployment tools, there is lots of information about ‘infrastructure as code’ and deployments. Let’s be perfectly clear. These tools do not cater to the application teams, they cater to the operations teams. This category of tools is all about managing VMs, load balancers, databases, and for Kubernetes, the clusters themselves. When reading about tools in the category you will find information on stateless vs. stateful servers, a pets vs. cattle conversation. Tools in this category make it easy to deploy an infrastructure update automatically. They all take a slightly different approach, but overall cater to operations for tracking and deploying infrastructure layers. Tools that fit into this category are:
Chef and Puppet – Manages and deploys Infrastructure as Code. Popular in physical and cloud environments.
Rancher, Spinnaker and Containership – Manages and deploys your Kubernetes Clusters.
Docker – Container Platform Management.
AWS CloudFormation – A declarative, text based, method of modeling and provisioning infrastructure resources.
AWS OpsWorks – Managed instances of Chef and Puppet, for companies who have already invested in these tools.
Google Cloud Deployment Manager – Manage cloud resources with simple templates.
Application Release Automation and Continuous Deployment DevOps Deployment Tools
This category is often confused with the above group of tools. While it may seem like deploying an infrastructure component and updating an application component should be the same, they are not. First, application code is updated on a high frequency basis. Developers respond to end user demands as quickly as possible, pushing updates back to end users on a continuous feeback loop. Infrastructure updates do not occur at this pace. Second, agile developers want to manage incremental updates, not monolithic. Small incremental changes are applied has often as possible. DevOps deployment tools in this space need to understand how the application is initially installed and track the changes overtime. Now here is the confusion. Because DevOps deployment tools in this category can be extremely expensive, developers have used tools like Chef and Puppet to manage application level updates. They do so by managing the monolithic application in RPMs (Linux user only). It gets the job done, but does not provide the ability to manage an individual incremental update, or update a database schema change. DevOps deployment tools that fit into this category are:
DeployHub – Provides a central catalog of independent deployable microservices and reusable objects where developers can publish to and deploy from for updating applications and their database changes. Provides traditional ARA capabilities, with integration into Infrastructure deployment tools for tracking low-level changes if required. Agentless and designed for both microservice and legacy environments.
Harness, XebiaLabs, IBM UDeploy, Octopus Deploy, CA Automic, Electric Cloud – Traditional Application Release Automation solutions that package the entire application as a monolithic whole and deploys the package to environments (collections of servers or VM images in a cloud environment.) From this list, only Harness and Xebia are agentless. Agentless delivery is important for supporting serverless environments. Xebia does not do packaging. Octopus Deploy is popular in Microsoft shops.
AWS CodeDeploy – An AWS specific application deployment solution that focuses on an ‘end point’ release process. In other words, transports a file from point A to B.
Google Cloud Deployment Manager – A Google Specific application deployment solution that helps you move a YAML file that contains a applications components from point A to B.
Continuous Delivery DevOps Deployment Tools
Now you would think that anything that used the word ‘delivery’ would mean ‘deployment,’ but it doesn’t. Continuous Delivery is a category of DevOps deployment tools that manages the application life cycle and the steps within. Continuous Delivery centralize the steps of the application life cycle, like a job scheduler. It itself does not do software compiles, software testing or software release. It instead calls on other DevOps tools to do the work in the correct order. Often these DevOps deployment tools are mistaken as application release tools, because they can call on external tools and scripts to do the work. Tools in this category include:
GitHub – With the announcement that GitHub includes ‘Actions’ we can add GitHub to this list. A GitHub action can be called in a particular order to define the life cycle process. And yes, a GitHub Action can call a deployment script or process, but does not do the deployments itself.
Don’t be confused by the term ‘deployments’ when researching DevOps deployment tools. ‘Deployment’ means different things depending on the context. If you need to manage application level code updates, don’t assume you can use a tool intended for infrastructure updates. Continuous Delivery can call a deployment process but does not do the work itself. Always ask the next question which is ‘what exactly was the solution designed for?’ If it was designed to do one thing, it does not mean it can do another, even though the solutions sound very similar. Chances are they are not anything alike. Yes, you can occasionally use a kitchen knife as a screw driver, but you might think twice about assembling that new bookshelf using just a kitchen knife. It may take way longer than you want.