Over the past few years, we’ve seen an almost obsession with developing and adopting CI/CD tools throughout the DevOps community. There are thousands of “how-to’s”, “top x tools”, and “tool x vs tool y” type articles, and it has gotten to the point where it’s quite difficult to figure out how and which one to pick as your own. So naturally, I figured I’d add one more to the mix, with the mention that this should contain a tad more information on the subject.
We reached out to a few awesome companies and poked our noses in their DevOps toolchain hoping to find a balance between build vs. buy new tools. We asked them also how they manage to build a successful DevOps team, what are the main roles you should have to get started, and how you can make sure they work seamlessly together. If you missed my other article about DevOps team structure and roles you can check it here.
Let’s dive into the DevOps toolchain topic.
What Is a DevOps Toolchain?
A DevOps toolchain is a collection of all the tools your team is using to aid in the delivery, development, and management of software applications throughout the systems development life cycle, as coordinated by an organization that uses DevOps practices.
Why Do You Need One: Toolchain Use Cases
Looking back at how we used to develop software we can clearly see how we’ve increased the speed at which we develop our applications. The zero to production speed of new features or even fully-fledged applications went up dramatically with the introduction of DevOps as a critical component of software development.
Naturally, with the increased popularity of DevOps, the need for specialized tooling rose through the roof. This sparked the DevOps Toolchain gold rush and for a few very good reasons. DevOps toolchains got popular because they replaced a lot of manual work that the developers had to do with automation. The results speak for themselves.
Faster Deployments
In every DevOps toolchain, you’ll find some type of continuous integration and continuous integration tool that will speed up deployments by eliminating any bottlenecks with the use of automation. This results in an unprecedented velocity when it comes to deployments so instead of having weekly deployments now they can have them on a daily basis or in some cases every few hours.
Fine-tuned Incident Management
When it comes to incidents it’s not a matter of if they will happen but rather a question of when it will happen. In the Age of DevOps, there are new ways to respond to incidents and with proper tooling, you’ll be able to quickly understand what went wrong and who is the right person to work on the issue.
A mature DevOps team understands that incidents happen and it’s only a matter of time so they take extra precautions to increase their readiness and decrease their response time. They set up monitoring tools, alert systems, and runbooks that help each member know who to contact when an incident is detected and what to do next.
Quality Assurance
QA has always played an important role in traditional engineering teams but DevOps stepped it up a notch making QA an integral role in every modern DevOps team. Both QA and developers play a strategic role but nowadays their responsibilities have merged a little bit as QA is built-in together with development and operations that enable them to collaborate to build a flawless application or software. QA plays a strategic role in ensuring that quality is taken up as a responsibility by both Development and Operations.
How to Create a Healthy DevOps Toolchain: Build vs. Buy
Thanks to a rapid adoption rate throughout the world, the DevOps movement started to develop an entire ecosystem around it with thought leaders, conferences, classes dedicated to DevOps, and of course a large array of tools.
It became a living breathing entity. A self-evolving cultural model that betters itself over time thanks to a community of dedicated people that work tirelessly to meet the current challenges.
Naturally, there’s a wide selection of tools out there to pick and choose but, you see, DevOps tools are not your run of the mill tools that you can pick up and add or remove from your proverbial toolbelt at any time. At Sematext we develop awesome monitoring and troubleshooting tools and we know all too well that picking a tool that your entire team will use requires a lot of research.
There’s a cost to take into account, but that might not be all that important to most. What’s really important is whether or not it will work for your particular needs and the ease with which the team cand adopt the new tool, does it have good enough documentation? How’s their support team? Is their infrastructure balanced enough to support your needs?
That doesn’t even cover if developing your own tool might make sense or not. On paper, a custom tool would work great but when it comes down to it, developing and maintaining it requires a dedicated team focus only on that particular project. This can have a hefty tool financially, and more often than not, the result is going to be inflexible enough that whenever a new variable is introduced there’s going to be a lot of reworking and rethinking to remove compatibility issues.
So how do you choose the right option for you? What do you look for and how do you vet your choices? To answer these questions we’ve reached out to some of the best DevOps people we know. Here’s what we found out.
Out-of-the-Box DevOps Tools
We are beginning to realize how complex many of the tools we use on a daily basis have become. Sometimes this is inevitable because we are working with complex distributed systems that need to heal themselves and reliably deliver all communications. Sometimes we instead look at a complex tool and realize it made a small problem into a large headache: we accidentally add layers of abstraction that make it seem like the problem has been solved when it has just been renamed and pushed to a new imaginary layer none of us really understand. I’m not going to pretend for a second I understand Kubernetes in great depth, but I can see that it’s not appropriate for every project and in some cases, teams are adding needless complexity into their projects just because everyone else is doing it and many of us have some incredibly strong feelings about product preferences and whether the source code should contain spaces or tabs. I think we’ve all been guilty of missing the greater picture sometime during our career.
When we take a step back, we can sometimes start to see where these systems are overkill. The hundreds of hours of configuration management code in an annoying DSL could have been done in a fraction of the time with shell scripts. We realize that writing infrastructure as code providers is bizarrely complex, and try to find a better solution that takes less time. It seems like all DevOps applications are in the middle of a great convergence aiming to represent every fact about the system as YAML; even the DSLs some services produce feel more like writing YAML instead of capturing the idiomatic experience of the language and providing a more pleasurable development experience.
The reality of the situation is quite different, unfortunately. We have schedules to keep, and often it is still cheaper to procure a mediocre-to-average toolset instead of writing something better.
If your company does not give you time to work on personal projects or participate in the OSS community, you’ll have little time to build your system. Sometimes teams do not even have a choice in the tooling they are provided within the first place. Unless a really novel approach has management approval or you happen to be a DevOps startup, you will likely be buying anything you need. I hope we see more innovation in the OSS community and that companies take notice and in return, become more willing to take risks themselves on in-house software.
While both options are valid in their own way it really comes down to the requirements themselves. Understanding what you and your client needs should be your first step in deciding if you want to buy or build your DevOps tools.
Andrei Pirjol, a DevOps engineer from London told us that tools built in-house don’t tend to last very much and get increasingly heavy in new features, old code that is passed over to multiple stages of code changes. From his experience, buying DevOps tools is more of a budget-related issue rather than anything else.
Custom DevOps Tools
If a specific tool or functionality already exists, it is faster to improve the process. On the other hand, it might not work 100% of the time, and in such cases, you’ll have to customize them to fit your need(if that’s even possible). For small companies, writing their own tools might be time-consuming, besides the dedication of people that could be focused on bringing value to the product.
However, it also must be considered that you don’t need a cannon to kill an ant. So, if creating a deployment script works well for your need, you can go for it instead of starting a whole deployment pipeline from scratch. Just have a plan, consider points such as growth and improvement, not only the current state of your development pipeline but how you plan to evolve it.
Must-Have Tools
Your basic DevOps toolchain will have about 7 components. Of course, this might be a little different for in some cases depending on each team’s particularities, project requirements, team size, etc. While I could spend the next couple of days talking about each tool that you can use for every component listed here, I’ll talk about the most popular ones in each category and I’m going to leave you to look up alternatives for the tools you are interested in.
1. Issue tracking – Jira
Jira is one of the most popular issue tracking and project management tools out there. It was first released in 2002, making it one of the oldest issue tracking systems in the world, and it’s currently used by over 75,000 customers around the globe
2. Communication and planning – Slack or Mattermost
Just like with issue tracking software there could have been a very long list of candidates for communication tools but I’m going to stick with Slack and the less popular Mattermost. Both Mattermost and Slack offer agility and efficiency through modern collaboration. Mattermost features a secure self-hosted solution while Slack, the more popular alternative amongst developers offers a simple to use communication platform that works out of the box.
3. Infrastructure automation – Terraform, Ansible, Puppet, Chef
I’ve tried limiting myself to only a couple of options, I really did, but when it comes to infrastructure automation there are so many flavors and caveats to consider that it’s almost impossible to talk about one and not the other. I’ve picked 4 options for this category but to be perfectly honest this list should have gone on for a while. Terraform is an infrastructure provisioning tool that is cloud-agnostic and written in GO. Ansible is an agentless orchestration tool that uses configuration modules written in YAML format called Playbooks. Puppet is a ruby based configuration management tool that’s similar to Chef the latter uses cookbooks to configure virtual machines.
4. Continuous Integration – Bamboo, Jenkins, and TeamCity
Every software team out there builds code in chunks and cycles by multiple people and sometimes multiple teams. The tricky part is getting all the code integrated without creating issues. Continuous integration tools let you detect errors quickly and resolve them faster. A few examples of continuous integration tools are Bamboo, Jenkins, and TeamCity.
5. Source Code Management – Github, Bitbucket, Gitlab
All the code you are developing needs to be stored somewhere that’s easily accessible by anyone in the organization, can be updated, deleted, and rolled back anytime that’s needed. Source control tools give you these features to exploit. A few examples of source control tools are Github, Bitbucket, Gitlab.
6. Monitoring – Sematext
Monitoring tools are an absolute must in every DevOps scenario, either you build your own tools, buy existing ones, or go with any of the existing open-source tools. They ensure service uptime, optimal performance, and help with troubleshooting issues and bugs. Open-source ones may not have full-blown features like Sematext Cloud or Datadog, but keep in mind they’re open-source products and can hold their own just fine. However, buying a tool such as Sematext Cloud will help you detect and troubleshoot production & performance issues with logs, metrics, synthetic and real user monitoring all together in one place.
See how Sematext compares to other solutions in our post about the best cloud monitoring tools available today.
7. Quality Assurance – Selenium
QA tools are a dime a dozen, built for specific tasks and frameworks so I’m not going to dwell on every scenario but rather only mention Selenium – the most popular automated testing tool out there. It is specifically designed to support automation testing of a wide range of browsers.
Every team will have a different set of tools they prefer or use and some may have more or fewer components in their DevOps toolchain, but the list above contains the most common pieces of software used by developers.
Takeaways
I usually try to end my articles with a conclusion, a simple idea to take back home with you but when it comes to such a colossal subject like DevOps tools, I’m afraid I’m not going to have one.
Apparently there’s no one universal answer that would work for everybody. So how do you actually go about getting the right tool? Najib Radzuan, a DevOps lead from Malaysia has a clever checklist that will help you figure out if you do need to buy or build the tools your team will use.
Before the team chooses any tools for their DevOps team, the following criteria need to be in place 1st:
- Define all issues/problems and goals.
- Define all your problems and issues your team has and what you want to achieve in the future.
- List of existing resources/tools which can solve all issues you listed.
- List all the existing resources and tools you have and come out with a possible solution toward each issue.
- Know your team capability and budget.
- Not each possible tool or solution that you listed you able to apply or implement in your organization. Your budget allocation also plays a big factor to choose your toolchain.
When your existing resources are able to solve or archive your DevOps goals, then you can build your tool and solve all the issues and problems you have. This also includes your team’s capacity to maintain and support when something wrong with the built tools. If this applies to you then most likely you should be building your own DevOps tools rather than buying them.
But when your current resources and tools do not meet the goals you set and cannot solve your current problems, then you need to buy the solution(tool) or seek an external DevOps consultant to help your organization.
Hopefully, this article has shed some light on what you might want to look for if you find yourself in the position of picking the next tool for your team.
This article has been published from the source link without modifications to the text. Only the headline has been changed.
