Introducing DevOps Core Principles

0:00[AUDIO LOGO] Welcome to the AZ-400 certification playlist here at CBT Nuggets. My name is Knox Hutchinson, and I will be your instructor on this journey. DevOps, is a tremendous phenomenon. It's been going on for about a decade now, and one of the cool things about it is that DevOps itself is continuing to get better and better and better. Which is interesting because that's the point of DevOps, it's to make your actual code shipment and operations deployments, all go better and better and better.

0:41So in that way, in the sense that DevOps keeps getting better, and we keep getting better because we're using DevOps, it's a cycle, it's a circle, and you're going to see cycles and circles a whole lot in this particular set of videos. It's all about understanding why do we need DevOps? Why do we care? What even is DevOps? And what makes up DevOps? These are really important, fundamental things to understand before we start jumping into portals and clicking around and hacking away at things.

1:13So in this set of videos, we're going to talk about the core principles of DevOps and how DevOps is all about striving for continual improvement in faster deployment times, and more secure code. We'll even talk about management styles that really facilitate a DevOps lifestyle. So get ready as we start to explore more about what DevOps is that it sets up an introduction for the AZ-400 certification exam. Let's go.

0:00[AUDIO LOGO] So what really is DevOps? Of course, there is a technical definition for what DevOps is. But really the question we should be asking is, why DevOps? What does DevOps seek to accomplish? And why are organizations embracing it, especially ones that develop software in-house? That's what this video is going to cover. Let's start to introduce the core principles of DevOps.

0:31So I want you to take a moment to define what you think DevOps is. What is DevOps? Me personally when I look at this, I'm like, well, let's just take it at the simplest level. I see dev, and I see ops. So it must be something like the Fusion of my development lifecycle in conjunction with my businesses' operations. A lot of times, people also make ops synonymous with infrastructure.

1:06Put another way, that's things like networking and server, server development. And that's true. I would say that infrastructure is part of your businesses' operations. But there's also things like analytics. Your business intelligence team are part of the businesses' operations because they steer the direction that you're going with. Even things like accounting could be part-- considered part of your actual operations. So when I look at the surface level, I'm thinking, OK, well it must be the fusing of my businesses' operations directly with my software development lifecycle.

1:44And that's pretty true. The idea with software development now isn't to go out and create the world's greatest application, because people want to buy the world's greatest application. No. Instead software and development is now seen as a tool in every single business that we can develop to make the business better. If you think about tools, in general, you always want to use the right tool for the job, right? If I'm trying to get a nail in the wall, I want to use a hammer.

2:16If I'm trying to turn a Philips head screw, I'm going to use a Phillips head screwdriver. Well, with software and businesses, business' needs are complex. Therefore, we have to create software to solve our businesses' problems. So we have to look at what operations our business' needs help with in the first place. So oftentimes, we see DevOps as this never ending cycle of development, of software development, where it's we're developing software that is constantly being iterated on and improved.

2:53And we will never be able to say that we're truly done. This is actually an important like psychological thing to wrap your head around as a software developer is that the very essence of DevOps and the very essence of a business is that they live on eternally. So your work will never ever be done. But what we can do is we can break the work down into smaller pieces. So when we start to think about what it is that we need to do, we start to plan out what it is that we want to build.

3:26And why we need to build it. Why is it important? We will then go into a phase where we build it. That's kind of the idea. And once it's built, this is going to be in like a local environment or a dev environment. This isn't going to be shipped to production yet. Then we move on to continuous integration. That means this is where we start to integrate what we've build into our current code base, and see that it's going to work OK side-by-side.

3:58Once we know that it's going to work OK, we move on to deployment, where we actually see it is now in production, and it has been moved smoothly into the production environment. Then we operate, which means we monitor or maintain the application itself. And once it's been operating-- it's operational, and it's maintained, what starts the loop all over again? I'm kind of going to jump over here for a second.

4:29That's feedback. We receive feedback for the work we did. And then we get to plan what the next thing is that we want to do. This is a really big thing to wrap your head around. And this really is the core of DevOps. It really is it. It's this whole figure process here, where we plan our work, then we build it locally, then we ship the code, then it gets deployed in production, then we maintain the code and operate it and see how it's going, and then we receive feedback so that we know what to do next.

