What is a container?

A container is a standardized unit of software that packages up software code into standardized units for development, shipment, and deployment. Read along to learn everything you always wanted to know about containers.

What is a container?

Background

The world of computing has varied environments. A computing environment includes computer machinery, data storage devices, client devices, software applications, operating systems, networks supporting processing, and exchange of data and information as needed by the software application. For the sake of clarity, computing environments include personal computing, client server computing, distributed computing, cloud (grid/cluster) computing. Various platforms help address different processing and operational requirements, but their use also helps explain the complexity of working with software applications IT environments. Initially, the conventional approach was to isolate applications to the specific environment they were written for, and build connectors to other environments.

API to SOA / SOAP to Microservices

API to SOA / SOAP to microservices - An Application Programming Interface (API) is an example of a connector referred to above. APIs are a set of definitions and protocols that are defined to allow different applications to interact with each other. This solution was efficient when applications were heavy and larger in size and were written in select environments to leverage computing capabilities, operational, and security needs. As web-based technologies emerged, connector approaches evolved from legacy APIs and the use of HTTP, JSON, URL, XML, to Simple Object Access Protocol (SOAP) and the use of HTTP and XML, to Service-Oriented Architecture (SOA). As web-based technologies evolved to cloud-native applications, serverless and virtual computing emerged. With the requirement to perform across multiple environments, including on the cloud and on devices with lower processing power, applications have become specific service-oriented, and developed with fewer lines of code. This led to emergence of microservices architecture4, and the evolution to SOA. Microservices arrange an application as a collection of loosely coupled services. - an evolution to service-oriented architecture (SOA). Microservices arrange an application as a collection of loosely coupled services.

The classic case for a container

Containers help resolve a typical dilemma faced by many developers in the evolving native-cloud based application opportunity, – varying computing environments meant that an application tested using Python 2.x could face issues because the production environment ran on Python 3.x ---- or ---- the application is tested on a certain Secure Socket Layer / SSL library, while the production environment has another one installed. Additionally, variations in security settings, file storage setup and network setups could cause the application to fail.

Emergence of containers

To allow applications, like microservices, to operate across computing environments, the concept of the containers emerged. While virtual machines (VMs) were in use before containers, VMs for microservices were bulkier due to OS images in the VM. A container is a logical packaging of the application, isolating it from the environment in which it runs. This allows container-based applications to be deployed with ease, regardless of the target environment which could be a private data center, the public cloud, or even a personal computer.

Containers made an appearance over 10 years ago, built into Linux with LXC. Other versions, like Solaris Containers, FreeBSD Jails, and AIX Workload Partitions followed. However, most developers recognize Docker for introducing the modern container era.

A single container can be used to run a microservice or even a software process to a larger application. The container consists of all the necessary executables, binary code, libraries, and configuration files.

The Open Container Initiative (OCI) run by the Linux Foundation helps to develop industry standards for container formats and container runtime softwares across platforms. The first standards were based on Docker technology, and Docker was an early developer of containers.

OCI sponsors include AWS, Google, IBM, HP, Microsoft, VMware, Red Hat, Oracle, Twitter, and HP as well as Docker and CoreOS.

Summary

To allow applications like microservices to operate across computing environments, the concept of containers emerged. A container is a logical packaging of the application, isolating it from the environment in which it runs. This allows container-based applications to be deployed with ease, regardless of the target environment, which could be a private data center, the public cloud, or even a personal computer. Containers encapsulate discrete components of application logic through microservices, provisioned only with the minimal resources needed to accomplish their job.

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.