There are probably thousands on Github for the use of teeth-cutting like in the blogpost. I've made one. You just lose interest when you impl the easy/naive stuff and need to actually use a real solution in production.
Apache's httpd is perfectly good as a web server, and passable as a proxy. I can't say that it'd be my first choice, but I'm not aware that there's any special reason not to use it.
The Byzantine config file syntax was a common complaint shared by the early defectors to nginx. If I never have to edit that conf file again it will be too soon.
Several of those are ingress routers, and I’ve seen no claims of those being able to run standalone (ie without specifically k8tes) so they are technically load balancer, except they can’t operate standalone. Say I wanted to run one per server instead of NodeJS cluster mode. I could not substitute those, right?
One is F5 which nobody says anything nice about anymore, and was positioned as a hardware solution for most of its good years.
I’d also note that a number of these are pretty young, indicating that there was a power vacuum that is now filling in.
I'm thinking of a "load balancer" that charges for basic features like querying for which downstream servers are in service..
HAProxy on the other hand has been doing some really fantastic stuff lately that is in the open source. It makes me a bit sad that the former is the "go to" and HAProxy doesn't get the usage it deserves.
To your specific point though I think it's just super tricky to get all the features people expect at the performance they expect as well. You essentially need to implement an very efficient HTTP server, also apparently not trivial, in order to get expected Layer 7 features.. Embedded scripting language support is quickly becoming de facto.. Simple traffic proxy/forwarding is the easy part but getting something competitive together feature and performance wise feels way beyond teeth cutting?
EDIT: Using golang as an example. You would need to either piggy-back the best HTTP server available for your language platform or write your own. The stdlib Golang http server is not competitive performance wise. The reasons for this are pretty well known and seem to be largely accepted by the core team(AFAICT). This won't impact most app and service developers too much, but for an LB service the number of cycles it leaves on the table my not be acceptable at all.
I’m dealing with some people that have some sort of existential dread of haproxy and I can’t get them to admit why they won’t use it. I’d send them to a therapist but I’m not their boss.
Yup. It's also famously incompatible with the wider ecosystem because it's not a drop in replacement for net/http. There are other criticisms I haven't really looked into as well.
Not meant to be my own criticism, just an observation. I believe the net/http interface ossified its own design decisions making it hard/impossible to be compatible with?
And yet we have only a handful and one of the most popular charges money for cool features and does not appear to have an ABI for addons.