Sure! Let me pull out my handy dandy virtualization and spin up a new virtual machine!
For all forms virtualization, it all starts with a hypervisor. A hypervisor is a piece of software that runs and manages virtual machines, and security-wise prevents them from escaping out into the host machine. Because these are VMs they’re running an entirely separate copy of the OS with their own kernels and completely independent environments. As a result, they are amazing resources and tools for data replication in case of emergencies. Used for easy cloning and replication, VM copies can be spun up easily if other images go down or it can be used to clone/copy/paste similar configurations for different purposes instead of having an entirely different physical machine to deal with.
A sandbox performs a similar purpose security-wise but without the virtualisation usually – the application is executing within the same environment using the same kernel as the rest of the machine but it’s isolated from everything else. Overall, virtualization allows the user to expand the capabilities of the hardware while helping to contain IT costs while improving the system’s reliability and security. Managing a variety of virtual machines (VMs), the hypervisor is able to configure each of them to act like it has the system hardware’s processor, memory and resources, however it is just allocating those resources to the VM.
There are two primary types: bare metal and hosted.
Type 1 – Bare Metal Hypervisors
Hardware -> Hypervisor -> Instances
Real enterprise and physical servers. Hypervisor is installed directly on the hardware and then host instances on those hypervisors that is running on the physical hardware. There is typically a management console that actually deals with the hypervisor and instances itself. The server screen itself will basically just display the computer specs and the IP address for the user to access the management console, on a separate PC, but on the same network. Can also automatically schedule and migrate instances to different servers depending on the resource utilization, so on peak times or on low times they can be moved to different physical boxes and allocate the necessary resources as needed. The management software can allow it to migrate as needed if the physical boxes fail to help maintain uptime. Say you have an authentication server on a 16gb server box, obviously on peak hours that might not always be enough to manage and authenticate things efficiently and without latency, as a result the management console can automatically schedule if the used RAM exceeds 12gb, it’ll automatically migrate it to a server box with 64gb of RAM instead to help with those peak usage resource allocation hours. In addition, overallocation can be used which means you can allocate more total RAM to each of the instance than what the actual physical server has itself. Another example would be a 16gb server box with three different instances, let’s allocate 12, 10, and 8 gb of RAM to each of those instances and that will come out to a total of 30gb. Obviously it doesn’t actually do that but it just logically allocates that much RAM to each instance to give it as needed
Type 2 – Hosted Hypervisors
Hardware -> OS -> Hypervisor -> Instances
Computers. Personal desktops. Etc. Things like VirtualBox that can spin up instances on top of a personal operating system. The biggest selling point is a simple configuration and without a need for a management console. Once again it’s important to consider resource allocation, however instead of overallocation, it doesn’t work that way with hosted hypervisors. In these Type 2 hypervisors, it will create a static RAM allocation and thus take away that RAM from the hosting computer. So for a 16gb RAM host computer and you allocate 4gb of RAM to a hosted instance, then you really only have 12gb of RAM available to the hosted computer to manage the hosted instance as well. Also important consideration is the networking as vulnerabilities can travel across through different instances and the network traffic can pass over and mess things up.
The savings are pretty tremendous. The cost of running, say, 100 web application servers on separate hardware includes not only the cost of the physical components, but also:
- rack space needed in the data center, particularly costly if you’re building your own datacenter, or even buying/renting from a third party
- the power consumption of 100 individual units and the associated costs of cooling
- time spent on provisioning new systems (virtualization lets you clone systems easily and quickly with all the same hardware and software features as another system)
- the cost of downtime (features such as live migration, fault tolerance, and high availability are readily available on virtualized platforms and can be difficult to achieve with physical hardware)
- lack of readily available hardware (if I need a new web server today, and I don’t have the spare hardware, what do I do?)
- setup costs (someone has to be paid to drive to the data center, cable the machine, test the hardware, etc. before it’s put into production)
Virtualization also has a lot of benefits around resource utilization that you don’t get with physical machines. Traditionally, server/workstation operating systems such as Windows are notoriously bad at resource management to begin with, whereas hypervisors are designed with resource utilization in mind.
It’s like an apartment building where the physical server is the building and it’s broken up in to apartments (the virtual servers). All of your resources, space, utilities, power, are physically attached to and come into through the building, but once there are divvied up in to the units. Each unit is its own household, the size may vary, the amount of the buildings resources it uses can be very different; but each unit is entirely separate from the others and even has its own address. You can continue with the apartment analogy with purpose and content for each unit, but that’s basically it; physical server = big apartment building, virtual servers = apartments.