History of go links

Where and how did go links originate? What's the history of the useful internal short links we use and love today?

Perhaps unsurprisingly, go links have their origin at Google, specifically on the SysOps team where Eric DeFriez and Benjamin Staffin worked together back in 2005. The need for go links emerged from Googlers constantly asking their team to manually create shortcut URLs. In an effort to take work off their plates,  they created a system that let Googlers set up go links for themselves—no DNS changes or code reviews needed. We caught up with them for a Q&A about the history of go links.

Follow Eric DeFriez on LinkedIn and Benjamin on Twitter and GitHub.

Benjamin: When we were on the SysOps team at Google, we were frequently asked to set up memorable shortcut URLs like http://helpdesk that people wanted to promote internally in slides and printed materials, to point to somewhere on the corporate network. These weren't hard to set up, but between the various moving parts they took an hour each and that time added up quickly given how fast Google was growing.  Sometimes we would get requests to create the shortcut URLs after they’d already referenced them in printed materials!

To take that work off our plate and let Googlers set up short links themselves, during lunches within our team we often discussed creating a sort of "AOL keywords for companies".

Towards the end of 2006, Eric DeFriez created the first go links application that let Googlers create go/ links to their hearts' content.

Eric: The first go/ links system was created during one of the periodic weeks that I was on our team’s ticket rotation in, where we would handle user support requests on a range of topics from shortcut URLs, to username changes and NFS quota increases.  One afternoon in Fall 2006, rather than spending the time handling these types of odious tickets like I was supposed to, I instead decided to write the go/ system that we’d talked about where people could create and manage these shortcuts themselves.  Creating the system was very quick: I had a basic system working the same day.  I skipped creating the standard design document or discussing with the team leadership–instead sort of went rogue and utilized the discretionary “20% time” engineers were given (like how another engineer used to envision and create Gmail a few years earlier).  I created the application using the managed hosting environment that our team ran, built on apache with python and mysql for the backend database.

Eric: We expected at the very least for it to save our team 10+ hours a week handling the dozen or so shortcut URL tickets, which was enough for it to be very worthwhile for us. However we drastically underestimated how much extra demand there would be for it when people could create links completely self service. Within a few weeks of the system being soft launched, it leaked to the large internal “misc” mailing list and number of links and QPS shot up by 100x within a 24 hour period. Within a few months of launch we had 20,000 shortcuts and were handling 10,000 redirects/day inside Google.

The initial version was only able to create new shortcuts and do logging. But pretty quickly I added ability to update and delete shortcuts, show usage analytics, secondary owners, and an administrative interface so helpdesk could transfer ownership when someone left the company. Over time another teammate, Chris Heiser, rewrote the system to run on standard Google infrastructure like Bigtable and borg so that it could keep up with demand (not apache and mysql), then later it was rewritten again to work when not on the internal network/VPN.

Shortly after launch there were a few times when usage exploded and we had to quickly scale up our infrastructure. Additionally, engineers were often kicking the tires and intentionally creating redirect loops, misleading URL titles (many April fools jokes and fake “go/holiday-gift” rickrolls during this era), and finding URL/HTML escaping issues. As the system was written spur of the moment, I did it without the normal design doc and review process, it was only a month later when asked by a few of the team leaders did I create a design doc and have it reviewed posthumously.

So did it take off pretty quickly? By the time I joined Google in 2010, go links were a way of life.

Benjamin: Yes, as I recall, it took off pretty quickly, especially because we were trying to push people to use go links to create shortcuts rather than other methods like bare hostnames, which took time away from our team. Creating a go link was easy and self-serve.

Was there any pushback at Google against the rollout of go links?

Benjamin: Not much, and not in the way of policy. There was some concern around things like, say, go/yahoo not pointing to Yahoo, but by and large people recognized it was solving a real problem and were supportive.

Eric: Very early on, when people were still requesting shortcut URLs and we would redirect people to use http://go/example instead of http://example there would sometimes be pushback to the new URL.  But that quickly abated as we added more features to go/ like usage analytics and as it just became the de-facto standard to use go/ for all shortcuts.

Have you set up go links at other companies you've worked at?

Benjamin: I've never been the one to do it, but I've seen them pop up at companies I've worked at since Google. At Fitbit, for example, someone put together a simple app during a hack week and it caught on.

Eric: Even though we were never permitted to discuss go links externally, other Google employees eventually spread the word after leaving and the links pretty quickly popped up at other companies, open source projects and universities to name a few.

Was the go links app part of your core work, or was it more of a 20% time project?

Eric: It was never work I was formally assigned on my team OKRs or anything like that.  It was closer to “20% time” the first few quarters given it was self-directed, however within a few weeks of the launch leadership became aware and it had their strong support given it solved a real problem and reduced team toil time.

How was the "Short Links" Google Apps lab related to the go links app used inside Google?

Benjamin, Eric: That app was built as one of the first publicly-available App Engine apps to work with Google Apps.  That was written mostly as a demonstration of the App Engine infrastructure and wasn’t really used internally at the time.

What's it like seeing companies built around this idea you pioneered?

Eric: I think it's pretty cool! For me it's a reminder that (a) some seemingly trivial and “solved” ideas do have real value, and (b) having a good idea is only the very beginning of creating something. The harder (and more important) part is actually executing it.

‍