In a previous blog, we talked about how microservices have changed application modernization. A somewhat related concept that’s also had an impact is that of containers. And, as it so happens, microservices and containers work well together for app modernization.
As a refresher, with microservices, an app is broken down into a collection of small, loosely coupled services. Each service is continuously developed and separately maintained and communicates through a clearly defined, lightweight framework to achieve a business objective.
Containers wrap up a piece of software in a complete filesystem that contains everything it needs to run. This guarantees that it will always run the same, regardless of the environment. Containers are well suited for use with microservices for a number of reasons.
The Benefits of Containers for Microservices
The lightweight nature of containers makes them extremely amenable to use with microservices. They can encapsulate a lightweight runtime environment for an app, and provide a consistent environment that can accompany an app from the developer’s desktop all the way to the final production deployment.
Containers also remove the dependencies on the underlying infrastructure services. Access to resources, such as storage, can be abstracted from the app itself. Because the container handles much of the access to native cloud resources, this makes the app portable and speeds up the refactoring of the app.
In addition, containers provide better-distributed computing capabilities. An app can be divided into many different domains, all residing within containers. The containers can be run on different cloud platforms, including the ones that provide the highest cost and performance efficiencies. As such, apps can be distributed and optimized according to their utilization of the platform from within the container.
Containers also provide programmers with more flexibility. Any programming language that the OS supports can run in a container. Plus, each individual microservice can run in its own container. That reduces the costs of managing services.
Additional reasons that containers work well for microservices: they offer finer-grained execution environments than VMs, better isolation for component cohabitation, and faster initialization and execution.
Containers vs. VMs
Of course, microservices can be built and run without using containers. A microservice can run as a fully provisioned VM. VMs make it easy to partition execution environments. The problem is that each VM requires its own OS. No app component can be executed without placing it in a VM. That’s why, from an efficiency perspective, containers are a better option.
VMs contain all OS components, but containers only have the microservice code itself and supporting code libraries. Other functionality is shared on a common OS with other microservices running in containers.
An app within a container operates independently from those in other containers but still answers to directives from the kernel or orchestration tool. While it’s possible to run multiple app components within a single VM, this introduces the risk of conflicts between components that can lead to app problems.
Containers perform execution isolation at the OS level. A single OS instance can support multiple containers, each running within its own, separate execution environment. Running multiple components on a single OS reduces overhead and frees up processing power for app components.
Because containers enable multiple execution environments to exist on a single OS instance, multiple components can exist together within a single VM environment. Developers don’t have to segregate app code into separate VMs. Processing power previously devoted to those VMs can be used by the app code. With this kind of isolation, multiple microservices can be placed on a single server. Services can’t interfere with each other, and container efficiency allows for higher server utilization rates.
Containers also have a performance advantage over VMs. Every VM must run its own execution environment and OS copy. This uses up server processing cycles that would otherwise be used to run the apps.
Size presents another issue. VMs can be large, which means they can take a long time to get up and running. Microservices-based apps tend to experience highly erratic workloads. With a VM-based microservices app taking several minutes to respond to a traffic spike, users can experience delays and possibly not have access to what they need.
Containers are much smaller than VMs, and start much faster. They don’t require the lengthy OS spin-up time that a VM does, so they’re more efficient at initialization.
This works better with microservices’ erratic workloads, and the shorter container initiation times can help increase user satisfaction and improve the financial performance of revenue-generating apps. In addition, because containers can launch in seconds or milliseconds, additional service components can be deployed immediately when and where they’re needed.
It’s important to note that containerized apps can have their share of complexity. In production, these apps may require hundreds to thousands of separate containers. This is where container runtime environments benefit from the use of tools to manage all the containers in operation and automate and scale container-based workloads for live production environments.
Tools aside, microservices can still require numerous updates, and the associated processes require many decisions to be made. For example, should a microservice be updated through a blue-green deployment setup with new containers spun up and then the old ones taken down? Or is the better option to use rolling updates in which a new container is created and put in service while taking out an old container? A certain amount of skill and expertise is required to ensure the right decisions are made in order to yield optimal results.
The ClearScale Advantage
ClearScale has extensive experience in the use of containers, container orchestration tools, and microservices for cloud application development services. You can read about one of them here. Because of ClearScale’s work, this client has been able to take advantage of the wide range of third-party services natively integrated with Kubernetes, a container orchestration tool. It also now benefits from the use of microservices which, even when managed by separate teams, can be updated independently. There are many other case studies demonstrating ClearScale’s expertise.