What will be the programming language of the Cloud?

When I used to be responsible for building on-premise enterprise systems I railed against heterogeneity. I understood that architectures based on ‘best of breed’ solutions were typically less than the sum of the parts (if they worked at all). I believe in collective code ownership but that means that when the resident Python guru says “I could easily knock up a quick script to do that” or the long-time Smalltalker says “this bit of the system would be so much better built in Seaside” the implication is that the whole team has to learn Python or Seaside. I believe in simplicity, and whilst using “the best tool for the job” is a form of simplicity getting even just two techies to agree what the best tool for any given job actually is is a task in itself. Having a small, well-defined set of technologies is, to my mind, far simpler than having an ever-growing morass of different tools, languages, applications and libraries.

After twelve months of doing serious development on force.com we have a relatively small and well-defined set of technologies:

  • All application code and unit tests written in Visualforce and Apex – the languages of the force.com platform – plus JQuery/Javascript for added client-side dynamism
  • System test code written in Java (we could use any other language that has a binding for Selenium WebDriver but all the dev team has a lot of Java experience behind them)
  • Build written in Ant running via Bash scripts on EC2
  • Force.com IDE

And that’s it.

But something is threatening my nice safe, sanitised and homogenous Utopia: pesky customers. Because one customer needs to have some of the data from our service appear in their Microsoft Office suite we now have a small utility written in C# and WPF. And because other customers love the idea of accessing some services and data from within MS apps this is going to get bigger and more complicated. Because another customer wants a feature that the force.com platform can’t support, and we think this is going to be a good core feature to offer other clients, we’re going to have to build it using Google App Engine, or maybe in Java/Tomcat on EC2, or maybe in Ruby or …

All of which got me thinking: what might become the dominant programming language of the cloud? Apex is syntactically similar to Java and Google AppEngine is effectively a cut-down version of Java. But the ever growing complexity of the language and the shenanigans of Sun and now Oracle (not to mention Apple) lead me to think Java will not too shortly be appearing in various lists of legacy technologies. Ruby is simpler than Java but I never got the feeling that it was that much better and, if it wasn’t for Rails, would probably be nothing more than vaguely interesting. The various functional programming languages genuinely do offer something different to Java or Ruby but, at the moment, their support for some of the fundamentals of cloud computing are a bit limited: web services in Haskell anyone?

I even went so far as to start to draw up a list of the characteristics for my perfect cloud language before realisation dawned:

I’m asking the wrong question.

Because one of the great things about coding in the cloud is the incredible variety of platforms and services offered and their different strengths and weaknesses. Want to store and distribute files in the cloud? Use Amazon S3 … there is no language to learn as such, just a simple REST API. Need to run your build process in the cloud? Use whatever your favourite technology is and spawn up an EC2 instance to run it in. Need an application for capturing, managing and reporting on information? Force.com is a great bet.

I can’t wait for the first functional programming cloud platform that will allow us to write functional transforms and drop them in such that we can call them with a URL and get the results back in XML or JSON form. Amazon Hadoop offers some basic data transformation and calculation services in the cloud and I’m sure many other types of calculation and data manipulation engines will start to appear. When vector processing becomes truly cloud-based we’ll have many further options for data processing.

The idea that one language could support all, or even a significant majority, of these types of service is patently ludicrous and the only conclusion I can make is that the principle of homogeneous technology stacks belongs with a lot of the other principles I used to apply to building large systems: in the past. Its going to be a challenge to embrace the heterogeous future of Apex + Java + C# + Javascript + Ruby(?) + Scala(?) + Pig + ???, plus the different platforms they support or are supported by, but I’ve come to believe that this old dog is going to have to learn a lot of new tricks if he’s to get the most out of the cloud.

Advertisements

