3 ms·
Because like any design pattern microservices should be used to address a specific problem. Martin Fowler describes that particular design pattern here in great
by BjoernKW 9y ago
Because like any design pattern microservices should be used to address a specific problem. Martin Fowler describes that particular design pattern here in great detail: https://martinfowler.com/articles/microservices.html https://martinfowler.com/articles/microservices.html
Microservices however unfortunately have become a fashionable cure-all that's applied indiscriminately to software projects of all sizes, ages and purposes. Hardly anyone seems to be asking anymore why they're actually using microservices. Everyone uses them because everyone else does.
Microservices always incur overhead both in terms of engineering and network latency as well as maintenance / administration. If you have more than 1 microservice you need infrastructure for orchestrating and monitoring these services.
For all that to be worth it you need to have pretty solid arguments for using microservices in the first place. For a new project I'd usually advise against using microservices right from the start. Doing so is often rooted in the same kind of fallacy that has people worry about Facebook-scale scalability before they even have their first user.
If you start having problems that can be solved with microservices then good for you! This means your software is successful and has grown so much in terms of features and responsibilities it's starting to become intractable with standard approaches.
This is precisely why Martin Fowler argues for starting with a monolith first: https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html
A traditional monolith gives you the opportunity to learn about the problem domain first without having to worry about implementation details such as microservices.
- smugworth 9y agoI think the strategy of "monolith first" isn't a poor one, but it is a little humorous to see someone who makes part of their living helping companies break apart their monoliths advocate it.
- mbrameld 9y agoI guess. My partner is currently starting a mushroom farm. She hopes one day it will be big enough to make use of a very large facility. Right now it isn't, though. Do you find the same humor in her real estate broker guiding her towards smaller properties initially even though if her business successfully grows the broker will make part of their living helping her move into a bigger location? Makes perfect sense to me.
- nucleardog 9y agoI get what you mean by saying it's humorous, but I think it's important that nobody easily dismiss what he says because of who he is. A lot of what he's arguing against is cargo cult programming, and I think it's fair for anyone to argue against that. If your only explanation for why you chose one architecture or design pattern over the others (especially if that option introduces a lot of additional drawbacks) is "because that's just what you do", you need to stop and objectively evaluate what you're doing.
- caseymarquis 9y agoI second this. You can internally build your monolith in a way that makes a transition to microservices easy. Avoid global state and build single concern processes which have their dependencies passed to them on creation.
- le-mark 9y agoAlso note that it is very, very difficult for anyone, inexperienced or experienced, to build a monolith that can later be pulled apart. You're two suggestions are a great start. You have to really design with the major blocks of functionality in mind, and carefully manage dependencies between these blocks AND third party dependencies. So many monoliths are balls of mud, that can't be pulled apart with any reasonable effort. The code may not be spaghetti, but the dependencies and interdependencies are.
- marcosdumay 9y agoHonestly, if one can not create a monolith that isn't a giant ball of mud, one has not chance at all of creating a distributed application, microservices or not, even ignoring quality.
- BjoernKW 9y agoIn that case one not unlikely ends up with an anti-pattern known as The Distributed Monolith, which combines the worst of both worlds.
- neuromantik8086 9y agoWhat about flow-based programming (https://en.wikipedia.org/wiki/Flow-based_programming https://en.wikipedia.org/wiki/Flow-based_programming)? How would you argue (or not argue) that differs from microservices? When would you advocate for a monolith first vs building one tool that does one thing and does it well and then pipes its output into another tool?
- marcosdumay 9y agoIt is a design technique that can be used for designing microservices based applications or any other kind of application that is distributed. So, it's something completely different and the difference you asked makes no sense. There is a link on that page for the more generic dataflow based programing. I'd advise anybody to follow it and simply ignore its specializations until they master the generic one. I'd also say that any program should be designed from multiple points of view, so do not stop at dataflow.