This document summarizes a presentation about Erlang on Xen and new approaches to cloud software stacks. It introduces Erlang on Xen as a new Erlang runtime that runs without an operating system and is optimized for low startup latency. It then outlines 7 "commandments" of new cloud software, including running computations near data and avoiding administration. Two potential projects are described: developing a Dom0 based on Erlang on Xen, and evaluating all web scripts inside separate Xen domains for increased security and performance.

1. Erlang on Xen:
Redefining the cloud
software stack
erlangonxen.org
Xen Dev Summit
2013
1
Friday, 25 October 13

2. Today’s agenda
7 commandments of Newsoftware
+
2 project ideas
2
Friday, 25 October 13

3. Erlang on Xen 101
•
A new Erlang runtime, runs w/o OS
•
Conceived in 2009
•
Built from scratch, specifically to run on Xen
•
Optimised for low startup latency
•
Highly-compatible with Erlang/OTP
•
Not an open source (yet)
•
The public build service is free
•
EoX starts to exec Erlang code in 4-5 ms after the
launch
•
Sustainable spawning rate = 10 instances/sec
Friday, 25 October 13
3

4. 7 commandements of
Newsoftware:
1) Do not assume the presence of OS underneath
2) Software must be oblivious to boundaries of physical
nodes
3) All services must share the same auto-scalable fabric
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
Friday, 25 October 13

5. 1) Do not assume the presence of OS
underneath
-A full-featured kernel is an overkill for cloud instances
-Linux is optimised for very reliable long-living servers
-Unix-like access control does not help in the cloud
-Virtual devices require much simpler drivers
-Newsoftware will often run without a traditional OS
Library OS – implement OS-level functions as a
library – Mirage OS, OSv, rump kernels
Language runtime OS – use high-level language
for OS-level functions – Erlang on Xen
5
Friday, 25 October 13

6. 2) Software must be oblivious to
boundaries of physical nodes
-Cloud services make confines of a physical node less
relevant
-You can only scale so much vertically, horizontal is the
true scaling
-A user application should be ready to partition the
computation onto many instances
-Many services can be ephemeral – provisioned only
when needed
Current cloud stacks are not ready yet
Cloud management should become an integral
part of all standard libraries
6
Friday, 25 October 13

7. 3) All services must share the same
auto-scalable fabric
-Running cloud management stack isn’t
different from other tasks. All animals tasks
are equal.
-Cloud services should be elastic too – it would
be only too natural to implement them using
the same auto-scalable infrastructure
Packaging of cloud services as auto-scalable
applications paves the way to autonomous
clouds with far-reaching implications
7
Friday, 25 October 13

8. INTERMISSION: Zerg Demo
See zerg.erlangonxen.org — instance-per-request proof of
concept and check out the table at bottom of the page
Friday, 25 October 13
8

9. 4) Run computations near data they
process
-“Scanning” database queries shovel all data
through the network
-Especially unpleasant when joining
-The cloud storage hides the real topology too
well
-I/O traffic could congest datacenter’s networks
Storage nodes should be able to run lightweight data
processing instances
Xen provides the proper isolation for safe local data
processing
Friday, 25 October 13
9

10. 5) Child nodes get configuration from
the parent only
-Apps are really big nowadays, and are difficult to
understand
-Configuration is a mess of config files, scripts, and
Chef recipes
-Introducing proper hierarchy and order should help
-Erlang uses supervisor-workers scheme that works
and keeps things simple and understandable
The final destination is no manual configuration at all
10
Friday, 25 October 13

11. 6) Avoid “administration” at all costs
-Human beings can react to once-per-hour events,
not on the second (or millisecond) timescale
-Human admins do not scale well
-Apps should discover services they need and
make scaling decisions
-Traditional admin tasks go away due to simpler
Newsoftware stack
The final destination is no configuration at all
Many administration tasks can and should be automated
11
Friday, 25 October 13

12. 7) SMP is abomination of cloud
computing
-SMP hinders VM migration
-Datacenter is the computer for the Newsoftware
-No shared memory - use message passing
-Passing messages between VMs on a local host
is as fast as shared memory/locking
-Respawn smaller VMs are much faster
Services built from single-core VMs are much more
elastic and robust
12
Friday, 25 October 13

13. 2 project ideas:
1) Dom0 based on Erlang on Xen
2) Javascript in a Xen bottle
Friday, 25 October 13

14. 1) Dom0 based on Erlang on Xen
“Implement Xen toolstack in Erlang, remove Linux from
Dom0”
-Dom0 toolstack reminds strongly of Erlang – events,
pattern matching, multiple processes, etc
-xl is fast, yet not fast enough for on-demand
instance provisioning
-Use Linux inside unprivileged driver domains
Current status:
A prototype instance spawning interface developed –
in C and Erlang (zerg.erlangonxen.org)
14
Friday, 25 October 13

15. 2) Javascript in a Xen bottle
“Evaluate all web scripts inside a separate
Xen domain”
-Increase security of web browsing
-Use languages other than Javascript
-Run web scripts faster – native speed
15
Friday, 25 October 13

16. 2) Javascript in a Xen bottle
“Evaluate all web scripts inside a separate Xen domain”
-Increase security of web browsing
-Use languages other than Javascript
-Run web scripts faster – native speed
API calls
Browser
domain
Callbacks
Engine
domain
Spidermonkey
16
Friday, 25 October 13

17. Thank you. Questions?
17
Friday, 25 October 13