Software Development in the Modern World

0:00Welcome to the content for DevOps tools, engineers,

0:03and modern software development.

0:05Look, it's a really weird time to be a software developer

0:09and talk about modern software development practices

0:12because they're changing literally by the week.

0:15In fact, software development and DevOps engineering

0:18is unrecognizable from where it was even two months ago,

0:22now that most of the world has figured out

0:24that Claude code and codex exist.

0:28And it really is revolutionizing the speed

0:30at which we develop and ship applications.

0:33It's also revolutionizing the job market

0:36in a really weird and unfortunate way.

0:38But that being said, a lot of reports and statistics

0:42are coming out saying that DevOps engineers

0:45are among the more safe technologists that are out there.

0:49In fact, the recent study that I read

0:51said that DevOps engineers will only see something

0:54like a five to 6% impact from the advent of AI,

0:59Claude code and codex applications.

1:01Now, that being said,

1:03when we're talking about modern software development,

1:06you can't talk about it without using Claude code,

1:10cursor, or codex.

1:11You just can't.

1:12That's just what's being used today.

1:14It's not going to be on your exam,

1:15but it's 1000% something you're going to use

1:19if you work in a modern software environment.

1:22So all that being said,

1:24we are going to talk about

1:26the software development lifecycle

1:28and the DevOps engineering lifecycle

1:30and the tools that we use for it.

1:32But we're also going to be making sure

1:34that we cover the things that are actually being used

1:37in practice these day and age,

1:38which is for the most part, Claude code, codex, or cursor.

1:42I personally use Claude code with Opus 4.7.

1:46That's what's available today.

1:47And that's what we're going to use,

1:49or at least I'm going to use for a large part

1:51of the rest of this course.

1:53So without further ado,

1:54let's start talking about

1:55what modern software development practices look like

1:59for a DevOps engineer.

0:00So like I say, it is the year 2026 when I am recording this.

0:04There is a new exam blueprint for the LPI DevOps Tools Engineer exam.

0:11And my kids have clearly messed with my marker, so let me go ahead and rewrite this LPI

0:19DevOps Tools exam. And the big thing that you are probably wondering as a learner is

0:27should I still learn this? Should I still take the time to learn what these tools do in the year

0:342026? Because Claude and Codex and whatever other LLMs are out there or other tools out there,

0:42specifically 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

0:56haven't changed, at least not yet. They might be coming. They might come up with something new,

1:02but probably not. We're still heavily using microservice-based applications.

1:10We're still deploying to the cloud. We're still deploying Docker containers.

1:16And 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

1:28typing the commands, we prompt Claude Code to do it. And it really does do most of the work

1:34and probably better than 95% of humans on the planet would ever do it.

1:40Like I say, there is a lot of research out there that says the actual writing of an application

1:46itself is starting to transition to heavily rely on Claude Code. But the deployment of said

1:54applications and ensuring that the delivery of it is consistent and works and iterates and is smooth

2:01is 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

2:18understanding what a microservice is and how the cloud really works in the point of the cloud

2:24and how to build your own containers and how to deliver to K8s all with the assistance of these

2:30tools is a very valuable tool or is a very valuable skill. In fact, I would even argue

2:37that it's going to be a huge competitive advantage for you to learn this certification

2:42because in an era of vibe coding, there's going to be a lot of quote-unquote experts out there

2:49who've never actually touched these technologies before. They are going to apply for jobs,

2:55and then there will be you who is certified to do these things. You can prove that you understand

3:01how the cloud works, how Docker works, how Kubernetes works. You didn't just trust Claude

3:06Code to do it. It's going to be a differentiator for you to actually prove that in the era where

3:13everybody 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.

3:27We augment it and leverage tools like Claude Code and Codex, but for the most part,

3:32the delivery of applications into scalable and automated infrastructure is still

3:40a human-driven responsibility. So now that that's out of the way,

3:44we'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.

0:05Code is law.

0:09Because ultimately when we write an application

0:11to perform a task,

0:13it's going to do exactly what it was coded to do.

0:18It's not going to deviate from that.

0:20It's not gonna read between the lines.

0:22It's not gonna guess or hallucinate unless you're an LLM.

0:26Code is law.

0:28If code is law,

0:30then source control right here

0:36is the entire legal system.

0:39It is court records.

0:43It is enforcement of law or policies.

0:49It is the history of the entire legal system.

0:54It is the current state.

0:58Oh, that's not how you spell state.

0:59It is the current state of the legal system

1:03and the current law.

1:05So this kind of begs the question,

1:07what is source control?

1:10Well, we're gonna spend a lot of time

1:12talking about how to work with source control.

1:14The application that we all use this day and age is Git.

1:19Now you've probably heard of something like GitHub

1:22or GitLab.

1:23Those are websites that support the Git application.

1:27Git is an app.

1:29You install it into your system

1:31if you don't already have it.

1:32For most Linux distributions,

1:34which is what we really use to develop software

1:37this day and age,

1:38Git almost always ships with it by default.

1:41And the idea is,

1:43let's think you've got a folder structure.

