I was at the London CloudCamp last night, with a large crowd, mostly techies. Gojko Adzic has posted a comprehensive reviewalready!

I ran an open space (break-out) session on persistence in cloud applications. As Gojko points out, we didn't have time to get into as much detail as I'd hoped - in fact, we didn't even get through my list of questions! However, the fact that the largest number of people were interested in persistence in clouds was the most interesting feedback - at least I'm not alone in puzzling over this area!

As we didn't even finish the introduction and list the questions(!) during the session, here's a brief summary of the background:

• My company's interest is in offering consultancy services in this area, so I'd like to know what we're talking about, surprisingly.  We also produce model-driven generators for application development, and we have a version for the GigaSpaces platform called GigaSystemBuilder: this just does the nuts and bolts right now, no persistence like the others.
• GigaSpaces is somewhat different from other grid/cloud solutions in that it focusses on grid components that integrate both data and processing - see Nati Shalom's explanation.  It also provides partitioned clustering that is handled by the container, so the power of a cluster can be beefed up at run-time if the system gets hot.
• So the stage seems to be set to handle really fast data-oriented applications.  But my feeling - shared with others, if discussions after the session are anything to go by - is that there is still a gap between an enterprise application developer's view of how to handle data and the grid vendors'.  An impedance mismatch, as it were.
• Seasoned campaigners of large-scale distributed computing like Eric Brewer and Pat Helland tell us that programming for large-scale, distributed applications is a different kettle of fish to your dad's J2EE.
• So the master question was, what will the dominant architecture be in 5 years time for cloud/grid applications.  And this becomes really interesting if the architecture shows how to do data persistence at grid-like speeds, but with traditional database systems' reliability.

There does seem to be a "missing link" (as one participant put it) here - a layer between the classical 'entity' layer and a physical persistence service, to handle the  details of distributed multi-layer transactions for data operations, plus miscellaneous twiddly bits (e.g. allocating unique sequence numbers across a partitioned architecture).  Hopefully we can make this area easy enough for take-up by large numbers of application developers, and simple enough that they can produce a fast scalable architecture without too many tears (or tiers).

If you have an interest in this area, let me know and I'll share more of the detail behind this.  Hopefully I'll be posting a thought-out paper in a couple of weeks.