Have you tried to look at the beginners' roadmap to learning DevOps? If you haven't, don't worry; here's an image below:
Figure 1. DevOps roadmap by Vrashabh Sontakke
The image above shows 30+ tools a beginner must learn to become a DevOps engineer. Well, that's a lot.
Youtube tutorials, articles, and various blogs don't make this any easier, as they keep dishing out some much information without considering the users. Most times, these tutors need to gain experience in what it's like, to use these tools daily, hence why they can bombard individuals with so much at a time.
In this article, I will break down this problem and highlight a system I found effective when learning DevOps. This approach will give beginners and DevOps engineers, in general, an excellent method for applying and choosing various tools for a particular project.
What is DevOps?
DevOps is an approach that helps software development and IT operations teams work better together. Before now, these teams worked independently of each other and would often face challenges in coordinating their efforts. DevOps brings them together to improve how they collaborate and communicate.
Although this is true, this isn't all there is to DevOps. It is a set of practices that aids the building/development of software. To achieve this, there must be a shift in mindset and a set of tools to automate various processes/tasks. To achieve this automation, a good understanding of certain tools is crucial. However, there are so many tools to learn.
With a simple Google search, you could see a ton of DevOps tools and need help figuring out where to start. Hence, it is crucial to have a system to pick up tools to learn or use for any project.
Measures to consider while choosing tools
There are specific measures to look out for before choosing any tool for a job. These measures serve as requirements to be met by a tool. The following are measures to consider before adopting a tool:
Cloud agnostic tools
These are tools that function independently of any platform. These tools work and adapt easily to multiple public and private cloud providers. These tools are compatible with any cloud infrastructure without facing any operational issues. That means when using a cloud provider such as AWS; it is advisable to use tools that integrate with other cloud providers such as GCP, Azure, etc. Examples of cloud-agnostic tools include Kubernetes, Terraform, Vault, etc.
Ease of use
Learning how to use new tools can be difficult, and this difficulty can only get worse when you have to acquire further information while learning this tool. For example, learning a CI/CD tool such as Jenkins requires learning Groovy, which has a Java syntax. I found this difficult, as I needed to gain more knowledge of Java to learn this tool effectively. Learning CI/CD and Groovy simultaneously wasn't fun, and I had to abandon it after a while.
For this problem, I had to carry out research and found out that Gitlab CI uses YAML. YAML is an easy-to-read data serialization language. In DevOps, you encounter YAML in multiple areas, whether in Docker when using docker-compose or Kubernetes while writing Kubernetes manifests files, so it was easy to adopt Gitlab CI because I already had a prerequisite knowledge.
The Hashicorp corporation has made a huge impact in providing valuable tools and platforms in the cloud ecosystem. The advantage of using the tools they provide, such as Terraform, Vault, and Packer, is that they all have the same language, Hashicorp Configuration Language (HCL). This means you can easily pick up any of these tools by learning HCL, which is similar to JSON. This approach can be useful when choosing tools to learn or use for a project.
Immutable infrastructure
In making well-informed decisions, such as whether configuration management tools are needed, you need to know the type of infrastructure you manage or run.
A mutable infrastructure is one where you can change or modify the infrastructure at any time. An immutable infrastructure, however, is one in which changes cannot be made while it is live, but rather, the existing infrastructure is destroyed and replaced with a new one.
With a mutable infrastructure, you can use configuration management tools such as Ansible, Chef, Puppet, etc for modification. However, since changes aren't made to immutable infrastructures, you can't use these tools. This is where a tool like Packer comes in handy.
Packer can help you bake a preconfigured machine AMI where your infrastructure gets installed and configured at boot time. You won't need configuration management.
Running an immutable infrastructure comes with advantages such as reduced infrastructure complexity which results when the application grows larger. Therefore, if you're running this type of infrastructure, you won't need any configuration management tools.
Environment-native services
A good understanding of cloud providers is an important skill in this profession. They offer an array of services that enable you to build, deploy and manage applications quickly and effectively. Cloud Providers have advanced over the years, offering basic if not all, the tools needed by a DevOps engineer.
Although it is good practice to use services independent of any cloud platform, it is advisable to start your infrastructure in the cloud. As the application grows and a need to add another cloud platform comes in, you can switch to a cloud-agnostic tool. Why use many other tools when you can use these services offered on one platform? This solution isn't limited to cloud providers alone, as it can be extended to CI/CD tools.
When collaborating in teams, version control systems are used to keep track of the versions of the application. Platforms such as Github and Gitlab stand out in this ecosystem, and they come with numerous features asides from version control and source control management. They come with their own CI/CD platforms.
Using the CI platform with GitHub and GitLab, which is GitHub Actions and Gitlab CI, is not just cool but a smart choice for DevOps engineers. It aids in seamless integration and familiarity and is easy to use. While most engineers would use Github to store their code, then use Jenkins to checkout the repository, why not use the tool that comes with Github instead? Adopting the services within a particular environment, be it a cloud provider, or a repository manager, reduces the complexity of your infrastructure.
With these checks, you can make sure you choose the most appropriate tool for the job.
Tool to learn
Using these checks before picking a tool is crucial in making the right decision; however, what tool do you learn? Don't get me wrong, you still have to learn a handful of tools, but don't worry, now that you have a good system, you'd know how to use a hammer instead of a drill for a nail job. Below is a list containing various DevOps tools and their respective areas of use:
Infrastructure management: To automate the process of setting up and managing cloud infrastructure, a tool like Terraform is king!
Containers and Container Orchestration: Packaging applications and their respective dependencies have never been easier using Docker while orchestrating container infrastructure with an effective tool such as Kubernetes.
Monitoring and Logging: Monitoring statistics and obtaining logs from applications can be done using tools such as Prometheus and Grafana.
Security: All forms of data can be lost without security in applications. Using a tool such as Vault from Hashicorp can be helpful.
CI/CD: As discussed earlier, GitLab CI and Github Actions can save time to learn as they are familiar and easy to use.
Server templating: Using Packer has never been easier to create reusable server configurations in a platform-independent and documented manner.
Note: Cloud providers provide the equivalent of each of these tools, and it is essential that you know at least one cloud provider and the respective equivalent of these tools to use the right tool at the right time.
Conclusion
This article highlighted the problem of having too many tools and needing a proper manner of adopting the right tool for a project. This is not a paid post or a promotion to any company. However, it is based on the personal opinion of an individual who found it difficult to start my DevOps journey and was crippled by the fact that I had too much to learn.
Don't let the conversation end. This article was drafted from a conversation between Aahil and Francis from the DevOps Learning Space (DLS). Don't be left out. What do you think? Do you agree with my opinion? I'd love to hear all about it.