7 thoughts on “What will be the programming language of the Cloud?

  1. Perl Child

    You could say the cloud language is already here (it’s javascript) and only Microsoft’s security protections for office(how easy is it to target office through javascript from the web? not that easy, there’s been too many system-level hacks). But basically, everything you said about needing WPF or tomcat could just be reduced to using json/js to drive office directly, bypassing the middlemen. This is important why? Because JS is on all the devices, unlike flash, or office, for that matter. Ever since apple put an “ok” JS engine in safari on ipods/iphones, and the other manufacturers followed suit, this has been the 800 white elephant in the room. People will be ok today about needing their pc to massage data in complex ways. But as tablets and phones get more and more powerful, that tolerance will go away. Joe Random Customer who cares not a whit about technology will say “I want to access this from wherever I am, because this is incredibly time sensitive information that cannot wait” and the market will have to follow suit.

    Reply
    1. pauldyson Post author

      Thanks for your comment.

      You could say that JS is the language but I’ve come to believe that ubiquity and homogeneity are old-fashioned concepts in the cloud. Ruby on rails hosted on heroku makes delivering user-centric web-apps far easier than Node.js on the same platform. Force.com makes delivering MIS and CRM type systems even easier than RoR on Heroku. I think Functional Programming languages will make a huge contribution once the supporting infrastructure for a cloud-based FP service is reality (and I’ve yet to see Clojure on Heroku so we may be on the first rung of the ladder already).

      I’ve grown to love Javascript but see its role firmly on the client. I may be wrong about this and, in the end, if someone writes something as well thought out and support as RoR in JS it may come to dominate. But I don’t see any pressing need to rush to a single language and so think it is unlikely to happen.

      Reply
  2. akoprowski

    Great post! And an intriguing question, indeed.
    Regarding functional programming in the cloud; you say: “I can’t wait for the first functional programming cloud platform that will allow us to write functional transforms and drop them in such that we can call them with a URL and get the results back in XML or JSON form.”. Well, wait no more; enters Opa 🙂
    Opa is a new functional programming language that is cloud-ready and targets the web. Its big selling point, I think, is that it allows to code for the heterogeneous web eco-system in one coherent language with one paradigm. In particular: all client-server communication is transparently taken care of by Opa, the client code (JS) is generated from Opa code and even the client-server distribution is automated (and can be fine-tuned for performance/security with simple annotations). Also Opa offers the complete technology stack: web server, database and distribution framework are all part of the language.
    Granted, it’s a very new language that still has to gain traction and to prove itself in the field. But we (I’m part of the MLstate team working on Opa) strongly believe in it and are determined to work hard to gain its user base, adoption and wide recognition. We’d love to hear what you think about Opa. You can find more information on http://opalang.org and on Opa’s blog: http://blog.opalang.org.

    Reply
    1. pauldyson Post author

      Thanks for your comment. Opa sounds very interesting and I’ll certainly check it out. My only caveat is that I don’t currently have a need for FP type services in our technology stack so it won’t be much more than a play at this point, but I’ll also pass on details to a few people I know who use FP a lot. Regardless, its great to see people pushing the boundaries of this stuff so I wish you all the best with it.

      Reply
  3. pauldyson Post author

    A brief update ten months on from the original post. Over the past six month, we have branched further out than the technology stack described. Today we consider our platform as consisting of three pillars: force.com, Ruby-on-Rails running on Heroku, and AWS.

    Force.com is, as it always was, at the core, providing the UI for our application suite and most of its functionality.

    RoR/Heroku provides web services that extend the core application. My doubts about Rails have been more than answered by Rails 3 and our experience of Heroku is been of a fantastic, well thought-out and well-supported service. No wonder Salesforce bought them.

    We always did use some Amazon services, mostly S3 and a bit of EC2 for running our automated build. We now more extensively use EC2, specifically with Elastic Beanstalk, to run services written in Java where RoR/Heroku aren’t appropriate (e.g. where we rely on libraries only available in Java, or Heroku’s limited temporary filestore is an issue for us), and to provide a fail-over in the case of a Heroku outage (and, yes, we understand the extent to which a Heroku outage might itself be caused by problems in Amazon’s data centres). We’ve also started using some additional Amazon Services; quite possibly the gold standard model for how to provide open, simple, accessible services to cloud developers.

    Reply
  4. Petri Kivikangas

    How about Scala? It has been designed to support distributed computing, and clouds by nature are distributed. Scala also works on JVM (well, almost any language nowadays does: Python, Ruby, Clojure, JavaScript, and so on).

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s