We can often improve the quality of an application by segregating subdomains by their characteristics, which include:
It’s important to remember that whether the benefits of segregating subdomains by their characteristics outweighs the drawbacks depends on the details of the application.
Let’s look at a few examples.
A subdomain requires certain resources, such as CPU, GPU, memory, network bandwidth, storage, etc. It also requires a particular number of “instances” to achieve the desired throughput and availability. However, the unit of scaling in an application is a component, or more precisely, a component instance. This means that the component’s subdomains are scaled together, which risks over provisioning resources for some of its subdomains. If you package subdomains as separate services, you can scale them independently by, for example, using different EC2 instance types, which improves resource utilization and reduces cost.
Let’s imagine, for example, the following scenario.
There are two subdomains,
Order Management, which has ‘normal’ resource needs, and
Fraud Detection, which needs GPUs.
To achieve the desired throughput 10 instances of
Order Management are required but only 5 instance of
Fraud Detection is required
If we put these two subdomains in the same
Order Service component, we will have to provision 10 instances of the component, which will result in 5 instances of
Fraud Detection being underutilized.
This architecture might be expensive to scale since
p4d.24xlarge EC2 instances that have GPUs are 8x the price of
We can reduce the cost of scaling by segregating these two subdomains into separate services, which can be scaled independently.
Segregating subdomains by their resource requirements is mostly beneficial when operating at high scale when there are significant cost savings.
Software development in some domains is regulated. For example, if you are developing software that’s classified as Software as a Medical Device then your development practices follow various standards such as ISO 13485 and ISO/IEC 62304, which are obstacles to DevOps-style development. However, it’s possible that only a subset of your application’s subdomains are regulated. If that’s the case, then you can segregate the regulated subdomains into separate service(s). This will enable you to develop the unregulated subdomains using DevOps practices.
It’s likely that some of your application’s subdomains are more business critical than others. For example, let’s imagine that you are credit card payment processing company. The subdomains that handle credit card authorization and charge requests are critical to the business. That’s how you make money and you most likely have strict SLAs with your customers. In contrast, other subdomains, such as merchant account management, are likely to be less critical.
You can, therefore, improve availability by segregating subdomains by the business criticality.
You can, for example, define a
Payment Service, which handles credit card authorization and charge requests.
It has a separate code base, runs on its own infrastructure and is decoupled at runtime from the rest of the services.
As a result, it’s unaffected by any problems that might occur in the rest of the application.
Moreover, developers working on other functionality, such as merchant account management, don’t have to worry about breaking the
Segregating by business criticality is typically beneficial when there are severe consequences of downtime, e.g. violating an SLA.
Some subdomains manage sensitive data, such as Personally Identifiable Information (PII). Packaging such a subdomain as a separate service can improve security. The data can only be accessed via the service’s API. Moreover, network-level security mechanisms can be used to further restrict access.
In Domain-Driven Design (DDD), subdomains are classified into the following types:
We can improve productivity by packaging core subdomains as services that are separate from those non-core subdomains. This ensures that their development is no longer affected by or constrained by those other subdomains. You could, for example, upgrade or change a core domain’s technology stack separately from any non-core domain. Packaging core subdomains separately increases the organization’s ability to focus on their 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