5:08And a really important part about this entire process right here is to do things in small increments, or do it incrementally. That way, we can ship small pieces at a time, get feedback, and learn how to adjust it. We call this the cycle. What a clever name, right? And this software development lifecycle is oftentimes likened to something called the OODA loop. I brought up Wikipedia here because the OODA loop is really well-known.

5:41There's a lot of history here that's actually really cool. The OODA loop was originally designed for like fighter pilots. You can kind of see the section right here, so that they could very quickly react to very bad situations, and learn how they should handle these situations before they get shot out of the sky. In the OODA loop, I'm going to write OODA right here, what we have here is we have observed-- that's what we're trying to do. We're going to observe the environment that we're working in as we walk through the figure 8 that we just covered here.

6:17This figure 8 here represents one life cycle of a bit of software that we've just gone through. So we're observing what is happening in the business. Then we orient ourselves around what it is that we're trying to accomplish. We then decide what we need to do. And then we act. So in observation, we're looking at business needs. We're responding to the market events. We're responding to customer feedback or internal feedback.

6:51In orientation, we're trying to figure out what are the possible solutions to all of these events? And what are the things that we could even do in the first place to solve any of the problems that we're having? In decide, we decide what it is that we're going to commit our time to doing. And then in act, we go forth and we conquer. And this OODA cycle is really, really, really important. And you oftentimes want to make your decisions with a couple of different factors.

7:24You have a quantitative factor, meaning there is some measure or some statistic that we are tracking. We are collecting data on how each one of these life cycles is going. There's also a qualitative factor, meaning we are receiving somebody's opinion whenever we actually deploy these items here. So this all comes down to what objectives you're trying to meet.

7:54Is the key objective here to increase shipment time? The time it takes to deliver our code or even deliver a product out there in the real world? Or is it more of an aesthetic thing, where we want to make people really, really happy to use our product? These are the types of feedbacks that we're going to be monitoring as we go through our OODA. Now the next big thing that you need to understand is, what are the possible outcomes, or really, what happens in our feedback phase?

8:27That's going to be a really important thing to wrap your head around. At the end of the day, Microsoft likes to tell us that there are three outcomes that there could be. The outcome could be mission accomplished. It was good. We actually learned from what it was that we actually shipped and deployed. The outcome met our objective. And the outcome was really, really good. Otherwise, we have mission failure. The outcome was not achieved.

8:57This was a bad outcome from the shipment that we've done, or there is no change at all. The outcome didn't really go in either direction. It was neither good nor bad. And part of the things that you want to do in your DevOps lifecycle when we're actually learning about how we can streamline shipping code quickly as possible is whenever there is a mission accomplishment, we want to do more of those types of things. And whenever there's a failure, there's this awesome term that's out there, we want to fail fast.

9:33A nice way of putting this is we want to get back on our feet and recover as quickly as possible. We want to say that didn't work. We're going to do the opposite of that next time. We're going to do the thing that absolutely does work. We're going to learn from this and improve upon it on the next time. The ultimate goal here is that when we deploy small increments of code and we receive feedback, and we learn from this quantitative or qualitative feedback, and we assess whether the mission was accomplished or a failure or there was no change at all, we want to ship another one quicker next time.

10:09And we want to lean into the ones where there are accomplishments. The goal is always to have quicker deployments in shipments of things that are working well, of things that are going well, whenever we have a mission accomplishment. So when we're developing our own code in-house, when we're developing our own software in-house, we want to understand, first of all, that we will never be done doing it. So what we're going to do is we're just going to build it one small piece at a time.

10:42We're going to ship it and streamline the deployment of it in such a way that it integrates smoothly into the production environment. And then we will assess based on the feedback if that shipment of that small integral piece was really, really working. Then we kind of fork our direction based on the results that we're receiving, if the mission was accomplished or not from there. So now that we understand kind of what DevOps is seeking to do, in the next video, we're going to talk about methods of getting there.

11:17And some of the tools that we can use to get there. In particular, I'm going to be focusing in on this section that we were talking about here, and that was continuous integration and continuous deployment. For now, this introduces what DevOps is. I hope this has been informative for you. And I'd like to thank you for viewing.

