OPEN DATA CENTER ALLIANCE USAGE MODEL: Cloud Infrastructure Rev. 1.0

Transcription

1 OPEN DATA CENTER ALLIANCE USAGE MODEL: Cloud Infrastructure Rev. 1.0

2 Table of Contents Legal Notice...3 Executive Summary...4 Definitions...5 Purpose and Audience...5 Scope and Assumptions...5 Commonalities of Cloud Infrastructure...5 Differences between IaaS+ and PaaS...7 When to Aggregate Infrastructure...7 Impact of Premises...7 Sampling of the Current Cloud Infrastructure Ecosystem...8 General Cloud Infrastructure Capabilities...9 Usage Scenarios...10 Usage Scenario 1: Deploying an Enterprise, Cloud-Aware Production App to Cloud Infrastructure...10 Usage Scenario 2: Deploying an Enterprise Archiving Solution to Cloud Infrastructure...11 Related ODCA Documents...12 Recommended Industry Actions...13 Contributors Ed Simmons UBS Catherine Spence Intel Dave Casper MoogSoft 2

3 Legal Notice This Open Data Center Alliance SM Usage Model: Cloud Infrastructure document is proprietary to the Open Data Center Alliance (the Alliance ) and/or its successors and assigns. NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Alliance Participants are only granted the right to review, and make reference to or cite this document. Any such references or citations to this document must give the Alliance full attribution and must acknowledge the Alliance s copyright in this document. The proper copyright notice is as follows: 2015 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way without the prior express written permission of the Alliance. NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Alliance Participants is subject to the Alliance s bylaws and its other policies and procedures. NOTICE TO USERS GENERALLY: Users of this document should not reference any initial or recommended methodology, metric, requirements, criteria, or other content that may be contained in this document or in any other document distributed by the Alliance ( Initial Models ) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models. The contents of this document are intended for informational purposes only. Any proposals, recommendations or other content contained in this document, including, without limitation, the scope or content of any methodology, metric, requirements, or other criteria disclosed in this document (collectively, Criteria ), does not constitute an endorsement or recommendation by Alliance of such Criteria and does not mean that the Alliance will in the future develop any certification or compliance or testing programs to verify any future implementation or compliance with any of the Criteria. LEGAL DISCLAIMER: THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN AS IS BASIS. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE ALLIANCE (ALONG WITH THE CONTRIBUTORS TO THIS DOCUMENT) HEREBY DISCLAIM ALL REPRESENTATIONS, WARRANTIES AND/OR COVENANTS, EITHER EXPRESS OR IMPLIED, STATUTORY OR AT COMMON LAW, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, VALIDITY, AND/ OR NONINFRINGEMENT. THE INFORMATION CONTAINED IN THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY AND THE ALLIANCE MAKES NO REPRESENTATIONS, WARRANTIES AND/OR COVENANTS AS TO THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF, OR RELIANCE ON, ANY INFORMATION SET FORTH IN THIS DOCUMENT, OR AS TO THE ACCURACY OR RELIABILITY OF SUCH INFORMATION. EXCEPT AS OTHERWISE EXPRESSLY SET FORTH HEREIN, NOTHING CONTAINED IN THIS DOCUMENT SHALL BE DEEMED AS GRANTING YOU ANY KIND OF LICENSE IN THE DOCUMENT, OR ANY OF ITS CONTENTS, EITHER EXPRESSLY OR IMPLIEDLY, OR TO ANY INTELLECTUAL PROPERTY OWNED OR CONTROLLED BY THE ALLIANCE, INCLUDING, WITHOUT LIMITATION, ANY TRADEMARKS OF THE ALLIANCE. TRADEMARKS: OPEN DATA CENTER ALLIANCE SM, ODCA SM, and the OPEN DATA CENTER ALLIANCE logo are trade names, trademarks, and/or service marks (collectively Marks ) owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document does not grant any user of this document any rights to use any of the ODCA s Marks. All other service marks, trademarks and trade names reference herein are those of their respective owners. 3

