Infrastructure with AI Agents for Dummies Transcript, AI Summary & Key Points

00:23 AI agents are amplifiers. If you're good at your job, agents make you better. you do more great things faster. But if you're bad at what you're doing, agents amplify that as well. You used to cause a slow trickle of Now you have means to unleash a fullblown storm at scale in minutes. Now AI is all the rage these days and for a good reason. So of course people are using agents to manage real resources, infrastructure, databases, applications, all of it, right?

00:57 The question is what happens when they do? That's what we're looking at today. An agent managing actual cloud resources. What goes wrong? Why it goes wrong? And what it takes to make it work properly. We'll take a quick break for me to introduce you to Corsera, the sponsor of this video. So, here's something most of us run into. The stock keeps moving.

01:20 New tools, new platforms, new AI capabilities every month, week, day, even. Staying competitive isn't a one-time effort anymore. It continues. And the people who keep their skills sharp are the ones who get the interesting work. That's where Corsera Plus comes in. It's a single subscription that gives you unlimited access to over 10,000 courses, professional certificates, and specializations from universities and companies you already know.

01:47 Google, IBM, Microsoft, Meta, and many, many, many more. The content comes from the same companies actually building the technology. For folks watching this channel, there's a lot to dig into. Google Cloud and IBM have full certification tracks. Deep learning AI has solid material on machine learning and generative AI. There are professional certificates for DevOps, cyber security, and data engineering.

02:12 Pick a pat and jump across them. One subscription, thousands of options, your own pace. Right now, Corsera Plus is 40% off for 3 months using the link in the description. If you've been meaning to upgrade your skill set, this is a good time. Invest in yourself. Big thanks to Corsera for sponsoring this video. And now, let's get back to the main subject.

02:34 Imagine this. Someone needs a database. Maybe it's for an app they're working on. Maybe someone just told them to set one up. They have an AI agent at their fingertips. So, they do the obvious thing, the most obvious thing. They ask for a database. So, let's see what happens. I'm using open code as the agent today, but it could just as well be cloud code or Gemini CLI or Codex or whichever agent you prefer.

02:57 Doesn't matter, right? The story is the same. The agent right now in my case is in plan mode. So instead of immediately executing whatever comes to its mind, it will propose a plan first. The prompt is as simple as it gets. Now the agent did not run off and create something random. It stopped and asked which GCP database we actually want. CloudSQL posgressql cloud SQL MySQL alloy DB fire store spanninner each option comes with a oneline description which is helpful but a oneliner is hardly the basis for a decision like

03:33 that and then it works a bit more and then it asked about environment sizing once it got the answers it laid out the steps it plans to perform and listed the values it still needs from us from me before execution. Now pause here for a moment because those questions reveal the real problem. You need to understand GCP in this case or whichever platform you're using.

03:56 You need to understand it. There is no way around it. The agent will ask questions and you need to answer them. If you don't know whether you need Cloud SQL or Spanner or whether exposing a database through a public IP is a good idea, you're stuck. You cannot answer what you don't understand. You can't. But wait, it it gets worse. AI will not, and I repeat, will not ask you everything that should be asked.

04:18 It often dumps things down to a handful of multiple choice questions. And that's okay if you're a dummy, right? But if that's the case, if you're a dummy, you should not be managing anything, nothing. On top of that, you need to understand how agents themselves work so you don't get fooled by them. It's the same as with technical managers, right? If you don't know what to ask your team, you might just as well not ask them anything.

04:45 You'll just nod that whatever they say and they will do whatever they want. So let me answer right answer the way an inexperienced person would put it in a new project. Make it public because hey that's convenient and accept whatever the agent suggested for everything else. And then it works. It works. It works. And there we go. The agent came back with the final plan.

05:05 dev sizing, lowest cost tier, high availability disabled, and public access open to all networks. Now, to its credit, it even flagged the risk that 0000 makes the database reachable from the public internet and that is not recommended for production because it's silly. But hey, a warning is only useful if the person reading it understands the consequences.

