Tools are a crucial element of the DevOps process, but the sheer quantity of tools out there can be pretty overwhelming for new DevOps practitioners.
To get around this challenge, our experts have designed a DevOps tools “Radar”, which helps engineers select the best possible tools for whatever problem they face.
The Radar categorizes tools by four main areas of concern that reflect the lifecycle of an application: continuous integration, infrastructure, release management, and monitoring. Within each of these areas, the tools are then categorized even further, matching them to specific tasks and steps in each process. Cloud and security are two additional considerations that should permeate the whole process, as they usually impact all areas of concern, but for this article, we will focus on the specifics of each classification.
Continuous Integration
Under the continuous integration (CI) umbrella, which is primarily focused on building the product, tools are classified into three sections: source control management, building/testing, and artifact management.
CI is all about getting fast feedback to improve software quality and reduce time-to-market. The process generally starts with checkout and analysis before moving to testing, building, and finally artifact management. Each of these five stages in CI requires specific tools for each part of the process.
For the checkout stage, tools like GitHub and GitLab are best-suited, while analyzing requires something like SonarQube or Sonatype IQ Server. At the test stage, you could use the Radar to choose between something like JUnit or Apache JMeter, then build with Maven or Grunt. Finally, tools like DockerHub or Nexus cover the artifact management stage.
Once the tools are chosen in this process, six high-level tools take care of all five stages through orchestration: GitHub, CircleCI, GitLabCI, Jenkins X, Azure DevOps, and AWS CodeStar. These top-level tools should be chosen based on the technologies, languages, and stack your product is based on, which can sometimes limit your choices.
Infrastructure
The next step to utilizing the Radar is to think about where to deploy the product, which means defining how the infrastructure will look.
Operations first need to choose a service layer by selecting the best “whatever-as-a-service” according to the use case. These might include Azure VM or AWS VPC for IaaS (infrastructure), Heroku or AWS ES for PaaS (platform), Firebase or AWS Cognito for BaaS (backend), and Azure Functions or AWS Lambda for FaaS (function).
Next, they’ll look at containers for runtime and orchestration, which have plenty of options like Docker, Cri-O, Kubernetes, AWS ECS, and more. These should be chosen based on the level of functionality required.
Finally, when considering automation configuration, the Radar helps choose between tools like Puppet, Ansible, and Chef for provisioning, Vault for secrets, and Packer for machine images. On the automation infrastructure side, Terraforma and Pulumi are good options for infrastructure as code, while Consul helps with Networking.
Release Management
With a finished product and fully configured infrastructure, next comes the release management process, which covers deployment strategies, orchestration, and updates.
The first thing to do is to select a deployment strategy, such as rolling, recreate, or blue/green, which are commonly associated with Kubernetes.
As far as orchestration goes, you have Jenkins X for Kubernetes applications, Spinnaker, which works very well with VM deployment based applications, and Octopus Deploy. As with all other parts of the Radar, Amazon, Azure, and Google Cloud also have their own set of tools for these problems.
Monitoring
After release, it’s essential to track metrics, check the application’s health, and continuously collect insights. The Radar helps you choose what to monitor and figure out the most important information to extract from the application.
The Radar includes Google’s four golden signals of metrics (latency, traffic, errors, and saturation), which mean something different for every use case, so choosing what to monitor comes down to the organization’s specific needs.
Once you know what to monitor, there are several monitoring stacks available, including Beats for exporters, Prometheus for a time-series database, and Grafana for UI. The other main choices in these areas are Splunk, AppDynamics, Instana, DataDog, Dynatrace, New Relic, and Elastic Stack.
Choosing the Right Tool, Every Time
When using the Radar, we’ve found that the best approach is to think about how to balance the trade-offs of each tool, which comes down to understanding your problem in depth.
For example, a tool might be capable of solving a complex problem but it might not have enough flexibility to integrate with your ecosystem. On the flip side, a tool may come at a low price point, but you end up spending more on maintenance and support in the long run. Ultimately, no feature or attractive element of a tool will matter if it doesn’t solve your problem.
These trade-offs apply to almost every tool on the DevOps spectrum, so it’s always worth building a PoC before 100% committing to any one set of tools as it will show you exactly how it works in a real-life scenario. Again, our Radar is designed to speed up that process and provide a visual representation of the most suitable combination of tools.
The DevOps Tools Radar makes it easy to highlight the principle tools that would work best for your project by removing some of the complexity associated with choosing tools. By speeding up that process, companies can leverage them in a way that impacts a software development team’s delivery pipeline, process, and culture—at least, that’s how it’s impacted us.
