> I've talked to developers who have taken a single app that worked perfectly fine and split it into five or six services just because "microservices!" We've a

> I've talked to developers who have taken a single app that worked perfectly fine and split it into five or six services just because "microservices!" We've also all met that developer that decided that Foo (library, framework, pattern, language - pick your poison) is SO MUCH BETTER than Bar (which is what you use now), and frantically sets out to replace all things Bar with Foo (and gives up halfway, so now you've got the maintain both Foo and Bar bit of your code, all intertwined). The problem isn't with Foo and it's merits, it's actually very useful, the problem is that that developer is, frankly, shit. Microservices is a perfectly useful pattern to achieve a number of ends, but it's not the answer to all questions. Know what you're trying to achieve, evaluate options on their actual merits (not what's buzzwordy this month) and make decisions consciously. EDIT to add: > can I see parts of this project being used in another project? That's not the only benefit from microservices. Smaller units are easier to reason about (and test!), and they allow you to experiment: A monolithical app needs to maintain some sort of consistency. Most of the time it will be written in the same language, using the same general patterns and libraries supporting these patterns (eg. dependency injection using Guice or Spring). Most of the time, none of this will be cutting edge, some of the time it will be decidedly out of date, but changing it is hard and risky, and, well, it works. With microservices your can use the languages, patterns and libraries that suit your isolated use case best. Need to support complex web forms? You might want to run Node.js so you can use the same JS code for validation on the front end and back end. Need lots of boring CRUD in your admin app? Ruby on Rails is your friend. Number-crunching? You might want to use Clojure or F#. Interfacing with some proprietary system (e.g. Sharepoint)? Use the best supported library you can find (.NET webservices client), and build a service up around that, on the platform that best supports that library (ASP.NET on IIS on Windows).