3 ms·
Yep, I used to be that guy as well. It is easier to see things as black and white because then you don’t need to dive deep and it is easier to sell to manageme
by alemanek 2y ago
Yep, I used to be that guy as well. It is easier to see things as black and white because then you don’t need to dive deep and it is easier to sell to management. The really strong engineers/architects I have known can explain the trade offs of the various approaches.
For small teams or early stage development I love a well architected modular monolith. Grow past a couple of teams and maybe add some dedicated ops people and service oriented architectures start making more sense. Get real big and have the capacity to handle the monitoring and orchestration challenges and microservices enable that.
It’s all trade offs and recognizing that allows you to evolve with your operational and organizational needs.
- seabrookmx 2y agoI much prefer "service oriented architecture" terminology to "microservice" because services need not be the same size. Have a daemon listening to a queue to send emails? Sure, microservice! Have 10 REST endpoints that are backed by the same interconnected data? Sure you could have 10 lambdas or something but.. why?
- alemanek 2y agoYeah I try to use “service oriented architecture” in discussions because it implies as small as necessary instead of as small as possible. I find it reframes the discussion a bit and encourages a better set of initial domain boundaries. While I work on things that are large and need to scale well I don’t work at the hyper scaler level which is where I think the “as small as possible” type services are more commonly needed. But, that is just speculation on my part from reading lessons learned whitepapers from those companies