How ERLANG helps in building high performance cloud applications

Posted by in Others category on for Beginner level | Points: 250 | Views : 6232 red flag

In this article we will see how Erlang helps in building high performance cloud applications


Cloud computing is the delivery of computing as a service, in which shared resources, software, and information are provided to computers and other devices as a utility over the network. So, there is a need for a programming language that will allow us to write reliable, scalable, production distributed systems.

This need tells us about true concurrency. What we need is a lightweight process with no shared memory, asynchronous message communication and mechanisms to change code on the fly so that programs can evolve and change as they run in non-stop systems.

Erlang Programming Language is a perfect choice in this jargon not only for developing applications, but also for empowering cloud infrastructure.

In this article we will observe the capability and strength of Erlang programming language for building reliable and scalable cloud applications using some of it's native features like concurrency, distribution, Hot code upgrade etc. that will help to run applications easily in the cloud.


Erlang is a programming language designed for developing robust systems of programs that can be distributed among different computers in a network. Developed in the 1980s at the Ericsson Computer Science Laboratory to address a then-unfulfilled need for telecommunications programming, it has evolved as a general purpose concurrency-oriented functional programming language suited for fault-tolerant, error recovery, distributed, soft real-time systems since then. It supports hot swapping, so that code can be changed without stopping a system.

Although its roots are in telecommunications, Erlang's unique features and extensive library make it suitable as a general-purpose programming language and well-suited to programming projects such as network servers, control systems and web development.

Though the same behavior can be achieved by using other contemporary languages, however, the proponents of Erlang claim that it is superior to those when developing back-end systems that require: fault tolerance, distributed processing, a large amount of concurrent activity, real time response times in milliseconds, and non-stop operation.


So what do we really mean by "concurrent"? Is it just another word for "in parallel"? Well, almost but not exactly, at least when we’re talking about computers and programming. One popular semi-formal definition reads something like “those things that don’t have anything that forces them to happen in a specific order are said to be concurrent".

For example, given the task to sort two packs of cards, we could sort one first, and then the other or we could sort both in parallel. There is nothing that requires us to do them in a certain order; hence, they are concurrent tasks, they can be done in either order, or we can jump back and forth between the tasks until they’re both done, or, if we have the extra appendages, we can perform them simultaneously in true parallel fashion.

This may sound strange: shouldn’t we say that tasks are concurrent only if they are actually happening at the same time? Well, the point with that definition is that they could happen at the same time, and we are free to schedule them at our convenience. Tasks that need to be done simultaneously together are not really separate tasks at all.

One of the really nice things that Erlang does is that it helps us with the physical execution: if there are extra CPUs (or cores or hyper threads) available, it will use them to run more concurrent processes in parallel—if not, it will use what CPU power there is to do them all a bit at a time. The Erlang programs automatically adapt to different hardware—they just run more efficiently if there are more CPUs, as long as we have things lined up that can be done concurrently.

Thread and Concurrency - The old model has some problem

The traditional way of offering concurrency in a programming language is by using threads. In this model, the execution of the program is split up into concurrently running tasks. It is as if the program is being executed multiple times, the difference being that each of these copies operated on shared memory.

This can lead to a series of hard to debug problems, as can be seen below. The first problem, on the left, is the lost-update problem. Suppose two processes try to increment the value of a shared object acc. They retrieve the value of the object, increment the value and store it back into the shared object. As these operations are not atomic, it is possible that their execution gets interleaved, leading to an incorrectly updated value of acc, as shown in the example.

The solution to these problems is the use of locks. Locks provide mutual exclusion, meaning that only one process can acquire the lock at the same time. By using a locking protocol, making sure the right locks are acquired before using an object, lost-update problems are avoided. However, locks have their own share of problems. One of them is the deadlock problem, which is pictured on the right. In this example two processes try to acquire the same two locks A and B. When both do so, but in a different order, a deadlock occurs. Both wait on the other to release the lock, which will never happen.

These are just some of the problems that might occur when attempting to use threads and locks.

Erlang takes a different approach to concurrency: the Actor Model.

The Actor Model

The Actor Model, was first proposed by Carl Hewitt in 1973 takes a different approach to concurrency, which should avoid the problems caused by threading and locking.

In the actor model, each object is an actor. This is an entity that has a mailbox and behaviour. Messages can be exchanged between actors, which will be buffered in the mailbox. Upon receiving a message, the behavior of the actor is executed, upon which the actor can: send a number of messages to other actors, create a number of actors and assume new behavior for the next message to be received.

Of importance in this model is that all communications are performed asynchronously. This implies that the sender does not wait for a message to be received upon sending it, it immediately continues its execution. There are no guarantees in which order messages will be received by the recipient, but they will eventually be delivered.

A second important property is that all communications happen by means of messages: there is no shared state between actors. If an actor wishes to obtain information about the internal state of another actor, it will have to use messages to request this information. This allows actors to control access to their state, avoiding problems like the lost-update problem. Manipulation of the internal state also happens through messages.

Each actor runs concurrently with other actors: it can be seen as a small independently running process.

Actors in Erlang

In Erlang, which is designed for concurrency, distribution and scalability, actors are part of the language itself. Actors in Erlang are called processes and are started using the built-in spawn function. Let us see the Actor Model concept into action with a very simple example.

In this application, an actor is defined which acts as a basic counter. We send 100.000 increment messages to the actor and then request it to print its internal value.

