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

Is organizational unpreparedness a dark matter force?

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 © 2023 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.

Chris helps clients around the world adopt the microservice architecture through consulting engagements, and training workshops.

PREMIUM CONTENT

Premium content and office hours is now available for paid subscribers at premium.microservices.io.

MICROSERVICES WORKSHOPS

Chris teaches comprehensive workshops for architects and developers that will enable your organization use microservices effectively.

Avoid the pitfalls of adopting microservices and learn essential topics, such as service decomposition and design and how to refactor a monolith to microservices.

Learn more

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

Remote consulting session

Got a specific microservice architecture-related question? For example:

  • Wondering whether your organization should adopt microservices?
  • Want to know how to migrate your monolith to microservices?
  • Facing a tricky microservice architecture design problem?

Consider signing up for a two hour, highly focussed, consulting session.

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 RESVJCMC to sign up for $95 (valid until September 26th, 2023). 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.

ASSESS your architecture

Assess your application's microservice architecture and identify what needs to be improved.

Consulting services

Engage Chris to conduct an architectural assessment.



Join the microservices google group

Topics

Note: tagging is work-in-process

Microservices adoption   ·  ancient lore   ·  anti-patterns   ·  application api   ·  application architecture   ·  architecting   ·  architecture   ·  architecture documentation   ·  assemblage   ·  beer   ·  containers   ·  dark energy and dark matter   ·  deployment   ·  design-time coupling   ·  developer experience   ·  development   ·  devops   ·  docker   ·  eventuate platform   ·  glossary   ·  hexagonal architecture   ·  implementing commands   ·  implementing queries   ·  inter-service communication   ·  kubernetes   ·  loose coupling   ·  microservice architecture   ·  microservice chassis   ·  microservices adoption   ·  microservicesio updates   ·  modular monolith   ·  multi-architecture docker images   ·  observability   ·  pattern   ·  refactoring to microservices   ·  resilience   ·  sagas   ·  security   ·  service api   ·  service architecture   ·  service collaboration   ·  service design   ·  service discovery   ·  service granularity   ·  service template   ·  software delivery metrics   ·  success triangle   ·  tacos   ·  team topologies   ·  transaction management   ·  transactional messaging

All content


Posts

24 Jul 2017 » Revised data patterns