Splitting the workloads is a good, natural progression. The next pain point will be data boundaries. What tables are shared and joined against in different areas of the code? The ability to scale data access can be hard. As teams grow, shared understanding goes down and eventually data will get tangled together. Scaling systems is scaling data access. Scans, joins and aggregations will put pressure on the db and moving segments of data to their own data stores will be called for. Will you be able to untangle the monolith?
Keep the monolith, but split the workloads
21–30 of 161 posts
Re: Keep the monolith, but split the workloads
#22Splitting the workloads is a good, natural progression. The next pain point will be data boundaries. What tables are shared and joined against in different areas of the code? The ability to scale data access can be hard. As teams grow, shared understanding goes down and eventually data will get tangled together. Scaling systems is scaling data access. Scans, joins and aggregations will put pressure on the db and movi…
Doesn’t mean microservices is a good fit. You’ll need a team per serviceC but you don’t have the people who know the boundaries. Better keep it as a monolith in that case.
It’s far far far worse to split something up with bad understanding about the data and access patterns than to just struggle along.
Re: Keep the monolith, but split the workloads
#23One 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 org…
> 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.
Re: Keep the monolith, but split the workloads
#24> Writing code is hard enough without each function call requiring a network request
And eating food is difficult enough without all that time between plate and mouth, which is why only nutrient slurry forced through a tube makes sense! Why to scale from 20 to 200 engineers we only need to add more tubes and none of that pesky dinnerware!
This is just silly.
It's ok to like monoliths (or tubed slurry), but there's no reason to make up nonsense to justify it.
Re: Keep the monolith, but split the workloads
#25This is standard practice on monolithic apps. It is effectively an N-tier architecture. On Rails it is very expected that you would deploy the same codebase to two tiers (web and worker) and simply run rails s in one and sidekiq in the other.
Ditto in Django + Celery
Anyone using a more modern/lightweight alternative to Celery?
Re: Keep the monolith, but split the workloads
#26We used this approach in a previous project, and can work quite well in my experience. It's wonderful to be able to avoid the insanity of microservices.
Re: Keep the monolith, but split the workloads
#27One 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 org…
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.
Re: Keep the monolith, but split the workloads
#28This is standard practice on monolithic apps. It is effectively an N-tier architecture. On Rails it is very expected that you would deploy the same codebase to two tiers (web and worker) and simply run rails s in one and sidekiq in the other.
We're doing this with our monolithic Node.js / Express application as well, but I wasn't aware that it's a common pattern. For us having a monolithic app greatly simplifies development, deployment, updating dependencies, shared code, etc. Just having a single set of third-party dependencies to update makes things so much easier.
It's so common Heroku has worker dynos and cron support via the scheduler add-on.
Re: Keep the monolith, but split the workloads
#29Author here, thanks for sharing! This is a strategy I’ve used across many projects in several languages, from big Rails apps to the Go monolith we deploy at incident.io today. It’s just one way you can make a monolith much more robust without moving into separate services, which helps you keep the benefits of a monolithic application for longer. Hope people find it interesting.
Question: Have you considered one separate binary (but still sharing the entire codebase) for each "workload" instead of using a flag to switch? If so, can you highlight the advantage of the flag way?
Re: Keep the monolith, but split the workloads
#30One 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 org…
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.
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.