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.
- 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) 
They began their app on Ruby on Rails. Ruby on Rails was becoming very difficult to scale.
Before, on Rails, they had
- 150 AWS instances
- Slower response times
- Multiple caching strategies
- Multiple engineers per app 
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
The book Designing for Scalability with Erlang/OTP explains why Erlang had to have these features:
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.
What’s so special and different about Erlang? A few things, but I’d like to highlight something unique to Erlang: isolation of code in processes.
All code in Erlang runs in tiny, isolated processes that share nothing. This unique feature to Erlang makes Concurrency and Fault Tolerance possible.
Isolated processes enable concurrency by allowing the computing work to be run on multiple CPUs/cores, with the Erlang VM able to start and stop any process and make sure all processes get their turn to execute.
Node.js has concurrency, it's just not any good. In Node.js a blocking workload can hold up the whole world.
Fault tolerance means a system isn't taken down by bugs/errors/failure. On the Erlang VM, whenever a process encounters an error, it gets shutdown/restarted and the rest of the system continues along fine.
Fault tolerance is required to have 99.999% uptime and is a feature of the Erlang VM that's not found in other systems.
The remarkable backend of WhatsApp
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 
Whatsapp runs on Erlang. Whatsapp puts two million users on each server .
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.
That’s a lot about Erlang? I thought you were pitching Elixir
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.
Back to Bleacher Report. Elixir is how a Ruby on Rails development team was able to bring the power of the Erlang VM to their high-traffic API. Erlang the language can be intimidating for web development teams because it's so different and lacks tools that web developers expect.
Elixir makes present-day web developers as productive on the Erlang VM as they were on Ruby on Rails, Node.js, PHP, or .NET.
My bold claim: Elixir is such a good language, that it makes Ruby/Node/PHP/.NET/etc developers MORE productive than before.
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 . Its platform and libraries are very mature.
2. Elixir is in a healthy growth phase that hasn't slowed down.
Attendance at ElixirConf has doubled two years in a row:
- 2014: 105 attendees
- 2015: 256 attendees
- 2016: 542 attendees 
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 
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.)  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 :
...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.
I began my career not in programming. I worked as a door-to-door salesman in college that then switched to an accounting track inside the same company.
I got totally sideswiped by Ruby on Rails in 2008 because of how easy it was to create web applications and switched careers to becoming a Ruby consultant.
In January 2015, Bryan Hunter gave a talk on Elixir to the Nashville Ruby meetup. (Here’s an example of his talk, except for the Node.js audience: https://www.youtube.com/watch?v=q8wueg2hswA)
That talk was the beginning of the end for me to be able to do Ruby anymore. Elixir code has a lot fewer defects and bugs, is much faster than Ruby, but keeps most of the good parts of Ruby. The only drawback to Elixir is not having 10 years worth of libraries written for Ruby on Rails.
I studied Elixir and built personal projects with it in 2015, and in 2016 I gained two Elixir clients that I’m still working with.
When I’ve had work days that toggle between Ruby and Elixir, I am filled with anxiety writing Ruby code because of all the categories of programming errors and complexities that are inherent and Ruby that are not possible in Elixir. Not to mention how slow everything is and how much caching code you have to write.
Case Study: Ecos
Ecos is a business-to-business sales deck application used by companies like Emma and HealthStream. I developed version two of their app in Elixir and React.
Testimonials in Nashville
I worked with Josh to build a new SAAS platform for Ecos in record time. Josh in an expert in Elixir and can juggle both technical complexities and business needs. It was a pleasure to work with him and I hope to work with him again.
What I can do for you
- Build a new backend service for web or mobile
- Scale an existing Ruby backend by introducing Elixir
Pricing and Working Relationship
I will give you a fixed-price bid for your project (assuming it's a good fit)
Ready to talk?
Call me at 615-852-6559 or email me at [email protected]