these materials are the copyright of john wiley &...

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

by Michael Wessler, OCP & CISSP

Cloud Architecture

FOR

DUMmIES‰

ORACLE SPECIAL EDITION


Cloud Architecture For Dummies®, Oracle Special Edition

Published by John Wiley & Sons, Inc. 111 River St. Hoboken, NJ 07030-5774 www.wiley.com

Copyright © 2012 by John Wiley & Sons, Inc., Hoboken, New JerseyPublished by John Wiley & Sons, Inc., Hoboken, New JerseyNo part of this publication may be reproduced, stored in a retrieval system or trans-mitted in any form or by any means, electronic, mechanical, photocopying, record-ing, 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) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.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 317-572-3205. For details on how to create a custom For Dummies book for your business or organization, contact [email protected]. For information about licensing the For Dummies brand for products or services, contact BrandedRights&[email protected]: 978-1-118-21692-7 (pbk); 978-1-118-21771-9 (ebk) Manufactured in the United States of America10 9 8 7 6 5 4 3 2 1


http://www.wiley.com

http://www.wiley.com/go/permissions

mailto:[email protected]

mailto:BrandedRights&[email protected]

Contents at a GlanceIntroduction .................................................................. 1

Chapter 1: Cloud Characteristics and Definitions ............................................................. 3Cloud Computing Defined .............................................5Benefits of a Cloud Architecture ..................................5Challenges to Cloud Architecture ................................6Chapter 2: Cloud Architecture ................................... 9Service Models ...............................................................9Deployment Models .....................................................11Hybrid Cloud Scenarios ..............................................13Architecture Principles and Guidelines ....................16

Chapter 3: Cloud Modeling ...................................... 19Cloud Perspective ........................................................20Cloud Maturity Model .................................................21Logical Views ................................................................24Cloud Management ......................................................26

Chapter 4: Cloud Implementation ........................... 31Engineered Systems.....................................................31Oracle Product Mapping .............................................33Oracle’s Public Cloud Offerings .................................36

Chapter 5: Ten (Okay, Nine) Things to Consider When Moving to a Cloud Model ............................. 37


Publisher’s AcknowledgmentsWe’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 [email protected]. For details on licensing the For Dummies brand for products or services, contact BrandedRights&[email protected]. Some of the people who helped bring this book to market include the following:

Publishing and Editorial for Technology DummiesRichard Swadley, Vice President and Executive Group PublisherAndy Cummings, Vice President and PublisherMary Bednarek, Executive Director, AcquisitionsMary C. Corder, Editorial Director

Publishing and Editorial for Consumer DummiesKathleen Nebenhaus, Vice President and Executive Publisher

Composition ServicesDebbie Stailey, Director of Composition Services

Business DevelopmentLisa Coleman, Director, New Market and Brand Development

Acquisitions, Editorial, and Vertical Websites

Senior Project Editor: Zoë WykesEditorial Manager: Rev MengleAcquisitions Editor: Katie FeltmanSenior Business Development Representative: Karen L. HattanCustom Publishing Project Specialist: Michael Sullivan

Composition Services

Senior Project Coordinator: Kristie ReesLayout and Graphics: Carrie A. Cesavice, Lavonne RobertsProofreader: Dwight RamseySpecial Help from Oracle: James Baty, Rex Wang


mailto:[email protected]

mailto:BrandedRights&[email protected]

Introduction

C loud 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 prod-ucts, 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 infrastruc-ture as a service. Applying the right deployment model, maturity model, architectural principles, and focus are the keys to your success.

About This BookThis 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.


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 BookNow 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-of-life 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.


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

C loud computing represents a style of computing that lends itself to the dynamic needs of busi-

nesses today via rapidly scalable and deployable com-puting 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 DefinedCloud computing is an emerging and evolving architec-ture, and as a result, many definitions and expectations of the architecture exist. A generally accepted definition


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 applica-tions 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 capa-bility. Resource usage can be monitored, con-trolled, 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 charac-teristics are critical to cloud computing: scale and veloc-ity. Traditional IT systems are based on limited numbers


5

of systems with few changes, but cloud computing pro-motes multiple large systems (scale) with constant change (velocity) to support the cloud. Expect the mag-nitude and dynamic nature of the cloud to be fundamen-tally different than traditional IT systems.

