Even though DevOps is a cultural shift, not a job title, there are still tools that can help break down silos and tools that are associated with the movement. This means that if you’re applying for a “DevOps job,” you’ll likely be working with certain tools. This is why I use the word in the title of my book This is also where beginners tend to be drawn to DevOps, at the tooling level. Really, this isn’t so bad. “How can I use the tools that organizations who move quickly do?,” is a pretty good question as long as one isn’t blind to the idea, that mental models and culture can play a huge role as well. So with that in mind, what tools should you learn if you want to be “DevOps”? There are no exact tools, it depends on your organization, its wants, needs, and goals. That’s DevOps for you. But there do tend to be some categories that these tools fall into. And like programming languages, once you know one, it’s a lot easier to learn another since many of the concepts you already know will map.

Categories are:

• Configuration Management
• Source Control
• Communication
• CI/CD
• Monitoring

For configuration management there are a few options:

• Chef
• Puppet
• Salt
• Ansible

Do you need to learn all of these? Probably not, and certainly not all at once. It’s better to learn how these tools work in general, what paradigms do they follow, etc… and then pick one and learn more about it.

For example, Salt follows a Master/Minion (client/server). Chef follows a similar model. But Ansible doesn’t have a centralized server.

For source control, though others are around, I’m just going to say learn git unless your organization has another requirement for you. If you or your team want a place to learn and try it out, you can use Try Git

For CI/CD, its important to think about what you’re trying to accomplish, but many tools can be used to accomplish similar goals. Don’t let your team get bogged down in the weeds, its more important to get a basic pipeline up and running and improve from there. Options include:

• Jenkins
• Drone
• Travis
• Gitlab

You’ll notice I also listed communication. This might not seem like a DevOps or SRE thing at first, but really communication is what helps you break down silos. It also can help you resolve an incident faster. This could include tools like chatbots, or even your system for contacting relevant people like PagerDuty.

For monitoring Just as with some of the above tools, it’s more important to consider what you want to monitor and to what extent than it is to worry about a specific tool at this point. If you’re going to monitor some metric, you should be able to answer some questions about it. First, what does this data tell me? If it doesn’t tell a story of some sort, its highly likely it shouldn’t be monitored or you need to investigate what the data means to your organization. Secondly, to determine if you should be alerting around that metric, “What do I want someone (possibly me) to do in response to this metric?” also “when?” and “how quickly?”

If you there is no action to be taken around a metric, it’s not a good candidate for alerting.

What do you think? Leave a comment. To see more like this click here: https://thaiwood.io/DevTo