Part IV: The Two Paths for Purposeful Architecture

Executive Summary

Here it is, the culmination of a trek to reach the pinnacle of purposeful architecture with well-designed contextual boundaries of expertise. There are two paths, Monoliths and Microservices. Both have purpose, yet the purpose of each does not fit with every system or subsystem situation. The two paths offered between the covers of this book are fitting for a given set of circumstances, and possibly a hybrid of both is appropriate. There is no shame in taking either path as long as the decision to take one over the other is backed by sound reasoning and intellectual honesty.

Chapter 10: Building Monoliths Like You Mean It

Building a Monolithic architecture should not feel like a third-class, cop-out choice—that is, not if you build a respectable, well-modularized Monolith in the way that the authors recommend. Building Monoliths as a first-class choice is the theme of Chapter 10. We’ll offer guidance that explains two ways to get there.

▪ Take a lesson in why Monoliths should be used under specific circumstances, and how to achieve the best results.

▪ Take a brief history lesson on how the industry reached the mess that it has found itself in. This historical perspective delivers a reliable background on why software went so wrong.

▪ Every system construction endeavor that does not need to use a Microservices architecture must set out on the path to create a well-modularized Monolith. This is not just an attainable goal, but the only way to avoid the tangled, muddy mess that is the inevitable destination of lesser efforts. The effort includes the proper reference to business capabilities and wise architecture decisions.

▪ When a Monolith has not been architected, designed, and implemented as a desirable, well-modularized Monolith, a course correction is difficult but not impossible. But how do teams deal with change that’s required to maintain the legacy system operational while simultaneously reworking the architecture?

▪ Either trek can be taken to achieve the best Monolithic architecture result, while keeping the sound software from gradually sliding into a pit of mud. Take advice on how to prevent the slowly creeping doom.

Chapter 11: Monolith to Microservices Like a Boss

Microservices are a suitable architectural decision, especially when certain contextual areas of expertise change more quickly than others. An added advantage of Microservices is that they are delivered as separate deployment units from all other subsystems. When Microservices are appropriately used, they can be a boon to autonomous development and delivery.

▪ Mental preparation is essential for every software development venture. Even so, we must be especially mentally prepared to take on the challenges of distributed systems architecture. It’s not an easy trek to deliver robust distributed systems, but that journey can be made simpler by the use of some techniques and tools that support the techniques.

▪ The straightforward way to get from a Monolith to Microservices is when the Monolith is well modularized. This might have been because the Monolith was architected properly from the start. Or, instead, it could be that a legacy Big Ball of Mud was heavily refactored to a modularized Monolith using the steps provided in Chapter 10. Either way, starting with a modular Monolith is the best way to get from legacy to Microservices.

▪ When dealing with a legacy Big Ball of Mud, taking the trek directly to a Microservices architecture will be the most challenging journey. Even so, it is possible to reach that destination by fully comprehending the ruggedness of the terrain. This requires extracting components from the legacy, and implies all of the same challenges as the journey of Big Ball of Mud to modular Monolith that were discussed in Chapter 10. Yet, this is more like attaching new train cars to a train as it is speeding ahead, and then disconnecting those cars one-by-one as self-powered vehicles that arrive at the destination with all others. All the while, the team is working on the top of the train, with individuals simultaneously leaping from car to car as necessary. What could possibly go wrong? The guidance in Chapter 11 offers safety harnesses to the team members and catwalks between cars.

▪ Decisions, decisions. At what point can the legacy Monolith be decommissioned? There are several different trade-offs involved, not the least of which might be expensive hardware and software support licensing that have locked in businesses for decades. Consider the positive and negative consequences.

Chapter 12: Require Balance, Demand Strategy

After an intense journey to reach solid, high ground with strategy digital transformation and event-first learning and purposeful architecture, making the best choices to use Monoliths and Microservices is possible. This chapter steps through a cooldown with reinforcing reminders to balance choices and remain bent on strategic innovation.

▪ Because software architecture is a multidimensional discipline, it calls for balance when choosing trade-offs between the competing forces of different non-functional requirements.

▪ Outstanding takeaway: Balance is unbiased. Innovation is essential. Demand strategy.

Companies without a software innovation strategy will eventually become obsolete. Don’t trade off the opportunity to turn a current core software system into the next generation of SaaS or PaaS in your industry. You now have incentive, inspiration, and tooling to start that journey, or to keep innovating along the path that has already begun.