Why use containers?

Container technology has emerged as the preferred deployment platform due to its characteristics. Read through to learn the importance of containers, their benefits, and their role in microservice deployments.

Why use containers?

Microservices

As computing evolved to deployments in native-cloud and serverless architecture, there was a need for lighter software applications that could be:

  • Deployable independently, and be maintained and tested by smaller teams
  • Coupled loosely with other business applications and processes

These requirements led to the concept of microservices, also known as the microservice architecture. This is an architectural style that structures an application as a collection of services that are fine-grained and the protocols are lightweight. Microservices enabled legacy technology solution stacks to be broken into smaller logical units/parts that can run independently on cloud environments, allowing these complex applications to be quickly tested and reliably deployed.

Microservices, being loosely coupled and independently deployable as smaller services, needed a platform that supported lightweight deployable capabilities.

Benefits of containers

Container technology emerged as the preferred deployment platform for microservices due to characteristics, like being light, modular, and portable:

  • Light – A container encapsulates the microservice (Layer 5 in the graphic) that are fine-grained (providing specific code for specific business services), and that include specific messaging protocols (Layer 4 in the graphic) relevant to the specific business service. This makes a container light, starting at only few tens of megabytes in size. This light deployment allows multiple containers and, in turn, microservices to be hosted by one physical machine. As microservices are light, they do not need to be continuously loaded onto computing resources, and can be initialized immediately when needed, as well as be available for just-in-time use, and shutdown when not in use.
  • Modular – Since one container could run a database while another could run an application front end, a complex application can be split into modules across containers. This modular approach aligns container as a platform for the microservices architecture approach. The modular approach eases management of individual modules in a complex application, and changes in a module can be made without rebuilding the entire application.
  • Portable – Containers are OS independent, as they share the machine OS kernel through the platform (Layer 3 - Container Runtime in the graphic). While this allows portability across devices for organizations, such as developer laptop to on-premise private data center, to private and public cloud environments. Portability can be limited to an extent by the container platform’s OS compatibility. For example, Red Hat OpenShift supports only containers with Linux images. Additionally, specific container platforms may not always be backward and forward compatible with updates and new releases in OS.

DevOps / CI-CD as drivers for container adoptions

Container and microservices adoption have been led by organizations that have transitioned to modern development and application patterns like DevOps and CI/CD as the way to build, release, and run software.

Summary

As the concept of microservices emerged, enabling legacy technology solution stacks to be broken into smaller logical units/parts that ran independently on cloud environments; these loosely coupled and independently deployable smaller services, needed a platform that supported lightweight deployable capabilities. Container technology emerged as the preferred deployment platform for microservices due to characteristics like being – light, modular, portable.