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:
In this post, I describe the software development 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:
Let’s look at each of the three elements of the success triangle starting with process.
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:
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.
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.
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.
The next post describes the architectural characteristics required to develop software rapidly, frequently, reliably, and sustainably.
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.
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
Chris offers numerous other resources for learning the microservice architecture.
Want to see an example? Check out Chris Richardson's example applications. See code
Got a specific microservice architecture-related question? For example:
Consider signing up for a two hour, highly focussed, consulting session.
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.
Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.
Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,
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.
Engage Chris to conduct an architectural assessment.
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