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?)
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:
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".
Some keywords to go further on this sections:
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.
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:
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
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:
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!
Codurance Regional Director for UK North Simon Shaw has been confirmed as a committee member of techUK’s new Regions & Nations Council. The new..
As we wrap up January, it's exciting to reflect on the progress of our Software Crafters Manchester sessions this year. We've introduced..
Thank you to everyone who joined the Codurance team this week, to help launch our new office in Leeds. It was great to connect with people and feel..
Join our newsletter for expert tips and inspirational case studies
Join our newsletter for expert tips and inspirational case studies