05:31 I don't. I'm a dummy or or at least I'm pretending to be one. or maybe I'm not pretending. I'm not sure. There we go. So, the plan looked fine to someone who doesn't know better. So, we switched to I switch to build mode. The mode where the agent stops proposing and starts executing and gave it the prompt that does all the damage. All the damage in this story.

05:54 There we go. It works. It works. Some 15 minutes later, it's done. The agent ran a bunch of G-Cloud commands, hit a few issues along the way, fixed them itself, and ended up with a working database. There's the user password, the public IP, and readym made PSQL command to connect to it. Amazing. And it can be connected from anywhere by anyone, anyone who gets at least anyone who gets hold of that string.

06:21 Now, notice what the agent used to do all of that. It used trickcloud. Why? because it happened to be on my machine. That's it. That's the whole reason. You need to know which tools you need and you cannot let AI make that decision for you based on whatever it finds laying around. So, let me be blunt over there. You should get fired for even contemplating the option to manage infrastructure with G-Cloud.

06:50 It's everything is code now. If you do that and you do not get fired. If you don't get fired after doing that, you should quit because that's not the company you want to be in. The only thing worse than using CLIs to manage resources is clicking buttons in a web console. And for that one, getting fired is not enough. It's not enough. That calls for ritual suicide.

07:12 Besides, what we got is only a fraction of what's needed for running a database. Is there an actual database inside that server? Well, I don't know. Are there schemas? Is it highly available? We don't know. Or and we didn't ask, right? We just did stuff. And that over there, that's a shame because asking is the only thing AI is genuinely great at enabling.

07:36 Ask why, ask how, all the time. And an agent becomes a phenomenal teacher. That's not what I did. I I just said, "Hey, just do it." And here's what makes that dangerous. Nothing visibly failed. Nothing. The database works. Apps can connect to it. And then inexperienced person looks at that and sees success. That's exactly the problem. It works. Hides everything that is wrong underneath all that.

08:07 A is not an excuse for not knowing things. So here's the only reasonable only reasonable thing left to do. You it up and it's my fault for not knowing what I'm doing. Destroy everything you created. Destroy it all. The plan to clean up is simple. Delete the whole GCP project and remove the local temp files where the agents stash the generated password.

08:28 Yes, the database password lived in temp files on my laptop this whole time. Amazing, right? That's one more thing I pretended I don't know about and real people doing real job actually don't know about. So one more switch to build mode and then do it and everything is gone. So if letting an agent lose with whatever CLI it finds on the machine is a firing offense, what should it use instead?

08:54 And the answer is clear, right? Infrastructure is code. But which tool? That's next. So which tool should we use? Should it use instead? Let's let's go through the options. Right? There is to begin with anible and the like similar tools, right? Don't even think about it. Tools like that were built for a different era back when we managed our own servers by hand in our own data centers on technology that's now two decades old.

09:27 The rest of the world switched to API based management a long time ago. If you somehow did not get that memo, it's fine. You got plausible denability and you can keep telling yourself that is still a good idea. everyone else should erase it from memory. Then we have tools like Terraform and similar ones right now. Those are genuinely amazing tools. They paved the way and pretty much buried unsele style configuration management.

09:54 Think of them as the second generation focused on APIs and immutability instead of mutating servers in place. The trouble is that we are now in the third generation where resource management is API based and the only APIs that really matter. The only ones that matter are the ones coming from Kubernetes with Kubernetes acting as the control plane. So that's where Kubernetes native resource management comes in.

10:19 Any tool that treats Kubernetes as the control plane for your infrastructure is a better choice today. So why Kubernetes native in the first place? Well, Kubernetes does not just create a resource and walk away the way a oneoff apply does. It continuously reconciles, watching the actual state, comparing it to what you asked for and correcting any drift, any drift on its own over and over and over and over forever.

