3 ms·

Microservices are risk mitigation. If you know what are you doing - Monolith is optimal way. We use microservices, because we acknowledge that we don't know ho

Microservices are risk mitigation. If you know what are you doing - Monolith is optimal way. We use microservices, because we acknowledge that we don't know how final product would look like, and we mitigate risks associated with adding and removing unknown number of features. Facebook was creating clone of Twitter, well known product, well known path. There is no need for microservices.

boxed 2y ago
How do you lower risks of adding and removing feature if you need to not only need to add/remove the feature but also decide which service it goes in, set up coordination, and manage networks between the services? That's more work, and more surface area.
aerhardt 2y ago
I mean, can’t you decouple your modules inside a monolith just as well, if what you’re looking is to mitigate the risk of removing features?
The_Colonel 2y ago
I would actually put it exactly the other way round. If you don't have a crystallized architecture yet, prototyping with a monolith is faster. You don't have to make the cuts (this belongs to this service) which are expensive to change later (unlike moving classes between modules). Doing internal Java/.NET/whatever interfaces is easier than introducing external API (and associated infrastructure complexity, authorization, routing...), they are much easier to tweak. You have transactions, don't have to deal with a lot of asynchronicity, network overhead etc. For a prototype, I'd always rather do a monolith.
DeathArrow 2y ago
Actually for a big codebase there are always reasons to use microservices: much better scalability, easier to develop using small teams, easier to maintain, the software is more robust.
- smokel 2y ago
  There are even more reasons to use a monolith, or to simply use a service oriented architecture. Probably not necessary to repeat here, but microservices add a lot of complexity due to asynchronicity, limited interfaces, and more complex error handling.
temporarely 2y ago
Sorry, but that's just too rich. If you don't know how to design schemas (extensible, modular, ..) and don't know how to design coherent APIs around that, then yes, go Microservices to mitigate the risk. The risk here being the likely chance that you got the schema wrong and end up hacking around it in your "monolith" [almost always sic].

boxed 2y ago

How do you lower risks of adding and removing feature if you need to not only need to add/remove the feature but also decide which service it goes in, set up coordination, and manage networks between the services? That's more work, and more surface area.

aerhardt 2y ago

I mean, can’t you decouple your modules inside a monolith just as well, if what you’re looking is to mitigate the risk of removing features?

The_Colonel 2y ago

I would actually put it exactly the other way round. If you don't have a crystallized architecture yet, prototyping with a monolith is faster. You don't have to make the cuts (this belongs to this service) which are expensive to change later (unlike moving classes between modules). Doing internal Java/.NET/whatever interfaces is easier than introducing external API (and associated infrastructure complexity, authorization, routing...), they are much easier to tweak. You have transactions, don't have to deal with a lot of asynchronicity, network overhead etc. For a prototype, I'd always rather do a monolith.

DeathArrow 2y ago

Actually for a big codebase there are always reasons to use microservices: much better scalability, easier to develop using small teams, easier to maintain, the software is more robust.

smokel 2y ago
There are even more reasons to use a monolith, or to simply use a service oriented architecture. Probably not necessary to repeat here, but microservices add a lot of complexity due to asynchronicity, limited interfaces, and more complex error handling.

temporarely 2y ago

Sorry, but that's just too rich. If you don't know how to design schemas (extensible, modular, ..) and don't know how to design coherent APIs around that, then yes, go Microservices to mitigate the risk. The risk here being the likely chance that you got the schema wrong and end up hacking around it in your "monolith" [almost always sic].