Is organizational unpreparedness a dark matter force?

microservice architecture   architecting   dark energy and dark matter   Microservices adoption   anti-patterns  

New public workshop: Architecting for fast, sustainable flow - enabling DevOps and Team Topologies thru architecture. Learn more and enroll.


These days I write and talk a lot about the dark energy and matter forces and how they shape a microservice architecture. The dark energy forces encourage decomposition whereas the dark matter forces resist decomposition. The five dark matter forces are technical in nature and include Prefer ACID over BASE and Minimize runtime coupling. However, based on how many organizations struggle to adopt microservices, I’m wondering whether there is a sixth dark matter force: Organizational Unpreparedness. In other words, if an organization is not willing or able to use the microservice architecture properly, it might be better off sticking with the monolithic architecture.

There are several obstacles that an organization must overcome to successfully adopt microservices:

  • Microservices require rigorous design skills
  • Adopting microservices requires a learning culture
  • Microservices require the rest of the success triangle

Let’s look at each one in turn.

Microservices require rigorous design skills

Software design is difficult. It’s something that many developers struggle with. Unfortunately, the microservice architecture requires rigorous design skills. And to make matters worse, it’s much less forgiving of bad design decisions than a monolith architecture.

For example, the consequences of two tightly design-time coupled packages in a monolith is not as severe as two tightly coupled microservices. A monolith has a single code base and so changing two packages simultaneously is relatively easy. It’s a single commit. But in a microservice architecture, each service has multiple code base and is deployed independently. Consequently, changing two microservices is much more difficult and expensive. You often have to evolve APIs and carefully coordinate the release of changes.

To avoid poor design, a microservice architecture requires a much higher level of rigor than a monolith architecture. An organization that wants to adopt microservice architecture must be prepared to honestly assess its developers’ design skills. And, if they are lacking, be prepared to invest in training and mentoring.

Adopting microservices requires a learning culture

Adopting microservices is, by definition, doing something new. But to do something new, an organization needs to have a culture that embraces change and tolerates failure. Unfortunately, many organizations have a culture that is the opposite of this: a culture that is risk averse and intolerant of failure. Since it’s inevitable that mistakes will be made, such a culture can be a significant obstacle to adopting microservices.

The solution is, of course, for an organization to change its culture to a Westrum generative culture.

Microservices require the rest of the success triangle

The microservice architecture is 1/3rd of the success triangle. In order to benefit from the microservice architecture, you must almost always adopt the other two elements of the success triangle: DevOps as defined by the DevOps handbook; and an organization structure consisting of small, loosely coupled teams, as described by Team Topologies.

Unfortunately, many organizations struggle with adopting team topologies and DevOps, since they involves changing how people work. Adopting Team topologies requires an organization to break down traditional silos, which can be difficult. Organizations also struggle with DevOps for the same reasons that they struggle with Agile: a mismatch in culture; difficulty embracing empowerment and autonomy; and confusion about about what it actually is. For example, a common misconception is that DevOps is a role, when in fact it’s a set of principles and practices for delivering software rapidly, frequently, and reliably. It’s common for an organization to hire DevOps engineers who are responsible for infrastructure automation.

The solution, for course, is for an organization to commit to properly understanding and adopting DevOps and Team Topologies.

Summary

In order to use the microservice architecture properly an organization must be prepared to do the following:

  • Ensure through training and mentoring that its developers have rigorous software design skills
  • Have, or be willing to have, a generative culture that embraces change and tolerates failure.
  • Adopt the other 2/3rds of the success triangle - DevOps and Team Topologies - in order to benefit from microservices

If an organization is unwilling or unable to do these things, it might be better off sticking with the monolithic architecture.

What do you think?

I’m curious to hear what you think. Please let me know.

Need help migrating to microservices?

I’m available to help your organization adopt microservices. I provide consulting and workshops.


microservice architecture   architecting   dark energy and dark matter   Microservices adoption   anti-patterns  


Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About Microservices.io

Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.

New workshop: Architecting for fast, sustainable flow

Enabling DevOps and Team Topologies thru architecture

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for my June 2024 online workshops....

NEED HELP?

I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon GIVLKECM to sign up for $145 (valid until June 19th, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter


BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,


The Eventuate platform

Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.


Join the microservices google group