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:
- 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.