21

One of the common arguments for using microservices is better scalability. But I wonder whether this argument is really valid.

Lets say we had an application consisting of 10 microservice with 9 of them having each two instances (for redundancy) and one of them with 4 instances to handle the load (scalability). The pro-microservice argument is then that you are able to scale this miroservice indepently from the other services.

However, lets say all 10 microservices were modules in a single monolith and that several (e. g. 22 like the sum from above) instances of this monolith were deployed. The system should be able to handle the load for the one critical part, because there are enough instances to do so. If instances are containing program logic not needed, the only downside would be, that the binary and the amount of needed RAM would be slightly larger. But then again, the difference shouldn't be too big in most cases - at least not compared to the rest of the stack (think of Spring Boot). The upside of a scaled monlith would be a simpler system without (most of) the fallacies of a distributed system.

Am I missing something?

Improve this question
4
  • 3
    How big of a monolith are you talking? Because I think that it could be more than a "slightly larger" amount of RAM. Not to mention deployment time - fixing a bug could take 22 deployments instead of 4. But maybe your monolith is small and deployments don't take a lot of time, database migrations don't take a lot of time, and so on.
    – Thomas Owens ♦
    Jun 8, 2017 at 13:32
  • I havent counted lines of code, but the monolith would have several thousand lines of code (not a giant system). The starting point of my consideration was that the size of the actual application code is tiny compared to big frameworks like Spring and Hibernate. The number of deployments could actually be less then with microservices, because if you had 2 instances you would have already basic redundancy and more instances would be for scalability.
    – deamon
    Jun 8, 2017 at 13:42
  • @deamon Be aware that with the monolith approach there is no parts of the code that is totally dead on each instance, just rarely used code. Now, the code itself may only consume a small amount of memory, but if it uses a lot of objects chached in memory that amount can grow substantially.
    – Frank Hopkins
    Feb 5, 2019 at 13:34
  • Note that the overhead of basic "getting it run code" isn't necessarily as large as you might know it from your Java applications where often the whole jvm is part of the service image.
    – Frank Hopkins
    Feb 5, 2019 at 13:43

3 Answers 3

Reset to default
26

The point of microservices is not to reduce processor load. In fact, because of the overhead of communication and repetition of functions that used to be global utility code, it usually increases processor load somewhat.

The point of abolishing a monolith is much more to be able to maintain, deploy and run a complex system of functionality at all. Once your system reaches a certain size, compiling, testing, deploying etc. a monolith becomes just too expensive to be feasible while maintaining a decent uptime. With microservices, you can upgrade, restart or roll back a system piecemeal.

Make no mistake, we don't write microservices because it's inherently a better solution to couple things loosely over remote interfaces. In fact, the loss of strong type and consistency checking that a monolith could provide is often a major drawback. We do it because we have to because complexity has gotten the better of us, and are making the best of a suboptimal situation.

Improve this answer
6
  • 2
    Agreed. The reason to move to a microservice architecture is mostly political. Distributed load, decoupling are consequences, not causes. The real benefit of the microservices is at the SDLC and the Governance. On top of this, the architecture is the logical response to a need which in most of the cases comes from the company's market strategy. The time-to-market is shorter than monolith architectures so the company is allowed to adopt new strategies, shift from one to another smoothly and quickly
    – Laiv
    Jun 8, 2017 at 14:14
  • 8
    That's why someone shouldn't go straight to microservices for medium and small applications, too. The overhead and added complexity to the system may very well end up costing more time, money and quality than a monolithic system, on those scales.
    – T. Sar
    Jun 8, 2017 at 18:28
  • »We do it because we have to because complexity has gotten the better of us, and are making the best of a suboptimal situation.« Yes. For me, that nails it!
    – Thomas Junk
    Jun 8, 2017 at 20:23
  • 2
    @ewan You can use more than one computer with monoliths, too.
    – deamon
    Jun 12, 2017 at 6:21
  • 1
    I would contest the last line. Microservices don't reduce complexity, they add it. However, they can be used to strictly enforce separation of concerns, if your team cannot achieve that within a monolith as it's always too tempting to just break the implicit separation lines. Microservices mainly do make operations on a big scale easier with respect to monitoring, they enable partial updates and yes, scalability with respect to memory and replacement of individual components while the system keeps running. They also make it easier to split work into different teams.
    – Frank Hopkins
    Feb 5, 2019 at 13:40
3

You are mostly correct. If you have quick services which are loaded equally you might as well install them all on all the boxes. It isn't as 'nice' as having a box per service, but it does save money.

However. as soon as you have an imbalance, say service 5 takes 100% of the cpu for 2min, you want to move that service onto its own box so that it doesn't block all the other services if it runs.

If calls to service 5 time out due to load, only some functions of your app will fail instead of all.

Now you could do the same thing with a well modularised monolith. Install all the services, but only route service 5 traffic to one of them. While not routing service 5 traffic to the other boxes.

But usually monoliths by their very nature are not a loose collection of services that happen to be installed on the same box. There will be in memory calls between the modules which will cause the failure of the app.

Improve this answer
1

The point of micro services are 1) separation of concerns and 2) distributing load. Essentially this frees us up to make the best black boxed service we can with technologies specific to that task. Our services can be polyglot -- that is written in different programming languages on different stacks. Different teams can work on each service with no knowledge of how the others work beyond the contract of their api. This, taken as a whole, allows for a much simpler code base for each service which is easier to debug, understand and tweak for performance.

Improve this answer
1
  • I agree partly. My point was not about arguments for microservices in general, but about scalability. In my specific case the microservices are all written in the same technology, for example. So while it would be possible to use a different technology for each, it is simply not the case here. I wanted to verify that I don't miss an important point about scalability.
    – deamon
    Jun 9, 2017 at 6:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.