Book club at Codurance - Strategic monoliths and microservices

26 Jul 2022

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. Production ready microservices by Susan J. Fowler was one of the books that shared some learnings on standardising 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, the book Architectural Patterns by Mark Richards, where he lists different architectural styles including microservices.

Finally, here we are once again going 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 we did at the book club while reading the book and mix that with some of our thoughts and experience on the subject.

Note: Here we followed the author's book structure, starting from part I till part IV, each section is focused on specific aspects of the decision making process of monolith or microserives (both?)

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")
  • Domain Driven Design 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 Patterns of 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 I

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.

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 externalised is known as tacit knowledge.

When starting to read the book, much of the concerns were around the actual implementation and how real the proposed thinking could be applied in real world projects, fortunately the authors start to go deeper in part III and IV for that matter. This part depicted most of the pains and the reasons behind change in any organisation. Usually startups are the ones towards change often, 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.

Note: "status quo" is not necessarily "bad", businesses need to offer their services for the long term.

Some keywords to go further on this sections:

  • Inverse Conway's law
  • Bruce Tuckman on organisational behaviour
  • Cynefin framework
  • ADR's

 

Part II

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 glueing what was presented in the first part.

Besides that the critique on what agile became is something that made me realise that after 20 years of agile, most of the industry thinks that agile is SCRUM, this is also the author's interpretation in the section 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?

For the authors, knowledge should be the centre, in software we are learning all the time in order to do something for the business - agile cultivates that. 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.”

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, helps teams to understand better what each piece is doing. This is important as the authors say that to eliminate completely the giant system might never happen. When it does, the path to settle the system is long.

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

To help understand and organise 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 normalise 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.

  • Anticorruption 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


Some keywords to go further on this sections:

  • Bounded Context
  • Ubiquitous Language

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 Behaviour

 

Part III

Chapters 8 and 9

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]

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 favour of hexagonal architecture, in the book, they dive into what it is, and why to use such style. Alistair Cockburn recorded a three episode video (but in one talk) his thoughts to put in place this architecture style. 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

Chapters 10 through 12

The last part of the book focuses on different aspects of software architecture focused on how to deliver an 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.

We 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). 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.

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.

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

 

These were the highlights of our last Codurance Book Club meeting where we discussed the book Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture by Vaughn Vernon and Tomasz Jaskula. We hope these considerations have motivated you to learn more about monoliths and microservices and we encourage you to review this book to review and deepen concepts.

If you want to review more relevant content on different topics, here is a link to our Insights page.

See you next time!