Software Development in the Modern World

0:00Welcome to the content for DevOps tools, engineers, and modern software development. Look, it's a really weird time to be a software developer and talk about modern software development practices because they're changing literally by the week. In fact, software development and DevOps engineering is unrecognizable from where it was even two months ago, now that most of the world has figured out that Claude code and codex exist. And it really is revolutionizing the speed at which we develop and ship applications.

0:33It's also revolutionizing the job market in a really weird and unfortunate way. But that being said, a lot of reports and statistics are coming out saying that DevOps engineers are among the more safe technologists that are out there. In fact, the recent study that I read said that DevOps engineers will only see something like a five to 6% impact from the advent of AI, Claude code and codex applications. Now, that being said, when we're talking about modern software development, you can't talk about it without using Claude code, cursor, or codex.

1:11You just can't. That's just what's being used today. It's not going to be on your exam, but it's 1000% something you're going to use if you work in a modern software environment. So all that being said, we are going to talk about the software development lifecycle and the DevOps engineering lifecycle and the tools that we use for it. But we're also going to be making sure that we cover the things that are actually being used in practice these day and age, which is for the most part, Claude code, codex, or cursor.

1:42I personally use Claude code with Opus 4.7. That's what's available today. And that's what we're going to use, or at least I'm going to use for a large part of the rest of this course. So without further ado, let's start talking about what modern software development practices look like for a DevOps engineer.

0:00So like I say, it is the year 2026 when I am recording this. There is a new exam blueprint for the LPI DevOps Tools Engineer exam. And my kids have clearly messed with my marker, so let me go ahead and rewrite this LPI DevOps Tools exam. And the big thing that you are probably wondering as a learner is should I still learn this? Should I still take the time to learn what these tools do in the year 2026? Because Claude and Codex and whatever other LLMs are out there or other tools out there, specifically Claude Code, write all the code for us. They do 90% of the work for us.

0:49Here is the answer, the honest answer. Yes. Why? Because the tools themselves haven't changed, at least not yet. They might be coming. They might come up with something new, but probably not. We're still heavily using microservice-based applications. We're still deploying to the cloud. We're still deploying Docker containers. And we're still shipping to Kubernetes, very frequently abbreviated K8s.

1:21All of these things still exist. Just instead of us manually typing the code and manually typing the commands, we prompt Claude Code to do it. And it really does do most of the work and probably better than 95% of humans on the planet would ever do it. Like I say, there is a lot of research out there that says the actual writing of an application itself is starting to transition to heavily rely on Claude Code. But the deployment of said applications and ensuring that the delivery of it is consistent and works and iterates and is smooth is still something that is largely human-driven. And it'll probably stay that way for a good bit.

2:09So yes, I 1,000% believe that DevOps engineers are mostly safe in the advent of AI and that understanding what a microservice is and how the cloud really works in the point of the cloud and how to build your own containers and how to deliver to K8s all with the assistance of these tools is a very valuable tool or is a very valuable skill. In fact, I would even argue that it's going to be a huge competitive advantage for you to learn this certification because in an era of vibe coding, there's going to be a lot of quote-unquote experts out there who've never actually touched these technologies before. They are going to apply for jobs, and then there will be you who is certified to do these things. You can prove that you understand how the cloud works, how Docker works, how Kubernetes works. You didn't just trust Claude Code to do it. It's going to be a differentiator for you to actually prove that in the era where everybody kind of has skills, but not really, you can actually prove that you do have skills.

3:18So this is kind of the point of why we still learn this, why we still understand how DevOps works. We augment it and leverage tools like Claude Code and Codex, but for the most part, the delivery of applications into scalable and automated infrastructure is still a human-driven responsibility. So now that that's out of the way, we're going to get started talking about modern software DevOps in DevOps engineering.

0:01If code is law, that's a phrase that we say all the time. Code is law. Because ultimately when we write an application to perform a task, it's going to do exactly what it was coded to do. It's not going to deviate from that. It's not gonna read between the lines. It's not gonna guess or hallucinate unless you're an LLM. Code is law. If code is law, then source control right here is the entire legal system.

