By WalkingTree February 10, 2021
Microservices is an architectural style of building systems using simple, lightweight, and loosely coupled services that can be developed independently. The coupling can happen if a change to one microservice enforces an almost immediate change to all other microservices that collaborate with it directly or indirectly. Let’s take a look at some poor design decisions that violate loose coupling and lead to distributed monoliths.
- Database Sharing – Database sharing is the most common form of implementation coupling. The choice of data storage are details that should be hidden from clients. Sharing databases will expose them all.
Solution – Have customers provide an API that Orders can use to retrieve the customer data. The formatting of this data will stay the same as long as customers are committed to keeping its current contract up.
- Code Sharing – Microservices can fall into the trap of implementation coupling by sharing dependency libraries. Shared code has to be lightweight, exclude domain-specific logic with minimal dependencies.
Solution – Customers and orders should each have their copy of the customer’s object in different dependency libraries.
- Excessive Sharing of the Domain Data – Domain-driven design is usually recommended for breaking a monolith into microservices. But if microservices start to share domain-specific data, it will create a distributed monolith through domain coupling.
Solution – Only share the data that your clients need. If they need something that is outside of the domain boundary, it’s time to rethink service boundaries.
Read on to know more about coupling in Microservices and how to avoid them.
An integrated security practice within the DevOps process helps ongoing collaboration between engineers and security teams and build…
DevOps is the most recent tech absorption in enterprises with close sync between software development and IT operations…