GP - Fotolia


Deciding when it's time to combine containers and microservices

Containers can offer wonderful benefits for microservices, but that doesn't mean they should always be used in conjunction. Tom Nolle explains the pros and cons of this approach.

Containers are probably the fastest-growing and most broadly exciting development in virtualization and cloud computing. Microservices are a close second, so anything that could combine these two developments is something to look at closely. 

However, cloud planners and application developers should frame the benefits of containers and microservices independently, and then in combination. They should pay particular attention to the kind of dynamism their applications will develop and also make plans for service federation.

It's complicated

The relationship between containers and microservices is complicated because it's not fixed. Containers are not necessary for microservices deployment, nor are microservices needed to justify container use.  Containers are an operations tool that can improve deployment time and efficiency, but there are other comparable tools, such as virtual machines (VMs). Microservices are a way of enhancing application agility and code reuse, but there are other approaches here as well. That's why it's critical to look at all your software goals when assessing the benefits containers will bring to your microservices environment.

Let's start with the most compelling point: operational technology. Most IT professionals know containers are a form of virtualization that avoids duplicating the operating system across machine images by providing a common platform that is shared amongst all components. The most common container tool is Docker, and it's already well-known as an easy way to deploy virtual and cloud components. Containers currently lag VMs as the dominant deployment technology in virtualized data centers and private clouds, but they're gaining and will likely overtake VMs quickly.

For users who have not considered virtualization or private cloud adoption because they fear the complexity of hypervisors and VMs, containers offer a wonderfully lightweight way of hosting microservices.

On the development side, microservices are an evolution of the longstanding trend toward application componentization and loose binding of components. Small and generally useful software functions are published as network-connected services for reuse across a range of applications. This can also reduce software image size by letting every application use one copy of a general function or feature, and it can enhance development by creating a new software model that approaches one of module assembly or no-code. Microservices are gaining ground on other models, including SOA, for new applications.

For users who have not considered virtualization or private cloud adoption because they fear the complexity of hypervisors and VMs, containers offer a wonderfully lightweight way of hosting microservices. You can deploy them quickly, replace them quickly, and move them and even replicate them if you have a performance problem or a server failure. There's no question microservices in containers are a better approach than hosting them traditionally.

So, container or VM?

If containers are a logical alternative to traditional hosting of microservices, then the only question on container adoption is whether the VM alternative is even better. When a real decision around combining containers and microservices is to be made, look at how containers and VMs compare in their support for microservices.

There's no question containers are efficient microservices hosts. A microservices model involving a large number of separately hosted components could waste a lot of memory if each microservice were to be hosted in a VM with an independent OS. The multiplicity of OSes would also make maintaining version control in machine images more burdensome and put more pressure on operations.

The primary factor to consider when deciding if microservices can be effectively hosted in containers is the extent to which your company demands strict isolation of key applications for security or compliance reasons. Because they share an OS, containers are not as robust as VMs in sustaining independence among tenant application components. Microservices that are shared between applications with isolation requirements and those without them offer a similar possible point of compliance risk. 

Where no isolation of applications is needed, both containers and microservices can be freely deployed, and using both will improve development and operations efficiency. But when application isolation is needed, both container technology and microservices will have to be deployed with compliance guidance. This should start with a network connectivity plan that separates applications that demand special security from the others and places them onto protected subnetworks.

This is easily accomplished with enterprise software-defined networking technology, and even traditional IP networks can be partitioned this way. Look for support that specifically provides connectivity and access control to the subnets that host applications with security and compliance requirements. Also, be sure there's no risk of data or access leakage if you share microservices between secure and traditional applications.

Suppose you successfully address the compliance risks of containers and microservices. Can containers then help with microservices deployment? The answer is yes in nearly all cases, and the combination is more valuable with every microservices deployment. The biggest benefit will come from the memory savings generated by eliminating the OS from each image, but you may also find server usage efficiency is much higher with containers in microservices applications.

Good microservices practices dictate that you don't want to make a microservice out of a function that is constantly invoked. Network-coupling these functions will generate propagation delay that will eventually affect runtimes and quality of experience. This means most microservices will be lightweight, minimal users of resources. You'll limit the number you can host per server and increase operations costs if you allocate each microservice to a VM.

The operational downside of containerized microservices could be DevOps. DevOps tools typically support VMs better than containers, and container systems like Docker have traditionally provided limited internal support for complicated deployment orchestration. The more complex your microservice deployment is, the more important it will be to ensure you have proper DevOps tools available. So, before you commit to containers, look carefully at your DevOps options.

Some Docker users have found great value in turning to DevOps based on the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) specification. Unlike most DevOps tools that have their roots in traditional data center deployment, TOSCA is a cloud architecture, and blueprints are available for most container deployments.

In summary

Microservices should be easy, and containers can make them so. But container use in microservices deployment can exacerbate security risks across application boundaries that could violate corporate security and compliance guidelines. Take care with containers and microservices in order to keep everyone happy.

Next Steps

Learn more about the combined effect of microservices and containers

How to manage a heterogeneous hypervisor environment

Things to consider while enabling microservices through the cloud

Dig Deeper on Distributed application architecture