0:06One of the things that makes DevOps DevOps is CI/CD. Now that stands for continuous integration and continuous development. While oftentimes, these are written out as CI/CD, and it makes you think it's one thing, it's really not. It's two separate things. Continuous integration is different from continuous deployment. And in this video, we're going to set out to demystify what CI/CD is. Let's go. So I mentioned this before, and I'm going to say it again.

0:36We see all the time. We see it written out as CICD, or sometimes CI/CD. But it's very important to wrap your head around the simple concept that these two things, while oftentimes they're done at the same time, they are not the same thing. First, let's unpack what continuous integration, or the CI portion, really is. When we have continuous integration, what are we really talking about?

1:08Well, we have a really big application, or maybe our really big application, in actuality, there's a bunch of small applications that work together. That's really what we're looking at right here is, in most modern enterprise architectures, it's really something like this now. The cloud really brought this along, where we have what looks like one big application, but it's actually a bunch of really small applications.

1:39A great example of this is something like amazon.com. To the end user, looks like one website. Under the hood, it's really a ton of back end applications that are all working together to make your shopping and checkout and shipping experience as smooth as possible. So when we want to roll out new features-- let's call this feature-- I'll give this a name. We'll call this Feature 1A, something really simple like that-- what Feature 1A is going to do is it's going to enhance our application.

2:14But we need to figure out, first of all, if that's going to break anything. That's a really important thing to understand. So what feature 1A, what we're doing here is we write the code for Feature 1A separately from any running application that we have right now. So what they actually call this is branching. Usually, that's what we're talking about here. We've basically taken a copy of our current code and are editing it in a safe, nonproduction environment.

2:48So when we want to start to perform integration, what we're really talking about is merging our feature code into an existing branch of the application. We're merging the code into an existing running production or running environment, whether it's production, development, or test environment. Now 99.9% of the time, that's exactly what's going to happen. We're going to very carefully increment our way into the actual environment.

3:23So continuous integration is really focused in on getting the code starting to merge in, starting probably with a dev environment, then moving to a test environment, before we finally get it into a production environment. You may be thinking to yourself, well, how is that, at that point, how has it not been delivered? The simplest way to put that is it simply hasn't been turned on yet. If we are shipping code that only impacts, let's say, this tiny little application right here, we may not be telling the other applications, go look at that new code.

4:04It's very simple in that regard that we just simply haven't told the rest of the environment that has been a change. This is where continuous delivery really comes into play. This is where we're basically turning everything on. This is where we deliver the software solution to a test or production environment. Or, put another way, we're delivering this new feature to the end user who's actually going to use it. And a big part of all of this process is the fact that, at each stage, at each step of the way, if we're starting off with continuous integration into the dev environment, we can review how well did that go?

4:48We get feedback at that point. Then, we move it into the test environment. Guess what? We get feedback again, and we can iterate on this process as it goes along-- guess what-- production environment. We can get feedback as to how that integration went. Then, when it comes time for actual deployment, we can yet again deploy it to the dev environment. Did it go well? Great. Let's get some feedback about how that went. Did it break anything else? Should we improve upon the actual deployment of itself?

5:19Then, we move it down to the test environment. And, finally, when we're ready to turn it on, we move it into the production environment. The continuous integration and continuous deployment pipeline has really given us a bunch of different things. The first one is, effectively, if this is done right, we can do things with no downtime because we've been testing it the whole way, through dev and test and production and iterating on it, until it's actually ready for the actual deployment to the production pipeline itself.

5:54This is why you see applications, like Amazon, that are improving all of the time-- rolling out new UIs, new features, new buttons. But you never actually see those apps go down, do you? That's because they're going through a CI/CD pipeline so that the code can merge straight into production in a smooth, secure way, without any issues, because all of those issues had been handled up until that point. So what kinds of CI/CD pipelines are you going to learn about in this particular course?

6:29You're, of course, going to learn about GitHub and Azure DevOps. In particular, GitHub has a pipeline called Actions, and in Azure DevOps, they're very cleverly called Pipelines. But you see pipelines everywhere nowadays, even outside of DevOps tools like these. You see pipelines in Power BI services that are out there now. You see pipelines and some open source software operations. You see pipelines in Azure development resources, like Azure app services, with their deployment slots.

