These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Transcription

1

2

3 Cloud Architecture FOR DUMmIES ORACLE SPECIAL EDITION by Michael Wessler, OCP & CISSP

4 Cloud Architecture For Dummies, Oracle Special Edition Published by John Wiley & Sons, Inc. 111 River St. Hoboken, NJ Copyright 2012 by John Wiley & Sons, Inc., Hoboken, New Jersey Published by John Wiley & Sons, Inc., Hoboken, New Jersey No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) , fax (201) , or online at Trademarks: Wiley, the Wiley logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. Oracle is a registered trademark of Oracle International Corporation. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book. LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HERE- FROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAP- PEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ. For general information on our other products and services, please contact our Business Development Department in the U.S. at For details on how to create a custom For Dummies book for your business or organization, contact info@dummies.biz. For information about licensing the For Dummies brand for products or services, contact BrandedRights&Licenses@Wiley.com. ISBN: (pbk); (ebk) Manufactured in the United States of America

5 Contents at a Glance Introduction... 1 Chapter 1: Cloud Characteristics and Definitions... 3 Cloud Computing Defined...5 Benefits of a Cloud Architecture...5 Challenges to Cloud Architecture...6 Chapter 2: Cloud Architecture... 9 Service Models...9 Deployment Models...11 Hybrid Cloud Scenarios...13 Architecture Principles and Guidelines...16 Chapter 3: Cloud Modeling Cloud Perspective...20 Cloud Maturity Model...21 Logical Views...24 Cloud Management...26 Chapter 4: Cloud Implementation Engineered Systems...31 Oracle Product Mapping...33 Oracle s Public Cloud Offerings...36 Chapter 5: Ten (Okay, Nine) Things to Consider When Moving to a Cloud Model... 37

6 Publisher s Acknowledgments We re proud of this book and of the people who worked on it. For details on how to create a custom For Dummies book for your business or organization, contact info@dummies.biz. For details on licensing the For Dummies brand for products or services, contact BrandedRights&Licenses@Wiley.com. Some of the people who helped bring this book to market include the following: Acquisitions, Editorial, and Vertical Websites Senior Project Editor: Zoë Wykes Editorial Manager: Rev Mengle Acquisitions Editor: Katie Feltman Senior Business Development Representative: Karen L. Hattan Custom Publishing Project Specialist: Michael Sullivan Composition Services Senior Project Coordinator: Kristie Rees Layout and Graphics: Carrie A. Cesavice, Lavonne Roberts Proofreader: Dwight Ramsey Special Help from Oracle: James Baty, Rex Wang Publishing and Editorial for Technology Dummies Richard Swadley, Vice President and Executive Group Publisher Andy Cummings, Vice President and Publisher Mary Bednarek, Executive Director, Acquisitions Mary C. Corder, Editorial Director Publishing and Editorial for Consumer Dummies Kathleen Nebenhaus, Vice President and Executive Publisher Composition Services Debbie Stailey, Director of Composition Services Business Development Lisa Coleman, Director, New Market and Brand Development

7 Introduction Cloud computing is yielding compelling benefits in terms of dramatically lower operating costs, increased speed, and organizational agility for the entire business. Through well-defined functionality, architectural guidelines, and design principles, cloud computing has matured to a production-grade solution. And when coupled with engineered technology products, the resulting cloud capabilities are even more impressive. Understanding cloud architecture and models is a key step in your cloud journey. Find out how cloud service models provide applications, platforms, and infrastructure as a service. Applying the right deployment model, maturity model, architectural principles, and focus are the keys to your success. About This Book This book consists of five short chapters, each written as a stand-alone chapter, so feel free to start reading anywhere and skip around throughout the book! Chapter 1: Cloud Characteristics and Definitions. This chapter identifies essential cloud characteristics and outlines the key benefits and challenges of cloud computing.

8 2 Chapter 2: Cloud Architecture. This chapter goes into three common cloud service models, four cloud deployment models, and the architectural principles and guidelines that ensure cloud success. Chapter 3: Cloud Modeling. This chapter outlines a cloud maturity model and a logical architectural model for cloud, and examines the cloud management infrastructure. Chapter 4: Cloud Implementation. This chapter delves into how engineered systems apply to cloud computing, public cloud options, and technologies that make the most sense for the cloud. Chapter 5: Ten (Okay, Nine) Things to Consider When Moving to a Cloud Model. In that famous For Dummies style, I give you the Part of Tens detailing items to help get you get started with cloud architecture. Icons Used in This Book Now and then you see icons that call attention to important information. Here s what to expect. When you see this icon, you may want to, uh, remember it. You won t find deep meaning-oflife stuff, but it may be good to know for later. This icon usually denotes something I wish someone had told me before I learned it the hard way! Keep these items in mind to make life easier.

