This is part 1 in a series of blog posts about why and when to use the microservice architecture. Other posts in the series are:
The microservice architecture is an architectural style that structures an application as a collection of services that are
It’s important to remember that the microservice architecture is not a silver bullet. It should never be the default choice. However, as I wrote recently, neither should the monolithic architecture:
Instead, both architectures are patterns that every architect should have in their toolbox.
Whether or you not you should use the microservice architecture for a given application can be summed up as ‘it depends’. A longer and perhaps more helpful guideline is:
IF you are developing a large/complex application AND you need to deliver it rapidly, frequently and reliably over a long period of time THEN the Microservice Architecture is often a good choice
This is the first of the series of articles that expands on that guideline and attempt to explain when you should consider using the microservice architecture. It describes why IT must deliver software rapidly, frequently and reliably (DSRFR). Later articles explain how DSRFR requires your architecture to have certain properties, which in turn requires you to choose between the monolithic and microservice architectures.
Let’s first look at why IT must deliver software rapidly, frequently and reliably
There are two trends that are changing how IT delivers software (and driving the adoption of microservices). The first trend is, as Marc Andreessen said back in 2011, software is eating the world. In other words, every company, regardless of its industry, needs to become a software technology company. It doesn’t matter whether you’re in banking, insurance, mining, aviation. Your products, your services, are all powered by software.
The second trend that’s driving the adoption of microservices is that the marketplace within which companies operate is becoming increasingly more volatile, more uncertain, more and more complex, and more ambiguous(a.k.a.VUCA). For example, traditional brick and mortar banks in Singapore and Hong Kong have or will soon have multiple new competitors: virtual banks. And, in the UK, insurance companies are must now compete against Insurtech startups that offer innovative new products, such as Zego, which provides hourly commercial insurance for gig economy workers.
Because of these two trends, businesses today must be much more nimble, much more agile, and they must innovate at a much faster rate. And, since these innovative products and services are powered by software, IT must deliver software much more rapidly, much more frequently, and much more reliably.
One of my favorite books about high performance IT organizations is Accelerate by Nicole Forsgren, Jez Humble and Gene Kim. It introduces four metrics that the authors have found to be a good way to quantify rapid, frequent, and reliable delivery of software. The first two metrics measure velocity
Both these metrics are very much based on Lean principles. Reducing lead time is important because it results in faster feedback. Also, a shorter lead time means that a bug in production can be fixed much faster.
Accelerate uses deployment frequency as a proxy for batch size, which is another important lean concept. Reducing batch size has numerous benefits including faster feedback, reduced risk, and increased motivation.
The second two metrics measure the reliability of software delivery:
Obviously, we want to minimize these two metrics. We must reduce the likelihood of a change causing a production outage. But if it does, we must be able to quickly detect, diagnose, and recover from that failure.
The following diagram shows the results of the 2017 State of DevOps Report. The State of DevOps Report is published every year by the Accelerate authors. It surveys a large number of organizations and asks them about their development practices including the 4 metrics described earlier. The results are then analyzed and organizations clustered by those four metrics into low performers, medium performers, and high performing organizations.
As you can see, high performing organizations develop software at a much faster rate. The deployment frequency is significantly higher. They’re deploying multiple times a day into production. The lead time is quite short as well, under an hour.
But what’s really interesting is that these organizations are also developing software in a much more reliable way. The mean time to recover is less than an hour, and also the change failure rate is significantly less. High performing organizations deliver software rapidly and reliably. It’s common for high performance IT organizations at large companies to deploy 100s or 1000s of times per day. Apparently, Amazon deploys every 0.6 seconds!
High performing IT organizations are delivering software rapidly, frequently and reliably. But what’s more, according to the research done by the Accelerate authors, high performing IT organizations result in better business performance as measured by profitability, productivity, and market share. In other words, today, in order for a business to be successful, it needs to have mastered software development.
In the next post, I’ll discuss another challenge for IT: the need for sustainable development.
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