Why microservices - part 3: two thirds of the success triangle - process and organization

success triangle  

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

This is part 3 in a series of blog posts about why and when to use the microservice architecture. Other posts in the series are:

  • Part 1, the need to deliver software rapidly, frequently, and reliably
  • Part 2 - the need for sustainable development
  • Part 4 - the final third of the success triangle - architecture
  • Part 5 - the monolithic architecture

In this post, I describe the software development success triangle.

About the success triangle

In order to deliver software rapidly, frequently, reliably, and sustainably you need what I call the success triangle:

In other words, you need a combination of three things:

  • Development process - DevOps
  • Organizational structure - a network of loosely coupled, cross functional teams
  • Architecture - sometimes a monolith and sometimes the microservice architecture

Let’s look at each of the three elements of the success triangle starting with process.

The success triangle: Process = DevOps

The process part of the success triangle is DevOps. As the must read book DevOps Handbook describes, DevOps is a set of principles and practices where developers, testers, and operations collaborate and communicate to deliver software rapidly, frequently, and reliably.

The philosophy underlying DevOps consists of the three ways:

  1. The rapid flow of small changes from developers to production and end users
  2. The rapid flow of feedback from production and end users to developers. This includes both telemetry, such as metrics, from the production environment, and feedback from users.
  3. Continual learning and experimentation in order to improve how software is delivered and the software’s resilience.

A key part of DevOps is continuous delivery, which is ‘… is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way…’. Two of the key foundations of continuous delivery are continuous integration and automated testing. Software is built, tested and deployed by an automated deployment pipeline that is triggered by each commit.

Another key part of DevOps, which is inspired by Lean, is hypothesis driven development and A/B testing. Research shows that as many as two thirds of ideas have zero or negative value. Teams should, therefore, make product management decisions based on feedback from real customers rather than, for example, the HiPPO (highest paid person’s opinion). One reason IT performance correlates with business performance is because the lower your lead time and the higher your deployment frequency the faster you can experiment to find those features that increase revenue.

The success triangle: Organization = small, cross functional teams

Let’s now talk about the organization aspect of the success triangle. As the must read book Team Topologies describes, a high performance IT organization is a loosely coupled network of small, autonomous and empowered teams. Each team is relatively small, ideally five to nine people. That number is chosen because the research shows that small teams promote trust, which is essential for high productivity. Also, each team is long-lived because it takes time for a team to become highly effective.

Also, teams should be cross-functional (also a DevOps principle) because that eliminates time-consuming handoffs, which would otherwise occur between different cross-functional groups. For example, in a silo’d organization, developers hand code over to QA, who would then hand the code over to operations. In contrast, in a modern organization, each team should all of the skills to take a requirement and turn it in to deployed code. In some organizations, such as Amazon, each team also contains business people and effectively functions as a mini-startup.

Also, each team should own a suitably sized software component. That’s important for two reasons. First, code ownership promotes long-term sustainable software development. If the team owns the code, they’re strongly incented to keep it clean. What’s more, the components should be suitably sized. You should never overload a team with a code base that is far too large for them to manage.

What about architecture?

It’s essential to organize an IT organization as a loosely coupled network of small, autonomous and empowered DevOps teams. But, in order to be successful you also need the final third of the success triangle: architecture.

What’s next

The next post describes the architectural characteristics required to develop software rapidly, frequently, reliably, and sustainably.

success triangle  

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


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