While that is technically possible, finding a “place to stand” has not turned into a practical possibility yet. It’s a similar story with Containerization. It’s not practical to move the entire IT world from VMs to containers. A more practical approach that will bring in more business benefits is to identify specific target workloads and focus on those instead of trying to containerize all the workloads in a datacenter.
Why containerize in the first place? When the IT world turned from Waterfall to Agile methodology for app development and moved from Monoliths to Microservices based apps, instead of running these microservices in heavy VMs, it was inevitable to switch to a lightweight alternative – Containers.
This model became a catalyst for some of the upcoming technologies like IoT and Data Analytics. DevOps methodologies and tools that enabled continuous integration (CI) and continuous delivery (CD) fast tracked the adoption of containers. CI/CD pipelines automated the workflow across various stages of app development – check-in and integrate code changes, validate, build, package, test and finally deploy the new release in production.
Containers are lightweight since it does not include an entire Operating System (OS) image and leverages the underlying host OS instead. It contains only the application and the dependent libraries. That enables various applications to run in containers side by side on the same host without conflicting with each other, even different versions of the same application, with its own set of libraries packaged in the container. This architecture makes it very easy to port containers from one host to another in a Data Center (DC) or Public Cloud as long as the underlying OS is compatible. Since most containers used by businesses are Linux based, OS compatibility has not been a challenge. Windows containers are comparatively newer, and we will talk about that a little later.
