Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating Dropbox from Nginx to Envoy

dropbox.tech

Post reply on HN
Print view View original

131–140 of 243 posts

Re: Migrating Dropbox from Nginx to Envoy

#131

Post by Bombthecat »

e40 wrote: post #40

Also note that we’ll cover the open source version of the Nginx, not its commercial version with additional features. It always kills me when very successful companies don't buy software from other companies. I remember being at a lunch with a prospective client that really loved our technology. About 1/2 way through, he said he really would love to purchase our software, but the CEO doesn't allow them to use anythin…

In germany its the opposite, no free software in production! Only software with enterprise support!

We Germans are very risk adverse (i hate that sometimes)

Re: Migrating Dropbox from Nginx to Envoy

#132

Post by toast0 »

eric4smith wrote: post #104

It's interesting almost no web server provides an easy way to deal with multi-tenant multi-domain architectures in a good way that includes automatic SSL. Caddy is the closest, but still not near enough. There is this small segment of the market that we operate in that requires thousands of TLS connected domains to be hosted behind a dynamic backend. It's services like Tumblr, Wordpress.com, or any other hosting serv…

I would think the way to do this would be to run a separate TLS daemon that handles the certificates (including acme challenges, presumably) and then pass the socket to your http server, either by proxying it (preferably to a unix socket), or like actually pass the FD with the session keys.

I don't think hitch (formerly stud) supports acme challenges, but that's where I'd start.

Re: Migrating Dropbox from Nginx to Envoy

#133

Post by simplyinfinity »

eric4smith wrote: post #104

It's interesting almost no web server provides an easy way to deal with multi-tenant multi-domain architectures in a good way that includes automatic SSL. Caddy is the closest, but still not near enough. There is this small segment of the market that we operate in that requires thousands of TLS connected domains to be hosted behind a dynamic backend. It's services like Tumblr, Wordpress.com, or any other hosting serv…

We are using OpenResty with lua-auto-ssl for exactly this purpose, and it works like a charm.

Re: Migrating Dropbox from Nginx to Envoy

#134

Post by bschwindHN »

mholt wrote: post #110
eric4smith wrote: post #104

It's interesting almost no web server provides an easy way to deal with multi-tenant multi-domain architectures in a good way that includes automatic SSL. Caddy is the closest, but still not near enough. There is this small segment of the market that we operate in that requires thousands of TLS connected domains to be hosted behind a dynamic backend. It's services like Tumblr, Wordpress.com, or any other hosting serv…

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?

Yeah I'm not sure what they're getting at, I've used Caddy as well for similar "custom domain" features, it was super easy. Thanks for creating it!

Re: Migrating Dropbox from Nginx to Envoy

#136

Post by doteka »

chii wrote: post #124
pjmlp wrote: post #100

Earlier quoted context omitted.

All fine and dandy, except that those patches and collaboration don't pay bills.

> patches and collaboration don't pay bills. implying that just because your open source project is being used, that it is entitled to fund the bills of the project maintainers. I think patches and contributions are a form of bill paying.

Get that “implying” crap out of here, this isn’t 2008 4chan.

Re: Migrating Dropbox from Nginx to Envoy

#137

Post by Nitramp »

Slartie wrote: post #130
pjmlp wrote: post #114

Earlier quoted context omitted.

Yep, gRPC is the new toy for distributed computing, after everyone realised that DCOM, CORBA, RMI, Remoting actually made sense instead of parsing XML and JSON text formats all the time.

I had to chuckle as well when I read that article and the part about gRPC. Seems like the pendulum is swinging into the other direction again - back to where we've already been ten or twenty years ago. New name of course, but same concepts. One really starts to feel old at such occasions.

It certainly does look like that. I do think though that we've learned a number of central lessons in the process:

- treat messaging as a first class concept, not something to hide & abstract away.

- do not attempt to implement polymorphism in a messaging protocol. Do not bind your messaging protocol to a programming language's type system (they serve different purposes).

- bake fundamental monitoring & maintainability concepts into the protocol (e.g. intermediaries must be able to understand what responses are errors).

- have a well understood, simple backwards and forwards compatibility story.

- etc.

All of this is stuff we didn't understand in RMI or CORBA or SOAP etc. REST was a great wakeup call, both in simplicity and some of the messaging protocol concepts (such as error modelling). It is missing the application level binding - there's just no good reason why you wouldn't have a statically checkable method/request/response type binding.

I am a bit weary on whether gRPC will go over board again in complexity. We'll see.

Re: Migrating Dropbox from Nginx to Envoy

#139

Post by speedgoose »

nyanpasu64 wrote: post #103
JoshTriplett wrote: post #101

Earlier quoted context omitted.

In a business context, I'd definitely consider paid support for an Open Source product. But I'm not interested in a proprietary version that I can't modify or get third-party support for or otherwise work with in a pinch; I'm certainly not going to make a business dependent on it. Push the proprietary version hard enough and I'll reconsider whether I even want to use the Open Source version, or if it might be on more…

> Push the proprietary version hard enough and I'll reconsider whether I even want to use the Open Source version Qt is pushing hard for commercial licensing (which I heard prevents you from using the open-source version), putting L/GPL FUD on their websites, and trying to track users of their installers more.

And nowadays, most people use Electron instead of Qt.

Re: Migrating Dropbox from Nginx to Envoy

#140

Post by ivalm »

chii wrote: post #124
pjmlp wrote: post #100

Earlier quoted context omitted.

All fine and dandy, except that those patches and collaboration don't pay bills.

> patches and collaboration don't pay bills. implying that just because your open source project is being used, that it is entitled to fund the bills of the project maintainers. I think patches and contributions are a form of bill paying.

Something should pay for the bills and if the oss project creates lots of real value then I would prefer to live in a world where some of that value goes to pay the bills. The alternative world simply discourages oss since devs would have to work other jobs. There is qualitative difference when you have a dedicated core team vs just everyone contributing patches.
Post reply on HN