Is this you?

• Your business model requires supporting millions of users
• Your backend API breaks under heavy traffic
• Your scaling strategy is to keep adding caching and servers forever
• Your API's latency / response time has become unacceptably slow
• Ruby on Rails is proving that it doesn't scale
• Node.js is brittle and can't do any heavy lifting

There is a better way

• Support one million users per server
• Handle huge spikes of traffic
• Dramatically reduce your server expenses and server count
• Decrease server response time to “instantaneous” ( < 30 ms)
• Increase your app's uptime

Let me tell you about Bleacher Report.

Bleacher Report is the 2nd largest sports news website/app.

They have:

• 1.5 Billion page views per month
• 3+ Billion Push Notifications per month
• 250,000 concurrent users at peak
• 200 Million push notifications sent on their busiest day (NFL Draft Day) [1]

Before, on Rails, they had

• 150 AWS instances
• Slower response times
• Multiple caching strategies
• Multiple engineers per app [2]

After switching to Elixir, they had:

• 1/15 the number of servers
• 10ms-30ms response times (super fast!)
• No caching!
• Approximately one engineer per app
• 1/15 the number of servers
• (Yes, I intentionally repeated that point)
• 1/15 the number of servers!!!

What is the secret sauce?

Why can’t Node.js, or Java, or Ruby, or Python, or even Go achieve results like this?

The secret sauce is the Erlang VM. The Erlang VM is an open source engine for running concurrent, real-time, fault-tolerant code. It was designed in Ericsson’s Computer Science Lab in the 1980’s— That’s older than all the other languages running the web today.

Erlang was designed for phone switches that had to

• handle millions of concurrent users
• have 99.999% uptime

At that time, the only systems that required the levels of scalability and fault tolerance we take for granted today were boring phone switches. They had to handle massive traffic spikes on New Year's Eve, fulfill regulatory obligations for the availability of calls to emergency services, and avoid the painfully expensive contractual penalties forced on infrastructure suppliers whose equipment caused outages. In layman's terms, if you picked up the phone and did not hear the dial tone on the other end, you could be sure of two things: top-level management would get into serious trouble and the outage would make the front page news in the papers. No matter what, those switches were not allowed to fail. Even when components and infrastructure around them were failing, requests had to be handled.

WhatsApp is the most popular phone messaging app in the world— more popular than SMS, than Facebook Messenger, than iMessage. As of February 2016 WhatsApp had

• 1 Billion+ active users
• 64 Billion messages sent on peak day [3]

Whatsapp runs on Erlang. Whatsapp puts two million users on each server [4].

Another remarkable thing about Erlang at Whatsapp: When Whatsapp was acquired by Facebook in April 2014 it had 450 million active users and ten (!!!) Erlang engineers. That's one engineer for each 45 million active users.

When it comes to real-time, million-user backends, the Erlang VM is the best in the world.

Yes, I am pitching Elixir. Elixir was created in 2012 by José Valim. José was a Ruby on Rails core member tasked with solving Rails’ concurrency problems. Here’s José telling the story:

Could you tell us more about it? How did this happen?

It is a long story, but I will try to make it short and sweet. Back in 2010, I was working on improving Rails performance when working with multi-core systems, as our machines and production systems are shipping with more and more cores. However, the whole experience was quite frustrating as Ruby does not provide the proper tool for solving concurrency problems. That’s when I started to look at other technologies and I eventually fell in love with the Erlang Virtual Machine.

I started using Erlang more and more and, with experience, I noticed that I was missing some constructs available in many other languages, including functional ones. That’s when I decided to create Elixir, as an attempt to bring different constructs and excellent tooling on top of the Erlang VM.

Web developers love modern tools and productivity. The Erlang VM powers real-time, million-user backends. José brought them together by creating Elixir.

But isn't it risky to choose a newer technology that doesn't have thousands of developers and a mature ecosystem?

This is a great question. Let me share some thoughts:

1. Elixir is new (released in 2012, version 1.0 released in 2014), but Erlang is old. Erlang is running major chat, trading, online gaming, and telecom services around the world and isn't going anywhere. Erlang is running 40% of the mobile traffic in the world [5]. Its platform and libraries are very mature.

2. Elixir is in a healthy growth phase that hasn't slowed down.

• Ten Elixir books in print [6]
• 44 job listings on this board (checked August 2016) [7]
• Lots of companies using it in production [8]

Attendance at ElixirConf has doubled two years in a row:

• 2014: 105 attendees
• 2015: 256 attendees
• 2016: 542 attendees [9]

3. There is a huge pool of quickly trainable Elixir developers-- the senior Ruby developer talent pool. Dockyard is a web development agency that has switched from using Rails to Elixir on the backend. They said it took "one week" to get their Rails developers able to make productive contributions to an Elixir app [10]

Carbon Five is a large software consultancy using Ruby. Their first production Elixir app is a iPhone API backend, and they found "We were immediately productive" using Elixir (coming from Ruby.) [11] Here's a long quote about how it went from using Ruby to Elixir:

We were immediately productive

Coming from Ruby, we were immediately comfortable with Elixir’s syntax. The Phoenix’s MVC framework gave us a familiar structure for our code. Elixir’s tools, like iex and mix, were invaluable. And we could even leverage some of our usual services, like CircleCI and Heroku. These similarities helped us be productive relatively quickly – even within our first week.

There’s a caveat to this, however. Elixir’s similarity to Ruby is deceptive. Beneath the facade it’s truly a very different beast. As time progressed, we noticed this more and more. We had brought some of our Ruby baggage along with us, and we weren’t using the language the way it wanted to be used.

Bleacher Report found that their Ruby developers, after getting over the initial learning curve, didn't want to go back to Ruby. Here's some rough excerpts from a webinar Bleacher Report did with Erlang Solutions regarding their success with Elixir [12]:

...The majority of our team now has had exposure to Elixir, and not many folks want to go back [to Ruby]. They really have enjoyed it [Elixir].

...There's the initial hump to overcome in terms of thinking in terms of functions instead of objects, but the familiar Ruby syntax helps.

...We have the Programming Phoenix book and the Programming Elixir book, and that's all they need to get started.

...We have these Ruby developers who are now Elixir developers and they don't want to go back to Ruby.

Conclusion: It is wise to vet new-ish technologies. You want to know that they will be around and strong in 3, 5, 10, 20 years. I think Elixir will be.

Let’s Sum This Up

Elixir can give you

• High availability (uptime)
• Millions of users per server
• With API response times 10ms - 30ms

Elixir is not a hype-fad that will fade, but a growing language with a large developer recruiting base.