-export([run/0, counter/1]).
run() ->
    S = spawn(counter, counter, [0]),
    send_msgs(S, 100000),
counter(Sum) ->
        value -> io:fwrite("Value is ~w~n", [Sum]);
        {inc, Amount} -> counter(Sum+Amount)
send_msgs(_, 0) -> true;
send_msgs(S, Count) ->
    S ! {inc, 1},
    send_msgs(S, Count-1).
% Usage:
%    1> c(counter).
%    2> S = counter:run().
%       ... Wait a bit until all children have run ...
%    3> S ! value.
%    Value is 100000

The Run function starts a counter process and starts sending increment messages. Sending these messages happens using the message-passing operator (!). As Erlang is a purely functional language, it has no loop structures. Therefore, this has to be expressed using recursion. These extremely deep recursion stacks would lead to stack overflows in Java, yet Erlang is optimized for these usage patterns. The increment message in this example also carries a parameter, to show Erlangs parameter capabilities. The state of the counter is also maintained using recursion: upon receiving an inc message, the counter calls itself with the new value which causes it to receive the next message. If no messages are available yet, the counter will block and wait for the next message.

Actor scheduling in Erlang

Erlang uses a preemptive scheduler for the scheduling of processes. When they have executed for a too long period of time (usually measured in the amount of methods invoked or the amount of CPU-cycles used), or when they enter a receive statement with no messages available, the process is halted and placed on a scheduling queue.

This allows for a large number of processes to run, with a certain amount of fairness. Long running computations will not cause other processes to become unresponsive.

Starting with release R11B, the Erlang run-time environment has support for symmetric multiprocessing (SMP). This means that it is able to schedule processes in parallel on multiple CPUs, allowing it to take advantage of multi-core processors. The functional nature of Erlang allows for easy parallelization. An Erlang lightweight process (actor) will never run in parallel on multiple processors, but using a multi-threaded run-time allows multiple processes to run at the same time. Big performance speedups have been observed using this technique. Also applications can be scaled horizontally by sing this technique.

Distributed Erlang

Erlang programs are designed to run on networks of computers and that can coordinate their activities only by message passing.

Distributed Erlang provides a method for programming applications that run on a set of tightly coupled computers. In distributed Erlang, programs are written to run on Erlang nodes. We can spawn a process on any node, and all the message passing and error handling primitives work as in the single node case.

Distributed Erlang applications run in a trusted environment- since any node can perform any operation on any other Erlang node, a high degree of trust is involved. Typically distributed Erlang applications will be run on clusters on the same LAN and behind a firewall, though they can run in an open network.

The central concept in distributed Erlang is the node. A node is a self contained Erlang system containing a complete virtual machine with its own address space and own set of processes. Access to a single node or set of nodes is secured by a cookie system. Each node has a single cookie, and this cookie must be the same as the cookies of any nodes to which the node talks. To ensure this, all the nodes in a distributed Erlang system must have been started with the same magic cookie or have their cookie changed to the same value by evaluating erlang:set_cookie. The set of connected nodes having the same cookie defines an Erlang cluster.

As a simple example, we can show how to spawn a process on a remote node.

-export([rpc/4, start/1]).
start(Node) ->
spawn(Node, fun() -> loop() end).
rpc(Pid, M, F, A) ->
Pid ! {rpc, self(), M, F, A},
{Pid, Response} ->
loop() ->
{rpc, Pid, M, F, A} ->
Pid ! {self(), (catch apply(M, F, A))},

Then we start two nodes; both nodes have to be able to load this code. If both nodes are on the same host, then this is not a problem. We merely start two Erlang nodes from the same directory. If the nodes are on two physically separated nodes with different file systems, then the program must be copied to all nodes and compiled before starting both the nodes.

So it is clear that Erlang is designed to be run in a distributed environment. An Erlang virtual machine is called an Erlang node. A distributed Erlang system is a network of Erlang nodes. An Erlang node can create parallel processes running on other nodes, which perhaps use other operating systems. Processes residing on different nodes communicate in exactly the same way as processes residing on the same node. This in turn boost performance in applications and brings high scalability.

Hot Code Upgrade

In a real-time control system we often don't want to stop the system in order to upgrade the code. In certain real-time control systems we may never be able to turn off the system to perform upgrades, and such systems have to be designed with dynamic code upgrades in mind.

When we write app in Erlang, we get dynamic code upgrade support for free when we use OTP.This can save hundreds of hours of time in development.

This is a common Erlang development workflow:

  1. •Start the app.
  2. •Edit the code
  3. •Recompile. (one keystroke)

That's it! There is no restart step. The app gets updated with the new code while its running and tests get run automatically to ensure there are no regressions.


  1. Erlang Web site
  2. Erlang course
  3. Armstrong, J. 2007. Programming Erlang: Software for a Concurrent World. Raleigh, NC: The Pragmatic Bookshelf
  4. Armstrong, J. 2003. Making reliable distributed systems in the presence of software errors. Ph.D. thesis, Swedish Institute of Computer Science


So in this article, we have seen how Erlang helps in building high performance cloud applications.Hope this will be helpful.Thanks for reading.

Page copy protected against web site content infringement by Copyscape

About the Author

Full Name: Niladri Biswas
Member Level: Platinum
Member Status: Member
Member Since: 10/25/2010 11:04:24 AM
Country: India
Best Regards, Niladri Biswas
Technical Lead at HCL Technologies

Login to vote for this post.

Comments or Responses

Login to post response

Comment using Facebook(Author doesn't get notification)