Reasons for building microservices are often about using isolation as a means to handle change. Sharing code between services couples your services to each other and by this you are crossing the isolation barrier, reducing the effectiveness of the isolation and the ability to handle change, David Dawson writes questioning the Don’t Repeat Yourself (DRY) principle.
David, CEO at Simplicity itself, sees some common reasons for building microservices including:
- Independent scaling
- Service isolation
- Separate service life-cycles
David claims that these reasons are all about handling change, in the environment or in the codebase and he believes change is often also the main guidance used when splitting services apart.
The reasons among developers for sharing code across microservices are basically quite few, David has found, and include:
- Leverage existing technical functionality, e.g. through shared libraries.
- Sharing data schemas, e.g. by using the same classes.
- Sharing data sources, e.g. using the same data store by different services.
David emphasizes that all code sharing will attach your services together via the shared code. Creating a single source of truth, adhering to the DRY principle within a single service will create internal coupling but causes no problem in a service with a single responsibility. In contrast, when crossing a boundary, even though some things look the same, they are in a different context and must be different, implemented by different code and using a different data store. David urges that no matter how similar things look, we must resist attaching them because that means we are coupling across boundaries and across different contexts, a direct path to a big ball of mud.
David thinks the DRY principle has become one of the fundamentals of software development, comparable to design patterns but also that it has been transformed into a Don’t Repeat Anything principle and Copy and Paste is bad. Going back to the roots and the book “The Pragmatic Programmer” DRY was described as:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
David notes that the key term here is the concept of knowledge, not about copy and pasting. Although the principle is useful in certain areas he believes the term has been taken out of its context and applied too broadly. When applied at a higher level, e.g. sharing schemas, on a microservices architecture we will be left with the cost of maintaining the architecture but without the benefits, they have been short-circuited by DRY.