DEV Community

Discussion on: Why monoliths are a long term bad idea

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!