1:44Here's a folder.

1:45It's the world's worst drawn folder,

1:47but that's how I'm gonna draw folders,

1:49like the little tab at the top

1:50and then the Manila folder.

1:52Anyways, we're gonna call this the root of our project.

1:56This is the root of our application.

1:59And then within that,

1:59we have a bunch of directories like this.

2:03We call this the tree

2:05and maybe they have sub directories

2:07and so on and so on and so on.

2:09And it just kind of keeps going on and on and on forever.

2:12Within these directories,

2:13we then have files.

2:15I'll just put F right here for files

2:18and kind of put an F right here for files

2:20and an F right here for files and so on.

2:23The idea with Git is we can tell Git

2:27track changes to any specific file that we want

2:33or all the files within a folder

2:35or so on and so on and so on.

2:36We tell Git,

2:38as soon as somebody types in a change

2:40and then saves that change to disk,

2:44Git knows what has changed in that file.

2:47And it can visually show you something called a diff.

2:53Where it shows you a A and a B,

2:56a before and an after version.

2:58So maybe in the before version,

3:00we deleted some lines

3:02and over here,

3:03we added some new lines.

3:05It shows you what has changed

3:07from where we last took a snapshot of the file

3:11and where it is today.

3:13Specifically,

3:14those snapshots are something called commits.

3:17And it's kind of like setting a version of a file.

3:20So we might start off with version one of a file.

3:23Then we've made some changes to it

3:26and we can compare the new version

3:28of whatever we have saved to disk

3:31to the last commit,

3:32version one.

3:33And that's the whole idea with Git

3:36is we can literally track the state

3:39and changes of all files at all times

3:42across an entire project.

3:45It's more powerful than that though

3:48because what really happens

3:50is we use something like GitHub

3:55to centralize collaboration.

3:58So here's our project on GitHub.

4:01It's got again,

4:03the whole file and folder structure.

4:06And then my job is to fix bugs in our project.

4:10So what I can do is I can clone

4:13or basically download a copy

4:16of this repository of this entire project

4:19to my local computer.

4:22And now I've got a copy of this

4:24and I can work on making fixes.

4:27I'll create a new version of this

4:29that makes the fix

4:30and I can synchronize it back

4:32to the central repository later.

4:34What makes this extra cool

4:36is that other people like Alice,

4:40Alice can also make a clone of this repository,

4:45all the files and folders here

4:47on her local computer.

4:49And she can work on building out new features

4:52in separate files,

4:54in different branches.

4:55We're gonna talk about all of that later

4:57in a different branch.

4:58And she can,

4:59when she's done,

5:00she can synchronize her changes

5:02back to the main repository.

5:04What ultimately happens here

5:06is we have lots of people

5:08or even teams,

5:10lots of teams collaborating on the same project,

5:14working on the application in tandem,

5:17in parallel.

5:18And Git and GitHub

5:20becomes our source of truth.

5:23What is the ultimate current state

5:25of our application?

5:27Like I say,

5:28we're gonna spend hours

5:30talking about how Git works

5:32and how GitHub works.

5:34But the biggest thing to understand

5:36is that all,

5:37and I mean 99% of all,

5:43DevOps work begins with source control.

5:47Ultimately,

5:48when changes to the application are made

5:51and synchronized back in

5:54to our central repository,

5:56we can then kick off automated workflows

6:01that happen,

6:02again, automatically.

6:03That's the whole point of automated.

6:05And when I say automated,

6:06what's gonna happen

6:07is a copy of this repository

6:11will automatically be deployed

6:13to a server.

6:15That server will be pre-programmed

6:17with tasks that say things like,

6:20can we build the application?

6:24Does it still work?

6:27Can we automate testing

6:30to be done on this

6:31such that we can validate

6:33all of these tests

6:34of our application still pass?

6:37And when all of that checks out automatically,

6:40we can then deliver

6:42the latest version of our new application

6:45straight into test environments

6:48or even production environments.

6:52That's right.

6:52What I'm saying here

6:54is that we can be developing changes

6:57to our application.

6:59And when we're done

7:00and we synchronize that change

7:02back into source control,

7:04source control can automatically

7:07build,

7:08test,

7:09and deploy

7:10our entire code base,

7:11the entire application itself.

7:14This wizardry,

7:15this magic

7:16is why you've never seen

7:18amazon.com go down.

7:21In the decades it's been alive.

7:23They mastered source control.

7:25Same thing with Google.

7:27Honestly, same thing

7:29with Meta slash Facebook

7:31and really any of the tech giants

7:32that you see today.

7:34They've mastered source control,

7:36which means they've mastered DevOps.

7:39Really the biggest thing that happened right here is test.

7:42They mastered testing

7:44and they ensure that no broken code

7:47ultimately makes its way

7:48into the test or production environments.

7:51So this is all to say

7:54that the beating heart of DevOps

7:56is source control.

7:58You'll then do things like configure Jenkins

8:01or GitLab

8:02or Azure DevOps

8:04or any other DevOps tool

8:06to automate the building,

8:08testing,

8:09and deployment.

