Dark energy force: segregate by characteristics

a dark energy, dark matter force

We can often improve the quality of an application by segregating subdomains by their characteristics, which include:

Resource requirements
Domain-specific software development regulations
Business criticality
Security
DDD subdomain type

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.

Segregating by resource requirements to improve scalability

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 m5.24xlarge instances. 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.

Segregating by regulations to accelerate development

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.

Segregate by business criticality to improve availability

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 Payment Service.

Segregating by business criticality is typically beneficial when there are severe consequences of downtime, e.g. violating an SLA.

Segregate to improve security

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.

Segregating by DDD subdomain type to accelerate development

In Domain-Driven Design (DDD), subdomains are classified into the following types:

Core - the business logic that’s unique to your business and provides competitive advantage. Core subdomains should be the focus on your development efforts.
Supporting - the business logic that’s common to many businesses but often requires customization. Ideally, you should be able to buy this functionality from a third party but sometimes you must write it yourself.
Generic - the business logic that’s common to many businesses but doesn’t require customization. Generic subdomains should be bought from third parties.

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.

microservice architecture architecting dark energy and dark matter

Follow @MicroSvcArch

Microservice Architecture

Dark energy force: segregate by characteristics

a dark energy, dark matter force

Segregating by resource requirements to improve scalability

Segregating by regulations to accelerate development

Segregate by business criticality to improve availability

Segregate to improve security

Segregating by DDD subdomain type to accelerate development

About Microservices.io

MICROSERVICES WORKSHOPS

LEARN about microservices

Get the book: Microservices Patterns

Example microservices applications

Remote consulting session

Virtual bootcamp: Distributed data patterns in a microservice architecture

Learn how to create a service template and microservice chassis

BUILD microservices

Consulting services

The Eventuate platform

ASSESS your architecture

Consulting services

Topics

Posts