10:48 You also get a single consistent API surface for everything. Real role-based access control and a huge ecosystem that already speaks that same language massive ecosystem. So which one do we use? There are several good options like crossplane, crow, cluster API, cubea and a few others. Now we're going to use crossplane. And you might be asking, hey, why cross lane and not crow qlla or cluster API?

11:13 Well, honestly, they're all reasonable, all good, but Crossplane just happens to be the most mature of the bunch with the widest adoption and the broadest coverage of cloud resources. It's awesome. I love it. It's a project I work on. That's it, right? We'll use crossplane. You can use any other if if you don't like crossplane for some unknown reason.

11:34 The point is that you use Kubernetes to manage resources. So, that's why we'll use crossplane. Here's roughly quickly how it works, right? You hand Kubernetes the desired state. A handful of manifests describing the resources you want. Those land in the control plane cluster where crossplane runs right alongside Kubernetes API. Each manifest becomes a managed resource or MR a Kubernetes object that maps one to one to real resource out at wherever whichever cloud provider you're using.

12:06 Things like a database instance, a database, a user, right? Anything you want. Crossline reconciles each of those MRS against the provider's API and creates the actual resources and then it keeps reconciling forever and ever and ever so that if anything drifts away from what you declared it gets pulled right back. So let's give the agent the exact same task as before.

12:29 Create a database in GCP but with one crucial addition. We tell it to use crossplane MRS. Same goal, completely different tool underneath. And then it works. It works. It works. And just like before, since we are in plain mode, the agent comes back with a round of questions before it touches anything. I will just answer the questions, right? Right. Fast forward.

12:50 Switch over to build mode and let it rip. Let it run. And this takes time, probably 10 10ish minutes. Anyways, let's fast forward. And there we go. It's done. We get the connection details, the project, the region, the instance, the database, the user, and the public IP. Brilliant. Now, before we get too excited, notice what did not change. We still had to answer questions about GCP, and the agent still didn't ask everything that should have been asked.

13:18 Switching from G-Cloud to crossplane fixed the tool but at this level working directly with draw manage resources it did not remove the need for you to actually understand cloud underneath. Now hold that thought because that's precisely the problem internal developer platforms are built to solve by they're narrowing the surface down to what people actually need and what people are comfortable with.

13:44 So we'll get there. For now, let's see what it actually built. So, back in plan mode, I ask it to output the resources it created. And there it is. Instead of a pile of imperative G-Cloud commands, everything is now a set of crossplane manage resources, real Kubernetes objects describing the database instance, the database, and the user plus a Kubernetes secret holding the autogenerated password.

14:08 This is the difference that matters. It's all declarative. It all lives in the cluster, and it can all be reconciled. Now, here's the thing, though. There's so much more to running a database than a handful of managed resources. If you don't know what all of that involves, chances are plenty of other people don't either. And even if you do know, the next person might not.

14:33 And even if everyone knows, it's still mindnumbingly tedious to assemble the same pile of resources into a working solution over and over and over again, every single time. So that's the queue. That's where an internal developer platform swoops in. So this is not it, right? So let me give a appropriate message to AI. You it up and it's my fault for not knowing what I'm doing.

15:00 Destroy everything you created. Now you will notice how much cleaner the cleanup is. Now because everything is Kubernetes resource, the plan is just a handful of cube control deletes for the instance, the database, the user and the secret plus removing the local manifest file. The agent even has the sense to leave cross provider and credentials alone since he did not create those.

15:21 Now compare that to chasing down whatever G-Cloud scattered around last time, right? And that's only assuming that you're in the same session of AI. If you're not, oh my god, you're lost. You're done. you'll never remove all the resources. So, one more switch to build mode. One more do it and it's all gone. Done. So, crossplane gets us off CLIs and onto proper declarative reconciled foundation, but we are still wiring up Rome managed resources by hand one at a time.

