Microservices AntiPatterns and Pitfalls

Chapter 5. Grains of Sand Pitfall

Perhaps one of the biggest challenges architects and developers face when creating applications using a microservices architecture is service granularity. How big should a service be? How small should it be? Choosing the right level of granularity for your services is critical to the success of any microservices effort. Service granularity can impact performance, robustness, reliability, change control, testability, and even deployment.

The grains of sand pitfall occurs when architects and developers create services that are too fined-grained. Wait—isn’t that why it’s called microservices in the first place? The word “micro” implies that a service should be very small, but how small is “small”?

One of the primary reasons this pitfall occurs is because developers often confuse a service with a class. Too many times I’ve seen development teams create services by thinking that the implementation class they’re writing is actually the service. Nothing could be further from the truth. 

A service should always be thought of as a service component. A service component is a component of the architecture that performs a specific function in the system. The service component should have a clear and concise roles and responsibility statement and have a well-defined set of operations. It is up to the developer to decide how the service component should be implemented and how many implementation classes are needed for the service.

As Figure 5-1 shows, a service ...