From Infrastructure Analyst to Cloud Engineer: My 5-Year Journey

Five years ago, I was working as an Infrastructure Analyst at BDO Uruguay, managing traditional on-premises servers and wondering if “the cloud” was just another tech fad. Today, I’m a Cloud/DevOps/SRE Engineer at Marigold, working with cutting-edge cloud technologies and helping build systems that serve millions of users. Here’s the story of that transformation and what I learned along the way.

The Traditional IT Foundation (2017-2021)

My journey began in 2017 at BDO Uruguay as an Infrastructure Analyst. Like many IT professionals in Uruguay at the time, my world revolved around physical servers, network cables, and traditional enterprise software. I was responsible for:

  • Managing Windows and Linux servers in on-premises data centers
  • Troubleshooting network connectivity issues
  • Maintaining backup systems and disaster recovery procedures
  • Supporting enterprise applications like SAP and Exchange

While this might seem outdated now, this foundation was invaluable. I learned how systems actually work under the hood—something that many cloud-native engineers miss. Understanding physical networking, storage systems, and server hardware gave me insights that I still use today when designing cloud architectures.

The Learning That Changed Everything

In 2020, during the pandemic, I made a decision that would change my career trajectory: I enrolled in the Certified Network Defender (CND) program at EC-Council University. This wasn’t just about cybersecurity—it opened my eyes to modern infrastructure concepts, automation, and the security challenges that traditional IT approaches couldn’t solve efficiently.

Around the same time, I was pursuing my degree in IT Infrastructure at Universidad ORT Uruguay. The combination of academic learning and hands-on experience gave me a solid theoretical foundation while keeping me grounded in practical realities.

The First Leap: Engineering Support (2021)

In March 2021, I joined Park Place Technologies as an Engineering Support specialist. This role was my first real exposure to enterprise-scale systems and international operations. Working with clients across different time zones taught me:

  • The importance of clear communication in technical roles
  • How to troubleshoot complex systems under pressure
  • The value of documentation and knowledge sharing
  • Why 24/7 support requires different thinking about system design

This experience planted the seeds of what would later become my passion for Site Reliability Engineering. I started to understand that the goal isn’t just to fix problems—it’s to prevent them from happening in the first place.

The Cloud Awakening: Sabre Corporation (2021-2022)

December 2021 brought my first official “DevOps & SRE Engineer” title at Sabre Corporation. This was my introduction to cloud technologies, and honestly, it was overwhelming at first.

The Reality Check

My first week at Sabre was humbling. Suddenly, I was expected to understand:

  • AWS services and their interconnections
  • Infrastructure as Code concepts
  • CI/CD pipelines
  • Container technologies
  • Monitoring and observability at scale

The learning curve was steep, but the travel industry’s demands for high availability and scalability provided the perfect environment to understand why cloud technologies had become essential.

Key Learnings from Sabre

  1. Scale Changes Everything: The systems I’d worked with before served hundreds of users. Sabre’s systems served millions. This taught me that solutions that work at small scale often break at large scale.

  2. Automation Isn’t Optional: Manual processes that seemed fine for 50 servers become impossible with 500 servers in the cloud.

  3. Monitoring Must Be Proactive: In traditional IT, we often waited for users to report problems. In cloud environments serving global customers, you need to know about issues before users do.

Although my time at Sabre was brief (4 months), it was transformative. I left with a clear understanding of what modern infrastructure looked like and a hunger to learn more.

Scaling Up: CAE (2022-2024)

Joining CAE as a DevOps & SRE Engineer in March 2022 marked the beginning of my serious cloud engineering career. CAE, being a leader in simulation and training technologies, provided exposure to mission-critical systems where downtime wasn’t just expensive—it could impact safety training for pilots and other professionals.

The Projects That Shaped Me

1. Infrastructure as Code Implementation

One of my first major projects was helping migrate CAE’s infrastructure to Infrastructure as Code using Terraform. This project taught me:

# Before: Manual AWS console clicks
# After: Repeatable, version-controlled infrastructure

resource "aws_eks_cluster" "training_platform" {
  name     = var.cluster_name
  role_arn = aws_iam_role.eks_cluster.arn
  version  = var.kubernetes_version

  vpc_config {
    subnet_ids = var.subnet_ids
    endpoint_config {
      private_access = true
      public_access  = true
    }
  }

  depends_on = [
    aws_iam_role_policy_attachment.eks_cluster_policy,
  ]
}

The difference between clicking through the AWS console and having infrastructure defined in code was like the difference between following a recipe and having a chef who could recreate a dish perfectly every time.

2. Kubernetes Migration

Moving workloads from traditional VM-based deployments to Kubernetes was my crash course in container orchestration:

# Learning to think in terms of desired state
apiVersion: apps/v1
kind: Deployment
metadata:
  name: training-simulator
spec:
  replicas: 3
  selector:
    matchLabels:
      app: training-simulator
  template:
    metadata:
      labels:
        app: training-simulator
    spec:
      containers:
      - name: simulator
        image: cae/training-simulator:v2.1.0
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

3. 24/7 On-Call Experience

This was where I truly learned the SRE mindset. Being responsible for systems that couldn’t fail taught me:

  • How to design for failure (because everything fails eventually)
  • The importance of observability and good alerting
  • How to balance feature velocity with system reliability
  • The art of incident response and post-mortem analysis

The Technical Growth

