- Using Mircoservice when not required for example
If deployment is only once per month
If the team is not ready
If the app just works fine with monolithic
- Testing
Changes can cause cascading failure
Others depend on our service
Implement red-green deployment - It will only affect small subset of
people. Do testing directly in production. Do rollback
- No Devops
No Logging and Tracing
Distributed tracing -> Used to find which microservice in my code
is taking long time to respond. It will help to plot the graph between service
a to the end service. And also help us see which service took long time.
Kubernetes has side-car. AWS has X-Ray.
If we don't have automated deployments.
If we don't have configuration management. For example: environment
specific details Dev, Test, QA, PROD. It should be in a configuration service.
Don't check-in hostnames
- POLYGLOT
Chose appropriate technology. Choosing many random technology makes
support difficult
Difficult to do auto-deployment if we have too many different stacks
like .net, java, go, python, ruby. use standard tech stack. Better to use
single tech stack.
- Don't expect failures
Lot of failures in microservices than monolithic
Build microservices for resiliency by doing graceful degradation
Do health check before sending request to some other service
Retry again in case of failure. It can be a transient failure. Retry
only at command level. Use circuit breakers at service level.
Process asynchronously
No comments:
Post a Comment