8:11But it all begins with source control.

8:13We're listening to specific

8:15code change events

8:17on source control

8:19and that kicks off the workflow.

8:21So that's the first thing I want you to understand

8:23about modern software development.

8:25It begins with Git

8:27and some sort of collaboration tool

8:30like GitHub.

0:00The next thing we're talking about are services.

0:03And services is not what it sounds like.

0:06In fact, we just call them micro-applications

0:09or micro-services.

0:11If you take an application,

0:13if you think about just the way we used to develop software,

0:17I'm gonna say 20 years ago,

0:18we would have an app.

0:21I mean, it was gigantic.

0:23It would have the front end,

0:27which is basically how the user saw it.

0:30This could be a website,

0:33or it could be a console application,

0:37or it could be something called compiled,

0:39meaning it was like a .exe.

0:42If you were on the Windows world,

0:44an executable application.

0:46In the Linux or macOS world,

0:50we start to see things like bins or binaries

0:52as our applications.

0:55There's other things that we could do.

0:56.dmgs are kind of applications.

0:58Anyways, you get the idea.

0:59This is how the user interacts with our application,

1:04how they use the application.

1:07Then, kind of in the middle of it,

1:10we had what is called our application tier.

1:13This is, put another way,

1:15this is the business logic,

1:17the business end of things, if you will.

1:20Basically, the user's done something.

1:23They've clicked on something,

1:24or they've clicked the submit button,

1:26they've filled in a field,

1:28and then we gotta do something with it.

1:31This is what the app does, the application tier,

1:35and our gigantic one-piece application used to do.

1:39As the user interacts with the application,

1:42they're doing things, they're processing data,

1:45they're changing things.

1:46This is what the app tier does.

1:49It is really the brains of the whole operation,

1:52and it's what makes it move.

1:54Lastly, we had data storage.

1:58Lots of times, this is a database itself,

2:01but it could be just text files,

2:04CSVs, or a SQLite file, or something like this.

2:08We used to ship all of these as one gigantic thing,

2:13one gigantic application,

2:15where when you ran the EXE,

2:17sure, you saw the front end,

2:19but it also had the app and data storage baked into it.

2:24So, a user would type in a field, they'd click submit.

2:29The app tier would pick up all the data

2:31that they submitted.

2:33It would think about it.

2:35It would think, okay, well, what should I do with this data?

2:37Am I trying to submit a credit card information

2:41to purchase something, or whatever?

2:43And then whatever it did,

2:44it would store that data plus any results

2:48inside a database, so they could be stored here.

2:53What microservices do is it starts to split

2:57all of this apart into a bunch of miniature applications.

3:01Because when you start to think about the app,

3:04what did the app really do?

3:06The app had features or functionality.

3:15And it didn't just do one single,

3:18I mean, maybe your apps did,

3:19maybe they did one single thing.

3:21You launched an application to do one single thing.

3:24But most applications are really complex.

3:27Take a look at this.

3:29Here's an application, amazon.com.

3:32Does amazon.com do one single thing?

3:36No, it does a lot of things.

3:38It has a search bar.

3:40It has authentication.

3:43It has managing your own returns and orders.

3:47It has a shopping cart.

3:48It has things that you might be interested in.

3:51It has a jumbotron with all of these different things

3:54that it's promoting.

3:56And it shows you, it knows that Mother's Day is coming up.

4:00So gifts for mom is right here.

4:03It knows that people like to read books

4:05and here's what's popular lately.

4:08These are all functionalities.

4:10Understanding what the calendar is,

4:13understanding what's trending,

4:15getting you to navigate to the thing

4:18that you're interested in most quickly by searching,

4:22loading your authentication and your credentials

4:25and your past orders,

4:26authenticating you that way,

4:28looking at what the state of your shopping cart is,

4:32even understanding your geolocation is all part of this.

4:37These are all functions and features of an application.

4:41So this begs the question,

4:43yes, I'm interacting with a front end.

4:46Does the application tier itself,

4:49the business logic of it,

4:51is it managing all of these things right now?

4:56And the answer is not in the way that you're thinking.

4:59These, like the location service, the shopping cart,

5:04the sign-in and authentication,

5:07understanding the calendar, understanding what's trending,

5:11these are now in modern era, modern applications,

5:16separate applications that communicate to each other.

5:21So what do we do instead?

5:23Yes, we'll have a front end application

5:30that end users out here in the world work with

5:33and interact with.

5:34The thing is, is we will distribute it globally

5:38through a bunch of different means.

5:40We're going to talk about that a lot more later.

5:43But ultimately, the idea here is our front end users,

5:48our clients who are distributed all around the world

5:51will have a seamless, smooth, quick accent

5:54or experience in their own region.

6:00So we'll talk about how that works

6:02in the cloud videos coming up.

6:04But then when they want to process data or log in,

6:09it directs them to a different application

6:13like authentication right here.

6:16And once someone gets authenticated,

6:19maybe that will then load their shopping cart application,

6:25which could, and it could also load their orders and returns.

6:31And here's the thing, orders and returns.

