Microservices and containers
Microservices would not be as effective an approach if it weren’t for containers. Much like virtual machines, containers are a form of virtualization, but whereas VMs virtualize the hardware, allowing multiple operating systems to run concurrently on the same hardware, containers virtualize the OS, allowing multiple workloads to run on a single instance of an operating system.
Virtualization is the act of dividing up computational resources (CPU, RAM, storage, connectivity) and wrapping them into individual scopes. To these virtual spaces, they believe they are a real, full system, unaware they are just a part of a larger machine. This allows multiple environments to run on the same hardware, and is the fundamental makeup of the cloud space, allowing multiple users to access a cloud system that may be running many more environments than the physical infrastructure would seem to support.
Virtualization, using either VMs or containers, contributes to IT flexibility, agility, and scalability, however, containers are aptly suited for microservices. Compared to VMs, containers are much smaller because they virtualize at the user level. A container contains a package of software, with the necessary dependencies, including code, runtime, configuration, and system libraries for it to be able to run on a host. Container instances sit atop a container engine that orchestrates the creation of containers, their resource allocations, and manages them. In this way, a container can be created from an image, holding and running a microservice, giving it exactly the resources it needs, and finally can blink out of existence instantaneously when it’s no longer needed. Has the microservice failed to require it to be reset? Simply spin up a new container, and discard the failed one. Additional workloads press the system, responsive automatic scaling can duplicate containers to meet demand. Containers are light-weight and compared to VMs or a server reboot can multiply and collapse nearly instantly.