9 Chapter 1 Cloud Characteristics and Definitions In This Chapter Defining cloud computing fundamentals Identifying the characteristics of cloud computing Examining the benefits and challenges of the cloud Cloud computing represents a style of computing that lends itself to the dynamic needs of businesses today via rapidly scalable and deployable computing resources over the network. Cloud benefits are significant, but you must develop your own cloud architecture to reap the greatest benefits. This chapter examines the key characteristics of cloud computing and the key benefits and challenges of implementing a cloud architecture. Cloud Computing Defined Cloud computing is an emerging and evolving architecture, and as a result, many definitions and expectations of the architecture exist. A generally accepted definition

10 4 is provided by the National Institute of Standards and Technology (NIST). Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. NIST lists and defines the following five characteristics of cloud computing: On-demand self-service: A consumer provisions computing resources as needed automatically without manual work by the service provider. Resource pooling: Computer resources are pooled to transparently serve multiple applications or tenants. Rapid elasticity: Capabilities can be rapidly and elastically provisioned to quickly scale out and rapidly released to quickly scale in. Measured service: Clouds automatically measure and control IT resource use via a metering capability. Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the service. Broad network access: Capabilities are accessed over a network and accessed through standard mechanisms that promote heterogeneous thin or thick client platforms. In addition to the NIST definition, two additional characteristics are critical to cloud computing: scale and velocity. Traditional IT systems are based on limited numbers

11 of systems with few changes, but cloud computing promotes multiple large systems (scale) with constant change (velocity) to support the cloud. Expect the magnitude and dynamic nature of the cloud to be fundamentally different than traditional IT systems. Benefits of a Cloud Architecture Moving to a cloud computing architecture represents a significant potential shift in your IT mentality. To make such a fundamental change requires strong motivating business factors to encourage the change. Cloud computing comes with many such motivators, but they can generally be grouped into three key areas: lower cost, business agility, and a focus on innovation and core competencies. Lower cost Cloud computing drives down IT cost. Rather than purchasing and supporting dedicated resources to support the peak demand for each application, cloud resources are shared among multiple applications via resource pooling. Pooling enables higher resource utilization and less excess capacity, resulting in lower hardware, software, administration, and infrastructure costs. A measured, metered service model ensures that users only pay for the resources they consume, not for unneeded capacity. Whether it s on-demand use of a public cloud, or a private cloud, lower cost for the organization is realized. Business agility Rapid time to market and simplified deployment for new applications are key motivators. On-demand 5

12 6 provisioning and rapid elasticity allow applications to be deployed and scaled very rapidly. Faster deployments increase the organization s agility and allow IT to be more responsive to the business. Excess capacity may be reduced and systems can be scaled as needed for increasing demand. Focus on innovation and core competencies Shifting to a cloud architecture liberates your organization s best and brightest staff to focus on innovation and core competencies rather than supporting traditional IT systems. Your staff can focus on the business s core competencies, differentiators, and sources of competitive advantage. Challenges to Cloud Architecture As with any new idea, cloud architecture does face some challenges. Although some challenges are organizational and philosophical, others are more tangible. Here is a list of common challenges faced by clouds: Abstraction. An effect of cloud architecture is that details of the IT system are abstracted and simplified. Determining the most useful level of abstraction and granularity is a challenge. Delegation of control/lack of control. Under cloud architecture, the underlying technologies are no longer under the organization s physical control. Coming to terms with not having exclusive, direct physical control over server hardware

13 and infrastructure is a significant organizational change in IT culture. Application portability. Applications with unique hardware platforms or nonstandard infrastructure requirements are difficult to support using capacityon-demand, shared-services environments. Standards are essential. Security. Placing critical, sensitive information in a cloud will generate an emotional response in many people. But, with the right technical measures, processes, and policies, high-level security can be achieved. Proliferation and version control. Organizations must ensure that they are disciplined not to grow and sprawl out of control. Unnecessary resources and out-of-date components need to be decommissioned and released back into the cloud for the benefit of all cloud consumers. Discipline and metered service contracts and fees enforce responsible cloud use. Regulatory compliance. Cloud computing emphasizes distributed IT. But different industries and regions of the world have unique regulatory requirements about the location of data and how data must be managed and accessed. Transparency. The degree of information the consumer requires regarding the technical hardware architecture of the cloud varies based on the cloud model. Theoretically, the infrastructure of the cloud shouldn t matter to the consumer (unless there is a regulatory issue), but it does matter to the service provider. 7

