SO_REUSEPORT[1] solves this nicely in linux land. pity the JVM does not support it.
you just bind in the second server. it starts handling requests then you tell the first server to unbind and wait until it finishes handling its requests and then the first server kills itself.
"The next real step in this, and one that is really at the core of the microservices architecture, would be to cluster etcd and remove nginx completely"
Nginx is useful to stop slow clients attacking app servers, so still a useful layer to have depending on how the clojure app servers handle slow clients, etc.
I don't really understand all the complaining about JVM startup times. It's a second; usually less. Unless you're using JVM apps as command line utilities I don't see the problem.
A "hello world" Java program starts up fast, sure. But Clojure start-up time usually takes more than 1 second; it can be 10 seconds plus if you include many jars. I don't know whether that's more the fault of Clojure or the JVM.
It is clojure. Clojure literally bootstraps itself on every startup, and this bootstrap takes a little less than a second even on a fully started jvm. And since none of your clojure code can run until clojure.jar is fully bootstrapped, large clojure projects can easily start up for 5+ seconds before executing a single piece of code.
I love clojure as a language, but my code is usually cli oriented and it was such a terrible fit for it that I switched to Scala. Despite being on the jvm, my startup times are an order of magnitude better.
I have several apps that use Enlive for templating. It's an awesome library, but reading HTML, parsing it out, and producing the templates at compile-time seems to add a very notable chunk to the startup. Better at compile-time than runtime, of course, but definitely something to consider.
JVM starts in less than second also for a little bit more as "hello world" java program. But different crappy path/annotations scanning and bytecode manipulating tools like hibernate take a long time.
I think the mention of JVM start up time is a bit erroneous. A mechanism for uninterrupted service during deployments is needed whether the JVM takes a millisecond, a second or a minute to load up.
But the site is still down for some period of time, even if it's less than a second. That's unacceptable for applications with many users that are deployed many times per day.
Zero-downtime for web servers/services is very easy. In most cases. Even if the web server needs minutes to start.
It's a trickier, if you (must) have persistent connection from client to (app)server and have a state. And a lot trickier, if you will upgrade (big, xxx gigabytes in size) schema or whole relatioanal database.
you just bind in the second server. it starts handling requests then you tell the first server to unbind and wait until it finishes handling its requests and then the first server kills itself.
[1] http://lwn.net/Articles/542629/