By Chris Tozzi
If you google “DevOps tools,” you’ll see a dizzying litany of software applications, all promising to simplify your life as a DevOps engineer. This can be an intimidating experience — not only because there are so many DevOps solutions available that it can be difficult to know which ones are the best for your needs, but also because of the idea of having to learn and “carry around” so many tools is itself unnerving.
After all, if you or your DevOps team spend your day continuously delivering software, you probably don’t want to have to keep track of dozens of different tools to do it. Nor do you want to have to shift between different tools every time the status of your code changes as it travels down the delivery pipeline.
That’s why it can be worthwhile to take some time to simplify choosing your DevOps tools.
Why simplify your DevOps tools?
To be clear, simplifying your DevOps flow does not mean abandoning third-party tools altogether. Nor does it mean attempting to do everything with just one tool. You can’t continuously write, test, build, deploy and manage applications without the help of at least a few tools.
But there is such a thing as too many tools that can complicate the DevOps process. If you have more software than you really need, it’ll become a distraction (not to mention a waste of resources on your infrastructure). That is why one of the main challenges to the DevOps model is choosing the right set of tools.
If you were a carpenter, you wouldn’t carry around a dump truck’s worth of tools. If you did, you’d spend so much time searching for and switching between different tools that you’d neglect your core job duty. You’d instead want to stick to the essential set of tools that you can fit in a toolbox or two in order to keep things simple. Doing the same with your DevOps toolset is crucial for the same reason.
Here’s how to choose your DevOps tools using simple strategies
So how can you simplify your DevOps toolset? Let’s take a look at some of the following best practices.
Focus on broad categories, not specific needs
There are two ways to approach the process of selecting a DevOps tool. One is to identify a specific problem, such as the need to monitor a server, and find a tool that lets you do that.
The other is to think more broadly and categorically. Instead of focusing on finding a tool that lets you monitor a server, you might search for a tool that helps you monitor and manage all types of infrastructure.
Taking the latter approach will likely lead to a simpler DevOps toolset because it will reduce the total number of tools you use. In most cases, a tool that can monitor your server can also monitor the containers running on that server, and probably also help you to manage the overall performance of the application that those containers host. In this scenario, you could select a single APM tool that meets all of your needs, keeping things simple.
Avoid redundancy
Obviously, you don’t want multiple tools that do the same thing. You very likely already realize this.
However, the tricky thing about tool redundancy is that it can be easy to adopt redundant tools by accident. You might choose one tool for building software and a different one for deploying code after it is built, even though both tools support builds and deployment. In this case, it would be better to choose one tool and use it for both tasks.
You can avoid adopting redundant tools in the first place by thinking categorically about your tool needs, as described above. You can also periodically review the features of the tools you use to check whether you have overlapping features and could use a single tool to do more things.
Embrace well-integrated tools
If your DevOps tool makes it hard to work with other tools, it will probably lead to issues and complexity. On the other hand, if your tool integrates with lots of other tools and platforms, it will help you keep things simple.
That’s because continuous integrations help to ensure that you can easily move data from one tool to another, or move your tool from one platform to another. You don’t want an APM tool that works only with one type of public cloud, for example, because you’d then have to adopt a separate tool if you decided to move to a different cloud, thereby bloating your toolset. You also don’t want to have to write custom configurations or integrations in order to share log data from one platform with a tool that was not designed to support that platform.
The number of integrations offered by DevOps tools varies widely. When selecting a tool, consider how its integrability will influence the simplicity of your overall toolset.
For example, we chose Github for our source code management and we were able to utilize its Webhooks to ship various types of Github events – commits, pull request creation, merges, etc. into Sematext. This then allowed us to view various reports about our team’s productivity. Here’s an example dashboard showing the team’s activity over a period of time and across various repositories:
You can learn more about this Github integration to see how to set this up for your team.
Choose simple licenses and pricing models
One way in which DevOps tools can become complex and complicated is in the realm of licensing. Complex licensing requirements can make it difficult to move a tool from one server to another or to scale up your usage of the tool without first modifying licensing terms, which can entail a very long and complex bureaucratic process that you probably want to avoid.
For this reason, preferring solutions with simple licensing schemes is one way to keep your toolset simple. Choosing open source is an option (although keep in mind that many DevOps tools that have an open-source core require commercial licenses for large-scale use). Another is to stick with simple licensing terms — For example, choose a tool with pricing and licensing based simply on the number of servers you use, rather than a more complex (and harder-to-predict) set of factors, like how many user accounts are on each machine, or which times of day the tool is running.
If you’re interested in building or optimizing your DevOps toolset, check out our list of the best DevOps tools available on the market right now. Additionally, read our breakdown of the best practices for adopting the DevOps model, for a seamless and effective implementation.
Use case
Joe has just signed on to an Application Performance Monitoring platform and started to monitor the performance of his Solr App. Turns out the platform he signed up for does not have Log Management or Infrastructure Monitoring, forcing Joe to now search a separate solution for metrics and logs. The context switching that Joe will have to do when switching from one platform to the other will only cost his organization more of his time.
What’s the conclusion? Choose DevOps Tools that come with many products, you may not need them now, but at least you have them as an option in the event you need them. For example, Sematext offers Application Performance Monitoring, Log Management, Real User Monitoring, Infrastructure Monitoring, and Transaction Tracing making it a comprehensive solution for full-stack observability in the cloud or on-premise.
Conclusion
When it comes to DevOps tools, you have lots and lots (and lots) of options. In order to avoid a toolset that is too large to wield effectively or that creates more distractions than it is worth for reaping the benefits of DevOps, keep things simple by focusing on covering a broad range of needs, avoiding redundant features, choosing tools that are well integrated with third-party platforms, and avoiding complex licensing models.
Bio
Chris Tozzi
Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.