QCon SF 2009: Simon Guest, Patterns of Cloud Computing

These are my unedited notes from Simon Guest's talk about Patterns for Cloud Computing at QCon SF 2009.

"This talk is about Jim, he has many questions about cloud computing…"
5 pattern of cloud-based applications
Definition of cloud computing
Different models:
- Applications must run on-premises – complete control, upfront capital costs
- Application runs at a hoster – lower capital costs, but pay for fixed capacity even if idle
- Shared, multi-tenant, pay as you go – pay someone for a pool of computing resources that can be applied to a set of applications
Public Cloud vs. Private Cloud – private cloud useful e.g. for telcos offering this to their customers
Windows Azure – compute, storage, management, based on 64bit Windows images
SQL Azure - RDBMS
.NET Service - service bus and access control
[ed.: Who thinks of these names, and even more importantly, why doesn't Microsoft fire them?]
Different models infrastructure (IaaS) vs. Platform as a Service (PaaS) as main paths
Slide shows that MS offers a higher-level stack than Amazon - EC2 provides instance, Windows Azure model is a platform as a service model
[Seems to me this is one of the major problems of Azure – it seems neither one or the other, as I would define PaaS as what GAE does, which is much higher-level than simply a Windows Server]

Shows how to scale up a Web app using more machines, load balancer, database partitioning
A lot of work - a lot of money
Designed for peak capacity, idle for a lot of time
Much easier to let cloud vendor handle this dynamically
Prerequisite for successful scaling in the cloud: having a queue to decouple web tier and backend
Starbucks [of all possible examples! ;-)] as an example for queueing
Demo: "PrimeSolvr" (Web 2.0 because it's missing the last "e")
3 takeaways: 1) core tenet of cloud computing: ability to scale up/down 2) understand how to communicate between roles and nodes 3) strategy for when to scale up and down

Simply approach internally: one application per customer - works only for small numbers
Implications: Schema customizations, UI customizations
3 options for data in a multi-tenant environment: 1) share DB between customers 2) each customer gets a separate DB - hard to do on-premise, much easier in the cloud 3) fixed DB schema with customizations on a tenant-by-tenant basis
Demo: ASP.NET MVC app using the HTTP host name to switch UI and DB Schema
Takeaways: 1) Consider multi-tenancy first, hard to retrofit 2) Design considerations must include both data and UI specifics 3) Identity as a very important consideration, see MS Patterns and Practices paper on multi-tenancy ID

Popularized by MapReduce
Apache Hadoop, Cloudera, Amazon Elastic MapReduce, Hadoop implementation
Typical on-premise solution: very infrastructure-heavy, complex, expensive
No explicit framework implementation on Azure
Demo (inspired my MapReduce): Development Fabric (local execution environment), not using virtualization [similar to GAE environment]; next step is upload to Azure staging area, next level production
Takeaways: MapReduce very visible, although can be hard to initally grasp, learn about existing implementations; MS academic effort: Dryad

Problem: Affinity between hardware and data
how does the cloud help? breaks the affinity
virtualized layer between the data you store and the hardware underneath
Three ways: blobs, tables, relational
MS: Azure Blog Storage – REST API (using GET (even range requests) and PUT); PutBlock API to move blocks - transaction build up [must look this up]
Azure Table Storage (Key/Value pairs)
Initial relational effort: SQL Server Data Services (MIX 08) - REST API on top of SQL
Customer reaction: We want to do TDS (MS native DB protocol)
SQL Data Services (MIX 09), late SQL Azure: TDS (SQL Server) in the Cloud
Similarity between internal and cloud architecture makes it easier for customers [agreed, even though this might me more of a problem]
Demo: SQL Azure (http://sql.azure.com); Codeplex sqlazuremw (migration wizard) - migration from local SQL Server DB to the cloud (subset of SQL Server functionality, e.g. restrictions on certain value types, clustered indexes)
Takeaways: 1) Storage in the cloud may look the same, but breaks the affinity problem 2) Pricing is relevant 3) SQL Azure factor for moving to cloud in the first place=

Classic approach: VAN, now replace by Internet direct file transfers
Cloud approach: REST-based queues could be used for communication - not commonly used, problem: need to pass tokens around
Putting a web facade in front of the queue doesn't work too well either due to firewall problems. HTTP polling is bad [why?]
MS Solution: .NET Service Bus
TCP Relay: outbound bi-directional socket, tunneled through the bus and kept alive on both sides. Enables routing of arbitrary protocols across company boundaries
Alternative: Message Buffer, exposed using AtomPub, support retrieve, peek, lock
Takeaways: Be careful consuming REST-based queues because of shared secret
additional trouble because of REST
service bus as potential solution

Last question: How can patterns be integrated?

1) Sample PHP (!) application running on Windows Azure, ported to GAE and EC2 (as ASP.NET)
2) Map reduce spreads load across Amazon, Google, MS
3) Store results in SQL Azure database
4) Coordinate communication using .NET Service Bus
How many prime numbers between 1 and 10,000,000? 40 jobs of 250,000 numbers
WPF client app sends off job
"I'm gonna submnit the job and pray"
Spontaneous applause as the demo actually worked
make sure you have a clear definition of cloud computing
explore the 5 usage patterns
think about the next steps for implementation and migration