Cloud Engineering Reinforced
Going Back to Basics!
A few months into working with cloud systems, it’s easy to stop questioning the basics. You know enough to get things done, so you stop checking whether what you “know” still holds up.
Sometimes, cloud models (IaaS, PaaS, and SaaS) get treated like vocabulary to memorize, but they’re really just answering one question: who’s responsible for what — you, the platform, or the provider. The more infrastructure the provider takes off your plate, the less control you have over it, and that tradeoff is the whole decision.
Get Duane Williams’s stories in your inbox
Join Medium for free to get updates from this writer.
Deployment models add a second layer to the same question — public, private, or hybrid is really just deciding how much of that environment you own outright versus share, and most teams land somewhere in the middle rather than fully one or the other.
That thinking shows up again the moment you set up an AWS account. Anyone can create one in five minutes. Locking down the root account, turning on MFA, and routing daily work through an IAM user instead is the part that actually determines whether the account is safe to build on.
Networking still runs underneath everything No matter how managed a cloud service feels, there’s still a network underneath it. Every request comes down to one device finding another by address, with DNS translating something readable into that address, and traffic hopping across a few routers and switches along the way before it ever reaches an application. The same handful of commands still answer most “why isn’t this working” questions:
nslookup example.com —# is it DNS?
ping example.com — # is it even reachable?
traceroute example.com — # where does it break along the way?
Nothing fancy, just the fastest way to narrow down a problem before reaching for anything more complicated. No matter how advanced your skills become, the fundamentals always matter.
