5 ms·

Please can you explain why using microservoces is over engineering? Is it because it’s a relatively new approach? Im getting involved in a new project that is u

by majjam 9y ago

Please can you explain why using microservoces is over engineering? Is it because it’s a relatively new approach? Im getting involved in a new project that is using microservices and a new framework...

beaconstudios 9y ago
not OP, but microservices can cause you to have to spend a disproportionate amount of time writing glue code between services. Starting with microservices is often a case of implementing separation of concern at the network rather than the functional layer, which is IMO too high in the stack. Microservices should be extracted for performance reasons, not build from the start because they are trendy.
Ygg2 9y ago
Did you read Honest status page? If you want your debugging session to reminiscent of a whodunit go with microservices. If you are doing microservices, I hope you have a good reason for doing so. Because there are significant problems with using microservices.
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 ago
  I 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 ago
    I 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 ago
    I 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 ago
  I 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 ago
    Also 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.
sudhirj 9y ago
They work well when designed well - and for me that's more often designed organically. If they're designed badly, most bugs eventually reduce to trying to do distributed transactions across microservices. That's my yardstick - if I see poor man's distributed transaction attempts happening across service boundaries I'll start to assume over-engineering / cargo culting. If I see services acting a nodes in an pipeline or a flowchart, preferably with multiple incoming lines, it smells better to me.

by majjam 9y ago

beaconstudios 9y ago

not OP, but microservices can cause you to have to spend a disproportionate amount of time writing glue code between services. Starting with microservices is often a case of implementing separation of concern at the network rather than the functional layer, which is IMO too high in the stack. Microservices should be extracted for performance reasons, not build from the start because they are trendy.

Ygg2 9y ago

Did you read Honest status page? If you want your debugging session to reminiscent of a whodunit go with microservices. If you are doing microservices, I hope you have a good reason for doing so. Because there are significant problems with using microservices.

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 ago
I 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 ago
  I 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 ago
  I 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 ago
I 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 ago
  Also 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.

sudhirj 9y ago

They work well when designed well - and for me that's more often designed organically. If they're designed badly, most bugs eventually reduce to trying to do distributed transactions across microservices. That's my yardstick - if I see poor man's distributed transaction attempts happening across service boundaries I'll start to assume over-engineering / cargo culting. If I see services acting a nodes in an pipeline or a flowchart, preferably with multiple incoming lines, it smells better to me.