2

I arrived in a project and they have 2 instances of a microservice. Each instance running in a 16gb RAM + 4 CPU setup in AWS (using Kubernetes), horizontally scalling up to 4 - 6 instances at peak days, but normally, 2 instances are enough to deal with the throughput at most times.

I didn't saw any problem with this setup, but one of the architects said that this cannot be considered a microservice anymore. I asked "Why? Does it deal with multiple business contexts? Is it tighly coupled to any other applications?". He answered "No, it's because it runs in a big machine". That's the only reason he gave me and it sounded really strange to me at first.

I've gone through the monitoring of these microservices and found that it receives a huge amount of requests per second. And some of the operations take sometime (1 - 3 seconds) to run.

Ok, I did understood his point -- sometimes, when using big machines, maybe you're having resources wasted, because the actual throughtput is not even close to the potential of the machine, but, as far as I can see, this is not the case with this microservice as it deals with huge amounts of requests per second.

Does this kind of constraint exists in the microservices architecture? In my opinion, it really depends on the scenario. If the machines have their potential wasted, then it may be better to reduce the size of the machine and do horizontal scale when needed. If the machines don't have their potential wasted, then having a large machine is okay.

(And bear with me, but I don't even think that 16GB + 4CPUs is such big machine as he said)

What are your thoughts on it?

10
  • 4
    Well, there's an obvious answer to this question but it's probably not one you should say to your "architect". Oct 26 at 15:01
  • 2
    I've seen this debate happen at multiple organizations and I consider it a gray area. The "micro" in microservice refers to its architecture, not so much its resource utilization. But, a service which consumes an order of magnitude more resources than others does warrant investigation. Either way, I wouldn't get into a debate regarding semantics with your coworker.
    – Dan Wilson
    Oct 26 at 15:03
  • 1
    shrug, you are the best kind of correct, but if you have a microsevice that is using lots of CPU, is it because its doing something complex? can that complex thing be split into even smaller bits? seems an obvious point
    – Ewan
    Oct 26 at 15:06
  • @PhilipKendall . . . Now I'm curious about what is this obvious question xD. . . Oct 26 at 15:07
  • 1
    @MatheusCirillo Rearrange these words into a sentence. "About. Talking. You're. What. Clue. A. Have. Don't. You." Oct 26 at 15:08

1 Answer 1

5

There are two factors that I see at play here:

  1. Inconsistent definitions of Microservices
  2. Misconceptions based on literal interpretations of the prefix 'micro'

The first is probably the more legitimate issue to be concerned with. Here's a presentation by Sam Newman, the author of "Building Microservices: Designing Fine-Grained Systems" he gives his definition of Microservices and then says something to the effect of "if you have a different definition, that's fine, feel free to write your own book". I actually tend to disagree with that assertion: having multiple incompatible definitions of the same term is pretty much always a bad thing. I do think his definition is (or should be) authoritative. It seems to me that you are at least somewhat aligned with his definition.

There are a lot of articles and maybe even books that describe microservices as being 'small'. What makes them small can depend on lots of things depending on the person who is writing/saying such things but typically it's that there's a single endpoint per deployment. I think that's not only incorrect but also extremely ill-advised. Unfortunately, there are so many of these alternate (and at best useless) definitions being put forth that it doesn't surprise me that they people believe they are correct.

TL;DR Microservices are primarily about autonomy, especially over data. Your challenge is more about organizational politics than technology. It can be difficult to correct a more senior technical team member without creating a lot of other challenges for yourself. Good luck.

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.