0:39It is court records. It is enforcement of law or policies. It is the history of the entire legal system. It is the current state. Oh, that's not how you spell state. It is the current state of the legal system and the current law. So this kind of begs the question, what is source control?

1:10Well, we're gonna spend a lot of time talking about how to work with source control. The application that we all use this day and age is Git. Now you've probably heard of something like GitHub or GitLab. Those are websites that support the Git application. Git is an app. You install it into your system if you don't already have it. For most Linux distributions, which is what we really use to develop software this day and age, Git almost always ships with it by default.

1:41And the idea is, let's think you've got a folder structure. Here's a folder. It's the world's worst drawn folder, but that's how I'm gonna draw folders, like the little tab at the top and then the Manila folder. Anyways, we're gonna call this the root of our project. This is the root of our application. And then within that, we have a bunch of directories like this. We call this the tree and maybe they have sub directories and so on and so on and so on. And it just kind of keeps going on and on and on forever.

2:12Within these directories, we then have files. I'll just put F right here for files and kind of put an F right here for files and an F right here for files and so on. The idea with Git is we can tell Git track changes to any specific file that we want or all the files within a folder or so on and so on and so on. We tell Git, as soon as somebody types in a change and then saves that change to disk, Git knows what has changed in that file.

2:47And it can visually show you something called a diff. Where it shows you a A and a B, a before and an after version. So maybe in the before version, we deleted some lines and over here, we added some new lines. It shows you what has changed from where we last took a snapshot of the file and where it is today. Specifically, those snapshots are something called commits. And it's kind of like setting a version of a file.

3:20So we might start off with version one of a file. Then we've made some changes to it and we can compare the new version of whatever we have saved to disk to the last commit, version one. And that's the whole idea with Git is we can literally track the state and changes of all files at all times across an entire project. It's more powerful than that though because what really happens is we use something like GitHub to centralize collaboration.

3:58So here's our project on GitHub. It's got again, the whole file and folder structure. And then my job is to fix bugs in our project. So what I can do is I can clone or basically download a copy of this repository of this entire project to my local computer. And now I've got a copy of this and I can work on making fixes. I'll create a new version of this that makes the fix and I can synchronize it back to the central repository later.

4:34What makes this extra cool is that other people like Alice, Alice can also make a clone of this repository, all the files and folders here on her local computer. And she can work on building out new features in separate files, in different branches. We're gonna talk about all of that later in a different branch. And she can, when she's done, she can synchronize her changes back to the main repository.

5:04What ultimately happens here is we have lots of people or even teams, lots of teams collaborating on the same project, working on the application in tandem, in parallel. And Git and GitHub becomes our source of truth. What is the ultimate current state of our application? Like I say, we're gonna spend hours talking about how Git works and how GitHub works. But the biggest thing to understand is that all, and I mean 99% of all, DevOps work begins with source control.

5:47Ultimately, when changes to the application are made and synchronized back in to our central repository, we can then kick off automated workflows that happen, again, automatically. That's the whole point of automated. And when I say automated, what's gonna happen is a copy of this repository will automatically be deployed to a server. That server will be pre-programmed with tasks that say things like, can we build the application?

6:24Does it still work? Can we automate testing to be done on this such that we can validate all of these tests of our application still pass? And when all of that checks out automatically, we can then deliver the latest version of our new application straight into test environments or even production environments. That's right. What I'm saying here is that we can be developing changes to our application.

6:59And when we're done and we synchronize that change back into source control, source control can automatically build, test, and deploy our entire code base, the entire application itself. This wizardry, this magic is why you've never seen amazon.com go down. In the decades it's been alive. They mastered source control. Same thing with Google. Honestly, same thing with Meta slash Facebook and really any of the tech giants that you see today.

7:34They've mastered source control, which means they've mastered DevOps. Really the biggest thing that happened right here is test. They mastered testing and they ensure that no broken code ultimately makes its way into the test or production environments. So this is all to say that the beating heart of DevOps is source control. You'll then do things like configure Jenkins or GitLab or Azure DevOps or any other DevOps tool to automate the building, testing, and deployment.