14 8 The challenges of cloud computing are manageable and are outweighed in comparison to the benefits to the organization. A key way of dealing with these challenges, and reaping the desired benefits, is to make sure that you adopt a thoughtful architecture (see Chapter 2).

15 Chapter 2 Cloud Architecture In This Chapter Identifying three cloud service models Explaining four cloud deployment models Describing when hybrid clouds make sense Defining architecture principles and guidelines This chapter examines service models, deployment models, hybrid cloud scenarios, and the architecture principles and guidelines for cloud architecture. Service Models The type of computing resource that is offered in a cloud defines a cloud s service model. NIST and the industry have identified three common service models that are based on what cloud services are provided: applications, platform, and/or infrastructure. Software as a Service (SaaS) With Software as a Service (SaaS), service consumers get their software applications from the service provider. The consumer uses the software as an

16 10 application while the provider manages the underlying platform software and infrastructure hardware. Platform as a Service (PaaS) In Platform as a Service (PaaS), the consumer (a developer) uses programming languages, tools, and the runtime platform from the provider for application development and deployment. The platform may include databases and middleware in addition to application development tools. Infrastructure as a Service (IaaS) With Infrastructure as a Service (IaaS), the provider manages the underlying physical cloud infrastructure (servers, storage, network, and the associated virtualization and operating systems software) while the consumer deploys and runs his or her own application and platform software. Virtualization software is often a key enabler for IaaS architectures. Figure 2-1 shows how service models are related. In Figure 2-1, you see SaaS providing cloud applications, PaaS providing cloud platforms, and IaaS providing cloud infrastructure with usage examples of each environment. It is important to note that each model is not dependent on the others. A SaaS application abstracts the underlying hardware and software, so SaaS need not run on an exposed PaaS or IaaS. Similarly, PaaS abstracts the underlying hardware and need not run on an exposed IaaS.

17 11 Consumer Service Provider Different Users IT Professional Customizations Application Platform IaaS Cloud Developer Customizations Application PaaS Cloud Business End-User Customizations SaaS Cloud Consumer Service Provider Figure 2-1: Cloud service model hierarchy. Deployment Models This section defines four cloud deployment models. These models are based on who has access to the cloud. Private clouds Private clouds are for the exclusive use of a single organization. The cloud is often hosted by the same organization in a private data center, but it may also be hosted by a third-party service provider. Private clouds can offer a high level of control and visibility by the managing organization and are perceived as potentially providing a higher degree of privacy and security.

18 12 Public clouds Public clouds are used by multiple organizations on a shared basis. The cloud is hosted by an outside party providing the cloud as a service. Public clouds do not require an upfront capital investment and are therefore fast and inexpensive to get started but consumers typically have less control and visibility over the service, compared to private clouds, since public clouds are shared and service providers are motivated to provide a standardized offering to reduce their costs. Community clouds Community clouds are used by related organizations or consumers with a common purpose. These are not available to the general public, but are available to members of a specific community. Examples include branches of the military, government or educational organizations, or industry partners and suppliers. These are especially useful where the consumers share special needs (for example, high security), or there is a requirement for common services. Hybrid clouds Hybrid clouds occur when an organization s IT requirements are supported by a mix of private, public, and community clouds in order to take advantage of the benefits of multiple cloud types. Today, these are most likely special use cases, but in the long term this is the likely future of all IT. Some specific types of hybrid clouds are covered in the next section.

19 13 Hybrid Cloud Scenarios Real-world implementations may not fit exclusively in a public, private, or community cloud. In many cases, using both public and either private or community clouds makes sense. This section talks about three common scenarios: life cycle distribution, functional distribution, and cloud bursting. Life cycle distribution This scenario involves separating development and test from production. An enterprise may want to leverage public clouds for rapid, low-cost development and then move to the corporate data center for mission critical production. Figure 2-2 shows these separate environments with differing requirements deployed to different clouds. Private Cloud Public Cloud Test Production Development Enterprise Provider Figure 2-2: Life cycle distribution model.