7:06There's a lot of different ways that pipelines are coming up. So, with that being said, this introduces CI/CD. CI is all about merging the code in to the existing environments to find, at an early stage, any bugs or defects in the code or the actual deployment process itself. That way, we don't take down the application and production. Once we know it's looking good, we move on to continuous deployment, where we can get the feature and the code push to a production environment where it's usable by the end user.

7:42The feature is now live. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] So DevOps is an entirely different style of doing your work and shipping your code. But with that comes an entirely different style of management that the organization should actually employ to facilitate a DevOps work style. And the one that many organizations have gravitated to is Agile. Now, agile is a very large and complicated thing.

0:32There's certification exams around just being an Agile member. And we have content here on CBT Nuggets that goes deep into how Agile works. And I'd really encourage you to watch that if you're serious about working in a DevOps environment, because that will help you understand the management styles that you're going to work with. That being said, we're going to take a little bit of a crash course as to how Agile can be used to facilitate DevOps work styles. Let's go. So how do we keep on track with all of these iterations and changes and deployments?

1:06Really, that is what gave birth to the Agile management system. Agile, at the end of the day, really tries to do one important thing-- deliver value. Important term there-- deliver value as quickly as possible while reducing the headaches. Notice I didn't say deliver software, because it's not shipping full-blown applications that we're trying to do.

1:37No, we're trying to iterate on the software that we've already created. Now sure, sometimes there's going to be a greenfield deployment where we're developing something from scratch. But usually, what we're trying to do is build one gigantic application. And if this little portion right here could be better this week, maybe that's our mission for this week. We can add value to the organization by working on this little piece and getting it operating a little bit better this week.

2:07Now, Agile is a management style or, really, a management principle, at the end of the day. Instead of working on something for months or even years, instead, what we're trying to do is we're simply trying to break down our task into small, digestible tasks that we can deliver very quickly. I know that may seem silly. It may seem like, well, the only thing that I could get done this week is something that's really easy.

2:38Well, yeah, that's kind of the goal. We've got a team, a group of people here. And what we can do is we can just look at what can each individual person accomplish this week that could possibly add value to our overall mission statement here. And usually, that small piece is just as digestible or small as you're thinking of. It's kind of like you the learner here at CBT Nuggets. You're going for the AZ-400 certification exam, right?

3:10So you download the entire blueprint. And in that blueprint, you've got modules or domains. And inside those modules or domains are all of these bullet points of things that you have to learn. And inside those bullet points, there's-- accomplish task A and task B by doing task C, or something like that, one of those individual bullet points. What if I told you that, yeah, your end objective is the AZ-400 certification exam. And you're going to get there at some point.

3:41But for this week, let's just focus on task C, just this week, or maybe even just the next few days. Just focus on task C. And if you accomplish task C, great. Next week, we'll move on to task B. And then next week, we'll move on to task A. And then after three weeks, oh, look at that, we've done this line. And eventually, at some point, you will have gotten acclimated to all of the stuff that you need to know for the AZ-400 certification exam.

4:13That's the point of Agile. It is a bit of a mental shift to stop thinking so big and to stop looking at the goal of the AZ-400 and start thinking about, well, my goal this week is really just this bullet point. And that's what Agile is trying to do. So when we are working on software and we've got this process right here and it felt really big, well, now, what if my goal for this week was just to enhance this little corner of the application?

4:45Well, guess what, that falls into my life cycle. I can plan for it. I can build it. I can move it into CI. I can move it into CD. I can operate it. And then I can get feedback as to how it went. Did it go well? Yeah. Let's see what we can do next week that's on the same vein, and then the next week that's on the same vein, and then the next week that's on the same vein. And if any of those didn't go well, we look at what went wrong. And how do we improve upon it? Let's fail fast. But the interesting thing about Agile is that Agile isn't just one method of doing it.