8:11But it all begins with source control. We're listening to specific code change events on source control and that kicks off the workflow. So that's the first thing I want you to understand about modern software development. It begins with Git and some sort of collaboration tool like GitHub.

0:00The next thing we're talking about are services. And services is not what it sounds like. In fact, we just call them micro-applications or micro-services. If you take an application, if you think about just the way we used to develop software, I'm gonna say 20 years ago, we would have an app. I mean, it was gigantic. It would have the front end, which is basically how the user saw it.

0:30This could be a website, or it could be a console application, or it could be something called compiled, meaning it was like a .exe. If you were on the Windows world, an executable application. In the Linux or macOS world, we start to see things like bins or binaries as our applications. There's other things that we could do. .dmgs are kind of applications. Anyways, you get the idea. This is how the user interacts with our application, how they use the application.

1:07Then, kind of in the middle of it, we had what is called our application tier. This is, put another way, this is the business logic, the business end of things, if you will. Basically, the user's done something. They've clicked on something, or they've clicked the submit button, they've filled in a field, and then we gotta do something with it. This is what the app does, the application tier, and our gigantic one-piece application used to do.

1:39As the user interacts with the application, they're doing things, they're processing data, they're changing things. This is what the app tier does. It is really the brains of the whole operation, and it's what makes it move. Lastly, we had data storage. Lots of times, this is a database itself, but it could be just text files, CSVs, or a SQLite file, or something like this. We used to ship all of these as one gigantic thing, one gigantic application, where when you ran the EXE, sure, you saw the front end, but it also had the app and data storage baked into it.

2:24So, a user would type in a field, they'd click submit. The app tier would pick up all the data that they submitted. It would think about it. It would think, okay, well, what should I do with this data? Am I trying to submit a credit card information to purchase something, or whatever? And then whatever it did, it would store that data plus any results inside a database, so they could be stored here. What microservices do is it starts to split all of this apart into a bunch of miniature applications.

3:01Because when you start to think about the app, what did the app really do? The app had features or functionality. And it didn't just do one single, I mean, maybe your apps did, maybe they did one single thing. You launched an application to do one single thing. But most applications are really complex. Take a look at this. Here's an application, amazon.com.

3:32Does amazon.com do one single thing? No, it does a lot of things. It has a search bar. It has authentication. It has managing your own returns and orders. It has a shopping cart. It has things that you might be interested in. It has a jumbotron with all of these different things that it's promoting. And it shows you, it knows that Mother's Day is coming up. So gifts for mom is right here.

4:03It knows that people like to read books and here's what's popular lately. These are all functionalities. Understanding what the calendar is, understanding what's trending, getting you to navigate to the thing that you're interested in most quickly by searching, loading your authentication and your credentials and your past orders, authenticating you that way, looking at what the state of your shopping cart is, even understanding your geolocation is all part of this.

4:37These are all functions and features of an application. So this begs the question, yes, I'm interacting with a front end. Does the application tier itself, the business logic of it, is it managing all of these things right now? And the answer is not in the way that you're thinking. These, like the location service, the shopping cart, the sign-in and authentication, understanding the calendar, understanding what's trending, these are now in modern era, modern applications, separate applications that communicate to each other.

5:21So what do we do instead? Yes, we'll have a front end application that end users out here in the world work with and interact with. The thing is, is we will distribute it globally through a bunch of different means. We're going to talk about that a lot more later. But ultimately, the idea here is our front end users, our clients who are distributed all around the world will have a seamless, smooth, quick accent or experience in their own region.

6:00So we'll talk about how that works in the cloud videos coming up. But then when they want to process data or log in, it directs them to a different application like authentication right here. And once someone gets authenticated, maybe that will then load their shopping cart application, which could, and it could also load their orders and returns.

