The Enterprise Cloud
Download as PPT, PDF2 likes847 views
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.
The Enterprise Cloud
- 2. Agenda
- 6. $$$
- 7. What makes an enterprise uncool is also what defines it
- 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)
- 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
- 20. SPI Model SaaS PaaS IaaS
- 21. Agenda
- 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
- 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
- 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!