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

The GitHub Load Balancer

githubengineering.com

Post reply on HN
Print view View original

121–130 of 137 posts

Re: The GitHub Load Balancer

#121

Post by otterley »

logicalstack wrote: post #45
Ianvdl wrote: post #3

Given the title and the length of the post I was expecting a lot more detail. > Over the last year we’ve developed our new load balancer, called GLB (GitHub Load Balancer). Today, and over the next few weeks , we will be sharing the design and releasing its components as open source software. Is it common practice to do this? Most recent software/framework/service announcements I've read were just a single, longer po…

Joe from GitHub here, frankly there is a lot we want to talk about and release and it was simply too much for one post. We'd like to give it a proper treatment and single very long post won't do that. Also, it allows us to get folks interested in the project and give us time to prepare our code for release. It's a surprisingly big job.

Personally, I would have preferred you waited until you could release all the documents at once. I admit I was interested, but I've seen too many people and organizations start a conversation but never finish it or show the goods. It's misleading and unfair to dangle a solution when all you really have is a problem.

Take, for example, this post from CoreOS back in March 2016 that suggested that they might know a way to improve systemd-journald performance: https://coreos.com/blog/eliminating-journald-delays-part-1.h...

It smelled suspicious, but its release generated a bunch of noise on HN anyway. And they never followed up with subsequent parts, which suggests to me that they never found a solution in the first place.

I'm not suggesting that GitHub is blowing smoke -- if you truly have a solution, that's great! But there's no harm in gathering documentation and source code and cleaning it up and waiting until it's good and ready to go. Otherwise, I frankly mistrust the motives and abilities of those involved. Call me cynical if you must.

To paraphrase from another industry, "sell no wine before its time." There's a lot of wisdom there that is equally applicable to products in our industry too.

Re: The GitHub Load Balancer

#122

Post by contingencies »

sitkack wrote: post #120
contingencies wrote: post #111

Earlier quoted context omitted.

I second this from China. Apple Appstore based OSX updates are literally impossible here. Annoyingly, they are required to upgrade Xcode.

One technique I used is to download updates directly via wget -c --limit-rate=200K http://support.apple.com/downloads/DL1833/en_US/osxupd10.10.5.dmg -c resumes download where left off, the rate limiting can be used to match the speed of your connection or intermediaries reducing stalls, drops and angry network users. I would often keep a list of URLs in `download-queue.txt` and use the above flags with -i to load the…

A download manager would be fine if there was a non-opaque method of determining the download address, and they actually let you do that (I know the developer site for instance uses some combination of cookies/referrers to limit external access to binaries presented for download).

Re: The GitHub Load Balancer

#123

Post by zepolen »

ckdarby wrote: post #68
jimjag wrote: post #29

I am increasingly bothered by the "not invented here" syndrome where instead of taking existing projects and enhancing them, in true open source fashion, people instead re-create from scratch. It is then justified that their creation is needed because "no one else has these kinds of problems" but then they open source them as if lots of other people could benefit from it. Why open source something if it has an expect…

Have you ever contributed to HaProxy? Have you ever tried committing massive alterations to major open source projects? It isn't as simple as here's my massive rewrite, click the accept button and everything works out for the open source community. Let me be the first to say that the level of politics, circle jerking and knowing people is ridiculous.

As someone who's contributed multiple patches to multiple open source projects, this is 100% truth.

I have >3 month old pull requests to add tests which have never been looked at - whereas someone who knows the project maintainer will get a PR looked and merged the next day.

Re: The GitHub Load Balancer

#124

Post by sitkack »

contingencies wrote: post #122
sitkack wrote: post #120

Earlier quoted context omitted.

One technique I used is to download updates directly via wget -c --limit-rate=200K http://support.apple.com/downloads/DL1833/en_US/osxupd10.10.5.dmg -c resumes download where left off, the rate limiting can be used to match the speed of your connection or intermediaries reducing stalls, drops and angry network users. I would often keep a list of URLs in `download-queue.txt` and use the above flags with -i to load the…