6:31And here's the thing, orders and returns. That's not the, this application here doesn't store that data, does it? No, it retrieves that data and then returns it back to the front end. So this is all going to come from some sort of persistent database. We're starting to set up another big topic. And this is how communication flows and where data gets stored and when it gets stored.

7:06But let's continue talking about more microservices here for a second. Because once someone is authenticated, they could then purchase something. They click the submit button or the buy now button. Well, guess what that does? That triggers a credit card workflow, which is going to actually charge something like Visa, who returns a successful response back to the credit card workflow, who returns a successful response back to the purchase, who then sends it to the logistics workflow, which then gets sent to the warehouse, which then gets sent to the shipping and handling.

7:56And once we actually have something like shipping confirmations, guess what? We're going to store that in a database. Same thing with our purchase confirmation. Guess what? That's going to link up to our orders and returns, which is then going to be displayed in the front end. Yes, it does feel like this can get out of hand fast, but an application like amazon.com is not a small application.

8:26By actually breaking these functionalities into small applications, what does that mean? We can have individual teams assigned to each one. Let me change the font here to something like orange. We can have individual teams assigned to each one of these microservices. And their job is just to make sure this one piece works. We isolate failures that way.

8:57We isolate bugs quickly that way. And importantly, we can scale the most critical microservices more quickly. For instance, let's say authentication is something that you, as a user, do once a month. You only have to log out or log into amazon.com once a month. But maybe, if you're perhaps like my wife, you're purchasing something every single day. So she logs in once, but I get that brown box every single day.

9:29The purchase application inherently has to be bigger because of my wife's shopping habits. And I want to be clear, I absolutely, there's nothing wrong between me and my wife. This is a joke. It's a joke that we tell each other every single day. She thinks it's hilarious. I think it's hilarious. The point is, is that on average, the purchase application is going to get hammered a lot more than the authentication application. The good news is, is we can spin up more purchase servers without having to spin up more authentication servers.

10:05We can ship new features to purchase without impacting the shopping cart. That's the beautiful thing here with isolating our microservices. We can now have dedicated focus from a specific team on a specific service. We can scale it independently. We can fix bugs independently. And we can ship features independently. And this is why modern web scale applications are now broken up into multiple pieces.

10:39The big takeaways now for you to understand is that they communicate by APIs. Almost always a REST API. Basically, if you're not familiar with that, they're leveraging the HTTP protocol to send information back and forth. The front end says, hey, a user's just clicked the login button and they've given me this username and password. The authentication app says, I'll take it from here. And that's the end of it.

11:10There is no state that is stored when there is a API request going back and forth. Whenever there is data that needs to be stored, the application itself is going to submit that data to a database where storage happens. But finding things like request histories, like when did auth talk to orders and returns, that's simply not a thing that's going to happen. We keep our API requests stateless.

11:42Fire off a request, get a response, tear it down. That's the end of it. And when there is data that we the developers say, nope, we need to store this data, it goes into a database for storage. And we can retrieve that data whenever we need, but it'll be as simple as firing off a request for that data and then sending it back to the requester that it originally came from and then tearing it down. The API requests only lives for the duration of one request and one response, and that's the end of it.

12:15So this is now understanding how web-scale applications work in the era of microservices in the modern software development world.

0:00Next up, we're talking about the cloud-ish. We're really talking about data center and the difference between using the cloud or own environment, which is what we're talking about when we say modern software development. But for the exam purposes, they really want you to know about public clouds. I'm talking, of course, about AWS, Azure, GCP, maybe Vercel for your front-end hosting, and so on, DigitalOcean, the list goes on and on. Basically, if you have an application, a app workload, it makes a lot of sense for a lot of different reasons to build it for the cloud for, well, really a list of reasons.

0:44The first one is scalability. When we look at the cloud, one of the words that gets used a lot is elastic. You see the letter E a lot in AWS. You might be thinking of EC2. That's the virtual machines that you can spin up in AWS. It's EC2 because it's Elastic Cloud Compute. And what makes it so elastic is auto-scaling. Auto-scaling is a thing that's present in all of these.