Benefits of a Cloud ArchitectureMoving 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 com-puting 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 costCloud computing drives down IT cost. Rather than pur-chasing 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, soft-ware, 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 agilityRapid time to market and simplified deployment for new applications are key motivators. On-demand


6

provisioning and rapid elasticity allow applications to be deployed and scaled very rapidly. Faster deploy-ments 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 competenciesShifting to a cloud architecture liberates your organiza-tion’s best and brightest staff to focus on innovation and core competencies rather than supporting tradi-tional IT systems. Your staff can focus on the busi-ness’s core competencies, differentiators, and sources of competitive advantage.

Challenges to Cloud ArchitectureAs with any new idea, cloud architecture does face some challenges. Although some challenges are organi-zational 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 simpli-fied. Determining the most useful level of abstrac-tion 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 exclu-sive, direct physical control over server hardware


7

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 capacity-on-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 mea-sures, 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 decom-missioned 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 empha-sizes 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 con-sumer 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.


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 chal-lenges, and reaping the desired benefits, is to make sure that you adopt a thoughtful architecture (see Chapter 2).


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

T his chapter examines service models, deployment models, hybrid cloud scenarios, and the architec-

ture principles and guidelines for cloud architecture.

Service ModelsThe 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


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 devel-oper) 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 appli-cation 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 virtual-ization and operating systems software) while the con-sumer 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 applica-tions, PaaS providing cloud platforms, and IaaS provid-ing 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.


11

DifferentUsers

IaaS Cloud

Platform

Application

Customizations

IT Professional

Application

Customizations

Developer

Customizations

Business End-User

PaaS Cloud

SaaS Cloud

Cons

umer

Serv

ice

Prov

ider

Cons

umer

Serv

ice

Prov

ider

Figure 2-1: Cloud service model hierarchy.

Deployment ModelsThis section defines four cloud deployment models. These models are based on who has access to the cloud.

Private cloudsPrivate clouds are for the exclusive use of a single orga-nization. The cloud is often hosted by the same organi-zation 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.


12

Public cloudsPublic 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 ser-vice, compared to private clouds, since public clouds are shared and service providers are motivated to pro-vide a standardized offering to reduce their costs.

Community cloudsCommunity 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 cloudsHybrid clouds occur when an organization’s IT require-ments 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.


13

Hybrid Cloud ScenariosReal-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 distributionThis scenario involves separating development and test from production. An enterprise may want to lever-age 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 dif-fering requirements deployed to different clouds.

Private Cloud Public Cloud

Production

Enterprise Provider

Development

Test

Figure 2-2: Life cycle distribution model.


14

Here, you see a lifecycle in which development and test-ing 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 distributionOrganizations might split functionally different applica-tions or different parts of an extended business pro-cess 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 busi-ness functionality as SaaS from a public cloud, but keeping custom or proprietary components in the pri-vate 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.


Claims Processing

Enterprise Provider

CRM

HRM

Figure 2-3: Functional distribution model.


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 burstingSome 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.

Claims Processing

Enterprise Provider


Claims Processing

Synchronization

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.


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 compli-cated real-time transactions.

Architecture Principles and GuidelinesTo 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, for-

mats, and specifications must conform to industry standards. Interoperability and portability is ensured by knowing and following standards.

✓ Perceived simplicity. Clouds and computer sys-tems 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 spe-cific function. Abstractions, models, and policies are methods of simplifying the environment.


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 net-work) 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 con-trols the “cloud,” transparency of key items is essential. Performance metrics, security, reliabil-ity, 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.


18


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

I t may be tempting to just jump right into building a cloud environment — but like with all IT, it’s proba-

bly 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, imple-ment, 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 perspec-tive. You also find out about the cloud maturity model, cloud architecture logical views, and finally cloud management.


20

Cloud PerspectiveBefore embarking on any multi-step cloud-building pro-cess, it is important to first identify your cloud per-spective. 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 imple-menting 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 ser-vice, 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.


21

Cloud Maturity ModelA maturity model is used to benchmark your implemen-tation against others in a similar environment to deter-mine 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 domainsCapabilities define specific components or characteris-tics within the cloud. Sixty capabilities have been iden-tified. 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.


22

Architecture

Infrastructure Organization

TechnologyDominated

Information Governance

