Day 43 of My Cloud Engineering Journey: Finishing DevOps Fundamentals and Learning That Good Cloud Engineers Think About Cost Too

Today I wrapped up the DevOps Fundamentals course, and it was a fitting way to conclude everything I’ve been learning over the past several weeks. Looking back, it’s interesting how my perspective has changed. When I first started learning about DevOps, I thought it was mostly about tools. Now I realize the tools are important, but they’re only one piece of a much larger system.

Today’s Topics

• The four common DevOps metrics for measuring software delivery performance
• Additional engineering and operational metrics
• A Data Scientist’s perspective within DevOps
• Technology patterns and choosing the right tools
• Transitioning from older technologies to newer architectures
• An Architect’s perspective in DevOps
• The overall value of DevOps
• A team-based DevOps scenario

One takeaway that stood out to me was the importance of measuring success instead of guessing it.

Whether it’s deployment frequency, lead time for changes, recovery time after incidents, or change failure rates, metrics provide an objective way to understand how a team is performing. Rather than relying on assumptions, engineering teams can identify bottlenecks, improve processes, and make informed decisions backed by data.

I also enjoyed learning about technology patterns and the thought process behind choosing solutions rather than simply selecting the newest technology available. Good engineering isn’t about chasing trends. It’s about understanding the problem, evaluating trade-offs, and selecting the right tool for the job.

Outside of the course, I spent some time exploring my own AWS account with a different objective in mind: cost awareness.

I navigated through AWS Billing and Cost Management, reviewed my monthly spending, looked through my EC2 instances, and audited my storage usage. Along the way, I terminated instances I was no longer using and deleted storage resources that were no longer needed.

This wasn’t exactly FinOps at an enterprise scale, but it reminded me that good cloud habits start early. Even when you’re learning, it’s important to understand what resources you’re running, what they’re costing you, and whether they’re still providing value. Cloud resources are incredibly easy to create, but they’re just as important to clean up when they’re no longer needed.

I think getting into the habit of periodically auditing my own AWS environment will make me more mindful as I continue building projects in the future.

One thing I’ve appreciated about this entire DevOps course is that it wasn’t just technical. It covered the people, processes, culture, automation, measurement, collaboration, and technology that all come together to deliver software reliably.

As someone transitioning toward a Cloud DevOps Engineer role, I feel like this course gave me a much better understanding of the “why” behind everything I’ll continue learning. Linux gave me command-line confidence. Terraform introduced me to Infrastructure as Code. DevOps Fundamentals helped connect those technical skills to the bigger picture of how modern engineering teams actually work together.

Tomorrow I’ll begin learning Shell Scripting in Linux.

I’m looking forward to it because it feels like a natural next step. The more comfortable I become with the Linux command line, the more valuable automation becomes. Writing shell scripts will allow me to automate repetitive tasks, reinforce the Linux skills I’ve been building, and continue developing practical skills that are directly relevant to Cloud and DevOps engineering.

One day at a time. The consistency continues.