DevOps Tools Saga! ⚔️

Have you ever wondered what all the famous DevOps tools like Docker, Kubernetes, Jenkins, Terraform, and more are used for? What problems do they actually solve? Well, I was just as confused at first—trying to figure out why individuals and companies use these tools. In this blog post, I will explain all the most commonly used DevOps tools, what problems they solve, and how engineers used to handle things before these tools were built. I'll keep this blog in a story format to make it easy and engaging—so stay tuned and enjoy the read!

The start:

So suppose you have an idea that lets people book tickets to travel to the Moon, and you are planning to build a website to turn this idea into reality. As a good developer, you start coding. After a few weeks, you get the first version of your website, and now it’s time to share it with the world. But how would you do that? The code is still running on your laptop and is only accessible on localhost:8080. If you find some way to share it with the world from your laptop, the website will only be accessible if the laptop is switched on and won’t be accessible if it is turned off. Hmm, so what can we do?🤔

You need to host your application on a system that is never turned off. So you find a server that can be either a physical server in a data center, a virtual server, or even on the cloud. You copy the code from your laptop to the server, but it’s not that easy. To make the code run, you need to first configure the server. For example, if you have written your code in Python or Golang, you will also need to configure the server with those languages. If your code on the laptop contains any libraries or packages, you have to set them up on the server too.

Now that you have developed your application on your laptop, it becomes your development environment, and the server you host your application on becomes your production environment. After setting up all of these, you have your website running on the server. The server also has an IP address and is accessible on that IP address. You don’t have to share the IP address with people, so you purchase a domain name and map the IP address to the domain name, for example: www.travelmoon.com.

You are now set and ready to share your website with the world. You tweet on Twitter/X tagging Elon Musk, and he retweets it. Now your website is buzzing all around and is famous, with thousands of users visiting your website and booking their future travel.

To recollect this workflow, you have developed your website in the development environment and you host it on a server, which is your production environment. The code on your laptop is in a text format and is not suitable to run. To run it as an application for the end user, it needs to be in an executable format, for example, .exe for Windows. Converting code from text format to executable format is known as BUILD.There are tools available for it such as Maven and Gradle for other platforms, and you usually have a build script, for example: ./build.sh, that invokes these tools to build the application. Once built, the executable is moved to the production environment on the server and run in production, and this is referred to as the DEPLOY stage.

Please note there are many variations, ways, and tools to do this process, but this is just an example to keep it simple.

Now you have users visiting your website and requesting more features, so you hire your friends. Everyone is working in their own development environment and on the same codebase. They all copy their code to a central hub, and you need a solution to let developers collaborate with each other. This is where GIT and GITHUB come in.

Git and GitHub:

Git helps all the developers work on the same application and collaborate. Everyone downloads Git on their laptop and starts contributing to the code. Developers can now pull the code from the central hub using the git pull command and can push the code they have written using the git push command. The central hub is a cloud-based platform that acts as a central location for all the code. GitHub is the publicly hosted Git-based central repository of code that provides a user interface. There are also similar platforms like GitLab and BitBucket.

Now the development issues are sorted. However, remember we still need to move the code manually to the production environment every time something new is ready. The previous workflow included developing code in your development environment (laptop), building the code in an executable format, and deploying the code to production (server).

Now, with multiple developers, the code needs to include all the changes made by everyone. For example, if Developer A is working on a payment feature, Developer B is working on a notification feature, and Developer C is working on user details, building on a laptop won't work because they won't have each other's latest code. Therefore, we need to perform the build operation on a dedicated server called a BUILD SERVER. This server can get the latest version of the code before moving it to production.

Directly pushing the code from the BUILD SERVER to the PRODUCTION SERVER is risky as it may contain bugs. Hence, we need to test it in the test environment known as the TEST SERVER.

A developer writes code on their laptop, pushes it to GitHub, and then you manually copy the code to the build server, where it builds the code into an executable. You then manually copy it to the test server to test the code and verify everything works well, and finally, you manually copy it to production. Do you see how hectic it is to do everything manually? 😩 So, you decide to manually copy all the code once a week, but that’s not acceptable to the users or the developers because some minor features are ready and don’t need weeks to be pushed to production. What can be done to automate this manual task and push the features to production whenever they are ready? This is where CI/CD tools come in.
Jenkins:

Tools like Jenkins, GitHub Actions, CircleCI helps you automate these manual task. When you configure one of these tools for instance Jenkins, every time code is pushed, it is automatically pulled from the GitHub repository to the build server and then it is built, then the executable is automatically moved to the test server and performs various test and upon successful testing, it is automatically deployed into production. This allows feature to deployed into production whenever it is ready and with less manual intervention and allow you to ship features faster making users more happier.

Now with Git, GitHub and Jenkins we can build our application and push them to production seamlessly however it is not that seamless.

Do you remember the dependencies, libraries, and packages that we need to configure on the servers we talked about earlier? We still need to manually install and configure them on all the servers where this code runs. If you miss configuring one of these dependencies with the correct version in the right way, the software won't work properly and will lead to unwanted outcomes. This is where containers come in.
Docker:

Docker helps package the application and its dependencies so it can run on any server without worrying about missing dependencies. For example:

