ZIO
ZIO Consulting IT architect and software architecture lecturer.

Microservices Positions and Consolidated Definition

(Updated: )
Reading time: 6 minutes
Microservices Positions and Consolidated Definition

Microservice architectures evolved from previous incarnations of Service-Oriented Architectures (SOAs) to promote agility and elasticity. This post updates the SOA vs. microservices positioning part of an older IFS web page on microservices. It also defines microservices via seven tenets, reverse-engineered from books, articles and blogs.

TL;DR: Evolution not Revolution

I see microservices are a contemporary implementation approach for Service-Oriented Architecture (SOA) principles and patterns, emphasizing and benefiting from modern software engineering practices. Please read on if you would like to learn why — or disagree.

Microservices Tenets

To support a comparison, consolidated definitions are required. My 2017 journal paper “Microservices tenets Agile approach to service development and deployment” compared several early definitions and distilled seven tenets1 from them that microservice-based software should have. Here is a slightly updated version of these tenets:

  1. Fine-grained, message-based remote APIs expose independently deployable, scalable and changeable services each having a single responsibility.
  2. Business-driven development is applied (for instance, domain-driven design) so that each service represents and models a business capability.
  3. Services encapsulate their own state, IDEALly in a loosely coupled fashion (which is a cloud application architecture design principle).
  4. Programming and persistence are polyglot, and communication technologies are also chosen in a best-fit “polyglot protocols” manner (for instance, HTTP resources, asynchronous message queues, gRPC).
  5. Services are deployed into lightweight containers.
  6. Decentralized Continuous Integration and Delivery (CI/CD) is practiced.
  7. More DevOps practices are applied, end-to-end service monitoring for business agility and domain observability in particular.

The seven tenets are also featured in this presentation and this one.

Recap: The SOA Style

My 2009 definition of SOA by way of principles (loose coupling, first and foremost) and patterns (service contract and others) can be found in Chapter 2 of my PhD thesis. Here is an excerpt (legend: U stands for user and channel diversity, P for process and resource integrity, I for integration needs and interoperability, S for semantics of business information):

Note: The ESB pattern should not be confused with products or open source assets realizing it (or claiming to do so), and installations of such products. For instance, the pattern does not impose a “single, central physical instance” constraint, but merely emphasizes the need for protocol adaptation, routing and message transformation. Much of the negative bias that can be found online can be attributed to product (mis)-use rather than flaws in the pattern. In this article, we report this smell (and six more, for instance “shared persistence”) in more detail and suggest a “rightsize ESB refactoring”.

Microservices vs. SOA: Positions

Three rather different positions can be observed, both online and in print:

  1. Microservices as a new architectural style competing with SOA and to be contrasted with it (“better SOA”). See this example.
  2. Microservices as a synonym to SOA (“nothing new”), see for instance this blog post and this one.
  3. Microservices as a substyle, variant, and/or implementation approach to SOA (“SOA done right”), see several positions from a SATURN 2015 microservices workshop.

Update (May 20, 2021): Actually, you can find a fourth position: Some say that SOA and microservices solve different problems and cannot be compared. See for instance “Microservices vs SOA: How to start an argument” by Kim Clark. I agree that SOA can be used on the enterprise level (and that component-level reuse often is not a suitable goal in a distributed enterprise system landscape). I do not agree that the SOA style is limited to enterprise architecture work; many successful SOA projects were application-level ones. And why does strategic domain-driven design come into play as a microservice identification technique if microservices are only internal to a single application (and context)? What is the application boundary in a (micro-)services-oriented system anyway?

Maybe the wording compromise is that the principles and patterns of service-orientation can be applied to single applications (building construction in the architecture metaphor) and entire enterprises (city planning). Microservice architectures pose additional constraints and recommend certain implementation approaches, primarily targeting the decomposition of single applications (defined as and identified within one or more domain-driven bounded contexts).

This line of thought can be summarized as:

Enterprise SOA is-a variant of SOA, and Application SOA also is-a variant of SOA; microservices can-implement an Application SOA.

Radically Different? Nothing New?

Going through the various online resources, I found — and continue to find — a lot of evidence for Position 3:

  • In this Software Engineering Radio interview, James Lewis highlights the close connection from/to SOA (assuming that SOA is understood and done right).
  • In this goto 2014 presentation, Martin Fowler points out that it is fair to say that the microservices approach has been done under the name of SOA for at least a decade if not more (with the term SOA being too broad, and meaning different things to different people).2
  • In his SATURN 2017 keynote, Chris Richardson makes similar remarks and defines (micro-)services as loosely coupled and organized around business capabilities, which very much is in line with the SOA definition reported above, as well as SOA introductions such as that in my OOPSLA tutorial 2005 to 2008 (slides).

