Earlier quoted context omitted.
Several companies use Caddy for exactly this purpose. Fathom Analytics for example uses it for their custom domains feature. Caddy can even reactively provision certs during TLS handshakes. It's a native feature. Why does it require lots of workarounds?
Is there any mature integration to achieve this with Kubernetes?
Migrating Dropbox from Nginx to Envoy
221–230 of 243 posts
Re: Migrating Dropbox from Nginx to Envoy
#222Re: Migrating Dropbox from Nginx to Envoy
#223Earlier quoted context omitted.
Does anyone know a good license for that? Maybe the Prosperity license? EDIT: I've just realized that I want a revenue-limited trial, rather than a time-limited one. I basically want the Prosperity license, but with the ability to say "you have to pay me if your company makes more than $100k in annual revenue". Is there a license like that? I've emailed the License Zero people, hopefully they'll do something for that…
> Does anyone know a good license for that? The "that" in question was "copyleft if your project is open, pay us if your project isn't open". For that, try the AGPL or GPL, depending on your use case and customers, and then sell alternate licenses for people who don't want to make their own code open. > Maybe the Prosperity license? That isn't an open source license, despite its efforts to be ambiguous on that front.…
The Prosperity license seems like a better fit to me, as the GPL/AGPL has a different set of constraints (e.g. customers who want to keep their code closed).
What's wrong with a license that's non-OSI "open" but gets developers paid from large companies to develop otherwise open software?
Re: Migrating Dropbox from Nginx to Envoy
#224Earlier quoted context omitted.
I've admired Drew and the early Dropbox team for getting things done and shipped even when compiled python GUIs was edgy as the initial Rails version of Twitter was. But they shipped and validated the market. Now adding all those fancy and cool tech mentioned in the blog post will increase the complexity by a lot but it's not clear what are the real benefits. Does a decreased number of machines running really justify…
With that move it is actually decreasing the complexity and improving manageability and sustainability.
If you change all tires if a running car, you are increasing complexity and risk. The blog post describes the fallacy/anti-pattern of starting from scratch. It's usually a people problem when people don't want to understand the Source of the current state and also don't want to fix it. A green field looks so much nicer than dirty plumbing. But it's wrong.
Another sign of this anti-pattern is the hyper focus on the green field solution and not to think about simpler solutions (better DevOps tooling, hire C++ developers to rewrite slower lua Code etc)
Re: Migrating Dropbox from Nginx to Envoy
#225Earlier quoted context omitted.
I think the problem with xDS is that their example go-control-plane repository is completely useless. It's overly complicated with frightening-sounding details that don't matter to someone experimenting ("you MUST MUST MUST CACHE THIS how to do so is an exercise left to the reader"). I ended up reading the specs and found them very clear, and wrote my own xDS implementation: https://github.com/jrockway/ekglue/blob/ma…
On that note, the grpc spec specifically calls for load balancing that doesn't actually do the proxying, but instead hands out assignments, with the server passing it's current load back to the load balancer service. it sounds like in this case the grpc client is using some array of xDS, but the server is using xDS along with...?
I feel like xDS is a relatively new addition to gRPC. I think there is another parallel implementation inside gRPC of external load balancing, which may convey server load information back to the gRPC client.
I looked up the current state of the xDS code, and there's a lot more of it than I remember. The EndpointDiscoveryService based gRPC balancer is here: https://github.com/grpc/grpc-go/blob/master/xds/internal/bal.... It appears to balance similarly to Envoy; locality-aware with priorities.
(That doesn't surprise me because I don't remember any field in the ClusterLoadAssignement proto that sends load information back to the client. Health, yes; load, no. But I could easily not remember it being there because it hasn't been something I've tried to implement.)
But yeah, the way to look at endpoint discovery is like DNS. DNS can return multiple hosts, and clients will spread the load by picking one at random (sometimes, if you're lucky). EDS is similar to this, but is a streaming RPC protocol instead of connectionless UDP, so it's theoretically easier to operate and monitor.
The other xDSes do more things -- CDS lets you discover services (that EDS then gives you endpoints for). RDS lets you make routing decisions (send 10% of traffic to the canary backend). SDS distributes TLS keys (and other secrets). ADS aggregates all of these xDSes into one RPC, so that you can atomically change the various config versions (whereas requesting each type of stream would only be "eventually consistent"; doing it atomically is good where route table changes add new clusters, the client is guaranteed to see the new cluster at the same time the route to that cluster becomes available).
It is all somewhat complicated but very well designed. This reminds me that I want to look more deeply into gRPC's support of xDS and add some integration tests between gRPC and ekglue.
Re: Migrating Dropbox from Nginx to Envoy
#226Earlier quoted context omitted.
> Does anyone know a good license for that? The "that" in question was "copyleft if your project is open, pay us if your project isn't open". For that, try the AGPL or GPL, depending on your use case and customers, and then sell alternate licenses for people who don't want to make their own code open. > Maybe the Prosperity license? That isn't an open source license, despite its efforts to be ambiguous on that front.…
The Prosperity license seems like a better fit to me, as the GPL/AGPL has a different set of constraints (e.g. customers who want to keep their code closed). What's wrong with a license that's non-OSI "open" but gets developers paid from large companies to develop otherwise open software?
The comment you originally responded to said:
> The model of "copyleft if your project is open, pay us if your project isn't open" is one where I have no problems or concerns, and will happily use the open version and recommend that people building something proprietary purchase a paid license. Nor will I typically worry about the motives or future of the project unless I have some other reason to. And the KDE Free Qt Foundation means I never have to worry about Qt going proprietary.'
Software under a proprietary license is something I can't build other Open Source software atop of that I expect other developers to use and collaborate on. I don't want to have a forked ecosystem of proprietary-with-source-available software, I want to actually collaborate on Open Source software.
With Open Source, I'd feel confident that if we had to manage it ourselves, or fork it and add a patch, or get a third-party to develop a patch, or work with a dozen others with the same needs we have and collaborate on it, we can do so. It's reasonable to build an ecosystem or community or company around. You cannot replicate that with any non-open license; by the time you're done granting all the necessary rights, what you'd have is a non-standard-but-Open-Source license, at which point you'll get more traction if you use an existing well-established Open Source license.
I don't really care about encouraging the development of more proprietary software, whether or not it happens to have source available. There are already well-established models for getting people to pay for proprietary software. If someone is looking for a funding model for Open Source, and what they find is "turn it proprietary and generate FUD that it's as good as open", that's a failure. And when people are looking for Open Source and they find proprietary-with-source-available, it undermines decades of careful work and explanations by the FOSS community, and generates substantial confusion.
It's your software, and ultimately your choice how to license it. Various companies have tried the "source-available but still proprietary" model. Just please don't call it open or contribute to the FUD around proprietary-with-source-available licensing.
Speaking from experience, when encountering software under a proprietary-but-source-available license that tries to act like it's open, the response from companies that actually deal in Open Source is not "Ah, OK, let's pay them and use it", it's "yikes, get this away from us, how did this even end up in consideration, let's either use something Open Source or use something actually proprietary, not something by someone who is either confused about the difference or hopes other people will be". (The set of engineers and lawyers who deal with software licensing professionally, at various companies, tend to talk about it with each other.)
Re: Migrating Dropbox from Nginx to Envoy
#227Earlier quoted context omitted.
The Prosperity license seems like a better fit to me, as the GPL/AGPL has a different set of constraints (e.g. customers who want to keep their code closed). What's wrong with a license that's non-OSI "open" but gets developers paid from large companies to develop otherwise open software?
The comment you originally responded to said: > The model of "copyleft if your project is open, pay us if your project isn't open" is one where I have no problems or concerns, and will happily use the open version and recommend that people building something proprietary purchase a paid license. Nor will I typically worry about the motives or future of the project unless I have some other reason to. And the KDE Free Q…
That makes sense. Unfortunately, as someone else in the thread has mentioned, the ways of monetizing OSS misalign the incentives between user and developer, and they haven't really been very successful anyway.
I develop multiple popular libraries that thousands of people use, yet I've never seen a single cent from them, which is fine for me because I don't develop them to make money. However, it's really hard to foster an ecosystem when companies who extract millions of dollars of value from FOSS don't feel like they need to give back.
Re: Migrating Dropbox from Nginx to Envoy
#228Earlier quoted context omitted.
I suppose, but you know you’re what you’re buying when you sign up for RedHat. I was trying to imagine a scenario where free OSS project does that, like Kubernetes or React.
Disclaimer: I work for Red Hat but opinions are my own I totally disagree. Red Hat patches/maintains things regardless of whether people pay for it. Everything is always available open source. There are numerous derivatives of RHEL that get these for example. The money you pay for Red Hat stuff is for support. There are always free-as-in-speech and free-as-in-beer alternatives of red hat products.
It might very well be my misunderstanding, so I apologize, but doesn't RHEL get security updates that are unavailable to the "rest of us" for a bit?
Re: Migrating Dropbox from Nginx to Envoy
#229Earlier quoted context omitted.
The comment you originally responded to said: > The model of "copyleft if your project is open, pay us if your project isn't open" is one where I have no problems or concerns, and will happily use the open version and recommend that people building something proprietary purchase a paid license. Nor will I typically worry about the motives or future of the project unless I have some other reason to. And the KDE Free Q…
That makes sense. Unfortunately, as someone else in the thread has mentioned, the ways of monetizing OSS misalign the incentives between user and developer, and they haven't really been very successful anyway. I develop multiple popular libraries that thousands of people use, yet I've never seen a single cent from them, which is fine for me because I don't develop them to make money. However, it's really hard to fost…
> Unfortunately, as someone else in the thread has mentioned, the ways of monetizing OSS misalign the incentives between user and developer, and they haven't really been very successful anyway.
Many ways of monetizing it don't misalign incentives. As a user, I don't value support less just because software is more reliable; on the contrary, I trust the software in higher-value contexts because it's reliable, and in those contexts I need the support more. I don't value "host this for me" less just because the software is easy to install and configure (because I still don't want to be the system administrator if I don't have to). And "please develop this feature for me" has great alignment of incentives.
> However, it's really hard to foster an ecosystem when companies who extract millions of dollars of value from FOSS don't feel like they need to give back.
You're a lot less likely to get paid for software that's under an all-permissive license (e.g. MIT or Apache or BSD). It's unfortunate that so much of the ecosystem has settled around permissive licenses; with such licenses, your best strategy for making money may be "use the software to get hired somewhere or to build reputation for consulting". There's a reason companies love permissive licensing, and subtly (or unsubtly) discourage copyleft. Strong copyleft gives you more options to monetize something, either now or in the future.
That said, I also do agree that there need to be more good ways of funding Open Source.
Re: Migrating Dropbox from Nginx to Envoy
#230Earlier quoted context omitted.
That makes sense. Unfortunately, as someone else in the thread has mentioned, the ways of monetizing OSS misalign the incentives between user and developer, and they haven't really been very successful anyway. I develop multiple popular libraries that thousands of people use, yet I've never seen a single cent from them, which is fine for me because I don't develop them to make money. However, it's really hard to fost…
> Unfortunately, as someone else in the thread has mentioned, the ways of monetizing OSS misalign the incentives between user and developer, and they haven't really been very successful anyway. Many ways of monetizing it don't misalign incentives. As a user, I don't value support less just because software is more reliable; on the contrary, I trust the software in higher-value contexts because it's reliable, and in t…
Maybe you're right, I do tend to choose MIT/BSD usually. I think I'll switch to GPL, though I don't entirely agree with your first paragraph (I am less likely to pay for software if I can host it myself, for example, though possibly not by much).