6 ms·

One critique I have is that this presents a binary option of either full monolith and microservices. The truth is somewhere in between where you have dependent

One critique I have is that this presents a binary option of either full monolith and microservices. The truth is somewhere in between where you have dependent services large enough to warrant being their own monolith being split off. Breaking up of a monolith is almost never (anecdotal observation after 15 years of seeing this argument surface in every company I've been in) a technical need, but a combination of organizational and business requirements. This is not to say it's never technical, just that it's rare for it to be a reason. Organizational: The teams are so huge that they prefer their own development cycle, deployment, and rollout safeguards. Business: Partitioning of products for different SLAs, which is difficult to guarantee when you have a different team introducing some bug every other week that takes down the servers.

lawrjone 3y ago
You’re right, that’s a very fair point. I should’ve made it clear that the middle ground of moderately-sized but logically separate services is very much a good world to be in. I’d actively encourage splitting a monolith into services when the candidate split would be: 1. A service that has a clear purpose that can be explained either separately from the monolithic whole or as a complementary piece 2. It will receive enough active development that the cost of upgrading/on-going investment is an acceptable percent of total work time 3. It can improve the organisations state of ‘ownership’ and better align the codebase with the team structure that own it There is always a middle ground, and I should’ve done better to explain that.
npn 3y ago
> This is not to say it's never technical, just that it's rare for it to be a reason. It will be a lot more technical reason from now on, when we begin to utilize more "AI" stuff, like language models. all of those stuffs are slow to start, because they need time to load the huge model, so it is better to make a service that dedicated to the AI stuff, so the development of the business side do not get hold back by the slow restart cycle. and AI is just an example, there is a lot of case when it more reasonable to split it to another service too, for example some CPU intensive tasks. Even Erlang/BEAM can't do anything about it if the code is writing in C/Zig/Rust and get called using NIF.
devoutsalsa 3y ago
A monolith doesn’t have to be one giant ball of mud. It can be discrete, well-factored services all by itself. I recently worked on decomposing a monolith into micro services, but it felt like we were just spreading one big problem over multiple services. All of the services ended up being tightly coupled, even the the goal was to avoid that. We created a macrolith.
- stepbeek 3y ago
  And it’s incredibly difficult to work with a distributed monolith. I find that the joy I get from development just fades completely when even trivial changes involve too much faff.
- intelVISA 3y ago
  Agreed, transforming a monolith into a 'distributed monolith' just creates a different set of even worse problems, the root issues are still unsolved. Still, thanks to AWS it's vogue, expensive and probably keeps half of us employed when we have to untangle it all!
- taneq 3y ago
  Exactly! All this debate seems to stem from people being forced to work with a big ball of mud and then concluding that no one process should ever be allowed to become that big, because big processes are balls of mud. And so, having missed the real lesson (which isn’t ‘don’t make it big’ but rather ‘don’t make it out of mud’!) they build a big ball of little balls of mud.
  - marcosdumay 3y ago
    > they build a big ball of little balls of mud Nah, they make a lot of sturdy, well structured rocky balls. And let them move around a big mud soup that is outside of their sight. So they don't even see mud.
- mjr00 3y ago
  It's not about monoliths always being a ball of mud. Even the most well-composed monolith still has problems with teams wanting to do conflicting release cycles, needing clearer ownership over who has responsibility for what part of the codebase, and knowing who should be responsible for on-call for which services. And there is, of course, dependency hell, since everything in your monolith probably should depend on the same version of third-party libraries.
Olphs 3y ago
Do you think it's good idea to migrate from monolith to microservices before scaling the team? We are essentially doing this right now, I personally don't think the teams are yet large enough to warrant this migration, but leadership says that we can't scale further before we have microservices. Imo most of the problems could be solved with increased testing and knowledge about the system. The tech also could definitely still scale with just by boosting the hardware and occasional performance passes on slow endpoints/queries.
- yakshaving_jgt 3y ago
  > but leadership says that we can't scale further before we have microservices These are depressingly common alarm bells. There are companies with valuations over 12 figures which don't do microservices, so the scaling justification is dubious at best.
- iamflimflam1 3y ago
  Are you doing “extreme” micro services? A esperare database for each micro service, one endpoint for each microservice etc.. or the slightly more sensible - let’s split the monolith up into obviously independent system (very much like the article talks about).
  - hardware2win 3y ago
    >extreme microservices >separate databases Isnt it like the basic thing?
    - ohgodplsno 3y ago
      If your database isn't the performance issue and those two services spent 99% of the response time on calculating the 15755th digit of pi, not separating the database isn't a problem. Similarly, if both of your services need to fetch some user information, but you haven't created a user information service with its own database they could both talk to, having a shared database is fine. Splitting each and every service with its own database, talking to other services to access their database by default is cargo-cult behavior. All it's going to do is make it hell for you to work on those services.
fendy3002 3y ago
And one technical / business side that's very valid: error-proofing the service and database. It is to prevent the database to be populated incorrectly, such as financial data, that you proof it behind a set of well-defined API, to prevent any leakage of sensitive data (PII or credit-card info) and to be easily audited.

lawrjone 3y ago

You’re right, that’s a very fair point. I should’ve made it clear that the middle ground of moderately-sized but logically separate services is very much a good world to be in. I’d actively encourage splitting a monolith into services when the candidate split would be: 1. A service that has a clear purpose that can be explained either separately from the monolithic whole or as a complementary piece 2. It will receive enough active development that the cost of upgrading/on-going investment is an acceptable percent of total work time 3. It can improve the organisations state of ‘ownership’ and better align the codebase with the team structure that own it There is always a middle ground, and I should’ve done better to explain that.

npn 3y ago

> This is not to say it's never technical, just that it's rare for it to be a reason. It will be a lot more technical reason from now on, when we begin to utilize more "AI" stuff, like language models. all of those stuffs are slow to start, because they need time to load the huge model, so it is better to make a service that dedicated to the AI stuff, so the development of the business side do not get hold back by the slow restart cycle. and AI is just an example, there is a lot of case when it more reasonable to split it to another service too, for example some CPU intensive tasks. Even Erlang/BEAM can't do anything about it if the code is writing in C/Zig/Rust and get called using NIF.

devoutsalsa 3y ago

A monolith doesn’t have to be one giant ball of mud. It can be discrete, well-factored services all by itself. I recently worked on decomposing a monolith into micro services, but it felt like we were just spreading one big problem over multiple services. All of the services ended up being tightly coupled, even the the goal was to avoid that. We created a macrolith.

stepbeek 3y ago
And it’s incredibly difficult to work with a distributed monolith. I find that the joy I get from development just fades completely when even trivial changes involve too much faff.
intelVISA 3y ago
Agreed, transforming a monolith into a 'distributed monolith' just creates a different set of even worse problems, the root issues are still unsolved. Still, thanks to AWS it's vogue, expensive and probably keeps half of us employed when we have to untangle it all!
taneq 3y ago
Exactly! All this debate seems to stem from people being forced to work with a big ball of mud and then concluding that no one process should ever be allowed to become that big, because big processes are balls of mud. And so, having missed the real lesson (which isn’t ‘don’t make it big’ but rather ‘don’t make it out of mud’!) they build a big ball of little balls of mud.
- marcosdumay 3y ago
  > they build a big ball of little balls of mud Nah, they make a lot of sturdy, well structured rocky balls. And let them move around a big mud soup that is outside of their sight. So they don't even see mud.
mjr00 3y ago
It's not about monoliths always being a ball of mud. Even the most well-composed monolith still has problems with teams wanting to do conflicting release cycles, needing clearer ownership over who has responsibility for what part of the codebase, and knowing who should be responsible for on-call for which services. And there is, of course, dependency hell, since everything in your monolith probably should depend on the same version of third-party libraries.

Olphs 3y ago

Do you think it's good idea to migrate from monolith to microservices before scaling the team? We are essentially doing this right now, I personally don't think the teams are yet large enough to warrant this migration, but leadership says that we can't scale further before we have microservices. Imo most of the problems could be solved with increased testing and knowledge about the system. The tech also could definitely still scale with just by boosting the hardware and occasional performance passes on slow endpoints/queries.

yakshaving_jgt 3y ago
> but leadership says that we can't scale further before we have microservices These are depressingly common alarm bells. There are companies with valuations over 12 figures which don't do microservices, so the scaling justification is dubious at best.
iamflimflam1 3y ago
Are you doing “extreme” micro services? A esperare database for each micro service, one endpoint for each microservice etc.. or the slightly more sensible - let’s split the monolith up into obviously independent system (very much like the article talks about).
- hardware2win 3y ago
  >extreme microservices >separate databases Isnt it like the basic thing?
  - ohgodplsno 3y ago
    If your database isn't the performance issue and those two services spent 99% of the response time on calculating the 15755th digit of pi, not separating the database isn't a problem. Similarly, if both of your services need to fetch some user information, but you haven't created a user information service with its own database they could both talk to, having a shared database is fine. Splitting each and every service with its own database, talking to other services to access their database by default is cargo-cult behavior. All it's going to do is make it hell for you to work on those services.

fendy3002 3y ago

And one technical / business side that's very valid: error-proofing the service and database. It is to prevent the database to be populated incorrectly, such as financial data, that you proof it behind a set of well-defined API, to prevent any leakage of sensitive data (PII or credit-card info) and to be easily audited.