15:51 The real payoff comes when we package all of that into something other people can use without knowing any of it. That's what we'll build next. So what is an internal developer platform you might ask right? Think of it this way. Somewhere somewhere in your organization there are people who actually know what running a database a cluster an application or any other type of resource really means the user the schemas the backups the networking all of it.

16:21 Internal developer platform is how those people package that knowledge into readymade services that everyone else can consume without knowing or caring uh or caring what's inside. What's below all that? Instead of every person assembling piles of low-level resources and answering questions they're not equipped to answer, they get one simple interface that exposes only what they actually need.

16:43 And that over there brings us to cross compositions. A composition is in essence a recipe. someone there must be someone who knows what they're doing and that someone defines one time what is a database right what does that mean in your organization which resources it expands into and which uh defaults it provides and uh which other things it needs to do and it exposes all of that as a new simple Kubernetes API new API and since it's all Kubernetes native you keep every benefit we talked about earlier real APIs, drift

17:21 detection, continuous reconciliation, access control, the whole package. That's exactly the mechanism an internal developer platform needs. So here we go. You create one small resource that says, "Hey, I want the posgusql database." That resource called a composite resource or XR and then and it lands in the control plane cluster where the composition picks it up and expands it into all the underlying managed resources.

17:47 the database instance, the user, the database itself, the schema, and whatever else your platform team decided a proper database setup should include. From there, it's the same story as before. Everything reconciles against the cloud provider continuously forever and ever and ever and ever and ever. So, let's see it in action. Same ask before, but this time we pointed the agent at the composition that's already in the control plane cluster.

18:13 Now, while we watch it work, it reveals one of the big advantages of doing this through Kubernetes. The APIs are discoverable. The agent poked around the cluster and figured out by itself which compositions exist, what their schemas look like, what can be done, and how. We did not have to feed it files, dogs, and anything else. Now, that said, this would be even better with a custom agent or skills or MCP or something like that.

18:43 those would already know that resources are managed through crossline compositions and which Kubernetes API match the intent. So we wouldn't need to spell any of that out in the prompt. So it would be one sentence instead of two sentences. Not a big deal though. Okay, there we go. Now once it figured it out, look at the plan. It boils down to a handful of simple values like a name, a region, version size.

19:06 Now compare that to the interrogation we went through with draw manage resources. That's the whole point of the simplified interface. Users see only the things that actually matter to them while everything else everything else the company policies the security decisions the best practices all that is already implemented inside the composition by the people who know what they're doing.

19:29 Now remember asking questions is the thing AI is generally great at enabling. So let's use it. Uh let's see what else could we have tweaked. Then it works works works and there we go. Among other things, the answer reveals that the database we're creating is not even tied to a single provider. There are compositions for GCP, AWS, Azure, and even a local one.

19:50 The same simple interface, multiple implementations, all sitting in the same control plane ready to be used. Okay, now that we know what the composition offers, we can be more specific about what we want. And there we go. The agent translates all of that into the resource, including a sample schema, and asks for a couple of confirmations before it executes anything.

20:07 Now, here's an important note before we let it loose. Ideally, most people should have right access. Right access only and exclusively to those composite resources, the simple highlevel ones like these database and nothing else, nothing else in the control plane cluster, no row manage resources, no cluster internals and certainly certainly no direct access to the destinations themselves.

20:31 Doesn't matter whether it's AWG, GCP, Azure or your own data center. Just a curated interface the platform team built for them. And there we go. Time to execute. We switch to build mode and give it a green light. And then it works, works, works. And a while later, everything is up. The composite resource and everything is spawned is synced and ready.

20:53 The instance, the user, the databases, and even the schema. The agent also explains the choices it made along the way like patching the instance tier when GCP rejected the composition's default for the posgusql version we picked which is probably latest doesn't matter. So let's get the full picture of what we ended up with. Now by now I got tired of the whole plan and build plan and build dance.

