[foxylion]

I don't get it. When you limit the memory of the java process it will be a _lot_ lower. A spring boot server can be started with -Xmx64m. Setting the memory limit to 200mb is more than enough to prevent OOM kills in Kubernetes.

We run many spring boot services in that way. With absolutely no issues.

Edit: just checked it, -Xmx32m is also usable.

[empthought]

> A spring boot server can be started with -Xmx64m

That would have required the author to read the manual and think about their problem for a few minutes, which is much less fun than justifying their already-formed preference after the fact.

[emforce]

I believe I addressed this in the 4th paragraph of this article. I can't imagine many teams going back and optimizing their memory usage after they've deployed something to production.

Unless you have capacity in your sprint to do some fine grained optimization of these things you'll most likely be looking at extending the platform or picking up potential feature requests.

But even still, the point still stands whilst not to the same extreme. You have to actually to set this flag in order to reduce 64MB which is still 60+ times the size of a similar Go service and 3-4 times the size of a thin Java/Python application.

[foxylion]

What you forget is: You get so many features with Spring Boot and you can actually use them without increasing the memory footprint.

Yes of course, for a single service with one endpoint that does nothing it is bloat. But which microservice does nothing?

Think about a database backend, actuator endpoints, etc. They are all possible with a memory footprint of ~200mb. It can be less is you use another language, but I doubt that Go will give you such a major framework for developing a microservice. And this will save you a lot more time than taking an hour to reduce your memory footprint.

And one thing you missed too: Using the JVM should also be combined with a basic knowledge about how the heap works. And if you do not limit it, it will get a lot bigger than required, this should be common knowledge. Comparing this to Go it seems like a much better way. In Go there is afaik no way to limit the heap. In worst case it will grow and grow and grow.

[mmargerum]

Go comes with pretty much everything you would need for micro services in the standard library and linking those parts in isn’t likely to change the memory profile very much.

[empthought]

Not really seeing anything in the Go standard library for https://docs.spring.io/spring-boot/docs/current/reference/ht..., most of which we need for microservices.

[empthought]

> I can't imagine many teams going back and optimizing their memory usage after they've deployed something to production.

After your two years in the industry, I am surprised that you can't imagine someone changing a command-line parameter in a configuration file.

[mping]

You lack imagination :) what I find hard to imagine is many teams going back and forth between microservices in go, java, python because of memory consumption.

Besides, every decent Java dev knows that it's a memory hog, comparing to most of the platforms out there; but that normally isn't a concern when you choose something Jvm based.

[empthought]

> You have to actually to set this flag in order to reduce 64MB which is still 60+ times the size of a similar Go service and 3-4 times the size of a thin Java/Python application.

This is a pointless way to evaluate alternatives, though, because you'll never beat BCHS[1].

[1]: https://learnbchs.org/start.html

[cosminaut]

The setting of the JVM arguments is so simple and easy, I can't imagine that it would take that much sprint work apply them.

[foxylion]

Yes... But such blog posts are terrible. They share bad knowledge and so many people trust such blog posts and make decisions based on this.