I didn’t start in the cloud. Most of the people I work with today began their careers with a cloud account and a Terraform file. I began mine closer to the wires, with firewalls, routers, and phone calls that could not drop.
This is the short version of how I got from there to here, and why I think the long way around made me a better engineer instead of a slower one.
Table of contents
Open Table of contents
Starting in the wires
My first real work was in networking and telecom. Fortinet and Palo Alto firewalls, VPNs, switching, and a lot of VoIP with Asterisk. It was a good place to learn, because the feedback loop was brutal. When a call dropped, someone noticed in the same second. There was no “eventually consistent” in telephony. The packet either arrived in time or the conversation broke.
That world also pushed me deep into systems. Slackware, FreeBSD, compiling things by hand, reading man pages because there was no managed service to hide behind. I learned what the machine actually does when you ask it to do something, which is a kind of knowledge that keeps paying off long after the specific tools are gone.
The mindset that stuck
In telecom you don’t get to scale your way out of a bad night. You design for failure up front, because failure is loud and immediate. You think about redundancy, failover, what happens when a link flaps at 2 AM, what the system does when one piece disappears.
Nobody called it SRE back then. But that is exactly what it was: assume things break, measure what matters, and build so the broken part doesn’t take everything down with it.
Moving to the cloud
Then the cloud showed up and a data center became an API call. That part felt like magic. The part that did not change was the hard part, and I already had the habits for it.
I brought the old instincts with me. Assume it breaks. Design for the 3 AM page. Automate the boring and error-prone work so a tired human isn’t doing it by hand. The tools were new, Terraform, Kubernetes, pipelines, but the questions underneath were the same ones I had been answering for years.
Why the old layers still matter
Most outages are still, at the bottom, a networking or systems problem wearing a cloud costume. DNS resolution, routing, MTU, a security group that is really just a firewall rule with a friendlier name. The abstraction is wonderful right up until it leaks, and it always leaks eventually.
When that happens, the engineer who understands the layer underneath is the one who fixes it while everyone else is still refreshing the status page. That is the quiet advantage of starting low in the stack.
What I would tell someone starting today
You don’t need to take the same fifteen year road I did. But don’t skip the fundamentals on the way up. Learn what a packet is. Learn what the kernel is doing. Learn why the answer to the outage is so often DNS. The cloud is still just someone else’s computer, and sooner or later you will need to know how the computer works.
That is the thread that ties all of this together for me, and it is most of what I plan to write about here.
I write about Cloud, SRE, DevOps, AWS, Kubernetes, Terraform, and the real lessons I pick up building and operating infrastructure. Opinions are my own.