Business &Strategy

Operations,Administration

&Management

Projects,Portfolios &

Services

OrganizationalDisciplines

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 adoptionMaturity defines the quality and consistency of a domain’s implementation. Maturity is measured on a scale with six levels: none, ad-hoc, opportunistic, sys-tematic, 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 implementa-tion scores within each domain is important. Chart


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 & Strategy5

43

21

0

Operations, Administration& Management

Current Maturity Current Adoption

Information

Infrastructure

ArchitectureGovernance

Projects, Portfolios &Services

Organization

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


24

their position relative to their goals and relative to peer organizations.

Logical ViewsBuilding 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, secu-rity, 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.

Acce

ss Native Protocols Portals Custom UIs Self-Service APIs

Proxy

Interfaces

Network Perimeter Security NamingUser Interaction / self service

Balancing

Reso

urce

sSe

rvic

es

Compute Networks Storage

Servers

Logical Pools

Physical Pools Disks Engineered Systems

Real EstateFacilities

SaaS

PaaS

IaaS

Cooling Utilities

Clouds External

Legacy

Partners

Business Process Business Service ApplicationBusiness

MgmtCustomer, Contracts,

Revenue Mgmt

OperationsService, Life cycle,

Con�guration,Performance,

Monitoring

Security andPolicy Mgmt

Security, Policy Mgmt,Security Services

OrchestrationOrchestration,

Mediation

Design–timeModel Mgmt, Tools

Container Queue Data

Clou

d M

anag

emen

t

Server Network

Deployable Entities

Storage

PoolManagers

Figure 3-3: The four logical views of cloud infrastructure.


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 net-work 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 physi-cal computer nodes, storage disks, and network com-ponents. 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.


26

Cloud ManagementCloud 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 provision-ing and operations; and management areas such as cus-tomer 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.

Opportunity Management

Account Management

Customer Provisioning

Relationship Management

Cloud Business ManagementCustomer Management

De�nition

SLA

Discovery

Metrics

Pricing

Discounts

Contracts Management

Revenue Management

Security & Policy ManagementSecurity Management

Rating

Reporting

Billing

Chargeback

Payment

Collection

Service De�nition Service Discovery

Cloud OperationsService Management

Forecasting Metering SL Authoring

Provision Management Capacity Management

Abstraction Patch Mgmt Resource Mgmt

Lifecycle Management

Performance Management

Con�guration Management

Identity

Certi�cates Delegated Admin

Entitlements Risk Analysis

Orchestration

Work�ow Mediation

Design-timeModel Management

Security ServicesAuthentication Auditing Federation

Authorization Role Mapping

Fraud Detection

Encryption

Policy ManagementAttachment Assessment Enforcement

Authoring Deployment Compliance

Introspection Model Design Validation

Federation Package Deploy

Event Processing

SL Management User Experience Biz Transaction

Diagnostics Biz Service Problem/Incident

Asset Discovery Asset Mgmt Knowledge Mgmt

Release Mgmt Compliance Change Control

Mon

itorin

g

Figure 3-4: Cloud management.


27

The following sections delve into the key areas and capabilities of cloud management.

User interaction and repositoriesAutomation, self-service management, and user provi-sioning are key components. User interfaces and meth-ods to support these functions must be supported by the cloud management system.Data regarding usage by consumers and other informa-tion is stored in repositories to be accessed by neces-sary components. The infrastructure needs to support the sharing of data across repositories.

Cloud business managementClouds have a business and commerce component, even private clouds with IT as the service providers and employees as consumers. Depending on the envi-ronment, complex business rules may exist. At a mini-mum, 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 operationsOperational capabilities that must be supported include ✓ Service management ✓ Life cycle management ✓ Performance management


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 managementCloud technology is still developing, the architectural components can be complex, and automation and inte-gration 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

OrchestrationOrchestration is the ability to coordinate multiple pro-cesses, workflows, or capabilities that together achieve a desired result. For example, to provision a server environment, you issue requests for hardware, operat-ing 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 orches-tration, often in the form of automated workflows, event processing, and mediation (to resolve conflicts).


29

Design-timeIn 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.


30


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

T his chapter moves from the theory of cloud archi-tecture 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 SystemsTo 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 hard-ware, storage, and operating systems technology and combines it with database, middleware, and applica-tions software into highly optimized and integrated products.


