The Best DevOps Tools for Your Application Lifecycle

Looking to get into the DevOps space? Or maybe you are working in software development and your company is adopting DevOps techniques? Wherever you are in the organization, you will come in contact with DevOps tools in your day-to-day work.

We put together a list of the most popular DevOps tools companies are using throughout the lifecycle of the application. These DevOps tools can be leveraged at all stages of the application lifecycle from writing code to build and test as well as from application deployment to operation, monitoring, and security.

The best DevOps tools for your application lifecycle

1. Application lifecycle: Writing code

Source Control

There is no doubt anymore. Everyone is using Git for version control of their source code. The basic commands like clone, commit, and push are easy to learn, but there’s much more. Can you create a branch? Rebase your branch from master? Resolve conflicts? Squash and merge your branch into master? What if you accidentally made a wrong commit? If you don’t know the answer to these questions, you should get yourself up to speed. Any real Site Reliability Engineer (SRE) or Cloud / DevOps engineer will be able to use these commands without hesitation.

Software Development Platform

Git integrates with a Software Development Platform like GitHub, GitLab, Atlassian, Azure DevOps, or AWS CodeCommit. These platforms allow developers to collaborate on software, open Pull Requests (PRs), and resolve conflicts. You want to understand how to use these platforms. These platforms allow you to collaborate on your projects with your colleagues. Engineers building deployment pipelines will need to know how to integrate source control within the Continuous Delivery platform.

2. Application lifecycle: Build and test

Continuous Delivery

Now that you are aware of the Software Delivery Platform, it’s time to talk about Continuous Delivery. In this stage, you typically use your code within version control to create pipelines to build, test and deploy your software. Software Development Platforms often provide tooling within their platform to build pipelines. If that’s the case and you’re starting from the ground up, then most likely you’ll be using the built-in pipeline functionality. It’ll be fully integrated within the platform, using integrations for source control, testing (build tool integrations), and deployment (for example, Kubernetes).

Besides using your Software Development Platform, a popular open-source tool that has already been around for some time is Jenkins. It is used in almost all organizations. Jenkins can be used as a complete Continuous Delivery platform, taking care of the build, test and deployment phases. It can also be integrated within existing platforms. AWS CodeBuild, for example, can build & test your software itself, but you also have the option to integrate with Jenkins and let Jenkins handle the build, test, and deploy phase.

3. Application lifecycle: Deployment

Continuous Deployment

As part of the Continuous Delivery cycle, you need to be able to Continuously Deploy your applications. Today you typically deploy using containers, so let’s cover this first.

To deploy containers, you’ll need a container orchestration platform. The most popular one is Kubernetes. It is available as a hosted platform on almost all public cloud computing providers. Although Kubernetes can do a lot for you, it is a very complex tool with its own ecosystem of tools. If you are looking for something more simple, then have a look at what cloud vendors are offering. AWS provides Elastic Container Service (ECS). ECS is also a container orchestrator, but much simpler to use. Other useful tools are Docker-compose to build and test your containers locally, and Docker swarm, which is a Docker orchestrator built by Docker itself.

When building your pipelines to build, test and deploy, you will see that a lot of platforms have support for Kubernetes out of the box. Azure DevOps has integrations for their hosted Kubernetes service, Azure Kubernetes Service (AKS), allowing you to easily deploy your code on Kubernetes using Azure DevOps.

Deploying Docker

Containerization has a lot of benefits. You start with writing a Dockerfile which contains the information on how to build your Docker image. This Dockerfile is the only file you need to build your container. You can build and run containers on your own machine, or run it as part of your Continuous Delivery process. Once built, you can run it on any Docker orchestrator, like Kubernetes.

The containers will be isolated on kernel level. As a result, containers start much quicker than a Virtual Machine (VM). Isolation includes network isolation, process isolation, and resource isolation. That way you can run multiple containers on one machine, without having port or resource conflicts.

The adoption of containers in general and Docker in particular has paved the way to easily deploy, redeploy, and scale containers within your infrastructure. Kubernetes will manage the resource utilization, scheduling, scaling, security, and network, while you can concentrate on what goes in the container itself. Thanks to the availability of Kubernetes as a service on the major public cloud providers, you can practically run these containers wherever you want. The only caveat is that you still need to get access to your data, so in reality, the cross-cloud deployment strategy is still not as easy as you might expect.

Deploying without Docker

Not using Docker is still an option. Continuous Delivery already existed before Docker came around. A good approach here is to build a Virtual Machine (VM) image instead of a container image. The same approach as containers still applies, but the artifact is now different: a VM image instead of a container. Packer is an open-source tool you can use to build these images. Packer supports VMware for on-prem deploys, but also cloud providers like AWS. The whole process of building a VM image will take longer, but the end result is the same. You will need to schedule your images somewhere on your infrastructure, and you need orchestration tools for that.

One delivery tool that stands out here is Spinnaker. It’s a tool developed by Netflix to roll out changes to your ever-changing infrastructure. Within Spinnaker you can initiate the build of these images, integrate with Jenkins for build/test, and deploy them on your cloud infrastructure. 