5:19In fact, Agile often goes hand in hand with a management technique called scrum. Now, scrum is a much more rigidly defined version of how your Agile management style should work. For instance, we define work in sprints. A sprint is oftentimes goes hand in hand with a calendar week, usually one week. Sometimes it can be more. Sometimes it can be two weeks. Or sometimes it can be less.

5:50But in this case, we're saying we're going to start the week off with a sprint that's going to be one week long. You have a stand-up meeting where everybody on the scrum team gets together, and they determine, what are we going to do for this particular week? What business objective is it going to accomplish? The scrum team has carefully defined roles. We have a scrum master. What a cool name, right? Then we have a scrum product owner.

6:23This is the person who actually has some say into why we're doing what we're doing. What is the actual business need? And then we actually have the scrum dev team. They are the people who get stuff done. It's kind of interesting how rigid scrum actually is. In a scrum outline like this, we even define things like the dev team will have no more than seven people on it. The product owner will be two people. The scrum master will be one.

6:54And the scrum master is enforcing the rules of scrum and adhering to scrum best practices throughout the rest of the team. It's really that rigid and that serious. We even then define things like, what is going to be our work backlog? This is stuff that product owners bring to the table. These are the things that we say, we want these done. The actual end goal itself is known as the increment. This is the product that's going to be delivered at the end of the sprint.

7:27Then we actually have sprint cycles. So within this one week, what takes place? We have sprint planning. Then we have a daily scrum, where each of the members of the scrum team talk about what it is that they've done to accomplish work for the sprint backlog. Then towards the end of the scrum event, after the product is being shipped, we do a scrum review or a sprint review. And then we can even go into retroactively looking at what has happened in the actual previous scrum.

8:03How did the scrum go? So when a project is considering adopting an Agile workflow or an Agile work style but they don't have all of the experience needed to define the rules themselves, scrum is usually what they go with because scrum, even though there's a lot of moving parts, at the end of the day, it's relatively easy to understand. You have scrum team members. You have sprints. You have a workflow. And then you actually have the artifacts of the scrum themselves.

8:37So all of it actually comes together in a really seamless way. It does take a little while, maybe a quarter or two, for a team to really find that rhythm. One of the most hard things for a team that is transitioning to Agile to figure out is what is actually achievable in one week. How do we break the big work that we've used to been doing down into even smaller increments? That's what Agile is really all about. And that really is one of the hard things to wrap your head around and adjust to.

9:08But once you've got that figured out, work starts happening a lot quicker. And the cool thing about it is when the work gets broken down into smaller pieces, we can adjust and adapt to what is happening in our entire business on a week-by-week basis. We're working on something this sprint. But next week, we can work on something completely different. And that's kind of a cool thing at the end of the day. And that's how scrum really goes back to benefiting DevOps.

9:39It's all about shipping, receiving feedback, and iterating on that shipment. When we break the work down into small sprints, we can iterate as a team a lot quicker. So this is why we see Agile and scrum coming together very frequently in a DevOps environment. I hope this has been informative for you, and I'd like to thank you for viewing.

0:06At the heart of everything, with all of our code and with all of our CI/CD pipelines and with all of our DevOps work styles and lifestyles and everything, lives source control. Source control is the source of truth. And it is how we, as developers and infrastructure engineers, can all collaborate on the same thing at the same time. Now source control is, again, a major topic. And we're going to dig a lot deeper into how different kinds of source control work as we progress through this set of videos.

0:42For now, let's just implement and introduce the fundamental ideas of source control. Let's go. So what is source control? That is a big topic that, quite frankly, we're just going to introduce it in this video and then build upon it and build upon it and build upon it and build upon it throughout pretty much the entire series that we're going to be talking about, including some dedicated content on just getting familiar with one of the most important kinds of source control, and that is Git.

1:15Now you may be thinking to yourself, well, I've heard of GitHub. Is that the same thing? No, GitHub is a hub for Git. Git is what actually keeps track of all of the times our code changes. For instance, we have code that we have created that runs a production application. Git can take that code and say, all right, this is the starting point. This is going to be the production code in its current state today.

1:49Then we, the developers, can start working on, like I said before, branches. For instance, I may create a branch for a shopping cart feature. So I'll call this shop cart branch. So what does that really doing? Well, it's taking this application right here and creating a copy of all of the code and storing that code in what we call the branch. All of the developers who are associated with working on this shopping cart can then make a copy of that code right here to their local computers, like their desktops or their laptops.

