[00:02] devops engineer. Your first task is to set up a web application on AWS. The application needs a server to run on and database to store data and storage for user uploaded files. So you open the AWS console and start clicking. You launch
[00:18] an EC2 instance, click click, configure, create an RDS database, click through the settings, you set up an S3 bucket, so more clicking, and it works. The application is running, you feel great. But then your manager says, "Now you
[00:34] need to do exact same setup for our staging environment." So you open the AWS console again and start clicking. Launch another EC2 instance, but here you have to pause because you think, "Wait, what size did I use last time?"
[00:48] Then you have to create another database, and you think, "What password did I set for this database?" Another S3 bucket. "What permissions did I configure for the first S3 bucket?" you realize that you don't remember exactly
[01:02] what you did because there are thousands of details in the configuration. And even if you wrote it down and documented it, recreating everything by clicking is tedious and very error-prone. So this is when you start wondering, "There has to
[01:17] be a better way, right?" And there is. Actually, there are several ways. And most engineers think there are just two approaches: the old way where you click through the console and the new way where you use tools like Terraform. But
[01:30] that's like saying there are just two ways to get somewhere, either walking or teleportation. There's actually a whole journey in between. So in this video, I want to show you the four stages of infrastructure management. Each stage
[01:43] solves problems from the previous stage, and understanding where you are on this journey will change your perspective about what you should learn next. So about what you should learn next. So let's start at the beginning.
[01:59] infrastructure through the AWS console. Everything is done by clicking through the web interface. You need to launch an EC2 instance, you just click through the launch wizard, choose the instance type, configure the network, add storage, set
[02:12] up security groups, and so on. You need an S3 bucket, just click create bucket, fill in the name, set the permissions, configure encryption, leave the rest of the defaults, and there you go. And honestly, that actually works. And it's
[02:26] very easy to start here. You can see everything visually, you can explore the options, it feels very tangible and understandable. And this is why this stage is actually important. You need to actually understand the basic concepts
[02:42] of cloud infrastructure before you start automating it. So, you need to understand what VPC is before you provision it automatically. You need to see how security group rules actually work visually, which ports you're
[02:56] opening, what IP ranges you're allowing, before you can write them in code. So, the console actually teaches you what AWS resources exist and how they connect to each other. When you're launching an EC2 instance through the console, you
[03:11] see the relationship between the VPC it needs to be in, the subnet within that VPC, the security group that controls traffic, the key pair for SSH access to your instance, the IAM role that it might need. So, you're learning all
[03:25] these basic building blocks and round the EC2 instance that you're creating. And this is valuable, but pretty quickly, you start hitting problems. First of all, it's not repeatable. You set up a production environment, now you
[03:38] need staging. You have to click through everything again, trying to remember what you did in which order exactly. Second, it's not documented. So, six months later, when someone asks, "Why did we configure the security group this
[03:51] way?" you don't remember. Nobody remembers. There's no record. Also, it's very human error prone. When you're setting up the 10th server, you're tired, you accidentally choose the wrong security group, you forget to close a
[04:05] port, open another one, the server cannot connect to the database, debugging takes hours, so very high chance of human error here. And finally, it doesn't scale. If you need to launch 20 servers, are you going to click
[04:18] through that wizard 20 times? That is super inefficient. So, you start looking for a better way, and you discover the AWS CLI and Python scripts.
[04:31] So, welcome to stage two. You discover that you can control AWS through code. And now that you understand those basic concepts and building blocks, you don't need to visually see them all the time. So, instead of clicking, you start
[04:44] writing scripts, like a Python script, cuz Python has a library for AWS to connect with AWS and basically do anything that you can do in the console programmatically, or connect to any other cloud provider. So, you start
[04:57] controlling, creating, configuring everything via scripts. And this is a game-changer, because now you can repeat things. You save your script, just run which is identical. You can share the script with your team. It also acts as a
[05:11] documentation, and you can modify it for different scenarios. And this stage is powerful, because it gives you automation. Tasks that maybe took you 30 minutes of clicking, now take just 30 seconds. And you can add logic to your
[05:25] scripts. You can check if a resource already exists before creating it. You can look through a list to create multiple resources, or handle errors gracefully. You can also chain multiple operations to create more complex
[05:38] workflows. For example, you can say, "Launch an EC2 instance, wait for it to be up and running fully, get its IP address, update your DNS records, configure monitoring, and so on. Now, try doing all that through the console
[05:53] automating everything with Python scripts. Everything looks great, but you quickly learn that scripts are great for automation, but terrible for state management. Let me explain what I mean.
[06:06] You write a script that creates an EC2 instance. You run it, great, you have a server. The next day, you run the same script again. Maybe you forgot you testing something, some configuration change. Now, you have two servers. So,
[06:20] which one is the real one? You're debugging your script, so you run it Congratulations, you just launched five servers, and you're not even sure which ones are supposed to exist. So, the script does not know what infrastructure
[06:34] already exists, unless you explicitly check it. It just executes commands. resources. So, you end up writing a lot of code to check, "Does this resource exist? If yes, don't create it. If no, create it." And you would have to do
[06:48] this with every single resource. And this gets complicated really fast. But here's another problem, deletion. Let's say you created 10 resources with your script. Now, you want to tear everything down, delete the whole stack. You need
[07:01] separate scripts to delete everything in the right order. If you miss one resource, you're paying for something that you forgot existed. Or if you delete things in the wrong order, it may mess up your entire infrastructure. And
[07:14] finally, these scripts also do not handle updates well. Let's say you have a server running, you want to change its instance type. Your script only knows how to create servers, but it's not really good at modifying them. So,
[07:27] you're automating, but you're not really managing infrastructure. You're just clicking faster through code, basically. So, this is when you realize you need something that understands the current state of your infrastructure and can
[07:40] manage changes intelligently. And that's where infrastructure as code tools like where infrastructure as code tools like Terraform come in. infrastructure as code. With Terraform, you completely change how you think
[07:56] about infrastructure. Instead of writing imperative scripts that say, "Do this, then do that. If resource exists, don't create it. If it doesn't exist, then create it." Instead of these imperative commands, you write declarative
[08:11] configuration that says, "This is what I want to exist." So, basically, instead of giving the script a step-by-step execution steps of what it needs to do, you say, "This is what I want as a final
[08:23] result. You figure out the steps behind to get me this result." So, that's how Terraform works compared to Python script, for example. So, here's what the same EC2 instance looks like in Terraform compared to Python script, for
[08:37] example. You're not saying, "Create this instance." You're saying, "This is a definition of a resource that I want you to create. It's an EC2 instance with these properties." And after I execute this, this thing should exist. And
[08:51] here's where it gets interesting. When you run Terraform the first time, Terraform sees in your code configuration that you want an instance. configuration that you want an instance. Then it goes to AWS and it checks, "Does
[09:04] this instance already exist in AWS infrastructure or not?" And it sees it doesn't exist. So, Terraform creates it. Now, you run Terraform the second time, anything. Terraform sees you want an instance. Again, the code hasn't
[09:19] changed. It goes and checks, "Does it already exist?" Yes, Terraform does nothing. Then you go and change the instance type of the same instance to T2 instance type. Again, Terraform checks the code, "Oh, this is what you want."
[09:35] Then it goes and compares what is a type of the instance that already exists. It's T2 micro, but you want T2 small. Great, let me handle this. So, it updates the existing instance with that one property. Finally, you delete the
[09:51] configuration. You basically just select the entire code and you just delete it. Terraform sees you don't want any instance. It goes to AWS and sees but there is an instance in the infrastructure, but your code says you
[10:04] don't want any. Perfect, it just deletes it to match your desired configuration. And this is state management. And Terraform does it very easily actually by just maintaining a simple state file that tracks what infrastructure exists
[10:19] at any moment and comparing it to what's in the code. So, every time you run Terraform, it reads your configuration, the Terraform code that's tells it what you want, it reads the current state, what exists, compares them, shows you a
[10:33] plan of what will change after the execution. So, you confirm that you want this change to happen and makes only the necessary changes to give you that new desired state. And this now changes everything because your infrastructure
[10:48] suddenly becomes repeatable, means the same Terraform code produces the exact same infrastructure every time, no matter how many times you run the script. And you can create identical staging, production, development
[11:02] environments from the same code with single command execution. Now, usually you have some values or some variables that are different across those environments, even though the resources are the same. So, Terraform actually
[11:16] gives you a way to parameterize your code and pass those different variable values if you need to for different environments. Your infrastructure also becomes reviewable and this is very important. Infrastructure changes go
[11:30] application code, because your entire infrastructure is now written as code. So, your teammate can see, "Wait, you're opening port 22 to the entire internet? That is a security risk." And you can fix these issues before applying the
[11:45] changes. Your infrastructure also becomes versionable. I don't know if this is a real word, but your infrastructure basically lives in Git, which allows your infrastructure code to be versioned just like your application
[12:00] code. So, you can see entire history of changes, who made what change and when. version if you need to, and it's automatically documented without you having to create some text document, because the code is the documentation.
[12:14] If you want to know how production is configured, you just read the Terraform everything looks great with our Terraform configuration, but even with Terraform, problems still exist. First of all, manual execution. You still have
[12:28] to remember to run Terraform. Someone needs to notice a change was merged to Git and manually apply it, so that the actual infrastructure gets updated, right? Someone needs to run Terraform apply command from terminal to make the
[12:42] changes. Problem number two is, in parallel to Terraform code making changes to AWS infrastructure, you still have manual changes made to the infrastructure. So, someone goes into AWS console and manually changes
[12:55] something, because maybe they were debugging some issues, so they need to fix something quickly. Or maybe there was an emergency fix, so they just wanted to quickly patch and fix some issue, and they just took the fastest
[13:09] route by doing it directly in AWS. And when that happens, it actually breaks a lot of things, because now your Terraform state does not match the actual state or the reality. And if nobody executes Terraform run after
[13:22] these manual changes, then nobody even notices there was this change for months. And then something breaks, you realize that your infrastructure drifted from your code. And there is official name for this as well, called
[13:35] configuration drift. Another issue that you have with Terraform is state file management. The state file needs to be stored somewhere everyone can access. Usually, S3 bucket is used to store that file because if you have it locally on
[13:49] your computer, what happens if another engineer wants to run Terraform script up-to-date state file that you have, right? So you need to set up locking so
[14:01] simultaneously and corrupt the state. And finally, there is an issue of coordination because multiple team members working on infrastructure need to coordinate who's applying the changes in what order. What if two people are
[14:14] working on different parts or the same parts of the code? And these problems are all soluble, obviously, but they need operational overhead. And they all point to the same fundamental issue, which is Terraform is still a tool you
[14:28] manually run. But what if instead the infrastructure automatically stayed in sync with your code? What if manual changes were automatically reverted? And automatically when Terraform code
[14:43] changes was merged in Git repository? Do we have a concept for that? That could actually solve most of these problems, right? Well, that's exactly where the final stage comes in, which is called GitOps.
[14:56] So with GitOps, you fundamentally change how infrastructure changes are deployed. So Terraform solves the problems of how infrastructure creation, deletion, and modification is automated. On top of that, now we have this layer that
[15:11] actually manages how those changes are deployed and enforcing a team workflow where there's no configuration drift, nobody manually intervenes, and so on. And that's what GitOps does. So, instead of manually running Terraform, you
[15:25] basically set up an automated system that watches your Git repository. It detects whenever infrastructure code changes in the repository. And whenever it does, it automatically fetches those changes and applies those in the
[15:39] continuously ensures that reality matches what's in Git. So, let me give you specific examples. Let's say you're using a tool like Argo CD, which was originally built for Kubernetes, but the
[15:52] pattern applies to infrastructure as well. And you have a Git repository with all your Terraform code. And you configure Argo CD to watch this Step one, you need to change infrastructure. Maybe you want to add a
[16:05] new server. So, someone on the team edits Terraform code in their local Git clone, right? So, locally on their laptop, they make the changes. And once they're done, they open a pull request. Your team reviews it and says, "Looks
[16:18] configuration, so we can actually apply it." And to confirm that the PR is merged to the main branch. As soon as this happens, Argo CD detects that there was a change or new commit in the branch. It automatically runs Terraform
[16:33] plan to see what will change. It applies the changes, and your new server is created. So, nobody has to run manual commands to apply the changes. You just merge to Git, and the rest was done automatically. But here is the really
[16:48] powerful part of GitOps, which is the continuous sync. Every few minutes, Argo CD would check, "Does the actual infrastructure match what's in Git?" So, let's say someone goes into AWS console and manually changes a security group
[17:04] configuration. Maybe they're debugging or testing something. Argo CD detects, "Wait, the security group in AWS does not match what's in Git." So, it automatically reverts the manual change back to what Git says. In this way, it
[17:19] back to what Git says. In this way, it enforces that no manual changes persist and that whatever it naturally means that Git repository becomes the single source of truth. If it's not in Git, it will not exist. If someone makes a
[17:33] manual change, it gets reverted to what's in Git. So, think about what problems now disappear with GitOps. If you want to ask who deployed this the commit history. Why is staging
[17:45] Well, they're both deployed from the same Git repository with different variable files. So, if they're different, the difference is visible in Git. Someone made a manual change and now things don't work. Can't happen
[17:57] reverted. We need to roll back to yesterday's infrastructure. Just revert the Git commit, the automated system deploys the previous version. I'm Well, system applies it automatically after the code review. So, you can run
[18:11] all the tests and make the checks within the pull request before it gets merged and deployed to the infrastructure. So, this is an ideal infrastructure state that you want to work towards. But, there is a stage after GitOps that we're
[18:27] going to see become more and more prevalent in the future because of AI. So, this is stage five of what I call an AI-assisted infrastructure that directly
[18:40] layers on top of infrastructure as code and GitOps to make it even more efficient. So, where does AI fit into this whole thing? Well, even with GitOps, you're still doing few things manually, which is writing all the
[18:54] changes yourself, debugging configuration issues, and those are exactly the things that you can now automate or enhance with AI. So, let's go back to our initial scenario where you need to set up that web application,
[19:08] server, database, storage, and and on. With GitOps, you would still need to write Terraform code for the EC2 instance, configuring the RDS database with all its settings, or set up the S3 bucket with proper permissions, right?
[19:22] Create security groups with the right rules, and so on. And this requires deep AWS knowledge cuz you need to understand those concepts to be able to write it in Terraform. You need to know which instance type to choose, what database
[19:34] engine settings to configure, how to structure security groups correctly, and you need to go and make sure you have the up-to-date Terraform syntax to define the desired infrastructure because things do change, and AI is
[19:49] exceptionally good at writing code. So, instead of searching for the right syntax and configuration to create your desired infrastructure configuration in Terraform, you basically go to AI or use an AI-native
[20:03] code editors like Cursor, and you just type in natural language, "I need a web application setup with auto scaling between two and 10 instances, a PostgreSQL database with read replicas, and an S3 bucket for user uploads with
[20:18] proper security." And AI generates the Terraform code for you. It creates an configuration, an application load balancer, the database with read replicas in multiple availability zones, S3 bucket with encryption and
[20:33] appropriate access policies, security groups with least privilege rules, and then you, as an experienced engineer, you review the generated code to make sure it's correct, adjust anything specific to your needs, and now you have
[20:46] code ready for your use case within minutes instead of maybe hours. You can also create AI automation for code reviews, right? Whenever a junior engineer commits something to a Git repository, you can have AI review the
[21:01] code and detect any security issues or any configuration issues, and so on. So, AI can actually catch issues before your teammates even look at the code. It will know the AWS best practices, security guidelines, cost optimization patterns.
[21:15] So, for example, it may flag configuration and say, "This RDS instance is in public subnet, but best practice to put databases in private subnets. So, please change that." Or you're using T3.large
[21:27] for this workload. Based on typical usage patterns, T3.medium would be sufficient and save you another $30 per month. And in addition to that, you can actually use AI to continuously monitor your infrastructure resources while they
[21:41] are deployed, which is actually a completely new addition to your Because traditionally, you would just deploy resources with Terraform or GitOps, and they just stay there until you manually review and optimize and
[21:57] decide, "Are we creating resources that we're not fully using and paying a lot even need?" So, you can create AI automation that continuously analyzes your infrastructure and tells you, "Hey, your production database is using uh 40%
[22:11] CPU on average, and you're paying for a large database instance, but medium would be sufficient to handle your load. You can save this much per month." Or you can say, "Three EC2 instances have been running for 6 months with
[22:27] consistent usage, so switching to reserved instances would save you 40%." Or detect, let's say, "This S3 bucket has 2 TB of data that hasn't been accessed in last 90 days, so maybe you
[22:40] can move it to a cheaper storage and save this much per month." So, as you see, AI can actually enhance parts of your infrastructure management if you use it efficiently. But here is a very important point that I want to make. AI
[22:54] may make you faster in infrastructure management, but it doesn't replace the technical understanding or domain expertise of the subject. If you ask AI to create a VPC with public and private subnets, but you don't understand what a
[23:08] VPC is or why you would want public versus private subnets, you cannot evaluate if AI solution is correct. AI may generate code faster that looks right, but has maybe subtle security issues. If you never went through stage
[23:22] one and learn what a security group does, you won't catch that the AI maybe opened too many ports. Or in most cases, you wouldn't even know what to ask AI to
[23:34] create or automate for you if you don't understand the underlying concepts. So, think of AI as a knowledgeable co-worker, not a replacement for your knowledge. Because if you hire a team member that has a lot of knowledge and
[23:48] is very efficient in what they do, it doesn't mean that you now need to know less, right? The more knowledge you have, the more efficiently you can use this AI assistant, basically, to work much faster and get the most of your
[24:01] knowledge and understanding of the subject. And that's why the learning path is not to start with AI and jump straight into the end stage, but actually go through the stages one by one. Because a lot of junior engineers
[24:14] try to jump straight to the AI code generation because it sounds impressive and they don't want to {quote} unquote lose time, but that means they will never build a foundational knowledge if they skip the stages. So, the expert
[24:27] engineers who really understand infrastructure walked the whole path. they understood the cloud concepts and main building blocks. They automated with CLI or Python until they hit the limits and felt the pain of imperative
[24:41] scripting. Then they adopted infrastructure as code and understood the value and power of declarative configuration and state management. Then they implemented GitOps, and now they use AI to work faster. They understand
[24:53] everything that AI generates because they've written it manually before. So, each stage actually teaches you something that the next stage assumes you know. So, when you review the stages, just know where you are on the
[25:05] journey and what comes next. And if you need a structured path through the stages, our DevOps boot camp covers stages one till three like console scripting and infrastructure as code and the advanced DevSecOps boot camp takes
[25:21] you into GitOps and securing infrastructure parts. And once you have that deep expertise, you can layer AI automations on top of that at any point very easily yourself. Because once you know how to do things manually and how
[25:37] they work under the hood, you can then easily automate them. Now, I hope you learned a lot of valuable insights in this video. Let me know in the comments what your next action step is in your infrastructure management journey. I'd
[25:50] love to hear where you are and where you headed. And with that, as always, thanks for watching and I'll see you in the next video.