Service rewrite - Significantly reduce the number of servers

Will it be taunting to rewrite a service in another language? But cloud service provider Iron.io does exactly that and has successfully reduced its server from 30 to two. Iron.io posted the whole story on its official blog, here's a look:

Iron.io and IronWorker

Iron.io was originally a consulting firm helping other companies build applications and is now a cloud service provider. Iron.io IronWorker's reason for developing the same old fashioned:

Iron.io was previously a consulting firm, and AWS and Ruby on Rails were two very hot areas during IronWorker's development. Iron.io has several customers that have hardware facilities that send data to it continuously (7x24 hours). In order to collect and process this data, Inro.io has created their own internal service "worker as a service." As for the reasons for the release is very old-fashioned, in their own use at the same time, suddenly feel that other agencies may have similar needs (very similar to the "bookseller" Amazon?), So the birth of the release version of IronWorker.

Of course, the first release of IronWorker uses Ruby and a Rails-based API. At first IronWorker did a good job of supporting a fairly heavy load with little effort and time. However, IronWorker was quickly limited by Rails:

RoR is another disaster

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

When a "huge" request is made to connect to their server, it is likely that a domino effect will result in the collapse of the entire server cluster:

As some threads take up more than 50%, Rails server CPU utilization will soar to 100%, and the server will be unusually slow. The load balancer assumes that the server has failed and removes it from the server cluster; however, the jobs on the removed server will be allocated to the remaining servers and the problem occurs - resulting in the entire event Thread has not been removed or processed. On such a vicious circle, the servers in the cluster are removed one after 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 many years of excellent (less-load-consuming) development experience, Iron.io decides to rewrite the API to be the culprit of Rails, so first and foremost what they face is what programming language to use.

Go's stand out

The first thing they think about is returning to the performance advantages of Java, but after years of using Ruby, it's simple, clear, and interesting, and Java is being thrown away because of its encoding efficiency. Then there are some scripting languages ​​that have higher performance than Ruby, such as Python, JavaScript / Node, derivatives of Java such as Scala and Clojure, and other languages ​​such as Erlang and Go. After some prototype and performance tests, they eventually chose Go.

Go was a big risk when it came to that environment, because Go had no big community, no open source projects and no number of successful use cases. There is too much unpredictability in using Go, such as hiring good engineers; however, most of these do not happen.

Go version usage

After the Go version was introduced, the number of Iron.io servers was reduced directly from 30 to 2, and the additional two redundant servers were never used. The CPU utilization is less than 5%, while the initialization process uses nearly 50M of memory compared to Rubby, Go version takes less than a few hundred K.