Why monoliths are a long term bad idea

TLDR: It’s not about the technical side, it’s about people!

Monoliths can be as good as anything… on the technical side, but something some people fail to consider is the Dev Experience.

People will be working with them, not only now, but in the future.

Even if you start small today, in a few years, maybe dozens or more people will have to use it… and well… they won’t like using it.

If you’re a developer… you’re probably nodding right now.

The causes:

1 — Monoliths get too big

What would you say if I showed a 1500 lines file?

You would probably be like: “What the hell?”

Even with a proper organization… dozens or hundreds of classes and functions are something overwhelming.

Then why a monolith with dozens or hundreds of files is “not a problem”? Even with a proper organization, its scope is too big to grasp.

And when you follow the usual patterns frameworks tell you to do (this applies to both front and back end), you probably have a mob of files spread over dozens of folders and subfolders that are all related to the one thing you have to use.

2 — Monoliths get old, fast…

Things get fast, and in tech, even faster.

Something from 5 years ago can be called at least outdated and something from 10 years is already ancient.

You might say something like “Java is Beatles”, but even then it’s not like you’re using Java 7 without frameworks. And if you are… then keep reading.

Take Node, for example, you can have vanilla (and with that, you have the “flavor” using Express, Koa, Fastify…) then you had Adonis 4, Adonis 5, Nest, Apollo, maybe you forgo a proper back end and use Next as BFF (or using lambdas, or Firebase/Supabase).

Possibilities are endless, and while some would be harder than others to make a monolith from… be sure someone is doing it.

3 — Monoliths are slow to change

Start that some are not even possible to change…

Sometimes the framework changes too much from one to another that it’s impossible to even think about migration…

Angular 1 to Angular 2+, Adonis v4 to Adonis v5… and what happens? Either you’re still using (and even upgrading/basing your business) in a framework that lost all official support (yes, some companies are still too invested in AngularJS) or you’re probably had to rewrite the whole thing. Maybe you’re still migrating, maybe you haven’t even finished that and are already thinking of rewriting again.

The developers:

Developers, well… they want to play with the shiny new toys more than with “old stuff”.

We barely tolerate having to use code we wrote a few months ago, imagine having to use code other people made who knows when?

Why are we still using insert perfectly good framework when we could be using the new version or new framework.

And don’t get developers started in having to choose a language… (BTW, unless you’re talking about a core business that requires something really specific or with users in the 6 figures numbers… you can probably use the equivalent of WD-40 and Duck Tape and it will work just fine…)

Finally, developers are a lazy bunch. It’s easier to just write the damn thing again than try understanding and messing with whatever you may or not have.

This leads to unhappy developers.

And unhappy developers leave. Leaving with a lot of knowledge in hopes of new green fields.

Or maybe they will push for a great rewrite… and while rewriting everything in Rust can be a stupid idea that will take too long, maybe moving a few core things from the old Ruby on Rails to Rust might be just what you need.

But what is the alternative?

As you would split the 1500 line file into multiple files (and probably in multiple folders), thinking small is probably the better idea.

Finding people to handle the Ruby on Rails monolith might be hard (and expensive), but if the ROR were just a microservice (emphasis on micro) or something inside a monorepo, then to fix it… probably even someone like me that never touched Ruby might be able to do something about it, and if worst come to worst and it starts to give too much trouble, a rewrite will be faster and easier.

And what about Svelte or Remix? Well… for the front end, you have micro front ends… so the old stuff can stay there while new stuff can be made on whatever new fad there is.

As long as you keep the stuff small…

Developers having to maintain stuff will know that the scope will always be small, some will even look up to the (possible) multiple different languages/frameworks/paradigms being used.

Others will look up to the next “new thing” since when they finish the current project being made in Next, the next one will be made on Remix.

The obvious problems

On the technical side? Yes, many obvious ones.

And I’m thinking it’s a 50/50 chance that DevOps Engineers are either thinking on hunting me down or on how fun it would be to automate something like that…

But as a developer, if I enter a new team and see a fraction of this freedom… well… what do you think?

Cover Photo by @charlybron on Unsplash