4 OPEN DATA CENTER ALLIANCE USAGE MODEL: Cloud Infrastructure Rev. 1.0 Executive Summary The National Institute of Standards and Technology (NIST) 1 defines Infrastructure as a Service (IaaS) as including the following three components: Compute Networking Storage Closely mapping to those components are three ODCA Usage Models: 2 Compute Infrastructure as a Service (CIaaS) Rev. 2.0 Software-Defined Networking Rev. 2.0 Scale-Out Storage Rev. 1.0 While the segregation of infrastructure resources into these three components is useful to a degree, they are more appropriately considered as a cohesive set of aggregate resources that can be purchased, provisioned, and managed as a whole. This is especially important as the lines between software as a Service (SaaS), Platform as a Service (PaaS), and IaaS blur. SaaS offerings continue to add options and flexibility (thereby delving into PaaS); recently, the industry introduced the concept of IaaS+, which blurs the line between IaaS and PaaS by adding modular services on top of infrastructure services. This Cloud Infrastructure Usage Model uses IaaS+ as a starting point and addresses how cloud infrastructure compute, networking, storage, and related services and management facilities can be used in the marketplace. The Open Data Center Alliance s vision is that consumers will use this usage model, along with the others published by the ODCA, to guide their cloud service acquisition decisions, thereby increasing the standardization of cloud service consumption. This standardization will help make true cloud brokering possible across cloud service providers. 1 NIST is a non-regulatory federal agency that promotes U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. For more information about NIST, go to 2 See 4

5 Definitions The following table defines terms used throughout this document. Table 1. Terms and Definitions Term Infrastructure as a Service (IaaS) IaaS+ Platform as a Service (PaaS) Blueprint Definition This is the most fundamental cloud service model and is divided into three different offerings: compute, storage, and network. Each may exist in a variety of usage models. With IaaS, providers provision virtual machines (VMs) and other resources, such as object storage, virtual networking, or software bundles. This consists of the software platform and operating system on top of IaaS components. It is distinguished from PaaS in that the components stacked above the hypervisor are not run as a service. The users get their own instance of the component and are then responsible for supporting and maintaining it. This is a managed service that removes the need for the consumer to manage the complexities and details of the underlying infrastructure for an application. This describes a desired set of interrelated cloud resources, serving as the cloud equivalent to standard reference architectures. For example, a blueprint may prescribe a standard set of ports and configuration settings for a database to connect to middleware. Purpose and Audience This usage model defines how compute, network, and storage resources aggregate to form cloud infrastructure, and how that infrastructure may be consumed and managed holistically. This document serves a variety of groups, including but not limited to: Business decision makers looking for cost-efficient ways to maximize the value of information. For example, publishing information to internal and external stakeholders to increase engagement, satisfaction, and where appropriate create revenue-generating services with information. Risk management and security operation teams seeking a means to improve data controls for sensitivity, loss prevention, and data quality management in complex information architecture ecosystems. IT groups involved in planning, design, operations, and procurement that want to improve solutions from the cost/time efficiency of project delivery and on-going operations perspectives. Solution providers and technology vendors seeking to better understand customer needs and tailor service and product offerings. Standards organizations involved in defining standards that are open and relevant to end users. Scope and Assumptions It is presumed that underlying facilities such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) are understood. Commonalities of Cloud Infrastructure Compute, network, and storage share several common aspects: They are software-definable. Granted, what software defined means to networking differs from what it means for compute or storage, but these differences are environmental only, not fundamental. They can be virtualized. The industry is familiar with virtualized servers; the same is possible for networks and storage, thereby increasing utilization and expediting provisioning. They can be automated. As the industry moves from people consuming cloud services to machines consuming cloud services through automated workflows, each infrastructure component, and many subcomponents such as caching and data movement can be automated, using a modular approach through an API layer. 5

