My brief definition of Microservices

James Lewis and Martin Fowler have an excellent description of Microservices that I encourage anyone and everyone to read. Unfortunately, not everyone has the patience to read what amounts to an academic paper, so I will do my best to write something shorter, more approachable, and perhaps less intimidating.

I believe it’s easiest to understand Microservices as an evolution of a “Cloud Service”. I will define a Cloud Service as:

Software with an API accessible over TCP/IP

The contemporary wisdom of how “Cloud Services” should be architected can be thought of as having the following loosely-defined stages:

  • 1995-1998: Monolithic Procedural code with a Query String API returning XML
  • 1998-2002: Monolithic Object Oriented Code with a Query String API returning XML
  • 2002-2004: Monolithic Layered Object Oriented Code with a REST API returning XML
  • 2004-2006: Monolithic Layered Object Oriented Code with a REST API returning JSON
  • 2006-2008: Domain Modeled Layered Object Oriented Code with a REST API returning JSON
  • 2008-2010: Domain Modeled Layered Object Oriented Code with a REST API returning JSON that delegates work to other Cloud Services
  • 2010-2012: Domain Modeled Layered Object Oriented and/or Functional Code with a Message API that delegates work to other Cloud Services via an Asynchronous Message Queue
  • 2012-Today: Sub-Domain Modeled Object Oriented and/or Functional Code with a Message API that delegates work to other Cloud Services via an Asynchronous Message Queue

The last stage is how I define a “Microservice”:

  • Sub-Domain Modeled… – The “micro” in Microservice; It does not encompass the entire problem-domain, only a smaller portion of it (authentication, order processing, logging, etc.)
  • …Object Oriented and/or Functional… – It is irrelevant how exactly these services are designed, due to their loose coupling
  • …with a Message API… – Messages have no strict definition, and are purpose-designed to transmit whatever services need to communicate
  • …that delegates work to other Cloud Services… – Due to the loosely coupled nature of each service, to do something of practical value requires a collaboration among multiple services (NOTE: If poorly designed, this will create more problems than it solves).
  • …via an Asynchronous Message Queue. – This is where much of the horizontal scaling, system stability, and deployment benefits come from, as each service instance can be scaled and deployed independently without fear of messages being missed.

Many definitions for Microservices exists, and most of them are correct. The difficulties in discussing Microservices arise when an attempt is made to conflate an abstract architectural design concept to a specific system implementation. The two might be correlated, but a Microservice should not be described by a specific system implementation, but instead by the desired architectural characteristics. To say it another way, the problem you are trying to solve should dictate the architecture you design, and some (not all) problems benefit from a Microservice architecture. As with all software design challenges: Define the problem before considering solutions.

In the future, what we call a “Microservice” will evolve into something else that has characteristics we need for the software challenges we encounter. We are just now discovering how to create architectures that best incorporate physical devices with telemetry as their cross-cutting concern (i.e. “The Internet of Things”), non-deterministic problem-solving services (i.e., machine learning, AI, fuzzy-query big data-sets), as well as non-deterministic computing services (i.e. eventually consistent data stores, quantum computing, spacial graph analytics). Each of these will require novel architectural approaches that may be built on Microservices, but we have yet to discover and codify what these new approaches will be.

To help keep your mind open and ready to accept new architectural challenges, every once-in-a-while review the Gartner hype-cycle. The awareness of future challenges will help prevent you from developing a cognitive bias towards your favorite architectures. To be in the best position to design architectural solutions to future problems, every potential solution must be at your disposal – those others have thought of, as well as those you will have to invent to address your specific challenge.


For those wanting to build a foundation in abstract architectural concepts, I would recommend the following books to be read and understood in sequence:

  1. Design Patterns: Elements of Reusable Object-Oriented Software
  2. Patterns of Enterprise Application Architecture
  3. Domain-Driven Design: Tackling Complexity in the Heart of Software
  4. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s