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 that sound frustrating? 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-fashioned, in their own use, and suddenly feel that other institutions may also have similar needs (very similar to "book Dealers" Amazon?) ), and was born
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, however, Ironworker was constrained by rails.

It's another ror.

To keep the service flowing, Iron.io keeps its server CPU usage at 50-60%;CPU usage once it exceeds this range, it increases the number of servers. Of course, if you do not mind increasing the number of services, it is also feasible, but soon they will mind!

When a "huge" request is connected to their server, it is likely that a multi-meter effect will cause the entire cluster of servers to crash:

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

When the go version is launched, the number of servers in Iron.io has been reduced from 30 to 2 units, and two additional redundant servers have never been 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.

Via Oschina