When discussing about microservices, it is often treated as a full architecture or technical topic. Heated converstaion usually started without context. People dislike microservices because they are concerned about simplicity from an angle; people like microservices because it offers some simplicity in another dimension without considering trade-offs.
Microservices is a journey towards an archtecture based on:
- Problem domain specific solution
- Engineering team size
- Operation maturity
- Security model
- Performane requirements cross sub-systems
- Team knowledge about distributed systems complexity
- Tooling maturity of monitoring
- Maturity of existing product design
- Most important is product delivery time scale
Greator complexity of those factors would increase risks of project delivery:
- Team has no experience in managing the complexity
- More technical dept to clean up
- Close deadline for the project
- Problem domain does not fit for purpose
- No basic tooling enable monitoring, debugging capability (reduce overall productivity in both development and production environment)
A few lucky big company can afford or even willing to build technology for technologies. Your team financial status, engineering context would help to derive towards building a product.
Comments