Microservice Architecture
Supported by KongWhy 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:
- The rapid flow of small changes from developers to production and end users
- 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.
- 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
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.
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 moreLEARN 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 MECNPWNR to sign up for $120 (valid until May 16th, 2023). There are deeper discounts for buying multiple seats.
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.
BUILD microservices
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
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 · assemblage · beer · containers · dark energy and dark matter · deployment · design-time coupling · 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 · 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 · tacos · team topologies · transaction management · transactional messaging
