Many teams are moving inexorably away from monolithic software. While the phrase “monolith” has taken on a negative connotation, there’s nothing inherently wrong with monolithic software. The word describes a codebase that is self-contained and mostly independent.

Increasingly, we use the word monolith or legacy to mean a Big Ball of Mud, a codebase that is difficult to change, it’s capabilities are set in stone. The popular solution is application modernization, which usually involves microservices.

If circumstances haven’t changed much, legacy software doesn’t necessarily need modernization. When it does, organizations sometimes imagine a Big Lift and Shift Transformation. But that’s not how modernization works.

Moving from monolith to microservices (smaller, containerized applications) is an incremental decoupling of capabilities. Most of the time, microservices are brought online in relationship to the current (monolithic) software. Microservices are self-contained and independent, like monolithic software, but unlike monoliths, they depend on well-designed relationships with other software. Relationships replace the capabilities that were previously housed wholly inside the monolith.

Microservices are easier to change and evolve … unless they are tightly coupled. In a monolith, information is always available to all the code. Microservices have access to only the information they need, only when they need it. Redesigning the structure and flow of data is critical to loose coupling. When we modernize, we rearchitect space and time in our system.

The most difficult aspect of architecting microservices isn’t Kafka, Kubernetes, Docker or learning GoLang. (Though those skills are challenging!) The most difficult part is changing the way teams, and the organization, think about software. Teams need to adapt to new patterns and surrender those that don’t fit the new paradigm. For example, teams unwilling to let go of database transactions (as essential) will create very complicated microservices implementations.

Microservices rely on pattern thinking. Which often means transforming a linear software delivery approach into an adaptive, learning-driven approach. Otherwise, teams can’t help but build a Distributed Monolith In the Cloud.

How do we reconsider and adopt the patterns, in the technology and in the people, that support microservices? What guides our decision making? Where do we begin?

Here are some resources for diving into these questions. They’ll help us explore the patterns, perils and pitfalls while developing the thinking skills needed.

Microservices Patterns

by Chris Richardson

A comprehensive overview of the challenges teams face when moving to microservices, with industry-tested solutions to these problems.

Monolith to Microservices

by Sam Newman

This practical guide, with many insightful patterns, is a companion to  Building Microservices .

Architektur-Migration (nicht nur) zu Microservices (German)

by Eberhard Wolff

The architectures of many systems are suboptimal. Eberhard advises teams moving from monolith to microservices. In this episode, we discuss the typical procedure for such migrations and the challenges that arise. (In German)

Seven Ways to Fail at Microservices

hosted by Thomas Betts

Implementing microservices is really challenging and there are many ways to fail. Holly Cummins has identified seven ways to fail at microservices. Thomas Betts asks her to describe them and how they can be avoided.

Microservices with Node JS and React

taught by Stephen Grider

This comprehensive course includes building with high-value technology tools. It goes deeper than most courses into the more challenging aspects.

Just remember: there is no such thing as a microservice. The microservice architecture is an architectural style that structures an application (a.k.a. system) as a set of loosely coupled services.

― Chris Richardson

You Might Enjoy …

Writing as Thinking

and learning and leading

January 19 – March 16, 2023

Thursdays for one hour
at Noon ET, 5pm GMT, 6pm CET, 9am PT

Writing as Thinking is an eight-week course for technologists — introducing writing practices for thinking, learning and leading.

Well-reasoned writing transforms disparate thoughts into meaningful action. In this course, you’ll practice writing in ways that help you:

cultivate self awareness
strengthen your recommendations
learn from other people’s expertise
effectively lead knowledge work

Learn more about this course.

The course fee is $499.
The initial (beta) course is on sale for $249. 

Contact Mentrix

Get Updates

From Software to Systems


Enjoy luxury, exclusivity and discretion


Get 25% Off & Free Shipping On Your First Order. Enter Code WELL25SPE