Welcome back, and in this video,


I'm going to step through physical and virtual servers.


If you understand both of these,


when I cover container architecture in a future video,


it will make more sense and the differences will be obvious.


Now, I don't want to waste too much time on this,


so let's jump in and get started.


Physical servers should be pretty easy to understand


for anyone who's worked in IT for any length of time.


Generally, you buy physical servers upfront,


meaning you own 100% of the capacity


of that physical server.


The flip side, though, is that if you have a failure,


it's 100% your problem.


Anything running on this server will stop


and you need to handle any hardware repairs or replacements.


A server really is just a collection of hardware,


things like a motherboard, some CPUs,


a certain amount of memory, a collection of storage,


and possibly some add-on cards, such as GPUs


or other cards for specific workload needs.


All of these need to be chosen by you for their features,


but also sized appropriately.


And this, the sizing, is one of the main issues


with using physical servers.


These resources collectively form the capacity


of the physical server.


They influence how much can be run on that server


before it shows performance issues.


But, and this is often forgotten,


it's this capacity that you've paid for.


And so, ideally, you want to consume it in its entirety


so that your business gets maximum value.


Now, what runs on a physical server varies,


but at a conceptual level,


you start with the operating system,


the software which allows you or an application


to interact with the hardware.


Now, you'll want to run something on this operating system,


maybe an application,


but applications use runtime environments,


so these are dependencies and libraries.


If you run an application written in Java, for example,


there's going to be additional things that run


within that Java runtime environment,


which are required for your application.


And these also consume resources.


Now, at this stage, you have a functional application


running within the runtime environment


on the operating system.


But what about all of this?


This is the capacity of the server, which you aren't using.


And there are two main ways of handling this.


One, it's wasted, so you don't consume it


and it just sits idle.


You're basically throwing away or burning money.


You might not have given sizing much thought


when you chose the specific type of server,


or you might have sized the server much larger than you need


to cope with sales or other busy periods.


But unless you use it, you waste it.


Alternatively, you could consume it with other applications.


This means you're not wasting any money,


as your investment in hardware is being used.


And if you pick applications


which have their usage peaks at different times,


you can actually be pretty efficient


with hardware utilization.


But, and this is a major risk with this approach,


if one of the applications fail,


this can cause the other applications to fail.


One disruption causes other disruptions.


And before long,


much of your business' stack can be offline.


Historically, this was how IT was done, with servers.


You picked the hardware, you sized them,


you added some buffer to cope with busy periods,


and hoped for the best.


This approach tended to be risky


and wasn't effective at using resources well.


And that's where virtual servers, or virtualization,


comes in handy.


And let's look at that next.


With virtual servers, things are slightly different.


We still use physical servers,


only now, we refer to this as a host,


a virtual machine host, or a VM host.


And since this host is still just a physical server,


it has resources, so CPU, memory, storage,


and optionally, add-on cards,


just the same as physical servers.


Now, before we talk about how this VM host


runs your typical operating system runtime


and application stack,


there's a new component


which I want to introduce, a hypervisor.


Now, there are many different vendors


which make hypervisors.


You might have heard of VMware, Hyper-V,


VirtualBox, Xen, KVM.


These are all examples of hypervisors or hypervisor stacks.


The job of a hypervisor is to manage


physical resources within a server.


So, physical resources in a server


are designed to have one thing accessing them,


the operating system.


With virtual servers,


you are carving up the physical capacity,


allowing multiple virtual machines


to run on the same physical hardware,


and so, something needs to sit in the middle


to act as a referee or arbiter,


and that's the job of the hypervisor.


So, now, we have the capacity of our VM host,


capacity which is accessed via the hypervisor.


Now, I'm not going to go into detail of how hypervisors work


at a deep technical level in this video.


That's a topic for another dedicated video.


Conceptually, just imagine the hypervisor is working


behind the scenes controlling access to physical resources.


The operating systems that run on top of the hypervisor,


they don't even need to be aware of it.


So on top of the hypervisor,


we create and run virtual machines.


These are just like physical servers


in that they each have an operating system,


one or more runtime environments,


and one or more applications, but they're virtual.


They have no direct access to the server hardware.


Instead, they access the VM host hardware


via the hypervisor.


Now, virtual machines can be all the same size,


or you can create bigger and smaller virtual machines


which are sized perfectly


for the specific job that they need to do.


You can configure a VM host


so that each virtual machine has its own dedicated resources


and this means you never go over 100%


of what physical hardware the host has,


or you can oversubscribe.


If you have 20 virtual machines


which only consume resources 50% of the time,


they could in theory be put into a host,


which could otherwise only host 10 virtual machines


which consume resources 100% of the time.


What's really important to remember,


especially when I talk about containers


in a different video,


is how virtual machines are isolated.


They have their own operating system,


they're self-contained.


They generally have their own allocation of resources


so they can be as active and as noisy as they need to,


without impacting other virtual machines.


In fact, if you have the failure of one virtual machine,


then it should only impact


that one specific virtual machine.


You should be able to reboot that one VM


without impacting any of the others.


You can patch VMs without impacting other virtual machines.


You can even change the size of a virtual machine,


so allocating more or less resources


as the requirements on that VM change.


In most cases, you won't just have one VM host.


Instead, having multiple controlled by the same hypervisor.


Your pool of resources will be split


across multiple underlying VM hosts.


And you can even move, or migrate, virtual machines


from one VM host to another while they're running.


And this can either be an explicit action performed by you


or an automatic process to handle capacity needs,


or it can be due to one of the VM hosts failing.


And in this sense, virtualization can help your ability


to recover from failure in a disaster scenario.


Virtual machines are much faster to start up


versus physical machines.


They don't have the same


hardware testing process to go through,


so reboots and cold starts can be much quicker.


They also offer much better resource utilization


versus physical machines.


You can host many VMs on a single physical host,


while not having the risk associated


with many applications running on the same OS.


Instead of having many applications on one operating system,


you have many virtual machines,


each hosting a single application on their operating system.


The virtual machines are entirely isolated,


each running their own copy of the operating system,


and this means each of them is protected


from the activities of others.


But this also might mean that you waste resources


because each copy of the operating system


needs its own resources to run.


If you're running 50 copies


of the same operating system, say Debian,


then you're wasting a lot of resources


because of this duplication.


And this wastage due to duplication


is something that containers fix,


and that's something I'm going to be talking about


in a separate video.


Now, at this point, that's everything I wanted to cover.


I've talked briefly about physical servers


and virtual servers,


I've talked about the differences


and you can use this knowledge to fully understand


the benefits provided by using containers.


But at this point,


that's everything I wanted to cover in this video.


So, go ahead and complete the video, and when you're ready,


I look forward to you joining me in the next.