11

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?

Duncan
  • 341
  • 2
  • 9
  • 17
    Define *"cloud"* and we can tell you what you might want to know. The term *"cloud"* is marketing speak and means something different to each person who uses it. –  Sep 10 '12 at 11:44
  • I thought saying openstack cloud would be enough of a definition of what we are implementing on. See http://www.openstack.org/. Or are you requesting more info on the project? It's 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. – Duncan Sep 10 '12 at 13:03
  • I edited question to hopefully make it better and remove the 'marketing' concern. My issue is selecting the best tool for the job. I'm a rookie at stackexchange so don't quite have the hang of it. – Duncan Sep 10 '12 at 13:12
  • 1
    specifically the term *"cloud"* is nebulous and doesn't mean anything specific, it is marketing speak, you still haven't defined what actually qualifies something as a *cloud application*. Personally I know what I know what **I think** it means, I am sure **it isn't what you think it means**, given the question. –  Sep 12 '12 at 02:03
  • "the term 'cloud' is nebulous" - good one! It means virtual something and you should specify whether that "something" is software, operating-system, a single-machine, multi-machine-and-network, or something else. – GlenPeterson Sep 12 '12 at 04:05

3 Answers3

9

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.

pap
  • 1,290
  • 6
  • 8
  • 7
    Erlang was designed for *fault-tolerant* computing. It's just that *distributed computing* is a prerequesite for that (how can you reliably return a result if someone accidentally spills coffee over your single machine, you *need* at least two machines) and *parallel* and *concurrent computing* are just special cases of distributed computing, so Erlang also happens to be good at those. But that's not what it was designed for. – Jörg W Mittag Sep 10 '12 at 11:28
  • 1
    @JörgWMittag As long as we're splitting hairs... yes, it's _purpose_ was to achieve fault tolerance. It _achieved_ this through parallelization. It was _designed_ to _implement_ this in the AXE digital telephony switch which carried two isolated, parallel calculation pipes with one working as hot standby. – pap Sep 10 '12 at 11:33
  • 1
    Yes, sorry, I should have been more clear: cloud computing is distributed pretty much by definition, and it is often (not always but usually) implemented by clusters of inexpensive and more importantly *unreliable* machines but designed to deliver a reliable service. *That's* what makes Erlang such a good fit. – Jörg W Mittag Sep 10 '12 at 11:38
9

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.

Glorfindel
  • 3,137
  • 6
  • 25
  • 33
Jimmy Hoffa
  • 16,039
  • 3
  • 69
  • 80
  • About the "No Side Effects" you say "This is a very uncommon behavior among software languages" - I am a bit surprised at this. Can't Java and C# do this today? What languages do you know that has to have side effects when calling a function? – NoChance Sep 12 '12 at 02:59
  • 3
    @EmmadKareem It's not a question of whether you _can_ write a program without side-effects; as you noted, you can do this in Java or C#. It's whether the default is side-effect free, and whether there is compiler support for this. In Java you cannot, for example, tell the compiler "this method doesn't have side effects". This in turn means the compiler cannot warn you when you're breaking the rules! – Andres F. Sep 12 '12 at 03:27
  • @EmmadKareem I'm not saying it's impossible to write C# or java without side effects (though extremely rare), rather I'm saying that very few programming languages have strict policies built into the language that segregate functions with side effects from those without. – Jimmy Hoffa Sep 12 '12 at 03:34
  • It would be great if Java had a @NoSideEffects annotation to put on a method to tell the compiler to enforce no-side-effects for that method. In my own code I like to think it's common for methods to have no side effects. Sure, some methods have to be mutators in a language like Java, but many don't. Especially if you prefer immutable objects in your designs. – GlenPeterson Sep 12 '12 at 04:08
  • Jimmy Hoffa and @AndresF., thanks for your clarifications. – NoChance Sep 12 '12 at 04:12
  • @Jimmy Hoffa: I would also mention single-assignment (immutability) in your answer. Also, the Actor Model and message passing eliminates the need for shared variables and locks - two nightmares of concurrency in a language like Java. I'm just reading Wikipedia and citing my Java and XSLT experience and limited lisp/scheme experience - never used Erlang. Hope that helps. – GlenPeterson Sep 12 '12 at 04:13
  • @GlenPeterson Doesn't immutability in and of itself get rid of the need for locks? No shared variables being a side effect again of immutability. I will add immutability here though as it's a good point I'm surprised I didn't mention this in my answer! – Jimmy Hoffa Oct 24 '12 at 14:35
  • In C#, it is possible to mark a method with the [PureAttribute](http://msdn.microsoft.com/en-us/library/system.diagnostics.contracts.pureattribute.aspx) but, granted, it is not the default. – Louis Kottmann Oct 24 '12 at 15:41
  • @Baboon Awesome!! I see this is new with .NET 4 but that is totally awesome! Thanks for mentioning it! – Jimmy Hoffa Oct 24 '12 at 15:49
  • @JimmyHoffa Great question! I hope you don't mind that I posted it here: http://programmers.stackexchange.com/questions/171253/can-immutability-eliminate-the-need-for-locks-and-synchronized-blocks – GlenPeterson Oct 24 '12 at 18:30
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.

Garry Hodgson
  • 31
  • 3