Strategic monoliths and microservices - Driving Innovation Using Purposeful Architecture - Book review and takeaways

Microservices have gotten attention in the industry since its inception. The idea of having independent deployment, scalable services, and rapid interaction was quickly spread across developers and among decision takers in the software
community.

Therefore, such advantages took more attention than its counterparts, leading to the microservices hype and later on to the reflection on the learning that the community got. For example, some interesting things happened when a big open source project tried adopting microservices and had to go back to the monolith.

The community brought some insightful learnings and thoughtful thinkers tried to warn the difficulties of maintaining such architectural pattern in production. In this same blogs post, I already wrote some lines about microservices, Production ready microservices by Susan J. Fowler was the first book I read that shared some learnings on standardizing microservices, in the book, the experience gathered from Uber was shared for readers to understand what it takes to build such an ecosystem. Not only that, I also shared some thoughts around the book "Architectural Patterns" by Mark Richards, where he lists different architectural styles including microservices.

Finally, here we are once again to go over one more book, this time the chosen one is "Strategic monoliths and microservices: Driving Innovation Using Purposeful Architecture" by Vaughn Vernon and Tomasz Jaskula, the idea is to go over the highlights I did while reading the book and mix that with some of my own thoughts on the subject.

Note: in this post I tried to follow the author's book structure, starting from part I till part IV.

Takeaways

If you are busy, here goes the takeaways:

• Microservices for some reason are hype and monoliths were converted in something "bad"
• Adopting microservices come with trade offs that are usually ignored (async communication, distributed tracing and so on, Sam Newman shared more info regarding that)
• The decision to go for microservices of not, should be backed by business purposes (thus the name of the book "purposeful architecture")
• DDD and event sourcing is used heavily to depict the approach of discovery the "real" business needs
• Throughout the book, the monolith and later or the modulith are the approaches recommended most of the time
• Legacy systems that are monoliths carry the risk of never being retired because of business needs - Maybe this one could benefit from https://martinfowler.com/articles/patterns-legacy-displacement as an alternative
• The strategy to shift to microservices implies that the application is a modulith with defined boundaries (again DDD is used)

Part 1

Chapters 1 through 3

The first part of the book gives an introduction of what strategic means and how the authors will approach things moving forward in the book. This part the authors spend most of the time building the ground in which they will expand and use later on to use as an argument of why monoliths and why microservices (with the business goal always in mind). In the end, we are building things for a reason.

Sadly, the authors have found that most companies and teams creating software claim to use Agile, yet don’t understand how to be agile.

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture - Vaughn Vernon and Tomasz Jaskula

An introduction to event sourcing is also shared and used as a technique to discovery and experimentation,those can be a powerful tool to dive into the business weeds and get the most important part that will bring value, this is what the authors called essential strategic learning tools. Learn fast, experiment often and fail often.

The greater part of the knowledge is carried by individuals in their minds. The knowledge that has not been externalized is known as tacit knowledge.

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture - Vaughn Vernon and Tomasz Jaskula

When starting to read the book, much of my concerns were around the actual implementation and how real the proposed thinking could be applied in real world projects. This part depicted most of the pains and the reasons behind change, which is the opposite of big corporations - often those big corps prefer the status quo - but as the authors said innovation is key for business continuity.

Some keywords to go further on this sections:

• Inverse Conway's law
• Bruce Tuckman on organizational behavior
• Cynefin framework
• ADR's

Part 2

Chapters 4 through 7

The second part is where the authors start to use the concepts from Domain Driven Design to depict a strategy guided by business needs and also to start gluing what was presented in the first part.

Besides that the critique on what agile became is something that made me realize that after 20 years of agile, most of the industry thinks that agile is SCRUM, this is my interpretation of what the authors says on Don't blame agile.

Even worse, as the authors depict, SCRUM also lists knowledge acquisition as the last requirement in the framework[^1].

How can a team place a new feature in the backlog before they understand it?

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture - Vaughn Vernon and Tomasz Jaskula

For the authors, knowledge should be the center in the impact of doing something for the business. Which I totally agree with, there are some things that we as an industry just forget about, we even create some buzz words to stay away from the business and to create a barrier in the language while communicating.

You might ask, why knowledge is so key for the success of a business, and the authors take this one clear and loud:

As the saying goes, “you can’t time the market.”

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture - Vaughn Vernon and Tomasz Jaskula

Learning should be the end goal to be able to navigate the monolith and also to start to understand the contexts in which the application lives. Systems that are labelled as Big ball of mud exist and with them years of technical debt are accumulated, but in there, there is lots of information to get from and understand how a business operates.

It is worth saying that splitting a big system, or at least modularizing some of its parts, of it helps teams to understand better what each piece is doing. This is important
as the authors say that to eliminate of of those giant will never happen.

Any amount of effort in a large enterprise will never eliminate all messy and unseemly legacy bits.

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture - Vaughn Vernon and Tomasz Jaskula

To help understand and organize better the contexts within the business and the legacy systems, some strategies from Domain Driven Design can help.

For example, creating a ubiquitous language for the team to talk and share knowledge (this can help to normalize the different knowledge gaps that team members have), bounded contexts so the team have an understanding where the things start and end.

The idea of mapping and having everything like that in place is to allow teams to understand, communicate and to fail fast and learn. The authors also depicted the usage of those tools in chapter 6 named "Mapping, Failing, and Succeeding-Choose Two".

• Partnership
  • In the discussion of this Context Mapping type, let’s limit a Partnership mapping to being one that occurs between two teams.
  • It’s often true that two teams have aligned goals and neither one can succeed without the other.
