FWIW I would never ever recommend running raw Erlang/OTP on the internet apart from hobby apps, I always use a dedicated load balancer (haproxy, nginx, traefik, …):

• crypto is expensive, the LB provides very efficient TLS termination without clogging up your OTP apps
• crypto is hard, the LB have this as a core priority. If you read the last 3 years of OTP related code for TLS you will see quality & valiant efforts to keep up with the status quo but it’s always trailing what the LB can provide. If there is a security issue with a mainstream LB you can be certain it will be fixed in a handful of days.
• LB are really good at doing LB. Simple things like handling blue/green deployments, switching nodes for maintenance, dealing with malicious traffic, rate limiting, are easiest done right at the point of contact with your infrastructure. If you have a LB squashing a bad user, your app can perform properly for all other users without constraints. If not, your rate limiting activities have to compete with your valid users
• when you need to update TLS certificates, or change connection parameters, you’ll not need to have to take your app down to do so.

At the end of the day, these 4 reasons are just 1 reason: separation of concerns is a good thing. Use the right tool for the job. Do TLS termination with a process that is designed fro this. Same for load balancing of end-user requests.

I wonder how this consideration of trade-offs changes when you start considering http2 and the fact that many popular LB/proxy solutions (Nginx and AWS ELB for example) don’t forward http2 - they downgrade the traffic between the balancer and server to http1.

It’s very much a case of measuring and optimising your deployment. Simply pouring HTTP2 everywhere and waiting for a significant improvement is unlikely to help much.

For example:

If you have your LB configured correctly, then you already have multiple persistent open HTTP/1.1 connections between the LB and your app server, that will remain open across many request/response cycles. There is very little gain to be had from multiplexed backend connections, and you have no TLS nor TCP setup/teardown cost.

However, prioritised streams, compressed headers, and server push can make a significant difference on the client side, and I am not at all clear how a LB impacts this yet. Some functionality appears to require end-to-end HTTP2.

Kazuho's Weblog: HTTP/2 (and H2O) improves user experience over HTTP/1.1 or SPDY has some old but useful data - 30% improvement in time to first paint, with substantial time spent configuring the server, including attempting to work around bugs in the prioritisation logic on the client side. While one hopes this has improved substantially since 2015, the inconsistent results between browsers is unlikely to have changed.

In projects like https://h2o.examp1e.net/ there are quite a few settings available to tune these, but I don’t think we have this sort of flexibility yet in Phoenix and Cowboy. It would be an interesting project for some organisation to fund.