A download manager would be fine if there was a non-opaque method of determining the download address, and they actually let you do that (I know the developer site for instance uses some combination of cookies/referrers to limit external access to binaries presented for download).

I haven't tested this specifically, but I did something similar

https://gist.github.com/dbr/294151

extracting cookies out of Safari so I could download developer binaries from apple.

Re: The GitHub Load Balancer

#125

Post by Veen »

gumby wrote: post #69

They talk about running on "bare metal" but when I followed that link it looked like they were simply running under Ubuntu. Is it so much a given that everything is going to be virtualized? When I think of "bare metal" I think of a single image with disk management, network stack, and what few services they want all running in supervisory mode. Basically the architecture of an embedded system.

In the hosting world, bare metal generally means dedicated servers and clusters of dedicated servers. It's just a shorthand for "not cloud".

Re: The GitHub Load Balancer

#126

Post by mobiuscog »

jimjag wrote: post #29

I am increasingly bothered by the "not invented here" syndrome where instead of taking existing projects and enhancing them, in true open source fashion, people instead re-create from scratch. It is then justified that their creation is needed because "no one else has these kinds of problems" but then they open source them as if lots of other people could benefit from it. Why open source something if it has an expect…

This is just ridiculous.

Open Source is about just that - allowing anyone and everyone to have access to the source and (if free) making their own version.

There never needs to be justification to write something from scratch, even if it's been done a million times before.

You can appreciate open-source, you can wish that proprietary code was open source, but you never have the right to tell people what they should do, nor are you ever likely to be correct as to what they should do - you are not them.

Re: The GitHub Load Balancer

#127

Post by unwind »

colemickens wrote: post #110
wmf wrote: post #74

Earlier quoted context omitted.

Yes, it is assumed that all startups are running in EC2 us-east-1 and "bare metal" is the accepted term for non-virtualized systems.

I don't get it. What else is bare metal meant to mean? "bare metal" = "embedded system"? What does "embedded system" mean then? I guess my age / cloud-nativeness is showing?

In the embedded space, there often isn't any type of OS or kernel between the application code and the hardware resources ("the metal").

If I want to send out a character through the board's serial debugging port, I don't do an open()/write()/close(), I poke the UART's transmit register.

When they said "bare metal", I too thought they ran without OS which had been kind of cool.

Re: The GitHub Load Balancer

#128

Post by yladiz »

I'm of two minds about this. Part of me agrees with many of the commenters here, in that Not Invented Here syndrome was probably in effect during the development of this. I don't really know Github's specific use case, and I don't know the various open source load balancers outside of Haproxy and Nginx, but I would be surprised if their use case hasn't been seen before and can be handled with the current software (with some modification, pull requests, etc.). On the other hand, I would guess Github would research into all of this, contact knowledgeable people in the business, and explore their options before spending resources on making an entirely new load balancer. Maybe it really is difficult to horizontally scale load balancing, or load balance on "commodity hardware".

That being said, why introduce a new piece of technology without actually releasing it if you're planning to release it, without giving a firm deadline? This isn't a press release, this is a blog post describing the technical details of the load balancer that is apparently already in production and working, so why not release the source when the technology is introduced?

Re: The GitHub Load Balancer

#129

Post by madmulita »

We are in the process of moving all of our infrastructure to OpenStack, OpenShift, Ansible, DevOps, Microservices, Docker, Agile, SDN and what not.

There are some brainiacs pushing these magic solutions on us and one of the promises is load balancing is not an issue, even better, it's not even being talked about.

Please, please, tell me there's something I'm missing.

Re: The GitHub Load Balancer

#130

Post by ctrlrsf »

voltagex_ wrote: post #82
logicalstack wrote: post #63

Earlier quoted context omitted.

CARP and similar systems require an active/passive configuration which we did not want since it needs at least twice as many hosts, half of which are not doing any work. We had similar issues with our former Git storage system based on DRDB ( http://githubengineering.com/introducing-dgit/ ). pfsync, lvs and etc uses multicast to share connection state which we also wanted to avoid.

Why do you want to avoid multicast?

You would need a large L2 network to support it, or you'd have to route it at L3, which is not trivial.
Post reply on HN