Xconomy put together a cloud computing event at Akamai‘s HQ in Cambridge today. The location was appropriate since Akamai was one of the first companies to work on computing in the cloud or, more specifically, at the edge of the network.

I spoke on a panel with Google, IBM, Microsoft and Sun. Their offering are somewhere between vaporware and beta.

• Google recently launched App Engine
• IBM has a big vision and is mastering resources internally
• Microsoft is trying to equate enterprise application hosting and SaaS as cloud services
• Sun recently did a beta release of Project Caroline.

Absent from the discussion due to schedules was Amazon, so I had to be the one to talk about Amazon Web Services. For the record, I like what AWS is doing for the simple reasons that (a) they shipped early and (b) they took a very open approach to the core of cloud computing (EC2 and S3).

The audience focused Q&A on a couple of interesting areas: SLAs/reliability, where is became clear that one-size cloud computing would not fit all, and security/privacy, which is indeed a very interesting topic, especially when one considers, for example, what governments can force your cloud services provider to do with your data.

There are three complementary approaches to both topics or, for that matter, any facet of value-add on top of the core infrastructure-as-a-service cloud computing layer:

• You can architect a solution that achieves your objectives based on core cloud services. For example, since many startups don’t trust Amazon S3 and EC2 not to fail they have made alternative provisions. In another example, one can introduce application-level encryption such that Amazon or Google only keep encrypted data and don’t have access to the keys.
• You can rely on enhanced cloud services, e.g., data encryption add-ins or spreading servers across different zones with an automatic failover layer maintained by the cloud service provider (CSP), etc. This carries potential lock-in implications in exchange for having to solve less of the problem yourself.
• Rather than solving the problem through technology, you can solve it through processes and contracts. For example, failure to meet SLAs can carry financial penalties.