4 ms·

I generally agree, but I'd make a bit of a distinction that doesn't mean making a pure monolith, you can still spinoff dedicated services where it makes sense w

I generally agree, but I'd make a bit of a distinction that doesn't mean making a pure monolith, you can still spinoff dedicated services where it makes sense without adopting a a full "microservices architecture".

Waterluvian 8y ago
I found this to be true with auth. Big monolith but I split off auth, which made using a single user authority much easier for all kinds of stuff that wanted nothing to do with the rest of the monolith.
- paulie_a 8y ago
  There are definitely some services that can be self contained and if it is a legacy codebase, modernized in an isolated way.
  - beaker52 8y ago
    And Domain Driven Design can help you understand which parts are the best candidates
karmakaze 8y ago
I specifically agree. The 'where it makes sense' has to be based on something practical, not theoretical nor in-the-not-immediate-future. Currently in one of our products we have 4 back-end services: webapp, api, relay, and broadcast. The scaling requirements and lifetimes of the relay and broadcast instances differ. The relay also has audio requirements. It all depends on your environment and the teams ability to deal with what's required.
edvinbesic 8y ago
Thinking about micro-services as a scaling solution is only ever looked at from the orchestration perspective for some reason. Most of the lessons there can be applied to scale your code as well so that you can spin parts of it off with ease. This also has the benefit of giving you a cleaner & more maintainable code-base so there is still a gain even if you never spin anything off, which could be argued was the problem in the first place. This is perhaps the best bang for your buck until you actually know what the bottlenecks are as it otherwise becomes a brute-force approach to "scale everything individually". Unfortunately "our code is ready to scale" doesn't quite sound as cool as "we run a thousand micro-services".

Waterluvian 8y ago

I found this to be true with auth. Big monolith but I split off auth, which made using a single user authority much easier for all kinds of stuff that wanted nothing to do with the rest of the monolith.

paulie_a 8y ago
There are definitely some services that can be self contained and if it is a legacy codebase, modernized in an isolated way.
- beaker52 8y ago
  And Domain Driven Design can help you understand which parts are the best candidates

karmakaze 8y ago

I specifically agree. The 'where it makes sense' has to be based on something practical, not theoretical nor in-the-not-immediate-future. Currently in one of our products we have 4 back-end services: webapp, api, relay, and broadcast. The scaling requirements and lifetimes of the relay and broadcast instances differ. The relay also has audio requirements. It all depends on your environment and the teams ability to deal with what's required.

edvinbesic 8y ago

Thinking about micro-services as a scaling solution is only ever looked at from the orchestration perspective for some reason. Most of the lessons there can be applied to scale your code as well so that you can spin parts of it off with ease. This also has the benefit of giving you a cleaner & more maintainable code-base so there is still a gain even if you never spin anything off, which could be argued was the problem in the first place. This is perhaps the best bang for your buck until you actually know what the bottlenecks are as it otherwise becomes a brute-force approach to "scale everything individually". Unfortunately "our code is ready to scale" doesn't quite sound as cool as "we run a thousand micro-services".