Hello there :wave: I'd like to throw a question to...

# server

[Christopher Hübner]

Hello there 👋 I'd like to throw a question to discourse: What is the case of using Docker in Production on Server Side Java/Kotlin applications? Isn't it running on a virtual machine already? I love using docker on development, because I can simulate the endowment it will run on very easy. How is it worth to risk that overhead on production of kotlin + docker on server-side?

[Leonardo Silveira]

JVM isn't a virtual machine the way you're thinking.

JVM virtualizes some aspects of an operating system inside a regular, single process; multi-threading to give the most notable example.

A full-feature virtual machine does something much larger, recreating several hardware aspects, going way further, virtualizing filesystem and network stack, for example.

virtualbox, vmware and qemu does it.

docker / podman does lightweight process. it'like if you software where a cake, the container image would be the nice box you put it.

so, go ahead and use as much docker as you can with your kotlin services.

[Ans Trakhtman]

I guess it depends where you are deploying and who is managing the deployment/infra. If it's a one person show, running on 1 server that you don't expect to be pulled from under you, you might be ok with installing the java that you need and using that to run the application. Although, you still need to answer the question of what will make sure your application survives server restart.

Docker is used in deployments usually to answer the same exact questions. Most cloud providers can give you a server with docker pre-installed, it's easy to get a docker-orchestrated environment (ECS, Kubernetese, to name a few). Servers are VMs today, unless you somehow have a dedicated machine, which is more expensive. Servers can be pulled from under you at any moment (even dedicated servers, stuff happens).
In this setup, docker answers the question of how fast can you get back into running your application? As fast as docker pull and docker run, if the host was suddenly upgraded from under you to a diff version of the OS, that's alright your app is fully prepackaged into an executable that has all it needs.
Changing the java version is a change within your app repo, trackable and easy, and does not affect the host, which is usually more difficult to upgrade. If a different team is doing the infra management, you are not dependent on them to have the time to upgrade the servers, you deploy as usual.
What will ensure that the app survives server crash/restart - docker orchestrator. You don't need to worry about that. No more supervisor install/configs.
If the app crashes, docker orchestrator will bring it up.
And ofc, if you use docker for both deployment and local env, you get very close to not having the "it-works-on-my-machine" case. (A.k.a you upgraded java locally and forgot to update the server or some such case).

In a nutshell, a couple reasons to deploy using docker.

[Rob Elliot]

For me the question is the other way around - given containers, is there any point targeting the JVM? Why not just write Rust? (Or Go, or Kotlin Native.)

The "write once, run anywhere" claim of the JVM to insulate you from the operating system & hardware is largely superseded by containers.

However, the JVM remains an excellent JIT compiler and has brilliant garbage collection, which are not to be sniffed at.

(Plus if you're me you're at a local maxima in terms of knowledge of the JVM, the Java standard lib & the Java ecosystem which makes switching away from it a painful prospect...)

[Daniel Pitts]

Docker doesn't require virtual machines in linux environments. It runs natively inside the system, just kind of separated from the rest of the system. Virtual Machines are a different technology, and shouldn't be confused with Containers.