Containers

Notes
April 5, 2018

In the traditional approach, applications are deployed on an OS with a set of services(database server, HTTP server) running. Applications can also be deployed on a virtual machine or a physical host that can provide such environment. But any update in the libraries on host OS may affect the multiple applications running on the OS. So anytime there is an update, the applications must be stopped, and it must be made sure that these updates do not break the application pipeline. Due to this CI/CD might become difficult. This traditional approach is pretty high maintanence, time consuming(takes time to boot and shut down the application) and uses good amount of resources.

What makes these Containers so nice?

  1. Low hardware footprint(smaller the footprint, lesser the space occupied)
    • Uses cgroups and namespaces to manage resources, which minimizes the amount of CPU  and memory overhead compared to the VM hypervisor/monitor.
  2. Environment isolation
    • Every application can run in it’s separate container with it’s own dependencies. Updating dependencies of an application in one container, does not affect the application running in another container.
  3. Quick deployment
    • Traditionally, deploying an application on a physical machine or VM requires fresh installation or restart of an OS  on the destination and any simple update requires restart of the entire OS.
    • Containers on the other hand are super nice! There is no need of fresh installation or restart of OS while deploying the container or while updating.
  4. Multiple environment deployment
    • In the traditional approach, any environment difference can potentially break the application. An application may work just fine on one machine, while it may not work on another machine.
    • But no such problem arises with containers, since the same container image is used. Thus, bringing an end to the “runs on my machines😏” problem.
  5. Reusability
    • The same container image can be reused by multiple applications, without the need to set up a full OS. A database container can be used to locally create a set of tables for a software application, and it can also be easily destroyed and recreated without much effort. We can use the same database container can be used by production environment to delpoy an application.

Well, containers may not always be so nice! For instance, applications accessing low-level hardware information – memory, file-systems and devices may fail if containerized. But containers are useful for most of the applications, although containerizing all the services(db, messaging, filesystems) in a single container or separate containers may depend upon the application.

Containers are really useful when an application is built on microservice architecture, where multiple services are used to run a single application. Microservices enables continuous delivery/deployment of large and complex applications. Containers provide a lightweight and reliable environment to create and run services that can be deployed in both development and production environment. So all the services can be deployed in separate containers making sure that even if one service is down, it will not bring down the entire application/system.

Some of the container providers include – Docker, LXC, Rocket, Drawbridge

References:  [1]http://microservices.io  , [2] Fundamentals of Containers, Kubernetes, and Red Hat OpenShift