The Software Architects' Newsletter
December 2020
View in browser

In our forty-first issue of the Architects' Newsletter, we are taking a break from our regularly scheduled program to bring you a 2020 year-in-review edition of the newsletter. In the list of highlights below, we have chosen a combination of our favorite content, and also the most popular articles with readers, as well as some new content items that build on the themes we’ve covered over the last year.


Principles for Microservice Design: Think IDEALS, Rather than SOLID

In this recent popular InfoQ article "Principles for Microservice Design: Think IDEALS, Rather than SOLID", Paulo Merson, a developer at the Brazilian Federal Court of Accounts and visiting scientist with the SEI, presented a new design model for microservices. He proposed that developers follow the "IDEALS": interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility.

In regard to event-driven architectures, he argued that an important benefit is improved scalability and throughput. This benefit stems from the fact that message senders aren't blocked waiting for a response, and the same message/event can be consumed in parallel by multiple receivers in a publish-subscribe fashion.

Modular Monolithic Architecture, Microservices, and Architectural Drivers

From observing what is currently happening within the software development community, Kamil Grzybek concludes in a recent article that most new projects are implemented using the microservices architecture.

He believes that the IT industry at large is making a mistake adopting microservices just because they believe this will solve all of the problems with monolithic applications. Instead, Grzybek recommends we focus on architectural drivers, and emphasizes that every architecture has its pros and cons—it will solve some problems but also create new problems. In a series of articles, he describes the basic concepts and properties of a modular monolith and the drivers leading to a specific architecture.

Architectures That Scale Deep—Regaining Control in Deep Systems

In this QCon video, Ben Sigelman talks about "Deep Systems" and their common properties. He re-introduced the fundamentals of control theory from the 1960s and explored the original conceptualizations of observability and controllability. Sigelman used examples from Google and other organizations to illustrate how microservices and other deep systems have damaged engineers' ability to observe software and provides a series of strategies that can be used to regain control.

This topic was also explored by Michelle Krejci in an InfoQ podcast, "Moving to Microservices: Visualizing Technical Debt, Kubernetes, and GraphQL".

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.

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.

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.

LaunchDarkly's Evolution from Polling to Streaming

In a recent article, Dawn Parzych, developer advocate at LaunchDarkly, discussed how the organization has evolved its customer-facing feature flag evaluation system from a polling-driven architecture to one based on streaming.

The benefits to their end-users included the increased speed of configuration changes — "customers today see rapid updates when flags change with significantly less bandwidth consumption" — and also included other advantages — "the batteries on the mobile devices are extended as they no longer have to spend battery power on polling".

Running React Applications at the Edge with Cloudflare Workers—Q&A with Josh Larson

Josh Larson recently released Flareact, an edge-rendered React framework built for Cloudflare Workers. Flareact is inspired by Next.js, a React framework that features hybrid static and server rendering. While Next.js optimizes React applications for production deployments, (e.g. pre-rendering, optimized pre-fetching, automatic code-splitting), Cloudflare Workers allows running code on the edge quickly, efficiently, and at scale.

Flareact seeks to replicate the advantages brought about by Next while adding the benefits of edge-side rendering and caching. Flareact currently supports file-based page routing, dynamic page paths, API routes, cache policy configuration, and edge-side data-fetching APIs.

Mock Service Worker Library Enables Resilient REST and GraphQL API Testing

The Mock Service Worker (MSW) API mocking library allows developers to test web applications without using an actual back-end, setting up a mocking server, or stubbing native http/https/fetch implementations. MSW mocks both Rest and GraphQL APIs. MSW received the JavaScript Open Source Awards this year.


InfoQ's Favorite Case Study

Zhamak Dehghani on Data Mesh, Domain-Oriented Data, and Building Data Platforms

In an InfoQ podcast, Daniel Bryant sat down with Zhamak Dehghani, principal consultant, member of the technical advisory board, and portfolio director at ThoughtWorks. Topics discussed included: the motivations for becoming a data-driven organization; the challenges of adapting legacy data platforms and ETL jobs; and how to design and build the next generation of data platforms using ideas from domain-driven design and product thinking, and modern platform principles such as self-service workflows.

Dehghani began by stating that becoming a data-driven organization remains one of the top strategic goals of many organizations. Being able to rapidly run experiments and efficiently analyze the resulting data can provide a competitive advantage.

There are several "architecture failure modes" within existing enterprise data platforms. They are centralized and monolithic. The composition of data pipelines is often highly-coupled, meaning that a change to the data format will require a cascade of changes throughout the pipeline. And finally, the ownership of data platforms is often siloed and hyper-specialized.

The next generation of enterprise data platform architecture requires a paradigm shift towards ubiquitous data with a distributed data mesh, Dehghani believes. Instead of flowing the data from domains into a centrally owned data lake or platform, domains need to host and serve their domain datasets in an easily consumable way.

Domain data teams must apply product thinking to the datasets that they provide; considering their data assets as their products, and the rest of the organization’s data scientists, ML, and data engineers as their customers.

The complete podcast and show notes can be found on InfoQ: "Zhamak Dehghani on Data Mesh, Domain-Oriented Data, and Building Data Platforms". An article that dives deeper into the topic can also be found on InfoQ, "The Distributed Data Mesh as a Solution to Centralized Data Monoliths".

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:


Data Plane Matters! A Deep Dive and Demo on NGINX Service Mesh

Watch this webinar and discover the service mesh basics! Learn why and when you need a service mesh...and why and when you may not. Watch on Demand.


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.