12

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
  • 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 '17 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 '17 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 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 at 13:43
20

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
  • 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 '17 at 14:14
  • 6
    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 '17 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 '17 at 20:23
  • I have to disagree with the last part of the answer. micro-services are inherently better than a monolith, because they utilise more than one computer – Ewan Jun 9 '17 at 14:58
  • @ewan You can use more than one computer with monoliths, too. – deamon Jun 12 '17 at 6:21
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
  • 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 '17 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.