Weekly DevOps career tips and technical deep dives. My mission is to help you land your next DevOps, Platform Engineering or SRE role, even if you are brand new. I went from nurse to DevOps and I can help you do the same.
|
Hey Reader, “Should I learn AWS or Azure?” I get this question every week. And most people overthink it. Here’s the truth: It doesn’t matter as much as you think. Choosing a cloud provider might feel like marrying a woman: you’re making a commitment for life. You’re locking yourself into an ecosystem and attaching yourself to a specific vendor. However, in a 10 year or 20 year view of your career, it matters much less. It doesn’t matter if you have zero tech experience or coming from a sys admin / software engineering background. You have to pick one in the beginning. Later in this newsletter I’ll explain what comes after that. First let me show you the 30-minute method to figure out which one to pick. Too Little Butter Spread Over Too Much BreadI see this happening almost every week. Someone enters my mentorship program and joins a coaching call with me to figure out their next steps. The biggest mistake they make: trying to learn AWS, Azure, AND GCP at the same time. You might be doing this too. You think you’re “diversifying your skills.” You think more clouds = more job opportunities. You’re wrong. Here’s what actually happens: You become mediocre at everything, expert at nothing. You know where a few buttons are in three different portals. You can’t troubleshoot anything. You can’t architect anything. You’re spread too thin to be useful. And recruiters see through it immediately. When I review a resume with AWS certifications, Azure certifications, and GCP projects, I don’t think “Wow, this person is versatile.” I think “This person can’t commit. They don’t know what they want. They’re probably job-hopping in six months.” Companies don’t hire cloud generalists. They hire specialists. They need “the Azure person” or “the AWS person.” Someone who knows that ecosystem deeply. Someone who’s spent a year or two actually building things on one platform, not someone who’s spent three months dabbling in three. (There are some exceptions for multi-cloud environments, but these are usually Architect level roles, not the hands-on engineering roles). I made this mistake when I started. I thought learning multiple clouds was protecting me. “If one cloud loses market share, I’ll have options!” Wrong. I was just preventing myself from getting good at anything. Depth beats breadth when you’re starting out. Always. The LinkedIn Test: How to Choose in 30 MinutesOkay, so you need to pick one. How? Stop asking Reddit. Stop watching “AWS vs Azure” comparison videos. Stop overthinking it. Open LinkedIn right now. I’m serious. Do this:
That’s it. Decision made. Follow the money, not the hype. Here’s my example: I’m in the Netherlands. When I search for Azure jobs in Amsterdam, The Hague, Utrecht, and Rotterdam, I get 1,651 results. When I search for AWS in the same regions, I get 77 results. That’s a 20x difference. Case closed. Why does Azure dominate here? Because Microsoft already owns Dutch enterprises through Office 365. They have local data centers. They offer free Azure credits to existing customers. They’ve locked in government contracts because of data sovereignty requirements. AWS might have the developer mindshare. AWS might be “cooler.” But Azure pays the bills in my market. Your market might be different. Maybe you’re in Seattle and AWS dominates. Maybe you’re in a tech hub where GCP has traction. I don’t know. That’s why you need to run the numbers yourself. Look for these market signals:
Pick One Cloud to Get Hired. Learn the Craft to Stay ValuableMost DevOps and Kubernetes jobs will list a cloud provider as a requirement. However, Cloud Engineering is a commodity at this stage. They’ve made it so easy for us that it’s not challenging anymore. This is not a surprise because we want AWS and Azure to make our lives easier. That’s what we pay them for. But it has consequences for us engineers. Learning managed cloud services only keeps your knowledge superficial and thus easier to replace by AI. My prediction: cloud engineering will become so abstracted, templated and AI assisted that in 5 years there is no “Cloud Engineering” specialty anymore. There will be Cloud Architects, but those are the guys that have been doing it for 8+ years, and companies only need a couple of them. If your only skill is typing out Terraform configs or peering VNets in the cloud, you’ll be without a job in 5 years. Craftsmanship Cannot Be ReplacedIf you want to stay relevant, you have to focus on tools, not vendors. I’ve drunk the Azure kool-aid and went deep, and it’s a well-paid skill to have. But I’m glad I kept my focus on free and open source software in my free time. I kept daily driving Arch Linux and I always kept my work focused around Kubernetes. Because Kubernetes is the tool of the future. You can read more about that in this previous newsletter, but here’s a quick recap:
Mediocre engineers will get a few cloud certificates, get a comfortable job and stop developing themselves. They don’t care to go a few layers deeper. They don’t understand Linux and are not willing to learn Kubernetes. I teach my students to be come future proof by learning the Craft: • Deep Linux • Networking • Kubernetes • Vendor agnostic tooling • Open source This is the way to career longevity and true Autonomy. Your company switches from AWS to Azure? You’re fine. It’s the same Kubernetes. You change jobs to a company using GCP? No problem. You know Kubernetes. Your next company is moving back to on-prem? Kubernetes runs there too. AWS loses market share in five years? Doesn’t matter. You’re not an AWS engineer. You’re a Kubernetes engineer. The cloud providers know this. That’s why they’re all standardizing on Kubernetes. It’s the orchestration layer that won. And if you control that layer, the cloud vendor above it is just implementation details. But here’s the problem: Nobody teaches you HOW to learn Kubernetes in a way that makes cloud skills easy. Most people learn cloud first, then maybe Kubernetes later. That’s backwards. You’re learning the abstraction before understanding what it’s abstracting. It’s like learning React before JavaScript. When you learn Kubernetes, cloud-managed Kubernetes services become obvious. You understand what’s happening under the hood. When something breaks, you can troubleshoot it. When you need to optimize it, you know what levers to pull. Become a Craftsman2 years I go I built KubeCraft. Kube for Kubernetes, Craft for Craftsmanship. I teach the Craft of the Kubernetes Engineer. A future proof career path that will ultimately lead to a life of sovereignty:
Hundreds of others have gone before you and landed six figure DevOps careers by my teaching. When you are ready to become a Craftsman, you can apply to join: CLICK HERE I only take 10 students per month and 4 spots are already gone for November. Claim your spot before it’s too late. Honor thy craft, Mischa |
Weekly DevOps career tips and technical deep dives. My mission is to help you land your next DevOps, Platform Engineering or SRE role, even if you are brand new. I went from nurse to DevOps and I can help you do the same.