6 These common aspects form the foundation for this Cloud Infrastructure Usage Model, and underscore that what is important is that the capability whether it s load balancing, block storage, or a virtual private network (VPN) is offered as a service, not where that capability is on the stack. Figure 1 shows how purchasing, consuming, and managing compute, network, and storage services as a holistic package, along with the services comprising IaaS+, might work. Elastic compute and storage form the heart of the infrastructure. Compute workloads are dynamically and automatically balanced. Storage can be purchased by purpose: hot (accessed often), warm (accessed occasionally), or cold (accessed rarely); or by technology (scale-out, scale-up, or archives); or by business tier (mission critical, business important, general data). Dynamic perimeters are software-definable using APIs, while external- and internal-facing VPNs and content delivery networks (CDNs) provide pathways for I/O. Modular services, such as Database as a Service (DaaS), Cache as a Service (CaaS), and Queue as a Service (QaaS) are included as appropriate. The configuration of the entire IaaS+ landscape is defined and controlled by blueprints. As shown in the figure, IaaS+ does more than just provision virtual machines (VMs) and the underlying infrastructure. It includes a broad set of services that could be used along with the applications running on those VMs, as well as the necessary integration, security, orchestration, and abstraction functionality. Ideally, IaaS+ also adds the ability to auto-provision a standard set of blueprints engineered images for technology stacks (that is, the operating system, database services, and middleware) on top of the IaaS foundation via self-service. Dynamic Load Balance SDN/CDN I/O MODULAR SERVICES Provisioning database, cache, queue, or container NETWORK external facing Elastic Compute Elastic Storage HOT in-memory, ssd WARM COLD archive NETWORK internal facing BLUEPRINTS standards, library, management, deployment capabilities DEVOPS and compositional services DYNAMIC PERIMETERS (API, software definable) Figure 1. IaaS+ includes compute, network, and storage, along with other modular services, blurring the lines between IaaS and PaaS. 6

7 Packaging compute, network, storage, and associated management and control functions as an aggregate is especially beneficial to organizations taking a DevOps approach to software development. The DevOps approach stresses communication, collaboration, and integration between software developers and information technology (IT) operations professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services. Companies with release/ deployment automation want to more flexibly manage and drive this automation, without needing to enter everything manually at the command line. Developers are given more environment control, enabling them to define an infrastructure that is application-centric but still aligned with governance models of the organization. Differences between IaaS+ and PaaS The main difference between IaaS+ and PaaS lies in the service agreements. Generally, with PaaS the cloud service provider manages the middleware and operating system as well as the infrastructure. But with IaaS+, the service agreements generally are at the IaaS level; that is, consumers are responsible for managing their operating system, applications, middleware, and data, while the cloud service provider manages only virtualization, hardware, storage, and networking. Two other differences are that PaaS generally focuses on application development while IaaS and IaaS+ generally focus on operations, and IaaS+ requires a more modular approach than is typical of PaaS. Two examples may help illustrate the IaaS/IaaS+/PaaS relationship: VMware ESXi is a type 1 hypervisor it is simply about provisioning VMs (strictly IaaS). VMware vcenter Server, in contrast, is a centralized management application that helps enable centralized management of VMs (IaaS+). If a database is deployed on standard infrastructure and the service contracts are tied to infrastructure performance, that would involve IaaS+. However, if the database is deployed on IaaS with contracts tied to database performance, that would involve PaaS. When to Aggregate Infrastructure The ODCA strongly believes that, for the majority of cloud service use cases in the marketplace, the aggregate approach to compute, network, and storage resources is appropriate. However, the ODCA does recognize that there are several commonly encountered a la carte scenarios, such as the following: Compute. Grid and other CPU/memory-only purposes Networking. Virtual private networks (VPNs) Storage. Archive storage A compelling target that is ripe for aggregation of IaaS offerings is cloud-aware application development. For more information, refer to the document, Open Data Center Alliance Best Practices: Architecting Cloud-Aware Applications Rev Impact of Premises The ability and advisability of aggregating infrastructure services is not significantly affected by the location of the resources in a public/private hybrid model. However, in the case of the on-premises scenario, it may be appropriate to configure the private, on-premises cloud as closely as possible to the public cloud (or, conversely, choose a public cloud offering that closely resembles the private cloud configuration). Using separate domain suffixes and brokering security through gateways are two ways to isolate the private cloud from other existing on-premises infrastructures making it easier to control the configuration. Keeping the technical design of the on- and off-premises infrastructures consistent, as shown in Figure 2, makes it easier to aggregate and orchestrate resources across a hybrid cloud. It also provides a consistent user experience. OFF PREMISES ON PREMISES OpenStack Elastic Compute Elastic Storage HOT WARM COLD OpenStack Elastic Compute Elastic Storage HOT WARM COLD Figure 2. In a public/private hybrid model, it is recommended to isolate the on-premises infrastructure so that it retains a consistent configuration with the off-premises infrastructure. 7

