Microservices AntiPatterns and Pitfalls

Chapter 3. The “I Was Taught to Share” AntiPattern

Microservices is known as a “share-nothing” architecture. Pragmatically, I prefer to think of it as a “share-as-little-as-possible” architecture because there will always be some level of code that is shared between microservices. For example, rather than having a security service that is responsible for authentication and authorization, you might have the source code and security functionality wrapped in a JAR file named security.jar that all services use. Assuming security is handled at the services level, this is generally a good practice because it eliminates the need to make a remote call to a security service for every request, thereby increasing both performance and reliability.

However, taken too far, you end up with a dependency nightmare as illustrated in Figure 3-1, where every service is dependent on multiple custom shared libraries.

Figure 3-1. Sharing multiple custom libraries

This level of sharing not only breaks down the bounded context of each service, but also introduces several issues, including overall reliability, change control, testability, and deployment.

Too Many Dependencies

If you consider how most object-oriented software applications are developed, it’s not hard to see the issues with sharing, particularly when migrating from a monolithic layered architecture to a microservices one. One of the things ...