24. Four sources of pressure driving change: a perfect storm Consumerization - Massive scale services - Tech smart consumers Collaboration - Moving from vertical integration to horizontal, networked biz model Computing Anywhere - Rising demand for mobility to support faster response to customers Corporate IT challenges - OPEX, CAPEX, DC power, space, business responsiveness Le Cloud
26. “ Physical” perimeter Physical data centre Outside world Secure “gateway” (DMZ, firewall, etc.) Authentication + Authorization (Active Directory, LDAP, etc.)
27. “ Physical” perimeter Data centre cloud (VMware) Physical data centre Virtual servers Outside world
28. “ Physical” perimeter Cloud Provider (EC2) Data centre cloud (VMware) Physical data centre Virtual servers Outside world
29. “ Physical” perimeter “ Virtual" perimeter Cloud Provider (EC2) Data centre cloud (VMware) Physical data centre Virtual servers Encrypted VLAN link Virtual switch / router / messaging broker Outside world
30. If your needs / budget require or can accommodate it, consider RAIC
31. Redundant Array of Independent Cloud providers http://www.jroller.com/MasterMark/entry/raic_pronounce_it_rake_please
32. “ Physical” perimeter “ Virtual” perimeter Cloud Provider (EC2) Data centre cloud (VMware) Physical data centre Encrypted VLAN link Cloud Provider (Flexiscale) Virtual servers Outside world
33. “ Physical” perimeter “ Virtual” perimeter Cloud Provider (EC2) Data centre cloud (VMware) Physical data centre Cloud Provider (SFDC) Cloud Provider (Mosso) Outside world
34. “ Physical” perimeter “ Virtual” perimeter Data centre cloud (VMware) Physical data centre Marketplace / Broker / Orchestratror Cloud Provider (Mosso) Cloud Provider (EC2) Cloud Provider (Flexiscale) Outside world
35. Note that this is not about, and never will be about, eliminating the internal data centre
36. “ Physical” perimeter “ Virtual” perimeter Data centre cloud (VMware) Physical data centre Marketplace / Broker / Orchestratror Cloud Provider (Mosso) Cloud Provider (EC2) Cloud Provider (Flexiscale) Outside world
48. One finds oneself on the front lines of the REST War ™ – the battle of the RESTafarians vs. the established IT Universe http://www.dehora.net/journal/2008/07/25/patterns-of-web-architecture/ http://www.dehora.net/journal/2008/08/15/rest-as-an-engineering-discipline/ http://www.infoq.com/articles/webber-rest-workflow/ http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven/ http://www.redmonk.com/jgovernor/2009/02/12/the-rest-of-the-cloud/ http://delicious.com/mastermark/rest/
49. And it forces one to think strange things about optimal patterns of storing and accessing data
50. Like sharding one’s data to meet resource demands http://highscalability.com/unorthodox-approach-database-design-coming-shard/
51. Questions like “is two-phase commit a feature? Or a bug?” begin to seem important
52. New terms, like CAP, Paxos and BASE creep into conversations about “eventual consistency” http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.1495 http://en.wikipedia.org/wiki/Paxos_algorithm http://queue.acm.org/detail.cfm?id=1394128 http://www.allthingsdistributed.com/2008/12/eventually_consistent.html
53. This was happening anyway, driven by the clash of Web architecture with the established IT universe
55. In particular, we will need to address decomposition of our systems in two dimensions: app logic, and data
56. There is an emerging consensus about what the consequences of all this are for app logic (and overall system design)
57. “ The canonical cloud architecture that has evolved revolves around dynamically scalable CPUs consuming asynchronous, persistently queued events.” http://highscalability.com/canonical-cloud-architecture
90. Join the conversation: http://groups.google.com/group/cloud-computing/ http://groups.google.com/group/cloudforum http://tech.groups.yahoo.com/group/cloudcomputing-tech/ … and please come talk to us, as well … http://twitter.com/mastermark http://www.jroller.com/MasterMark/ Thanks!