8 Sampling of the Current Cloud Infrastructure Ecosystem It is impractical to list all the relevant players in the marketplace, but some bear notable mention. OASIS, a non-profit consortium that drives the development, convergence, and adoption of open standards for the global information society, has defined the Cloud Application Management for Platforms (CAMP) specification an interoperable protocol that cloud implementers can use to package and deploy their applications. CAMP defines interfaces for self-service provisioning, monitoring, and control. Based on Representational State Transfer (REST), CAMP is expected to foster an ecosystem of common tools, plugins, libraries and frameworks, which will allow vendors to add value. 3 Another OASIS project, the Topology and Orchestration Specification for Cloud Applications (TOSCA), shows great promise for enhancing the portability and management of cloud applications and services across their lifecycle. TOSCA s goal is to help enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown) independent of the supplier creating the service and any particular cloud provider or hosting technology. TOSCA also seeks to help enable higher-level operational behavior to be associated with cloud infrastructure management. 4 OpenStack, an open-source operating system, controls large pools of compute, network, and storage resources throughout a datacenter, managed through a dashboard or the OpenStack API. OpenStack works with popular enterprise and open-source technologies, making it attractive for heterogeneous infrastructures. 5 Heat is the main project in the OpenStack Orchestration program. It implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code. 6 Amazon Web Services (AWS) provides pay-as-you-go compute, network, and storage services, along with value-added services. 7 For example, Amazon Glacier is a web-based file storage service that provides storage for data archiving and backup. AWS Elastic Beanstalk enables developers to deploy and scale web applications and services developed in several languages on a variety of servers. AWS CloudFormation provides orchestration services. 8 VMware vcenter Server, a central VM management package, provides a centralized platform for managing VMs, enabling service consumers to easily automate and deliver a virtual infrastructure. 9 Microsoft Azure is an open and flexible public cloud platform that seeks to help enable consumers to quickly build, deploy, and manage applications across a global network of Microsoft-managed data centers. Azure supports VMs, but also includes modular services such as DaaS, mobile backends, and machine learning. 10 Cloud Foundry is a multi-language public cloud application platform that seeks to help enable developers to deploy, scale, and manage their applications in the cloud. 11 Docker is an open-source project that automates the deployment of applications inside software containers by providing an additional layer of abstraction and automation of operating system-level virtualization on Linux See 4 See 5 See 6 See wiki.openstack.org/wiki/heat 7 See aws.amazon.com 8 See aws.amazon.com/cloudformation 9 See 10 See azure.microsoft.com 11 See 12 See 8

