Sōzu – HTTP reverse proxy in Rust for immutable infrastructures | Hacker News Reader

Sōzu – HTTP reverse proxy in Rust for immutable infrastructures

sozu.io

81 pointslwhsiao21 comments

It's AGPL licensed which for a proxy is a strange choice. They have an unanswered question for months on what it might mean: https://github.com/sozu-proxy/sozu/issues/764

Without an answer to that if you use this and you need to make any change to it (even a tiny bug fix), you're basically opening yourself up a pile of legal issues.

Why is it weird?

Section 13 of the AGPL v3:

    "Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."

So, if you make any modification to the program, you also have to "prominently offer all users interacting with it remotely through a computer network" [a copy of the source].

Which it doesn't currently do, so do you have to add a header to every request with a download link, or what? Without any clarification from the authors they can choose to interpret the license however they like.

Even clarification may not help, the vague term is still there in the license. A legal department may suggest you avoid such a license. Usual I am not a Lawyer disclaimer applies.

Its just means that if you change the code of SŌZU you'll have to have your fork public on GitHub.. Not a big deal.

If I understood it correctly, if you change the code of SŌZU, you need to open-source not only your fork, but everything that can be reached/connected to by SŌZU.

Google has a policy against using APGL internally, nor in your company equipment[0].

    The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license.

[0] https://opensource.google/documentation/reference/using/agpl...

I don't think this true, the idea is that it triggers the same-license requirement even for network accessible code. Where normal GPL only triggers that when the code is distributed, which allowed the SAAS loophole to exist.

As for the spreading to other programs part, yes that's the entire point, if you use free code, anything built on it should be free too, to continue giving to the Free/open Eco system.

Product description says:

a HTTP reverse proxy built in Rust, that can handle fine grained configuration changes at runtime without reloads, and designed to never ever stop.

How is that immutable? Sounds like it is highly mutable by design.

Because the backend servers/containers/pods are immutable, every deployment creates new backends (that have new IPs) and then kills the old backends. This requires changing the proxy config at runtime. In the old days the backends would be mutable and would be updated in-place, keeping their IPs, so you could leave the proxy config alone.

I'm sure the OP understood. But there is fine irony in the fact that a product that sells itself as immutable infrastructure is highly mutable.

Is it irony? Immutable data structures in languages like Haskell work the same way, copies are made and then the older ones are garbage collected. Seems like the same definition applies here.

Immutable doesn’t mean it cannot be updated. It just means that updates are happening without touching the same copy. This CoW-ish style is what they’re selling.

With IP Tableflipping [1], you can have live reloads & upgrades without losing a single packet and it is not web/proxy server dependent. Also, HAProxy has live reloads and upgrades from 1.8 by transferring socket connection from the old to the new instance. [2]

[1] https://inside.unbounce.com/product-dev/haproxy-reloads/

[2] https://www.haproxy.com/blog/hitless-reloads-with-haproxy-ho...

Flash in my mind: Use `systemctl reload nginx` instead of `systemctl restart nginx` for gracefully hot reloading nginx configs.

nginx config parsing can be slow for large deployments. Or at least it could 5 years ago when we had this issue.

For all wondering sozu against other reverse proxy, sozu is capable of shifting traffic to a new backend without killing a single tcp connection. That’s extremely useful for real time video application. I met the dev team (mostly French) a couple of times, they are super nice people!

Any decent reverse proxy should be able to shift traffic to new backend keeping old connections open. Nginx can, though combination of long tcp connections and frequent reloads would cause it to keep a lot of processes waiting for old connections to finish.

I hate to be that guy but this sounds no different from linkerd.

Or HAProxy.

I'd love to see this go head to head with Haproxy.

> Upgrades without restarting: Sozu is always-up, meaning it upgrades itself while still processing requests.

How?

looks like it does the same thing as caddy, taking config changes from a socket

probably the same way as nginx http://nginx.org/en/docs/control.html#upgrade

Reply on news.ycombinator.com