When discussing microservices, it is either a full architecture or a technical topic. The passionate conversation 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 architecture based on:
- Problem domain-specific solution
- Engineering team size
- Operation maturity
- Security model
- Performance requirements across sub-systems
- Team knowledge about distributed systems complexity
- Tooling maturity of monitoring
- Maturity of existing product design
- Most important is product delivery time scale
The greater complexity of those factors would increase the 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
- Lack of toolings enabling monitoring, debugging capability (reduce overall productivity in both development and production environment)
A few big companies can afford or even willing to build technology for technologies. Your team’s financial status, engineering context would help to derive towards building a product.
Leave a comment