20 14 Here, you see a lifecycle in which development and testing is located in a public cloud. Then the application moves to production in a private cloud. On the other hand, a startup might develop and test on a private cloud (for example, a developer s laptop) and then move the resulting apps to production in a public cloud. Functional distribution Organizations might split functionally different applications or different parts of an extended business process into different clouds depending on characteristics of the applications. These applications run in different clouds but are integrated with each other across the clouds. A possible scenario here is using generic business functionality as SaaS from a public cloud, but keeping custom or proprietary components in the private cloud. This is an example of using cloud to focus on innovation and core competence. Figure 2-3 shows different business applications deployed across public and private clouds. Private Cloud Public Cloud HRM Claims Processing CRM Enterprise Provider Figure 2-3: Functional distribution model.

21 15 In this scenario, you see a sensitive claims-processing application deployed to an internal private cloud. The claims application takes advantage of the private cloud s benefits but still has access to the generic HRM (human resource management) and CRM (customer relationship management) applications deployed in a public cloud. Cloud bursting Some applications have temporary workload spikes that exceed the processing capacity in the existing cloud. In these situations, the additional workload is off-loaded to another cloud to handle the processing. Figure 2-4 shows cloud bursting due to capacity limitations. Private Cloud Public Cloud Synchronization Claims Processing Claims Processing Enterprise Provider Figure 2-4: Cloud bursting model. In this example, normal application processing occurs in the private cloud. Once workload exceeds the capacity of the private cloud, that excess workload is moved to a public cloud for processing.

22 16 Cloud bursting can also support Disaster Recovery (DR) where the primary site fails and the application fails over to another cloud that may be a different model. One complication of this scenario is the need to simultaneously synchronize two distributed environments, which may not work for complicated real-time transactions. Architecture Principles and Guidelines To be successful in using a public cloud or designing a private cloud, it s useful to embrace some architectural principles (rules) and guidelines (recommendations). When designing a cloud or examining a perspective cloud to use, consider whether it meets the following principles and guidelines: Conformity to standards. Cloud interfaces, formats, and specifications must conform to industry standards. Interoperability and portability is ensured by knowing and following standards. Perceived simplicity. Clouds and computer systems are inherently complex, but to the greatest degree possible that complexity should be masked from the consumer. Just automating manual provisioning won t solve the challenge. The cloud should only present the information to the consumer that is necessary to perform a specific function. Abstractions, models, and policies are methods of simplifying the environment.

23 17 Visibility. If the system cannot be measured, it cannot be effectively managed. The architecture and technology should lend itself to monitoring all resources. Tools to monitor and manage all aspects of the cloud (hardware, software, and network) need to be implemented in accordance with industry standards, but first decide what your measurable objective is. Transparency. Due to the high level of abstraction and because no single group or organization controls the cloud, transparency of key items is essential. Performance metrics, security, reliability, and availability data must be visible to the cloud consumer. Fail in place. Availability should not be limited by hardware failures, which are inevitable. Redundancy and intelligent management software can leverage standardized resource pools to operate continuously despite component failures. By following these key architecture design principles and guidelines, a cloud has a much higher degree of long-term relevance and sustainability.

24 18 These materials are the copyright of John Wiley & Sons, Inc. and any

25 Chapter 3 Cloud Modeling In This Chapter Looking at perspective Defining the cloud maturity model and relevant domains Exploring logical model views of the cloud Examining cloud management capabilities It may be tempting to just jump right into building a cloud environment but like with all IT, it s probably better to do some thinking up front. Understanding your cloud perspective and modeling the components of the cloud are critical. From software payloads to user roles, models will guide you to architect, implement, and operate the cloud. Appropriate modeling allows for a more successful cloud experience. It s really just about making your key cloud decisions. This chapter helps you to identify your cloud perspective. You also find out about the cloud maturity model, cloud architecture logical views, and finally cloud management.

26 20 Cloud Perspective Before embarking on any multi-step cloud-building process, it is important to first identify your cloud perspective. That is, how do you approach and control the impact and benefits of a cloud? Everyone should be on the same page. First, you want to scope out the cloud project. For an enterprise cloud initiative, it s critical to understand what your perspective or motivation is for implementing the cloud. Consider where you are on each of three dimensions: Cost versus agility. Do you want to reduce IT costs or do you want to achieve technical agility? IT driven versus business unit driven. Who s in charge? Is the cloud initiative being driven by the general IT organization (often cost focused) or directly by a line-of-business organization (usually flexibility and/or innovation focused). IT as support versus IT as a business. If the organization s business is an IT product or service, or if it otherwise views IT as a differentiating mission-essential element, then the speed and agility advantages of cloud computing are often the driving motivator. Answering these questions will guide you in using the following tools, designing your cloud, and being able to measure your success.

