The Enterprise Cloud

  • 1,270 views
Uploaded on

Presentation given on April 21st, 2009 for the first CloudSlam conference (http://cloudslam09.com/)

Presentation given on April 21st, 2009 for the first CloudSlam conference (http://cloudslam09.com/)

More in: Technology , Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,270
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
117
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Enterprise Cloud
  • 2. Agenda
  • 3. What’s an “enterprise”?
  • 4.  
  • 5.  
  • 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/
  • 87.  
  • 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!