This document introduces Phoenix, a web framework for building scalable and fault-tolerant distributed systems with Elixir and Erlang. It discusses how Moore's Law has led to more multi-core machines requiring better support for concurrency. Phoenix provides productivity benefits like Rails while enabling applications to handle massive concurrency through Elixir and Erlang's actor model and lightweight processes. The document demonstrates building basic and real-time web apps with Phoenix as well as using it as the web layer for distributed systems.

1. Phoenix for Rubyists
Concurrency and Scalability with Productivity
by Doug Goldie
Code Cauldron

2. Why New Language ?
Scalability
Concurrency
Productivity of Rails
Why New Language or Framework?

3. Moore’s Law is Dead!
number of transistors in a dense integrated circuit
doubles approximately every two years.
We are seeing more multi-core machines
with more cores.
The observation is
What are we getting …. more chips, more multi-core machines.

4. What do we need?
Handle Multicores
Distributed Systems
Massive concurrency
But still with Productivity

5. What do we build?
Any Web Applications
Distributed Systems
But we still want
productivity

6. The Answer
Phoenix
Elixir
Erlang

7. What do we build?
Any Web Applications
Distributed Systems
But we still want productivity

8. Any Web Application
Classic CRUD monolith
Single page app (SPA) - with any frontend
Realtime app
productivity and performance.

9. Distributed Systems
Small distributed apps.
Large-Scale distributed, fault-tolerant system
Phoenix as the Web component
Elixir for the other components.
productivity and performance.

10. Agenda
Elixir in 10 minutes
Basic Phoenix app
Real-time app
Distributed systems
Some really contrarian, disruptive ideas !!
- Rails like demo
- Non-rails like demo - realtime
- web component for a distributed, fault tolerant system
- use this platform to do things in a really contrarian way.

11. Elixir

12. Elixir in 10 minutes
placeholder

13. Basic Web Application

14. Phoenix demo
Classic Rails example

15. Real-time Application

16. Real-time Features
Phoenix
Channels
Topics
Elixir & Erlang
Massive concurrency
Actor model
Processes

17. Processes
• lightweight, small
memory, fast to create
and terminate
• message passing
• no shared data
• links and monitors
• error handling
Erlang is
designed for
massive
concurrency
Erlang is designed for massive concurrency. Erlang processes are lightweight (grow and shrink dynamically) with small memory footprint, fast to create and terminate,
and the scheduling overhead is low.

19. Chat demo
Classic real-time example
Phoenix channels / topics

20. Server A
HTTP Server
Nginx and Phusion
Passenger
Request processing Ruby on Rails
Long-running requests Go
Server-wide state Redis
Persistable data Redis / MongoDB
Background jobs
Cron, Bash scripts, and
Ruby
Service crash recovery Upstart
Server B
Erlang
Erlang
Erlang
Erlang
Erlang
Erlang
Erlang
A real world Rails app needs other software.
other things: sidekiq, docker, ???

21. Server A
Server B
Erlang
Erlang
Erlang
Erlang
Erlang
Erlang
Erlang
A real world Rails app needs other software.
other things: sidekiq, docker, ???

22. Distributed Systems

23. HTTP Server
Nginx and Phusion
Passenger
Request processing Ruby on Rails
Long-running requests Go
Server-wide state Redis
Persistable data Redis / MongoDB
Background jobs
Cron, Bash scripts, and
Ruby
Service crash recovery Upstart
Erlang
Erlang
Erlang
Erlang
Erlang
Erlang
Erlang
Server A Server B
This isn’t just large-scale problems. We build distributed systems all the time.
A real world Rails app needs other software.
other things: sidekiq, docker, ???

24. Of course there are large-scale problems to solve.

25. Hard Problem to Solve

26. with only 10 engineers!
In 2014, sold for $19 Billion.
465 million users
550 servers

27. Erlang History
Developed over 25 years ago by Ericsson for building
Telcom products
Released as open source in 1998.

28. Requirements
• high concurrency
• distribution
• fault tolerant
• soft realtime
• high availability
• external interfaces
• hot code upgrade

29. –Robert Virding
“Erlang is for building systems.”

30. Processes
• basic unit of work
• message passing
• no shared state
• high concurrency
Erlang is designed for massive concurrency.
Erlang processes are
— lightweight (grow and shrink dynamically)
— with small memory footprint,
— fast to create and terminate, and
— the scheduling overhead is low.

31. Processes
• lightweight, small
memory, fast to create
and terminate
• message passing
• no shared data
• links and monitors
• error handling
Erlang is
designed for
massive
concurrency
Erlang is designed for massive concurrency. Erlang processes are lightweight (grow and shrink dynamically) with small memory footprint, fast to create and terminate,
and the scheduling overhead is low.

32. Scheduler
uses multiple cores out of the box

33. Actor Model

34. OTP
• supervision trees
• behaviors
• applications
• releases
• release handling
Erlang is designed for massive concurrency.
Erlang processes are
— lightweight (grow and shrink dynamically)
— with small memory footprint,
— fast to create and terminate, and
— the scheduling overhead is low.

35. OTP
Library of Design Patterns
Behaviors
Client Server
Supervisors and Workers

36. Gen Server

37. Lifecycle of GenServer

38. Fault-tolerance

40. Quotes
“Best kept secret in software”
- Evan Miller, author of Chicago Boss
“Erlang is about building Systems”
- Robert Virding
“Erlang makes the easy things hard
and the hard things easy”
separate?

41. Umbrella demo
Phoenix and Elixir have Umbrella apps.
Separate Applications in one repo.

42. Server A Server B
HTTP Server Nginx and Phusion Passenger Erlang
Request processing Ruby on Rails Erlang
Long-running requests Go Erlang
Server-wide state Redis Erlang
Persistable data Redis / MongoDB Erlang
Background jobs Cron, Bash scripts, and Ruby Erlang
Service crash recovery Upstart Erlang

43. Review

44. Erlang review
• massive concurrency
• Processes
• OTP
• Virtual Machine
(BEAM)

45. Elixir review
• BEAM (Erlang VM)
• modern syntax
• macros
• tooling
• community
• documentation

46. Phoenix review
• pipelines
• changesets
• contexts
• channels/topics
• umbrella apps