6:39That's not the, this application here

6:42doesn't store that data, does it?

6:45No, it retrieves that data

6:47and then returns it back to the front end.

6:50So this is all going to come

6:53from some sort of persistent database.

6:56We're starting to set up another big topic.

6:59And this is how communication flows

7:02and where data gets stored and when it gets stored.

7:06But let's continue talking

7:08about more microservices here for a second.

7:11Because once someone is authenticated,

7:13they could then purchase something.

7:19They click the submit button or the buy now button.

7:21Well, guess what that does?

7:23That triggers a credit card workflow,

7:28which is going to actually charge something like Visa,

7:33who returns a successful response

7:35back to the credit card workflow,

7:37who returns a successful response back to the purchase,

7:40who then sends it to the logistics workflow,

7:46which then gets sent to the warehouse,

7:50which then gets sent to the shipping and handling.

7:56And once we actually have something

7:58like shipping confirmations, guess what?

8:01We're going to store that in a database.

8:05Same thing with our purchase confirmation.

8:09Guess what?

8:10That's going to link up to our orders and returns,

8:12which is then going to be displayed in the front end.

8:14Yes, it does feel like this can get out of hand fast,

8:20but an application like amazon.com

8:23is not a small application.

8:26By actually breaking these functionalities

8:29into small applications, what does that mean?

8:33We can have individual teams assigned to each one.

8:37Let me change the font here to something like orange.

8:41We can have individual teams assigned

8:45to each one of these microservices.

8:48And their job is just to make sure this one piece works.

8:53We isolate failures that way.

8:57We isolate bugs quickly that way.

9:00And importantly, we can scale

9:04the most critical microservices more quickly.

9:07For instance, let's say authentication is something

9:10that you, as a user, do once a month.

9:14You only have to log out or log into amazon.com once a month.

9:19But maybe, if you're perhaps like my wife,

9:21you're purchasing something every single day.

9:24So she logs in once,

9:26but I get that brown box every single day.

9:29The purchase application inherently has to be bigger

9:34because of my wife's shopping habits.

9:38And I want to be clear,

9:39I absolutely, there's nothing wrong between me and my wife.

9:42This is a joke.

9:43It's a joke that we tell each other every single day.

9:45She thinks it's hilarious.

9:47I think it's hilarious.

9:48The point is, is that on average,

9:51the purchase application is going to get hammered

9:53a lot more than the authentication application.

9:56The good news is, is we can spin up more purchase servers

10:01without having to spin up more authentication servers.

10:05We can ship new features to purchase

10:08without impacting the shopping cart.

10:12That's the beautiful thing here

10:14with isolating our microservices.

10:17We can now have dedicated focus from a specific team

10:21on a specific service.

10:22We can scale it independently.

10:25We can fix bugs independently.

10:28And we can ship features independently.

10:31And this is why modern web scale applications

10:36are now broken up into multiple pieces.

10:39The big takeaways now for you to understand

10:42is that they communicate by APIs.

10:46Almost always a REST API.

10:49Basically, if you're not familiar with that,

10:52they're leveraging the HTTP protocol

10:55to send information back and forth.

10:57The front end says,

10:58hey, a user's just clicked the login button

11:01and they've given me this username and password.

11:04The authentication app says, I'll take it from here.

11:07And that's the end of it.

11:10There is no state that is stored

11:14when there is a API request going back and forth.

11:17Whenever there is data that needs to be stored,

11:21the application itself is going to submit that data

11:25to a database where storage happens.

11:27But finding things like request histories,

11:30like when did auth talk to orders and returns,

11:34that's simply not a thing that's going to happen.

11:37We keep our API requests stateless.

11:42Fire off a request, get a response, tear it down.

11:46That's the end of it.

11:47And when there is data that we the developers say,

11:50nope, we need to store this data,

11:52it goes into a database for storage.

11:55And we can retrieve that data whenever we need,

11:58but it'll be as simple as firing off a request

12:01for that data and then sending it back to the requester

12:04that it originally came from and then tearing it down.

12:07The API requests only lives

12:10for the duration of one request and one response,

12:13and that's the end of it.

12:15So this is now understanding how web-scale applications work

12:19in the era of microservices

12:22in the modern software development world.

0:00Next up, we're talking about the cloud-ish.

0:03We're really talking about data center

0:05and the difference between using the cloud

0:08or own environment, which is what we're talking about

0:11when we say modern software development.

0:13But for the exam purposes,

0:15they really want you to know about public clouds.

0:18I'm talking, of course, about AWS, Azure, GCP,

0:24maybe Vercel for your front-end hosting,

0:27and so on, DigitalOcean, the list goes on and on.

0:30Basically, if you have an application, a app workload,

0:35it makes a lot of sense for a lot of different reasons

0:38to build it for the cloud

0:41for, well, really a list of reasons.

0:44The first one is scalability.

0:49When we look at the cloud,

0:51one of the words that gets used a lot is elastic.

0:55You see the letter E a lot in AWS.

0:58You might be thinking of EC2.

1:00That's the virtual machines that you can spin up in AWS.

