Cloud Architects: The Skill That Makes You AI-Proof

Do you want to know why deep fundamentals matter and why they're your most transferable skill in tech? If so, this video is for you. In today's video, we're going to discuss why deep fundamentals matter so much and why they are the key to success. For cloud architect career security architect careers and any other I. T architect. When I started my career, things have changed a little bit. Or have they? But you know yesterday it was virtualization, then it was cloud, then it was containers, then it's service mesh, then it's zero trust. I mean, it constantly feels like a state of evolution. But if you take some of the noise away, a lot of people really feel about the same thing. If I don't learn this right now, I'm going to fall behind. And I see this from so many people. They're so worried about learning the new thing and falling behind. But today, I want to give you an antidote to that anxiety. Deep fundamentals are going to be the most transferable skills in tech, especially for cloud architects, enterprise architect, security architects. And here's the reason your fundamentals don't expire when the tool changes or the name changes. Now, if you've ever felt that whiplash, if I need to learn this, this. I need to learn this comment fundamentals in the chat so I know that I'm talking to people just like me that have experienced this in the past. So what do I mean by deep fundamentals? When I say deep fundamentals, I don't mean trivia. I don't mean the vocabulary. I don't mean which box is to click. I mean the core ideas that are going to show up in nearly every system. How networks behave. Things like latency, throughput failure modes. Identity and access management. Encryption. Segmentation. Micro segmentation. Consistency. Availability. Observability. Change management, risk management, those kinds of things. Because when you really look at it, those fundamentals are kind of like the physics of what we actually do as architects. And the point is, is tools come and go. You know, it used to be ISDN and Frame Relay. Now it's kind of an Ethernet or a VPN world or Mpls based circuits or Ethernet layer two circuits, but vendors rename things. I mean, a lot of the old technology just gets rebranded over time, but that kind of physics, those fundamentals tend to not change very often. It's only the marketing names that do. And I can tell you, after being an enterprise architect for decades, I can tell you the people that rise the fastest often aren't the ones that memorize a whole bunch of features and chase a whole lot of certifications, though the people who truly understand what's happening under the hood, in these systems and in the business. And that way, when you know what's going on, it becomes so easy to adapt to everything. You know, the secret to the new tech is often the old tech. It just looks a little different. And there's actually an old legendary internet document called RFC 1925. And it's the 12 networking truth. And it's humorous. Internet specification or request for comment, but it's so accurate. And here's the thing is, a lot of the new technology is really the old technology with the new name, I'll give you some examples. It's old patterns with modern packaging. It's the same old constraints, but we now have new interfaces. It's an old problem, but with a new dashboard is changed very little. For example, approximately in 2000, Cisco had something called NetFlow that would show you the type of traffic that was traversing your network. Now AWS has that same service right now in 2025, at the new AWS Reinvent in December 2025, AWS announced an interconnect where basically they have a connection to Google, and you can just provision a private line on that, or a private connection or a virtual private connection. Now, that's not that much different than the frame rate way networks in the 1990s or the ATM network. So the V plus networks are any of these networks that existed. And when you know the old thing, learning the new thing is so easy because you're not starting from zero, you're mapping, what, you know, to something that's changed a few percent along the way. And that's going to make it real simple. And that's the power of fundamentals. They give you a metal model that will survive any generation of technology. So 20 years later, in many cases, those same fundamentals still apply. So I give you an example for cloud architects. And I'll security architects. Now let's say we've got someone that tried to be an architect and learned engineering. And they became obsessed with tools, and they became an expert of a tool and configuring the tool, even though that's more engineering work. But let's say they did that.

