You are developing a business-critical enterprise application. You need to deliver changes rapidly, frequently and reliably - as measured by the DORA metrics - in order for your business to thrive in today’s volatile, uncertain, complex and ambiguous world. Consequently, your engineering organization is organized into small, loosely coupled, cross-functional teams. Each team delivers software using DevOps practices as defined by the DevOps handbook. In particular, it practices continuous deployment. The team delivers a stream of small, frequent changes that are tested by an automated deployment pipeline and deployed into production.
A team is responsible for one or more subdomains. A subdomain is an implementable model of a slice of business functionality, a.k.a. business capability. It consists of business logic, which consists of business entities (a.k.a. DDD aggregates) that implement business rules, and adapters, which communicate with the outside world. A Java-based subdomain, for example, consists of classes organized into packages that’s compiled into a JAR file.
The subdomains implement the application’s behavior, which consists of a set of (system) operations. An operation is invoked in one of three ways: synchronous and asynchronous requests from clients; events published by other applications and services; and the passing of time. It mutates and queries business entities in one or more subdomains.
How to organize the subdomains into one or more deployable/executable components?
There are five dark energy forces:
There are five dark matter forces:
Design an architecture that structures the application as a single deployable/executable component that uses a single database. The component contains all of the application’s subdomains. Since there’s a single component, all operations are local.
Let’s imagine that you are building an e-commerce application that takes orders from customers, verifies inventory and available credit, and ships them. The application consists of several components including the StoreFrontUI, which implements the user interface, along with some backend services for checking credit, maintaining inventory and shipping orders.
The application is deployed as a single monolithic application. For example, a Java web application consists of a single WAR file that runs on a web container such as Tomcat. A Rails application consists of a single directory hierarchy deployed using either, for example, Phusion Passenger on Apache/Nginx or JRuby on Tomcat. You can run multiple instances of the application behind a load balancer in order to scale and improve availability.
This solution has a number of benefits:
This solution has a number of (potential) drawbacks:
These drawbacks become more severe as the application grows in size and complexity and the number of teams developing it increases.
A key challenge with the monolithic architecture is minimizing the potential drawbacks, especially as the application grows in size and complexity and the number of teams developing it increases. There are a few solutions that can reduce some of the drawbacks:
Increase maintainability and team autonomy by modularizing the monolith. Instead of the traditional layered architecture, the subdomains are organized into vertical slices consisting of presentation, business and persistent logic.
Accelerate the deployment pipeline by
The microservice architecture is an alternative pattern that addresses the limitations of the monolithic architecture.
Well known internet services such as Netflix, Amazon.com and eBay initially had a monolithic architecture. Most web applications developed by the author prior to 2012 had a monolithic architecture.
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 moreChris 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 RESVJCMC to sign up for $95 (valid until September 26th, 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
Microservices adoption · ancient lore · anti-patterns · application api · application architecture · architecting · architecture · architecture documentation · assemblage · beer · containers · dark energy and dark matter · deployment · design-time coupling · developer experience · 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 · modular monolith · multi-architecture docker images · observability · pattern · refactoring to microservices · resilience · sagas · security · service api · service architecture · service collaboration · service design · service discovery · service granularity · service template · software delivery metrics · success triangle · tacos · team topologies · transaction management · transactional messaging
Application architecture patterns
Decomposition
Refactoring to microservicesnew
Data management
Transactional messaging
Testing
Deployment patterns
Cross cutting concerns
Communication style
External API
Service discovery
Reliability
Security
Observability
UI patterns