Microservices: Terribly Named, Ambiguously Defined
For a profession that stresses the importance of naming things well, we’ve done ourselves a disservice with microservices. The problem is that that there is nothing inherently “micro” about microservices. Some can be small, but size is relative and there’s no standard of unit of measure across organizations. A “small” service at one company might be one million lines of code while far less at another.
Some argue that microservices aren’t a new thing at all and rather a rebranding of Service Oriented Architectures, while others advocate for viewing microservices as an implementation of SOA similar to how Scrum is an implementation of Agile.
Regardless, the poor naming of microservices is one of the reasons behind misconceptions and misapplication of microservices. Lots of developers, even those in three-man teams, are jumping on the bandwagon of splitting up apps into far too many services without understanding what microservices really are.
When a popular, attractive-sounding term like “microservices” flies around, it’s easy for the concepts behind it to get lost and distorted. Martin Fowler calls this Semantic Diffusion.
Semantic diffusion is essentially a succession of Chinese whispers where a different group of people to the originators of a term start talking about it without being careful about following the original definition. These people are listened to by a further group which then goes on to add their own distortions. After a few of these hand-offs, it’s easy to lose a lot of the key meaning of the term unless you make the point of going back to the originators.
The misconceptions don’t just affect people who want to use microservices, it also stokes the fires of those that are dismayed by the industry hopping on the microservices bandwagon without a deep understanding of its concepts.
Microservices pic.twitter.com/3xYWUgP2QW
— David Neal 🥓🥑 (@reverentgeek) July 10, 2017
Most critique is not necessarily a critique of microservices themselves, but rather a criticism of failed application of microservices coupled to (and likely caused by) a misunderstanding of microservices.
Without this knowledge, failures are attributed to the entire concept of microservices rather than the failure to use them successfully.
The Ideal Definition
There’s a lot of ambiguity around what microservices are in part because no precise definition exists. Like Agile, microservices are a collection of broad concepts rather than concrete practices.
How exactly the term “microservice” was invented has been documented by Martin Fowler:
The term “microservice” was discussed at a workshop of software architects near Venice in May 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on “microservices” as the most appropriate name.
James Lewis’ 2012 presentation at 33rd Degree in Krakow titled “Microservices — Java, the Unix Way” presented these new ideas and described microservices as a way of develop software faster by dividing and conquering using Conway’s law to structure teams.
Since then many others have continued to pioneer and advance the concepts around microservices including Fred George, Adrian Cockcroft (Amazon), Fowler (ThoughtWorks), and Sam Newman (ThoughtWorks).
Their definitions are fairly well aligned:
Newman:
Microservices are small, autonomous services that work together.
Lewis:
Fine-grained SOA architecture done the UNIX way.
Cockcroft:
Loosely coupled service-oriented architecture with bounded contexts.
Fowler and Lewis:
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
The problem with these definitions is that while they are helpful for introducing the idea of microservices when it comes to time put them into practice, they are not very helpful. Using these definitions, how would you determine whether it makes more sense to have 10 tiny services versus five medium-sized ones?
In his book “Building Microservices,” Newman explains that the right size is “Small enough and no smaller… We seem to have a very good sense of what is too big, and so it could be argued that once a piece of code no longer feels too big, it’s probably small enough.” Again, this doesn’t help you make a clear decision.
Ambiguous descriptions of microservices aren’t useful other than as an introduction. When it comes time to put microservices into practice, you need to find other ways to align your team.
