The Effects of Dark Energy and Dark Matter on Microservices: Five Crucial Influences

Dark Energy's forces encourage using separate services for each task, while Dark Matter's forces encourage combining tasks into one big service. This creates challenges in deciding whether to keep tasks separate or together.

This conflict needs careful analysis and several trade-offs to find the right balance and create a good service in the microservice architecture.

To learn more about "Dark Energy vs Dark Matter" and what it means, read this blog - Understanding Dark Energy and Dark Matter in Microservice Architecture

Dark Energy's Five Forces

Dark energy's repulsive force means that some services contain multiple subdomains (responsibility), pushing towards creating separate services for each subdomain.

There are five important forces that we will cover one by one.

1. Team autonomy

2. Simple components

3. Fast deployment

4. Support multiple technology

5. Segregated by characteristics

Team autonomy

Teams are divided, and each team works independently to build, test, and deploy its own subdomain without interference from other teams. Other teams may get involved only when subdomains need to connect or interact with each other.

Team autonomy = A team per service (subdomain)

Simple components

A service should be simple, handling just one task. It's important to analyze carefully when creating a service to avoid combining multiple subdomains into one, which could cause complexity later.

Simple components = A service exists to solve or handle a single, specific task

Fast deployment

Every team works on its own subdomain, so other teams' work doesn't interfere. This makes subdomains easy to build, test, and deploy quickly, allowing for fast feedback.

Fast deployment = One team works on one service (subdomain), allowing for quick deployment and feedback.

Support multiple technology

Subdomains can be built using different technologies. For example, one service might use Java, while another uses .NET or Python. This allows us to have multiple technology stacks for the services (subdomains).

Support multiple technology = A different technology per service (subdomain).

Segregated by characteristics

Services are divided based on their unique features or attributes. This ensures that each service is specialized and focused on handling specific tasks or responsibilities. If this reminds you of "simple components," refer to the summary below for clarification.

NOTE Summary:

• Simple Components: Keep it simple by ensuring each service handles just one specific task, avoiding the complexity of combining multiple tasks.

• Segregated by Characteristics: Organize services based on their unique features or attributes like security, business criticality, cost effective scaling or cheaper, and efficient, ensuring they are specialized and focused on specific responsibilities.

Segregated by characteristics = Dividing services based on unique features to ensure specialization and focus.

Dark Matter's Five Forces

Dark matter's force tries to pull multiple subdomains (responsibilities) into a single service, pushing towards creating a monolith.

• Simple Interaction

• Efficient Interaction

• Prefer ACID

• Minimize runtime coupling

• Minimize design time coupling

Simple Interaction

When multiple subdomains are combined into one service, creating a monolith, it makes interactions and local operations easier and simpler to troubleshoot. However, operations can become complex when handling individual subdomains separately.

Easy Interaction = Combining subdomains into one service simplifies interactions and troubleshooting.

Efficient Interaction

When multiple subdomains are part of one service, operations are performed locally, boosting efficiency and resulting in faster outcomes and better memory use because everything is managed within the same service. There are no challenges like network latency or limited bandwidth, as there would be with separate subdomains.

Efficient Interaction = operations locally, resulting in faster outcomes and better memory use without network latency or bandwidth issues.

Prefer ACID

Similar to the above, when every operation is local, transactions become easier to handle, and it's possible to maintain data consistency. In a distributed or separate subdomain setup, maintaining consistency or achieving eventual consistency in transactions becomes more challenging.

Prefer ACID = Easy to maintain data consistency, Local ACID Transaction.

Minimize runtime coupling

When multiple services interact in a distributed system, such as when service A calls service B, there can be delays or unavailability, leading to runtime coupling risks. However, if both subdomains are within a single service, there won't be runtime issues. Availability is higher, and latency is lower since both domains are managed within the same service.

Minimize runtime coupling = No runtime coupling risk, higher availability, and reduced latency.

Minimize design time coupling

Minimizing design time coupling means making the design and development process easier by combining multiple subdomains into one service, usually within a monolithic architecture. This has several benefits, like having a single codebase, consistent data, and easier communication. By merging components like product catalog, user management, and order processing into one service, the design process is simpler, reducing the complexity of managing separate services.

For example, when a new API is added or an old one is later removed, a distributed system might struggle to keep different API versions compatible across various services, which can lead to communication problems and more complexity in managing versions and dependencies.

Minimize design time coupling = Avoid costly simultaneous changes

Final Conclusion

When building a good microservices architecture, it's important to balance two key forces. One force pushes for separating services to make them more independent and flexible. The other force focuses on combining services for efficiency and simplicity. By understanding and balancing these forces, you can reduce problems and create a strong microservices setup that fits your organization's needs.

For more insights on various topics, visit my Hindi YouTube channel: youtube.com/@progrank.