2:34And they can edit that code locally on their computer. When they're ready, when they're like, OK, I think this is good to go, they can choose to then push their changes back to the branch itself. And the cool thing about Git, at this point, when it's pushing all of these changes, is first of all, every time a change gets shipped back to this particular branch, that is logged. It is effectively calling it a version.

3:04And in that version, it can track every single change that took place in that branch. So as this developer right here edits it's one line of code on their local computer, and they push it back to the branch, that push action that took place right there, it's called a commit. Every time that developer creates a commit to update this current branch with their changes, that commit is logged. And what that commit did-- specifically, any lines that it deleted, any lines that it added, any new files that it added-- all of that is stored in the log of that commit.

3:45So all of these developers can work on their code locally on their computer and push all of their commits back into the branch whenever they're ready. So the big thing that get does right out of the gate is managing all of these commits, logging all of these commits and tracking the differences. On top of that, it has conflict resolution. If this developer here edits line 2,030, and this developer here at it's line 2,030, and they said, this one is supposed to delete something, and this one says, no, this one's supposed to edit something, there's a mechanism built into Git for us to actually handle this conflict.

4:32We can actually manage which one should win, and we can do this in an automated fashion if that's what we want to do. That's part of the CI/CD pipeline. But we don't have to. We can manage it manually if that's what we want to do. Meanwhile, over here, we may be working on something entirely different. For instance, after someone is paid for their product, we may have to now handle shipment of the product. So we'll create a shipment branch, and an entirely different set of developers is over here working on the shipment branch.

5:07And, again, these branches, at this point in time where they live, don't impact the actual production running code at all. That's a big takeaway right here is, now, developers can work on pieces of the application. And when they're ready, they can request that this branch gets pulled into the main code and run into production. Of course, that would be handled in phases two. We could pull that code into the dev environment first, then the test environment, then the production environment, and handle the continuous integration and deployment of the code.

5:47This is all done thanks to the power of Git. Git is the open source framework that makes all of this version control and tracking possible. I didn't even go into the big stuff like handling rollbacks or reverting to previous commits if that's what we wanted to do. You can do all-- Git is extremely powerful, and all of the things that I'm telling you right now are barely scratching on the surface. Now, typically, in an enterprise, this is done in a private fashion.

6:21The central repository of code is handled and held on a private server. The Git tracking mechanism is all managed on the private server that's tracking changes of all of the code and all of the branches and everything like that. But the advent of the cloud in general made moving resources into the cloud a whole heck of a lot easier. So now what we can do, instead of actually having all of our code living on a private server, we can actually put it on a cloud-hosted application.

6:55This is where GitHub starts to come into play. Let me bring it down here on the screen and clear the screen for just a second. This is my personal GitHub, github.com/dataknox. When you see these repositories here, you should think of these as individual applications, like so. If I scroll down here, we can see things like individual applications. Let's pick on shadow-drive right here. Here's all of the code that makes up shadow-drive. Now if I wanted to, I could make this a private repository, meaning only people that I grant access to can actually see the underlying code and interact with it.

7:36Instead, one of the cool things about GitHub is that almost everything I get-- I say that, that's not true-- but a lot of the stuff on GitHub, where GitHub really got its notoriety, is that a lot of these repositories are public. And that oftentimes means they are open source software. So anybody around the world can come along to the code button right here and clone this code straight down to their local computer. I want to put computer right here. And they can make changes locally on this computer if they want.

8:09And when they're ready, they can go through a process-- it is a process. We'll talk about that process when the time comes-- of pushing their changes back into the main repository. That's what makes it open source, the fact that anybody can copy the code and work on it. And we as people, we as the human race, have all been working together to create applications and code. So, again, this is just a crash course for what source control really is.

8:42Source control, sometimes known as version control-- at the end of the day, what it's really trying to do is keep track of changes that individual developers are making to a central repository of code files. And we can keep track of those changes by using Git. And we can manage how we're allowing changes to be pulled into our main code repository, as well as handling conflicts, and everything that you're going to learn about when the time comes.

