| I would like to respectfully disagree with you on most of your points (in the article). 1. While network boundaries are not necessary, and in general add a little more overhead (and more boilerplate), it's a necessary evil. It helps you to think of each bit of software separately and in a way, helps you to find errors when they occur. I have worked with monolithic projects and while finding bugs is not hard, if it were a serverless micro-service, it'd be a lot easier. 3. adding discipline as an abstract afterthought is a lot harder than just forcing discipline with micro-service projects. 4. A not my problem approach might not be something to desire, but in my opinion, it helps in 2 major ways: i) people are a lot more responsible for their code ii) they don't make assumptions and take things for granted (a lot of error handling for example) 5. Scaling micro-services (especially with AWS Lambda et al. is insanely easy and an afterthought). That is not the case for a monolith where you either have to keep worrying about scaling or re-write code. I personally feel micro-services are the way to go. However, micro-services in general need a bit more guidance - best practices and so on and we have a lot more work to do before we get there. |