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

81–90 of 243 posts

Re: Migrating Dropbox from Nginx to Envoy

#81

Post by veshij »

weitzj wrote: post #32

I did not quite get how they configure envoy? Did they write their own control plane? Use ambassador/Istio/Gloo?

We have a mix of static and dynamic configuration. We started with almost everything defined in the configuration and implemented our control plane only for endpoint discovery service. Over the time we implemented more and more features there (certificates, tls tickets, route and vhost configuration, etc). We decided to write own implementation on control plane - actually the core part is pretty simple and easily expandable.

Re: Migrating Dropbox from Nginx to Envoy

#82

Post by dragonwriter »

holografix wrote: post #80
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…

This also rubbed me the wrong way. As an individual I think that shows selfish and opportunistic behaviour and it raises a red flag about that organisation in my mind. However, for profit companies are not here to do what’s “correct” they’re here to make money for its investors. If I had decision making abilities at Nginx I’d be conducting a comprehensive review of the free OSS offering and redacting the features and…

> If you have an enterprise, paid version of your OSS product it has to be impossible for an enterprise to use it for free.

Why? Most enterprises, especially ones that aren't tech firms, are going to shell out for enterprise support even if there are no additional features. Crippling the community version doesn't necessarily help enterprise sales, it can reduce overall mindshare reducing enterprise traction or, worse yet, mean that a third-party downstream edition with richer open-source features becomes dominant and it's creator gets “your” enterprise support contracts.

Re: Migrating Dropbox from Nginx to Envoy

#83

Post by dzonga »

rmoriz wrote: post #22
techntoke wrote: post #15

Who does Dropbox compete with these days? They have pretty much the highest prices for the least amount of value. The only reason I see them mentioned here frequently is their connection with Y Combinator.

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…

effect of being vc funded. the engineers hired later on, only care about engineering problems also company nametag & money, not user level problems. you would think, dropbox would be concerned with providing best value for the buck but nah. plenty of other examples fb, google - google software quality sucks for a place that employs 100s of engineers.

Re: Migrating Dropbox from Nginx to Envoy

#84

Post by mehrdada »

rebelnz wrote: post #66
mehrdada wrote: post #57

Earlier quoted context omitted.

Why does it blow your mind? Various obvious and sane reasons for this, including cost. I bet many of those companies you have in mind “buy” Windows and macOS, and if they are sufficiently big, most certainly buy Oracle or SAP for their corporate operations, finances, and accounting. It’s usually only the production side of sufficiently large internet-scale companies that is biased towards building. Most of the time y…

I think the point was a financially successful company not contributing to an open source project even after making a bunch of money just seems un-ethical? Maybe I'm old-school but I still think we should be supporting each other in this type of situation especially if one of us strikes it big? Sure - move away from Nginx but maybe throw some $ their way for the service they provided even if you don't legally have to…

I did not infer that from the OP’s comment, but in any case, I don’t know the specifics of their arrangement or whether they had been a commercial customer or not. Last time I checked Nginx had been doing fine selling itself for half a billion.

But more abstractly, I don’t actually agree with that sentiment. I see more of a responsibility to give back in the form of patches and collaboration than throwing $ at the problem. I see the nginx approach of open source simply as a business tactic no different from Windows Home/Pro customer segmentation except Home is free for tactical reasons to kill off other competition. It is a calculated business move; if your business model sucks-—which it obviously did not in nginx case—-does not imply others are acting less than ethically or they should pay you out of pity. (That said it might be strategically important for them to keep your head above water and survive for their own benefit as their vendor, but that’d be a different angle.)

I suppose the difference between free software vs open source is also relevant to this discussion, and I could relate to your sentiment when facing the former much more than the latter.

Re: Migrating Dropbox from Nginx to Envoy

#85

Post by dwaltrip »

holografix wrote: post #80
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…

This also rubbed me the wrong way. As an individual I think that shows selfish and opportunistic behaviour and it raises a red flag about that organisation in my mind. However, for profit companies are not here to do what’s “correct” they’re here to make money for its investors. If I had decision making abilities at Nginx I’d be conducting a comprehensive review of the free OSS offering and redacting the features and…

> However, for profit companies are not here to do what’s “correct” they’re here to make money for its investors.

While partially true, this is overly reductive. Companies can and often do take actions that serve goals beyond "increase upcoming quarterly profits".

Re: Migrating Dropbox from Nginx to Envoy

#86

Post by gitgud »

SaveTheRbtz wrote: post #41
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…

