I’m on my way back from the UC Berkeley’s RADlab winter retreat at Lake Tahoe. I’m really grateful to Prof. Randy Katz and the UC Berkeley faculty for inviting me.

RADlab’s vision is to enable one person (possibly the next Pierre Omidyar) to single-handedly invent and operationalize the next multi-million-user service (possibly the next eBay) over the course of a long weekend. RADlab’s retreat is an opportunity for industry leaders to mix with faculty and students to review the progress and provide feedback.

Over these intense three days, students and faculty gave excellent talks and demonstrations. Things that I can call-out in a (very) short list:

• By now, it is commonplace for researchers and students to develop, test, and run on cloud;
• Ruby has made it into the classroom. I’ve seen some impressive term projects with very little code written (and, interestingly enough, the test code has more lines than the actual code);
• Machine learning is alive! I have found some encouraging proof points in scaling up/down resources, generating equivalent synthetic workloads, timely detecting datacenter problems by way of signature correlation, etc.;
• A scalable data store (scads) for which cost/user doesn’t increase and there’s a declarative language to set performance/consistency tradeoffs;
• Use of a performance model to perform accurate diagnosis while using just about 10% of log data;

I often think about the scale divide between those who can get behind the curtains of internet-scale data centers (often times, in the 10^5 servers realm) and those who cannot. Those who have access typically have limited freedom to chase high-risk, high-payout propositions. Next-gen infrastructure researchers must get a chance to see their artifacts operating at scale. What can researchers and practitioners do to bridge the scale divide to a mutual advantage? I’ve seen that students clearly extract a lot of value out of their internships. Without a doubt, internships are a great win-win-win. Also, I’ve heard speakers asking for anonymized production traces. Unfortunately, this is a tough nut to crack … in the web age, the unintended ripple effects of taking traces out of the house give many corporations the heebie jeebies.

I look forward to monitoring the continued progress of RADlab.

In my Cloud-related outings, there are a couple of topics that I especially like to expand on (my view) or get hung up on (in all likelihood, my audience’s view :

Accountability (as in: where’s a throat to choke . In general, Cloud providers are not liable for any data loss, IPR loss, downtime, etc. For an enterprise, this is a key departure from outsourcing, hosting, B2B, … which all have some form of indemnification and a clear chain of accountabilities or escalation should things go horribly wrong (i.e., starting from the CIO nearest the boo boo). How will Fortune 500 enterprises overcome the fact that Cloud business rests on reputation only?

Availability: in my opinion, it’s one of two things. Either we think in terms of legacy applications and live by traditional KPI goals like three- or five-nines uptime that are comparable to (say) the dialtone service. Or else we come up with entirely novel application paradigms and stop looking at cloud availability with the glasses of the 1980s. After all, we have already settled for a much lower-quality wireless dialtone and can live with dialtone-less homes whenever power goes off (there was enough extra value for us to compromise on those). What we cannot do – I submit – is to run unchanged legacy applications on-Cloud and pretend to live by some new, lax KPIs.