1:03It's EC2 because it's Elastic Cloud Compute.

1:07And what makes it so elastic is auto-scaling.

1:12Auto-scaling is a thing that's present in all of these.

1:16And the idea is that we can scale in all four directions.

1:20It's not very hard.

1:22In fact, it's really just a point-and-click operation

1:24to scale a virtual machine up or down.

1:28When we rent an instance, like a virtual machine,

1:31we rent it with a specific size or skew.

1:35Let's say we might start off by renting a large VM,

1:39which might have something like eight CPUs

1:42and 32 gigs of RAM.

1:46And we start using it,

1:47and we realize we're only utilizing 1% of that workload.

1:51It's like, okay, maybe I don't need large.

1:53Maybe I just need a medium or a small VM.

1:56You can literally shut it down,

1:59scale it down to a different size, and start it back up.

2:03That's kind of the beautiful part about the cloud.

2:05And now we pay less per hour

2:08because we scaled it down to something like a small VM,

2:12which might only be two CPUs and eight gigs of RAM.

2:17That makes it elastic in the sense

2:18that we can scale it vertically up or down

2:22with the point of a click or a button.

2:24But the fact of the matter also stands,

2:25we can actually scale horizontally pretty easily too,

2:29especially on web front ends or even microservices,

2:33because if you really think about it,

2:35a microservice is also just a web server.

2:39It's hosting an API instead of a website.

2:42So what we can do is we can spin up

2:45a bunch of virtual machines

2:47and put them behind a load balancer.

2:50Now, whenever you think about that picture

2:52of the microservices scattered everywhere,

2:55you should actually think about this

2:57as multiple machines behind a load balancer

3:01everywhere you look, because that's what it really is.

3:05Again, we can do this with basically not much more

3:09than just a couple points and clicks,

3:11or also using some code.

3:13We could use code to scale it automatically

3:16and do it via DevOps.

3:18If we notice our web traffic

3:20is getting really, really clobbered,

3:22instead of scaling all these VMs up, which we can do,

3:26we can also just deploy more VMs

3:29and they automatically get added behind the load balancer

3:32and we can scale horizontally.

3:34You can actually do both.

3:36You can scale out and up or in and down at the same time,

3:41if that's what you want to do.

3:43The cool thing about it is we can scale

3:46and we're not committing this to scaling permanently.

3:50We're not committing to scaling up

3:51and scaling out permanently.

3:53We can scale up and out for the duration

3:56of two or three hours,

3:57maybe because we made some incredible announcement online

4:00that's generating a lot of web traffic for us.

4:03And then once the traffic dies down, we can just undo it.

4:06We can just roll it back, scale it back in,

4:09if that's what we need to do.

4:11And most of these VM plans are billed per hour.

4:15So we're only going to get billed

4:17for the compute that we actually use.

4:20So scale is a really, really, really big reason.

4:23One of the top reasons to do it.

4:26The second reason is redundancy.

4:31Almost everything that you deploy in the cloud

4:34has some form of redundant version of it going on.

4:38For instance, each of these VMs have disks in them, correct?

4:42Well, almost every time we deploy a disk,

4:45I'm going to say almost a lot,

4:46because you have total control over your deployments.

4:49You don't have to do anything that you don't want to do.

4:52But by default, when we create a disk,

4:55what is really happening back behind the scenes?

4:58It's creating something like a VMDK or a VHDX file,

5:03depending on if it's VMware based or Azure or Hyper-V based.

5:08And this is really just a file.

5:09That file lives on a SAN.

5:12The compute connects over the network

5:15to that SAN to get the disk.

5:17But then that SAN behind the scenes

5:20is going to replicate a copy of this disk

5:23at least two more times within the same data center.

5:26But lots of times we actually can make copies of it

5:29across data centers or even across regions.

5:32The point is, is when you log into this machine,

5:35you're only going to see one data disk

5:37attached to that virtual machine.

5:39But in reality, multiple copies of it

5:42exist behind the scenes,

5:44ensuring that there's a lot of redundancy in place.

5:48There is redundancy in absolutely everything in the cloud,

5:52from compute to storage, to message buses,

5:56to all of that stuff, to network connectivity.

5:58There is redundancy everywhere.

6:01And the big thing that we do is not only can we scale

6:04and right size our application,

6:07but we can also with relative ease,

6:10ensure that we can get five nines of availability

6:15because of all the redundancies in place.

6:18Now there's another really good reason to use the cloud,

6:22but it's kind of a tougher one to actually get to.

6:27And that is cost.

6:29You're going to hear a lot of people on the internet

6:32tell you that the cloud is more expensive

6:35than if you deployed on-premises.

6:37And to some degree, that's right.

6:40The cloud is definitely more expensive

6:43if you rely on infrastructure as a service.

6:46Put it nicely, virtual machines.

6:49It'll probably run you up a good bill if you're doing that.

6:53And the truth of the matter is,

6:54this is how most cloud deployments begin.

6:57You have virtual machines on-premises.

7:00It's not terribly hard to lift

7:03and shift them into the cloud.

7:05Now, they're not super easy either.

