Our thirty-fourth 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

Marty Abbott and Tanya Cordrey on Microservices, Availability, and Managing Risk

In this podcast, Marty Abbott and Tanya Cordrey from AKF Partners (creators of The AKF Scale Cube) sat down with InfoQ podcast co-host Daniel Bryant and discussed a range of topics related to architecture choice and the corresponding impact on an organization.

A key takeaway was that the microservice architectural pattern is best used for implementing the "breadth" of business functionality. Engineers should avoid building deep call chains of services, as this can increase the probability of failure, and can also increase the challenges of locating and diagnosing issues. Code libraries can often be used more effectively to implement "depth" within services.

Taming the Growth of Microservices

This video of Tobias Kunze's QCon San Francisco 2019 talk "Controlled Chaos: Taming Organic, Federated Growth of Microservices" focused on the challenges that result from "organic growth" of a system. He discussed patterns that can be applied to monitor and control these dynamic systems, like bulkheads, backpressure, and quarantines, from both an operational and security perspective.

A key takeaway was that developers should avoid building highly-coupled distributed systems. Instead, they should build "resilient federations" based on standard domain-driven design (DDD) federations of services. Developers should invest heavily in compensation strategies in code; "if something doesn't work quite right, make it so that the service degrades instead of failing".

QCon Panel: Microservices - Are They Still Worth It?

This panel presentation, which debates the value of microservice, was filmed at QCon London 2020 in the "Next Generation Microservices: Building Distributed Systems the Right Way" track. The panel was hosted by Nicky Wrightson, Principal Engineer at Skyscanner, and featured panelists that have moved from the monolith to microservices and in some cases back again.

The participants demonstrated strong opinions on monorepos, the challenges of operating distributed systems, and on the best way to structure an organization in order to successfully implement this architecture. A complete text transcript of the discussion is also provided.

Taking Microservice Conversations to the Next Level

In this recent The New Stack article, Eran Levy summarized some of the recent community discussions about microservice vs monoliths. Levy focused on four topics: the cost - is an organization really ready to invest in the changes and learning required; service structure - the need to design systems based on foundational software architecture principles; implementation retrospectives - identify pain points; and supporting (long - term) engineering decisions.

Levy concluded the article by stating that in order for progress to be made in building effective software systems within the larger industry context, it is important that the conversations focusing on architecture also show what didn't work in addition to highlighting the benefits.

Case Study

To Microservices and Back Again - Why Segment Went Back to a Monolith

While almost every engineering team has considered moving to microservices at some point, the advantages they bring comes with serious trade-offs. At QCon London, Alexandra Noonan told how Segment broke up their monolith into microservices, then, a few years later, went back to a monolithic architecture. In Noonan's words, "If microservices are implemented incorrectly or used as a band-aid without addressing some of the root flaws in your system, you'll be unable to do new product development because you're drowning in the complexity".

Microservices were first introduced to address the limited fault isolation of Segment's monolith. However, as the company became more successful, and integrated with more external services, the operational overhead of supporting microservices became too much to bear. The decision to move back to a monolith came with a new architecture that considered the pain points around scaling related to company growth. While making sacrifices in modularity, environmental isolation, and visibility, the monolith addressed the major issue of operational overhead and allowed the engineering team to get back to new feature development.

Noonan explained several key points in the evolution of Segment's architecture. The problems faced, and the decisions made at the time sounded familiar to any experienced software engineer. Only with the advantage of hindsight is it clear which decisions could have been better. Noonan explained each major decision point on a timeline and noted the pros and cons of each state of the system architecture.

QCon attendees discussing the presentation sounded like typical engineers joining a project with a long history. Quick remarks such as, "Well, obviously you shouldn't do what they did", were countered with voices of experience pointing out that most decisions are made based on the best information available at the time. One of the key takeaways was that spending a few days or weeks to do more analysis could avoid a situation that takes years to correct.

This case study is an excerpt of a full-length news item, written by InfoQ editor Thomas Betts, titled "To Microservices and Back Again - Why Segment Went Back to a 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:

Microservices: A Special Case for Choosing Initial Projects

A special case for initial projects is picking a microservice to deploy. Usually, such a service is a critical backend service for another application. A service that’s taken forever to actually deliver or has been unchanged and ancient for years is an impactful choice. This is not as perfect a use case as a full-on, human-facing project, but it will allow you to test out cloud-native principals and rack up a success to build momentum. The microservice could be something like a fraud detection or address canonicalization service. Citi, for example, chose a payment validation service as one of its initial projects: the perfect mix of size and business value to begin with.

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.