“DevOps” is a recently coined term that combines the realm of “development” with that of “operations.” So in theory, a DevOps engineer is someone who is proficient in both of these areas and understands how they interact with each other.
In reality, however, most DevOps engineers work on the “operations” side of things on a day-to-day basis. They understand enough about how software is written and how it works to smoothly integrate a given piece of software into a larger operational workload, and most DevOps engineers do work on system administration tasks. But there is a difference between a modern DevOps engineer and a sysadmin insofar as the DevOps engineer focuses on automation and cloud architectures.
Automation is achieved through a number of means, including continuous integration (CI), continuous deployment (CD), configuration management, and infrastructure-as-code (IaC), to name just a few. This article will explore some of the primary tools that DevOps engineers actually use today.
For better or worse, the most widely used CI/CD tool today is Jenkins. Jenkins was first released in 2011 and is arguably the first CI/CD tool that gained widespread adoption. It was (and still is) very popular but is aging and quite cumbersome to operate. Additionally, perhaps because it is a Java application, it requires a lot of resources while it is seemingly limited to only coordinating builds. Still, Jenkins is open-source, and you can run it on your own servers, which can be important if you want to maintain tight security on your operations.
There are numerous modern alternatives to Jenkins, such as GitLab CI, CircleCI, Travis CI, etc. These are typically much more lightweight than Jenkins and usually expect a file or set of files to be present in the git repository itself to provide instructions on how you should build and potentially deploy the software.
Consequently, most of these tools make assumptions on the structure of your code, including the assumption that one git repository will build and deploy one service. This will probably work well for many projects, especially simple ones. However, it can also be limiting if your code is more complex or you are using a monorepo, as in such a case, you don’t necessarily have just one git repo, one software, and one deployment.
So, if your software is quite complex and requires more intelligence for the CI/CD process itself, you might want to use another, a more flexible solution such as AWS CodePipeline, where CI/CD pipelines exist independently of the repo(s) they’re using. This will allow you to have far more complex builds and deployments, for example, by using multiple git repositories and a monorepo, or by deploying to many environments. Feel free to check out this post on best practices for CI/CD in Serverless environments.
Containerization (and especially Docker) has truly revolutionized the way software is built, delivered, and deployed. Docker is now ubiquitous and is a must-have skill for every DevOps engineer.
At its core, Docker leverages the ability of the Linux kernel to isolate some processes from the rest of the system. The isolated processes can’t see anything outside their bubble. Docker builds the concept of a “container” using these Linux features, which are essentially akin to lightweight virtual machines.
Now, thanks to this technology, it’s very easy to run one or more such containers on a given computer, and each container will act as a mini VM. Spinning up and shutting down containers is very fast, and it is now possible to run clusters of containers on cheap host machines.
You should be aware that there are alternatives to Docker, such as containerd, but in practice, everybody, except for a few fringe projects, uses Docker.
Docker is absolutely great and a game-changer, but you will want to do more than spin up and down a few containers here and there. Where Docker shines is when used in conjunction with a container orchestration tool in order to manage large to very large deployments. Such an orchestration tool will typically spin containers up and down automatically, for example, based on the current workload (i.e., scale out and in). It can also restart dead containers and distribute the load amongst your host computers to increase availability.
The most well-known container orchestration tool today is Kubernetes, developed at Google but now housed at the Cloud Native Computing Foundation. Kubernetes has a high adoption rate with technology aficionados and is by far the main independent offering when it comes to container orchestration. However, it has a notably high learning curve with arcane configuration files; setting up a vanilla Kubernetes cluster is a difficult and time-consuming endeavor.
Some DevOps engineers who specialize in one of the available public cloud vendors might focus on the corresponding vendor-specific orchestration tool, which essentially means ECS for AWS and Azure Container Instances for Azure (Google obviously uses Kubernetes). Apart from vendor-specific solutions, there are some other options out there, notably Mesos and Docker Swarm.
IaC is one area where there is a dearth of tools. The most well-known IaC tool today is Terraform. It is independent of any cloud vendor and actually supports a wide variety of cloud platforms. It also offers Terraform Registry, which is a community-led repository of Terraform modules, which can reduce the amount of time required to set up a workload. Terraform does, however, have certain limitations.
The second most well-known IaC tool is CloudFormation. It is AWS’s IaC offering, so, predictably, it works only for AWS. If your workload is on AWS, CloudFormation offers some benefits over Terraform, such as automated rollbacks and advanced permission management. Still, it tends to be slow and lacks Terraform’s syntactic sugar, such as loops and advanced functions.
There are numerous offerings in the field of monitoring, and it’s quite difficult to pick one winner. Today, one of the most-used software is Prometheus, which is the standard monitoring solution for Kubernetes clusters and features a very efficient time-series database engine as well as an alerting system. Prometheus is usually used in conjunction with Grafana, a visualization solution with which it integrates very easily.
There is also Jaeger, open-source software that’s pioneering the global effort in tracing. Importantly, Jaeger is a “graduated” project at the Cloud Native Computing Foundation, vouching for its maturity in such a recent field.
We must also mention Epsagon, which goes a step further and is a leader in observability and distributed tracing. Epsagon helps immensely when it comes to understanding complex microservices-based environments and why workloads are behaving a given way, and when you need to find bottlenecks and bugs.
Bonus DevOps Tools!
As a little bonus, let’s have a look at a DevOps tool that receives little attention but which is very useful and the only tool available in its field: Packer. If you still haven’t made the switch to Docker, you will find Packer very useful, as it is one of the very few tools that allow you to build VM images (e.g., AMIs, VirtualBox images, etc.). Using a combination of configuration files and scripts, Packer is typically used to build Amazon Machine Images, which are the images used to spin up EC2 instances.
Another good tool in this area is Vagrant, which spins up and manages virtual machines. Vagrant does need a VM engine, so it is usually combined with VirtualBox. If you are not using Docker, Vagrant is very useful for running VMs on your computer, which helps developers replicate a production environment on their computer without the need for additional hardware.
There is obviously a wide range of DevOps tools, matching the breadth of disciplines a DevOps engineer needs to master. New tools and software are created on a regular basis, and old software often gets a facelift or has new features added.
New technologies are also being developed continuously. For example, these days, service meshes are a very popular topic. Instead of a traditional cluster fronted by a load balancer, these meshes link microservices via direct links using side proxies. Such a new way of architecting distributed software requires brand new software elements, such as Envoy and Istio.
This is one of the main challenges for DevOps engineers: The number of technologies and tools they have to know and understand, a trend that seems to only accelerate over time.