Eight years ago I was an Infrastructure Analyst at BDO Uruguay, managing a small on-premises environment and wondering whether “the cloud” was hype or the next thing I needed to learn. Today I work as a Cloud, DevOps and SRE engineer, building production AWS infrastructure as code and owning the reliability of the systems I ship. Here is how that path actually went, including the parts that were not obvious at the time.

The on-premises foundation (2017 to 2021)

I started at BDO Uruguay in 2017. My world was physical and local: Active Directory, DNS, DHCP, Windows Server and Linux, running across a handful of on-premises servers. The work ranged from L1 support to L3 troubleshooting, and I ended up writing a fair amount of the company’s IT policy, security standards and operational procedures.

It is easy to dismiss that kind of work once you move to the cloud, but it gave me something many cloud-native engineers skip: an understanding of how systems behave underneath the abstractions. Knowing how DNS resolution, identity and storage actually work still helps me every time I design something on AWS.

In parallel I was studying. I took the Certified Network Defender program at EC-Council University and worked through an IT Infrastructure Analyst degree at Universidad ORT Uruguay. The combination of formal study and daily hands-on support kept the theory grounded.

First step into enterprise scale: Park Place (2021)

In March 2021 I joined Park Place Technologies doing L2 hardware support across enterprise platforms: Dell, Cisco, HPE, IBM, NetApp and EMC, under strict SLA targets. It was my first taste of working with US teams and of systems where response time was contractually measured.

That pressure taught me to troubleshoot calmly and to document everything. It also planted the question that would define the rest of my career: how do you stop problems from happening in the first place, instead of just responding faster when they do?

The cloud and SRE turn: Sabre, then CAE (2021 to 2024)

In December 2021 I took my first DevOps and SRE role at Sabre Corporation, on an airline operations platform. When that business unit moved to CAE, the platform, the team and the work continued, so I count those years as one continuous chapter from late 2021 to May 2024.

This was where I learned the cloud and SRE craft for real. The platform ran on OpenShift, and I went from being unfamiliar with container orchestration to operating five core microservices on it with Helm and an Istio service mesh.

A few things stuck with me from those years.

Infrastructure as Code is not optional. I owned IaC delivery across a three-environment estate, on premises, on AWS EC2 and on AWS ROSA, using Terraform and CloudFormation. The difference between clicking through consoles and having infrastructure defined in reviewable code is the difference between hoping you can rebuild something and knowing you can.

# A reviewable change, not a console click
resource "aws_security_group_rule" "api_ingress" {
  type              = "ingress"
  from_port         = 443
  to_port           = 443
  protocol          = "tcp"
  cidr_blocks       = var.allowed_cidrs
  security_group_id = aws_security_group.api.id
  description       = "HTTPS from approved ranges only"
}

On-call is where reliability gets real. I was the primary on-call SRE for a mission-critical platform, which meant owning P0 and P1 incidents and running the post-incident reviews afterward. Nothing teaches you to design for failure faster than being the person paged when it happens.

Automation scales, manual work does not. I automated configuration management with Ansible across the full environment and built CI/CD on Azure DevOps. The systems that survive are the ones where the boring, repeatable parts are handled by machines.

Where I am now: Zeta Global (2024 to present)

In May 2024 I joined Zeta Global, formerly Marigold, in AdTech. The focus shifted toward moving an enterprise estate onto clean, peer-reviewed Infrastructure as Code.

The work I am proudest of here is unglamorous on the surface and high-impact underneath:

• Migrating more than 40 AWS resources, including 20 EC2 instances, 13 Aurora RDS clusters, 4 ECS clusters and a Redshift warehouse, from console-managed to Terraform and OpenTofu on Spacelift. That eliminated drift and made every change reviewable.
• Architecting ECS Fargate platforms from scratch, including an SMS application migration with multi-provider integration and centralized logging through FireLens.
• Building multi-VPC networking with Transit Gateway and federating identity between AWS IAM Identity Center and Azure Entra ID.
• DBA-grade SQL Server work on AWS, including an RDS to EC2 plus FSx for NetApp ONTAP migration and the root-cause analysis of some genuinely nasty Error 823 incidents.

What actually moved the needle

Looking back, a few lessons matter more than any specific tool.

The fundamentals compound. Networking, identity and storage knowledge from the on-premises years pays off constantly in cloud design.

Learn by breaking things, carefully. I read plenty of documentation, but the real learning happened when something broke in production and I had to understand it under pressure, with a rollback plan ready.

Communication is half the job. Explaining a tradeoff to a developer or a stakeholder, and writing it down clearly, has been as valuable as any technical skill.

It is a continuous path, not a destination. The tools I use now will look dated in a few years. The constant is the goal: reliable, reviewable, well-understood systems that serve the people who depend on them.

If you are making a similar move from traditional IT into cloud and SRE work, my advice is simple. Start where you are, get hands-on with Infrastructure as Code early, take ownership of reliability rather than just monitoring it, and treat every incident as something to learn from. The path is demanding, but it is a good one.

---

Working through a similar transition? I am happy to compare notes. You can reach me on LinkedIn or by email.