9 General Cloud Infrastructure Capabilities Table 2 enumerates the ideal general capabilities both mandatory and optional for aggregated IaaS offerings. The features in the table are aligned with the ODCA Standard Units of Measure. For this usage model, it is not intended that all of the features in a given column must be supported as a group. In practice, a given service provider solution will combine different service levels for different elements. For example, all Bronze Performance feature requirements must first be met before combining features from any other performance level. For instance, Gold Network features can be combined with Bronze. Table 2. General Capabilities for Aggregated IaaS Offerings Mandatory Optional Category Capability Bronze Silver Gold Platinum Compute Able to manually scale out/back Able to automatically scale out/back Storage Able to manually scale out/back Able to automatically scale out/back Network Automated firewalls/acls Automated load balancing and traffic management Support for Software-Defined Network (SDN) for example, CDN Manual billing Automated billing Billing with integrated reporting Policy-based network management Isolation of the cloud from legacy infrastructure Ability to create VPN Automatic VPN creation Workload Compliant for workload in region X Compliant for moving workload from region X to region Y Workload is able to be locked to a region Modular Services Database as a Service Cache as a Service Queue as a Service DevOps/ Compositional Services Ability to store blueprints Blueprints in standard format (TOSCA, etc.) Ability to automatically deploy blueprints Policy (machine readable) Commercial (scaling limits)/sla scaling Workload placement (according to jurisdiction) Legal 9

10 Usage Scenarios The following two usage scenarios depict how an aggregated IaaS approach can work. Usage Scenario 1: Deploying an Enterprise, Cloud-Aware Production App to Cloud Infrastructure Business Drivers Automation, ease of deployment, and time to market. Goal Developer can focus only on workload, not on IaaS/IaaS+ details. Assumptions The enterprise app is cloud-aware and uses a language/stack commonly supported by cloud IaaS+ providers. Examples include: Apache HTTP Server for Node.js, PHP, and Python Passenger for Ruby IIS 7.5 for.net Apache Tomcat for Java Success Scenario 1 User is able to easily deploy a single-instance app to the cloud infrastructure without having to explicitly deploy individual compute, storage, and network components. Steps 1. Cloud subscriber logs in to cloud provider s web-based console. 2. Cloud subscriber provides a name for the app. 3. Cloud subscriber uploads the app. 4. Cloud subscriber accepts all configuration defaults, clicks save and clicks deploy. 5. Cloud subscriber specifies the max nodes policy. 6. App is immediately available via configured URL. The Amazon AWS Elastic Beanstalk video provides an example of the steps listed in the above Success Scenario. Failure Condition 1 Failed to deploy app. Failure Handling 1 Cloud provider and cloud subscriber are notified of failure per service-level agreement (SLA). Interfaces are used to enable clear analysis of reason for failure. Success Scenario 2 User is able to easily deploy an auto-scaling, load-balanced, multi-instance app to the cloud infrastructure without having to explicitly deploy individual compute, network, and storage components. Steps 1. Cloud subscriber logs in to cloud provider s web-based console. 2. Cloud subscriber provides a name for the app. 3. Cloud subscriber uploads the app. 4. Cloud subscriber accepts all configuration defaults, clicks save and clicks deploy. 5. Cloud subscriber uses the web administration console to specify that the app should auto-scale and be load-balanced. 6. App is immediately available via configured URL. 7. Workload on the app is scaled up and down as needed. 10