1:16And the idea is that we can scale in all four directions. It's not very hard. In fact, it's really just a point-and-click operation to scale a virtual machine up or down. When we rent an instance, like a virtual machine, we rent it with a specific size or skew. Let's say we might start off by renting a large VM, which might have something like eight CPUs and 32 gigs of RAM.

1:46And we start using it, and we realize we're only utilizing 1% of that workload. It's like, okay, maybe I don't need large. Maybe I just need a medium or a small VM. You can literally shut it down, scale it down to a different size, and start it back up. That's kind of the beautiful part about the cloud. And now we pay less per hour because we scaled it down to something like a small VM, which might only be two CPUs and eight gigs of RAM.

2:17That makes it elastic in the sense that we can scale it vertically up or down with the point of a click or a button. But the fact of the matter also stands, we can actually scale horizontally pretty easily too, especially on web front ends or even microservices, because if you really think about it, a microservice is also just a web server. It's hosting an API instead of a website. So what we can do is we can spin up a bunch of virtual machines and put them behind a load balancer.

2:50Now, whenever you think about that picture of the microservices scattered everywhere, you should actually think about this as multiple machines behind a load balancer everywhere you look, because that's what it really is. Again, we can do this with basically not much more than just a couple points and clicks, or also using some code. We could use code to scale it automatically and do it via DevOps. If we notice our web traffic is getting really, really clobbered, instead of scaling all these VMs up, which we can do, we can also just deploy more VMs and they automatically get added behind the load balancer and we can scale horizontally.

3:34You can actually do both. You can scale out and up or in and down at the same time, if that's what you want to do. The cool thing about it is we can scale and we're not committing this to scaling permanently. We're not committing to scaling up and scaling out permanently. We can scale up and out for the duration of two or three hours, maybe because we made some incredible announcement online that's generating a lot of web traffic for us. And then once the traffic dies down, we can just undo it.

4:06We can just roll it back, scale it back in, if that's what we need to do. And most of these VM plans are billed per hour. So we're only going to get billed for the compute that we actually use. So scale is a really, really, really big reason. One of the top reasons to do it. The second reason is redundancy. Almost everything that you deploy in the cloud has some form of redundant version of it going on.

4:38For instance, each of these VMs have disks in them, correct? Well, almost every time we deploy a disk, I'm going to say almost a lot, because you have total control over your deployments. You don't have to do anything that you don't want to do. But by default, when we create a disk, what is really happening back behind the scenes? It's creating something like a VMDK or a VHDX file, depending on if it's VMware based or Azure or Hyper-V based. And this is really just a file.

5:09That file lives on a SAN. The compute connects over the network to that SAN to get the disk. But then that SAN behind the scenes is going to replicate a copy of this disk at least two more times within the same data center. But lots of times we actually can make copies of it across data centers or even across regions. The point is, is when you log into this machine, you're only going to see one data disk attached to that virtual machine. But in reality, multiple copies of it exist behind the scenes, ensuring that there's a lot of redundancy in place.

5:48There is redundancy in absolutely everything in the cloud, from compute to storage, to message buses, to all of that stuff, to network connectivity. There is redundancy everywhere. And the big thing that we do is not only can we scale and right size our application, but we can also with relative ease, ensure that we can get five nines of availability because of all the redundancies in place.

6:18Now there's another really good reason to use the cloud, but it's kind of a tougher one to actually get to. And that is cost. You're going to hear a lot of people on the internet tell you that the cloud is more expensive than if you deployed on-premises. And to some degree, that's right. The cloud is definitely more expensive if you rely on infrastructure as a service. Put it nicely, virtual machines.

6:49It'll probably run you up a good bill if you're doing that. And the truth of the matter is, this is how most cloud deployments begin. You have virtual machines on-premises. It's not terribly hard to lift and shift them into the cloud. Now, they're not super easy either. There's a lot of content on certification exams here in CBT Nuggets on how to do it. You should definitely block out an hour or two of your time to watch that content if you ever get into that situation.

