15:1 Server Reduction...

Applications running at any significant scale typically execute on clusters of servers.  These clusters are composed, generally, from multiple similar servers.  These servers share the overall load of the app, allowing many more concurrent users than could ever run on a single server.  You could think of the clerks in the grocery store checkout as a human equivalent.  Having multiple servers also provides an arbitrary degree of redundancy, so that if one or more servers fail for any reason, the working servers remaining can pick up the load.  Building big clusters (if big enough, often called “server farms”) is the brute force way to scale up almost any modern web application.  It's the standard, “out-of-the-box” way to scale up to large loads; it's what everybody does.

Well, almost everybody.

Depending on the business model of the application in question, the cost of the additional servers may be significant.  In other words, if your application doesn't make a lot more money than the servers cost, you're going to care about that server cost.  How can you reduce the number of servers required to handle the load?

The answer to that is very specific to the precise nature of each application.  There are several general approaches one can take, ranging from the traditional iterative bottleneck identification-and-destruction technique to the raze-and-rebuild technique.

In the latter category is this: figuring out that you made a poor choice of programming language, and rewriting your entire application from scratch in a new language.  In our real-world equivalent, it's as if you replaced the ordinary checkout clerks with supermen who worked many times more quickly.  That's what these folks did, moving from Ruby to Go – and their reward was a reduction from 30 busy servers to 2 idling servers (and only 2 in order to provide redundancy!).

As one of the commenters points out, probably moving from Ruby is the important part of the exercise – most likely nearly any choice of a “normal” programming language (C, C++, Java, Erlang, etc.) would have achieved similar gains.  The author, however, makes some interesting points about Go – to me, most especially concerning its support for concurrency...