Encapsulation
Encapsulating the internals of a service through a carefully defined service boundary that does not expose internals of a service is important. Maintaining loose coupling in microservices is important to realizing the benefits of a microservices approach. If we are not careful, our microservices can become coupled. Once these services become coupled we can lose a lot of the value in a microservices architecture, like independent lifecycles. Deploying and managing a microservices-based application with tightly coupled services can be more complex than deploying and managing a monolith. If the deployment of a service needs to be closely coordinated with other services, there is likely coupling as a result.
Common causes of service coupling:
• Shared Database Schema
• Message Bus or API Gateway
• API design
• Rigid Protocols
• Exposing service internals in the API
• Organizational coupling (Conway’s Law)
Conway’s Law
Conway’s Law generally states that the design of a system reflects the communication structure of the organization.
Shared databases and schemas are common causes of coupling. We start out building our microservices, and because our microservices all use a SQL database, and there is some overlap in the schema, we simply have a bunch of our services share a database. All of our data is related in some way, so why not? It would appear that we can deploy and manage our services independently until we need to change something in the database, and then we need to coordinate a deployment with the other services and their teams. It might sometimes happen that a database schema never changes; however, more often than not they do need changing over time. There can be good reasons for two or more microservices to share database schema and still remain separate microservices, but it’s important to understand what the trade-offs are.
Another common cause of coupling that was prominent in past implementations of service-oriented architecture was an Enterprise Service Bus (ESB). The service bus often contained schemas, transforms, and business logic that were tightly coupled with the services that integrated with them.
Not only do we need to ensure the design and implementation enables us to reduce or eliminate the friction between our services so we can move quickly, it’s important that the teams themselves do not become coupled.