7:21And you should definitely proceed with an extreme amount of caution. But at the most fundamental oversimplified way of thinking about it is we're really just copying a virtual hard drive into the cloud, then setting up some sort of cluster and replication service, then failing over to the cloud. Next thing you know, you've got your same virtual machine running in the cloud. And you're like, great, now I've got the ability to scale it, check. Let me get my mouse back, scale it.

7:51And we also have redundancy everywhere, check. We've got both of those things, but it can rack up a pretty big cost. The next goal that you should start moving to is how do I refactor my application? How do I refactor my workload to actually work with platform as a service? This is where the cloud wins. Where a lot of people fall victim is they think that the cloud is meant to replace your core infrastructure.

8:23They think that your cloud is meant to just run virtual machines, and that's where your Active Directory and file share and all of those things should live too. In my opinion, that is just blatantly wrong. That is not the case. I firmly believe that core infrastructure should be kept as close to the people who touch it as possible. That's the worker. So if you've got Active Directory, if you've got a file share, you should keep that close to the people who use it. Whereas your application, your web-facing application, that's consumed by consumers.

8:59And the closest way to reach them is by using the cloud in conjunction with their content delivery networks and global distribution systems. Because virtual machines can be pricey and honestly somewhat wrong-sized, it is hard to right-size a virtual machine, you can use platform as a service. This is nearly perfect size for all of the applications. Lots of times you see this referred to as serverless.

9:31I mean, it's not entirely true. There's a server and an operating system running somewhere, but you never touch it. You're only focused on the workload. So for instance, if you are trying to deploy a web application and you want to use Azure websites, also known as Azure App Services, you can deploy an app service resource. And from there, you never touch the operating system again. You point something like VS Code at your Azure App Service to ship the code to, and next thing you know, web hosting is done for you.

10:07Azure is hosting your website and it scales to meet your demand. It's also more affordable than a virtual machine. Then you're thinking, okay, well, that's the front end. What about my microservices? There are a ton of container resources and container hosting for you to manage your microservices and your application. We're going to talk a lot more about containers in an upcoming video. Then you're thinking, okay, great, but what about the database? Because data is my most important asset.

10:38Guess what? They can give you all sorts of different SQL backends that all you have to do is connect to. You never touch the operating system. You don't even touch the SQL instance configuration. You just connect to the database, create your tables and start writing data to it. They also do no SQL backends in database caches like a Redis cache or document databases. Things that if you've ever worked with MongoDB, that would be familiar. Basically, they're deploying a private instance of say SQL Server or MongoDB or Redis that you can connect to, but you never have the hassle of actually managing underlying infrastructure or operating system.

11:23You just connect to the application and use it. And that's almost always more affordable. And it's almost always right sized for your exact workload. Because it's relatively easy to get started for software developers to use Platform as a Service, this is where your big win is. Because then you'll accomplish scale, redundancy, and cost savings at all the same time.

11:54And all of a sudden your microservices become much easier to manage and scale because you can actually automate the scaling as it reacts to workloads. So this is kind of the point of the cloud. Now I did say a lot about co-location and stuff like that. Like I said, there's a lot of people who are not finding these cost savings in the cloud, nor are they finding a need to globally distribute their application. For those people, it is more affordable to just buy a server, rack it in a local co-location data center, and deploy your applications to it.

12:32If you have the expertise to manage the underlying operating system and all the security that goes with it, great. That's a win for you because you don't have to refactor and build for Platform as a Service only to find out that we're not really trying to reach a global audience here and we're spending a lot of money to try to. It does make sense for a lot of workloads to revert back from the cloud to co-location. But for global scale applications, which is what really the point of this exam reaches, the cloud is a huge unlock in that case.

0:00Our final thing to talk about are containers and Docker, which is really the application that we use to work with containers. When you're learning about them for the first time, it's easy to conflate the two, but they're two separate things. It's kind of like the difference between a virtual machine and VMware. That's really what we're talking about here. Containers are so interesting, and Docker is the app that makes them really run and work. So let's first ask the question, what is a container?

