The evolution of the success triangle: microservices as the enabler of DevOps and team topologies

architecting   success triangle   devops   team topologies  

In my 2018 book Microservices Patterns I described the success triangle. It shows the relationship between the three ingredients necessary for the rapid, frequent and reliable delivery of software.

As I wrote in the book:

For a large, complex application, the microservice architecture is usually the best choice. But in addition to having the right architecture, successful software development requires you to also have organization and development and delivery processes.

The delivery process is DevOps, which I define below. The organization structure is a loosely coupled network of small product teams. Six years later the success triangle is still very relevant. It’s a great way to introduce the motivations behind microservices.

In this article, I describe the evolution the success triangle and explain why the primary goal of using the microservice architecture is to enable DevOps and team topologies. I also briefly cover how to decide between the monolithic architecture and the microservice architecture for your application.

Software is eating the VUCA world

One early enhancements to the success triangle was to include the two key trends that are driving the adoption of microservices. Here’s the success triangle from my recent ExploreDDD 2024 presentation:

It shows the trends: software is eating the world; and increasing volatility, uncertainty, complexity and ambiguity (VUCA). Let’s look at each one in turn stating with software is eating the world.

Trend #1: Software is eating the world

The first trend, which is quite old, is the increasingly important role that software plays in the delivery of an enterprise’s products and services. This trend is captured by the phrase “software is eating the world”, which was coined by Mark Andreessen in 2011. It doesn’t matter what industry you’re in, software is important. The Southwest Airlines meltdown during Christmas 2022 is a great example of the importance of software.

Trend #2: increasing volatility, uncertainty, complexity and ambiguity (VUCA)

The second trend is the increasing volatility, uncertainty, complexity and ambiguity (VUCA) of the business environment in particular, and the world in general. I used to introduce VUCA by talking about how, for example, changes to regulations meant that ancient banks suddenly needed to compete with fintech startups. But then the COVID pandemic happened. Not only was there terrible loss of life, but the pandemic also disrupted businesses and IT in ways that no one could have predicted. And, today other examples of VUCA include on-going wars and impact of climate change.

IT needs to deliver those applications rapidly, frequently and reliably

A business must be much more nimble in order to thrive in today’s VUCA world. And since IT is responsible for the applications that power the business, it needs to deliver those applications much more rapidly, frequently and reliably.

Team topologies and the DevOps handbook

Another enhancement to the success triangle was to include two books: the DevOps Handbook and Team Topologies. Team Topologies is a great addition to the success triangle since it describes an organizational structure (aka. topology) that organizes people into teams that can deliver software quickly and reliably.

Also, to avoid any confusion about the term DevOps, I included the DevOps Handbook. Unfortunately, DevOps is frequently misinterpreted as merely a set of tools or a job title. The DevOps Handbook, however, describe how it’s a set of principles and practices that are essential for rapid and reliable software delivery.

Architecture as the enabler of DevOps and team topologies

Initially, I merely characterized DevOps and Team Topologies as necessary components in the adoption of microservices. But at some point, a major shift occurred in how I thought about the relationship between process, organization and architecture. I started to see DevOps and team topologies as the goal and architecture as an enabler. In other words, embracing only DevOps and Team Topologies is not enough. Your application’s architecture must also support DevOps and Team Topologies.

Architectural requirements for DevOps and Team topologies

DevOps and Team topologies require an architecture with the following characteristics:

  • loosely (design-time) coupled - a fundamental property of good software. In particular, the ‘modules’ owned by different teams should be loosely coupled in order to minimize the need for coordination between teams.
  • testable - fast running automated tests that can be run locally and a fast deployment pipeline.
  • deployable - fast reliable, automated deployments in order to prevent the final step of the delivery pipeline from becoming a bottleneck.
  • observable - the production environment must emit a stream of telemetry - logs, metrics, traces - so that developers can understand both application and user behavior

An organization that wants to use DevOps and Team Topologies picks an architecture that has these characteristics. For some applications, that architecture can be a (modular) monolith and for others it can be microservices.

Designing an architecture that supports DevOps and Team Topologies

The first step in designing an architecture is to decide between the monolithic architecture and the microservice architecture. The dark energy forces are a useful framework for making this decision. For example, see this slide from a recent presentation that describes how your context determines the relevant dark energy forces to your application. The strength of these forces determines which architecture is the best choice.

Designing a monolithic architecture

If you choose to use a monolithic architecture, it’s usually best to design a modular monolith. When designing a monolith, it’s important to ensure that its modules are loosely coupled from both a design-time and build-time perspective.

Loose design time coupling improves developer productivity by ensuring that changes to one module don’t require changes to other modules. Loose build-time coupling accelerates the deployment pipeline by ensuring that changes to one module don’t require other modules to be built and tests.

Designing a microservice architecture

If you choose to use the microservice architecture, you must design the service architecture. The Assemblage design process is a great way to design a service architecture. It uses the dark energy and dark matter forces to shape the service architecture.

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help


architecting   success triangle   devops   team topologies  


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.

Upcoming public workshops: Microservices and architecting for fast flow

In-person: Berlin and Milan

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 one of my upcoming public workshops in November.

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 CCMHVSFB to sign up for $95 (valid until November 8th, 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