Now, during the build, you create a container image with the app and its dependencies packaged into it, and all the servers can run the container from the image without worrying about dependencies. With Docker, the developer can create a Dockerfile that specifies the dependencies, and the Dockerfile can be used during the build to create an image. The image can then be run on any server using a simple docker run command.

In production, we currently have one server, and as users increase, we have to add more servers and run our application on all of them. Since we have containers, all we need to do is run containers on them. Now, how can we do that the right way as containers are spun up when users increase and destroyed when the load reduces? How do you ensure that if a container fails, it is automatically brought back up? This is where a Container Orchestration platform comes in.
Kubernetes/K8s:

Kubernetes helps to declare how a container should be deployed and ensures that it always runs the same way as declared. It can help autoscale containers and the infrastructure based on need and manage resources. Instead of manually starting and stopping your app or worrying about it going down, Kubernetes automates the process.

If something crashes, Kubernetes restarts it for you. If your app is getting more traffic than usual, Kubernetes can automatically add more containers to handle the load, and it scales down when the traffic drops to save resources. Whether you're running your app on your laptop, in the cloud, or across multiple servers, Kubernetes keeps everything consistent and running the same way.

The underlying infrastructure is still a big challenge. Every time a new server is to be provisioned, it needs to be set the exact same way as the rest of the cluster. It needs to have the right resources attached to it, the right resources, and the right version of the operating system. All of these servers should have the exact same configuration. To automate the provisioning of these servers, tools like Terraform can be used.
Terraform:

Terraform automates the provisioning and configuration of servers regardless of the cloud provider and ensures the services configured are in the same state. For example:

Our moon travel website normally needs 2 servers to handle traffic. But during big sales or high traffic days, it needs to scale up to 5 servers to manage the extra load. After the rush is over, we want to scale down back to 2 servers to save money. We have to manually go to our cloud provider (like AWS), create 3 more servers, configure them, and then manually shut them down later. This is time-consuming and prone to mistakes.

We can automate this scaling up and scaling down process by writing a simple configuration file. Terraform will automatically create 3 additional servers to handle the extra traffic. To scale down after the rush, change the server_count back to 2 and run terraform apply. Terraform will shut down the extra 3 servers and keep only 2 running, saving you money. Hence, it is called Infrastructure as Code!

Terraform handles the physical side—creating or removing servers. When Terraform adds more servers to handle the increased traffic, these new servers are just empty machines. They don’t know what to do. These newly added servers need to be configured by installing software, deploying your website code, and making sure everything is running smoothly. How can we do this? 🧐 This is where Ansible comes in.
Ansible:

When Terraform adds new servers, Ansible automatically installs everything those servers need to run our Moon Travel website. This includes installing software and deploying your website code onto the new servers.

Now the workflow looks like this: Suppose it’s a holiday, and more people are visiting your site! Terraform sees the increased traffic and automatically adds 3 more servers. These 3 new servers are empty, so Ansible automatically installs software on them, deploys our website to these servers, and configures them. After the sale is over, Terraform removes 2 servers to save costs. No need to worry—Ansible has already made sure those servers were correctly configured before they were removed.

However, provisioning is not all; we need to maintain it as well. We need to monitor those servers and take preventive measures to see the CPU utilization on the servers, memory consumption, and identify which processes are causing higher consumption. This is where tools like Prometheus and Grafana come in.
Prometheus:

Prometheus helps you keep an eye on your servers, applications, and services by collecting metrics and providing insights into their performance. It tracks various metrics like CPU usage, memory consumption, response times, and error rates in real-time. This helps you understand how our website is performing at any moment. Prometheus stores metrics as time-series data, making it easy to visualize trends over time. You can see how performance changes during peak traffic times, like during a sale.

We also do not just want to collect metrics; we also want to graphically visualize them, and this is where tools like Grafana come in.
Grafana:

Grafana works seamlessly with Prometheus to create visually appealing dashboards that help you understand your application's performance. It allows you to create interactive and customizable dashboards to visualize the metrics collected by Prometheus. You can see graphs, charts, and tables that display real-time data about your Moon Travel Booking Website.

Resources:

Kodekloud [Paid]: https://kodekloud.com

Wrapping up:

Now that you have a clearer picture of what each of these DevOps tools does and how they solve real-world problems, I hope the mystery is starting to fade. These tools aren’t just buzzwords—they’re solutions to challenges engineers faced for years, and each one has revolutionized the way we build, deploy, and scale modern applications.

I encourage you to dive deeper into the tools that interest you most and experiment with them. DevOps is a journey, and whether you're building your own projects or working in a team, these tools will be your best allies.

Thank you for taking the time to read! If you enjoyed this post and want to stay updated on my journey, feel free to follow me or subscribe to my newsletter. If you're also diving into the world of DevOps, let's connect on LinkedIn, Twitter, or GitHub—I’d love to hear your thoughts and share ideas. I post in-depth blogs every week on what I’m learning, so join me on any of these platforms to keep the conversation going!

LinkedIn: www.linkedin.com/in/nsahil992

Twitter/X: https://twitter.com/nsahil992

GitHub: https://github.com/nsahil992