My Journey into DevOps — From an MCA Student to Cloud Infrastructure Engineer

It was my final year of MCA, and I had no idea what I was doing with my life.

Not in a dramatic way. More in the quiet, honest way that most students feel when the end of college is close enough to smell and the question — what comes next? — stops being theoretical and starts being urgent.

I had a direction, or at least I thought I did. I was interested in Android development. I had read about it, played around with it, and genuinely enjoyed the idea of building applications that lived in someone's pocket. It felt tangible. Real. Shipping something people could download and use — that was exciting to me.

But I was also, almost by accident, about to discover something that would change everything.

The Moment That Changed My Direction

It started with research. The kind of late-night, tab-heavy browser sessions that final-year students know well — trying to map your interests against the landscape of what the industry actually needs, what pays well, what has a future, and what you might not absolutely hate doing every day for the next several years.

Android development was still on the table. But as I dug deeper into the tech industry, I kept bumping into a word I did not fully understand: Cloud.

And alongside it, another one: DevOps.

I did not know what DevOps was. The Wikipedia definition was unhelpful. Most blog posts were either too shallow or too deep. But the more I read, the more something kept pulling me forward — not because I understood it, but precisely because I did not.

How does software actually run in production? Who manages the infrastructure that keeps applications alive at 3 AM? What does it mean to "deploy to the cloud"? How do teams ship code dozens of times a day without breaking everything?

These questions did not have obvious answers. And that, for me, was the sign that something genuinely interesting was hiding underneath.

So I went deeper.

The Research Rabbit Hole — Getting Genuinely Fascinated

The next few weeks were consumed by reading. Not formal studying — reading. Articles, Reddit threads, YouTube videos, documentation pages I only half understood. I learned what a virtual machine was, what containerization meant, why companies were moving workloads off physical servers and onto AWS and Azure. I read about CI/CD pipelines and how they automated the path from a developer writing code to that code reaching users. I stumbled onto Kubernetes and immediately found it both intimidating and fascinating in equal measure.

Something I read in those weeks has stayed with me:

DevOps is not a role. It is a way of thinking about software systems.

That framing unlocked something. This was not just a job category — it was a philosophy about how software should be built, deployed, and operated. It was about closing the gap between writing code and running code. It was about automation, reliability, speed, and treating infrastructure like a craft rather than a chore.

My interest in Android development did not disappear. But it quietly moved aside.

By the time I was done reading, DevOps was not a backup plan. It was the plan.

A cloud infrastructure monitoring dashboard showing Kubernetes pod health, Terraform state, and Prometheus metrics running across multiple environments

Infokalash — Where the Real Learning Started

Getting my first opportunity was the part nobody tells you much about in the career guides.

I joined Infokalash Pvt. Ltd., a newly founded startup in Hubli, as an intern. No large team, no established processes, no senior DevOps engineer sitting next to me ready to answer questions. Just a small, scrappy team building something from scratch and a lot of problems that needed solving.

Looking back, this was exactly the right environment for where I was.

In a big company, a junior engineer or intern often inherits a system that mostly works. You operate within guardrails that experienced people have already built. You learn, but you learn incrementally, within a contained scope.

In a startup, especially a newly founded one, you build the guardrails. You encounter problems that nobody has solved for that specific codebase, that specific architecture, that specific stage of the company's growth. You make decisions that matter. You break things that actually matter. And you figure out how to fix them.

The intern phase was about absorbing as much as I could, as fast as I could. I was reading documentation while also trying to apply what I was reading. I was setting up pipelines that half-worked and understanding why the other half did not. I was learning what "production" really means — not a word in a textbook, but a live system with real users depending on it.

Somewhere in that process, the intern became a DevOps Engineer.

Not because someone handed me the title and the knowledge came with it. Because the problems did not stop coming, and slowly, gradually, I stopped needing to look up the answer to every single one of them.

The Ocean of Tools — and Learning Not to Drown in It

One of the first things that overwhelms every new DevOps engineer is the sheer volume of tools.

Docker. Kubernetes. Terraform. Ansible. Helm. ArgoCD. Prometheus. Grafana. GitHub Actions. GitLab CI. Jenkins. AWS. Azure. GCP. EKS. AKS. GKE. Vault. Istio. Linkerd. Backstage. Datadog. New Relic. PagerDuty.

The list does not end. It grows. Every month, something new enters the ecosystem. Every year, something that was considered cutting-edge becomes the baseline expectation. The DevOps tools landscape is one of the fastest-moving in all of software, and if you approach it as a checklist to complete, you will exhaust yourself before you get halfway through.

I learned this early, and it helped me.

