1 / 22

Value Proposition and Challenges of Cloud Computing

Value Proposition and Challenges of Cloud Computing. Steven A. Warner, Ph.D NGIS/ATG/Technology August 2009. What is Cloud Computing?. Hype, smoke & mirrors, snake oil A new way of looking at buying and managing IT infrastructure and applications

Télécharger la présentation

Value Proposition and Challenges of Cloud Computing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Value Proposition and Challenges of Cloud Computing Steven A. Warner, Ph.D NGIS/ATG/Technology August 2009

  2. What is Cloud Computing? • Hype, smoke & mirrors, snake oil • A new way of looking at buying and managing IT infrastructure and applications • Something we’ve been doing for a long time but with a different name • A great way to make my budget go farther • A great way to burn up my budget faster • Not sure, I hear different definitions Confused?

  3. Cloud Computing Defined • NIST.GOV definition: Cloud computing is a model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. • This is a user-centric view and highlights: • Access method = availability, convenience, on-demand, via network, • Computing method = shared pools, configurable virtualized resources, including application, storage, and print • Setup = rapid provisioning/release, dynamic scalability, minimal management and service-provider interaction • “Pay-per-use” where relevant (differs from “hosted” environments, where model is “pay for maximum capacity”) • Not a technology but a means for using technology (or façade for the user) • Treats IT more as a utility than as a capital expense (etc.) that must be managed and upgraded

  4. Business Drivers • A recent working group identified potential government savings of $6.6 B over the next three years through cloud/SaaS (IDC: Total Cloud Market $42B by 2012) • Economics • Cost avoidance • Capital purchase • Power! • Maintenance • Staff • Pay for only what you use – do not need to size systems to maximum capacity required (also simplifies planning) • Enables some reallocation of budgets, assets, and people into primary business/mission areas or other IT tasks • Agility • Avoids capital procurement timing • Very rapid access to new capabilities/capacity – provides a way to add/increase services “just-in-time” without investing in new infrastructure, training new personnel, or licensing new software

  5. Delivery Models • Good industry agreement on three major layered models: • Software-as-a-Service (SaaS) Clouds, where an application environment is provided • Platform-as-a-Service (PaaS) Clouds, where an application development platform is provided • Infrastructure-as-a-Service (IaaS), where infrastructure capabilities such as storage or a bare operating system are provided • Within each model there is the dimension of ownership: • Public (someone else owns it outside of the enterprise – either hosted or open) • Can be either a consumer or enterprise market model • Private (the enterprise has sole ownership) • Focus is enterprise, not consumer market • Many dimensions to private, the “enterprise” can potentially include groups of enterprises, special interest groups, etc. Diagram courtesy of Cloud Security Alliance

  6. Implementation Patterns • Transference -- Take an existing on-premises application and move it to the cloud. • Drivers include economics, consolidation, and prototyping • Often includes “out-sourcing” • Development and Multi-Tenancy – Develop, assess, and operate new applications with unknown loadings without requiring a full initial capital investment. • Drivers are rapid and inexpensive prototyping, verification/validation, and risk reduction. • Surge (aka Burst) -- Ability to handle additional requirements on an as-needed basis. • Drivers are economic – avoiding paying for over-capacity. • Elastic Storage -- Application can grow exponentially from a value-added storage perspective. • Drivers are economic – avoiding paying for over-capacity – and also risk reduction. For example, data replication for disaster recovery, near-line storage for less frequently accessed data, archiving, backup • Collaboration – Moving shared inter-organizational resources into a common area. • Driver is ease of management, also keeps traffic out of the enterprise’s internal network.

  7. Implementation Patterns (continued) • These patterns drive various deployment models: • Pure Cloud – everything is in the cloud (whether internal, external private, or external hosted; or SaaS, PaaS, or IaaS) • Cloud <-> Cloud -- two to many, could federate • Enterprise <-> Cloud – hybrid of on-premises and one or more clouds (this will become a common scenario) • New design possibilities arise: • If we assume host virtualization is a core component of any PaaS or SaaS solution… • Virtual machines then become a fundamental level of application component (eliminates need for a common run-time across complex multi-component applications) • This will change how we design multi-tier applications, especially with state-less, clustered components (e.g. application servers) • However the added complexity emphasizes the need for good architecture, security, data classification, and systems engineering practices that takes into account the unique aspects of the cloud paradigm

  8. How to Build a Cloud (High-Level) • First and foremost (!), execute using good systems engineering practices! • Begin with governance • Understand goals, objectives, and requirements • Define an architecture, then design services, infrastructure, etc. to it • Obtain a suitable infrastructure of arbitrarily adequate capacity with network access • Virtualize the infrastructure and secure it • Add requisite components if goal is SaaS • Provide a means for end-users to obtain and release resources upon request in a dynamic manner (where relevant, to be charged for use also)

  9. The Virtual Private Cloud Communications Circuit(dedicated, Internet, etc.) Partners Public Clouds (External) External Hosted Applications Semi-Private Cloud (External) Private Cloud (External) Public Cloud (External) Public Clouds (External) Public Clouds (External) Enterprise Private Cloud (Internal) Inter-Cloud Access Non-Cloud Local Applications Inter-Cloud Access The Virtual Private Cloud is the aggregate of all the above environments.

  10. Challenges to Adoption

  11. Challenges to Adoption (continued)

  12. Challenges to Adoption (continued) • Understanding of the Paradigm • Definition: Lack of agreement over what exactly constitutes “cloud computing” • Confusion: Over what benefits cloud computing will provide, and the trade-offs • Multi-Tenancy: • How comfortable is an enterprise in storing its data in an environment shared with other customers? • What is the risk and the mitigation for data leakage? • How does this differ from what we did in the mainframe era? • Outrageous Vendor Claims and Obfuscation of Challenges: • Hinder understanding of cloud computing • What exactly are we buying? • To what is the vendor committing (especially true for a hosting vendor)?

  13. Challenges to Adoption (continued) • Understanding of the Paradigm (continued) • Role changes: The CIO (or equivalent) may need to evolve to a general contractor in many areas. • Lock-In: • How difficult would it be to move large volumes of data to a different cloud (cloud provider)? • This is both a procedural and a technical issue (format, bandwidth)

  14. Challenges to Adoption (continued) • Implementation and Operations • Architecture: • There is much disagreement over the necessary elements for a cloud technical architecture, and the elements are not mature. • In addition, SOA is the best approach for interface to clouds, yet culture for SOA success is immature and poorly understood. • There is much discussion over common cloud APIs, but none exist • Manageability: from the user perspective: • Existing management tools do not seem to be able to track metrics for applications that may reside on a varying number of different systems (not a problem where solution is a single VM) • How does asset management change in the cloud? • Distributed Management Task Force (DMTF) has initiated a working group to address (http://www.dmtf.org/about/cloud-incubator) • Memory limits within VM technology: VMs, which are approaching being a requisite design element, can address less memory than the physical OS. The latest product releases largely obviate this limitation. • WAN performance: Many geographies still are limited in their backbone capacity.

  15. Challenges to Adoption (continued) • Implementation and Operations (continued) • Loss of control: Will business elements of the enterprise bypass the enterprise’s IT organization? • Governance: • In which deployment models and use-cases does this play? • Is governance antithetical to the concept of cloud? • Will lack of governance aggravate problems already associated with lack of SOA governance? • Provisioning: For SaaS, how will applications and application components be provisioned? • Licensing: Vendors have been slow to develop appropriate models. • Confidence: As to reliability, scalability, and security in public clouds (economics will also drive cloud vendors to minimize costs)

  16. Challenges to Adoption (continued) • Implementation and Operations (continued) • Motivation for the Provider: • Ideally, providers keep just ahead of demand • May provide motivation for providers to federate and sell capacity to each other as do utility companies. Are there lessons from the power utility companies? • Aggravates manageability problem • Is the capacity really there for surge levels? Will another tenant’s surge impede your ability to do the same? • Service-Level Agreements: There have been effectively no substantive guarantees from public cloud providers.

  17. Challenges to Adoption (continued) • Security and Compliance • Threat Models: What new models arise in the cloud? Have we further aggravated issues already present within SOA and with standard computing vulnerabilities? • Examples: • Dynamic virtual machines – How much control to the user? • Resource isolation (appropriate isolation measures are needed): • VM-to-VM attacks • Data leakage • Weakened perimeter – Firewall ports enabling user access are a vulnerability • Patch and security control management – Becomes the user’s responsibility; aggravated by VM dynamism • Hybrid usage – Consistency of control; ensuring the user understands where their data resides • Administrative access across networks – A vulnerability also inconsistent with some security policies

  18. Challenges to Adoption (continued) • Security and Compliance (continued) • Cross-Domain Security: How does an organization extend or federate its authentication and authorization mechanisms into the cloud? • Data-at-Rest Security: What encryption and segregation mechanisms are provided? • Auditability: Can access to the data be audited? • Are data storage formats even amenable to auditing (more of an issue for chunking types of storage that lose the concept of a file)? • Forensics, as applications are not linked to physical infrastructure and the number of physical assets in play may vary • Accreditation in the Cloud: • How can you tell a cloud is “secure”? • Is there governing policy and procedures to accredit a cloud? • What processes and controls must be in place? (Pre-accredited clouds may actually simplify this process)

  19. Challenges to Adoption (continued) • Security and Compliance (continued) • Compliance: May preclude cloud paradigm in some cases due to: • Physical chain of custody requirements • Regulatory requirements • Physical Location: • Do you know what country your cloud resides in? • Would you know if it changed? • What compliance requirements change? • Is there governing law that recognizes the paradigm? • Conclusions: • There are many challenges to adoption of the cloud paradigm • Public clouds and private clouds have different sets of challenges, with some overlap

  20. Federal Government Environments • There are a few early adopters or near term plans: • “GovCloud”: • Significant interest by the Obama Administration in cloud computing, recognizing the following possible applications: • End-user communications and computing • Secure virtualized data centers • Portals, collaboration and messaging • Content, information, and records management • Workflow and case management • Data analytics, visualization, and reporting • Enterprise business applications • DISA Rapid Access Computing Environment (RACE) – a PaaS solution for DoD users, with option for hardened environment • Nimbus – cloud computing environment at Argonne National Laboratories • NIST – much thought leadership by Peter Mell and Tim Grance – has defined the need for a Cloud Interoperability Profile

  21. So What Can I Do Today? • Good public cloud applications today (look for high “wow factor”) • Backup/restore • Publication of shared (sanitized) data • Business analytics • Development, test, prototyping • Good private cloud applications today • Almost anything unless there is a high security or compliance requirement • Wait for public cloud • Mission-critical applications • Security- or compliance-sensitive data

More Related