Evolving a microservice architecture: how to right-size your services
This is a talk that I recently gave at SF JUG.
The key idea:
Only add a new architectural element (ie. service) if and only if it solves a tangible problem (i.e. resolves a dark energy force) and does not create more problems (i.e. by failing to resolve a dark energy forces) than it solves.
This is a simple idea, but it is often overlooked and can result in an excessively fine-grained, brittle, architecture.
Abstract
Let’s imagine that you want to add a new feature to your microservices-based application. You might be tempted to simply define a new service. After all, it is the MICROservice architecture. The trouble, however, with blindly adding new services, is that it often leads to the More the Merrier anti-pattern. An overly complex architecture that’s difficult to maintain and, perhaps, brittle.
In this presentation, I describe the dark energy and dark matter forces, which are conflicting concerns that you must consider when designing a microservice architecture.You will learn how the dark energy forces encourage decomposition into finer-grained services in order to improve aspects of your architecture including testability, maintainability, scalability. I describe how the dark matter forces discourage decomposition in order to improve aspects such as efficiency, availability and data consistency. You will learn how to use these forces to evolve your application’s microservice architecture.
Premium content and office hours is now available for paid subscribers at 