The tools are not the point. The tools are how you implement the point. The point is reliability. Speed. Automation. Reducing toil. Building systems that let engineering teams move faster with more confidence.

Once I understood that, the landscape stopped being overwhelming and started being interesting. Each tool solves a real problem that someone experienced before it was built. Understanding what problem a tool is solving — and whether that problem exists in your context — is far more valuable than knowing every flag in its CLI.

That said, some tools fundamentally reshape how you think, and they are worth going deep on regardless of whether you immediately need them.

Docker reshapes how you think about application packaging and environment consistency. Kubernetes reshapes how you think about workload management and desired state. Terraform reshapes how you think about infrastructure as something engineered, versioned, and reviewed — not clicked together in a console. Prometheus and Grafana reshape how you think about what it means to understand a running system.

These were not tools I learned once and moved on from. They are tools I am still learning, because the deeper you go, the more depth there is.

A DevOps engineer reviewing infrastructure-as-code configurations and CI/CD pipeline definitions in a collaborative workflow

Coping With the Pace — A Skill Nobody Teaches You

Here is something the DevOps community does not talk about enough: keeping up is a full-time job inside your job.

New tools come out constantly. Existing tools release major versions that change how they work. Best practices from two years ago are sometimes the antipatterns of today. The cloud providers release new services at a pace that no single person can track completely.

I have met engineers who respond to this by chasing every new thing — attending every conference talk, reading every release note, spinning up every new tool the moment it gets a GitHub star. I understand the impulse. I have felt it. But I have also learned that it is a path to shallow breadth with very little depth.

The approach that has worked better for me:

Go deep on the fundamentals first. Networking, Linux, distributed systems, how databases work under load, how the CPU and memory interact with the processes your containers are running. These things do not go out of style. Every new tool is built on top of them, and understanding the foundation makes every new tool easier to learn.

Follow problems, not tools. When a tool appears on your radar, ask what problem it was built to solve. If that problem exists in your environment, learn the tool properly. If it does not, file it away. The tool will still be there when the problem arrives.

Maintain a short list of tools you go deep on. My shortlist has stayed relatively stable for the past two years: Kubernetes, Terraform, Prometheus, and whichever CI/CD platform the team is running. I go broad enough to converse intelligently about the rest of the ecosystem, but I go deep on these because depth is where the real value is — in incidents, in architecture decisions, in mentoring.

Protect time for reading that is not about the immediate task. Some of my best learning has come from reading post-mortems from companies like Google, Cloudflare, and Stripe about systems failures and how they recovered. Not because I expect to face the exact same incident, but because the reasoning patterns they demonstrate — systematic debugging, careful hypothesis testing, clear communication during outages — are transferable to everything.

What This Journey Has Taught Me About DevOps as a Discipline

Four years in, with a startup internship, a first full-time engineering role, and several production incidents behind me, here is how I understand DevOps now versus how I understood it in that final-year research session:

Then, I thought DevOps was mostly about tools and automation.

Now, I know it is about reducing the distance between intention and outcome at every layer of the software delivery process. The tools are in service of that goal. The automation is in service of that goal. The monitoring, the incident management, the infrastructure design — all of it points toward the same thing: making it possible to build software reliably, continuously, and at a pace the business needs.

The engineers who are excellent at this are not the ones who know the most tools. They are the ones who ask the best questions. What is the failure mode here? What does recovery look like? How do we know this is actually working? What would we change if we had to maintain this in two years?

Those questions were not in any tutorial I read in my MCA final year. They came from doing the work.

Where I Am Headed Next

The journey from that late-night research session to here has been more rewarding than I imagined, and more humbling than I expected.

DevOps led me to platform engineering — thinking not just about keeping systems running, but about building the internal infrastructure and tooling that lets every team in an organisation ship software better. That evolution has felt natural, because the underlying question is the same: how do we make the process of building and running software as smooth and reliable as possible?

The field is not standing still. AI is beginning to enter the infrastructure space — anomaly detection, assisted incident response, infrastructure generation from intent. I am paying attention, and I am curious. But I am also grounded in the belief that the fundamentals — reliability, observability, automation, developer experience — will remain the foundation regardless of how the tooling evolves around them.

If you are a student reading this from a final-year position similar to mine, trying to figure out which direction to head: the research you are doing right now is part of the work. The curiosity that keeps you reading past the point where you understand every word is a signal worth trusting.

Follow the questions that do not have obvious answers. The map builds itself from there.

---

I write about DevOps, platform engineering, and cloud infrastructure at sourabhkulkarni.in — sharing what I learn as I learn it. The next article is already in progress.