32

When a customer buys an engineered product, that customer is getting a preconfigured and tuned hard-ware and software solution that he or she can begin using immediately. In addition, substantially higher performance, security, and manageability are engi-neered into the solution. Oracle has taken its best prac-tices 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 simplic-ity. The higher level of simplicity makes sys-tems 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 sys-

tems 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 sys-

tems are closed to outside entities except for well-defined, high-level interfaces.

The characteristics of engineered systems provide many benefits to cloud customers:


33

✓ Optimized and preconfigured settings by Oracle free customers from resource-intensive perfor-mance, architecture tuning, and complex integra-tion tasks.

✓ Rapid system standup and production implemen-tations 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 manage-ment tools.

✓ A single-point-of-contact vendor allows for better support and issue resolution.

All the benefits of engineered systems serve to pro-mote a common theme in cloud computing: lower IT costs and greater organizational agility.

Oracle Product MappingOracle provides multiple products to support the cloud architecture. These products also function well in non-cloud environments but are particularly suited to cloud computing: ✓ Oracle Enterprise Manager Cloud Control. A pow-

erful, integrated management tool for all compo-nents of the Oracle stack. Enterprise Manager Cloud Control has monitoring, tuning, provisioning,


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 compo-nents 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 virtualiza-tion, which plays a critical role in cloud architec-ture. 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 ware-housing. Exadata is an integrated hardware and software solution with its own internal disk stor-age and networking.

✓ Oracle Exalogic Elastic Cloud. Exalogic is an engi-neered system that integrates hardware, software, storage, and networking to support Java execu-tion (middleware and applications). Oracle busi-ness applications, Oracle Fusion Middleware products, and third-party applications run in this highly scalable processing machine.


35

✓ SPARC SuperCluster. SPARC SuperCluster is an engineered system that provides general purpose computing services including database, middle-ware and applications.

✓ Oracle Identity Management. Oracle Identity Management encompasses a suite of products to handle user access, authentication, and authoriza-tion across an IT infrastructure.

✓ Oracle SOA Suite. Oracle SOA Suite provides products for building, implementing, and manag-ing SOA.

✓ Oracle Business Process Management (BPM) Suite. Oracle BPM Suite enables creation, imple-mentation, optimization, and management of busi-ness 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


36

Oracle’s Public Cloud OfferingsFor 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 iden-tity management, high availability, elasticity, backup, and monitoring to enable secure and scal-able applications


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

T his 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 ModelsBe selective as you define your service and deployment models. For example, do not fall into the trap of think-ing that you need Infrastructure as a Service (IaaS)


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 WorkloadsMake sure that the environment you want to move to the cloud is indeed a good fit for the cloud architec-ture; 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 IaaSIaaS 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 envi-ronment, which is a concept many people identify with and latch on to.


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 CloudConsolidation is moving multiple applications onto a shared platform or shared infrastructure. You have a very strategic decision here.Consolidation onto shared infrastructure (IaaS) typi-cally leverages virtualization to share hardware, deliv-ering cost savings in hardware, power, cooling, and data center space.Consolidation onto a shared platform (PaaS), such as database or middleware, requires architecture stan-dardization 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 het-erogeneity that is a major cost driver. By moving onto a shared, standardized, and elastically scalable plat-form, you will achieve greater levels of cost savings as well as greater agility and faster new application deployment.


40

Design to Higher Service Levels and AbstractionLeverage 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 engi-neered 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 VirtualizationYes, cloud technology frequently includes virtualization capabilities. But it does so because it’s an enabled tech-nology 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 imple-mentation, 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


41

to Exadata, Exalogic, and SuperCluster) are built on an integrated architecture and offer many benefits.

Use Cloud to Become SecureAdherence 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 inter-faces, virtualized and automated environments, and extensive system monitoring. Therefore, as a byprod-uct, auditors have a higher degree of confidence that the system is well documented and standardized.

Evaluate IT Culture Impact, Change, and DirectionNot 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 tech-nology 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.


42

Understand the culture and maturity of your organiza-tion 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 transfor-mation within the organization.

Break Down Your Implementation into a Clear Road MapDon’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.


Notes


http://www.dummies.com

http://www.oracle.com

these materials are the copyright of john wiley &...

Documents