At CAE, I deepened my expertise in:

  • AWS Services: From basic EC2 and S3 to advanced services like EKS, RDS, ElastiCache, and CloudFormation
  • CI/CD Pipelines: Building robust deployment pipelines with Azure DevOps and Jenkins
  • Monitoring: Implementing comprehensive monitoring with CloudWatch, Prometheus, and Grafana
  • Security: Learning cloud security best practices and compliance requirements

But more importantly, I learned how to translate business requirements into technical solutions and communicate technical concepts to non-technical stakeholders.

Current Role: Marigold (2024-Present)

In May 2024, I joined Marigold as a Cloud/DevOps/SRE Engineer. This role represents the culmination of my journey so far, working with a team that’s pushing the boundaries of cloud-native architecture.

What’s Different Now

The complexity of systems I work with today would have been incomprehensible to me five years ago. We’re dealing with:

  • Multi-region deployments across global data centers
  • Microservices architectures with hundreds of interdependent services
  • Real-time data processing at massive scale
  • Advanced automation using GitOps principles

Current Focus: Microservices Architecture

One of my main goals at Marigold is deepening my understanding of microservices patterns. This includes:

# Service mesh configuration for inter-service communication
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - match:
    - headers:
        x-user-type:
          exact: premium
    route:
    - destination:
        host: user-service
        subset: premium
      weight: 100
  - route:
    - destination:
        host: user-service
        subset: standard
      weight: 100

The shift from monolithic thinking to microservices requires a completely different approach to system design, monitoring, and troubleshooting.

Key Lessons from My Journey

1. Foundation Matters, But Don’t Get Stuck

My traditional IT background gave me valuable insights into how systems work fundamentally. However, I had to be willing to let go of old ways of thinking when they didn’t apply to cloud environments.

2. Learn by Doing, Not Just Reading

I read countless blog posts and documentation, but the real learning happened when I broke things in production (carefully, and with good rollback plans).

3. Soft Skills Are as Important as Technical Skills

The ability to explain complex technical concepts to business stakeholders, collaborate effectively with developers, and remain calm during incidents has been as valuable as any technical skill.

4. Embrace the Learning Curve

Technology moves fast, especially in the cloud space. What I learned two years ago is already being superseded by new approaches. The key is to enjoy the learning process rather than trying to reach a final destination.

5. Build Relationships, Not Just Systems

Every role transition in my career happened because of relationships I’d built. Technical skills got me in the door, but personal connections opened the doors.

The Skills That Made the Difference

Looking back, here are the technical skills that had the biggest impact on my career progression:

Early Career (Essential for any IT role):

  • Linux administration and bash scripting
  • Networking fundamentals
  • Basic security principles
  • Troubleshooting methodology

Mid-Career (Cloud transition):

  • AWS core services (EC2, S3, VPC, IAM)
  • Infrastructure as Code (Terraform)
  • Basic containerization (Docker)
  • CI/CD concepts

Current Level (Advanced cloud engineering):

  • Kubernetes orchestration
  • Advanced AWS services (EKS, RDS, ElastiCache)
  • Service mesh technologies (Istio)
  • Observability and monitoring
  • GitOps practices

Always Important:

  • Python/scripting for automation
  • Git version control
  • Documentation and communication
  • Incident response and troubleshooting

Advice for Others Making the Transition

For Infrastructure Professionals Looking to Move to Cloud:

  1. Start with the fundamentals: Get AWS/Azure/GCP certified to understand core cloud concepts
  2. Practice Infrastructure as Code: Start small with Terraform or CloudFormation
  3. Learn containerization: Docker first, then Kubernetes
  4. Build projects: Create a portfolio showing your cloud work
  5. Join communities: Local meetups, online forums, and cloud communities

For New Graduates Entering the Field:

  1. Get hands-on experience: Cloud platforms offer free tiers—use them
  2. Understand the full stack: Don’t just learn cloud services; understand how they connect
  3. Develop T-shaped skills: Deep knowledge in one area (e.g., AWS) plus broad knowledge across the stack
  4. Learn to automate everything: Manual processes don’t scale
  5. Practice incident response: Learn how to troubleshoot under pressure

What’s Next?

As I continue my journey at Marigold, my focus is on:

  • Deepening microservices expertise: Understanding advanced patterns like event sourcing, CQRS, and distributed tracing
  • Exploring emerging technologies: Service mesh, serverless architectures, and edge computing
  • Building better automation: GitOps, policy as code, and self-healing systems
  • Sharing knowledge: Contributing to open source and writing about lessons learned

The Continuous Journey

The most important lesson from my five-year journey is that it’s not really a destination—it’s a continuous evolution. The technologies I use today will likely be obsolete in five years, replaced by new approaches I haven’t even heard of yet.

What won’t change is the fundamental need to build reliable, scalable systems that serve users well. Whether that’s done with traditional servers, cloud services, or technologies that haven’t been invented yet, the core principles of good engineering remain the same.

The transition from Infrastructure Analyst to Cloud Engineer wasn’t just about learning new technologies—it was about developing a new mindset. A mindset that embraces change, values automation, thinks in terms of systems rather than servers, and always keeps the user experience at the center of technical decisions.

To anyone considering a similar transition: the journey is challenging, but incredibly rewarding. The cloud engineering field offers endless opportunities to learn, grow, and solve interesting problems. Start where you are, use what you have, and take it one step at a time.

What’s your experience with career transitions in tech? I’d love to hear your story and share experiences. Feel free to connect with me on LinkedIn or reach out via email.