27 21 Cloud Maturity Model A maturity model is used to benchmark your implementation against others in a similar environment to determine your relative position and where you stand in terms of achieving your goals. This cloud maturity model provides a method to use when charting your success and identifying areas that need improvement. The cloud maturity model is composed of capabilities within eight domains and measured levels of maturity and adoption. Cloud capabilities and domains Capabilities define specific components or characteristics within the cloud. Sixty capabilities have been identified. Capabilities are then categorized into domains, covering not only technology, but also business goals and organizational change. Eight domains are defined within the cloud maturity model: Business and Strategy Architecture Infrastructure Information Projects, Portfolios, and Services Operations, Administration, and Management Organization Governance Figure 3-1 shows each domain grouped into technology and business domains.

28 22 Architecture Business & Strategy Organizational Disciplines Infrastructure Organization Information Governance Technology Dominated Operations, Administration & Management Projects, Portfolios & Services Figure 3-1: Cloud capability domains. An organization is generally strong in some domains and less developed in others. What is important is to identify and categorize your capabilities into the cloud domains. Then determine which domains are most important to your project. Maturity and adoption Maturity defines the quality and consistency of a domain s implementation. Maturity is measured on a scale with six levels: none, ad-hoc, opportunistic, systematic, managed, and optimized. Adoption defines how widely the cloud technology is being used within the organization. Maturity and adoption are used to categorize the level of success for components and ultimately domains. Determining how your cloud initiative and implementation scores within each domain is important. Chart

29 23 your progress of maturity and adoption for each domain against your goals. Figure 3-2 shows an example charting against the cloud domains using both maturity and adoption. Business & Strategy 5 Governance Organization Architecture Infrastructure Projects, Portfolios & Services Operations, Administration & Management Information Current Maturity Current Adoption Figure 3-2: Charting domain maturity and adoption example. Through gauging your relative position in the maturity model, you can determine where you are meeting your goals and identify areas that require improvement. It s not about pinpoint accuracy it s about focusing on your strengths and gaps. Oracle enterprise architects developed this maturity model and are available to help customers understand

30 24 their position relative to their goals and relative to peer organizations. Logical Views Building a cloud is much more than the core service model. To cover this larger design, I break down the cloud architecture into logical views of four key layers. Understanding these logical views provides insights into key components (operations, management, security, and so on) and how the various components are related to each other. The four logical layers are Access Cloud management Resources Services Figure 3-3 shows each logical view and the components within the corresponding layer. Access Interfaces Native Protocols Portals Custom UIs Self-Service APIs Network Proxy Perimeter Security Naming Balancing User Interaction / self service Resources Services SaaS PaaS IaaS Business Process Business Service Application Container Queue Data Server Network Storage Deployable Entities Logical Pools Compute Networks Storage Physical Pools Servers Disks Engineered Systems Facilities Real Estate Cooling Utilities Business Mgmt Customer, Contracts, Revenue Mgmt Operations Service, Life cycle, Configuration, Performance, Monitoring Pool Managers Security and Policy Mgmt Security, Policy Mgmt, Security Services Orchestration Orchestration, Mediation Design time Model Mgmt, Tools Clouds Legacy Partners External Cloud Management Figure 3-3: The four logical views of cloud infrastructure.

31 25 The access layer is composed of two subcomponents: interfaces and networks. Interfaces are for access both into the cloud for services by consumers and for cloud management tools. Networks represent the familiar network components such as naming (DNS), perimeter security (firewalls), proxies (bridging and tunneling traffic), and balancing (load balancers). The cloud management layer provides the management capabilities for the services supported by the cloud and is composed of five areas: Business management Operations Security and policy management Orchestration Design-time The resources layer is composed of logical and physical resources, resource pool management, and facilities (physical data center). Virtual servers are an example of a logical resource. Physical resources include physical computer nodes, storage disks, and network components. Pool managers are tasked with managing a specific resource (rather than an entire system) and present the resource to the cloud management layer to be deployed to consumers. The services layer is composed of the end-user services deployed within the cloud. The deployed services may utilize IaaS, PaaS, or SaaS. Deployable entities are models of services not just the resource image files, but also the architectural metadata.