7:07There's a lot of content on certification exams

7:10here in CBT Nuggets on how to do it.

7:13You should definitely block out an hour or two

7:16of your time to watch that content

7:18if you ever get into that situation.

7:21And you should definitely proceed

7:23with an extreme amount of caution.

7:25But at the most fundamental oversimplified way

7:28of thinking about it is we're really just copying

7:31a virtual hard drive into the cloud,

7:34then setting up some sort of cluster

7:36and replication service, then failing over to the cloud.

7:40Next thing you know, you've got your same virtual machine

7:43running in the cloud.

7:44And you're like, great,

7:45now I've got the ability to scale it, check.

7:49Let me get my mouse back, scale it.

7:51And we also have redundancy everywhere, check.

7:54We've got both of those things,

7:55but it can rack up a pretty big cost.

7:59The next goal that you should start moving to

8:02is how do I refactor my application?

8:05How do I refactor my workload

8:08to actually work with platform as a service?

8:12This is where the cloud wins.

8:16Where a lot of people fall victim

8:18is they think that the cloud

8:20is meant to replace your core infrastructure.

8:23They think that your cloud

8:24is meant to just run virtual machines,

8:27and that's where your Active Directory

8:28and file share and all of those things should live too.

8:32In my opinion, that is just blatantly wrong.

8:35That is not the case.

8:37I firmly believe that core infrastructure

8:39should be kept as close to the people

8:42who touch it as possible.

8:44That's the worker.

8:45So if you've got Active Directory,

8:47if you've got a file share,

8:48you should keep that close to the people who use it.

8:52Whereas your application, your web-facing application,

8:56that's consumed by consumers.

8:59And the closest way to reach them

9:02is by using the cloud

9:04in conjunction with their content delivery networks

9:08and global distribution systems.

9:11Because virtual machines can be pricey

9:14and honestly somewhat wrong-sized,

9:17it is hard to right-size a virtual machine,

9:20you can use platform as a service.

9:22This is nearly perfect size

9:25for all of the applications.

9:26Lots of times you see this referred to as serverless.

9:31I mean, it's not entirely true.

9:32There's a server and an operating system running somewhere,

9:35but you never touch it.

9:37You're only focused on the workload.

9:40So for instance,

9:41if you are trying to deploy a web application

9:44and you want to use Azure websites,

9:47also known as Azure App Services,

9:50you can deploy an app service resource.

9:54And from there, you never touch the operating system again.

9:57You point something like VS Code

10:00at your Azure App Service to ship the code to,

10:03and next thing you know,

10:04web hosting is done for you.

10:07Azure is hosting your website

10:09and it scales to meet your demand.

10:12It's also more affordable than a virtual machine.

10:15Then you're thinking, okay, well, that's the front end.

10:18What about my microservices?

10:20There are a ton of container resources

10:24and container hosting for you to manage your microservices

10:28and your application.

10:29We're going to talk a lot more about containers

10:31in an upcoming video.

10:32Then you're thinking, okay, great,

10:34but what about the database?

10:35Because data is my most important asset.

10:38Guess what?

10:39They can give you all sorts of different SQL backends

10:43that all you have to do is connect to.

10:46You never touch the operating system.

10:48You don't even touch the SQL instance configuration.

10:51You just connect to the database,

10:53create your tables and start writing data to it.

10:56They also do no SQL backends in database caches

11:00like a Redis cache or document databases.

11:04Things that if you've ever worked with MongoDB,

11:06that would be familiar.

11:08Basically, they're deploying a private instance

11:11of say SQL Server or MongoDB or Redis

11:14that you can connect to,

11:16but you never have the hassle of actually managing

11:19underlying infrastructure or operating system.

11:23You just connect to the application and use it.

11:26And that's almost always more affordable.

11:29And it's almost always right sized for your exact workload.

11:35Because it's relatively easy to get started

11:39for software developers to use Platform as a Service,

11:43this is where your big win is.

11:46Because then you'll accomplish scale, redundancy,

11:50and cost savings at all the same time.

11:54And all of a sudden your microservices

11:57become much easier to manage and scale

11:59because you can actually automate the scaling

12:02as it reacts to workloads.

12:04So this is kind of the point of the cloud.

12:06Now I did say a lot about co-location and stuff like that.

12:10Like I said, there's a lot of people

12:12who are not finding these cost savings in the cloud,

12:16nor are they finding a need

12:18to globally distribute their application.

12:22For those people, it is more affordable

12:25to just buy a server,

12:27rack it in a local co-location data center,

12:30and deploy your applications to it.

12:32If you have the expertise

12:34to manage the underlying operating system

12:36and all the security that goes with it, great.

12:39That's a win for you

12:41because you don't have to refactor

12:42and build for Platform as a Service

12:44only to find out that we're not really trying

12:48to reach a global audience here

12:50and we're spending a lot of money to try to.

12:53It does make sense for a lot of workloads

12:56to revert back from the cloud to co-location.

12:59But for global scale applications,

13:01which is what really the point of this exam reaches,

13:04the cloud is a huge unlock in that case.

