Not a personal blog: this is Wikimedia's public Grafana instance, showing Wikipedia traffic, database, CDN and TLS statistics.
HN links it as a public dashboard for checking Wikipedia traffic and outages, and as an example of an open Grafana instance.
The biggest benefit to dropping TLS 1.0 and 1.1 is that modern AEAD ciphers are only supported by TLS 1.2 and above. In TLS 1.0 your only options are the hilariously-broken RC4 or block ciphers in CBC mode, which is a perennial source of padding oracles (several new ones were just discovered earlier this year[1]). By setting TLS 1.2 as your minimum you can also require the use of AEAD ciphers as Mozilla's new guidelines recommend. (In theory you could support different ciphers with different TLS versions but I don't know how many people did that in practice.)
The Wikimedia Foundation has a dashboard showing TLS statistics for their services[2]. As they run one of the most popular websites on the Internet I think this data can be considered to be representative of clients on the public web. That dashboard shows 99+% of connections use TLS 1.2 and only 0.5% of TLS 1.2 connections use non-AEAD ciphers. Now, for someone operating at the scale of the Wikimedia Foundation dropping TLS 1.0 and 1.1 is probably not a good idea right now, but for smaller sites (particularly sites that are non-commercial/non-monetary in nature) it should be just fine.
Servers have already been dropping TLS 1.0 support for years now. According to SSL Pulse[3] only 67% of servers support TLS 1.0 compared to 95% support for TLS 1.2. At its peak, TLS 1.0 support was at 99%. If you want to continue using ancient software with the modern Internet you should probably use a modern proxy server anyways just…
60 Gbit/s of continuous traffic is a lot. If I'm reading the graphs right, Wikipedia "only" has 13.4 Gbit/s of outbound traffic [1]. Of course still well below the single-digit Tbit/s traffic of large internet exchanges [2] [3], but still unexpectedly large.
[1]: adding up the outbound numbers for each datacenter: 1.888 + 8.003 + 810 + 1.958 + 807: https://grafana.wikimedia.org/d/000000605/datacenter-global-overview?orgId=1
[2]: https://en.wikipedia.org/wiki/List_of_Internet_exchange_points_by_size
[3]: Not 100% correct as thanks to Corona, ix.br now has passed 10 Tbit/s peaks. https://ix.br/noticia/releases/ix-br-reaches-mark-of-10-tb-s-of-peak-internet-traffic/
You don't need resources if you are small and unknown. Run it at your house until you have a few thousand users, and then move to something like Hetzner (if you're one of those Swiss people with 25 Gb/s Internet, skip step 2). If I'm interpreting their grafana[0] right, Wikimedia gets ~20 edits per second and usually peaks less than ~200k requests/second across all projects, and it looks like traffic has not exceeded 7 Gb/s over the last 90 days across all data centers. Even the largest projects are not a lot from a technical perspective these days.
[0] https://grafana.wikimedia.org
Based on all the monitoring I've ever seen, the stats for Varnish would be the requests into Varnish.
If you wanted actual requests into the app servers you would look at those stats, and from that site, it's like ~5k req/s.
https://grafana.wikimedia.org/d/RIA1lzDZk/application-servers-red?orgId=1
I'm not sure why you think 100k req/s is low for Wikipedia
Wikimedia is unique in running some of the most popular websites with open access to almost all systems. As someone who has never been on the inside of FAANG, I found it rather interesting to browse around the backend infrastructure.
See, for example, their statistics at https://grafana.wikimedia.org/d/000000102/production-logging?orgId=1&refresh=5m
We're very transparent (I work for the Wikimedia Foundation).
You can see the specific dashboard for the Page Preview feature here (Last 6 hours):
https://grafana.wikimedia.org/dashboard/db/eventlogging-schema-jumbo?orgId=1&var-datasource=eqiad%20prometheus%2Fops&var-schema=VirtualPageView&from=now-6h&to=now