32 26 Cloud Management Cloud management includes the capabilities to manage and monitor the cloud s resources and provide those resources to the consumers. Cloud management addresses technical areas such as security, design, and architecture; process control areas such as provisioning and operations; and management areas such as customer management and billing for service consumption. Within cloud terminology, a component or function is sometimes referred to as a capability (refer to the Cloud Maturity Model section earlier in this chapter). Take a look at Figure 3-4 to see the key capabilities of cloud management. Cloud Business Management Customer Management Opportunity Management Account Management Customer Provisioning Relationship Management Contracts Management Definition SLA Discovery Metrics Pricing Discounts Revenue Management Rating Billing Payment Reporting Chargeback Collection Cloud Operations Service Management Service Definition Service Discovery Forecasting Metering SL Authoring Lifecycle Management Provision Management Capacity Management Mgmt Resource Mgmt Abstraction Patch Performance Management SL Management User Experience Biz Transaction Diagnostics Biz Service Problem/Incident Configuration Management Asset Discovery Asset Mgmt Knowledge Mgmt Release Mgmt Compliance Change Control Monitoring Security & Policy Management Security Management Identity Entitlements Risk Analysis Certificates Delegated Admin Security Services Authentication Auditing Federation Authorization Role Mapping Fraud Detection Encryption Policy Management Attachment Assessment Enforcement Authoring Deployment Compliance Workflow Mediation Event Processing Orchestration Design-time Model Management Introspection Model Design Validation Federation Package Deploy Figure 3-4: Cloud management.

33 The following sections delve into the key areas and capabilities of cloud management. 27 User interaction and repositories Automation, self-service management, and user provisioning are key components. User interfaces and methods to support these functions must be supported by the cloud management system. Data regarding usage by consumers and other information is stored in repositories to be accessed by necessary components. The infrastructure needs to support the sharing of data across repositories. Cloud business management Clouds have a business and commerce component, even private clouds with IT as the service providers and employees as consumers. Depending on the environment, complex business rules may exist. At a minimum, the management infrastructure must support these business aspects: Customer Contracts Charge The service model and deployment model you use will shape the business management aspect of the cloud. Cloud operations Operational capabilities that must be supported include Service management Life cycle management Performance management

34 28 Configuration management Monitoring User interaction Management repository Be sure that the tools used to manage the cloud meet industry standards and preferably offer integration with other components and repositories. Security and policy management Cloud technology is still developing, the architectural components can be complex, and automation and integration are widespread. Therefore, security and policy (rules) management capabilities must be supported by the management infrastructure. The security and policy management view is composed of the following capabilities: Security management Security services Policy management Orchestration Orchestration is the ability to coordinate multiple processes, workflows, or capabilities that together achieve a desired result. For example, to provision a server environment, you issue requests for hardware, operating system, storage, networking, and security. Even within a virtualized environment, multiple components are required and must be orchestrated. The cloud management system has to support orchestration, often in the form of automated workflows, event processing, and mediation (to resolve conflicts).

35 29 Design-time In traditional IT, all of the building and development is done up front, after that it s just execution. Moving to a cloud model implies breaking this up into two time horizons. Design-time focuses on the upfront assembly of resources and environment. Run-time focuses on the infrastructure management tools to rapidly deploy an application. This design-time/run-time capability should accommodate both your current and future applications. You are building a long-term, sustainable cloud environment. To do that you must develop a solid cloud architecture from the start.

36 30 These materials are the copyright of John Wiley & Sons, Inc. and any

37 Chapter 4 Cloud Implementation In This Chapter Exploring engineered systems and their benefits Mapping Oracle s products and technologies to cloud management infrastructure areas Understanding Oracle s public cloud offerings This chapter moves from the theory of cloud architecture into defining a more concrete roadmap for its implementation. Topics covered include engineered systems, Oracle products and technology mapping, and Oracle s public cloud offerings. Engineered Systems To build successful cloud computing, IT needs to become simpler, not more complicated. Engineered systems are highly optimized, vertically integrated hardware and software solutions designed to perform a specific technical function. Oracle uses server hardware, storage, and operating systems technology and combines it with database, middleware, and applications software into highly optimized and integrated products.

38 32 When a customer buys an engineered product, that customer is getting a preconfigured and tuned hardware and software solution that he or she can begin using immediately. In addition, substantially higher performance, security, and manageability are engineered into the solution. Oracle has taken its best practices for how to build high-performance, reliable, and scalable systems and applied that knowledge to the product. Engineered systems promote a higher level of abstraction, which results in greater simplicity. The higher level of simplicity makes systems easier to manage and operate. Examples of engineered systems from Oracle are the Oracle Exadata Database Machine, Oracle Exalogic Elastic Cloud, and Oracle SPARC SuperCluster. Engineered systems have multiple impacts on cloud architecture: Standardized components promote flexibility, consistency, security, and horizontal scaling. Granularity increases because engineered systems each support a specific function. Specialization is possible because each engineered system performs only well-defined duties and they perform those duties very well. Modularity of components is enhanced. Abstraction increases because engineered systems are closed to outside entities except for welldefined, high-level interfaces. The characteristics of engineered systems provide many benefits to cloud customers:

