For years, my world was defined by server racks and the intricate web of network cables. As a network engineer, my focus was on connectivity, security, and making sure the digital traffic flowed without a hitch. It was a career that taught me the value of methodical troubleshooting and understanding the entire infrastructure from the ground up.

But I felt a pull to the next layer of the stack, the code itself and the powerful potential of automation. I wanted to build solutions that not only used the cloud but also configured the cloud's infrastructure with code.

That's when I decided to make the switch to DevOps, and I knew I needed a project that would bridge my past experience with my future goals.

The Challenge: Building a Hands-On IaC Solution

My idea was simple but ambitious: build a full-stack application that would allow a user to click a button, and in the background, a new piece of cloud infrastructure would be provisioned using Infrastructure as Code (IaC). I decided to use Node.js and Express for the backend, with Terraform to manage the Azure resources.

It was exciting to see all the pieces come together. I built a simple frontend, set up my server, and created a POST endpoint to trigger the IaC process.

The Inevitable Obstacle (and the Network Engineer's Mindset)

Like any real-world project, it didn't work perfectly on the first try. I hit a frustrating error: EADDRINUSE. The server was telling me the address was already in use. I remember feeling that familiar wave of frustration, but my years as a network engineer kicked in. I started troubleshooting methodically. Was it a code issue? A configuration issue? Or was another process running on the same port?

I used a Linux command to check which process was using the port. I found the culprit and killed the process. It was a simple fix, but that moment was a huge validation. My network troubleshooting skills were not just relevant; they were a superpower in my new role as a developer.

A Product, Not Just a Project

This project became more than just a coding exercise. It evolved into a working proof-of-concept for a service—a tangible product that provides a clear solution to a real-world problem. It’s a testament to how I am applying my dual expertise to create value.

What I Learned and What's Next

This journey has been incredibly rewarding. It proved that my background gives me a unique advantage in the DevOps world, and that my passion for solving problems is stronger than ever. The next step is to continue building on this foundation, connecting my project to a CI/CD pipeline and exploring more advanced cloud concepts.

This is a new chapter for me, and I'm excited to see where it leads.

Key Takeaways for Your Own Journey

If you are thinking about making a similar career switch or want to build a hands-on project, here are a few things I learned that might help you:

Embrace Your Background: Don't discard your previous skills. My network engineering background was invaluable for debugging and understanding system architecture. Your unique experience is your superpower.
Build, Don't Just Study: Reading documentation is essential, but building a real project is where you truly learn. It forces you to solve real-world problems.
Document Everything: I learned to document my process and challenges, which helped me stay organized and led to this blog post. Sharing what you learn helps both yourself and others.

Thank you for reading about my journey.

Network Engineer to DevOps: My Journey into Automation