0:32A container is an application plus an environment for it to run in all contained in one. Basically, if you build an app or in particular, a microservice, if you wrote the code, then what does it do? You're going to run it locally on your computer and test that it works, but then it's time to deliver it somewhere. So what is it you used to do? What is it the way that we used to do things? Well, you deploy a virtual machine, have an operating system, patch it, install all the dependencies like, oh, this is going to need Java or Node.js or Python version 3.11.

1:17Within that, it'll need this npm package or this pip package or whatever and all of these additional things. You'd install all of those dependencies and then you would copy the code onto that machine and run it. What if I told you you didn't have to do any of that at all? What if instead everything that you need to run your app, like all of the bare minimum kernel of the operating system and whatever patches it needs, and whatever dependencies it need, what if that could all be shipped inside of this little box, and then that box can be sent, copies of it can be sent anywhere.

1:55So that we deliver it to these host machines where it needs to run, and it already has everything that it needs to run inside of it. So that means I build it one time and deploy it as many times as I want, and it will always work because it will always have the same environment wherever it goes. That is what a container is. A container is a self-contained app.

2:29That's really what it is. We use something called a Docker file. That's one word with a capital D, that capital D is important. In this Docker file, we define where the source code is, and what kind of environment it needs to build. We'll specify things like the kernel or operating system, which is really a very stripped down version of the operating system, and any node dependencies, Python dependencies, or any other dependencies.

3:11I'll put DEP right here for dependencies that you need to have installed in this environment, and it builds the self-contained self-running application for you. So how does it then work? Well, the container really shares the underlying. So here's my container, I'll put C, and here's my main operating system. Underneath the operating system, you have the raw kernel.

3:41The container piggybacks off of this raw kernel, and a lot of the compute and operating system doings or things that it needs happens on the host kernel itself. The container for all intents and purposes, usually believes it's just like a virtual machine. It believes it is a self-isolated instance. It believes it will have its own IP address. I got to redo, my mouse got a little messy there. IP address, its own operating system, its own version, and it'll have my app running inside of it too.

4:21The end result is that we can have an application and the full runtime environment for as little as 100 megabytes of space, or RAM, or runtime environment that we need. They are extremely lightweight. In fact, like the biggest container I've ever seen was something like one and a half gigs. Yes, I know there are probably bigger containers out there, but this is proving or showing what an upper limit of a container is.

4:53It's still much, much smaller than an operating system or a virtual machine itself. Because it's so lightweight, it is very, very fast to deploy and scale. The highest level workflow of it is here's me, I'm on my laptop, I build a container. I then publish that container to some repository. This can be public or private. Lots of people use Docker Hub.

5:27Again, I can publish my container to where I can only privately access it or I can make it public. Then I go to my target host box, I log into Docker Hub, and I pull the container down and run it on each of these machines. When this happens at scale, for instance, let's say we're talking microservices in the Cloud once more.

6:00In my Cloud environment, I can define service A, service B, service C, service D, you get the idea, it goes on for forever. In the Cloud, I can say this service needs to be deployed with three containers. I can say three copies of my container behind a load balancer.

6:32I'll make an application that handles, say, shopping carts, I'll containerize them, and then I'll have the Cloud automatically deploy my containers and scale them as need be. This happens significantly quicker than virtual machine deployment because everything is already contained inside the container. All you have to do is simply turn more on.

7:03Starting a container is almost like flipping a light switch. You can really start an application that quickly. The same thing will happen for service B. It'll be behind a load balancer and it'll scale. This can be something like credit card processing. Service D can be something like shipping and handling. I'll containerize that application or that microservice itself and put it behind a load balancer.

7:37Then comes in service C. This could be something like a database handler, where we connect to data or get data from all of these other services and log into a database and write data there. We might have one or two instances here. Maybe they target different databases each behind the scenes for different types of workloads or data that they might receive. Now, this is the idea with microservices and containers. It becomes much more predictable and easier to containerize an application and deliver it.