Let’s go back to the seven microservices tenets now:

  • Tenets 1 and 3 are partially new at best. The independent deployability was there in SOA 1.0, but not utilized much due to technology constraints at the time. The better SOA books from the 2000s gave similar advice about state and statelessness; try “SOA in Practice” by Nicolai Josuttis or “Enterprise SOA” by Dirk Krafzig and his co-authors.
  • Tenets 2 and 4 are not new at all, but defining elements of the SOA style.
  • Tenet 5, 6 and 7 actually contain novel aspects, but deal with service realization (implementation, deployment, governance) rather than style-defining patterns and principles.

The “Tenets” paper referenced above has a deeper analysis. A table in it compares the microservices characteristics proposed by Lewis and Fowler with SOA principles and patterns:

SOA vs. microservices

So I agree with the Sam Newman quote from the first edition of “Building Microservices” to “think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development” (again supporting Position 3).

Still not convinced? A Jan./Feb. 2017 interview with James Lewis, Mike Amundsen and Nicolai Josuttis in IEEE Software, facilitated by the Insights department editors3, contains a side bar that comes to similar conclusions.4

You need even more arguments and rationale from industry thought leaders? Here are two recent blog posts pointing out that services may have any size — and that modular monoliths very much have a place in the modern architect’s toolbox:

  • On Medium, Kyle Brown (IBM Cloud Garage) and Shahir Daya ask What’s the right size for a Microservice? and comment that services should be small — but not too small.5
  • Vaughn Vernon’s (author of “Implementing Domain-Driven Design”) advises that “following a purpose leads to useful cohesion” in Microservices and [Micro]services (and some purposes cannot be codified in a few lines of code).

I could not agree more! Context and requirements must drive the architectural decisions about service granularity and size; for instance, we6 collected 16 coupling and cutting criteria in the Service Cutter wiki and I7 am working on a light domain-driven service design method right now (stay tuned!).

Presentations, Papers, Projects

The updated version of the 7-tenet definition of microservices can also be found in a presentation of Context Mapper, our DDD modeling tool, for the Java User Group (JUG) Switzerland (slide 6 in this deck) and in this 2020 presentation. My CSCUBS 2017 presentation discusses loose coupling and service granularity and reports on research and development efforts at the time, as well as miscellaneous projects lessons learned.

These are some research papers on microservices and related topics that I contributed to:

  • Neri D., Soldani, J., Zimmermann, O., Brogi, A: Design Principles, Architectural Smells and Refactorings for Microservices. A Multivocal Review, 2019 (PDF)
  • Pardon, G., Pautasso, C., Zimmermann, O.: Consistent Disaster Recovery for Microservices: the Backup, Availability, Consistency (BAC) Theorem. IEEE Cloud Computing, 2018 (PDF)
  • Pahl, C.; Jamshidi, P.; Zimmermann, O.: Architectural Principles for Cloud Software. ACM Trans. on Internet Technology (TOIT), 2018 (PDF)
  • Furda, A.; Fidge, C.; Zimmermann, O.; Kelly, W.; Barros, A.: Migrating Enterprise Legacy Source Code to Microservices: On Multitenancy, Statefulness, and Data Consistency. IEEE Software, 2018 (PDF)
  • Pautasso, C.; Zimmermann, O.: The Web as a Software Connector. Integration Resting on Linked Resources. IEEE Software, 2018 (PDF)

You can find more on the papers and presentations page of this website. My older IFS page Microservices Resources and Positions collects many more pointers.

Three publication, research and development projects that I currently lead are Microservice API Patterns (looking into the request and response message that service consumers and providers exchange), Microservices Domain-Specific Language (MDSL) (a contract language that maps to OpenAPI, Protocol Buffers, GraphQL schema language, Jolie) and Software/Service/API Design Practice Repository (DPR) (a best-of-breed collection of templates, checklists and other design method elements).

Shorter versions of this post are available on Medium: Microservices Tenets and SOA vs. Microservices Positions. I hope you found it useful and worth sharing. Whether you agree or disagree with my analysis, I’ll be very interested in your arguments, please let me know them!

– Olaf (ZIO, socadk)

Notes

  1. I prefer the term “tenets” over “characteristics” or “principles” to indicate that I do not intend to provide a formal, strict definition but report common industry practices. 

  2. which by now also holds for microservices, semantic diffusion striking again!  

  3. disclaimer: I am one of them 😉 

  4. The article also discusses the relationship of Domain-Driven Design and microservices as well as other service design issues. Part 2 of the interview was published in the next issue and covers architectural and organizational concerns such as service composition, data integrity, and versioning.  

  5. They even go back to the roots of the word “micro” in ancient Greek to make their case! 

  6. two of my students with professional development experience, an industry partner and myself 

  7. putting my research hat on