Will Docker help the micro kill the monolith?
Taking a closer look at whether containers and microservices live up to the hype.
Application development using Docker container technology represents a shift in application architecture. Instead of monolithic applications there is a growing push to build applications comprised of microservices which are stateless whenever possible. These microservices are then easily distributed, updated, and scaled – or so we are led to believe.
The pros and cons of microservices
So what do we really gain from microservices? The benefits are many. Here are a few:
But microservices come with a few disadvantages, including:
The monolith has benefits as well:
What about a hybrid?
“Micro-Monolith” is a term I’ve heard referring to a hybrid type of application architecture. I’ve seen it implemented as a few coarse-grain Docker containers, and as a single virtual machine running a few coarse-grain Docker containers within it.
While technically a Docker application, it misses on the spirit of a microservices architecture. It does provide easier distribution (a key benefit of Docker and containers) but little else. Micro-Monolith could be considered a stepping stone to a true microservice architecture.
Let’s take a three tier app and compare how each architecture might address it. For simplicity we will assume the database is in a separate container for all options.
Architecture: 1 container with web, business, and persistence tiers combined
Summary: Easy to manage; traffic is hidden within the container; may have difficulties scaling; can’t scale or adjust resources differently for the tiers
Architecture: 3 containers – web, business, and persistence tiers
Summary: Still fairly easy to manage; traffic is more visible; could scale and adjust resources tier by tier
Architecture: 2 functional areas (arbitrarily chosen) each with 3 containers – admin (web, business, persistence); user portal (web, business, persistence)
Summary: More containers to manage; traffic is more visible and tunable as components are broken along functional lines; scaling and resources can be specific to function and tier; can have targeted updates by function and tier; etc.
The bottom line
This is a simple example, yet it illustrates that when you architect for microservices you have more flexibility. Development and testing is more focused and therefore will speed your ability to operationalize pieces of your system.
But be mindful of the disadvantages mentioned above. As someone once said, with great power comes great responsibility.
Are we being led down a primrose path of easy distribution, updates, scaling, and troubleshooting? Maybe. But from where I sit, it appears the micro will kill the monolith.