For what I am working on a deployment takes a couple of seconds including controlled shutdown and startup of the application.
I don't know how fast docker/jib would be but I am imagining this would be a somewhat heavier setup?
> [JRE version] would change very rarely.
It's optimizing for setting up new machines and having everything about how to run an application contained within that application itself rather than relying on sysadmins to `yum install` things or whatever. Plus with docker you always run the same version in prod that you do in dev (and on your local machine) unless you intentionally do something else.
> I don't know how fast docker/jib would be but I am imagining this would be a somewhat heavier setup?
Not really - a layered docker image may have tomcat as a base layer and then the app jars etc layered atop. Deployment is just downloading a new layer which wouldn't really be any overhead atop of just the jars.
Up to a very limited point. JVM backward compatibility is very good so you can do global version upgrades with reasonable confidence, and the JVM is such a common requirement (in the context of being a java shop) that including it in the base system image makes sense.
> plus whatever file-system resources like logging locations etc.
It's very much doable to get these down to zero (e.g. using remote logging), and I find it's worthwhile.
I upgraded a whole java shop to java8 and it was not a fun experience having two JVMs on the same machine and all the different tools thought they knew which one was the correct one but none of them agreed (it wasn't as simple as setting JAVA_HOME).
All of this java tooling/versioning is simple in theory since java is a pretty simple ecosystem (compared to something like C++ or even python to an extent), but there's so many layers of indirection in a modern build & deployment system that it's really painful to debug when some tool somewhere sets its PATH incorrectly or doesn't respect JAVA_HOME or symlinks or....)
If the apps had been docker-ized there wouldn't have needed to be a JVM on the host machine at all, and teams could come in and use java9 or whatever without having to work with SREs/devops to upgrade the machines and worry about whatever other apps may be using those machines or virtual-machine images.
I agree that having two JVMs on the same machine without something like docker can be problematic, but in my experience there's no need to ever do that - the backwards compatibility is good enough that you can just replace the old JVM with the new one.
I mean, if you're worrying about this kind of thing shouldn't you also worry about whether apps are built against older versions of docker? How easy is it to have two different versions of docker on the same machine and make sure that docker upgrades don't impact other apps running on those machines?
When I a deploy WAR-file it, it is fairly small (just app + dependencies), and startup / shutdown is well-defined and happens fast, allowing me to update an application with just a few seconds downtime. But here - how fast would an update be? How much downtime? Does it reinstall the os, the vm, the app, are the shutdown / startup operation well defined or does the process just get killed?
Wouldn't it take quiet a bit of work just to match what you get out of the box in a traditional setup?
If there is a problem with the new code, just point the traffic back to the working container and kill the new container.
> Does it reinstall the os, the vm, the app,
No. First, "reinstall" isn't the right word. The "OS" is baked into the container. There is no vm, Docker is not a vm. It doesn't re-install the app, it's starting it up in a new container. All your deploys are likely doing is pulling a new container image or layer (about the same size as your war) and calling `docker run` which could be more or less the same as `java -jar...`.
> are the shutdown / startup operation well defined or does the process just get killed?
There is a well-defined container lifecycle that iirc sends SIGTERM by default. This is similar to what systemd or similar would do.
Your layer, the top most layer, might have only your JAR. Assembling and deploying your container could be very fast -- but docker takes care of that. You could organize your container so that you have a layer with your Tomcat. Another layer with your JVM. Then you can easily swap in / out layers to define different versions of your container.
Whoever deploys your container on a server doesn't know or care what technology you use. Java, Python, etc. They just plug in the container and it runs. (Docker assembles its layers.)