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

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.



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.

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.

New 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 JUNVCEJE to sign up for $195 (valid until February 1st, 2023). There are deeper discounts for buying multiple seats.

Learn more

Signup for the newsletter


LEARN about microservices

Chris offers numerous resources for learning the microservice architecture.

Training classes

Chris teaches comprehensive workshops, training classes and bootcamps for executives, architects and developers to help 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.

Delivered in-person and remotely.


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

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

anti-patterns   ·  application api   ·  application architecture   ·  architecting   ·  architecture documentation   ·  dark energy and dark matter   ·  deployment   ·  development   ·  devops   ·  docker   ·  implementing commands   ·  implementing queries   ·  inter-service communication   ·  loose coupling   ·  microservice architecture   ·  microservice chassis   ·  microservices adoption   ·  microservicesio updates   ·  multi-architecture docker images   ·  observability   ·  pattern   ·  refactoring to microservices   ·  resilience   ·  sagas   ·  security   ·  service api   ·  service collaboration   ·  service design   ·  service discovery   ·  service granularity   ·  service template   ·  software delivery metrics   ·  success triangle   ·  team topologies   ·  transaction management   ·  transactional messaging

All content


Posts

24 Jul 2017 » Revised data patterns