Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Erlang on Xen:
the four themes
erlangonxen.org
kiev::fprog 2013
1
Friday, 2 August 13
The four themes
1. “Truly elastic services”
2. “Ephemeral servers”
3. “Autonomous clouds”
4. “Data-local computations”
2
F...
Erlang on Xen 101
• Erlang runtime, runs over bare Xen w/o OS
• Built from scratch, not a “port”
• Conceived in 2009
• Hig...
1. “Truly elastic services”
● Erlang on Xen instances (VMs) start to execute
Erlang code 4-5ms after the launch
● Sustaina...
2. “Ephemeral servers”
● Zero-footprint clouds – waiting services do not
exist/consume resources
● Weave a computing envir...
Demo: Zerg
zerg.erlangonxen.org — instance-per-request proof of concept
6
Friday, 2 August 13
3. “Autonomous clouds”
● OS-less instances are generally smaller, short-
lived and easy to migrate
● Applications can mana...
4. “Data-local computations”
● Erlang on Xen instances are building blocks of
future databases
● “Scanning” queries should...
Demo: A 1000-node cluster
● Each node in its turn
– Waits for a message to arrive (receive)
– Spawns a new node
– Waits fo...
Demo: A 1000-node cluster
10
Friday, 2 August 13
7 commandments of a NewSoftware
1. Do not assume the presence of OS underneath
2. Software must be oblivious to boundaries...
Thank you. Questions?
12
Friday, 2 August 13
Upcoming SlideShare
Loading in …5
×

Erlang On Xen @ Kiev Functional Programming event, Aug 3 2013

2,209 views

Published on

Explains how Erlang On Xen can transform cloud computing in future

Published in: Technology, News & Politics
  • Be the first to comment

Erlang On Xen @ Kiev Functional Programming event, Aug 3 2013

  1. 1. Erlang on Xen: the four themes erlangonxen.org kiev::fprog 2013 1 Friday, 2 August 13
  2. 2. The four themes 1. “Truly elastic services” 2. “Ephemeral servers” 3. “Autonomous clouds” 4. “Data-local computations” 2 Friday, 2 August 13
  3. 3. Erlang on Xen 101 • Erlang runtime, runs over bare Xen w/o OS • Built from scratch, not a “port” • Conceived in 2009 • Highly-compatible with Erlang/OTP • Optimised for low startup latency • Not an open source (yet) • The public build service is free 3 Friday, 2 August 13
  4. 4. 1. “Truly elastic services” ● Erlang on Xen instances (VMs) start to execute Erlang code 4-5ms after the launch ● Sustainable spawning rate = 10 VMs/sec ● See rush.erlangonxen.org ● Let the application decide how many nodes are needed ● Spawning a node mimics spawning an Erlang process 4 Friday, 2 August 13
  5. 5. 2. “Ephemeral servers” ● Zero-footprint clouds – waiting services do not exist/consume resources ● Weave a computing environment and lease resources on demand only ● Startup latency for Erlang on Xen fits a “processing window” ● A single physical node may host thousands (or millions) of ephemeral servers ● Better granularity and easier development 5 Friday, 2 August 13
  6. 6. Demo: Zerg zerg.erlangonxen.org — instance-per-request proof of concept 6 Friday, 2 August 13
  7. 7. 3. “Autonomous clouds” ● OS-less instances are generally smaller, short- lived and easy to migrate ● Applications can manage themselves ● No Chef/Puppet anymore ● A cloud infrastructure can become fully autonomous ● Applications and data stay legally under the user’s control 7 Friday, 2 August 13
  8. 8. 4. “Data-local computations” ● Erlang on Xen instances are building blocks of future databases ● “Scanning” queries should spawn many processing instances close to data ● ... 8 Friday, 2 August 13
  9. 9. Demo: A 1000-node cluster ● Each node in its turn – Waits for a message to arrive (receive) – Spawns a new node – Waits for the new node to become available – Runs a local ring of 7,777 processes – Mounts a share on the new node (9p) – Writes the message to /peer/mailbox – the write gets converted into Erlang message passing – Waits for 3 seconds – Destroys itself 9 Friday, 2 August 13
  10. 10. Demo: A 1000-node cluster 10 Friday, 2 August 13
  11. 11. 7 commandments of a NewSoftware 1. Do not assume the presence of OS underneath 2. Software must be oblivious to boundaries of physical nodes 3. All services share the same auto-scalable infrastructure 4. Run computations near the data they process 5. Child nodes get configuration from the parent only 6. Avoid “administration” at all costs 7. SMP is abomination of cloud computing 11 Friday, 2 August 13
  12. 12. Thank you. Questions? 12 Friday, 2 August 13

×