4. Application lifecycle: Operation 

Building infrastructure

Before you can deploy on your (cloud) infrastructure, you still need to set up a lot of resources in the cloud (or on-premises). The most common tool that can help you with that is Terraform. Terraform supports the major cloud providers (Amazon AWS, Microsoft Azure, Google Cloud, and others). It lets you write your Infrastructure as Code, allowing you to abstract your complete infrastructure setup. You can store the code in version control, allowing you to collaborate with teammates, get a history of changes, and use auditing tools.

Typically, the Cloud Providers will also have tooling to build your Infrastructure as Code. AWS will have CloudFormation and Azure has the Azure Resource Manager Templates. Those are great tools, but we find that Terraform has an advantage over them. Terraform is often easier to use, and the code is much easier to understand when someone else than the writer is reading it. It’s also independent of any cloud provider (it’s a free and open-source HashiCorp tool, just like Packer). You would think it would take longer for an independent tool to support all the resources, but the opposite has been true for now. The Terraform AWS plugin community is huge, and new AWS services are supported in no time. Sometimes even earlier than CloudFormation. There’s also great documentation available, and a GitHub project when you need support.

You can run terraform on your own machine, or run it within Jenkins. There is also Terraform Cloud which is a HashiCorp product that runs Terraform for you.

Building immutable infrastructure

When using containers or VM images to deploy your application, you will need to rebuild your image every time there’s an update to the application (a Git commit to version control). Once the image is rebuilt, you’re going to roll out this new image. Essentially, you’re going to shut down your current application infrastructure first. Then you’ll need to replace it with newer VMs or cloud instances until all the running servers contain the new version of the app.

This strategy is called “immutable infrastructure.”. Rather than replacing the application code itself, you’re going to replace the full running instance or server. This is a much better way of rolling out changes, than just trying to do an in-place replacement of your application code itself. You treat your infrastructure as immutable, you’re not going to allow any in-place changes. Every change needs to go through version control, the delivery pipeline, and needs to be deployed in the same way as normal deployment.

If you use this approach, you’ll need less reliance on configuration management tools like Ansible, Chef, Puppet, or SaltStack. In-place updates are not desired anymore. The best way of working is through the delivery pipeline.

When using Container orchestration tooling, this is even more true. Your Docker containers are immutable by default, so every time you’ll roll out an update, you will have built a new Docker image. On a Kubernetes worker level, you also are not going to want in-place changes anymore. You typically are going to use pre-built images from your cloud vendor that will contain a minimal set of software, just enough to run as a Kubernetes worker node. All the custom software is now within the container. Upgrades to the workers will also be immutable, allowing for a complete, immutable infrastructure setup. 

5. Application lifecycle: Monitoring and security

Security Threats

Building all the infrastructure to execute your DevOps strategy shouldn’t be done without security in mind. Cloud Providers have a lot of tools in place to help you secure your data and lower the risk of data breaches. One very powerful and often overlooked measure is simply to use very tight access rules. AWS has Identity & Access Management (IAM) to create users, groups, and roles. These contain access rules, which are called policies. Too often those policies are written too broadly, allowing too much access for a user, group or role. Tightening them up more could significantly improve your security posture. Advanced policies can be written with specific conditions to test where access is originating from, and allowing or denying access to resources based on this information.

Monitoring Tools

Once your infrastructure is set up, you’ll need to monitor it. The monitoring will be 2-fold: Monitoring of applications, and monitoring of the infrastructure itself.

To monitor the infrastructure, you’re going to want to use the tools that your cloud provider provides you. For AWS this will be CloudWatch. If no monitoring is available or you’re not on the cloud, then you’ll definitely want to have a look at Prometheus. This monitoring tool integrates with most cloud-native tooling and is a great tool to use. You will find a lot of different agents that you can use. You can install those agents on your Linux / Windows server instances. Other plugins are available for specific services, like databases. Prometheus supports pulling the metrics, but also has a push gateway for parts of your system that can’t support pull.

Prometheus can also monitor application metrics. Prometheus provides libraries for all the popular programming languages. You can set up metrics within your application to be pulled by Prometheus. Even if your programming language is not supported, the only thing you need is a metrics endpoint over HTTP where Prometheus can pull from. This simple design is the reason why Prometheus is so popular and powerful. You can monitor any application or part of your infrastructure with a simple implementation of an HTTP server with a page that exposes your metrics. 

Whether you use Prometheus for application or infrastructure monitoring, you can also integrate it with Grafana, to create awesome visual dashboards.

Once all the metrics are configured, you’re going to want alerts. Prometheus supports alerts through an alert manager. You can set up rules that are triggered and will notify you when something needs to be looked at. Alerts can be sent to an email, but other integrations like slack (for ChatOps) are also supported.

As you optimize your application lifecycle with new DevOp tools, consider some of the above tools. I also recommend brushing up your and your team’s technical skills through online courses on Udemy to help your team effectively implement these new DevOps tools.