0:00Our final thing to talk about are containers and Docker,

0:04which is really the application

0:06that we use to work with containers.

0:08When you're learning about them for the first time,

0:10it's easy to conflate the two,

0:12but they're two separate things.

0:13It's kind of like the difference

0:14between a virtual machine and VMware.

0:18That's really what we're talking about here.

0:20Containers are so interesting,

0:23and Docker is the app that makes them really run and work.

0:28So let's first ask the question,

0:29what is a container?

0:32A container is an application plus

0:37an environment for it to run in all contained in one.

0:43Basically, if you build an app or in particular,

0:47a microservice, if you wrote the code,

0:51then what does it do?

0:52You're going to run it locally on

0:54your computer and test that it works,

0:56but then it's time to deliver it somewhere.

0:58So what is it you used to do?

1:00What is it the way that we used to do things?

1:01Well, you deploy a virtual machine,

1:05have an operating system, patch it,

1:08install all the dependencies like,

1:11oh, this is going to need Java or Node.js or Python version 3.11.

1:17Within that, it'll need this npm package or

1:20this pip package or whatever and all of these additional things.

1:23You'd install all of those dependencies and

1:25then you would copy the code onto that machine and run it.

1:29What if I told you you didn't have to do any of that at all?

1:34What if instead everything that you need to run your app,

1:38like all of the bare minimum kernel of

1:41the operating system and whatever patches it needs,

1:44and whatever dependencies it need,

1:45what if that could all be shipped inside of this little box,

1:50and then that box can be sent,

1:52copies of it can be sent anywhere.

1:55So that we deliver it to these host machines where it needs to run,

2:01and it already has everything that it needs to run inside of it.

2:07So that means I build it one time and deploy it as many times as I want,

2:14and it will always work because it will always

2:17have the same environment wherever it goes.

2:20That is what a container is.

2:22A container is a self-contained app.

2:29That's really what it is.

2:32We use something called a Docker file.

2:39That's one word with a capital D,

2:41that capital D is important.

2:43In this Docker file,

2:45we define where the source code is,

2:49and what kind of environment it needs to build.

2:54We'll specify things like the kernel or operating system,

3:00which is really a very stripped down version of the operating system,

3:05and any node dependencies,

3:08Python dependencies, or any other dependencies.

3:11I'll put DEP right here for dependencies that

3:14you need to have installed in this environment,

3:17and it builds the self-contained self-running application for you.

3:23So how does it then work?

3:25Well, the container really shares the underlying.

3:30So here's my container,

3:32I'll put C, and here's my main operating system.

3:36Underneath the operating system,

3:39you have the raw kernel.

3:41The container piggybacks off of this raw kernel,

3:46and a lot of the compute and operating system doings or

3:50things that it needs happens on the host kernel itself.

3:54The container for all intents and purposes,

3:57usually believes it's just like a virtual machine.

4:00It believes it is a self-isolated instance.

4:04It believes it will have its own IP address.

4:07I got to redo, my mouse got a little messy there.

4:10IP address, its own operating system,

4:14its 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

4:27for as little as 100 megabytes of space,

4:32or RAM, or runtime environment that we need.

4:35They are extremely lightweight.

4:39In fact, like the biggest container I've ever

4:41seen was something like one and a half gigs.

4:44Yes, I know there are probably bigger containers out there,

4:47but 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.

4:58Because it's so lightweight,

5:01it is very, very fast to deploy and scale.

5:08The highest level workflow of it is here's me,

5:11I'm on my laptop,

5:13I build a container.

5:16I then publish that container to some repository.

5:21This can be public or private.

5:23Lots of people use Docker Hub.

5:27Again, I can publish my container to where I can only

5:31privately access it or I can make it public.

5:34Then I go to my target host box,

5:39I log into Docker Hub,

5:42and I pull the container down and run it on each of these machines.

5:47When this happens at scale, for instance,

5:51let's say we're talking microservices in the Cloud once more.

6:00In my Cloud environment,

6:01I can define service A,

6:05service B, service C,

6:10service D, you get the idea,

6:13it goes on for forever.

6:14In the Cloud, I can say this service needs to be deployed with three containers.

6:25I can say three copies of my container behind a load balancer.

6:32I'll make an application that handles, say,

6:35shopping carts, I'll containerize them,

6:41and then I'll have the Cloud automatically deploy

6:45my containers and scale them as need be.

6:51This happens significantly quicker than virtual machine deployment

6:55because everything is already contained inside the container.

7:00All you have to do is simply turn more on.

7:03Starting a container is almost like flipping a light switch.

7:07You can really start an application that quickly.

7:10The same thing will happen for service B.

7:13It'll be behind a load balancer and it'll scale.

7:17This can be something like credit card processing.

7:23Service D can be something like shipping and handling.

7:28I'll containerize that application or

7:33that microservice itself and put it behind a load balancer.

7:37Then comes in service C.

7:39This could be something like a database handler,

7:43where we connect to data or get data from all of

7:46these other services and log into a database and write data there.

7:50We might have one or two instances here.

