| There is absolutely no need to use different languages and technologies within a microservices architecture if it is not necessary for your business. But to simply dismiss the business perspective from your perspective seems a little naive. Some reasons why decoupling your architecture can make sense from a business perspective: - You have a complicated product, and wish to break it up into more digestible chunks, with allocated teams working on each abstract business concept (Amazon and Spotify do this). - You want to avoid having a single point of failure- if one service fails, the rest of the system might well keep on working. (Ever noticed how sometimes a panel on Amazon doesn't load?). If you're running a continuous development process, stuff breaks, a lot. It's good if that's locked down. - You have a business requirement to build something with a different technology (from experience- rendering javascript in a node service was much, much easier and more maintainable than with an existing Django app- we tried both.) - You want to experiment with new technologies without changing your whole stack. I'm pretty sure that the author wasn't talking about moving to microservices so they can blindly start building every aspect of the application in a different stack- but more that if they need to use a new technology for their business requirements, or want to give something a trial without committing, they can. And with the uncertainty and rate things change in modern software, and in a startup, that flexibility is invaluable. |