DEV Community

Discussion on: Why monoliths are a long term bad idea

Collapse
 
nssimeonov profile image
Templar++ • Edited

Sorrry for the sarcasm, but and article THAT WRONG actually deserves some sarcasm.

1 - Monoliths get too big

Yes, because splitting a monolith into microservices will reduce the codebase? Ah wait - it will actually increase it and code reuse will be reduced. You will have the same thing in a myriad of losely coupled projects and without proper e2e testing you will be lost. Refactoring capabilities are dramatically reduced. My honest advice: unless you actually NEED to split the monolith don't do it. There are use cases where you have to split your code so it runs on separate servers for security, redundancy and speed and you have multiple services communicating to each-other - but once you grow beyond a certain number of users and data size - you have no choice but to do that or pay for extremely expensive hardware and we all know each hardware has some limits, so at one point you may need to split it. But don't confuse the NEED with bad design. What you propose is overdesigning and this is bad. BAD!

2 - Monoliths get old, fast...

Your point being? Everything gets old, fast. Are you suggesting to rewrite the entire codebase every 2 years just to keep it current? Or you're just complaining for no reason here?

3 - Monoliths are slow to change

HELL NO! A bigger change in business logic in a microservices architecture may involve redeployment of a dozen of services along with front-end. With a monolyth you will create a new version of a single project, not a dozen of services. E2E testing will be a nightmare and backward compatibility gets on a different level as you will have to support the versions of each of these microservices.

This leads to unhappy developers.

Microservices lead to insanity. Change my mind!
The company I work for uses A LOT of microservices because we have no choice, but this isn't because we chose not to build a monolyth just to have fancy codebase, but because of scalability - this is a whole different topic as I explained initially.

But what is the alternative?

You confuse bad code with bad design. A single file with 1500 lines of code may or may not be bad. A single function spanning over 150 lines is definitely bad. This has nothing to do with the entire application.

a rewrite will be faster and easier.

You have no idea what you're talking about. A rewrite is always problematic and you will almost certainly lose hidden functionality and will introduce new bugs. ALWAYS! I've never seen documentation good enough to describe all possible edge cases, code with extensive unit and e2e tests that cover literally every single possible situation - this is the reason why even code with 100% coverage still has bugs. We test how we expect the code to work, yet users creatively find new ways to crash it.

As long as you keep the stuff small...

Well, if we can always write small apps, but alas stuff tend to evolve. Companies grow, can you suggest the following to your boss: "Hey, this company seems to be growing too big, let's downsize it a bit"? I dare you.

The obvious problems

Yes there are problems, however instead of one problem you will create 10 new. Bigger. And since you mentioned DevOps - instead of deploying one single monolyth you will have to deal with deploying a myriad of microservices and testing the integration between them. So you need to hire 10 DevOps engineers for each that you currently have. Have fun.

PS: Sorry I just checked your linkedIn profile - 3 years of experience as software developer explains a lot about your point of view. All I can wish you is that you don't experience the consequences of the architecture you are praising. Microservices are all fun and games until you grow after a certain point, then it turns into a real nightmare.

Collapse
 
noriller profile image
Bruno Noriller

I understand your point, but mine is not about the technical part and only on the human aspect.
Since you've checked my Linkedin, you might saw that I'm coming from a business formation, I studied and worked with HR and things like that.

If you check the Stackoverflow surveys on the last years you see that some languages started paying more and more, while others, like JS pay on average less and less.

Why? As Uncle Bob says, every 5 years the number of programmer doubles (I'm not sure how valid this is, but I gonna assume this as true).
When people learn, and I'm using myself and people near me as references. We don't go learning C, Perl or Ruby. Many universities are even dropping from teaching C/Pascal to Python.
New people will learn the "new" and the "hot" languages and frameworks, and they will want to work with that.

AngularJS was released around 12 years ago and there are companies that still haven't let go of it, even as it hit the end of official support. (I know of a low code platform where it's components and everything that is offered is based on AngularJS, if you want to design custom components, you have to make it in AngularJS even.)
Angular2 is another approach and other frameworks appeared and died in between.

