Our thirty-third issue of the Architects' Newsletter focuses on the topic of "Return of the monolith? The rise and fall of microservices". This title is slightly tongue-in-cheek, but it alludes to the industry's somewhat fad-driven desire to select the "best" architecture patterns. 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.

We believe these topics are vitally important. As best said by Martin Fowler et al, "Architecture is the stuff that's hard to change later. And there should be as little of that stuff as possible". The InfoQ team is working on our latest Architecture and Design InfoQ Trends Report (to be published soon), and the topics of microservices, distributed systems, and modularization are well represented.

News

Monolith to Microservices: Migrating Snap's Architecture Using a Service Mesh

Snap's two-year evolutionary architectural shift from monolith to cloud-hosted microservices has led to a 65% reduction in computing costs along with reduced redundancy and increased reliability for customers, all of this while maintaining security and privacy compliance. Snap found that service-oriented architecture enabled scalability and ownership for engineers.

Open source edge proxy Envoy is the core building block, creating a consistent layer for inter-service communication. An internal web app, Switchboard, constitutes the control plane for Snap's service mesh, which provides one location for service owners to manage their service dependencies.

Building a Serverless Web App: Why You Should Consider the Monolith

In a recent Medium post, Ashan Fernando, software architect at 99X Technology, argues that although it is possible to build full-stack "serverless" web apps with cloud-native technologies using the microservices pattern, for many instances this becomes "overkill". The fastest way to develop the application is by using the "serverless monolith" approach. In AWS, for example, engineers can build a serverless monolith by using a single AWS Lambda function for the backend. This blog post provides a tutorial for how to do just that.

What Comes after Microservices? Multi-Runtime Microservices with Bilgin Ibryam at QCon London

Bilgin Ibryam talked at QCon London about the evolution of distributed systems on Kubernetes and the future architecture trends. Ibryam said that the next trend would be to decouple infrastructure concerns from microservices. Ibryam calls this multi-runtime microservices, a service with business logic along with a sidecar in charge of state management, networking, binding, and lifecycle.

Ibryam has recently written a full-length article on InfoQ that provides a deep-dive into this new "mecha-service" pattern.

The Future of Cloud Native API Gateways

In this recently published QCon London talk recording, Richard Li spoke about the evolution of API gateways over the past ten years, and how the original problems being solved have shifted in relation to architectural styles (monolith to microservices to functions), cloud-native technologies and workflow. He talked about several challenges of using API gateways in the cloud with Kubernetes, and presented strategies for exposing Kubernetes services and APIs at the edge of a system.

The AKF Availability Cube: Eliminate Deep Chains of Services

In a recent AKF Partners blog post, Marty Abbot introduces The AKF Availability Cube, a model to guide discussions on how to achieve high availability within modern software systems, as well as a tool to evaluate the theoretical "as designed" availability of existing systems. Core advice includes: duplicate everything; eliminate the multiplicative effect of failure in "deep" or "broad" (micro)service call chains; fault isolate customer segments.

Case Study

Design and Implementation of a DDD-Based Modular Monolith

Kamil Grzybek recently updated a project on GitHub where he has designed, implemented, and described in detail a monolithic application with a Domain-Driven Design (DDD) approach. His goal with the project is to show how a monolithic application can be designed and implemented in a modular way. He has also discussed several architectural considerations and design patterns he has found useful in the application.

Grzybek, architect and team leader at ITSG Global in Warsaw, points out that the intent is not to create an oversimplified application or a proof of concept (PoC); he instead describes it as a full implementation that is ready to run in production. His motivation for the project came from having looked for something similar, but without success. For him, most sample applications are too simple or incomplete. Often, he also thinks they are, at least in some parts, poorly designed or implemented, or lack documentation.

Grzybek emphasizes that his implementation is just one of many ways to solve the same business problems. The software architecture of a system should be based on a number of factors, such as functional requirements, quality attributes, and technical constraints, but also influenced by developer's experience, technical constraints, time and budget, and so forth, and all this affects the solution.

The target for his application is the meeting groups domain, which he thinks is a domain most developers can reason about. It also has some complexity which makes it more interesting than a trivial CRUD-based application. He has then divided the main domain into four subdomains: meetings, payments, administration, and finally, user access.

To find the functionality needed in the domain, Grzybek refers to Event Storming, an approach to exploring complex business domains created by Alberto Brandolini, which he has used to find the behavior and the events in the different subdomains within the main meetings domain.

Grzybek has emphasized that the project is still under development and therefore he welcomes contributions. The application is a .NET Core application written in C# and uses libraries like Autofac (for IoC) and Dapper (a micro ORM used for read models). The project includes tests based on the Arrange - Act - Assert pattern, implemented using NUnit.

This case study is a summary of the full-length article, including a Q&A interview with Kamil Grzybek, that can be found on InfoQ: "Design and Implementation of a DDD-Based Modular Monolith".

To get notifications when InfoQ publishes content on these topics, follow " architecture" and "microservices" 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:

Discover new ways to improve the whole software delivery system

What new ways of working that generate high value should you implement next? Learn this and more from your peers at QCon San Francisco (Nov 16-20, 2020). Connect and learn from innovative leaders that have made an impact on their teams and businesses.

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.