¡Holaaa! 😁
Welcome to the transcript of our latest "What the Cloud?” episode! And lucky for you, this post has WAY MORE DOODLES than the video itself. 😁
If you happened to watch the previous episode, we talked about Cloud storage and the Amazon S3 service. You may even remember that I mentioned we were going to learn about Virtual Machines in Episode 5. So let’s do that today!
We’ve explained what servers are before, but at this point, you’re probably wondering.. what the cloud is a Virtual Machine?
A Virtual Machine (VM) is an emulation of a computer system. In other words, creating a computer within a computer. It uses software instead of a physical computer to run programs and deploy apps. One or more virtual “guest” machines run on a physical “host” machine.
Before VMs existed, what you had was physical hardware. Servers. Do you remember how in Episode 1 we explained that a server is a physical piece of hardware? So let’s pretend to time travel back in time about 15 or 20 years ago... and these servers, this physical hardware, they had maybe 1 xCPU. Maybe 1 Gig of ram. What you were able to do back then was install 1 application on it. Perhaps something like a web server to host a website. This is not a lot of space, is it?
Now servers get stored in racks, in Data Centers. Each rack holds more servers. And then these racks of servers are what is being stored inside those Data Centers (DCs).
If we count the amount of servers I may have in my drawing, it really isn’t that many. Let’s count! 1, 2, 3, 4, 5... times 4 racks... that’s 20 servers. Which means, if we calculate each of these pretend servers to have only the aforementioned 1xCPU and 1 Gig of ram... it will mean 20 web servers. Or 20 applications. Again, it doesn’t sound like a lot to us today, but back then, that was enough.
So what started happening? What changed? As companies and business requirements changed, 20 servers... 20 web applications was no longer enough! So what do you do? Well now inside of your server, instead of storing 1 application, now you start storing 2 applications. 1 web server and 1 mail server. Now we have more than 1 application per server.
But again, this is not that much. Now let’s fast-forward to only 10 years ago. Heeeyyyy, now these servers are getting better, fancier. They don’t come with only 1xCPU of storage, now they have 64xCPU and 128 Gigs of Ram!
Now, earlier we said you had that 1 web server... If you try to put that 1 web server into your server, and you use that entire hardware server for only 1 OS (Operating System) for that application that only needed 1xCPU and 1 Gig of Ram... then you are effectively wasting space! Your current hardware server still has over 125xCPUs left of space! Think of the amount of waste that you are creating. Your servers are being wasted.
Let’s go back to look at our 4 racks of servers in our DC. Now someone comes to you and says, “Hey, we have a new requirement now. We need to run more than 20 apps now. From now on, we want to be able to run 100 apps minimum, but we don’t want to increase our numbers of servers. We still want to stick to 20 hardware servers because we only have enough physical space in our DCs for that amount.”
What would do you do? Well, you can try to convince them to buy more DC space, or you can start to think of how to fit 100 apps in only 20 servers. If we do this last option, then we have to figure out how to fit more than 1 app per server.
But now software segregation comes in and it could cause a problem.
Wait, I bet you’re wondering “what the cloud” segregation means here. It is a separation, a splitting of a larger network into smaller network segments via something such as firewalls. One of the major advantages of such splitting is improved security.
Let’s get back to our drawing example though. If you have a web server and a mail server — 2 applications — on the same server, what prevents them from talking between each other? What happens if someone hacks our mail server and then reads all our emails? That would be pretty bad!
So currently, we have 2 problems: (1) Too many apps for the amount of physical servers we have; and (2) We are wasting our servers, because we don’t need as much capacity as these modern day servers come with for just 1 individual app.
🙌🏽 Enter the Era of Virtualization!
Virtualization takes that physical server and splits it up. And then each one can have it’s own OS. Here’s one OS, and here’s another OS, and here’s another OS.. and now I can have all kinds of apps in a single hardware server. Look, here’s my web server, here’s my mail server, and here’s my game server.
Ah, now this is segregation! And now you also get to have better utilization of each individual server, because now you have more than 1 app that runs per server.
So this Era of Virtualization that introduced VMs was two-fold. ONE, it allowed us to finally add segregation between our applications, so that they can’t talk between each other. Again, this is good to help prevent hackers!
TWO, it allowed better utilization of the resources of our servers. So even though we only have 20 servers, if we do the proper separation and have say... 3 VMs per server, we now have 60 VMs. And if we can have 60 VMs, then that means we can have 60 apps, because 1 app x OS.
Ok, but now we have a different kind of problem! Do you notice all the duplication that is happening here? OS, OS, OS...
We have 3 different OS here and this is a waste of memory too! The problem began because we were trying to fit more than 1 app per physical server, so we created VMs and separated the OS. But now we accidentally ended up with a lot of duplicate OS. So we are still being wasteful! We definitely have better utilization now, but it’s not exactly great just yet.
This is when containers joined this era.
I know, I know... you’re wondering, “what the cloud” is a container? Well, we will actually go into a lot more detail in Episode 6 on this, but for today, all you need to know is that a container is a form of operating system virtualization. It packages up code and all its dependencies so that your application can run quickly and reliably from one computing environment to another.
Ok. Let’s get back to explaining what containers have to do with VMs. What containers finally allowed us to do was to only have 1 OS and then on top of that OS, you have all of your apps that run as containers. So containers now solved the next level of the utilization problem that VMs originally helped improve in the past.
Now what I want to do is briefly head over to the AWS Management Console and go to the EC2 console.
Amazon Elastic Compute Cloud (EC2) is the Amazon Web Service you use to create and run virtual machines in the cloud (we call these virtual machines 'instances').
Let’s click the Launch button. All you need to do is follow these 7 steps to launch your 1st EC2 instance.
Step #1 is to Choose an Amazon Machine Image (AMI). Think of this as our OS. Look at all our options, all our flavors. We can pick from Amazon, Ubuntu, Windows, Red Hat and more! These OS all have Pros and Cons.
We are going to launch a Linux virtual machine on Amazon EC2 that falls within the Free Usage Tier.
For Step #2, we need to choose the size of our Instance. Remember... Instances are virtual servers that can run applications.
We are keeping it simple, so 1xCPU and 1 Gib of Ram should be more than enough for what we want to do. The size you decide to pick for your Instance Type will depend on your workloads. Let’s click Next.
For today, we won’t go into extreme detail on Step #3 Configure Instance Details. We can configure items such as adding an IAM role.. determine shut down behavior.. enable CloudWatch detailed monitoring.. But again, for today let’s leave the default configs.
We move on to Step 4: Add Storage. Again, we have many options to pick from. Today we are keeping it simple so 8 GiB is more than enough. We could also add New Volume Types of storage. Do we want to Delete on termination?
Now we can move on to Step #5: Tags. Ah yes, tags. Metadata.
I can put in ‘Name’ and ‘Web Server 1.’ I can add another tag. A Cost-Center and the Cost-Center number.
Now it’s on to Step# 6: Configure Security Group. A security group helps you add rules to allow specific traffic to reach your instance.
I’m going to pick HTTP type and pick a beautiful name for my security group.
Finally, the last step! Step 7: Review Instance Launch. We review our instance launch details and click the* Launch *button.
A pop modal asks us to “Select an existing key pair or create a new one.” AWS is basically saying, “Heyyy... I am not going to give you a username and password for this.”
This key pair is comprised of a public key and a private key file. I ‘create a new key pair’ and pick a name for it. Now I click the button, Download Key Pair. What I have downloaded here is my private key, in a file format called pem format.
This key pair is what will allow us later to connect to this EC2 instance.
Ok. Time to finally Launch our instance!
Success!
If we go back to all of our Instances, we can find this one we just created!
Wow, that was a lot to cover but I hope that Servers and their relationship to VMs make a lot more sense now!🎉
All right everybody, thank you for joining us in today’s episode of What the Cloud? ! In the next episode, we will talk about Containers. I can’t wait to see you there!
~Alejandra💁🏻♀️ y Canela🐾
Top comments (3)
Amazing Alejandra :)
thank you for the nice words and encouragement! 🤖🤖🤖
Thanks for explaining virtualization and segregation so easily. Also, a bit of packaging.