Their application is a "monolith" (even if it isn't really), if as time progressed they embraced the new frameworks, new components and features could have been done on other frameworks.

I know it's a nightmare to have multiple frameworks and other crazy stuff instead of one big monolith where you have all the groundwork, utils and everything else you need already done and ready to use.
(And you can mess up in one way or another, so let's just assume equivalent levels of mess.)

But, 5 years from now, let's say they continue with AngularJS, their costs will only rise, as people with the knowledge of it will only dwindle. It will also kept harder and harder to maintain, after all, now you even have to probably have a internal fork that you have to maintain.
Either that, or they would have to bear costs to train people in a framework that's 'dead', having people with lower levels of experience with a framework that will be harder and harder to learn and maintain.
I know people that used to program in COBOL, and they just don't want to work with it anymore. Companies might pay their weight in gold, but they don't want it.
So either you have people who have to start learning it from whatever source that is or you have to pay a premium to people who are able to work with it.

But now, let's say they embraced the nightmare that is to have smaller "services", the AngularJS part would be just one small part of the whole and years ago, probably even before the end of life of it, they would already had migrated it.
Or maybe, not even that! Maybe it's consistent enough to still work without problems, so there's not even a need to think about rewriting it.

Hiring people who know the new and hot stuff is easier and cheaper, the developer's themselves probably appreciate being able to use the fresh stuff than to learn some arcane framework.
People change jobs as often as they change cars, and being familiar with new technologies is something most developers want because that's the bulk of what the positions are after.

And of course, things like micro front ends is one solution for this problem.
It's now easier than ever to have multiple different frameworks in one project.

And before I diverge more, basically my whole point is about the human factor of the equation.

Collapse
 
nssimeonov profile image
Templar++

What about the human aspect? Complexity always increases as project evolves. You cannot avoid that. You can only make things worse if your architecture is inadequate.

I checked your linkedIn profile to get some idea how much experience you have in designing and maintaining software. Your business experience may give you some perspective what the business needs, but not how software works and how much effort is required to maintain the codebase and what are the downsides of some architecture decisions.

Every project has it's lifespan - this is true, so your observations on "we cannot keep using the old COBOL systems indefinitely" are correct. However it's not because we cannot find competent people to maintain them, nor because all new hires don't want to work with old programming languages, but because it's more efficient to use the new tools. As I mentioned before - money is king - if you have to pay a monthly salary to someone to create some functionality using COBOL, while using Python the same can be developed within a few hours - it's obvious what the business will prefer.

Every project reaches some state where maintaining some portions of it (or the entire project) are too expensive, so a re-do may be the better option. I'm are not talking about design flaws here (although this is a common case) but rather about the business needs outgrowing the original design. For example if we originally designed a car we may attach a trailer, we may upgrade the suspension and engine, but we cannot make a train no matter how much we upgrade the car. You cannot build a freightliner from a car although both use regular roads.

I think you get my point - if you NEED - you may redo some portion of the monolith by splitting it into a microservice and you can do that using whatever language/framework/etc. you want. Just don't do that "because it's fancy and the new hire prefers to use this instead of learn how to patch the existing code".

Nobody likes working on someone else's code. It seems easy to start over from scratch and it all looks clean, however if you go that path soon you will end with "Peter's project, Hanna's project, Joshua's project" and everyone will insist on working on their own project and not touching someone else's. The fun part starts when you get into a problem and you need to figure out where this is and apparently Joshua is on vacation and Peter left the company last year. Trust me - I've been there and done that over the past 30 years (yeah, I am a software engineer since 1992).

You want to keep the code as unified as possible and split microservices ONLY if you NEED to do that. Not because you want to do it or because "we can do it better". You should do that only if you have no other choice or if maintaining the old code is proven to be really ineffective.

Thread Thread
 
codymetzz profile image
Cody

As someone with about 6 years of software dev experience, I'm curious to know what your opinion is on when a microservice should be used. I've mostly worked on monolithic backends. Are there any resources you've found that are helpful when determining when to use one over the other?

Thread Thread
 
nssimeonov profile image
Templar++ • Edited

Here are my .2c:

The best rule to judge if you need them is: Don't unless you don't have any other option (or the costs of not doing so are multiple times higher).

Here are some valid use cases:

  1. Scalability and redundancy - obviously it's easier to have multiple small EC2 instances that perform some computation. Smaller VMs are easy to start on-demand. For example a food delivery company (Grubhub, Takeaway, Ubereats, Doordash etc) has a few "rush hours" when customers order, then it gets back to near zero. Another good use case is when you have a slow operation (CPU-intensive or communicating with external APIs) it makes sense to have multiple instances of a microserice instead of spinning off the entire monolyth.

  2. Partial redo of an old system - when you have a big old system, created over a decade ago, usually it's maintenance gets harder and harder over time. It's perfectly ok to rewrite portions of it as microservices in order to decrease maintenance costs, improve performance and implement new functionality.

  3. Memory and cache - if you have some processing that requires a lot of memory or caching (although we have distributed cache like Redis) - it makes perfect sense to extract this as a separate microservice. Implementing custom cache if you need it is ok. Multiple instances using less memory is cheaper to create than a bit less instances using much more memory. Here applies the second part of the rule - it's cost.

Please note that for all of the examples the main rule applies - you don't have any other option or it will cost you much more if you keep the monolyth.

PS: I'm sure that we can come up with more good examples, this is just what came to my mine for the brief time I decided to answer.

Thread Thread
 
codymetzz profile image
Cody

Thanks for the detailed answer! Much appreciated!