Our thirty-fifth issue of the Architects' Newsletter continues to focus on the topic of "Return of the monolith? The rise and fall of microservices". In the early 2010s, the microservices-based architecture began to rise in prominence. However, now in the early 2020s, we are starting to see push-back against this approach, and there is a growing interest in well-architected (modular) monoliths.

Although there is consensus across the industry that there is no single "best" architecture, at InfoQ we believe that discussing and analyzing various architecture styles is vitally important. The InfoQ team recently published our latest Architecture and Design InfoQ Trends Report (April 2020), and the topics of microservices, correctly built distributed systems, and modular monoliths are well represented.

News

Podcast Tour with Sam Newman: Monolith to Microservices and Back Again

In a recent InfoQ podcast, Wes Reisz talked with Sam Newman, author of Building Microservices. Topics covered in the podcast include understanding the problem you're trying to solve, organizational and people changes when it comes to microservice architectures, and why we're seeing projects reverting from microservices to monoliths.

In a recent Ambassador Labs podcast, Newman discussed the concept of microservice ownership, explored how to best approach the local development of a microservice-based system, and shared his opinions on the release trains model of deployment. On the Confluent podcast, he walked through database decomposition, integrating with new technology, and performing joins in event streaming architecture.

Shapeways Monolith to Microservice Series

Matt Boyle, VP Architecture at Shapeways, has written a seven-part Monolith to Microservice Series. The content of the series is wide-reaching, and explores everything from the motivations to move to microservices, how to identify a candidate "first service", and migration patterns using a service mesh.

A key theme throughout the discussion is development velocity: "While microservices themselves don't necessarily increase velocity, as a matter of fact, they can definitely improve it in specific situations".

The Benefits and Challenges of a Modular Monolith

The JRebel team has explored several of the benefits and challenges with creating a modular monolith and compared modular monoliths versus microservices and traditional monolithic applications. This is a topic that Simon Brown has been discussing for several years, and he has also recently highlighted this influential 2019 blog post from the Shopify team - "Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity".

The JRebel team argues that employing modularization best practices can help achieve some of the benefits of microservices without the associated cost of refactoring. However, they also offer words of caution; "modular monoliths have significant shortcomings when compared to microservices - especially in terms of continuous testing, integration, and deployment".

Apollo Data Graph Platform: GraphQL Middleware Layer

In a recent InfoQ podcast, Matt DeBergalis, founder and CTO at Apollo, discussed the motivations for GraphQL and the Apollo Data Graph platform. Key topics explored included data modeling in an enterprise context, and how incrementally adopting GraphQL can help with decoupling the evolution of frontend and backend systems, whether the systems are composed of a monolithic architecture or a microservices-based system.

Case Study

Decomposing a Monolith Does Not Require Microservices

"The monolith is not the enemy" and "microservices should not be the default choice" were two of the points Sam Newman made during his presentation on Monolith Decomposition Patterns at QCon London 2020.

Highlighting some of the topics in his recently published book, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith, Newman advised engineers to focus on the outcome, not the technology, and to always remember the goal of microservices is independent deployability. To achieve that goal, take an incremental approach to decomposition, and do not start by thinking the monolith is the enemy.

Ask yourself, "What problems am I trying to solve? And what does my current architecture not let me do?" Techniques from Domain-Driven Design, such as a modeling exercise on the existing monolithic architecture, can help find the service boundaries and break up the big box.

Newman said the term "monolith" has become a replacement for the name "legacy". He believes this is deeply inappropriate. Rather, a monolith refers to the unit of deployment. He pointed out that the "modular monolith" is using cutting edge ideas from the 1970s, like structured programming. While it takes good discipline to respect module boundaries and avoid a "big ball of mud", most companies would do better with the highly underrated option of a modular monolith than with microservices. Good module boundaries "can make it easy for different teams to work together, and approach and address different aspects of the system".

Newman cautioned strongly against "the worst of the monoliths, the distributed monolith". A distributed monolith has many services, but everything has to be deployed at the same time and requires lots of coordination between teams to get anything done. One indicator that you have a distributed monolith is if someone in your organization has a full-time job as a "release coordination manager". For an example of how the BBC re-architected a distributed monolith, watch the QCon presentation by Blanca Garcia Gil.

Newman's main takeaway was "Microservices should not be a default choice. You've got to think really carefully about if they're right for you".

This case study is an excerpt from a full-length news item, written by InfoQ editor Thomas Betts, titled "Decomposing a Monolith Does Not Require Microservices - Sam Newman at QCon London".

To get notifications when InfoQ publishes content on these topics, follow " architecture" and "microservices" and "modular monolith" on InfoQ.

Missed a newsletter? You can find all of the previous issues on InfoQ.

This edition of The Software Architects' Newsletter is brought to you by:

Microservices and the Role of the Enterprise Architect

Most cloud-native architectures use microservices; hopefully, to safely remove dependencies that can deadlock each team’s progress as they wait for a service to update. At scale, it’s worth defining how microservices work, as well, for example: are they event based, how is data passed between different services, how should service failure be handled, and how are services versioned? Again, a senate of product teams can work at a small scale, but not on the galactic scale. EAs clearly have a role in establishing the guidance for how microservices are done and what type of policy is followed.

InfoQ strives to facilitate the spread of knowledge and innovation within this space, and in this newsletter we aim to curate and summarise key learnings from news items, articles and presentations created by industry peers, both on InfoQ and across the web. We aim to keep readers informed and educated about emerging trends, peer-validated early adoption of technologies, and architectural best practices, and are always keen to receive feedback from our readers. We hope you find it useful, but if not you can unsubscribe using the link below.

Forwarded email? Subscribe and get your own copy.