• Shared Kernel
  • A Shared Kernel is a mapping in which it is possible to share a small model among two or more Bounded Contexts
  • More than 100 nations use ICD-10 codes for reporting statistics on causes of death. These kinds of standards form natural Shared Kernel models.
• Customer–Supplier Development
  • One team is considered upstream. The other team is considered downstream. The downstream team needs integration support from the upstream. The upstream team holds sway over what the downstream team gets.
  • Establish a formal relationship between the two teams that keeps each side honest in their communication and commitment toward support, and in being a customer that understands they are not the solitary pressure that their supplier, and possibly a former partner, faces.
• Conformist
  • A Conformist relationship is in force when at least two of a few conditions exist
• Anti corruption Layer
  • This pattern takes a defensive integration perspective by making every effort to prevent the upstream model from corrupting the downstream model.
  • Although this book is not meant to make technology recommendations, it does seem appropriate to acknowledge that the introduction of GraphQL represents a game-changer for such jobs.
• Open-Host Service
  • Think of an Open-Host Service as an API for exchanging information, where some exchanges might require the API provider to support data mutations from downstream onto their upstream model.
• Published Language
• Separate Ways

The authors also share that failing is a good way of learning:

Failure can lead to good because of the learning opportunities it produces.
That kind of controlled failure is based on a scientific approach
using experimentation and ultimately leads to success.

With all that in place, in this part the authors also take the time to go over a few DDD concepts and recap them. Here is the first mention of the second book of this series, as the examples depicted here are "light on details" the authors highlight that the next one is focused on implementation.

• Entities
• Value Objects
• Aggregates
• Domain Services
• Functional Behavior

Part 3

Chapters 8 through 12

The last part, at least for me, was one of the most interesting parts as the
focus shifted towards an architectural point of view and did some overviews
around hex architecture and event driven architecture.

If you think that good architecture is expensive, try bad architecture. —Brian Foote [BBoM]

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture - Vaughn Vernon and Tomasz Jaskula

As in other books, the definition of architecture comes into play. The idea
of bringing communication and understanding to this definition shed some
lights on the discussions around conflicting areas.

As also mentioned in the book Clean architecture, paying for architecture
can be done now or later. But, as later as it gets, the more expensive it will be, maybe this all comes to the why of the book, shifting left the decision of architecture is also important.

The authors make clean that the goal of an architecture is to achieve some
attributes, named:

• flexibility
• security
• performance and
• scalability

Of course, with the business needs in mind, the authors are in favor of the
hexagonal architecture, in the book, they dive into what it is, and why
to use such style. In here, I also tried to put together what I understand. And having a hexagonal architecture does not imply necessary microservices.

Nevertheless, the book follows as a review of different architectural styles, named:

• REST Request–Response
• Event Sourcing
• CQRS
• Serverless

Part IV

The last part of the book focuses on different aspects of software architecture focused on how to deliver a architecture (be it monolith or microservices) based on business needs.

The authors also offered something around "intellectual honesty" which for me is something to take into account for decisions that were taken from people that lack the proper knowledge.

In the end, I would also add people that try to hide some information.

When a Monolith has not been architected, designed, and implemented as a desirable, well-modularized Monolith, a course correction is difficult but not impossible.

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture - Vaughn Vernon and Tomasz Jaskula

I reserve this last beat to focus on the strategy that the authors propose in the last chapters as a way to ease the transition (if needed). I would assume that most of the companies that are trying or tried microservices are suffering because of the path they took, it seems that the authors also faced that:

When dealing with a legacy Big Ball of Mud, taking the trek directly to a Microservices architecture will be the most challenging journey.

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture - Vaughn Vernon and Tomasz Jaskula

In this part the authors share what we as an industry should have known for a long time.

The importance given for developers and architects are depicted as clear as water in a way to make us reflect: "Don’t underestimate the importance of hiring top software architects and developers. Do top businesses look for bargains in C-level executives?". It seems that as the industry grew, the bar needed for developers has decreased
and impressive enough the salaries have grown as in any other industry.

Besides that, there are some key ideas that are also known but are worth the rerun:

• No services should share its database with any other system-level or systems
• Refactoring is a continuous activity
• Monoliths are not big ball of mud

The number of Microservices should be determined by business purpose and technical justification.

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture - Vaughn Vernon and Tomasz Jaskula

Towards the end of the book comes the discussion around added complexity that arises from microservices (even though in some contexts they are desired), the network should be taken into account and it is not reliable. Besides that, some
patterns were born to deal with such scenario:

• Failure supervision
• Circuit breakers
• Retries with capped exponential backoff
• Idempotent receivers
• Out-of-sequence message deliveries

And of course, remember that what is in production still needs to be maintained, in that sense, the authors provide a step list with what should be the approach to be taken:

• Step 1. Identify all business capabilities that exist in the Big Ball of Mud.
• Step 2. Rank business capabilities according to strategic significance: core competitive advantage > supporting functionality > generic operations that could be replaced by third-party solutions.
• Step 3. Gather an inventory of the business rules and functionality that are still relevant and now irrelevant.
• Step 4. Decide which business capabilities will be extracted in priority order
• Step 5. Plan how the first of the business capabilities will be extracted.
• Step 6. Work iteratively and deliver incrementally on steps 1–5.

Another aspect is the data synchronization that has to happen when the strategy is set.

Note It might seem better to refer to “harmonizing” as “synchronizing”, because what is described here is a sort of synchronization. Yet, the data will no doubt take a different shape and possibly change its meaning between the legacy system and the new Microservices.