39 33 Optimized and preconfigured settings by Oracle free customers from resource-intensive performance, architecture tuning, and complex integration tasks. Rapid system standup and production implementations are common because the system is already built when the customer gets it. Capacity planning and performance tuning are more predictable and simplified because the level of capacity and performance is predefined. Appropriate sizing options are available so that customers purchase only the capacity they need to support their applications. Management is simplified due to preconfigured hardware and software and a rich set of management tools. A single-point-of-contact vendor allows for better support and issue resolution. All the benefits of engineered systems serve to promote a common theme in cloud computing: lower IT costs and greater organizational agility. Oracle Product Mapping Oracle provides multiple products to support the cloud architecture. These products also function well in noncloud environments but are particularly suited to cloud computing: Oracle Enterprise Manager Cloud Control. A powerful, integrated management tool for all components of the Oracle stack. Enterprise Manager Cloud Control has monitoring, tuning, provisioning,

40 34 and management capabilities in all hardware and software components in the cloud. Oracle Billing and Revenue Management (BRM). Software that manages and processes billing and revenue for digital products and services. BRM handles revenue management, capture, collection, and analysis. Oracle Virtual Assembly Builder. A software tool to package both middleware and database components so that they can be easily deployed and moved to different environments. Use this tool to package your multi-tier development and test applications and then deploy them to production. Oracle VM. Software to support server virtualization, which plays a critical role in cloud architecture. Use Oracle VM to create and manage virtual server operating environments to support the cloud infrastructure. Oracle Exadata Database Machine. Exadata is an extremely high performance engineered system for all database workloads including both Online Transaction Processing (OLTP) and data warehousing. Exadata is an integrated hardware and software solution with its own internal disk storage and networking. Oracle Exalogic Elastic Cloud. Exalogic is an engineered system that integrates hardware, software, storage, and networking to support Java execution (middleware and applications). Oracle business applications, Oracle Fusion Middleware products, and third-party applications run in this highly scalable processing machine.

41 35 SPARC SuperCluster. SPARC SuperCluster is an engineered system that provides general purpose computing services including database, middleware and applications. Oracle Identity Management. Oracle Identity Management encompasses a suite of products to handle user access, authentication, and authorization across an IT infrastructure. Oracle SOA Suite. Oracle SOA Suite provides products for building, implementing, and managing SOA. Oracle Business Process Management (BPM) Suite. Oracle BPM Suite enables creation, implementation, optimization, and management of business processes. There isn t room here to map all of these products to every function within the Oracle cloud technology stack, but they all provide key functions of the cloud management infrastructure model. Here s a partial list: Cloud business management: Oracle Applications Cloud operations: Oracle Enterprise Manager Cloud Control Security and policy management: Oracle Identity Management product suite Orchestration: Oracle Enterprise Manager Cloud Control and Oracle SOA Suite Design-time: Oracle Enterprise Manager Cloud Control and Oracle Virtual Assembly Builder Repositories: Oracle Database with Real Application Clusters (RAC) and Oracle Exadata

42 36 Oracle s Public Cloud Offerings For those preferring to consume cloud services rather than products to build their own cloud services, Oracle s public cloud offerings deliver: An enterprise cloud for business Self-service business applications on an integrated development and deployment platform with tools to rapidly extend and create new services Instant value and productivity for end-users, administrators, and developers, with predictable subscription pricing A fully managed environment that s built using Exadata and Exalogic, while adding built-in identity management, high availability, elasticity, backup, and monitoring to enable secure and scalable applications

43 Chapter 5 Ten (Okay, Nine) Things to Consider When Moving to a Cloud Model In This Chapter Defining your goals and objectives with the cloud in a clear, concise, and actionable manner Targeting environments and workloads suitable for a cloud architecture Leveraging engineered solutions and technology to improve performance and increase capacity This chapter identifies key items to consider before embracing cloud architecture. It also looks at the ways the cloud will benefit your organization. Clearly Define Cloud Service and Deployment Models Be selective as you define your service and deployment models. For example, do not fall into the trap of thinking that you need Infrastructure as a Service (IaaS)

