I was honestly wondering if this would happen. This is very interesting. I think we might start seeing Pingora in the wild considering its been battle tested in production by CloudFlare, maybe not overnight adoption, but I wont be surprised if in 5 years the landscape has changed somewhat. It's really hard to argue against something Cloudflare is using in production across many regions.
I'm not saying every single site in the world will be on it, but definitely wont be surprised if the number of sites not hosted by CloudFlare using Pingora increases.
That's what I mean is I can see various projects (whether stacks or even applications) built around Pingora in the coming years.
Thanks for that link, definitely checking it out.
> Today we are announcing plans to build a new high performance and memory safe reverse proxy in partnership with Cloudflare, Shopify, and Chainguard.
That is a strong start.
Edit:
I wonder how long before other major cloud players join in on building River. I could see the value in other players like Google, Microsoft or even Amazon investing in this tech.
After reading that original article, I'm wondering how HAproxy would have stacked up against Nginx. It seems much more suited to their use cases. That said, I'm all for new infrastructure built in Rust, and it's cool Pingora is set up composably so you can build your own LB/proxy without having to implement everything from scratch if you want to.
I worked at Cloudflare, but long ago, and not on this sort of thing.
Cloudflare has extensive experience with both of these things, including employing Mike Pall for a time. That they've invested in Pingora instead is an interesting data point precisely due to that deep expertise at scale.
As they say in the link that started this subthread:
> In production, Pingora consumes about 70% less CPU and 67% less memory compared to our old service with the same traffic load. The savings come from a few factors.
>
> Our Rust code runs more efficiently compared to our old Lua code. On top of that, there are also efficiency differences from their architectures. For example, in NGINX/OpenResty, when the Lua code wants to access an HTTP header, it has to read it from the NGINX C struct, allocate a Lua string and then copy it to the Lua string. Afterwards, Lua has to garbage-collect its new string as well. In Pingora, it would just be a direct string access.
Nginx is the most popular webserver used on the internet, it's used by major CDN so it is even more battle tested.
I don't see a reason why there would be a mass adoption of Pingora since it's just a proxy and there are other very rock solid solutions with more features. ( Nginx and HAProxy ).
I think you'll see a general sentiment among many of, "if it's good enough for Cloudflare, it's good enough for me."
Fitting Cloudflare's needs is not exactly a low bar, considering how much web traffic they route/serve.
Nginx and HAProxy are amazing products that I use every day. But this has merit that's worth interest. I can write my own Rust code for a slim and custom fitted Nginx for my specific use case with this. I think we'll soon be seeing other products like kubernetes Ingress controllers built with the Pingora framework in the near future that start stealing some of the spotlight from Ingress Nginx and family.
The leadership/ownership of nginx has changed, so the nature of the project may or may not change with it. In its day Apache seemed unstoppable as well. Only time will tell.
They don't seem to be quite the same thing since Pingora is more customizable for more work. It reminds me more of YARP, a C# reverse proxy from Microsoft.
So it looks like they are intending this more as a framework that you build your own custom proxy on top of for your team/company. So you just extend the conf for your custom filters and then you add the wrapper systemd Service.
I might try wrapping it in an envoy style service as a weekend project and just dockerizing it, seems pretty straightforward.
- not friendly enough for my script-based deploys -- in particular the story around letsencrypt certbot having to edit my nginx config to inject the cert paths and some other things. I want my program to be a deb package that just puts HTTPS proxy config as a config file somewhere and the rest to "just work"
- error reporting is quite unclear in my taste, and I'd love to see a "trace" mode where you can debug your misconfiguration
- integrating with kibana/grafana requires NGINX PLUS and/or some hacks
really curious how this will impact workerd. with these two there seem to be mostly a good supervisor/ orchestrator missing to have a full serverless stack.
Then there’s docs on the request phases here: https://github.com/cloudflare/pingora/blob/main/docs/user_gu...