The Enterprise Cloud

1,708 views

Published on

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

Published in: Technology, Design
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,708
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
122
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • The Enterprise Cloud

    1. 1. The Enterprise Cloud
    2. 2. Agenda
    3. 3. What’s an “enterprise”?
    4. 6. $$$
    5. 7. What makes an enterprise uncool is also what defines it
    6. 8. What’s “the Cloud”?
    7. 9. (The Cloud >= (The Net = all things via Internet protocols >= (The Web = all things via HTTP)))
    8. 10. But the emerging consensus seems to be that “cloud” = “a unit of elastically usable resources accessible over a computer network”
    9. 11. “ Cloud computing”, then, is a style of architecture that exploits such a “cloud”
    10. 12. Making use of the Cloud is an architectural and engineering challenge.
    11. 13. Architecture is about making design choices. Engineering is about knowing your materials.
    12. 14. So what are the architectural choices? What are the materials?
    13. 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)
    14. 16. http://www.mindmeister.com/maps/show_public/15936058
    15. 17. But wait! Once that’s sorted, you have to consider contextual dimensions…
    16. 18. The Radeztsky Cube http://cloudforum.googlegroups.com/web/Metaverse+Decomposition.pdf
    17. 19. http://cloudforum.googlegroups.com/web/Metaverse+Decomposition.pdf
    18. 20. SPI Model SaaS PaaS IaaS
    19. 21. Agenda
    20. 22. http://twitter.com/gblnetwkr
    21. 23. http://twitter.com/gblnetwkr http://en.wikipedia.org/wiki/Consumerization
    22. 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
    23. 25. Agenda
    24. 26. “ Physical” perimeter Physical data centre Outside world Secure “gateway” (DMZ, firewall, etc.) Authentication + Authorization (Active Directory, LDAP, etc.)
    25. 27. “ Physical” perimeter Data centre cloud (VMware) Physical data centre Virtual servers Outside world
    26. 28. “ Physical” perimeter Cloud Provider (EC2) Data centre cloud (VMware) Physical data centre Virtual servers Outside world
    27. 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
    28. 30. If your needs / budget require or can accommodate it, consider RAIC
    29. 31. Redundant Array of Independent Cloud providers http://www.jroller.com/MasterMark/entry/raic_pronounce_it_rake_please
    30. 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
    31. 33. “ Physical” perimeter “ Virtual” perimeter Cloud Provider (EC2) Data centre cloud (VMware) Physical data centre Cloud Provider (SFDC) Cloud Provider (Mosso) Outside world
    32. 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
    33. 35. Note that this is not about, and never will be about, eliminating the internal data centre
    34. 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
    35. 37. Agenda
    36. 38. “ Things to worry about” sub-agenda
    37. 39. Since we worked out, sometime in the early ‘90s, what the architecture of a “client / server” system design looked like…
    38. 40. There's been a general consensus about a sort of a canonical architecture for so-called “N-tier systems”
    39. 41. Presentation Service Facáde Application Logic Data Persistence
    40. 42. What does the Cloud do to that?
    41. 43. In a nutshell: efficient horizontal scalability
    42. 44. And that means parallelism
    43. 45. Parallelism has significant consequences
    44. 46. It leads one to try to avoid stateful interactions
    45. 47. To prefer asynchronous communications (messages)…
    46. 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/
    47. 49. And it forces one to think strange things about optimal patterns of storing and accessing data
    48. 50. Like sharding one’s data to meet resource demands http://highscalability.com/unorthodox-approach-database-design-coming-shard/
    49. 51. Questions like “is two-phase commit a feature? Or a bug?” begin to seem important
    50. 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
    51. 53. This was happening anyway, driven by the clash of Web architecture with the established IT universe
    52. 54. Cloud computing’s possibilities are accelerating the process
    53. 55. In particular, we will need to address decomposition of our systems in two dimensions: app logic, and data
    54. 56. There is an emerging consensus about what the consequences of all this are for app logic (and overall system design)
    55. 57. “ The canonical cloud architecture that has evolved revolves around dynamically scalable CPUs consuming asynchronous, persistently queued events.” http://highscalability.com/canonical-cloud-architecture
    56. 58. http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1632&categoryID=102
    57. 59. <ul><li>Use scalable ingredients </li></ul><ul><ul><li>Eg. Hadoop on EC2 </li></ul></ul><ul><li>Keep ingredients loosely coupled </li></ul><ul><ul><li>All communication via persistent messaging </li></ul></ul><ul><li>Assume constant failure </li></ul><ul><ul><li>Design things to persist state, restart from last known good, and continue their own tasks even if all around them fail </li></ul></ul><ul><ul><li>Consider things like re-tries with exponential back-off </li></ul></ul><ul><ul><li>Build IN redundancy </li></ul></ul><ul><li>Learn about things like the POSA Blackboard pattern, tuplespaces, and Map / Reduce </li></ul>
    58. 60. Read this book! http://www.amazon.com/How-Write-Parallel-Programs-Course/dp/026203171X/ http://www.lindaspaces.com/book/
    59. 61. The impact on data design is much harder to articulate
    60. 62. Essentially, we optimize for the worst case, in typical current system designs
    61. 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.
    62. 64. This is very inefficient
    63. 65. Moving forward, we will have to think about how to slice and dice our data for more efficiency
    64. 66. What data is subject to which rules? What impact does that have on what needs to be stored where, in what fashion?
    65. 67. The goal will become: store the right data, in the optimal place.
    66. 68. “ Things to worry about” sub-agenda
    67. 69. You will likely run into the following problems:
    68. 70. 1) Static, manual processes to provision and manage VMs will probably not scale to demand.
    69. 71. You will find yourself wanting to archive (versioned) VMs, ensure VMs have specific attributes, and otherwise maintain governance.
    70. 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.
    71. 73. Again, there are tools available and emerging that can address some of these needs…
    72. 74. CohesiveFT ElsaticServer, rPath, Vmware, Enomalism, Elastra, 3Tera, many others
    73. 75. These tools have widely divergent solutions to these problems – choosing one involves many tradeoffs
    74. 76. 2) Static, manual configuration and management of your network and security infrastructure will probably not scale with demand.
    75. 77. There are tools on the market, available now and emerging, to meet this demand.
    76. 78. CohesiveFT VPN-Cubed, Cloudswitch, the next version of Cassatt, whatever vCloud and/or Cisco’s “the InterCloud” turn out to be, etc.
    77. 79. But wait! You forgot security!
    78. 80. “ Things to worry about” sub-agenda
    79. 81. “ Physical” perimeter “ Virtual&quot; perimeter Cloud Provider (EC2) Data centre cloud (VMware) Physical data centre Virtual servers Encrypted VLAN link Virtual switch / router / messaging broker Outside world
    80. 82. “ Things to worry about” sub-agenda
    81. 83. http://www.flickr.com/photos/peterpearson/347124844/
    82. 84. http://www.flickr.com/photos/paszczak000/2564969200/
    83. 85. http://en.wikipedia.org/wiki/Kurt_Gödel LOL!
    84. 86. http://www.flickr.com/photos/rachels_secret/220269351/
    85. 88. http://www.flickr.com/photos/euthman/2989437967/in/set-72057594114099781/
    86. 89. Get the slides: http://www.slideshare.net/mastermark/
    87. 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!

    ×