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.
Fair enough, but most users won't care enough look it up and use 9.9.9.10 instead of 9.9.9.9 if they want better performance in exchange for allegedly lower privacy.
It appears 1.1.1.1 also does not pass client-subnet, atleast not by default. Queries to my authoritative from Google always includes client subnet, OpenDNS required request for whitelist. For Cloudflare its unclear.
>It appears 1.1.1.1 also does not pass client-subnet, atleast not by default.
Wow, this is actually a huge issue. Just as a simple test, I tried nslookup google.com for both 1.1.1.1 and 8.8.8.8, and Cloudflare's responses ping at about 200ms, whereas Google's responses ping at ~10ms.
That also explains the abnormally low response time of CloudFlare's solution compared to the 2nd and 3rd place solutions; the geo-location lookups require more time to reach and resolve a decision and thus represent an increase in response time from the resolver (in exchange for improved latency in all future communications to the target server).
If you have a CF PoP close to you, the absent of it shouldn't really matter. Will only have an effect for those with a Google peering much closer than CF peering.
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.
Ever since The Great Comcast DNS Outage of 2010, I've had the OpenDNS IPs burned into my memory from telling so many people.
I like the fact that you can sign up for OpenDNS and customize some of the filtering (ads, spam/malware, etc.) They used to have crappy handling of nxdomains (by default) redirecting you to a website with ads, but I believe that's no longer the case?
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?
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.