How I Moved from Backend to SRE
For a long time, I thought my responsibility ended at the backend.
If an API failed, the problem had to be in the code: a poorly optimized query, a misconfigured timeout, a small connection pool. That was my known territory, and I mastered it. I felt comfortable there.
But… there’s always a “but,” right? One night, an important endpoint went down.
At three in the morning, everything feels like a bad idea.
We had been dealing for hours with this endpoint that kept failing intermittently. Nothing reproducible. Nothing obvious. The kind of issue that makes you question even your own judgment. I was convinced the code was fine, but I reviewed it anyway. Twice. Three times. Looking for that tiny detail you miss when you’re tired and want to believe the problem is simple.
Nothing. The service kept crashing.
At that point, I was a backend developer. My world ended at the code.
Hours later, a teammate found the root cause. It wasn’t a line of code. It was a poorly applied IAM policy limiting a critical resource. Something I hadn’t touched. Something that, until then, I didn’t even consider part of my responsibility.
The next day, I couldn’t stop thinking about one thing: my coding decisions were conditioned by infrastructure I didn’t control. And the worst part wasn’t that. The worst part was realizing I had spent hours assuming the bug was mine because my thinking was limited to my own area of work.
That was the first moment I understood that knowing how to code well wasn’t enough. I could write clean, tested, efficient code and still not understand why my services were failing in production.
My First Leap: From Backend to Cloud Engineer
What seems like a role change turns out to be a natural expansion of how you think, if you step outside your cubicle. A Cloud Engineer isn’t a developer who knows AWS. It’s a developer who understands that their code runs in production because there’s infrastructure enabling and supporting it and knows how to create, manage, and optimize that infrastructure.
A shift in perspective changes everything. This first leap wasn’t about tools so much as changing the way I thought.
- Infrastructure can also be code. A VPC, an S3 bucket, or your IAM roles are literally code.
- CI/CD pipelines make deployments easier because there are tests, validations, analyses, and automatic rollbacks behind them.
- The cliché “it works on my machine” disappears. With containers and orchestrators, it works on any machine that follows the rules.
- And like any infrastructure, you learn to understand limits, costs, latencies, observability, and more.
If you work with separate infrastructure teams and developers in your company don’t understand how production deployments work, sooner or later you’ll face a major issue caused by that lack of understanding.
Here, the mindset shift is subtle but deep: you go from building services to building the environments that make those services possible.
My Second Leap: From Cloud Engineer to SRE
One of the most “educational” situations I experienced happened during a traffic spike that got out of control. Back when I worked at an agency, we handled large clients and always kept an eye on key dates like Black Friday and Christmas. But this time, one client launched a promotion without notifying us, a classic move.
At that time, my role was more cloud-focused than pure SRE.
After more than half an hour of confusion, we found the root cause: the cluster autoscaling had reached its maximum limit. That limit had been configured two months earlier to save costs in staging and it stayed that way in production.
The funny thing? The infrastructure was trying to scale. The metrics were demanding it. The orchestrator was ready. But the configuration prevented it.
The system didn’t fail because of a bug. It failed because responsibility doesn’t end with writing code, it includes understanding the environment where that code lives.
We could blame the client for not warning us. But the reality is that today we have the ability to turn any platform or website into a monitored and reliable environment.
That’s where my next step developed: turning services into robust, scalable, fault-tolerant platforms.
Becoming an SRE is, in a way, taking development and cloud logic to the extreme of reliability. While a Cloud Engineer focuses on building reproducible infrastructure, an SRE focuses on keeping it observable, scalable, and resilient (and in many companies, both roles overlap or are the same, and that’s fine).
This is where everything a developer already knows comes into play but applied at a different level.
- Automation: everything repeatable gets codified. Automating horizontal scaling, creating health checks, writing recovery scripts.
- Observability: monitoring logs, metrics, and traces as the primary source of truth. Instrumenting code, sending metrics to Prometheus, visualizing latency in Grafana.
- Designing measurable reliability: knowing when a service has been unavailable. Understanding root causes. Generating downtime alerts.
- Postmortems and continuous improvement: documenting causes, actions taken, recurring patterns and then automating repeated solutions.
Moving from backend to Cloud/SRE isn’t about learning more tools. It’s about expanding your horizon of responsibility. Accepting that your code runs on infrastructure that is just as important and must remain reliable most of the time.
Moving from Backend to SRE
Infrastructure isn’t a technical detail. It’s part of the business.
If you’re a backend developer interested in infrastructure, think about expanding your scope toward cloud and reliability.
Becoming a Cloud Engineer or SRE isn’t a leap into the void. It’s a natural evolution for those who enjoy building platforms that live, scale, fail, and recover.
It can feel intimidating at first. But once you start versioning infrastructure, understanding a pipeline, and seeing your services through real observability, you realize that what seemed like a whole new world is actually the logical extension of what you already know.
Your experience as a developer becomes your most powerful asset. It’s not a role change. It’s a perspective shift.
¿Quieres saber un poco más sobre quién ha escrito este artículo? 👇
I’m a Cloud Engineer | SRE with experience in cloud environments and AWS architectures, focused on automation, security, and operational efficiency.
I’m passionate about designing robust infrastructures, optimizing costs, and turning technical complexity into clear, maintainable solutions.