9:13For now, this has just been Introducing Source Control. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] The thing that really made DevOps come to be DevOps, is the fact that virtualization was created. When I say virtualization, I mean every single server that we deploy now isn't a physical standalone server. Instead, we can take one big physical server and dice it up into little, bitty virtual servers. But beyond that, we even introduce something called containers.

0:31And that really is the next evolution of virtualization that's happening. The fact that we have all of these things, these virtualized virtual machines and containers that we can spin up and tear down at any moment's notice, gave us the ability to introduce infrastructure as code. Whenever developers need new servers, they can just add it to their code. And it deploys the entire environment for them. So in this video, we're going to take a careful look about how virtualization and infrastructure as code really came together to define one of the most critical parts of DevOps.

1:08Let's go. So one of the things that you find out really quickly when you start working with DevOps is that whole Ops sign. In fact, I'm going to use a better color than yellow there. It's that whole Ops sign. All of our code has to run on top of something. It has to run on top of servers, typically. Why? Because servers oftentimes have two power supplies. And those power supplies plug into two different power circuits from two different energy providers.

1:41And sometimes, they even plug into two different battery backups, like so. So if one of those goes out, they've still got power no matter what. Then in a data center, where they all run, there's two different AC units blowing cool air down on those servers. And the servers' network has two different, or maybe four different, uplink connections into the actual network backbone itself, which has two different ISPs. You get the idea. The big thing about servers is really that not only that they're very, very powerful computers, but we run them in data centers to keep them alive because we really like our applications.

2:19We're proud of our applications. And we don't want people showing up to our desk going, hey, why is the application down? So it's a really important thing to understand that every time we need to deploy our application, we're not going to drive across town to deploy, to physically install a new server. No. Instead, now, we can use software. Like what we're seeing on the screen here, VMware's ESXi, this is actually an operating system. VMware's ESXi, that gets installed on a server.

2:51So when I install VSXi on my server that you're seeing here, I now have the ability to create little mini servers all on this big, physical piece of hardware. And for all intents and purposes, these mini servers aren't like special mini servers. They believe they're full-blown servers. For instance, look at this. You see I've got FILE-NUGs selected here. If I bring up the console, FILE-NUG, look, it's Windows Server. I can log into it. And there's not a dialed-down version of Windows Server.

3:22It's just Windows Server. So I can install, really, whatever I want or create any servers that I want on this ESXi server as long as I've got enough power to do it. Now, if I look at this particular server here, I've got 28 CPUs, 288 gigs of RAM. And I've got terabytes of disk space that are available to me on this. So it's nothing for me to spin up some small domain controller servers, or SQL servers, or file share servers.

3:53I can absolutely do that with no issue here. And the even cooler thing about that is ESXi exposes an API. So if I wanted to write code that could react to my code that I'm trying to ship, for instance, maybe I'm trying to ship a new feature, but that new feature requires its own underlying servers, part of that code is I could tell this API, I'm going to need you to deploy some new servers for me.

4:24And ESXi can handle creating the new servers from a template that I wanted to actually use. That's a major, major part of DevOps is the fact that we can now tightly integrate the code that I'm shipping with the actual infrastructure that it's running here. Now, beyond that, this was the first phase of software and virtualization was that we were able to take a physical server, like I have here, and break it down into smaller pieces. But then came along this thing, you've probably heard of it, called the cloud.

4:59And the big thing about the cloud is now, we can use other people's hardware. And their hardware is a lot better than mine because they're constantly recycling it all the time. And I don't have to manage. With this ESXi server, I still have to manage this physical server. If a disk goes out, I have to fix it. But with the cloud, I don't. I can simply deploy virtual machines, like I've done right here, with a click of a button or, again, using APIs. I could tightly couple in my entire Azure environment, if that's what I wanted to do, with my code.

5:36So as I need to scale my resources for new code features, whether up, down, in, or out-- we'll talk about all the differences about those-- I can use APIs and code to actually define how my infrastructure should be deployed and configured. The other big benefit to the cloud is the fact that when we deploy virtual machines or other resources, we only get billed for what we use. You can see, right now, mine is actually stopped.

