3 ms·
Until you have enough microservices and each microservice carries its own Go runtime. Then having one JVM suddenly isn't so bad. The problem (as someone else sa
by danieldk 11y ago
Until you have enough microservices and each microservice carries its own Go runtime. Then having one JVM suddenly isn't so bad. The problem (as someone else said) is that using Docker may not be the right solution here.
There are enough solutions (e.g. servlet containers) where you can run multiple services in one VM, with isolation, and security hardening (using security manager).
With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has downsides (typically more memory use) and upsides (upper bound on the maximum memory use of a process).
- publysher 11y agoYour remark about isolation is not entirely true: when you run multiple services in one VM, there are still a number of shared resources. Most notably, all services will share the same heap, so one ill-behaved service can bring down all the other services. The only way to prevent this, is to run each service in a separate VM. And at that point, you are once again comparing one Go runtime per service with one JVM per service.
- politician 11y ago> With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has ... upsides (upper bound on the maximum memory use of a process). If you're running a Go app in a container, you can use also tune the upper bound on memory use by restricting the available memory for the container.