The subject of monetizing opensource software is a tricky one. Some companies pursue the Open-Core principle, others monetize through the consulting services or cloud infrastructures. As for investing into opensource, Dropbox is trying to do that when possible, for example we (along with Automattic) did sponsor HTTP/2 development in Nginx.

Personally I think that monetisation of open-source goes against the consumer of the OSS in practically all cases.

- Open-Core::: Features are not added to core, as they want people to upgrade.

- Consulting::: Ease of use is ignored, as if it's too easy people won't need consultants.

- Sponsoring Goals::: Software is almost held at ransom, until goals are reached.

The best way to help open-source software is to donate or contribute code... if you're trying to maximise profits, then just make it propitiatory

Re: Migrating Dropbox from Nginx to Envoy

#87

Post by P4wl0w »

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…

Isn't this simple economic reasoning?

If you buy something or worse you have to pay license fees on a regular base your earnings will be smaller.

We live in a world that is driven by economic growth so the ultimate goal is to maximize profit.

Of course this has a moral aspect to it as well and I see it but in this case I think it is not outraging enough to be something on the scale of a scandal.

Many businesses use ideas or products for free to start a successful enterprise that earns a lot of money.

Re: Migrating Dropbox from Nginx to Envoy

#88

Post by SaveTheRbtz »

dmarble wrote: post #79
dmicher wrote: post #27

Earlier quoted context omitted.

Sadly, it would probably be as hard to maintain as an opensource version. We really want to have access to the code to make sure we can fix, troubleshoot it, understand it fast... Things that may've help: -- Configuration definition (e.g. protobufs.) -- More focus on observability: error metrics (instead of logs), tracing, etc. -- gRPC control plane. -- C++ module development SDK. -- (ideally) bazel. Some dataplane f…

Don't any of the major commercial open source vendors offer custom terms to give access to the commercial source? I'd imagine they'd contemplate it for big deals. Seems like one of the only ways to keep some of these sophisticated customers onboard.

open source argument is valid -- most software enterprise vendors do provide source code access (under NDA.) The rest of the arguments stand though: as it is right now, it way more developer/operator friendly to use Envoy in our production.

Re: Migrating Dropbox from Nginx to Envoy

#89

Post by mholt »

SaveTheRbtz wrote: post #76
xet7 wrote: post #73

How does Envoy compare to Caddy 2 ? https://caddyserver.com

To tell you the truth, we didn't consider it. From what I can get from the architecture docs[1], it can be a decent platform for apps, but might not be the best choice for a general purpose ingress/egress proxy (at least for now.) [1] https://caddyserver.com/docs/architecture

It is a great choice for a general purpose proxy. (That's kind of the point.)

Re: Migrating Dropbox from Nginx to Envoy

#90

Post by jrockway »

chucky_z wrote: post #70
ram_rar wrote: post #68

I feel so old now. There was a time, when I used to discuss with senior engineers @ Yahoo! to use NginX over Apache. Nginx was the hot thing, popularizing C10k [1]. Now in my current team, I have junior devs in my team pushing for Envoy over HAProxy/Nginx setup. Is this trend happening primarily because devs are pushing for GRPC over REST? What benefits does Envoy offer over Nginx, if you're still a REST based servic…

The operational overhead shifts to more API stuff, so people can write 100 lines of code instead of modifying 1 line of config, it feels like. This is never going to end as more things shift towards being core APIs that allow you to write code instead of configure things. It's not even configuration-as-code, it's just code managing configuration files. edit: I think my comment comes across maybe kinda rude. My beef w…

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/master/pkg/xds/xds.g... I did this after reading the source code for the most popular xDS implementations and finding myself horrified (you know the popular xDS implementation I'm talking about). Now I have a framework for writing whatever xDS server I desire, and it can be as simple or as complex as I want it. For example, for my use cases, I'm perfectly happy with a static route table. It is very clear what it does, so I have that. What annoyed me was having to configure the backends from Kubernetes for every little service I wanted to expose to the outside world. So I wrote ekglue, which turns Kubernetes services and endpoints into Envoy clusters and Envoy cluster load assignments. This means that I never have to touch the tedious per-cluster configs, and still get features like zone aware load balancing. And I don't have to take on complexity I don't want -- the woefully under-specified Kubernetes Ingress standard, service meshes, etc. (I also plan to use ekglue for service-to-service traffic because xDS is built into gRPC now... just haven't needed it yet. It's great to use the same piece of software for two use cases, without having to maintain and read about features I don't need.)

TL;DR: take a look at the spec. It's really well thought out and easy to implement. Just don't cut-n-paste from Istio because they got it really wrong.

Post reply on HN