6:08That means I'm not being built for this virtual machine, at least not for the compute portion of it. Sure, it's taking up a little bit of storage. And I'm borrowing an IP address. But for the most part, I'm not actually racking up a bill right now because this virtual machine has been deallocated. It's not actually allocated to a physical server in Azure's data centers right now. But when I want to start it up again, I can turn it on. It'll simply spin up my virtual machine in a matter of seconds. And then I'll start incurring a bill for it.

6:39And that's actually a pretty good deal, if you ask me. The fact that I only pay for what I actually use is a big, big part of it. But then take it a bit further. If I actually start working with-- let's go back to this environment here. If I actually start developing code using something like a SQL server, like I have here-- I've installed SQL server on this Windows Server machine. Now, I'm ready to say, you know what, the code changes that I made to my SQL server environment-- I created a new database, added all these tables, added an index to the tables-- now, I'm ready to ship that out into my production code.

7:16What are some of the issues that can start to arise? Well, I've got OS versions in the mix now. I've got SQL versions in the mix now. I've got all sorts of factors like .Net versions, and runtime versions, and, oh, wait. Now, SQL actually can work on Linux. You see what I mean? All of a sudden, these versionings that I have in my development environment might not match my test or production environment. And I can start to run into a major headache because now, I have to keep all of my virtual machines consistent from one environment to the next.

7:53And that can become a real problem. This is where containers really started to shine. Along came something called Docker. And I'm going to jump back to this code sample for a second here and jump back to my repositories. So along came something called Docker. In fact, there's a really funny meme where it's a guy who's talking to another guy and he's like, oh it doesn't work on my computer. And then the other guy says, well, it works on my computer. And then the first guy says, well, then we're going to ship your computer.

8:24That's kind of the joke that Docker is all about. Docker is where we can define our application using some basic code and ship the entire application environment along with it. That includes the operating systems-- well, it's sort of like including the operating system itself. So when I install a new server, and on the server I run Linux, I can now create an application that's going to run on top of this.

8:57And I'll just tell my container, borrow your underlying Linux operating system's kernel. And that's how containers actually work. They're extremely lightweight. Or they can be extremely lightweight. And they can be deployed in a matter of seconds, because all it really does is it says, create an isolated compute environment. This container right here, for all intents and purposes, is a completely separate computing environment from the underlying operating system itself.

9:31But we're going to borrow its kernel just so that we can actually run the processes. It will get its own IP address if we want it to. We can configure things like that. We can run applications side-by-side in different containers. And that's kind of the majesty of it. We can run containers on top of virtual machines. We can spin up multiple copies of the exact same container and then load balance across it. That's really kind of the beautiful thing here.

10:02Let me show you an example of where I created a very basic container for a very similar purpose. I was using SQL as my example there. Well, check this out. I've got a SQL server container that includes the Star Wars database. Here's the T-SQL commands that can create the database. But here's the actual backup of the database itself. So if I look at my shell script here, you can see exactly what it does. It says, get the Microsoft SQL server image that's running on Ubuntu.

10:34Then deploy SQL server with these basic configurations. So it downloads the image and then runs the Docker image. So now we've got an empty SQL server that's up and running in your environment. We then use these two commands to copy the local Star Wars backup into the container, because it's an isolated environment. And then we tell the Docker command line to run these exact commands on the actual container SQL environment.

11:07You can see, it's doing restore the files and then restore the database. So this runs an isolated SQL server on Linux in an isolated environment. Outside of this container, I can open up SSMS on my computer and connect into that container. And I've got a lightweight way to explore and learn how SQL server works. So again, we're going to learn a lot more about how containers work as we progress along through this playlist.

11:42It was important to me to actually set up just at a high level what containers really do. It's all about taking everything that we need to create an application, defining its own environment, like versioning and everything like that. And all of that is contained and held inside the container. And as long as it can get access to the kernel, which it will by default, then the container can run. It can run in an environment that is different from the underlying operating systems environment.

12:13And because of that, we've gotten really good at DevOps of shipping containers and editing code within containers. So this has been introducing how containers and virtualization play a mix in DevOps. I hope this has been informative for you. And I'd like to thank you for viewing.