44 38 when you really just need Platform as a Service (PaaS). Well-defined objectives will ensure that the cloud you get is the cloud you need. Also, don t be afraid of hybrid models where they suit your needs. Choose Appropriate Use Cases, Target Applications, and Workloads Make sure that the environment you want to move to the cloud is indeed a good fit for the cloud architecture; some workloads fit the cloud better than others. Careful analysis and understanding of your existing system will tell you if it is appropriate for the cloud or just needs minor re-work. Do not try to force a unique, highly customized system into the cloud; these types of systems do not fit well into the cloud architecture. Of particular concern, your workloads need to be compatible with horizontally scaled infrastructure to take advantage of cloud elasticity. There s Far More to Cloud Than Just IaaS IaaS is conceptually easy to understand; perhaps that s why many people focus so heavily on it. In other cases, IaaS may seem like just an extension of a hosting environment, which is a concept many people identify with and latch on to.

45 39 Consider the opportunities provided by Software as a Service (SaaS) and PaaS. Focus on these higher level services. Engineered solutions can be used to reduce the focus on the infrastructure, allowing you to spend more time on SaaS and PaaS. Use Consolidation as a First Step toward the Cloud Consolidation is moving multiple applications onto a shared platform or shared infrastructure. You have a very strategic decision here. Consolidation onto shared infrastructure (IaaS) typically leverages virtualization to share hardware, delivering cost savings in hardware, power, cooling, and data center space. Consolidation onto a shared platform (PaaS), such as database or middleware, requires architecture standardization for all or most of your applications therefore making it more difficult. However, this approach delivers significantly greater benefits because a platform reduces the heterogeneity of the software stacks in your environment, and it is this heterogeneity that is a major cost driver. By moving onto a shared, standardized, and elastically scalable platform, you will achieve greater levels of cost savings as well as greater agility and faster new application deployment.

46 40 Design to Higher Service Levels and Abstraction Leverage the natural characteristics of cloud design and technologies for your benefit. Use templates, assemblies, and engineered systems to make your cloud simpler and more standard (not more complex). Doing so increases your deployment speed and agility. These items will yield large benefits if they are central to your design and implementation. Leveraging engineered systems further aids in abstraction and higher service levels due to the design nature and capabilities of an engineered architecture. Focus on Integration, Not Just Virtualization Yes, cloud technology frequently includes virtualization capabilities. But it does so because it s an enabled technology for cloud scaling and elasticity. However, without good management tools and organizational discipline, virtualization can add to the complexity of the cloud. A less recognized key capability is integration. Integration allows all components to work together in an effective manner. Furthermore, integration allows for a more simple system and supports a higher degree of abstraction. Highly integrated solutions offer not just an easier implementation, but also a greater agility and speed. These benefits result in greater cost savings and the ability to focus less on technology and more on core business functions. Engineered systems (including but not limited

47 to Exadata, Exalogic, and SuperCluster) are built on an integrated architecture and offer many benefits. 41 Use Cloud to Become Secure Adherence to industry best practices, security practices and procedures, and standardized policies makes the cloud a secure place to do business. The factors that make the cloud successful also enhance the security and privacy of those using the cloud. Security becomes a systemic quality that spans multiple maturity domains. Consider private and community clouds to further enhance both real and perceived security. Regulatory compliance requirements are more easily met due to the standardized nature of the cloud. The success of the cloud depends on standardized interfaces, virtualized and automated environments, and extensive system monitoring. Therefore, as a byproduct, auditors have a higher degree of confidence that the system is well documented and standardized. Evaluate IT Culture Impact, Change, and Direction Not all organizations are immediately ready for the cloud, and some require evaluation and cloud strategy development to take full advantage of the architecture. In other cases, the target systems architecture or technology stack simply doesn t fit well into the cloud model. It is less important to be at a high maturity model than to have an accurate understanding of your current maturity level.

48 42 Understand the culture and maturity of your organization to ensure that it will be a good fit with the cloud. Encourage a culture where design principles consistent with self-service and cloud philosophy are rewarded. Gain senior management sponsorship to drive transformation within the organization. Break Down Your Implementation into a Clear Road Map Don t overcomplicate your cloud implementation that s an easy mistake to make. Instead, establish a road map for what you want and how to get there. Make sure that your plans are focused, holistic, and integrated. Be sure to chart your progress and set milestones as you move to the cloud, but don t be afraid to take a step back to address issues. Consider the impact of your steps and ensure that they make sense and serve your mission. If your road map does not make sense, then probably neither does your implementation.

49 Notes These materials are the copyright of John Wiley & Sons, Inc. and any

50 Notes These materials are the copyright of John Wiley & Sons, Inc. and any

51