What Makes a Microservice “Micro”?

People really like to be able to use numbers. We see this in management; we see it in requirements gathering. Numbers, after all, are objective. Objective is better than subjective, right?

The answer, of course, is “it depends”. If one can defend the proposition that a given number equates to a given level of quality, then an objective measure should be preferable. If, however, the number is arbitrarily selected, the fact that it’s a number doesn’t change the fact that it was subjectively chosen.

Take, for example, the size metric that “defines” a microservice. According to James Hughes (who considers the definition “atrocious”), “…there seems to be a consensus that a micro service is a simple application that sits around the 10-100 LOC mark”. Does this mean that when the codebase hits 101 lines of code, the result ceases to be a microservice? Does this mean that higher-level languages are required to create microservices because lower-level ones would exceed the LOC limit before expressing something useful?

Clearly a quantitative metric that is irrelevant to what we really want to measure won’t work. This leaves us to choose a valid way to make a qualitative judgement about what makes a microservice “micro”.

There’s the cynical approach:

and there’s the pragmatic approach:

In my opinion, the defining characteristic of a microservice is that it’s an application (in terms of having an independent codebase that is independently deployed) that exists as a component of what an end-user would be more likely to consider the actual application. A microservice is part of the internals of what is the perceived application. It is important to remember that the microservice architectural style is an application architecture style.

I believe that Ben Morris’s suggestion that “…a single deployable service should be no bigger than a bounded context, but no smaller than an aggregate” is a good heuristic for identifying the service boundary. It puts the emphasis on cohesiveness rather than size. It is the single responsibility principle at the application/component level of abstraction.

In my opinion, a microservice is a component of an application that is independently scalable and independently deployable, possess an independent lifecycle, codebase, and data. It is “micro” in the sense of “microcosm” rather than “micro” in terms of some arbitrary unit of size.


3 thoughts on “What Makes a Microservice “Micro”?

  1. Pingback: Are Microservices the Next Big Thing? | Form Follows Function

  2. Is it possible that we could consider reusability narratives to constrain the definition of a microservice? Might I suggest that it no longer qualifies as a microservice if it takes more than one concise sentence to describe the capability or it takes more than one sentence to describe the outcome? As soon as a service provides more than one outcome, it dramatically drops in reusability, and the second thing I want in a service is reusability. The first is correct outputs for all well-formed inputs.


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s