11 Failure Condition 1 Failed to deploy app. Failure Handling 1 Cloud provider and cloud subscriber are notified of failure per the SLA. Interfaces are used to provide clear analysis of reason for failure. Failure Condition 2 Failed to auto-scale app. Failure Handling 2 Cloud provider and cloud subscriber are notified of failure per the SLA. Interfaces are used to provide clear analysis of reason for failure. Discussion The lines between IaaS+ and PaaS continue to blur. This usage scenario could potentially be deployed on an IaaS+ offering, such as AWS Elastic Beanstalk, or to a PaaS offering, such as Cloud Foundry. What is important is the success of the deployment, not necessarily how it is deployed. Usage Scenario 2: Deploying an Enterprise Archiving Solution to Cloud Infrastructure Business Drivers Automation, ease of deployment, time to market, and flexible capacity. Goal Developer can focus only on workload, not on IaaS/IaaS+ details. Assumptions The enterprise archiving solution is vendor-agnostic and supports access to on-premises and cloud data repositories to accommodate short-term and long-term data archiving. Success Scenario 1 User is able to easily deploy an archiving solution that can use on-premises storage and cloud storage services, without worrying about individual storage and network components. Steps 1. Cloud subscriber enters cloud credentials into the archiving application. 2. Cloud subscriber provides name(s) and location(s) of application data sets (on-premises or cloud), specific retention and protection requirements, and deletion requirements for each application or data set being archived. Cloud subscribers can create templates (such as finance, external web, legal, manufacturing, human resources, user data, etc.). 3. Cloud subscriber helps enable archiving of data set(s) through archiving software solution. 4. Archiving software acts as gateway between source data stream and target storage. If on-premises repositories are reaching capacity limits, user-specified cloud storage is used as secondary tier of storage. 5. Archiving software attempts to retain short-term archive data in the on-premises storage. 6. Archiving storage automatically places long-term archive data in least expensive repository and automatically deletes files or objects 30 days after prescribed retention period. 7. Cloud subscriber can seamlessly view catalogs and restore files, objects, and directories from any archive. Failure Condition 1 Failed to restore files from archive. Failure Handling 1 Restore from disaster recovery copy of archive. 11

12 Success Scenario 2 Cloud subscriber needs to create an important, short-term, very large archival capacity. The service should make a copy of the data, provide data security over the network, and provide compute resources for data processing. Steps 1. Cloud subscriber prioritizes the archive as high priority. 2. Archive solution makes a copy of all relevant data, provides data security over the network, and provides compute resources for data processing. 3. Cloud subscriber verifies archive and processes the data as necessary. 4. The copy is deleted when no longer needed; space is rebalanced to minimize cost. Failure Condition 1 Failure to meet timelines to complete the job. Failure Handling 1 Add cloud storage providers or local storage on-the-fly to increase total aggregate bandwidth requirements. Failure Condition 2 Failure to correctly classify content, resulting in potential financial loss. Failure Handling 2 Provide cloud gateways that comprehend data classification and protection requirements to automatically route or restrict the transfer of specific classes of data. Related ODCA Documents Figure 3 shows a sampling of how ODCA documents relate to each other. The following ODCA documents, most of which are shown in the figure, are of particular interest to the cloud infrastructure discussion. 13 Standard Units of Measure for IaaS VM Interoperability Software Defined Networking Scale-out Storage Service Orchestration IaaS Privileged User Access Security Monitoring Identity Management Interoperability Guide The TOSCA proof of concept can be found here: ODCA Demos Software Application Portability in the Enterprise Cloud using the OASIS TOSCA Standard 13 Recently published ODCA documents do not appear in Figure 3. For a full list of available documents, visit the ODCA website. 12

13 IaaS Privileged User Access Single Sign-On Authentication Interoperability Across Clouds Provider Assurance Data Security Framework Data Security Standard Units of Measurement for IaaS Security Monitoring Regulatory Framework Scale-Out Storage Service Catalog Software Entitlement Management Framework Carbon Footprint and Energy Efficiency Long-Distance Migration VM Interoperability Commercial Framework Cloud-Based Identity Governance and Auditing SaaS Interoperability PaaS Interoperability Identity Management Interoperability Guide Cloud-Based Identity Provisioning Service Orchestration Information as a Service Compute Infrastructure as a Service Figure 3. Inter-relationship between ODCA documents. Recommended Industry Actions The ODCA recommends the following industry actions across cloud subscribers, cloud service providers, and the standards ecosystem: The ODCA has documented a rich set of cloud adoption requirements. We encourage enterprises to leverage the usage models and best practices as they consume cloud services. Cloud service providers should help to enable consumers to aggregate infrastructure resources and provide modular, value-added services as appropriate. This can help cloud service providers to accelerate cloud adoption and the pace of innovation offered through cloud computing. Standards bodies and cloud providers should define and implement standards that have cross-industry applicability and recognition. 13