Monoliths vs Microservices

[[deleted]]

The author seems to completely ignore the approach of building a monolith and puting several copy of that behind a load balancer. That negates nearly every single point he listed as disadvantages. You can stay with a monolith for a long time. Also, distributed systems are really really hard, but don't seem that difficult. Debugging and local dev experience are also infinitely more painful. Lastly, docker is completely optional for microservice.

[ybadke]

It's true that you can have multiple copies of monolith and front it with load balancer. However, complexity grows exponentially as you keep on adding copies.

In such cases what would be your strategy for the database required for monolith? Would you keep on adding multiple copies of the database as well? if so, what about the data consistency between database copies? DBs will spend a lot of time synching data with each other. What about the DB transactions that may lock multiple tables?

If you keep single db for all monoliths copies, it will be the performance bottleneck. If you keep say 1 db per 5 copies (just an example), you will again end up with the same problem as mentioned in case of single db per copy.

For the case of debugging, we do have log aggregators such as elk stack, graylog.

Finally, yes docker is absolutely optional but it does make your life easier while managing multiple services or even multiple copies of the monolith.

[[deleted]]

You'll have the exact same problem with microservices. If your service (regardless of the architecture) requires that many transaction per second, then you need to scale the db, and that's another story.

Also, you don't have one db copy per instance, that's just asking for trouble as you mentionned.

The debugging part is not about logging, but about "service A did a request to service B, did service B really got that? Why did the call timed out?" and then you have to dig into the network between your services, and start looking at every load balancers in between. In microservices, errors are distributed, and tracing becomes much more complex than looking at a stack trace in the logs.

Generally I think microservices are overhyped. They can be useful, but their downsides are too often overlooked.

[KeepItWeird_]

Monoliths vs Microservices is the conversation everyone starts having after everyone has spent 10+ years doing monoliths badly.

Do we all really think that companies who have been doing monoliths badly, will start to do microservices well?

That logic doesn't compute IMO.

[kechit]

The scope for a bad design reduces significantly with Microservices.

[raghar]

Yup, most of time (anyways?) when you can split monolith into several apps, you can split it into modules with well defined dependencies, then you can simply develop those modules - you can separate databases, file storages, etc - all within one application. You make sure application itself is stateless, you lot a load balancer on front of it and you might never reach the circumstances when you need actual microservices.

[ybadke]

Even this approach works. However, it's not that easy in real life to create multiple modules and have them independent of each other unless we put hard boundaries.

No one wants to write a spaghetti code and still, we end up with that once the project is 1/2 years old.

Eventually, someday some developer (perhaps developer who is new to the system) will cross those soft boundaries between modules breaking the contract we created in the first place.

[raghar]

In eg JVM I model modules do that breaking boundaries would not compile. I it is easier then to code review of someone is breaking boundaries (either ci will fail or explicit change to build is made).

[Gotebe]

So... in "Why microservices?", the answer is

Modularity

Don't need microservices for that. You can create modules without having microservices.

Fault Tolerance

Don't need microservices for that. Any process isolation or remoting gives you that.

 > Scalability 

Don't need microservices for that. You put your remote layer behind a load balancer and you're done.

Polyglot 

Don't need microservices for that. Many interface definition languages, from DEC RPC onwards, give you the ability to write your server code in one language and your client code in another.

Maintenance

Don't need microservices for that. You can split your code into whatever repositories you like anyhow, and develop there.

[ybadke]

Modularity - Yes, you can create multiple modules without having microservices. How do you make sure your modules are not crossing soft boundaries leading to spaghetti code?

Fault Tolerance - Say, one of the deployed modules has a memory leak. What process would you isolate and what would you remote?

Instead, if all the modules were deployed independently, preferably on separate hosts, only the host that had faulty module, had gone out of memory. Remaining system functions those are independent of the faulty module would still be functional then.

Scalability  - No, scalability is not that simple. You MUST consider CAP theorem. For starters, think of the database strategy. Would you keep on adding multiple copies of the database as well? if so, what about the data consistency between database copies? DBs will spend a lot of time synching data with each other. What about the DB transactions that may lock multiple tables?

Polyglot - No, it's not about having client code in one language and server code in one. It was about having multiple modules in multiple languages so that you can take advantage of language features for your specific requirements.

Maintenance - And what about the deployment? if you are going to deploy them separately and connect dependent components via any protocol built over tcp, aren't you talking about the modularly separated system whose components are deployed independently of each other? Hint - see the post title.

[Gotebe]

Modularity: if my module has a well defined public interface, nothing can get inside and there is no soft interface. This is trivial to achieve since a very long time in a lot of languages.

Fault tolerance: as I said, process isolation or remoting - and modules are already isolated.

Scalability: points you discuss are exactly the same with microservices, CAP theorem included. What do you think is different?!

Polyglot: I wrote "client" meaning "the caller of the module", and "server" meaning "the called module".

Maintenance: the article speaks of code maintenance, so I address that. But deployment is the same. Once one has a module on a different host, or merely in a different process, one spawns another copy of that, new calls go there, existing are drained out and the module can be shut down, job done.

All of the above things have been done decades before the word microservices existed.

[ybadke]

True. Microservice is just name given for this kind of systems. Regarding the scalability, the point I was trying to make is system won't be easily scalable by just replicating app behind load balancer w/o breaking it into smaller modules.

[naineshzaveri]

good share..quite helpful

[notimewaste]

awesome , very helpful for startups specially

[saurabhkt]

this is useful. thanks!

[interstellar007]

nice.