-
My friend: Hi Ibrahim, I have a question for you.
- Me: Please, go ahead.
-
My friend: I want to understand what is the trigger to move from Physical Servers into VMs and Containers?
- Me: Let’s assume that we have one physical server using one operating system (OS) with two apps installed on it, which are app A, version 1.0 and app B, version 1.0 and both apps are using a shared library v1.0. When app A has an update to v2.0, the shared library needs to be updated as well to shared library v2.0 which will make app A perform well, however app B will fail as it needs shared library v1.0 and so you can choose either to wait for both apps to have the same dependencies or separate the two apps in two different servers. So, you can imagine if every app needs a dedicated server with its own dependencies, we’ll have a huge number of physical servers in enterprise data centers. So, applications were deployed in separate servers not necessarily for performance or security reasons, but to guarantee stability following updates. Same applied for telco world, as we have a separate HW for each function, so for example, SGSN equipment is only SGSN and can’t be MSC or HLR and you can’t combine the SGSN, MSC, and HLR in one HW.
-
My friend: So, how did we solve this problem?
- Me: By using server virtualization which breaks the 1:1 relationship between apps and HW. A piece of SW, called a hypervisor, logically partitions the HW resources of a physical server into VMs. Each VM has its own OS (it is called guest OS) and application stack that are self-contained which means both can be updated without causing a dependency conflict with other VMs. So, virtualization solved the problem of huge number of physical servers, but introduced another problem
- Me: By using server virtualization which breaks the 1:1 relationship between apps and HW. A piece of SW, called a hypervisor, logically partitions the HW resources of a physical server into VMs. Each VM has its own OS (it is called guest OS) and application stack that are self-contained which means both can be updated without causing a dependency conflict with other VMs. So, virtualization solved the problem of huge number of physical servers, but introduced another problem
-
My friend: Really, what is the new problem here?
- Me: Companies had potentially ten times the number of VMs as they did servers, so the principal challenge of virtualization then became the onerous maintenance and patching of the operating system within each VM.
-
My friend: So, how did we overcome this new challenge with virtualization?
- Me: By using containers concept. So, another piece of SW called container engine, will provide application isolation and dependency management without the need to virtualize the OS, so all containers on a server share the OS of this server whether the server is using bare-metal or VM infrastructure. Each container is a complete instance of the application including all its various dependencies and so when a new app version is released, the developer published a new version of the container, even you can run multiple containerized versions of the same app on a single server. Of course, Kubernetes should be used to manage and orchestrate all these containers.
-
My friend: Thank you so much, you made it very clear.
-
Me: You are welcome.
Please press the like and share buttons to spread this info.
LinkedIn: 