Any stateless service can be scaled horizontally. But the fixed cost of running the JVM is higher than the runtimes in other ecosystems (say a rust application as an extreme example). The JVM has had an outrageous amount of effort put into having it scale well for large heaps with high CPU counts.

As the OP points out, GC in java-land isn't worth writing home about on 1vCPU. When you throw a 16GiB heap at it though, with 16vCPUs then you'll unlock some of the really interesting optimizations and garbage collectors that the showcase the JVM in an advantageous light.

So it's not that the JVM can't scale horizontally - that's a matter of system architecture - it's that scaling it as 100 tiny nodes is far less impactful than having 5 large nodes.

I don't know java, but that's not the message I got from the comment. It looks like with java, 3 VMs with 2 cores are better than 6 VMs with 1 core, which may be forgotten when configuring equivalent kubernetes services.

Their point is that you can and probably even reduce cost, but you need to decide on the atomic resource unit and whether that makes sense (like having a measly single core, low ram instance/container).

I don't think you quite understood what (s)he wrote.

The problem is using JVM without understanding some basic properties of it. Scaling is a matter of how you programmed it, not the language used.