We are starting a new project and implementing on our corporations’s instantiation of an openstack cloud (see http://www.openstack.org/). The project is security tooling for our corporation. We currently run many hundreds of dedicated servers for security tools and are moving them to our corporations instantiation of openstack.
Other projects in my company currently use erlang in several distributed server applications, and other Q/A point out erlang is used in several popular cloud services. I am trying to convince others to consider where it might be applicable on our project.
What are erlang’s strengths for cloud programming? Where are areas it is particularly appropriate to use erlang?
5
Other than the fact that Erlang was specifically developed to be run in concurrent/parallelized/distributed situations, the two main techniques that it employs making this possible are:
No side effects
This means, when you give a function a piece of data to execute against, it will not except in very strict cases affect anything else in the system/running process. This means that if you execute a function 300 times all at once concurrently, none of those 300 executions of the function will effect any of the others.
The implementation technique for ensuring no side effects is called “immutability” which roughly means, may not be mutated(changed). This means that as soon as you create a variable, the value of that variable may not be modified. Erlang implements this behavior with “single assignment” so after you assign a value to a variable, you may not assign a value to it again.
X = 1.
X = 2. // This is not a valid operation
This ensures no code may accidentally change the value of X causing a race condition, therefore it is inherently thread-safe and concurrent use becomes trivial. This is a very uncommon behavior among software languages and the biggest way Erlang manages to be so well suited for concurrent execution.
The actor model
This is a particular way of modelling that has shown to make the implementation and management of concurrent processing very simple for developers. Straight from Wikipedia:
The Actor model adopts the philosophy that everything is an actor.
This is similar to the everything is an object philosophy used by some
object-oriented programming languages, but differs in that
object-oriented software is typically executed sequentially, while the
Actor model is inherently concurrent. An actor is a computational
entity that, in response to a message it receives, can concurrently:
send a finite number of messages to other actors; create a finite
number of new actors; designate the behavior to be used for the next
message it receives. There is no assumed sequence to the above actions
and they could be carried out in parallel. Decoupling the sender from
communications sent was a fundamental advance of the Actor model
enabling asynchronous communication and control structures as patterns
of passing messages.
10
Erlang is particularly strong in concurrent/parallelized computing. In fact, it was designed originally for that very purpose. It has nothing inherent to do with cloud, except that oftentimes, calculation-heavy applications parallelized and deployed in “cloud” instances to make it easier to grow/shrink capacity on demand.
The rest is just marketing-speak.
3
One aspect of cloud that is different than traditional hardware deployments is the ease with which you can spin up new instances when needed. The ability to monitor other nodes, and processes on other nodes, makes it relatively simple to build highly dynamic systems that can add or remove vms and manage them as needed.
This is particularly so if you’re building your system using erlang’s OTP (Open Telecom PLatform) framework, which provides both structure and mechanisms (supervisor trees) to support building some pretty sophisticated stuff with far less effrot than you’d imagine. Erlang handles all the tricky bits so that you don’t have to.