- Clients know too much: Auth, Encryption, etc.
- Hard to change a microservice -> Don’t know who’s using it. Hard to add a new microservice -> No one may use it. Being political.
- Responsibility for the failure in a microservice. What happened when a microservice fails.
- REST is slow
Solutions – Useful Architectures
- API Gateway
- Provides: Auth, Routing, Rate Limiting, and Logging and analytics.
- It can be a bottleneck if all internal services access the API gateway. => Anti-Pattern
- Service Mesh. Side-car. Shared library.
- Work as a proxy(service discovery, routing).
- Control re-try pattern. e.g. circuit-breaker. Too much retry causes a problem.
- Broadcast -> Subscribe. Being independent of the other services.
- DB for each microservice
- local DB can provide local state for each Microservice, which allows independence.
- DB can be a small, cloud-based key-value DB.
- Very important to keep the consistent schema (contracts) among services.
- Can register all schema in the schema registry, which all microservices will share.
- Can have state by storing in cloud DB or storage.
- Durable functions -> Azure functions?
- Triggers and data from stores to functions -> Maybe Azure event grid is the answer for this.
- Unified view of the current state -> Hard to check what’s happening long the workflow of the entire system.