Use go instead of ruby to reduce the number of servers from 30 to 2

This is a creation in Article, where the information may have evolved or changed.

Using another language to rewrite a service, does it sound like a toss-up? However, cloud service provider Iron.io has done so, and has successfully reduced the server from 30 to 2 units. Iron.io the whole story on its official blog, here's a look at:

Iron.io and Ironworker

Iron.io, a consulting firm that initially helped build applications for other companies, is now a cloud service provider. Iron.io's rationale for developing Ironworker is also trite:

Previously, Iron.io was a consulting firm, and during the Ironworker development period, AWS and Ruby on Rails were two very hot areas. Iron.io has several customer-built hardware facilities that will constantly (7x24 hours) send data to them, and in order to collect and process the data, Inro.io established their own internal service "worker as a service". As for the issue of the reason is very old, in their own use, and suddenly feel that other institutions may also have similar needs (very similar to "book Dealer" Amazon), so the birth of the release version of Ironworker.

Of course, the Ironworker starter version uses Ruby and the rails-based API. At first, Ironworker performed very well, with little effort and time to support the heavy load. Soon ironworker, however, was constrained by rails:

It's another ror.

To keep the service flowing, Iron.io has kept its server CPU usage at 50-60%; Once the CPU usage exceeds this range, the number of servers is increased. Of course, if you don't mind increasing the number of servers all the time, that's also possible, but soon they'll mind!

When a "huge" request is connected to their server, a domino effect is likely to result in a crash of the entire server cluster:

Once some threads occupy more than 50%, the Rails server CPU usage will soar to 100%, and the server will become unusually slow. The load balancer considers the server to fail and removes it from the server cluster, but the jobs on the removed server are assigned to the remaining servers, so the problem occurs-the thread that caused the whole event is not removed or processed. In such a vicious circle, the servers in the cluster are removed from one another until the entire system crashes.

The only way to avoid this problem is to add enough computing power, which means huge costs. Based on years of excellence (using less resources to take on more load), Iron.io decided to rewrite the API and do the culprit rails, so that the first thing they faced was what programming language to use.

Go to the fore

The first thing they're thinking about is going back to Java's performance advantage, but after years of using Ruby for simplicity, clarity, and fun, Java is being discarded because of its coding efficiency weaknesses. Then there are some scripting languages that have higher performance than Ruby, such as Python, Javascript/node; Java derivatives, such as Scala and Clojure, and other languages such as Erlang, go, and so on. And after some prototypes and performance tests, they finally chose go.

There was a great deal of risk in choosing go in that environment, because there was no big community at that time, and there were not many open source projects, and there were not many successful use cases. There are too many unpredictable uses of go, such as recruiting good engineers, but most of them have not happened.

Use of Go version

go version of the launch, Iron.io server number directly from 30 to 2 units, two additional redundant servers are never used. CPU usage is less than 5%, and the go version uses less than hundreds of K compared to rubby using nearly 50M of memory during initialization.