bjslade

This is the approach we’ve taken with other similar systems too. Things can go so horribly wrong underneath your containers that the concept of having only one cluster in a prod scenario and maintaining it mid-air would be unthinkable.

Also agree on keeping state outside. Maybe the relevant tech will be mature sometime soon but we’ve seen orchestration bugs do nasty things to stateless containers that would have been a nightmare if state had been involved.

According to the FAQ[1], they also offer 9.9.9.10, which passes client subnet at the cost of other features.

[1] https://www.quad9.net/faq

Besides response time, the next level of comparison is how well geo-DNS-based services (global load balancing, etc.) support these resolvers. AFAIK 8.8.8.8 gives decent results in most places, though I've seen suboptimal US-centric results from Quad9 in Asia. Support for RFC 7871 (Client Subnet in DNS Queries) comes into play here too.

I too felt that Spring Boot was a response to the simplicity of Dropwizard. I worked at a place which had two opposing java camps. One was heavily into Spring Boot, the other, Dropwizard. This might not be a fair representation of Spring Boot, but unfortunately our Spring Boot crowd were card-carrying Spring-for-everything people who would over-engineer their systems to the point where a simple REST API would have thousands of lines of code, magic everywhere, mediocre performance, and present a nightmare learning curve for new engineers. The Dropwizard-based systems were far less magical and much easier to understand. Maybe Spring Boot can be just as nice, if the right people use it?