8:13We then take the environment and the operating system entirely out of the equation at this point. But then it gets even more interesting when we introduce Kubernetes very frequently abbreviated K8s, because what happens in Kubernetes between the K and the S is eight characters. Kubernetes is like if I were again comparing this to virtual machines, this would be like the VMware VCSA, where we have automatic scaling and workloads and migrations and balancing.

8:50That is what Kubernetes does. Kubernetes is your container orchestrator. Kubernetes is what handles the deployment of load balancing and sharing of applications and services, and allowing connectivity between the services to happen. You are not responsible for manually defining each one of these services and manually defining how they connect to each other, and manually scaling them, and manually managing the load balancing of traffic, and manually handling whether traffic is allowed in from the public or from these services really.

9:25This is what Kubernetes does. You tell Kubernetes what it is that you want and how a service should behave, and it orchestrates the rest for you. It ultimately manages all of the container hosts that your containers run on. It says these workloads should be on these hosts, and if it finds that a host is overwhelmed, it can migrate workloads, it can scale workloads, it again handles all the networking that your service need or your services need to make your application work.

10:05When you start thinking about how we got here, source control is where it all begins. It's what tracks changes from the line-by-line code itself. From there, using CICD and DevOps pipelines, source control events can trigger the building of code. In this case, it can trigger the building and testing of containers. When those containers are deemed fit, we can deliver those containers to their in-target sources.

10:37In a lot of cases, that's delivering them to Cloud resources, specifically Cloud Kubernetes environments, where Kubernetes is managing all of these containers that are newly built thanks to source code and DevOps and delivering them to stable environments. Yeah, it's big. We're talking about big applications in this entire course. We're not talking about small apps, we're talking about big ones and the delivery of incremental line-by-line code all the way through to your big service deployment in your applications.

11:15That's why you're here. This is a skill that is going to be hard for AI to take. Although AI can absolutely augment each and every one of these steps and you can leverage it to become a better DevOps engineer. We will begin focusing on all of this in the upcoming videos. For now, we focused in on what modern software development really entails. I hope this has been informative for you and I'd like to thank you for viewing.

0:01Let's make sure we understand the concepts in modern software development. Like I say, this is a bit of a moving target in the age of AI. But the tools are still the same, at least for now. We still use containers. We still build for microservices. We still build for the cloud and platform as a service. So let's make sure we understand it. A company has a large application where a single bug causes the entire system to crash. They want to redesign it so that individual components can fail without bringing down the whole system.

0:36Which architecture should they adopt? Well, monolithic architecture is the single bug that takes the whole thing down. Cloud-hosted virtual machines? You're getting closer. There's scalability there. There's redundancy there. But it can still take a whole app down with a single bug. Multi-threaded app that runs on multiple servers? Not really what we're looking for here. We want to break the whole thing apart into individual services. That way a service can go down, but most of the app still works.

1:08It's also easier to identify problems, fix them, and deliver them when you use a microservice. A startup expects unpredictable traffic spikes and wants to automatically scale resources up and down based on demand without buying physical servers. Which cloud benefit best meets this requirement? Static infrastructure? Yes, you can rent physical servers from your cloud provider. Manual provisioning? Well, that doesn't really automatically scale. That's manually scaling.

1:41Elastic scalability? That's really what we're looking for here. There's also vertical scaling only, which is scaling up or down, but automatically scaling allows you to scale in any direction. In or out, basically horizontally behind load balancers, or up and down to also increase the size of your machines. A team packages their application so it runs the same way on a developer laptop and in production. They also want a system that can automatically restart failed containers and distribute traffic across them.

2:16Which combination best fits this scenario? Bare metal servers only? Virtual machines managed by a controller? FTP deployment with cron jobs? Or containers with Kubernetes orchestration? This is it. Containers with Kubernetes orchestration. We should have known that the moment they said they're packaging an app so it runs the same way on a developer laptop as in production. It's the same environment when we use a container. Automatically restarting containers and load balancing them?

2:49That's what Kubernetes' job is. So this has been reinforcing what we learned about modern software development.