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:

  • Polyglot: Instead of restricting your application, and more importantly your development teams, to a single language, you build the service in the language which correctly suits the problem.
  • Interface driven: Teams agree on interfaces and interactions between services (i.e. contracts).  I prefer these contracts to be captured in code rather than in documentation. This helps to keep them from going stale.
  • Testability: Smaller services with contracts facilitate more thorough automated testing.  Smaller services are easily virtualized and/or simulated by mock components.  The ability to easily mock and virtualize also benefits development.
  • Resilient: Struggling with an ill-behaved service?  Microservices enable simple (and quick) restarts.  However, this may only address the symptom and not the problem.
  • Encapsulated runtime environment: Containers bring their runtime dependencies with them.
  • Updates:  Targeted fixes within an application.

 

But microservices come with a few disadvantages, including:

  • Size: The majority of existing images are large – in the range of several hundred megabytes.  Many are built without regard to security attack surface.  Things are improving with more attention to smaller base images like BusyBox and Alpine.
  • Deployment orchestration: Startup ordering, configuration of containers, etc. are all considerations.
  • Runtime management: Monitoring and troubleshooting can become (even more) difficult, dealing with vague symptoms like “the system is slow.”

 

The monolith has benefits as well:

  • Experience: We have been building them for years
  • Fewer parts: There are fewer things to keep track of.  A typical 3-tier app consists of a Web Tier, a Business Tier, and a Persistence Tier

 

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.

Monolith

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

Micro-Monolith

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

Microservice

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.

Do you agree? For more, meet up with me at CA World ’16 or tweet @MarkEmeis.

 


Mark Emeis
Mark is an intrapreneur and founder of Yipee.io, a CA Accelerator project, focusing on building…

Comments

Modern Software Factory Hub

Your source for the tips, tools and insights to power your digital transformation.
Read more >
RECOMMENDED
Low-Code Development: The Latest Killer Tool in the Agile Toolkit?What Are “Irresistible” APIs and Why Does Akamai's Kirsten Hunter Love Them?Persado's Assaf Baciu Is Engineering AI to Understand How You Feel