The tool focused person is focused on which button to I press, how do I use this tool. But a fundamentals focused architect, for example, says tell me the outcome that we need, what the constraints are that we have and what trade off. We're willing to accept. And from there works backwards. So it's very different because we cloud architects when in cloud architecture is not mount memorizing services. Security architecture is not memorizing services. It's about designing systems that behave the way the business needs to give that business a competitive advantage. So for the cloud architects out there, once you have the fundamentals, which in most cases are the data center, because all cloud computing is a virtual data center, you can pretty much walk into any technology and figure out real quickly what problem is it solving, what does it do in an abstract way? What does it not solve? What are the sharp edges on this technology? We have to be careful about what happens when it's going to grow at scale. And that's why deep fundamentals will make those cloud architects, so adaptable from one role to another role, because we don't freeze when a technology gets rebranded, we don't fall apart when yesterday's best practices change. Because our fundamentals are strong, we understand the underlying mechanics. And, if you think this is funny, I kind of liked in RFC 1925, one of the statements is it has to work. And that's basically the job description of architecture in some way, shape or form, at least from the technology perspective about the business side. Now the business side has to work too. So let's talk about security architects and where fundamentals help them. Security is a great example because in many cases attackers don't care what you're cloud up. They don't care which vendor you bought from. They don't care. They don't care what acronym is trending. They exploit fundamentals weak identity control, bad segmentation, over provisioned access, broken assumption. Unobserved changes that when they try to break into the system. Poor key management and of course human behavior. So if you're a security architect and you have deep fundamentals, new security tech becomes very easy because you probably already know it and you have to look at it. What trust boundaries does this change when you've got a new technology, for example, what does this do to the blast radius. What's the failure mode. What's the operational burning? And there's this. And what rest does it solve. And how is that going to help our organization after evaluating all trade offs. So you see as a security architect these deep fundamentals are going to help you to because you're not going to be focused on shiny tools. You're going to be protecting organization organizations and keeping them safe. Now let's talk about deep fundamentals being your protection against AI for any technology profession on the cloud. Architects, enterprise architects and security architects tend to be immune from AI related layoffs because the stakeholder management, the leadership and the people work that we do. But still, let's stay way ahead of the curve and your fundamentals help you stay better than AI. And here's the reason AI is pretty good. And a lot of things can generate config because it can explain par concepts. It can help you write a policy, summarize a log, and give you a lot of options very fast. But here's what I can't do. It can't give you sound judgment under uncertainty. And the reality is, when we have real heavy duty engineering or any kind of heavy duty cloud architecture. Enterprise architect your security architecture. Most of the time the information we have is incomplete. The logs may not be telling the whole story. We've got teams that are disagreeing with each other. The right answer isn't going to be based upon any technology. It's on risk tolerance, budget, timelines, customer impact. So other things. And when you have to make a decision to be accountable for it, those deep fundamentals are going to help you problem solve in a huge way. And they make you better than AI. So they keep you safe and they keep getting promoted and they keep it from getting replaced in any way, shape or form by AI. So I really want to talk about challenging and unexpected sort of environments. So I remember at one point in my life I worked in the ER, prior to that I was a paramedic. And when you're in challenging environments, you have to be really good at what you do because things get really hard. So here's the harsh truth. A lot of people look smart when things are easy, when there's a playbook that covers it, when the problem is familiar, when the system is stable, lots of people look great in those times. But what happens when they're not? And that's where the fundamentals are going to matter so much, because ask you away to go from a big, vague problem and narrow it down to know exactly what it is to be able to generate a hypothesis. Okay, it could be the network is a network latency. Let's test it. No, it's not letting network latency is it network throughput. Okay, let's test it. Is it the CPU? the Dram on the server. Is the performance of the block story to an issue. Let's test it

so we can create strategic hypotheses and then test them in the same way a McKinsey consultant we create mutually exclusive, collectively exhaustive hypotheses. But you've got to have good fundamentals to do that. And that also gives us a way to communicate when everyone else is spiraling around. And this is where careers are made in the hard times, not on the perfect day when things get tough and you are there to save it. So fundamentals are how you understand changes in the system. So if you make this change, what's the impact on another part of the system? And modern systems are complex. And that kind of complexity means if you make a change here, it can easily impact so many other things and create big effect. So you have the ability when you've got good fundamentals to plan it. What happens if this route changes? For example, what happens if you change an IAM permission? What happens when you add a new dependency. And your fundamentals will enable you to figure that out? I like what they said in RFC 925. It's a really funny RFC. You can find it on the internet engineering test for us on our web page if you want to read it. And they basically say it's more complicated than you think. And that's not pessimism. It's reality. When we get big, when we get it. So let's scale deep fundamentals will help you predict changes and how they ripple through the system. They'll help you understand what happens when you connect things. They'll help you see where the bottlenecks are going to form, and they will help you design for failure instead of hoping for success. So I really want you to truly focus on developing deep fundamental. So it's going to get you closer. So I don't want you to feel overwhelmed in the need to develop deep fundamentals. You just need a consistent loop. Pick one fundamental I don't care what is. Maybe it's BGP. If you're a networking person, learn the concepts, apply it to whatever you're designing right now, or think about it, explain it to someone else and that will reinforce your fundamentals. But make sure you understand it before you explain it. And those fundamentals, when they're part of you, it's something that you'll have for ever. So maybe make it a fun challenge. Once a week, read something foundational an old paper and Internet Engineering Task Force RFC. See a modern guide on various components of architecture. And that's basically how you're training to be better. We're training pattern recognition. We're training to be more adaptable. So if you take nothing else from this video, deep fundamentals are probably your most transferable skill in tech because technology rarely reinvent itself is generally ships new versions of old ideas, just like in RFC 29. Now I want to hear from you. Tell me what the one fundamental use skill you want to work in the comment section? Is it networking? Is identity and access management, is it network security? Is it security fundamentals? Distributed system observability? Then ops tell me the one set of fundamental things that you want to learn. And the chatbox I'd like to hear from you if you also if you're enjoying this video please give it a like subscribe to our channel and hit the bell to be notified of new videos to assist you in your architecture career. And I have a free bonus for you! Twice per week we run an architecture webinar where we'll go over what we do as architects. The skills you need as an architect, how to become an architect, and everything that you should do to go from wherever you're at. I mean wherever you're at your first architect job, whether that be a cloud architect, security architect, AI architect or enterprise architect. And you can register for those free architecture webinars. The link is in the description of this video. Also video are guides on how to become saying artificial intelligent architect or how to become a cloud architect or other things. How to win on the interview, for example for an architect role. So please stop by the description of this video, download some free things and hope to see you in a webinar. So this is Mike Gibbs signing off for now, and I hope to see you in another webinar or another YouTube video. Take care.