Hey, guys, we are recording this video session, so you will have a copy at the end. So let's begin. So what I plan to go over today is some examples. And what we intend to do is, like, you know, in the examples that we have had up until now, we draw some, you know, illustrations of diagrams of things connected appropriately, you know, people visiting load balancers, machines, on, you know, a variety of scenarios of usage. So what I want to be able to do is imagine a situation when you want to quickly reproduce something that is already designed by you. So there are two types of scenarios, actually, let me define those scenarios clearly. So we have, let's say, this scenario number one. When we have a team, and we are working to develop something, and we design some beautiful layout, some beautiful, you know, architectural blueprint for a given application, and it all goes live. And that's done by, you know, art or hand work, hand work. So you do it by hand, you know, elaborate process steps you follow, people do it, you develop something new, and, you know, it goes live, and the customers are using it. And they are all happy. Now, what I want to be able to do is, you know, have a method, a systematic method to reproduce the whole thing. So basically, it means tear down everything we have. But before we tear it down, I want to take some kind of a dump, a dump of what? A dump that contains my data, my files, my objects, my design, my connectivity, my security, my, you know, aspects regarding scalability. And basically, the entire design that I have, a new infrastructure, plus applications, plus the underlying concept behind making sure that this customer is happy, all of that, that I need to do, I will like to tear it down and reproduce again. So this and this, this will happen efficiently if you are able to take a dump. By dump, I mean extract, or in another word, backup. And when I say backup, I don't just mean backing up data and files. I mean backing up the whole design, complete connectivity, security, scalability, files, objects, applications, the whole thing, every single thing I want to be able to extract, take a dump, backup, things like that. And when I have that, I will put this entirety in form of a Git repository. And then when I want to tear down, I can. I can get rid of the whole thing. I can say, you know what, you, you go bye bye. And I want to reproduce the whole thing. I can because I have this with me. I have the Git repository containing the extract, the dump, the backup. So I can just restore. And when I restore my design, I get what I had to begin with, like exactly what I had to begin with, what my developers built. The beautiful handy work, the work of art, the fine thing that makes our customers happy. I can reproduce that very, very efficiently by restoring. So when I restore, I get my entire blueprint back up and running, just like it was. And the customer's happy again. That's the scenario I'm painting. Now, in order to accomplish that, we need some tools, some tools that will actually take this idea that I had, I just described to you, and implement that for real. So we will go to some, you know, some clouds, we'll build something here, nice and fancy in exactly how we want it to be, and I want to be able to, you know, iterate on it, iterate as in, you know, improve, improve, and then I want to destroy, recreate, and further improve. I want to keep doing this improvement as I go along, and I iterate on that, and I iterate my design, and, you know, basically keep improving my product that I am building. My product can be a complex architecture that, you know, I just restored that was constructed using, you know, original art, you know, people working manually and getting things ready, and I was able to take a complete extract that I was able to restore, and then I want to be able to put that back in the way it was, and while I do that, I may want to modify a couple of things, like I want to change my design a little bit, or maybe delete some files or add some elements of security, things like that. And all of these changes I will make is going to be inside my extract, and I will be putting that in a Git repository. So bottom line, you know, if you have some design, you want to take an extract, put that in a Git repository, and you want to then make changes to it, and then you have another commit, and then you want to apply this to a cloud. So this is the original creation you extracted, and you basically saved that in a Git commit. You made some changes as you want to improve or, you know, make amendments, your new design, and you can restore from this commit, and then here becomes your new design, live. So this is the concept that I want to illustrate, and the idea is kind of hard to comprehend because, you know, this specifically this idea, what is it that we are extracting? What are we putting in Git, and why is it so vague? That is deliberately vague to simplify. When I mention these things, what I'm really talking about is simple JSON files, or other types of files, like Terraform files, or, you know, the file format is actually not that relevant. But the idea is that you extract information about your cloud's blueprint and put them in some kind of files, and then put these files in a Git repository. So you can modify them, iterate on them, create new scenarios, and implement them. So the flow of work would be you create some design, take an extract, create a Git commit, make changes, make more changes, like that, and at any point in time, you feel like, you know what, I want to give these customers this implementation that contains, you know, not only my physical layout, but also my data, my files, my objects, my design, my connectivity, security, scalability, the application, the whole stack, complete stack, the complete blueprint running live. That's what I want to be able to do and give it to my customers. So all of that information is captured here, extracted and captured inside this Git commit. And so at any point in time when I'm making certain changes, so plus or minus, plus or minus, plus or minus, like that, I can, you know, apply this design, apply to a cloud, and you get that new design ready. You apply this to the cloud, you get that design ready. You apply this one, you get that design ready. That's the kind of scenario that I want to be able to demonstrate to you with a variety of examples. The reason this is relevant is because it gives you the flexibility to move something like a complex illustration that we saw, example applications that we saw, or you may have done it already in other cases where you have something like, you know, a VPC constructed. And in my example, you will notice that I currently have only one VPC, one route table. These are the default ones provided already, one gateway, one subnet. That's it. There's nothing much in this particular cloud that I have right now in Northern California. So that is by design, I deleted everything just this morning to show you that I'm beginning from scratch. And what I want to be able to do is construct some application. And I want to put that out somewhat similar to what this illustration is going to look like. So for example, it will look like what I'm going to build now. I'll build it by hand on this diagram. And then I'll build the same thing by code in the cloud. That's what I intend to do. So I'll begin with an eraser and make some room so these guys can go away. On the side, we're not looking at them, just moving them on the side. We have people who are using, you know, devices, laptops, desktops, we have a load balancer to balance the load. We have, you know, some setup kind of sort of like this, if you will. And in there, what I want to be able to show you is make a little bigger so you can see from a distance a little bit better. And this is what it will look like. So I want to begin with something that will have a virtual private cloud. So this all of it will be a VPC. And I will construct this VPC through automation. This is conceptually similar to the exercise that we did a long while ago, which was this exercise here in my account, come on, in cloud technologies in module number 11, if I remember right. Yeah, this one, data center in the cloud, that segment. If you remember this video sequence, we did a bunch of steps by hand. And that is conceptually kind of sort of somewhat similar to that design is what this design is going to be implemented. But this time, what I will do is I'll actually show you the automated method of building virtual private clouds and automated methods of taking captures of information about that cloud in a file or a collection of files so that we can then reproduce them in the context of another setup, another customer, another cloud, another situation, another application by making appropriate modifications. So what I want to be able to do is in the context of this discussion that we are having, I will go a little bit further in elaborating what that application is going to be doing under the hood. So inside that VPC, we will have at least two machines. And on one of those machines, we will have actually both of those machines, we will have Docker running. So inside those boxes, we will have Docker. So I will draw that by saying it has Docker running here. And when I have Docker running, I will have applications then running inside a container. So it will be something like this. And the application will be running here. And you will have a container that will have another application running inside the container. That's the scenario from an applications perspective. In addition to this, we will also have a load balancer that connects and distributes load among these two different applications running inside containers in Docker on those two machines in that subnet, in that yellow subnet. In addition to that, we will also have another subnet. And that subnet will be responsible for access control and network address translation. So that is what I'm bringing it from the other side, putting it here, like that. And so in that design, the idea would be in this machine, what I would like to have is a network address translation layer, so basically a NAT device, like for example, NAT. So this will become a NAT machine that will allow our machines that we have, that we have in a private subnet. So this is a private subnet. This is a public subnet. And what I would like to have is this purpose of this NAT is to allow these boxes to connect through the NAT and then go outside to the internet if they need to, whereas the purpose of this load balancer is to allow these customers to connect to these applications that we have running in the private area. And so the setup would be something like this guy will divide the work among this. I should choose a different color. So I'll just erase that, a different color among these two boxes. And the traffic will be routed over to the application like this. So the point will be that these customers who may be hitting that service endpoint will be automatically diverted to go to the application running inside your private subnet and will be distributed in terms of load balancing across two different Docker containers running on two different machines on the private subnet. And this public setup is basically for allowing outside access for these machines that you have in the private area for them to be able to go out and also allowing you to go in and mess with it if you like to. So you could. This is just you, just you. So that's the scenario that I will be building and I will be building through automation. So we don't have to waste time, we'll just not do all these steps that we have done in module 11. Instead, we'll go in the cloud here and watch what's going on because it will construct a new VPC right now. We just have only one VPC called the default VPC. And what I want to do is just show you a quick run. The run is going to be running an example that I have already provided in a link that I should bring it up for you. So that link is, I think the one that I mentioned the last time when we were doing the session, which is two days ago, we were talking about an example using, that's what I want to pull up and give you a link in Slack chat. And so that link is here. And that is the exercise that I will be running very quickly. And there we go. So that's the exercise. Another question, your voice comes in real soft after coughing, of course. You know why that happens is coughing actually is almost like yelling. And so the microphone thinks that I am going to be yelling. So when I speak softer, I mean, when I speak after coughing, then it thinks that I am actually slowing in speaking softly and that's why I don't sit down. So if you don't cough, there is no issue or you break the audio pipe and then you come back. So it doesn't, it forgets the previous coughing. So that exercise that I'm going to give you a link I just gave you is what is described here. It's already available on GitHub in that location and I have already cloned it. So if I go here, I find that exercise is located here and I will open up in atom editor to just quickly examine. And then, you know, without even discussing what it contains, just run it and then show you and then break that exercise down into parts, component by component, and then describe what it does because I want to just quickly run it to show you what it is doing. And so the way of running is actually just one line, which is this line terraform apply and that should do it. So we will go and check that out and see how it runs and then we'll go and study. So our idea would be to just run for right now. So here we set terraform apply. That's the way to run that exercise and we should have a running functioning design implemented in the Amazon's Northern California cloud, US West, according to this illustration. That's what I will expect to see when I run this. So I'm going to run it, terraform apply and let it go. And so it is going to do what I think it is going to do. And so I hope it works. But we'll see. It is doing its thing. And while it does, I would like to explain to you what's going on as it finishes. It should take like two minutes to finish the whole thing. And you will see that it is actually running through a variety of sequences. And so we will discuss that item by item, absolutely no doubt about it, but let it finish when it does. And finally, we will see the real live example implementation that is happening for real right now in this cloud, Northern California. And you can see that happening by when I refresh, you should see a new VPC constructed. And that thing is right there. Automated VPC came along, new VPC and lots of other things happening. It is not my default VPC. It's a new automated VPC getting constructed. We have a bunch of other things here, such as in the EC2 section, you have some machines starting up. There is one machine running right now. This machine is going to become the NAT device, which is this one. And that is this machine NAT. It has already been labeled like NAT. And it is running right now, so it is going to be installed and configured like a NAT. Any machine that you take, by the way, this is just a plain Ubuntu machine. You have to configure it into a NAT. So if you look at the machine itself, it is just a plain standard Ubuntu machine. And you will also notice a couple of things here, that this machine will be converted into a NAT device through injection of one line code that converts that machine into a NAT machine. And you will also see a couple of other interesting things that I will point out as it goes along in creating that device, NAT device. In addition to that device, we'll have two more, like I mentioned here in this illustration. You will have two more devices, like this machine here and another one here. And then we will see that it is getting configured with Docker. And once Docker runs on this end here, then we will be able to create containers. So container one, container two, running applications that I have here, this container running another application that I have here. And that app will get deployed inside containers in Docker on those two machines that will be created as it goes. We'll also notice that it is creating something right now, app zero and app one machines getting created in the next 10 seconds elapsed. So you should see what it does here. And we'll just go to the EC2 dashboard and we now have three instances running. And you can see that it has constructed two more machines. They are the app zero and app one, those two machines constructed. And by the way, it has reported that the entire infrastructure like I wanted is ready. And it's already out there in this cloud. So what does that boil down to? We were able to construct this in a matter of a couple of minutes. And as a consequence, what you have as a report in the output segment is that you have an application zero IP address, meaning the IP address of this box is an internal IP address, private IP is available to us like that. And we also have the private IP address of this box available to us. So we have IP, we have IP here. So these two are available and known to us, these are private IPs. So that means that we cannot directly connect to them. We also have the elastic load balancer created for us. So meaning this machine has a DNS name that is available to us, and that is provided here like that, that entire name. We also have been provided in NAT IP address, which is the IP address of this box. And that IP address is public IP. And so it is not 10 dot, but 54 dot. That's a public address. This is a private address. This is also a private address. And the addresses that we have now received is for the NAT device, which is this IP address. We also have the host name for load balancer. So that's the endpoint that I want to actually visit. And I will go copy that link, open it up in a browser. Let's say Safari, and paste. And I should see something. So here is my application running right there. You can see it. And this application, welcome to NGINX, is basically running inside those. That application is actually running right there. So here. That's where the app runs. And it is running in two different containers, this and this. And I am able to see that here. And if I hit this again and again and again, and if all of you also hit the same thing, you will notice, as you hit, that it all looks the same, exactly identical. And that's the point, that these applications are identical. So they can be substituted by other identical applications. And the user will see exactly what they see, which is what you see right now on that link. And so that's the implementation happened. And that is creation complete and all that good stuff, but let's see if we can connect to this box. Can I connect to the NAT device? Let's see. Let's go and say SSH to the NAT device. The NAT device IP address was here. So we'll grab that. We'll copy and say SSH Ubuntu at IP address. And it will let me connect to it. And I connected. Nice. And so I come out of it. You will also see that I have my SSH configuration in this location. So I'll go there, cd.ssh, and there is this file called config. That file is supposed to be the one that allows me to connect to the machine's internal IP addresses. So I need to modify that file, the config file. And I need to modify to make sure that it can understand where is my jump box. My jump box is the IP address of the NAT device, this guy. And I need to provide this IP address to that location, which I will do right now. I will take my IP address of the NAT device and delete the old one and put the new one and save. You will also notice that the internal IP addresses of these guys and these guys are in the shape of 10, 128, 1, x. This x can vary. That's how I have chosen my subnet for the private subnet. And so that is why this host number, host IP address scheme, is defined like 10.128.1.star. And this configuration allows me to connect to my internal machines, like these guys or that guy, like that. So once I have that NAT box as my jump box configured and I save and close, I should be able to use that configuration file here and automatically jump through that NAT device into the internal machines, which are this app 0 and app 1, those two boxes that I have constructed internally. I should be able to jump to them and connect automatically if I want to, if I need to, which I will, and I will do that right now. So I will go back to my location and now identify the IP address that we have. You can get the IP address from this command here, or you can get it from the EC2 console. You can go to the EC2 console pretty much like here and get the IP address from these boxes. You can see that they have the IP addresses, private IP is provided. They don't have public IP, which is expected. You will also notice that this public IP is missing for here, but for the NAT device, this NAT device, it has a public IP and that's what is here. And so with that understood, I want to actually go and connect to the machines internally, these guys. And so I will grab their private IP, copy here, bring it, break it, make some room, SSH, and then paste the internal IP address of that box. And I should be able to connect to it just fine. And here I did. And so now I'm connected to the internal IP address 10.128.1.188. That is this box. I'm connected to app zero right now. Now here in that box, as I said, you would expect that there is Docker running. So Docker runs in super user mode. So I will have to go sudo su. And then I can find the Docker is running. And not only that, there is a container also running. You can see that there is a container running by that name, Angry Samet. It is this ID, container ID, and it is running NGINX image. And that's the reason why you see NGINX, because it's running that image in there. Now it is also doing a couple of interesting things that are worth watching. And so I will do that, is make some room and say Docker ps-a. And you will see that the container ID, the image used, the commander under the hood, it is running six minutes. It has mapped the port 80 for the box outside to the port 80 inside the container, which translates to this illustration. So you have port 80 on this box mapped to the port 80 inside the container. That's this illustration, this segment. And they also have port 443 open, but only at the container level. So that was this container inside this machine that you saw. And while in there, what I want to show you is that it is running that NGINX thing. So if I want to go to that NGINX container, I could connect to that container itself. And I will say that I want to go to connect to that container, so Docker exec IT, and then bash, give me a bash prompt inside that container. So it gives me that. And here you can see that it is running NGINX. And there is my NGINX process and the worker process. Those two NGINX processes are running inside the container. We are in the container right now. This is the container ID. And here is the same container ID. I was able to enter that, go inside the container, and get a bash prompt in there. That's what I just did. And in there, I find this NGINX is running. Now I can go and make modifications if I like, but I don't want to make modifications by hand without a reason. So I just wanted to show you that there is this container running NGINX inside that machine, app 0. And with that, I will come outside of the container. So I exit once out of the container, exit another time to come out of root, exit another time to come out of that box, the app 0 box, and back to my workstation. I'll do the same thing again, but for a different machine, which is this machine, app 1, here with a different IP address. Grab that. And then SSH, the other IP address. And I'll say, yes, I connect. When I connect, I can see that it should also have Docker containers running in there. So Docker runs in super user, so I'll say pseudo SU. And then I will say Docker PS-A. And I see that there is another container running right there, exactly similar, with a different name, condescending BASI. And the same scenario, machines port number 80, map to port number 80 inside the container. You have a container ID running NGINX eight minutes ago. And so we take that container ID, we copy it, and then we say Docker. Allow me to go inside the container. And so it is going to allow us to go in there. And we are inside the container. In there, we will see that there are NGINX application running. Here is the master process, here is the worker process. Those two are running inside this container, which is this ID. And that is in the app 1 machine, different machine. And now we are in this other machine called app 1. What I want to be able to do is show you how this guy, the load balancer, what it is doing is basically balancing the load between this container and this container. That's what it's doing. So I want to be able to prove it to you that it is actually doing the way it is supposed to be doing. So how do we prove that? I want to prove it like this. What I want to be able to do is now that we have a load balancer connecting to one NGINX here and another NGINX here, this is in a Docker container on a machine called app 0. This is in a Docker container on a machine called app 1. And what I want to go and do is now that we are connected to this location, we are here connected. I want to make a change here manually. And this change will illustrate something that you can catch because this load balancer is going to balance the load among these two guys on a round robin basis. And so with that change being made here in this location, what I want to be able to do is show you that round robin. When you visit this point repeatedly, it will first go here and show then go here. It already does, by the way, but you don't see any change because they are identical. These guys are identical. This and this are identical or deliberately make a change here. And I will do that very easily here. What I will do is while I am inside that container, I will go to that location where it stores that file that you see when you go visit this site. This site, I would like to change it. So I'll go to that location and I will find that file there in the HTML folder. And in that file, there's the index HTML sitting. I want to modify that. I will say index HTML, you rename yourself, please. So you become something like whatever. And then I'll create a new file. I'll create something like I just made a change to the index HTML file inside the container. And after having made that change, I will come out and out of the root login and out of that machine and back to my local computer. So with that done, I would like you to visit this site and hit it repeatedly, like click and click and click again. You will see that it jumps. It jumps from one box to the other and then one box to the other and then box one and box zero and box one and box zero. You will see that happening as I do it. So I'm going to do it now. I'll hit and I hit again and I hit again and I hit again, again and again, again and again. That is what is happening. Now, when I'm looking at this, this is the same modification that I made. This is NGINX container running in app one. And then I repeat. I think I had to go do not disturb. So I'll go do that right now. Okay. Where is my do not disturb? Do not disturb. Come on. DND. Where are you hiding? There we go. So yeah, back to Safari. Do you see this? What I see? Okay, when you hit that link on Slack chat, do you see exactly what I see? It toggles between app one and app zero. What I can do is make that change for a similar change for you in the other app zero as well to clarify. So I would like you to hit that location, that endpoint that I have given you in Slack chat and hit it and make that change as you expect to see that I'm making right now. So I am doing that change as I speak inside here. What's just going on? Hold on. Hold on. Let me, yeah. So I'll go to the other machine and in that machine, I'll do the super user and go to that bash shell inside container. And in that container also, I will go to the same location, user share engine X, HTML, and modify that file and call it I, modify that file, call it I, and then echo this line to the file index HTML. And now you should be more clearly seeing what I have in mind is to demonstrate this idea, which is, hey, okay, I see that you have the answer. Yes. Yes, it works. So I'm going to hit it again. And I'm seeing app one, app zero, app one, app zero, app one, app zero, toggling. The toggling is happening as you notice in this browser. So this is app zero, sorry, app one, this is app zero, one, zero, one, zero. It's happening. It is toggling and shuttling between the two. And that's the implementation that I just demonstrated to you. But this was all like, you know, okay, I showed you something, but what's the point? So let's go deeper now in terms of understanding what it is doing and how it is doing and how can you do it on a similar or different case? How will you modify it? How will you put that to work for real? And so now recapping what we just saw in this picture, oh, it's gone too ugly now with too much of things written on top. So let me erase that. Okay, I'm erasing all of that. And let us understand what we just did. So what we had in this illustration was a simple implementation like this. But not only that, we had simple things like, you know, we have a security group for load balancer, a security group for this, a security group for this, a private subnet, public subnet, machines app zero. The green color is not good. So app, app zero, app one, that's the machines created, they install Docker, install Docker, put a container, container on nginx here, nginx here, and then configure this guy to connect to the box and this box. And that's the toggling happening in the two in between the two this load balancer is toggling between and distributing the load among these two guys as you hit that location again and again. So here we go. 0101. That's what's happening. And what this does is allows access for these guys to go out if it needs to, and also allows access to me. So I can go inside like this, if I need to. That's the route. It allows me to go, this is me. And so it gives me access to the machines inside if I want to go and go to this machine, go all the way to the Docker container if I need to, and make modifications in here if I want to. And I was able to do that just like that. And that's what you saw. That's what you saw from a user's perspective as to an observer's perspective. Now let's see, in most cases, when you have a load balancer, you don't want to do like this, like app 0, app 1, app 0, app 1. It throws people off. It makes people believe that these are two different things as opposed to one common service. You want to be able to have people get that experience of one large service which is balanced across multiple different containers. That's the scenario you would like to portray. So having this modification like app 0, app 1, making it different for different boxes, different containers, may or may not be appropriate. I just did that change for you to be able to see what we did and what we can do. And these are actually two different containers and two different things behind the load balancer. So you see here that there is, in the Amazon's console, there is a load balancer. Where is that? EC2 dashboard and load balancer. There is a load balancer available to us. That load balancer was constructed through our code that we ran. And so this is the automated load balancer that is constructed. You will also see a couple of very interesting things that we have never seen before. And so that is what I want to point out, is pay attention to this idea if you will. There are subtleties that I would like to bring to your attention that you may not capture if you are reading it first time. And that subtlety is the idea of stickiness, stickiness. And that is something that I would like to now describe. That is, let me just erase these guys. So imagine a situation where you have similar structure and you have this dude. This dude says, yeah, I just uploaded a picture here. So he uploads a picture. That picture might get connected. This guy's traffic might get connected to this box and the container inside. And that's where the picture is sitting now. Let's go. This is the picture P. So he uploads this picture P and it goes and sits there. He is dealing with that box. And then what happens is, tomorrow this guy comes again and says, OK, show me my picture. I want to see my picture I uploaded. And what happens is that this application might send him to this location tomorrow. So this is today and this is tomorrow. So when he goes there tomorrow, he says, where is my picture? Forget about tomorrow. You know, what if just he clicks again on the browser refresh, just a refresh, just a browser refresh, and this person will say, huh, where is my picture? And that is going to be a good big exclamation mark. Where did you lose my picture, dude? I uploaded a picture here. Where is that picture? And so that refresh, if he or she does, the user, that refresh might toggle the user to this location. And if you have hundreds of boxes like this on either side and lots of lots of these machines dealing with lots and lots of customers, they will toggle left and right and you will have a disaster at your hand when people will upload something. It will go upload it there and other boxes will not have it. And next time the browser refreshes, the user will get frustrated. Where is my picture? That's one scenario. Another scenario, you have, you know, hundreds of machines like this and the people are hundreds of users also are using. And so what you will notice is this scenario that you have a method of logging, login password. And so the user creates a login account and he or she is able to sign on. So the user signs on, on to the load balancer. The user comes in, says, yeah, please give me a machine. So I get connected to this box. And so I sign in, my ID, my password, and I all type that. And so that is good, I type and press enter. And a cookie generates and then the session establishes and all that good stuff. However, the next time when the browser refreshes, this machine will assign this to another machine, maybe here. Maybe there is this additional box that you have like this. So it goes here. And so if that happens, the sign in session was saved in this loop. Oops. I thought I was on do not disturb. How did the call come in? Strange. Is it not do not disturb? It is on do not disturb. How did it ring, man? It's a bug. It says do not disturb. And so if the sign in session comes in, and here the session is established, but the traffic might get forwarded to this location. And in that case, this box does not have my session, does not. And what does that translate to? It means this user will notice that he or she is logged out. Ha, another problem, like another frustration, frustration. And that is very likely to happen if you are not able to preserve the cookie in the sessions that you establish with this machine when you sign in and press enter, ID, password, enter. That session is established and stored in this box and your browser. However, this load balancer can just throw you to another machine randomly. And that has to be avoided for most practical purposes by ensuring stickiness. And that is something that you may not notice, but you expect that stickiness to be there. You expect that when I log into, say, Amazon.com or log into cloudgenius.com or whatever this site is, that I expect to see the login session preserved. And there may be more machines that I may want to use, but then my login session should carry forward with me as I associate myself. I would like to have stickiness. And that stickiness is what I will now demonstrate to you with a little change. You will see that I will go back to this location and observe the details corresponding to our load balancer. In that load balancer, you will have this machine and this load balancer running. It is a classic load balancer. Let me adjust a little bit. It's a classic load balancer, while it does, it's internet facing, so I can see it from the outside. You can see it from your computer. This is the DNS name that you have in that Slack chat that I have given you. And so in that location, what you will see is when you visit this location, you expect stickiness. And it is at the back end on the status on the backside. There are two instances in service. You can see that those two instances are these services, automated app 0, app 1. Those two machines are actually in service. They are serving the customer. You can remove them from load balancer if you like. And if you do that, they will go out of commission, not in service. And that is how you would actually remove if you have 100 machines. You remove some of them, you service them, you put them back through automation. You could do that if you have such a setup. In our example, what I want to be able to show you is this idea of stickiness. And so here, if you look at our configuration, the port configuration is mapped so that port number 80 from the outside is mapped to the port number 80 on the machines inside. And stickiness is disabled, and that's the default behavior. I want to edit my stickiness and decide who's going to maintain cookies to ensure stickiness. The cookies can be handled either by your application or you can ask load balancer to handle cookie stickiness for you. So in this case, by default, cookies are disabled, stickiness is disabled. What I'm going to do is enable the load balancer to generate cookie stickiness. And here, we can leave an expiration period if you like as to how many seconds we'll have the cookies just expire. But right now, I'm going to disable expiration and leave the cookies alone. And with that, I'll enable load balancer generated cookies, cookie stickiness, and save. When I save it, you will see that my stickiness is enabled with load balancer cookie stickiness policy, an expiration period of never, never expire. With that understood, what I want to do is go back to our browser, this time a different browser, so I can see my cookies clearly and go and remove my cookies that I have. So go privacy and remove all the cookies and they all go away. And so my cookies currently, I have remove all of them. So I don't have any cookies right now. And now, after having seen this situation, what I want to do is go to that site. Again, the one that I see in the load balancer and all that good stuff. And I will go open that site location from this endpoint I have here, copy, go to the Firefox browser, and open it up here. And so here is my app one. And if I hit it again, it is app one. Hit it again, it is still app one. It is not changing. I keep hitting, it is not changing. It is sticking to me, sticking me and associating me with the app one container. It is not going random directions and automatically sending my traffic to arbitrarily chosen boxes. Arbitrarily chosen containers because of this cookie right there. And I can remove this cookie right now. I'll say, you know what, remove the cookie. And now I go again and refresh, click and click and click. Yeah, I'm still stuck with the same app one perpetually like that. And you should notice that some of you will be stuck with one of those two containers we have. You will be stuck with that one. And it's almost like you have a session established, you're dealing with that machine, and it is not going anywhere. And so what do you, I want to see your observation. What do you observe on your site? I want to hear that. Anybody? It looks like the same machine for me. I say I'm sticking to you, right? Is it one or zero for you? For me, it is zero. Okay. So if you take a poll of how many people are seeing zero and how many people are seeing one, you will see that it is roughly 50-50. And that's the concept of load balancing, distributing the burden of people visiting from outside across the machines available uniformly. And that's the scenario. We can also modify and have our application deal with stickiness if our application is designed like that. In this simple example, we don't have it. So we cannot use this option unless we modify our application. In our application doesn't generate and handle cookies for us, so we are not choosing this option. But I think this is a better option when you have a properly created application constructed. You would rather let your application deal with the cookies, and that is a better recommended choice. If you have an application that actually deals with it. Now having done this part, I would disable the stickiness one more time. Save. Now stickiness is disabled, which means the cookies do not apply. So we should go back to our browser and remove the cookies and go back to the location and refresh. And it will say 0, 1, 0, 1, 0, 1, like that. It should start toggling again between 1 and 0. And you will also see that I get no cookies there. The cookies are blank. There's nothing to remove. And that's the scenario that you saw in a quick demonstration. Now what I would like to do is tear down the whole thing. And this time build the whole thing step by step so that we can understand what is it under the hood that's going on that helps you construct arbitrary designs like that. And so the tear down process is fairly simple. You can basically go to this location and say terraform destroy. And that's it. I mean, it will destroy for you. But I don't necessarily want to destroy. What I want to do is take a short break right now, come back and talk about another different tool that is actually helpful in understanding what we did. And so a very, very similar tool like terraform, but it's provided by Amazon. One of the services that they have is called CloudFormation. That's a tool that is very useful. And we'll talk about this and use it before we destroy the thing that we have constructed. So you will see that in a few minutes after the break. So I'm starting a timer right now. And let's resume after the break. Okay, guys, I think we are ready to resume. We are going to continue discussing this other tool that I mentioned briefly. I'm just checking if you're back. One, two, three, four. Yeah. You're coming back online, I guess. I don't see activity here yet. Okay. I don't know if you're online or not. I cannot detect. Are you back or not? Hey, guys. Okay. Good morning, Sami. That's good. So I think we should continue. I see some activity also. That's good. So let's resume. What I want to talk about is this similar tool that we discussed right now. We were able to construct a blueprint that we have stored already in a Git repository. All we did was to, say, terraform apply. And as a consequence, I was able to generate this implementation. The one that you saw me, the one that you saw, that implementation, I was able to create and show you, demonstrate to you. I was able to do that by this command, simple command, terraform apply. So terraform basically is a tool that allows you to apply a design to a cloud. So you put your design here, whatever blueprint that you construct, that you apply, and you see the result implemented in a matter of minutes. And that's what we saw. And so that's the terraform tool. That is an open source tool, by the way. It's available here, terraform.io. So that's the tool. This tool is open source. It's available on GitHub. And you will notice that it has the capability to work with a variety of cloud companies. So you have, you know, all these companies will support it. So your long list, Alibaba Cloud, Alibaba from China, Aruka, Atlas, AWS, Bitbucket, Gozon, Chef, Cloud player, a variety of providers, Datadog, DigitalOcean, Docker, Dyn, GitHub, Google Cloud, Heroku, some of the big names, Azure, OpenStack, you know, smaller names, Scaleway Cloud, and, you know, VMware. So a bunch of providers already available. These providers allow users like us to configure the underlying infrastructure, like, say, OpenStack, AWS, or whatever cloud company you're dealing with, the cloud provider you're dealing with, you can have that provider configure the way you intend. So our intention is defined in the design. And we go apply. When we apply, we see the result. It's a fairly powerful tool, and it is open, and it is generic, meaning it applies to any type of cloud that you have in mind, which is, you know, a nice thing to have, that that is a benefit. Whereas the other tool that I'm talking about, or going to talk about, is conceptually very similar, but it is tied to Amazon, only Amazon, that's the drawback. Drawback is a drawback only if you don't want to use any other cloud. In that case, you know, if you're just using only AWS cloud, that's a good tool. And so there are some companies do it that way, and that there is nothing wrong with their approach. But if it works for them, that's a good approach to have. So those companies that want to tie themselves with AWS cloud, which, by the way, is a big cloud, you know, lots and lots of people use it. They have a very similar tool like this, that thing is called cloud formation, cloud formation, and that is available here in this location. Now, at the first look of it, you will find it confusing. And at least I find it very confusing as to what do I do with it. It talks about this thing called create a stack and design a template, and then create a template from your existing resources, the three things here, right? So create a stack, create a template, and create a template from your resources. So practically, if you look at what they're describing, what it does is that they have two words. The two important words are stack and resource. So actually, I should say template. Another keyword that I pick up from here is template. So I should erase that. I should erase this and say template, why is the eraser not working? Okay. So template. The idea is that a template is what you will apply to a cloud that will generate your stack. So you apply a template to a cloud that will generate a stack of resources. And the converse or the reverse of that is if you have existing resources, existing resources, you could extract that information and create, or rather I should say create a extract and create a template. And so what is a template? Template is basically in the context of cloud formation, a template is a JSON file. And the scenario of usage is that if you have some existing resources, for example, we do have right now, we have a bunch of resources available here. In our EC2, that entire design is ready, this design, we have it ready already, it's running. So that's the existing resources that I currently have and I can extract that information about those resources and put them in a template very easily. At least that's the claim, cloud formation's claim is you could go this direction or you could go this direction, meaning if you have a resource, you can construct a template which will basically give you a JSON file. And if you have a template, which is the template you want, you can then apply it to create new resources that matches your template that you created based on an existing resource or set of resources that you had. So it's conceptually similar to what you will see in Terraform. In our Terraform exercise, what I did was that I had something defined already in the TF folder, in my folder that I gave you a link in GitHub. And then I said Terraform apply. So it applied, applies that and constructs our cloud. Now that I have my existing resources ready, I could extract. And this extraction, I can do that instead of using Terraform, use cloud formation to extract. And then I will receive a JSON template. That's the scenario that I will be running next. Now before I run, I would like to discuss this thing again one little time. Is this scenario of creating a stack is basically create this function, apply. So you have some design here, you apply, you create a stack. This scenario of design a template is to manually articulate and design a template using a visual content that they provide. So if you click the design template button, it opens up an editor. And here you could add something like EC2 instances and describe something like a internet gateway and security group definitions, VPC definitions, and things like a bunch of things that Amazon provides. You can basically drag and drop and draw it out as you begin. And then these resources, as you add them here, will get constructed in form of a JSON template. That is what you see at the bottom of the screen here, the template is getting constructed. And what you are looking at from that perspective, which is here, sorry, not here, here, is this visual tool I find not so intuitive to me. I cannot really put my head around in terms of how will I actually use for real. I find it easy to just go straight to the actual resource and construct it instead of doing through this visual method, which is a new development that Amazon has to construct resources from a visual perspective. It is something like, I think, one of you mentioned before cloudcraft.co was this, you have a service available that you could subscribe to, and you could then incorporate your machines and have them connect the way you like and have this configured. And then when you pay and connect your Amazon's account, like clicking this green button, pay them a monthly subscription, and then connect your Amazon credentials, they will probably be able to have this infrastructure that you design in form of a visual diagram illustration. They will apply that design to the actual cloud. And I find these tools may have some use, but I think I find it easier to just go directly to the cloud and deal with it directly right there by launching instances as you need and connecting them, the configuring them. I find it more easy to do it directly as opposed to doing through a visual tool like this or like the cloud formation tool, which is what the design template thing is, like you design template, and then you start building that illustration by hand, by taking these things and putting a cloud watch alarm and this visual thing I don't seem to like for some reason. Maybe it's just me. Some people seem to like it. I don't know why or who. But having said design template is a visual tool to construct a design that you like, and then you will have a template this you will construct visually. And in our example here, what we intend to do is like they're describing this create stack, design template, those two things. So if you have a designed template by hand, as a result, you have a JSON file. You can create a create a stack based on this template by applying this design and say apply that that's the way to work and construct a stack based on a template. Now in order for the tool to function, this cloud formation tool, it doesn't function on your laptop or your desktop, but it requires a separate EC2 instance on its own to run the tool itself. This tool that you have the cloud formation tool, that tool itself runs inside another instance that will take a picture of your existing cloud, existing stack that you have, existing resources you have. And then using your existing resource, it can construct a JSON file. And so that tool needs to run somewhere. And then it will look at your resource and construct a JSON that is the scenario that I want to be able to run. But in order for the tool to start, and this is the convoluted part, in order for the tool to start running, you have to use cloud formation and use a prepared ready-made tool template to create a stack that runs cloud formation. And then you use this stack to capture your existing resources in form of a JSON file. I think that may be a little bit complex to understand. So I'd like to probably simplify it. And if you do not understand this, ask me and I'll explain to you again and I'll show it to you how it goes. So we have some resource, we want to convert into a JSON file, we want to run this tool called cloud formation, that tool doesn't run by itself, but it needs an EC2 machine, which means a separate deployment of some sorts, which means you have to construct that, which needs another JSON file predefined for this thing. So it's a cloud formation JSON ready-made and that you run it to construct a new cloud and that cloud runs just cloud formation. And now this cloud will look at your existing cloud and create this JSON for you, for your real cloud. This is your cloud formation EC2 machine in a separate cloud. So think like that, separate thing separately runs. It looks at your existing cloud and then construct the JSON and put that JSON in a bucket. And so this JSON will be sitting in a S3 bucket at the end. That's the output you will see when I begin constructing my cloud formation machine and then use that machine to capture my real cloud and then construct a JSON, put that in a bucket and then I can destroy my real cloud and also destroy my cloud formation. Because I have captured my real cloud in a bucket in a S3 bucket in a JSON file, I can then use cloud formation template again to construct my real cloud. So that's the way of operations of this tool. So since we have to create a template from our existing resources that we have already, we need to use cloud formation. To use cloud formation, we have to launch a machine that runs cloud formation for us, for which we have to use another existing predefined JSON file just for the cloud formation tool called CloudFormer. And that is this thing called the Launch CloudFormer. So they have given us a ready-made template which runs the cloud formation machine. And that template is this location. You can see that template in the designer. So you can see it visually if you like, and what it has is these resources. And in there you will have, it's kind of difficult to read, but let's see if I can zoom it. So you have a bunch of things already that will be used to construct a tool called CloudFormer. And that is what this tool will create for you. So you will have a VPC created. In that you have subnets, one web server instance, one route for the VPC, and a couple of other services to help you look at your other things in your cloud. And these things actually have the ability to examine what else you have in your cloud and be able to capture in form of a JSON file, a template. So that's what that template looks like visually. Now what I want to do is to run that existing CloudFormer tool using a specified template that is provided by Amazon in its Amazon bucket called CloudFormation Templates Bucket. It is sitting in that location. It's the CloudFormer template. And I want to use that template from Amazon's S3 bucket. And I'll go proceed next. And when I do that, it is going to construct a new stack for me called AWS CloudFormer. I will assign a password for it. I'll put a complex password, something like A. And the username is also very complex, like A. And that's just my simple complex password, A. And I can choose difficult ones if I like to, but I don't care. So VPC selection, I can use an existing one if I want or create a new VPC. You can create a new VPC if you like. A separate VPC gets created. And this setting will control if the CloudFormer web server will launch in the default VPC or if a new VPC will be created or if you wish to launch into an existing non-default VPC. Those choices are available. I want to keep it separate, keep a separate VPC, launch itself CloudFormer tool in a separate VPC. And then look at my automated VPC that I have, my existing resources I have and capture the essence of all the resources and save them in a JSON file inside a bucket for me. And then I can deal with it. I can modify it, make sure that I can give it to my team members and have them reproduce exactly what I have in my cloud. And that's the CloudFormer way of doing things. So with this understood, I'm going to create a new stack called AWS CloudFormer in a new VPC and I will be using the login password A and I go next. I can define a key value pair and most of these settings, I'll just go with defaults because I want to just quickly get the tool running. So it is going to estimate my cost for me. It tells me that my cost will be $22 per month and that's okay. It's per month cost. So for right now, for a couple of hours, it's not going to be too much and I will proceed forward. After having understood the cost of running the stack, I close this item and say, yeah, please make my CloudFormer ready and up and running. So it says I acknowledge and create. So it creates a complete stack containing the CloudFormer tool for me in a separate VPC. And then I will use this tool to look at my other VPC, understand what I have there. I have a bunch of things running there. You saw me create that. We created all that using Terraform. We are going to take a snapshot of all that using CloudFormation. So that just to give you a flavor of what possibilities exist in the context of creating new architectures for your given applications. And how do you then take that from one location to another location in one customer to another customer reproduce that same behavior, give it to a team member in your company, have them work on the same exact setup in their account, in their cloud, in their region, in their setup, if you like. And that's what we will be doing as it finishes creation of creation is in progress. You can see the details. Right now it tells us creation is in progress and lots of things are happening at this moment. It is constructing a complete stack will be in a separate VPC. The VPC will be the CloudFormer VPC and it is getting ready. So we have our automated VPC constructed through Terraform. The other VPC is getting constructed with CloudFormer getting loaded there and that stack is getting built. So if you go to EC2 section, you will see that there is a new machine getting ready or not yet, it's not yet. So machines we have right now are only the ones that we created already to begin with. We don't have the other machines yet. So we have these three machines, the automated App0, App1 and our NAT device from the automated VPC. Those are the ones that currently exist. But I'm expecting soon we will have one more machine that runs the CloudFormer and that will be in a separate VPC. That separate VPC will be the CloudFormer VPC, which is this guy is running and creating right now. And as it does, you will see that output is not ready yet. That's the output I will expect to receive, which is going to give us a link to the new service, which is the CloudFormer service. That's what I'm expecting to receive in the output section. If you look at the events that are happening, that will show you things that are going under the hood. And so under the hood, it is doing a bunch of things, basically creating resources for us to be able to use that will constitute the CloudFormer tool. And that former tool is getting constructed, takes about two more minutes and we should have that tool ready. In the meanwhile, we'll just discuss something else. So we'll let it work as it goes on in creating CloudFormation tool. And the fourth instance popped up and this fourth instance is initializing right now. And this machine has this private IP, this public IP, and that is a part of your CloudFormer security group. It also tells you that it is in the VPC ID number 699 echo. So if you can go back to the VPC selections, you will find that this VPC called 699 echo is the one which is the CloudFormer VPC. So that VPC contains only one instance. And that instance is getting started in the EC2 section. You can see it again if you like. And you see it here in the four machines that we have, three of them belong to us. The fourth one on the top, this one, I should name it, I should call it the CloudFormer. And that instance is, when it initializes completely, will be ready for us to go to that IP address and understand the capability of that new tool that Amazon is installing for us right now. And so we will be able to make sure that it correctly works because I want to make sure that it succeeds before we can use it. It is still in progress and events are still going on. But as soon as this event process, the process of creating things that it does finishes, we should be able to see output showing the endpoint which we should visit to examine the service that we just started, the CloudFormer service. And that is what I'm waiting for it to happen. So that will happen when it does. While it does these things, let's discuss a couple of other things. For example, there is a chat message. The chat message question, a question reads something like this, does Amazon give these templates for the reference architecture they have given? Might be useful for architecture, architects to show POCs. Yes, I think they do. If Amazon does not, let me tell you where to find them. And I would go here and just do a Google search. And you'll probably find a bunch of them already here. And this is the browse sample templates. And so you can see topics, topics by topics, an auto scaling template. And you can just click the launch stack. And so here you can see that load-based auto scaling. You can see what's going on under the hood by viewing it in the designer or viewing the JSON file itself. This is the JSON file. And this is the output of the CloudFormer, the JSON output. By the way, JSON, as you know already, I think you know already, I think I have discussed JSON with you. It's just a file format that describes things like type is string and minimum length is 9 and things like that. So it goes on. And the US East region is this link like that. So it's a large file that's an output of a ready-made output that will do this thing. What does it do? Load-based automatic scaling. What it does is creates an auto scaling group with scaling policy that are based on CPU usage in order to start and stop EC2 instances, which span multiple availability zones. This template also uses auto scaling notifications so that you are emailed when the scaling events occur. Now, we saw the template. We can also launch it in one click. It launches the whole thing. It will give you that link already right there. And then you can go next and then next. And then let's see if I miss anything. And the operator email, you can put your email here if you like. And put a tag if you like here. So the key name, I want to just use this key and next and next. And so here is going to estimate the cost of it. Cost of running this solution is going to be about $37 per month. It will create EC2 service, it will create a CloudWatch monitoring service, and get us some basic support, which we don't need. And so that's what it will do. So having understood the bill, I will like to click and create. And it creates. I mean, I'll just hit create, but it will do it for us. Not a big deal at all. So I will go and hit it. I just started that stack. So the stack will build. And I will go back here and look at my stacks and understand what I have. And in there, in my CloudFormation, I will have another, this multi AZ notification sample. This template is getting started, creation in progress. And that is something that is getting constructed. By the way, this thing somehow decided to go to the Oregon region. I did not pay attention, apparently, it just went to Oregon. And so that's fine. We'll leave it there. We'll go back to our Northern California. And there you will have our CloudFormer ready and complete. What does that boil down to? It tells us that in our Northern California region, except that in the other example that I was talking about, it is still in progress, but we don't care about it too much. We'll come back and visit that later. This is the one that I just started for giving an example to Shiv in response to Shiv's question. We will stick back to California. And in there, we have our CloudFormation CloudFormer complete, which means we expect to see an output. The output is right there. And the output is that I would like you to go to this location, which is the URL for your CloudFormer tool. So this tool is running in a separate cloud. Let me grab that link, by the way. I'll copy that link address and go back here in California, EC2. And I have four running instances. And this is the CloudFormer tool running. And this is running, by the way, in the VPC ID, which is a separate VPC. It has this public IP address. And I want to visit that. I want to see what it shows me. So I'll go and paste it. And there, I will expect to see my CloudFormer, the new tool. Let's go see it. It says, select a certificate. And apparently, none of these certificates are correct. But I'll say, OK, maybe this one. I think I'll have to... This is not going to work. I don't know why it is asking for a certificate. It should not, because I put HTTPS. I think that's the reason why it did. I'm going to cancel it out, deny. Remove the HTTPS there. This is a bug, apparently. They gave me the link, and now they're not showing it to me. It is opening, apparently. So back to our EC2 console in our CloudFormer tool in Northern California. The output that we receive in this CloudFormer tool, the output we got was HTTPS. You can see it, HTTPS, that the output it gives us. And when I try to visit that site, the certificate is broken. And that is bad. Now we'll see without the HTTPS, it is not able to open. So I will try this in a different browser. I'll go to my Firefox browser and open it up in there. It is attempting to connect, but we are not actually reaching that. And that is weird, weird to say the least. Let's see another question. Oh, the comment was awesome. And so, yes, it is actually awesome that Amazon has built so many examples that you can just quickly go and play with. But just bear with this one idea. It can be really expensive if you forget to remove the resources. Yes, it is awesome, like you mentioned. But if you forget to destroy the resource after you create a large stack, you will get hit with a beautiful bill. And that is something you don't want to waste money by being forgetful. So don't waste money. Back here, this idiot thing doesn't seem to open. I don't know why. They gave us success report. And they gave us a value. This value is an output. And they say creation complete with success. And this is why I don't like this tool. Honestly, I don't like anything that doesn't work. And that's the challenge. But I'm going to see the logs if we have anything that is broken or any failures. I don't see any failures here. No. Do we have to open up? Possible. You're possible. They should have opened up the port on the security already. They should do it for us. This is like a ready-made solution. Don't expect me to go and open your ports. But we'll see. We'll examine it. They should open it up by design that the customer is going to visit. You create a stack for them. You better open up a security group. So we'll see what they have done. So we'll go and go to that VPC, the CloudFormer VPC, enable HTTPS access. We have port 443. Let's see whether they have actually done it or not. They have done it. Interesting. And then the certificate is broken. I see what's going on. The certificate is bad, apparently. So let's go visit that site again. So back to our Amazon's console in CloudFormation. We'll go select that all CloudFormer, look at the output, grab the output, copy as is. Go to Firefox, which is this browser. And in there, paste the HTTPS link. And it says, your security certificate is not secure. Connection is not secure. It is because your certificate, dear Amazon, your certificate is broken. You should fix it. And we'll say advanced and add an exception and say, confirm the exception. And now it is asking me for my username and password. And I will give that. And I will now go inside. Thank goodness. But this is a bug in Amazon. Their certificate that they have installed is bad. That's lame, lame, lame, lame. But now we have the CloudFormer tool. And they have been using this label beta for last seven years. And that doesn't excuse them from a certificate problem. OK. Enough of complaining about Amazon. We have the thing running, apparently. So let's go see what it does. Let's go see. So the idea is this tool has the ability to look at what else do you have in the Amazon Cloud. Apart from this tool itself, what else do you have? And then it takes a snapshot. So for right now, in our California region, we have to select a region because it operates on a region by region basis. We are going to ask it to stick to the Northern California region and say, you know what? Help me create a template of everything I have in the Northern California region. So please create a template. So it says, let me analyze what you got. I have this CloudFormer running in a separate VPC. So we'll ignore that, by the way. But let us see what else you have. And we'll take a snapshot of the whole thing, from a complete comprehensive perspective on creating a JSON file that contains every single thing that you have. What else do you have apart from this CloudFormer? Apart from this, what else do you have? That is going to be captured in the form of a file. And that file will be dumped in a bucket at the end of the game in the next 10 minutes. So we'll see that. It says template information. So here, my template information, I'm going to provide a description. What do I have in my Amazon US West 1 region? Or rather, this is what I have in my blah, blah, blah region. And so that's the description. And then I know it matches what I created using Terraform exercise. And that exercise is this one, specifically this one. So I will go back and mention that exercise right there. So the Terraform exercise we created, that is what is running. So it contains whatever it does. And so I want to make that template description clear. And I proceed next step. It says, do you have any Route 53 DNSes? No, nothing found. Next, do you have any VPC? Yeah, I have three of them. Which one do you want to select? I have no idea which one do I want to select. By the names, I can tell, but by the ID number, I don't think I can tell by the ID. So I don't know which one to select. So I need to go back to Amazon and say here, dear Amazon, please tell me the name or the number of my automated VPC. My automated VPC has the ID number 4041, this number. So I'll have to capture that. So I'll say, give me that one, this VPC. Next, in that VPC, it automatically selected the corresponding subnets and the corresponding internet gateway and the corresponding DHCP option set. That's all we have. We go next. We will also notice that it automatically selected the corresponding VPC network access control and the corresponding round tables. And next, the network. We would like to get this automated elastic load balancer, and we are not using any CloudFront distributions at all. So I'm not selecting any of these guys because I have a bunch of them, but not in this exercise. So we are ignoring them. Next, do I have any managed services? Not the Elastic Beanstalk, which is an example I am running on the side. Not that one, so I will ignore that one as well. This is an Elastic Beanstalk application that is running, that I am not including in this design because it is separate, not a part of the automated VPC creation that I have. So I'm skipping that one. Next, other things here, such as Elastic Beanstalk volumes and versions. I'm not including these guys as well, so I'm skipping them as well. Next, compute resources. In there, I have three instances that are actually functional. So I want to capture all three of them. And by the way, they should automatically select that third one, but it did not. That is also a bug. It should select the NAT VPC by itself, like that. This is the NAT VPC that we have. As you can notice, it's a part of the automated VPC. Its name is NAT. The first one was not selected by default. That is bug. It should select. It knows that it is part of the automated VPC, but it did not automatically select, which is unfortunate. Next, this stage of storage, we are not using any specific thing in any database as such in this design, so we can skip. Storage configuration, again, skip. Any application services, like simple queuing service, name service, kindness streams, no, we are not. From a security standpoint, we are using security groups called the automated VPC security group, the NAT security group, the web automated security group for the load balancer. Those three are correctly selected. Relational database security group, we are not using, so we should ignore that. And error enumerating resource, so it could not select elastic cache resource, could not select the spreadsheet resource. We are not using them, by the way, because there is some error going on, apparently. We can ignore that. It's not supported in that region. They don't have Redshift in Northern California. And so we can ignore those errors. We can proceed forward. And then it says operational resources. Do we have any auto-scaling policy? No, we have not defined them yet in this section, so we can continue. And next, we have a summary representation. In that summary, what this will do is look at our cloud, apart from whatever you have, apart from this CloudFormer tool, what else do you have? Take a selection, capture a complete comprehensive information about what you have in your cloud, and then continue. And when you continue, it gives you the template. This is the JSON file that you see right there. It describes what do you have. So you can save this template. OK, let's go back. And you have to put a bucket, apparently. And so you have to save this template in a bucket. And apparently, it does not give me a dropdown, which it should. It should let me select a bucket name in my S3 configuration. And that looks like another bug. But don't worry about it. What you can do is capture this JSON file, like this. Select it. Select the whole thing, which is clumsy, clumsy, clumsy. Copy. And put that in your Atom Editor locally. And so in the Atom Editor, you just save. And File, Save As. And put that in a specific location of your choice or preference. So I'll go and put it here. And I'll call it something I like. This is the CloudFormer tool output, XEF output template. And so that file is saved. That's good. How did I bring it down? I was able to bring it down manually because this silly tool did not save it for me in a bucket. It should give me a choice to select a bucket right there. It did not. That is unfortunate. But usually, it is supposed to give me a dropdown to give me a list of my buckets that I have in my account in Amazon. And let me save this CloudFormer.template file by clicking the Save button. It should automatically go and save. It did not because it doesn't know where to go. And that's a problem, another bug. So you can save the template, but it did not. So we saved it manually. And after having saved this, this is the entire purpose of that tool. The whole purpose of this tool was to capture whatever you have apart from this tool itself in your cloud and grab that down locally, bring it down, and put that in a file that looks like this. And so that's the file I want to open and read. So I'm opening it up, reading it right now. Here we go. So you'll see that it has segments. I'll go and highlight some of those important ones. It says it's an AWS template format version. It has a VPC identifier. It is an Amazon VPC. It is the CIDR block using this block. It is supporting DNS, supporting host names. The key name I'm using is called name. The value of that key is called automated. This is a key pair. You can see this automated key pair showing up here in the Amazon Cloud. There is a key pair. Where is that? In go to EC2 here. And you will find that my Northern California section has a key pair called automated. And that key pair name came down from here, automated. You will have a subnet defined with this CIDR block with a tag called public. You have another subnet defined with a different CIDR block with a tag called private, the two subnets. We have defined an internet gateway. We have defined DHCP option sets. This is the domain name, internal domain name. We have a network access control layer for the VPC. We have a route table defined for the VPC. We have a route table defined, another route table for the public, another one for private. Those two route tables are defined. We have a load balancer defined that is in the public subnet. We have a health check defined. This health check idea, I think I did not discuss. So I should discuss that briefly. The idea behind a health check is that if you have a load balancer and it is connecting to a bunch of machines, it has no way to detect whether this guy is healthy or not, healthy or not. It has no way to detect. So you have to provide them, this load balancer, a systematic method of detection of health. You can very simply do that by asking the load balancer to look at port number 80 and say, hey, are you there? Hello, are you there? Knock, knock. And if it responds, you can say that, yeah, the thing is healthy. If it doesn't respond, hello, knock, knock, who's there? If there's no response, it's not healthy. So if it is not healthy, don't send customer traffic to that non-healthy box. Don't send. Only send it to healthy ones. That's the idea behind health check. And you can do that. The target is HTTP port 80. And you pull it at an interval of every so many seconds. And if it doesn't respond in that timeout, then you mark it as unhealthy. And yes. With the load balancer, isn't it automatic for a load balancer to do a health check and stop connections to that? The question you have is, is load balancer automatically going to detect health check? No, unless you ask it to. And in our example, we have asked it to check for health. In our TARA form initial example, there is also the same health check. You will see it as we talk about it next time. So the idea of this health check is to look at this port 80 and see if that unit under the hood is healthy or not. If it is not healthy, just get rid of it. And you replace it, substitute it with another unit. And then the health check comes in again. Are you healthy? Are you not? If you're healthy, we'll mark you as good. And because you came back again, a replacement. The replacement is good. So mark it as healthy. And we'll send you some workload. And that's the way of this health check. That's how it works. You can see that implementation for real in our Amazon's dashboard load balancer and health check. And it shows you the same thing, HTTP 50. Timeout is five seconds. Interval, every 15 seconds. Unhealthy threshold, two. Healthy threshold, two. So if two times you see that it's unhealthy, you then assume that it is actually bad. If two times you see that the actual machine is responding correctly, positively, then you mark it healthy. But just one time somebody says, yeah, I'm healthy, doesn't mean it is actually healthy. You have to consistently say that you are healthy at least twice at an interval that you define here. And if it doesn't respond in five seconds, you mark it as unhealthy. So that's the health check description that we have set in our policy in Terraform that we captured in CloudFormer. This CloudFormer captures exactly the same details about healthy threshold, unhealthy threshold, interval, target, and timeout. And that is what you see here. You can edit those and define a different health check if you like. But we are not dealing with editing on the browser. We are going to deal within code in our Terraform code or Terraformer code. So connection drain policy, connection settings, cross zone is going to be across multiple zones or not. You have to contact more security groups like this SG Web Automated VPC security group. You have to define listeners. These listeners are basically the connections between the load balance of port 80, listening to port 80 inside on the machine inside. Then cookie stickiness policy, you can here define our default policy was nothing. But later on, we modified our stickiness policy and said, yes, we would like to have load balancer cookie stickiness policy created. And so this policy then gets captured in the JSON file. You see that this modification I made by hand after the fact. So it is getting captured in our JSON. And so the cookie expiration period is zero. You see that here in our description. The cookie stickiness is disabled. You can enable it. You can modify these parameters here. And that is what you see this capturing here. One thing I find is that it captured this policy. But in real life, I did not see it. I thought the stickiness was disabled, but it shows disabled. I don't know if it is cached or what, but the stickiness is disabled. You see that disabled, whereas it captured as enabled, which is strange. Hold on. Let me open that thing again. So the stickiness that I noticed in JSON was captured as AWS console load balancer cookie stickiness policy is activated with expiration of zero. But in reality, we did not have it. Don't know why. It should not capture because it was disabled when we ran that CloudFormer tool. When we ran CloudFormer, stickiness was disabled, but it captured as enabled, which is strange. Next one. We have instances defined. Those instances have instance ID, the machine image used, the key name used, automated VC key name, the instance type, whether monitoring is enabled or not, the tag value of NAT, the network interface of what happens when you delete that device, delete that NAT machine. Does it have a private IP address? What is the IP address? Does it have a group defined? Then does it have a public IP assigned for the NAT device? Yes, it has. More instances inside. These are the internal instances, T2 micro, using the same key pair. Does it have a private IP? Yes. Does these guys have a public IP? No, there is no public IP for these machines. This machine number two called app one or app zero, those two machines, app zero, as well as you see here app one, those two machines that are defined in this JSON. If you could keep going down, you will find the security groups defined for automated VPC security group for your web traffic security group for NAT traffic. And those groups are defined here. And now the properties of that group itself, like it says access allow from anywhere for the ACL one, which applies to this particular reference in the security group. You have more access control layers defined. You have a couple of subnets, subnet level access control defined. These get defined at the VPC section in the Amazon cloud somewhere here, you will see them. If you go back to the VPC segment here, and you can find ACLs defined here. And these are the ACLs we are looking at for the automated VPC. And the security groups references that we saw, we can filter them down to the automated VPC. And those security groups are captured in that JSON here. And I think you should run these things yourself to get this flavor of how do you capture a JSON containing your design implementation. You will see that it has a gateway attached, a subnet route table association attached. And all these details are basically back here. You can see them. There is a subnet defined, public and private subnet. There is a route table constructed. The three route tables, one is the main route table, which we don't use. The other two we use, which are the ones that are explicitly associated with a route called the private route. And this one is the public route. You will also see that the public route has a route to the internet going through the gateway. And you will also see that the private route has a route going to the internet through the NAT device. This, by the way, is the NAT device. You can confirm that by matching this number, 0 delta 0 0 brother delta delta. This is the NAT ID. You can see that the route to the internet for the internal subnet, the private subnet, the route to the internet is from this machine, not the gateway. And this machine, 0 delta 0 0, is your NAT device here. The machines, NAT. And this is the 0 delta 0 0 brother delta delta. That device is the NAT device, which is actually acting like a route to the internet for your route table. And you can see that 0 delta 0 0 brother delta, the same NAT ID came again. This is the instance ID for the NAT that is used for your routing to anywhere on the internet using the NAT device right there. And that information is also captured in your route table in this JSON file. And so you can keep scrolling like this all the way as you construct. I want you to do it yourself. And at the end, you will find a description. This is what I have in my Amazon US West region. I know it matches what I created using Terraform exercise and the link. So that entire detail gets captured in 511 lines of JSON, as you see this in the example. And what I would like to do is go back here and then describe to you the result of what we just accomplished. The result we did is basically summarizing. So we began with a folder containing a Git repository that I had created in Terraform. We applied that. And when we saw, it became our automated VPC running the design that we just played with a little bit, with load balancer and two instances and Docker and everything, and NAT and all that. And then we used a tool called CloudFormer. This CloudFormer tool needs to run by itself in a separate location. So you ask Amazon to start a CloudFormer tool. So you use a ready-made JSON that creates a CloudFormer tool. And it runs in its own CloudFormer. And then now that you have it running, you go to that site and say, Amazon, please capture whatever I have, whatever else I have. Apart from this thing, apart from this, what else do I have? So it shows you have this, and then you have a bunch of other things. So you want to capture the whole thing. I say, yeah, do that. And so it does. It captures the whole design that you have in the automated VPC. And it ignores whatever else you might have that you don't want. And then it dumps in a JSON file. And this is your architectural blueprint, your architectural blueprint. This is what you have here. And now you have this Terraform that you began with constructed in the form of Amazon's representation of a JSON. And you can then use this JSON to basically recreate your cloud. The challenge that you will have is this works with CloudFormer tool. And that's the only way to make it work, which means you're stuck with Amazon Web Services. And that may be good, may not be good, depending on your business situation. If you're stuck with Amazon and you like it, go ahead and party. If you're stuck with Amazon and you don't like it, too bad. You're screwed. I mean, that's how it works. So you should remain in a position of control. If you like Amazon, you stay with Amazon. Nothing wrong with it. But if you have this need to be able to have flexibility to go elsewhere, you would avoid using Amazon-specific tools. Instead, use neutral tools like this one, like I began with. And now we will go back to that tool to understand how can we use that tool to play more scenarios from a design perspective. So we'll go back to that workstation. And here, say Terraform destroy. So it says, are you sure you want to kill everything you have? And I say, yes, is the only answer. Only yes will be accepted to confirm. I say, yes, so please kill everything. It will go and wipe the whole thing out. And the whole design will be destroyed. And that's OK. We don't care. So while it gets destroyed, we'll see that these guys disappear. I want to also do one more thing, which is go back to my CloudFormation and destroy the CloudFormer tool itself, so CloudFormation. And the tool itself is the CloudFormer tool running right there. It is complete. And what I want to do is to destroy the CloudFormer tool itself. If I leave it running, that will be a problem because I'll be wasting money. So I want to delete the entire stack. And I said, yes, CloudFormer. You can go. And it's going. It'll kill itself. However, you will have another thing that I started accident. For Shiv, I started another example. So that is what I would like to look at now. By the time I understood it was in another location, not in Northern California, it turned out that I accidentally started in Ohio or Oregon. I don't know which one I did, but one of those two. So was it Ohio or Oregon? I think it was Oregon, not Ohio. Yeah, so it is Oregon. That's where it is running. So the tool that CloudFormer tool example that I started off on requests from Shiv is actually running somewhere here. So there is an instance running right there. And that is the T2 Small. So let's go see what it is doing for us. So we'll go CloudFormation, stay with Oregon. And it tells us that this sample is creation complete, which means we should be able to examine the output. And it tells us that you have a URL there. So this is your multi-availability zone. Load balance are ready for us to examine. And so we'll go there. And so it tells us exactly what we expect. And so go back to Slack Chat and paste it for you. And so that is the link for you to play with as I play with also. The idea behind this is that we are using a stack example provided here, this designer. Sorry, this specific load-based auto-scaling group that we have defined. We launched that stack like that. And it took off without even asking me in the Oregon cloud, which is what we are looking at here. And so it tells us you have successfully launched AWS CloudFormation sample. And I said, good. Now what? Let's go study the sample. So in that sample, we'll go see the thing visually. And so we can see visually what it is trying to accomplish. And this is the tool that I unfortunately do not like. But that's the best we have. So deal with it. OK, so let's see. Victorially, does it actually satisfy me as to what it is trying to tell and trying to communicate? Because it is kind of confusing. I don't know what to do with it. But I will go back to the actual implementation, like right here, and examine what do we really have? That's easier for me to understand as opposed to looking at the picture, which doesn't tell me anything much. Maybe I had to rearrange this picture to see it better. Maybe that's the way to do it. So you have a load balancer. And I don't know what. Yeah, I always struggle with this picture. But yeah, forget the picture. Let's get to the Amazon's cloud and see what we have there. So in Oregon, we have a VPC. How many do we have? Two? Two of them. One of them is the default. The other one is Cloud Genius. And let's see what machines we have running. In our EC2 section in Oregon, we have one running instance. And that seems to be running in your VPC number, 7brotherecho7. So that has to be understood which VPC is that. That's what I want to find out. I think it is the default VPC that's where it went, I suspect, because of the private IP looks 172, which is my default VPC. So I'm assuming it's the default VPC. And let's go see what do we have in the load balancer. We have a load balancer assigned to us that has a classic load balancer. It is internet facing. It has three availability zones. So A, B, and C, three availability zones assigned. Stickiness is disabled. We have some instances at the back end. We just have only one instance. That is this instance. And that is in the availability zone 2A. And that instance is in service, because the health check that we have, slightly different health check. It's as unhealthy threshold is 5, healthy threshold is 3. And the interval is 30 seconds. And timeout value is 5 seconds. That's a different health check listener. The internal listeners are port number 80, mapping to port number 80, and monitoring activity is happening. We will see that this specific example. We expect to see auto scaling. That's what the definition is in the example that we were opening and reading about. It tells us that it is expecting to auto scale with scaling policy that are based on CPU usage. So if our CPU usage grows up, we expect to see another machine pops up. We can do that by loading up the machine that we have running right there. We have one T2 machine running in the cloud. And so we will also write to examine our auto scaling group policy. So we'll go see here, what is our auto scaling group defined for us. And you will see that there is a launch configuration already. In that launch configuration, the idea is that you will use this machine ID, AMI ID, which is 7172B67. That's predefined for us. And that uses the Nilesh key pair. And that's the configuration that you will start automatically when CPU consumptions go beyond certain number. That's the definition here. On CPU usage, you grow the group, auto scaling group. And on CPU consumption, you shrink the auto scaling group accordingly, depending on how much CPU you consume. Having understood that part, let's go see the auto scaling policy. Right now, we are looking at the launch configuration. If you go back a step, and you will find that the launch configuration is what will be used, come on, yeah, no, not yet. So let's go back to the auto scaling group section here. And here, you will find that, hold on, something is wrong. So in our auto scaling configuration, we have an auto scaling group we should see defined here. And this is the auto scaling group definition. It tells us the policy about how it will grow and shrink. So let us go see that. In here, the name, as you can see, is based on the template that we used. The sample template was az, multi az notification sample, web server group number. The launch configuration associated is this launch configuration, which basically says, anytime you have a CPU consumption growing a certain number, that you add one more of the same type. That's the launch configuration defined. Minimum number of instances is one. That's what you see right now. We have one machine running. Desired number of instances is also one. Minimum one, maximum three. Availability zones, we would like to have them spread out across three different availability zones, 2A, 2B, 2C. The default cool down period is 300 seconds. The health check grace, what that thing says, health check grace period is zero. Now let us see, currently, our launch configuration defined and all the parameters regarding desired minimum, maximum cool down, and the availability zones are defined here. Let us understand some activity history. What has happened in the past? In the past, what has happened is that it started one machine because the minimum was set to one. And so since the minimum was set to one, the auto scaling group kicked in. When it found nothing, it started one machine. It says so. It says, at this time, a user request update of auto scaling group constraint to minimum one, maximum three, desired was one, changing the desired capacity from zero to one. And at that time, an instance was started in response to a difference between the desired capacity and actual capacity, increasing the capacity from zero to one. It's cryptic to read, so I'll read it again for you. It's like this. So the description is that it launches one instance. Why did it launch? It just described the reason for that here. It tells you in simple language that you wanted one, but actually you had only nothing, so it got you one. That's what it says. You wanted one, you got nothing, so it got you one. That's the cause. That's the history of this one unit that is running right now and successful. Let's go see the policy. The policy goes like this. There is a up policy and a down policy. The down policy is the shrink policy. The up policy is the grow policy. When you want to grow something, when do you want to grow? That is what is defined here. So we'll read that. Our grow policy, when you want to grow the number of machines you have, automatically based on certain metric. The metric is included here in the definition. The policy is self-explanatory, but I will like to read it line by line to make sure that we get it. We get it clearly. So first, I will read the up policy. The policy goes like this. Execute this policy when, at some point in time, when something happens. And when that happens, you take the action. What is the action? You add one machine. That's the action. And then wait. Wait and watch. 60 seconds before allowing another activity. You do that wait and watch game to avoid flip-flop, like I mentioned the last time. Otherwise, what happens is, if you have a threshold of something, say, this is the threshold. And I am here between a metric. So I cross the threshold. I start a machine. And as soon as I start a machine, the threshold goes down. Then I kill the machine. Boom. And then I create a machine, and kill the machine, and create a machine, and kill the machine. It's erratic. It's very erratic if I go like that. And so it's the flip-flop situation happens all the time if you do not have a concept of a wait. And that will trigger erratic behavior on your cloud. Really, start machine, kill machine, start machine, kill machine for no reason, just because the threshold crossed a border this way or that way, whatever the threshold is, threshold value. So it crosses the boundary. You start. You cross the boundary again. You stop. And that is erratic if you do it like that. So that's why you have this wait time, 60 seconds. Allow some wait time before doing another activity. Don't do anything until 60 seconds. And so now let's understand it again. Execute this policy of growing up when, and when it does, you take an action of adding one instance, and then shut up and wait for 60 seconds. There is a chat message I saw, so I'm going to read that. The comment was about probably why this article thought work inside choosing the right tool to provision AWS, the article might use the right tool to provision. I never read that article, but yeah, it's a good one. Yeah, makes sense, makes sense. Yeah, I see that. It's a relevant article. Good, thank you for capturing that link. And so back here in our discussion, which is about policy to grow, when would you grow? One instance and wait for 60 seconds is what is defined in this segment. So let's go read that segment. It says, something here, there's something, there's something breaches. When something breaches the alarm threshold, threshold is CPU utilization more than 90 for two consecutive periods of 300 seconds. For the metric dimensions, auto scaling group name equals AAS multi-AG sample, blah, blah, blah. So basically, if you read this simple English language, it tells you the alarm is breached when the threshold crosses. And the threshold is CPU goes more than 90 for two consecutive periods of 300 seconds each. So you have to somehow find a way to load up the CPU that you have there. So we have in our cloud, this Oregon cloud, we have that EC2 machine. There's only one, this one. And if the CPU consumption of this machine monitoring right now, the CPU consumption is like 3%. I mean, it's nothing. So we have to load up the CPU. If you load up the CPU and stick it beyond the metric that we have, which is I want to make it go more than 90% CPU for a period of 300 seconds and do it two times, continuously hitting the CPU on that box. What do you think will happen at that time? At that time, the alarm threshold will hit. It breaches the threshold, and as a consequence, this policy will execute. This execute policy when this thing happens, like 90% of more CPU consumption for 300 seconds and twice of that, two consecutive periods of that. That monitoring metric we need to capture here in the CPU utilization in the CloudWatch monitoring tool, which is, by the way, configured already for us. So if we find a way to hit this CPU heavy and make it go more than 90%, and that is what I will attempt to do for real example, like a real live example. So I will find a way to hit that CPU hard. How to peg the CPU 100%. And so this is what I will do. It says, I use stress for this kind of a thing. So there is a stress that I think we can run. So I want to run some stress. So for example, to stress two cores for CPU for 60 seconds, this is the stress that I want to run. So I'll run that stress on that machine. And let us see if we can run some stress on that box. So that is what I want to do. So what I will do is go to that box, first of all, make it visible from a monitoring perspective to you guys so you can see from a monitoring standpoint like that. And then I'll go hit the box, like hard. Hit it hard on a CPU metric. So let's go find out the IP address of that box first and artificially create load on there. So here is the public IP address. And I will go there. What is that OS? TC2 user, probably. So I am connected to that box. And right now, the CPU percent is low. So I'll go hit. Oh, no, not this hit. I'll go and hit it. Let's see how many CPUs you have, first of all. OK. So we have one CPU. And our CPU consumption is close to 0%. OK, nice. I'll load it up. I'll say, OK, load it up. Stress not found. So we'll say sudo yum install stress and say yes to it. So now I'll stress the CPU. And so the stress is happening. And we can examine that, confirm that. Stress is actually running. And you can see that the CPU is high right there. You see the CPU consumption going high. And it will stay like that for timeout of 60 seconds. So that is not going to actually hit the threshold. You will see nothing happening as a consequence because the monitoring needs to be 300 seconds, two periods of 300 seconds right now. It is only going to timeout in 60. So it will capture a spike here in the CPU consumption. You will see that the spike is happening. And let's go refresh. So the spike should show there is a spike. And what I would like to do is make a longer duration so it finished that spike, that CPU stress finished successfully in 60 seconds. But that doesn't meet our policy, the threshold that we have put in place. The threshold that we had selected was it has to be more than 90% for two consecutive periods of 300 seconds or more. So I will do that. And what I will do is I'll modify my stress command. Basically, this is artificially hitting the CPU to demonstrate a point, the point of scaling. So what I'm going to do now is to run the command slightly differently. And this time, I'll give it timeout of, say, 320 seconds and stress the CPU out and do it twice in two consecutive periods. So we'll repeat that same command, by the way, just like that. Copy. And another one. So two consecutive stresses of 300 seconds. And 300 seconds is like a five-minute period. Twice is like 10-minute periods. So it's a long wait. We have to wait for the actual kickoff of the threshold breaching the alarm. I hope you understand that. And I think it's a good time to ask questions, because this is live exercise. So we are stressing the CPU right now. And I have to wait for it to pick up some stress. And that CPU is actually pegged, as you can see, 100% occupied. And it is running. And it is hogging and all that good stuff. So let it hog. And I will put them side by side. So here, in the screen, we have that CPU hog running. Oops, hold on. CPU hog demo. This is the actual hog running. And this is the monitoring that we should refresh and see what they show. The monitoring metric should show something different now. So monitoring on that box, we see that the CPU utilization shows a spike. And this bigger spike this time, it did not cross 63% yet. It has to cross the average compute. And average CPU consumption has to breach the threshold of 190% for a period of 300 seconds two times. So that's exactly what we are running here in stress. And that stress will actually kick the auto scaling policy by breaching the threshold. And you should. And I'm betting money. Well, I should not bet money on Amazon. It has failed on me. But yeah, I'm just betting without money that this thing, this up policy will kick in in the next 10 minutes. I hope to see that, which means you will see. Let's see that. Let me adjust my screen a little bit. And as a consequence of this work that we are assigning to the box, which is basically putting artificial CPU consumption, we are pegging it to 100%, which means this up policy should breach in the next nine minutes or so. As soon as this stress followed by another stress of 300 seconds or more, we'll bring it to the knees and make the machine believe, the policy, auto scaling policy believe that the CPU is actually getting hammered. And it needs some help. Some help as in assistance from another machine. So you should see another machine pop up, another machine defined in the auto launch configuration pop up. So this launch configuration has this machine defined. This machine image with the key pair called Neles should automatically kick into the game and start participating in the load balancer already. Right now, we have only one instance. And this poor guy, which is in service, is getting hammered like this. I'm hammering it. And so it has to basically match the policy that we have defined. And the policy that we have set is to wait. And don't jump to conclusion that your CPU is actually 100%. But instead, let it burn. Burn for more than 90 CPU for two consecutive periods of 300 seconds. And at that time, you add one instance. Similarly, when you let it cool down, on the other hand, this shrink policy, so CPU alarm low, that will actually remove one instance. So the utilization percent, the breach of that alarm threshold will be when CPU utilization is consistently less than 70% for two consecutive periods of 300 seconds. So you basically show that you don't have CPU consumption more than 70 for two consecutive periods of 300 seconds. It's like five minutes. Is it five minutes? Yeah, yes. And so you will, at that time, see that the machine gets removed, so what we foresee, what we expect to see. Yeah, there is a question from David. I would like to answer that. It's a brilliant question. Yes, indeed. Your answer is yes. I will describe what he's saying. So what you notice is that right now, our desire, minimum one, maximum three, actual zero to begin with. And then it found out that there's a discrepancy between this and this, so it added one instance. Then what we did is that we put this grow policy and shrink policy in place. To grow, add one more plus one when you have more than 90 CPU for two periods of 300 seconds. And then you shrink policy when you have less than 70% of two periods of 300 seconds. And so we began hitting this machine that was added with load, and we loaded it up, and we started it to go 320 seconds, followed by another 320 seconds of 100% CPU, both. And as a consequence, in this five-minute period plus five-minute period, in the 10-minute period, it should pick up this alarm. And as a consequence, it should add one more. And after that, our load will die. Load will disappear. But then the alarm should pick up and already create one more instance. And that is what I'm expecting to see. And then in the next 10 minutes of this no load condition, that you will see that this machine should detect this condition. And then at that time, you should see it drop one machine and kill that one based on the fact that we intend to no load, meaning not run this artificial load that I have put on. And so since there is no load, there is no way to hit the machine directly as such. We are not going to consume the CPU all the way 100%. We cannot do it unless we artificially throw a load on it. And so that's what I'm doing right now. But at that time here, the load will disappear. And so this will be close to 0%. And then after a period of 10 minutes of no load, it will kick this policy and will shrink the machine. Now, what David is asking, David is asking a beautiful question, which is, what happens if you just destroy the machine right now? And so although I don't want to destroy it, because you know I am running this example, and so don't want to destroy it right now, but you could. And if you did, what you will notice is that actual becomes 0. Right now it is 1. You destroy it, it becomes 0. And so the policy will immediately kick in and say, your actual is 1. Sorry, actually 0. The minimum desire was 1. So I should add 1 immediately. And you will see that. Absolutely, yes. Yes, so that's the question was answered as yes. And that's what we see. So in our timer, let's say, I think it finished first five minutes successfully. So five minutes of 100% CPU going on, and the second batch of success CPU hog is going right now. Which means we should go and examine some monitoring there as to what's going on. So show me your monitoring, please. So your monitoring, please. And so here we have. Yeah, now it is looking good to me, like consistently pegged at 100% CPU. That's what I was expecting to see. And I'm happy to see that it is consistently close to 99%, 98%, 96%. Yeah, it's above 90%, right? Which is a good indicator of the fact that we were able to successfully, artificially load up the CPU by running this stress. Stress is an application. And it's just hogging the CPU doing nothing. And so that's what you see here going on. Stress, stress, two processes, two CPUs, but we just have only one. And you can run and stress out your CPU for no reason just like that if you intend to run some artificial testing like we are doing right now. In the next four minutes or so, and by the way, our second run has successfully completed, which means we should see something happening. And let's go refresh. And what do you see? Aha, see that? You see that this new thing popped up. This is initializing. And auto scaling group kicked in. And that is our auto scaling group in real live effect. And you see that this scaling policy shows you activity history in which the history tells you that it launched one more instance. And you will read the reason why it did so right now. And let's go read that reason. The previous reason was the desired capacity and the actual capacity was different. The desire was one minimum. And the actual was zero, so you add one. That was the reason the last time. This was at that time frame. But right now, the reason is different. The reason was that a monitor alarm triggered policy to grow up, changing the desired capacity from one to two. And therefore, at that time, an instance was created in response to a difference between the desired and actual capacity, increasing the capacity from one to two. So that popped up another instance because we decided to load up this poor guy. And that poor guy is now doing nothing right now. CPU is zero. It's idling right now. And so we will let it idle. And we will come out of that guy and disconnect. And so that guy is poor guy. Leave it alone. And so in fact, you notice that it is still zero. And so it is nice. But what this zero will do eventually is trigger another policy. Immediately, you will see that in the next five minutes or so, it will detect that the load has disappeared, that our CPU percent is substantially lower than 70% for a period of more than 300 seconds twice. And as a consequence, what will you see? You will see a shrink happening in the next four minutes or so. And you will see that if you go to the monitoring section and go full screen and go to the machine and running instances and look at the performance characteristics of these guys, and you will see that the monitoring on the activity on the first machine, the older machine that we have, shows you CPU utilization close to 100% all the way for this period of 10 minutes or so. And then it, boom, came down because we are doing nothing. Artificially, we dropped the load, the stress load. And then it came down. That is good. What about the other box? The other box that got created as a consequence of auto scaling up has performance monitoring very low to zero. Right now, it began with a little bit of 10, but came all the way down to zero as it started. So it is going to be zero because we are not loading it up, and it will stay like that. And at some time in the next few minutes, you should see another auto scaling activity happen. And as a consequence of that activity history, you will see that a third activity becomes visible. That shows you that the scaling policy corresponding to down policy, meaning remove one instance, will happen after the utilization of CPU goes below 70 for two consecutive periods of five minutes. And that is what I'm expecting to see pretty much here. Where is that? Terminal. Yeah, this terminal doesn't indicate much anymore, so I'll just quit. And yes, yes, yes. Due to the auto scaling policy, in effect, when it scales up adding an instance, is it an actual replica of the original, just like a clone, or you can select, you can say what do you want on that machine to be, what happens? So you make a good point. The answer to your question is, it doesn't make a replica. It does whatever you tell it to do. And you define whatever you tell it to do in the launch configuration. In the launch configuration, you specify that I want you to use this image. And so it uses that image. That's it. OK. So the launch configuration has to specify which image you want to grow with or shrink. So that is what the image will pick up and grow. Got it. OK. And so let's see activity history. Nothing yet. But it will kill itself, kill one of the guys itself. No problem, just like that. You will see it happening whenever the time threshold is. So when was the last time? When was the grow happened? When did the grow happen? It happened at 10.49. So at 10.59, meaning at 11 o'clock, we should see some shrink activity. So it's not 11 yet. So we have to wait for it to happen. When it does, it will die. And so I think you get the point. You get the point of auto-scaling. You get the point of this crafting architectural blueprints and capturing them outside in form of file structures that either look like the Terraform example. By the way, I will go through this one the next time when we run the session. So we'll go into detail about how do you do this, how do you write this, and how do you make this for real use in the context of what we want to be able to do. This is just an exercise I want to run to show you what the depth and breadth of possibilities exist around capturing a variety of design implementations you might have in a variety of clouds. And so we will go deeper in this example next time. But for right now, what I want to be able to say is I want to go and say this guy, I trust that you will kill it because what I don't like is waiting. I'm just an impatient guy. I think it killed itself. I think that the killing happened. Let's go see. So back to auto-scaling group. It detected that the CPU consumption is low. So it decides to kill. So it killed one instance. So the action is in progress. It says, I found out that you are doing nothing, CPU. You're idling. I want to shoot you in the foot or maybe in your head and kill you. And so that's exactly what it did. And so it is termination in progress, terminating EC2 instance. It says the reason, the reason for termination is that a monitor alarm triggered by policy and changing the desired capacity from 2 down to 1. And at that time, at 1856, an instance was taken out of service in response to a difference between desired capacity and actual capacity, shrinking the capacity from 2 to 1. And therefore, this instance was terminated. And you see that termination happened. You see that this machine collection that we have in our cloud is only one running instance. The other one is dead. And that was a good demo. I mean, I liked it. I liked it because it ran. It ran. So we'll go back to our cloud formation and look at this example stack that we have, the autoscaling group stack that we created. And I would like to have this tag go bye-bye. So we'll say delete stack, go bye-bye, and it dies. The whole stack dies. And so that's how you kill a stack in a cloud. So let's go back to Northern California. And we will notice that all the stacks are already dead. We don't have any stacks. You will also see that in our EC2 section, we don't have any machines. They are all gone. Back in Oregon region, our stack is still dying. And so it will die when it does. But until that time, you will see that the cloud formation is actually in the process of deletion. You will see some events happening. And those events will basically indicate deletions happening across the board. The whole stack will go down. And as a consequence, this thing will disappear. And along with it will disappear your EC2 instances and your load balancer and your autoscaling group and launch configuration. All of those things will basically go away. Right now, they exist. But they will go away as soon as the configuration is deleted. So bottom line, the key takeaways. There are lots and lots of examples available here in Amazon as well as in Terraform. But all the types of things that people have worked on already. And so the thing that you need to remember is you don't need to reinvent the wheel. The wheel has been already invented for you. You have to use the wheel and then build a car, build something else, build a plane, build something more important by standing on the shoulders of giants that already exist. You just need to know where they are and find them and use them and then build upon them to make your life easy, to make use of what they have already here. So that is the key takeaway. So you saw the autoscaling example. There are a variety of examples available across the board. This is just Amazon. You go to Terraform, there are tons and tons of examples available on GitHub and on Terraform site. And that is how we conclude for today. Next time, we will meet at 7th of March, Tuesday at 4 o'clock Pacific time, 7 o'clock Eastern time. Until that time, I would like to tell you that I'm actually going to travel. I'm going to Alaska. I'll come back by Monday. And I hope to see the Aurora Borealis. That's what I hope to see. And so I'll bring back pictures if I find something. And I will see you guys Tuesday. So we will run the session at scheduled time as planned, which is 7th at 4 o'clock. And I will now stop recording.