Microservices shouldn't run in a big machine?

Question

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?

Answer 1

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.