21:17 So this time I'll just fire away without switching to plan mode first. You know I'm living on the edge. I'm living dangerously. It's stupid of me. I recognize that. But hey, dummy is what dummy does. So here we go again. You it up and it's my fault for not knowing what I'm doing. When I say you, I mean agent and me is me. Nevertheless, destroy everything you created.

21:38 Okay, now there is confession time. I was lying earlier. I was I was lying when I said that ideally most people should have right access to only composite resources and nothing else in the control plane cluster. Nothing else. Most people should not have right access at all. No, no access, not needed. Direct access to the control plane should be reserved for break glass scenarios.

22:01 You know those moments when everything else has failed and someone has to step in manually only then. So how do changes get in? Well through git, right? You should still get fired for thinking you can be a software engineer without knowing that everything we do must be stored in it. That stays. So let's do githubs. That's next. Now very briefly because most of you already know what is gith but let's repeat just in case right it boils down to four principles.

22:31 First you have a declarative desire state. You describe what you want not the steps how to get there. Second the desired state is stored in a way that is versioned and immutable and that's exactly what gives us. Third desired state is pulled automatically. Nobody pushes changes to the system. Nobody. And fourth, the actual state is continuously reconciled with the desired one exactly exactly like we saw crossplane does except now the desired state lives in git.

23:00 Here's what that looks like in our case. You, me, your agent, whatever pushes manifests to a git repository. That's the desired state and that's the only only only entry point. Argo CD running in the control plane cluster pulls that desired state from the repo and applies it from there. where the chain we already know uh kicks in the composite resource the composition and the manage resources it expands into and the cloud provider ends up with the real resources continuously reconciled at every step along the way

23:32 nobody nobody touches the cluster directly anymore is the interface so let's make it happen let's do it right I'm asking the agent to create a public report generate manifest for the resources we created earlier push them there and configure Argo CD to sync it all I happen to use Argo CD today, right? But Flux or any other GOS tool would do just as well.

23:54 Actually, there is only Flux and Argo CD. Everything else is is just stupid. Don't use it. Right? So, Flux, Argo CD, whichever you want. Now, what really matters is that you do GitHubs, not which tool pulls the changes. And there we go. It works. It works. And sometime later, probably 10 to 15 minutes, something like that, it's done. The repo exists.

24:16 The manifests are in it. Argo City is syncing and the database is up. The summary calls out the secrets explicitly. And here's the beauty of it of what we did. From now on, this is the whole workflow. Push an updated manifest to the repo and that's it. Argo CD picks it up or plugs syncs it and everything downstream, reconciles on its own. No cube control, no cloud consoles, no direct access to anything.

24:42 So, let's do it one last time. Last time, I promise. Let's ask for the complete picture. Let's see what we got. And there we go. The list goes all the way down. The Argo CD application, the composite resource, the manage resources, the uh and even even the temporary helper database that Atlas spins up just to plan schema changes. Every single piece is accounted for, explained, and from now on managed from Git.

25:07 And that's the full journey. That's where we are today. We'll see where we'll be tomorrow with AI, but today that's where we are. At least when managing resources is concerned. We started with an agent blindly running G-Cloud commands it found on my laptop. That was horrible. And uh we ended up with a setup where the only thing anyone human ari can do is push declarative manifests to get that's the end result right while Argo CD crossplane and the composition take care of everything else.

25:38 What we did did not did not and I repeat did not remove the need to know what you're doing. You have to know what you're doing. It's not helping with that. It amplifies. It amplifies you. The difference between a storm and a great setup is still you. So don't please please please don't use agents to hide what you don't know. Use them to learn it. Ask why?

26:01 Why? Why? Why? Why? Why? At every single step. And the same agent that would happily build a disaster becomes the best teacher you've ever had. And once you know what you're doing, once you learn how to do things, then it does a great job. Thank you for watching. See you in the next one. Cheers.