JAOO 2008, Monday

This year, I'm attending JAOO -- for the first time. JAOO was once a Java-centric venue, but nowadays it has broader coverage.

Gregor Hohpe's The Internet as Platform: Programming the Cloud was about how systems developers should rethink their solution strategies. If scalability is of high priority, we need to give up luxuries, and give up some control:

• Luxuries would be traditional ACID and two-phase commit which are exchanged with compensation mechanisms, focus on idempotent operations, etc. Gregor presented a metaphor: In a coffee shop, asynchronous work processes result in high throughput, and error handling (if the customer didn't get the right coffee) is handled by retries. There are certainly many applications where relaxed consistency is acceptable; and there are settings where it's simply needed, for performance reasons. However, I feel that it's somewhat irrational to write off traditional ACID: ACID can make life of the systems developer much simpler due to not having to worry about sneaky compensation schemes. As not all applications need to be massively scalable, I believe that ACID should keep a prominent position in the systems developer's toolbox. Also: The World is not all about coffee shops: There are lots of applications where you can't just shrug and try again if something fails. (That said: I'm very sceptical of two-phase commits: I've seen several cases where it goes wrong and result in complicated situations.)
  
• Another of Gregor's points were about giving up control: As developers, we need to be more declarative and less imperative; that way, compilers and execution environments have a much better chance of parallelizing our work. This principle seems to be a general theme of this year's JAOO.
• Naturally, Gregor spent some time describing and demonstrating Google's exciting App Engine. App Engine is a cloud computing variant which works at a higher level than, for example, EC2: With App Engine, you dont' have to worry about operating system configuration, at the price of much fewer degrees of freedom. App Engine applications can "only" be written in a (large) subset of Python; certain cloud-unfriendly parts of Python have been cut away in order to ensure isolation between cloud guests. In addition to the Python language, App Engine developers can take advantage of a number of nice turn-key frameworks and APIs, e.g. for caching, authentication and data queries. Python is a great language, and cloud computing at a high level seems like a sensible idea, so I hope to get time to experiment with it at some point soon. My only grive about App Engine is: Why yet another query language? -- I'd much prefer a more SQL-like syntax.

Overall, Gregor's presentation was very well delivered and with interesting and thought-provoking statements.

Another presentation that I attended featured Guy Steele who gave an update on the progress of the Fortress programming language. Fortress is to be a programming language for high performance computing -- sort of Fortran++, although the syntax and the features of Fortress are rather different from Fortran. Fortress is designed with parallel execution in mind; e.g., many constructs are parallel by default, and if sequential execution is wanted, this has to be explicitly stated. Fortress is clearly aimed at the mathematically inclined programmers: It has operating overloading 'on steroids', in combination with tools to present source code with just about any glyph, such as greek letters. Note: Fortress is an imperative language; I was beginning to think that functional languages with minimal side effects would be the only way forward here.

Finally, I attended a panel discussion about cloud computing. The session wasn't as interesting as I had hoped for; maybe people were a bit tired in the afternoon. Discussion within the panel lacked energy, and there wasn't much audience involvement. I asked the panel to comment on two of the obstacles for cloud computing which I see. Where I work, we actually have some perfect use cases for cloud computing, in principle: Once a month, for example, we run some heavy computations which take several days and cause much stress, while at other times, the hardware is more or less idle. However, 1) what about security, i.e. protection of privacy sensible data, and 2) where is the business case if we need to upload ½ terabyte of data before the computations can start? My conclusion from the subsequent discussion was that we aren't going to be using EC2 for our computations any time soon, sadly. (Another unfortunate problem is that we rely heavily on SAS programs, and SAS Institute is notorious for virtualization-unfriendly licensing. But mayby SAS will wake up some day -- and perhaps even work with Amazon to provide access to SAS on EC2 nodes, charged by the hour?)

Apart from attending presentations, I had a chance to talk to a people in the exhibition area.

Among those were Red Hat which has recently opened a (small) office in Denmark.

I talked with people from the Danish National IT and Telecom Agency (ITST) about project-ideas for ITST's Software Exchange: I've recently had vague ideas about some identity management code which would be nice to have in the agency where I work; this might be in the scope of the Software Exchange. And I think that many public sector organizations would be able to make good use of a project charged with adding LDAP-based group definitions to per-directory access controls in Subversion.

Finally, I got a chance to shake hands with Stefan Tilkov. I recently listened to a podcast where Stefan did a great job of explaining the (very sound) ideas behind REST.