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 [1].

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 [2], 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

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:

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.

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”.

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.

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:

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:

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:

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:

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:

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.

References

  1. [1]N. C. Mendonça, C. Box, C. Manolache, and L. Ryan, “The Monolith Strikes Back: Why Istio Migrated From Microservices to a Monolithic Architecture,” IEEE Software, vol. 38, no. 5, pp. 17–22, 2021, doi: 10.1109/MS.2021.3080335.
  2. [2]T. Jaskula and V. Vernon, Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture. Addison-Wesley Professional, 2021.