4 ms·

What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years.

What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!

IMTDb 8y ago
What I love about monolith is coherence and forcing you to do things well from the beginning. Microservice mesh tend to become horrible to maintain after a few years when no one really measure which components will be impacted by a single change. On the opposite, change one small 50 line function and your IDE will happily show you all the calls to that specific function.
- Arqu 8y ago
  So the consensus is to do things well from the start. IMHO both have their merits but strongly depend on the usecase. There is no one size fits all. A lot of thought has to go into both options to make them really effective. Otherwise it's just garbage in garbage out.
- hoffs 8y ago
  Just like you have tests between monolith modules you can have integration tests between microservices
  - joshschreuder 8y ago
    The more layers you are testing, the slower and harder it is to write tests and the feedback loop is way longer also.
    - Arqu 8y ago
      Depends how you do it. Having a sane communication model/interface between the services allows you to test it in two ways: 1) You test the internal structure with unit tests 2) You test changes to the API contract with E2E tests Both are fairly straightforward once you set it up properly. Same goes for the monolith, assuming you do your work on following somethink like the SOLID principle, it is easy to test piece by piece. The only thing here is that the interface contracts are internal to the codebase vs external to other codebases. (You might argue the last point actually forces you to write a more coherent API contract in both situations)
avaika 8y ago
Though keep in mind that in microservice world suddenly you have dozen of problems you would never face in monolith world. You are forced to implement a good orchestration, deployment, segregate data between services and other stuff. It's all fun, but takes time to dive into that and build the right process. For sure it is nice and sound once it's built, but you might simply lose track of your primary product if you're solo project dev :)
baaym 8y ago
And then another downstream microservice fails when you deploy your change into a running environment, because you lack the integration testing capabilities of a monolith. It's true you achieve higher isolation with microservices, but you also lose points in other areas. And you can get lost in your haystack of microservices just as easily as in your typical monolith ;)
kabes 8y ago
You can just as easily create an unmaintainable spaghetti mess of microservices. Isolation is defined by good architecture, microservice or monolith is just how it gets executed.
collyw 8y ago
Not if you know how to architect one properly. How is a small microservice with one purpose different from a class / module with one purpose?
- js4ever 8y ago
  A simple syntax error in a monolith means the whole monolith is crashed. Bug anywhere in the monolith could mean border effect in the rest of the code anywhere. With microservices you guaranty isolation so a bug in one microservice won't have impact on the rest of the api
  - batiste 8y ago
    A syntax error should never make it production if you have even half decent infrastructure... In a monolith or a micro service. And if your microservice get to production with a syntax error do you really think the whole ecosystem is somehow more healthy? Not unless you wrote a ton of horrible defensive code with and retries and HTTP error/timeout catching code every time this service is called...
    - zzzcpan 8y ago
      Typically you make an abstraction for all those timeouts, retries and errors. It can look just like a normal function call and have optional arguments for timeouts.
  - zmmmmm 8y ago
    You're blurring the lines a bit between the true definition of microservices (eg: no shared schema, data structures, etc) and just a sensible deployment architecture. If their runtime state is independent then there is nothing stopping you taking your monolithic code base and deploying it N times, for as many independent end points as you want. That way service A crashing is never going to bring down service B, but they can still share code and data structures. The real question is, do they have shared runtime state? If they don't, you can do the above, but if they do, moving to microservices won't make that go away, it might even make it harder to deal with.

IMTDb 8y ago

What I love about monolith is coherence and forcing you to do things well from the beginning. Microservice mesh tend to become horrible to maintain after a few years when no one really measure which components will be impacted by a single change. On the opposite, change one small 50 line function and your IDE will happily show you all the calls to that specific function.

Arqu 8y ago
So the consensus is to do things well from the start. IMHO both have their merits but strongly depend on the usecase. There is no one size fits all. A lot of thought has to go into both options to make them really effective. Otherwise it's just garbage in garbage out.
hoffs 8y ago
Just like you have tests between monolith modules you can have integration tests between microservices
- joshschreuder 8y ago
  The more layers you are testing, the slower and harder it is to write tests and the feedback loop is way longer also.
  - Arqu 8y ago
    Depends how you do it. Having a sane communication model/interface between the services allows you to test it in two ways: 1) You test the internal structure with unit tests 2) You test changes to the API contract with E2E tests Both are fairly straightforward once you set it up properly. Same goes for the monolith, assuming you do your work on following somethink like the SOLID principle, it is easy to test piece by piece. The only thing here is that the interface contracts are internal to the codebase vs external to other codebases. (You might argue the last point actually forces you to write a more coherent API contract in both situations)

avaika 8y ago

Though keep in mind that in microservice world suddenly you have dozen of problems you would never face in monolith world. You are forced to implement a good orchestration, deployment, segregate data between services and other stuff. It's all fun, but takes time to dive into that and build the right process. For sure it is nice and sound once it's built, but you might simply lose track of your primary product if you're solo project dev :)

baaym 8y ago

And then another downstream microservice fails when you deploy your change into a running environment, because you lack the integration testing capabilities of a monolith. It's true you achieve higher isolation with microservices, but you also lose points in other areas. And you can get lost in your haystack of microservices just as easily as in your typical monolith ;)

kabes 8y ago

You can just as easily create an unmaintainable spaghetti mess of microservices. Isolation is defined by good architecture, microservice or monolith is just how it gets executed.

collyw 8y ago

Not if you know how to architect one properly. How is a small microservice with one purpose different from a class / module with one purpose?

js4ever 8y ago
A simple syntax error in a monolith means the whole monolith is crashed. Bug anywhere in the monolith could mean border effect in the rest of the code anywhere. With microservices you guaranty isolation so a bug in one microservice won't have impact on the rest of the api
- batiste 8y ago
  A syntax error should never make it production if you have even half decent infrastructure... In a monolith or a micro service. And if your microservice get to production with a syntax error do you really think the whole ecosystem is somehow more healthy? Not unless you wrote a ton of horrible defensive code with and retries and HTTP error/timeout catching code every time this service is called...
  - zzzcpan 8y ago
    Typically you make an abstraction for all those timeouts, retries and errors. It can look just like a normal function call and have optional arguments for timeouts.
- zmmmmm 8y ago
  You're blurring the lines a bit between the true definition of microservices (eg: no shared schema, data structures, etc) and just a sensible deployment architecture. If their runtime state is independent then there is nothing stopping you taking your monolithic code base and deploying it N times, for as many independent end points as you want. That way service A crashing is never going to bring down service B, but they can still share code and data structures. The real question is, do they have shared runtime state? If they don't, you can do the above, but if they do, moving to microservices won't make that go away, it might even make it harder to deal with.