Too often, technical options are framed as an “either/or” proposition. There seems to be a sense that if you use technology A, then technology B cannot be implemented; the reality, however, is that the relationship between technologies is often so complex that they defy such comparisons.
Very few things in the software world fall into this paradigm as strongly as containers and microservices. Often discussed as competing strategies, the two represent different ways of thinking that can be leveraged to provide a better overall product.
Below, we’ll compare containers and microservices. We’ll look at what makes them suitable to the average developer, what some strengths and weaknesses are, and some use cases that they are appropriate for. We’ll also discuss some standard technologies behind both and look to the future to see where they are going.
What is a Container?
In its most basic form, a container is simply an isolated process. It is a collection of segmented resources and application functions to do one specific thing — it is, quite literally, a “container” filled with all the code, dependencies, and a runtime environment required to perform a process.
A container is essentially like a car. Cars contain everything a person could conceivably need to get from one location to another in relative comfort and safety. From the engine, the air conditioner, to the carburetor, everything is designed for the specific form function, and there’s very little extraneous functionality. You’ll never find a standard-issue sedan built with an oven inside, because that’s not within the domain of what it’s supposed to accomplish.
This limit in functionality and pre-packaged form factor delivers several benefits. Chief among them is the fact that it allows for portability across stacks and platforms. When a container contains everything required to function, it is platform agnostic — the container can do the work it needs to do regardless of where it lives. Additionally, this makes the containers lightweight and efficient, as there’s minimal outside dependency or unexpected requirements that make operations heavy.
#docker #graphql #kubernetes #microservice #rest apis