architecture service-oriented-architectures microservices monoliths
Architectural patterns such as Micro-frontends, Backend for Frontend, Experience Services, and Domain Services are evolutions of service separation and specialization a.k.a. service-oriented architectural style (Read more in my previous blog post: Service Oriented Architecture - Slice and Dice about what these patterns are with examples). These patterns are designed to address specific challenges. Just like with any decision we make in software engineering, when we choose to use these patterns over other ways of solving the challenge, we need to understand the benefits, costs, and key enablers of these patterns. This understanding allows us to create a lay of the land and understand the trade-offs we are making.
architecture microservices service-oriented-architectures

In 2014, Martin Fowler and James Lewis put together a blog called "Microservices" after having concerns about the loose use of the term. I was working with ThoughtWorks at the time and, being a massive fan of Martin Fowler, I would always read his work. Although a decade has passed since then, and despite the clarity provided by his work and the community, the term 'Microservices' is still used loosely. There are definitely firms pioneering this architectural style, but many more are just following the trend for the sake of the name.

Ever since the term SOA was coined in 1996, there has been a lot of ambiguity surrounding it. In this blog, I am attempting to take a step back and explain what service-oriented architectures are and where microservices fit in. We will start by exploring SOAs themselves. Then I will move on to discuss the architectural styles sliced by sizes and finally examine the various implementation approaches based on functionalities. None of what I propose is new knowledge, it is an attempt to bring it all on a single page with the intent to form a reference for technical decision-making in organisations and teams.