This document discusses key aspects of enterprise cloud computing including definitions of cloud computing, the SPI model of cloud services, and architectural choices and challenges presented by cloud computing. Some of the main challenges mentioned are the need for elastic resources, stateless and asynchronous system designs, data sharding, and ensuring redundancy and high availability despite constant failures.

1. The Enterprise Cloud

2. Agenda

3. What’s an “enterprise”?

6. $$$

7. What makes an enterprise uncool is also what defines it

8. What’s “the Cloud”?

9. (The Cloud >= (The Net = all things via Internet protocols >= (The Web = all things via HTTP)))

10. But the emerging consensus seems to be that “cloud” = “a unit of elastically usable resources accessible over a computer network”

11. “ Cloud computing”, then, is a style of architecture that exploits such a “cloud”

12. Making use of the Cloud is an architectural and engineering challenge.

13. Architecture is about making design choices. Engineering is about knowing your materials.

14. So what are the architectural choices? What are the materials?

15. http://rationalsecurity.typepad.com/blog/2009/01/cloud-computing-taxonomy-ontology-please-review.html http://cloudcomputing.sys-con.com/node/811519 http://www.collab-ogce.org/gce08/images/7/76/LamiaYouseff.pdf SADIST-PIMP SPI (SaaS, Paas, IaaS)

16. http://www.mindmeister.com/maps/show_public/15936058

17. But wait! Once that’s sorted, you have to consider contextual dimensions…

18. The Radeztsky Cube http://cloudforum.googlegroups.com/web/Metaverse+Decomposition.pdf

19. http://cloudforum.googlegroups.com/web/Metaverse+Decomposition.pdf

20. SPI Model SaaS PaaS IaaS

21. Agenda

22. http://twitter.com/gblnetwkr

23. http://twitter.com/gblnetwkr http://en.wikipedia.org/wiki/Consumerization

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

25. Agenda

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

37. Agenda

38. “ Things to worry about” sub-agenda

39. Since we worked out, sometime in the early ‘90s, what the architecture of a “client / server” system design looked like…

40. There's been a general consensus about a sort of a canonical architecture for so-called “N-tier systems”

41. Presentation Service Facáde Application Logic Data Persistence

42. What does the Cloud do to that?

43. In a nutshell: efficient horizontal scalability

44. And that means parallelism

45. Parallelism has significant consequences

46. It leads one to try to avoid stateful interactions

47. To prefer asynchronous communications (messages)…

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

54. Cloud computing’s possibilities are accelerating the process

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

58. http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1632&categoryID=102

59. Use scalable ingredients Eg. Hadoop on EC2 Keep ingredients loosely coupled All communication via persistent messaging Assume constant failure Design things to persist state, restart from last known good, and continue their own tasks even if all around them fail Consider things like re-tries with exponential back-off Build IN redundancy Learn about things like the POSA Blackboard pattern, tuplespaces, and Map / Reduce

60. Read this book! http://www.amazon.com/How-Write-Parallel-Programs-Course/dp/026203171X/ http://www.lindaspaces.com/book/

61. The impact on data design is much harder to articulate

62. Essentially, we optimize for the worst case, in typical current system designs

63. “ What’s the most strict, stringent requirement we have to fulfill?” OK, make the entire system meet it. Store all data in that bucket.

64. This is very inefficient

65. Moving forward, we will have to think about how to slice and dice our data for more efficiency

66. What data is subject to which rules? What impact does that have on what needs to be stored where, in what fashion?

67. The goal will become: store the right data, in the optimal place.

68. “ Things to worry about” sub-agenda

69. You will likely run into the following problems:

70. 1) Static, manual processes to provision and manage VMs will probably not scale to demand.

71. You will find yourself wanting to archive (versioned) VMs, ensure VMs have specific attributes, and otherwise maintain governance.

72. But you will also need a way to maintain the “self-service” factor, or risk torpedoing a significant part of the value proposition of the Cloud.

73. Again, there are tools available and emerging that can address some of these needs…

74. CohesiveFT ElsaticServer, rPath, Vmware, Enomalism, Elastra, 3Tera, many others

75. These tools have widely divergent solutions to these problems – choosing one involves many tradeoffs

76. 2) Static, manual configuration and management of your network and security infrastructure will probably not scale with demand.

77. There are tools on the market, available now and emerging, to meet this demand.

78. CohesiveFT VPN-Cubed, Cloudswitch, the next version of Cassatt, whatever vCloud and/or Cisco’s “the InterCloud” turn out to be, etc.

79. But wait! You forgot security!

80. “ Things to worry about” sub-agenda

81. “ 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

82. “ Things to worry about” sub-agenda

83. http://www.flickr.com/photos/peterpearson/347124844/

84. http://www.flickr.com/photos/paszczak000/2564969200/

85. http://en.wikipedia.org/wiki/Kurt_Gödel LOL!

86. http://www.flickr.com/photos/rachels_secret/220269351/

88. http://www.flickr.com/photos/euthman/2989437967/in/set-72057594114099781/

89. Get the slides: http://www.slideshare.net/mastermark/

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!