Take a look at Assemblage, a microservice architecture definition process.
In my workshop, you will learn about to use Assemblage to design a microsevice architecture for your application.
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 set of independently deployable, loosely coupled, components, a.k.a. services. Each service consists of one or more subdomains and is owned by the team (or teams) that owns the subdomains.
In order to be independently deployable each service typically has its own source code repository and its own deployment pipeline, which builds, tests and deploys the service.
Some system operations will be local (implemented by a single service), while others will be distributed across multiple services. A distributed operation is implemented using either synchronously using a protocol such as HTTP/REST or asynchronously using a message broker, such as Apache Kafka.
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 consists of a set of services.
Please see the example applications developed by Chris Richardson. These examples on Github illustrate various aspects of the microservice architecture.
This solution has a number of benefits:
This solution has a number of (potential) drawbacks:
There are many issues that you must address.
How to design a microservice architecture that avoids the potential drawbacks of complex, inefficient interactions; complex eventually consistent transactions; and tight runtime coupling. Assemblage, is an architecture definition process that uses the dark energy and dark matter forces to group the subdomains in a way that results in good microservice architecture.
One challenge with using the microservice operation is implementing distributed operations, which span multiple services. This is especially challenging since each service has its own database. The solution is to use the service collaboration patterns:
The Saga, Command-side replica and CQRS patterns use asynchronous messaging. Services typically need to use the Transaction Outbox pattern to atomically update persistent business entities and send a message.
There are many patterns related to the Microservices architecture pattern. The Monolithic architecture is an alternative to the microservice architecture. The other patterns in the Microservice architecture architecture pattern address issues that you will encounter when applying this pattern.
Most large scale web sites including Netflix, Amazon and eBay have evolved from a monolithic architecture to a microservice architecture.
Netflix, which is a very popular video streaming service that’s responsible for up to 30% of Internet traffic, has a large scale, service-oriented architecture. They handle over a billion calls per day to their video streaming API from over 800 different kinds of devices. Each API call fans out to an average of six calls to backend services.
Amazon.com originally had a two-tier architecture. In order to scale they migrated to a service-oriented architecture consisting of hundreds of backend services. Several applications call these services including the applications that implement the Amazon.com website and the web service API. The Amazon.com website application calls 100-150 services to get the data that used to build a web page.
The auction site ebay.com also evolved from a monolithic architecture to a service-oriented architecture. The application tier consists of multiple independent applications. Each application implements the business logic for a specific function area such as buying or selling. Each application uses X-axis splits and some applications such as search use Z-axis splits. Ebay.com also applies a combination of X-, Y- and Z-style scaling to the database tier.
There are numerous other examples of companies using the microservice architecture.
Chris Richardson has examples of microservices-based applications.
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 organizations improve agility and competitiveness through better software architecture. Learn more about his 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 KQAWEXBH to sign up for $120 (valid until November 21st, 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 · books · containers · dark energy and dark matter · deployment · design-time coupling · developer experience · development · devops · docker · eventuate platform · generative AI · glossary · health · 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