Dark energy force: segregate by characteristics

microservice architecture   architecting   dark energy and dark matter  

---

a dark energy, dark matter force

We can often improve 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 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.