How microservices and containers work, apart and together
Microservices and containers are two methods that enable companies to more efficiently create and deliver applications. Here's how they work -- and when they're best used together.
Containers and microservices are related concepts that help companies design and adopt applications with speed, efficiency and flexibility. It's hard to talk about one without also talking about the other. Microservices and containers are distinct technologies -- they don't have to be used together, but they often are. Let's break down how each works, their key similarities and differences, and how an enterprise can use them in tandem.
What are microservices?
Microservices are individual units of software that combine to provide all of the functions required to run an application. Typically, each microservice handles a discrete type of functionality within an application. For example, one microservice handles logins, another generates the UI, another populates the interface with content specific to each user session and yet another interfaces with the database that stores user data.
Until about 2010, most applications were monolithic designs in which the entire application ran as a single unit and, in most cases, as a single process. Prior to wide adoption of the internet and APIs, a service-oriented architecture (SOA) approach evolved to break applications into somewhat smaller pieces. However, the individual services within an SOA are typically not as small or dynamic as microservices.
There are several reasons microservices have become popular over the past decade:
- Agility. Breaking applications into small pieces makes it easier to scale those different parts up and down. For example, if login requests spike, the application can run more instances of the specific microservice that handles logins.
- Resilience. If one microservice fails, the rest of the application remains intact, although part of its function might be unavailable. In this respect, microservices architectures are more resilient.
- Easier updates. Developers can update and redeploy microservices individually, which is more efficient than reinstalling the entire application each time an update becomes available.
- Maintenance. Typically, developers write and manage code separately for each microservice. This simplifies development work because it eliminates the need to sort through an expansive code base for every change.
What are containers?
Containers are semi-isolated environments in which applications, or parts of applications, can run. Unlike VMs which run entirely separate OSes, containers directly share resources with the OS of the server that hosts the containers. This makes containers more efficient than VMs because each containerized environment does not require a complete guest OS.
This article is part of
What are microservices? Everything you need to know
Moreover, containers are isolated at the process level from other containers, as well as noncontainerized processes that run on the server. This isolation makes containers more secure than multiple applications that run directly on a host server. Each container can have different environment parameters, rather than all containers sharing a common configuration.
Technology to deploy applications inside containers has existed since the introduction of the Unix chroot call in the 1970s. Containers became massively popular in the mid-2010s with the introduction of Docker and Kubernetes, which provided tooling that made it easier for developers to create and manage containerized applications.
Microservices vs. containers: Strengths and differences
The main difference between microservices and containers is that microservices are an architectural paradigm, while containers are a means to implement that paradigm. Containers host the individual microservices that form a microservices application.
However, an enterprise can host and deploy microservices in a variety of other ways:
- Serverless functions. These provide isolated environments that run code preconfigured to respond to triggers such as a user login request.
- VMs. It's uncommon to host microservices inside VMs. Nevertheless, it's technically feasible for developers to deploy a set of microservices inside individual VMs and then connect them together to form a microservices app. This provides even stricter isolation between microservices than do containers.
- Directly on the OS. There is also no technical reason why you can't deploy a set of microservices directly on the same OS and not isolate them inside of a container or VM.
- Unikernels. These lightweight, self-booting environments contain everything required to run a specific application or service. They can be used to deploy microservices on a server without a conventional OS.
How microservices and containers work together
Nevertheless, containers are the most popular way to implement a microservices architecture, for several reasons:
- Fast start times. VMs take up to a few minutes to start, but containers can typically start in just a few seconds. It's easier to maximize the agility of microservices when they are hosted inside containers.
- Security. Containers provide isolation for each containerized application or microservice, which reduces the risk that a security vulnerability can spread. Microservices deployed directly on a host OS are less secure in this respect.
- Service discovery. It's simpler for microservices to locate and communicate with each other when they all run in containers that are managed on the same platform. If you deploy microservices in VMs, serverless functions or unikernels, each host may have a different networking configuration. This makes it harder to design a network architecture for reliable service discovery.
- Orchestration. Along similar lines, microservices are easier to orchestrate -- schedule, start, stop and restart -- when they run in containers on a shared platform.
- Tools. The tools that support microservices deployment with containers have significantly matured over the past several years. Orchestration platforms for containers, such as Kubernetes, are massively popular and well supported in every major public cloud today. By comparison, there are few tools to orchestrate microservices hosted in unikernels or VMs.
When to choose containers vs. microservices
Put simply, for an enterprise that wants to deploy microservices, containers offer the best tradeoff among security, performance and management. In some scenarios, it makes more sense to deploy microservices without containers -- for instance, a workload may require especially strict isolation between microservices, or several microservices require different OS environments. VMs might be better suited for these situations. Also, keep in mind that containers can host monolithic applications, not just microservices.
For the foreseeable future, though, expect containers and microservices to fit together in a way that other technologies within the microservices landscape do not.
