Where are containers used today?
This is an open-ended section. The intent is to tell where and how containers are used today in a production environment. This section also introduces the concept of container orchestration with Kubernetes, the most used open source orchestrator solution, adopted by thousands of companies worldwide. Container adoption is spreading across every enterprise company in every business sector.
But if we investigate the success stories of companies already using containers or a Kubernetes distribution, we'll discover that containerization and container orchestration are accelerating the project development and delivery, speeding up the creation of new use cases in every kind of industry – from automotive to healthcare. And regardless of the economics, this is really has a great impact on computer technology in general.
Companies are shifting from the old VM deployment model to a container one for new applications. As we briefly introduced in the previous paragraphs, a container could be easily represented as a new way for packaging applications.
Taking a step back to the VMs, what was their main purpose? It was creating an isolated environment with a reserved number of resources for a target application to be run.
With the introduction of containers, the enterprise companies realized that they can better optimize their infrastructure, speeding up the development and the deployment of new services introducing some kind of innovation.
Looking back (again) to the history of containers' adoption and their usage, we can see that at the beginning, they were used as a packaging method for old-style, monolithic application runtimes, but then once the cloud-native wave rose and concepts such as microservices became popular, containers became the de facto standard for packaging next-generation, cloud-native applications.
Important Note
Cloud-native computing is a software development practice to build and deploy scalable applications in public, private, or hybrid clouds.
On the other hand, containers' format and orchestration tools were influenced by the rise of microservice development and deployment; that's why today we find in Kubernetes a lot of additional services and resources, such as a service mesh and serverless computing, which are useful in a microservice architecture.
Important Note
Microservice architecture is a practice to create applications based on loosely coupled, fine-grained services, using lightweight protocols.
From our daily job with customers adopting containers, we can confirm that customers started packaging only standard applications in containers and orchestrated them with a container orchestrator, such as Kubernetes, but once new development models arrived at the developers' teams, the containers and their orchestrators started to also manage this new type of service more and more:
Figure 1.6 – Microservice architecture on a real application
Just to give us a bit more context around the microservice architecture topic, consider the previous picture, where we find a simple web store application built with microservices.
As we can see, depending on the type of client we're using (mobile phone or web browser), we'll then be able to interact with the three underlying services, all decoupled, communicating with a REST API. One of the great new features is also decoupling at the data level; every microservice has its own database and data structure, which makes them independent in every phase of development and deployment.
Now, if we match a container for every microservice shown in the architecture and we also add an orchestrator, such as Kubernetes, we'll find that the solution is almost complete! Thanks to the containers' technology, every service could have its own container base image with just the needed runtimes on board, which ensures a lightweight pre-built package with all the resources needed by the service once started.
On the other hand, looking at the various automated processes around application development and their maintenance, an architecture based on containers could also be easily fitted on the tools of CI/CD for automating all the needed steps to develop, test, and run an application.
Important Note
CI/CD stands for continuous integration and continuous delivery/deployment. These practices try to fill the gap between development and operation activities, increasing the automation in the process of building, testing, and deployment applications.
We can say that containers' technology was born to fulfill system administrator needs but ended up being the beloved tool of developers! This technology represented in many companies the conjunction ring between the developers team and the operations one, which enabled and speeded up the adoption of DevOps practices that were previously isolated to increase collaboration between these two teams.
Important Note
DevOps is the group of practices that help link software development (Dev) and IT operations (Ops). The goal of DevOps is to shorten an application's development life cycle and to increase an application's delivery release.
Even though microservices and containers love to live together, enterprise companies have a lot of applications, software, and solutions that are not based on microservices architecture but previous monolithic approaches, for example, using clustered application servers! But we don't have to worry too much, as containers and their orchestrators evolved at the same time to support this kind of workload too.
Containers technology can be considered an evolved application packaging format that can be optimized for containing all the necessary libraries and tools, even complex monolithic applications. Over the years, the base container images evolved to optimize the size and content for creating smaller runtimes, capable of improving the overall management, even for complex monolithic applications.
If we look at the size of a Red Hat Enterprise Linux container base image in its minimal flavor, we can see that the image is around 30 MB during download and only 84 MB once extracted (through Podman, of course) in the target base system.
Even the orchestrators adopted internal features and resources for handling monolithic applications, too far from the cloud-native concepts. Kubernetes, for example, introduced in the platform's core some features for ensuring the statefulness of containers, as well as the concepts of persistent storage for saving locally cached data or important stuff for the application.