7:53Maybe they target different databases each behind

7:56the scenes for different types of workloads or data that they might receive.

8:02Now, this is the idea with microservices and containers.

8:06It becomes much more predictable and

8:09easier to containerize an application and deliver it.

8:13We then take the environment and

8:15the operating system entirely out of the equation at this point.

8:20But then it gets even more interesting when we introduce

8:24Kubernetes very frequently abbreviated K8s,

8:28because what happens in

8:31Kubernetes between the K and the S is eight characters.

8:34Kubernetes is like if I were again comparing this to virtual machines,

8:40this would be like the VMware VCSA,

8:44where we have automatic scaling and workloads and migrations and balancing.

8:50That is what Kubernetes does.

8:52Kubernetes is your container orchestrator.

8:56Kubernetes is what handles the deployment of

9:00load balancing and sharing of applications and services,

9:05and allowing connectivity between the services to happen.

9:09You are not responsible for manually defining each one of

9:13these services and manually defining how they connect to each other,

9:17and manually scaling them,

9:18and manually managing the load balancing of traffic,

9:21and manually handling whether traffic is

9:23allowed in from the public or from these services really.

9:25This is what Kubernetes does.

9:28You tell Kubernetes what it is that you

9:30want and how a service should behave,

9:33and it orchestrates the rest for you.

9:36It ultimately manages all of

9:40the container hosts that your containers run on.

9:46It says these workloads should be on these hosts,

9:51and if it finds that a host is overwhelmed,

9:53it can migrate workloads,

9:55it can scale workloads,

9:57it again handles all the networking that your service

10:01need or your services need to make your application work.

10:05When you start thinking about how we got here,

10:08source control is where it all begins.

10:11It's what tracks changes from the line-by-line code itself.

10:15From there, using CICD and DevOps pipelines,

10:20source control events can trigger the building of code.

10:24In this case, it can trigger the building and testing of containers.

10:30When those containers are deemed fit,

10:33we can deliver those containers to their in-target sources.

10:37In a lot of cases,

10:39that's delivering them to Cloud resources,

10:43specifically Cloud Kubernetes environments,

10:46where Kubernetes is managing all of

10:49these containers that are newly built thanks to source code and

10:52DevOps and delivering them to stable environments.

10:57Yeah, it's big.

10:59We're talking about big applications in this entire course.

11:03We're not talking about small apps,

11:04we're talking about big ones and the delivery of

11:08incremental line-by-line code all the way through

11:12to your big service deployment in your applications.

11:15That's why you're here.

11:17This is a skill that is going to be hard for AI to take.

11:22Although AI can absolutely augment each and every one of

11:26these steps and you can leverage

11:28it to become a better DevOps engineer.

11:31We will begin focusing on all of this in the upcoming videos.

11:35For now, we focused in on

11:37what modern software development really entails.

11:40I hope this has been informative for you and

11:42I'd like to thank you for viewing.

0:01Let's make sure we understand the concepts in modern software development.

0:05Like I say, this is a bit of a moving target in the age of AI.

0:09But the tools are still the same, at least for now.

0:12We still use containers. We still build for microservices.

0:17We still build for the cloud and platform as a service.

0:21So let's make sure we understand it.

0:23A company has a large application where a single bug causes the entire system to crash.

0:30They want to redesign it so that individual components can fail without bringing down the whole system.

0:36Which architecture should they adopt?

0:39Well, monolithic architecture is the single bug that takes the whole thing down.

0:43Cloud-hosted virtual machines? You're getting closer.

0:47There's scalability there. There's redundancy there.

0:50But it can still take a whole app down with a single bug.

0:53Multi-threaded app that runs on multiple servers? Not really what we're looking for here.

0:59We want to break the whole thing apart into individual services.

1:03That 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.

1:15A startup expects unpredictable traffic spikes and wants to automatically scale resources up and down

1:22based on demand without buying physical servers.

1:26Which cloud benefit best meets this requirement?

1:29Static infrastructure? Yes, you can rent physical servers from your cloud provider.

1:36Manual provisioning? Well, that doesn't really automatically scale. That's manually scaling.

1:41Elastic scalability? That's really what we're looking for here.

1:45There's also vertical scaling only, which is scaling up or down,

1:49but automatically scaling allows you to scale in any direction.

1:53In or out, basically horizontally behind load balancers,

1:56or up and down to also increase the size of your machines.

2:01A team packages their application so it runs the same way on a developer laptop and in production.

2:08They also want a system that can automatically restart failed containers

2:13and distribute traffic across them.

2:16Which combination best fits this scenario?

2:19Bare metal servers only? Virtual machines managed by a controller?

2:25FTP deployment with cron jobs? Or containers with Kubernetes orchestration?

2:30This is it. Containers with Kubernetes orchestration.

2:34We should have known that the moment they said they're packaging an app

2:37so it runs the same way on a developer laptop as in production.

2:42It's the same environment when we use a container.

2:45Automatically restarting containers and load balancing them?

2:49That's what Kubernetes' job is.

2:51So this has been reinforcing what we learned about modern software development.