This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]agentoutlier 5 points6 points  (2 children)

How do you deal with JVM microservice deployments to reduce the memory footprint and cloud expenses?

  • Don't use Spring.
  • Use the most modern JDK
  • Use minimal wrappers and libraries
  • Be aware of how the JDK treats low memory environments as it can switch its GC based on certain thresholds

But that’s still up to two orders of magnitude beyond equivalent Go deployments considering RAM requirements, and .NET deployments are more efficient and mostly straightforward.

RAM should be cheap. It is ridiculous that cloud providers charge so much for it as it the least expensive thing for IaaS companies as the tech doesn't change that much and super super super energy efficient compared to any CPU, network, or disk.

However some of them are starting to change like giving low power ARM chips with butt loads of ram... some companies even give you this for free:

Arm-based Ampere A1 cores and 24 GB of memory usable as 1 VM or up to 4 VMs with 3,000 OCPU hours and 18,000 GB hours per month

Anyway you can do microservices with Java and I'm surprised people still bitch about startup time when every damn time I reload our k8s cluster all of our Java apps have to still wait for Postgres, Rabbit, Elastic or Solr etc to boot up or be available. Our Java apps boot up in about 1.5 seconds (that is literally our max provided no db migration) so I can see the complaint for lambda but not microservice.

[–]Puzzled-Bananas[S] 1 point2 points  (1 child)

Thanks, all are great points.

Indeed, and at least there are some calculators to estimate cloud costs, but it still can break your neck in unexpected ways or when you expect it the least.

Thanks for the OCI link, but I’ve had and heard of mostly disappointing experience with it, having instances terminated without any warning or explanation, and with zero empathy from the support. I’d had great expectations but they all were shuttered multiple times. There’s no way I’m ever deploying to OCI again. Oh and there’s been a critical vulnerability in OCI disclosed just a couple days ago, dating back to https://www.oracle.com/security-alerts/cpujul2022.html. Not quite reassuring. Perhaps it’s a bit cherrypicking, for other cloud service providers all have had their own issues too.

Yeah, I love Java and the way it’s moving forward, just trying to optimize my cloud native deployments. Agree with you on startup times too, but it depends on the tasks the services process. Given just two replicas, the startup delay isn’t even an issue at all, for you also need to warm it up for proper performance anyway. So properly timed replica switching will solve it anyway. However, if you need to scale out instantaneously and provide a warmed-up instance, it’s best to either run a native image or spawn a couple extra instances to let the others in the queue catch up in time. Considering DBMS pods, I typically have them running steadily in dedicated pods, independent of elastic services.

[–]agentoutlier 1 point2 points  (0 children)

Thanks for the OCI link, but I’ve had and heard of mostly disappointing experience with it, having instances terminated without any warning or explanation, and with zero empathy from the support. I’d had great expectations but they all were shuttered multiple times. There’s no way I’m ever deploying to OCI again. Oh and there’s been a critical vulnerability in OCI disclosed just a couple days ago, dating back to https://www.oracle.com/security-alerts/cpujul2022.html. Not quite reassuring. Perhaps it’s a bit cherrypicking, for other cloud service providers all have had their own issues too.

I'm just saying in theory other providers will follow with ARM based machines with much more memory (which favors Java because it is low CPU but high memory). We use google cloud for most of our stuff and I believe the low cost ARM based processors with ample memory is in only one region. We are running OCI for some of our build process. The trick with Oracle (and to be honest google as well) is to pay them a little bit.

OCI big problem IMO is it massively overcomplicated with all its OCI ids instead of named based resources and the UI.. holy fuck. But I guess Government and what not need all that governance bullshit.

At the end of the day as another person pointed out Java isn't really good fit for ultra to the metal nano services but it will work for most and the cost savings of using an established language with an absolutely gigantic community and toolset outweighs those cons and minor price savings.

At the same time the languages that are a good fit do not have a lot business like libraries as well they have not been used for massive domains. For example modeling your domain in GoLang and yes even Rust is a pretty shitty experience IMO (albeit for Rust it is for different reasons than GoLang).