I guess that signals it's time for nginx users to check out possible alternatives - just in case, if things turn out for the worse.
I can recommend having a look at https://varnish-cache.org/ - while its performance might not be 100% up to par with nginx in some (very, very high-end) scenarios, it has many other fortes that nginx (at least in its FOSS release version; I've never used nginx plus) just cannot match in my experience. Having seen `varnishlog` and `varnishtest` in action alone are worth spending a day or two exploring it.
The problem, of course, when all contributions are "limited" to those within the company, that the talent and expertise required to keep things going exist just in the company itself, and not in the overall open source community. So when the company behind the tech "goes away", all the knowledge does too. It's for that reason that open source that is totally under the control of one company is so dangerous. Sure, you have the ability to fork, but the reality is that such a fork is almost assuredly doomed to fail. You really are beholden to that company.
The antithetic case here has precedence too (node/iojs amongst others) -
"org realizes its share of the base tech has outlived its 'welcome' to no real financial benefit". But I guess a more pressing question is: can a corporate entity be "hands-off" enough so that its subsidiary has room to work as effectively as it had prior to its acquisition?
I don't have the wherewithal to get at these arguments from any angle (and I'm certain I'm missing many others).
Studious maintenance of the base code and branches/PRs besides build tried/true code bases and I hope that we're not being torn of that practice from this buyout; but only time will tell ...
I've replaced most of my nginx instances with traefik, except those just serving static files. The configuration is more straightforward and the EncryptIt integration is a lot more elegant than in nginx's case.
According to the public statements, F5 is committing to maintain the current level of resources NGINX has allocated to their open source programs, to keep the same dev team involved, to keep licensing as it currently is, not change any of the repositories on Mercurial and GitHub and to keep the NGINX brand.
Which only means that NGINX will get even better over time.
I guess this[1] image from the F5 article gives an idea of where nginx fits from their perspective. F5 is a huge company (4000~ employees) that already likely has thousands of boxes running nginx. If you're going to continue using nginx as a critical piece of your business you might as well secure its future.
Which is an interesting statement given that everyone I've run into associated with F5 - local reps or users - have been relentlessly hostile to "open source crap".
NGINX was already paywalling bug fixes once they launched Pro.
proxy_pass for example will only resolve a hostname at the time the configuration is parsed, unless you use a convoluted variable hack. This was a serious issue requiring you to restart your fleet if a backend server changed IPs. The bug fix for this was implemented only in Pro and sold as "DNS for Service Discovery."
I'm sure that's not the only feature it's missing compared to nginx. Envoy is not very comparable to nginx, in my opinion... but I also wouldn't reach for varnish as an nginx alternative either.
Envoy is not the web server, it's load balancer. If you want to serve static files It will be better to use any other software. Furthermore, it is a very complex problem for HTTPS servers, because the Linux kernel doesn’t have full-featured TLS support for sendfile syscall. I implemented daemon which is used as in-memory storage for static files and client for our proprietary web server. Trust me :)
The number of security vulnerabilities due to PHP's crappiness is two orders of magnitude greater than all of nginx vulnerabilities combined.
Yet PHP is a memory-safe language.
Memory safety won't fix anything by itself, it will just shuffle the shit into some other place.
Now if you're claiming that if you take nginx developers and force them to use Rust they'll somehow start writing better code, then that's a valid point. Although I'm in extreme doubt that it is realistic or even true.
Idunno, it seems fine to me. There are plenty of HTTP daemons that get the job done though, and if you have exacting requirements, there's nothing particularly difficult about writing your own specialized one (generally you don't have to write every feature of NGINX).
I can recommend having a look at https://varnish-cache.org/ - while its performance might not be 100% up to par with nginx in some (very, very high-end) scenarios, it has many other fortes that nginx (at least in its FOSS release version; I've never used nginx plus) just cannot match in my experience. Having seen `varnishlog` and `varnishtest` in action alone are worth spending a day or two exploring it.