I have been asked repeatedly what the first DevOps tool I would suggest setting up is. The problem with the question isn't that I don't have an answer. The answer is annoying because it is that "it depends" on what your worst problem is. So over the next couple of weeks we are going to talk about which tool or tools I recommend for where. I also will explain what I look for in a tool. Because you need to know how to figure out what "it depends" means for you.
You can break the sets of tools down any way you wish. I am going to do it this way because it works for me. They are Configuration Management, Monitoring, Repository Management and Automated Deployment. The order I have them listed in is also a great way to deploy them. But as you will see that "it depends" part of this problem will likely change it. There is also a fair amount of cross functionality to the tools. For instance, Configuration Management tools can generally do some basic monitoring.
Let's explain what they are first. Configuration Management is the class of DevOps tools that make things consistent. This generally means servers and applications. They can almost always be extended to manage a large number workstations for something like a Windows XP to Windows 7 migration. They almost always start from a base OS and build out the prescribed applications and configurations. The configurations can be anything as simple as a list of users to as complex as a complete N-Tier Application.
Monitoring tools are the class of DevOps tools that monitor for issues. The can be very simple only allowing you to ping servers and check whether ports are responding. Most are more complicated. They almost all will check system statistics like free disk space, CPU Usage, etc. The most complex ones will allow you to provide functional test scripts to validate that full functionality is working.
Both of these first two sets of DevOps tools come in one of three forms Agent Based, Agentless, and Hybrid. Almost all are moving towards the hybrid approach. Agent Based tools are faster responding because there is no need to poll the server. They tend to scale easier. The problem with them is that you have to watch to make sure the processes are running. Agentless are slower responding but you don't have to worry about the agent being down. They don't tend to be as easy to scale because the main server has to spend more time with each machine. Hybrid solutions tend to give you the best of both worlds. You get the speed of an agent with the ability to remotely restart the agent remotely and decent scaling. Scaling both of these DevOps tool classes tends to be a challenge. That challenge however doesn't come into play generally until you start reaching the thousands or tens of thousands of servers. So unless you work for a large company this generally isn't part of the "it depends" equations for most people.
Repository Management and Automated Deployment solutions are generally driven by the tools set used to build your applications. For instance, if your a Windows Shop you are probably using Team Foundation Server for Code Repositories. But if you are a Linux or Web Shop you are probably using Git/Github/GitLab. The choices made in both of these DevOps tool sets make them extremely dependent on each other. You may also notice that I didn't say Continuous Deployment. That is because while most Automated Deployment Tools will help you reach Continuous Deployment none of them require it. Pushing buttons to deploy anything is not always a bad thing.
I most often recommend deploying a Configuration Management tool. That is probably because I am biased towards the operations side of DevOps. My other reason is that until you can stabilize things deploying the other tools is far more difficult. If you are spending 18 hours a week doing something that should be done in 18 minutes,like adding users to systems, implementing it give you a little more than two days back to your week. That's plenty of time to deploy the other tools then.