• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Cumulus   Ciclo De Vida Do Cloud   Stratus, Altostratus E Cirrus
 

Cumulus Ciclo De Vida Do Cloud Stratus, Altostratus E Cirrus

on

  • 687 views

 

Statistics

Views

Total Views
687
Views on SlideShare
687
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Unzip Keynote2_BuildingBlocksOfPrivatePaaS_v7_audio.zip into the same directory as this presentation. To turn off automatic advancing of slides, uncheck “Use Rehearsed Timings” under “Slide Show”. To turn off audio narration, check “Show without narration” under “Set Up Slide Show”.
  • We’ll start with a macro-level organization of our building blocks. Note that we’re talking here about a private cloud context where an enterprise is building and providing the cloud offering internally. This is typically executed in a model where a central IT function within the enterprise builds and manages the cloud, and internal “customers” within the enterprise such as different departments are clients or “tenants” of the cloud. Some of what we’re talking about here may apply to public cloud as well, but that is not our focus in this presentation. [click] At the bottom of the software stack, residing just above physical servers, is infrastructure. This may or may not include virtualization but in most cases has an operating system (stay tuned though—even this has exceptions!). Notice that we depict management as an integral part of the picture—this theme will recur throughout our story. In the context of cloud, if one is offering infrastructure as a service (IaaS), these are the pieces inolved. [click] Platform as a Service, or PaaS, subsumes the infrastructure level and includes database, middleware, and custom-built or other additional pieces such as shared components or a self-service interface that are specific to the particular PaaS offering. Again, management is an important part of this story and is manifested as the combination of mechanisms internal to the individual layers, external management mechanisms, and how these are integrated.
  • For many (if not most) enterprises pursuing a private cloud strategy, a platform-level (PaaS) cloud offering is a natural strategy and is superior to a basic infrastructure-level (IaaS) offering for several reasons. The basic idea is that PaaS provides the right balance between Central IT providing enough in the cloud so that cloud tenants can get up and running quickly and easily but have enough latitude and flexibility to create the applications they really need. If Central IT provides a much lower level offering such as at the IaaS level, each tenant must reinvent the wheel and build most of the stack on his own, lengthening time-to-deployment and resulting in inconsistent stacks that are harder to manage. By providing more in a PaaS model, tenants not only get up and running more quickly, but Central IT’s management, security, and efficiency is greatly enhanced through consistency and economies of scale.
  • [quickly summarize since this was covered in the previous keynote] This slide shows the lifecycle of how a private cloud would work within an enterprise. Note the different roles. 1. First IT sets up the private PaaS based on the Oracle Cloud Platform. They also define certain shared components to ensure standardization and make it easier for app builders. These components may be services, processes or UI components. They also need to set up a self-service application, potentially based on WebCenter portal and Identity Management. This is potentially also integrated with the enterprise’s IT Service Mgmt application such as Siebel or BMC/Remedy. 2. Next, an app owner can take advantage of the PaaS and shared component to more quickly assemble the app and deploy it through self-service. If their role entitles them to make that request, it is automatically provisioned. If not, it gets routed to their management and/or IT for workflow approval…just like a procurement process. 3. Third, users start using the app. 4. If usage starts to approach the capacity limits, the app owner can monitor this through self-service. And the system can scale automatically thanks to an underlying grid architecture at the database and middleware levels, and thanks to effective grid control by Enterprise Manager. 5. Enterprise Manager also tracks resource usage (metering) and this data can be used to charge back to the departments or LOBs. So, this PaaS shows some of the key characteristics of cloud computing: self-service, shared services, dynamic provisioning, elastic scalabiltiy and metering/chargeback.
  • We identify five basic categories of capability that are important for enabling PaaS and are definitive in making a given infrastructure a truly cloud offering. [click] first is the notion of sharing infrastructure with the ability to dynamically allocate resources across different applications to scale their capacity. [click] second, and this is definitive for making the cloud offering truly “platform” is the ability to create shareable, reusable components that cloud tenants incorporate into their applications. [click] third is the ability to deploy apps nearly instantly—a basic feature that is definitive for cloud computing in general. [click] fourth, dependent on the ability to deploy apps quickly, is the ability for tenants to do so without time-consuming live interactions with IT—the basic idea is to login to a Web site and get an app live in minutes. [click] we’ll start by looking at what it takes to set up shared infrastructure with dynamic scaling. [click] fifth, a capability that really permeates the other four, is the ability to set up, monitor, and automate the infrastructure in cloud-specific ways such as automatic the dynamic capacity adjustment and generating departmental chargeback information or reports based on usage data.
  • Let’s look in detail at what we mean by shared resources with dynamic adjustment. The basic mechanism for enabling resource pooling and sharing with dynamic adjustment is clustering. Clustering is a mechanism that exists at many levels within the Oracle stack, such as at the application server level, in-memory data grid level, and database level. Clustering is the ability to have multiple instances or “nodes”, each running on a separate machine, work together in a cluster to support a given workload. Important for clouds is the ability to dynamically add and remove nodes in live running clusters. For example [click] a spike in load on an application is sensed, and nodes are added to the underlying WebLogic Server and/or Coherence clusters to accommodate that spike. [click] Not just applications but shared components have spikes to be accommodated, and different spikes will be addressed in different ways such as this one entailing expansion of the Coherence grid but not the app server cluster. [click] Clustering at the Database level with RAC operates in a similar fashion.
  • Ok, let’s turn to our second major requirement, component sharing.
  • A definitive and important distinction between IaaS and PaaS is that the platform provides a number of components for cloud tenants to use in creating their applications. These components are unique to each domain, enterprise, and cloud and thus are custom-built, though with significant help from the Oracle PaaS Foundation as we’ll see in a minute. These are created by the Central IT function. There are three basic kinds of platform-based components. The first include components that will be embedded in the tenant app (e.g. code that is copied into an app). The second consists of services that are already up and running and get connected and called into by the tenant app—these are things like SOA services. The last category is like the first but sort of inverted: The component is a nearly complete app that only requires minimal additional customization to turn it into a full app. You could think of this as an app shell or an app chassis. Creating SOA services and BPM processes as reusable components is straightforward with Oracle SOA Suite and BPM Suite. The Central IT department creates [click] services and process components. [click] Once they are created, they are registered in the registry, stored in the repository, and connected through the service bus. Next [click], the departmental app owner creates an app, finds [click] platform components to include, [click], includes them, and then [click] deploys the app.
  • Now let’s turn to the third PaaS requirement, support for fast deployment.
  • WebLogic Server Virtual Edition appliances are particularly interesting in the context of PaaS. [click] Central IT can create pre-configured app server appliances as bases for apps to be created by departmental app owners. [click] These appliances may or may not be pre-packaged with library code modules specific to the enterprise, and in either case the departmental app owner adds the Java code and other modules that constitute his individual app and then deploys the appliance with these additions. [click] Key to making platform appliances effective is exactly what is exposed as configurable and extendable by the departmental app owners.
  • Now, let’s take this whole concept of prepackaging components with exposed extension points to the next level. As nice as an appliance is, the reality of typical enterprise applications is that they are not self-contained, single-element entities but rather comprise multiple distributed elements that are connected together. [click] Each element might be an appliance, but the application overall consists of multiple appliances connected in a certain way. Here’s where we introduce the notion of an assembly, a sort of “meta appliance” that consists of multiple appliances plus information about how to connect them. [click] Oracle Assembly Builder is a tool that takes such a multi-tier, distributed application and packages it up into an assembly that can be reused in a way similar to the way appliances are used. [click] the assembly, like an appliance virtual image, is essentially a file that contains the images of the constituent appliances as well as metadata about how those appliances get configured, connected, and started up.
  • So with that brief introduction to assemblies and Oracle Assembly Builder, let’s consider the implications for PaaS. [click] Extending our PaaS lifecycle model here, Central IT uses Assembly Builder to create assemblies as shared components on the Platform. [click] Departmental app owners use the assemblies much like they use appliances in the previous example, except that the assemblies package and hide details of much more complex topologies, and are essentially shells of distributed multi-tier applications. The work each departmental app owner needs to do is now significantly reduced, and the risk of introducing configuration errors is also reduced. In addition, the various apps that different departments build using a given assembly now have much more consistency in their structures, simplifying operational acdtivities including diagnostics, updates, etc.
  • Now let’s look at the fourth requirement area, self service.
  • The first thing we want to highlight in the area of self service is the importance of the management capabilities. If we review our PaaS lifecycle model from the standpoint of the activities carried out by the cloud tenants, the departmental app owners, we see that many of the self-service activities such as setting policies, monitoring and adjusting application-level behaviors, and even chargeback based on usage metering depends on unified management mechanisms that span the foundation stack. More detail on this will follow in the management breakout session.
  • Now we turn to the fifth major category of requirements, management and automation.
  • This is a huge topic, and we’ve devoted an entire breakout session to cover it in detail. We wanted to highlight here that it is truly a cross-cutting, integral set of requirements across the entire stack. If we review one last time our PaaS lifecycle, this time from the standpoint of Central IT in the ongoing running of the Platform, we can quickly get a sense of the nature of required automation. [click] Ahead of applications’ running, Central IT has entered policies ranging from foundation-wide to application-specific. [click] End users use the application, in many cases not even needing to know that they are running on a cloud per se—their main concern is application availability and responsiveness. As they’re using the cloud-based apps, Central IT is monitoring the platform and adding resources to the pool as aggregate demand grows, and meanwhile the platform itself is automatically adjusting allocation to optimize across ebbs and flows of demand and also failing over automatically as cluster nodes encounter problems, etc. Again, this automation depends on sophisticated mechanisms within the stack layer technologies themselves and the centralized management functions unified within Enterprise Manager.

Cumulus   Ciclo De Vida Do Cloud   Stratus, Altostratus E Cirrus Cumulus Ciclo De Vida Do Cloud Stratus, Altostratus E Cirrus Presentation Transcript

  • "Cumulus“, Ciclo de Vida do Cloud: Stratus, Altostratus & Cirrus Luís Ganhão Solutions Senior Manager
  • Agenda
    • WIC
    • WTHIHACC
    • OV
      • PCBB
      • PIaaS vs PPaaS
    • PPaaS
    © 2010 Oracle Corporation
  • What is Cloud Computing © 2010 Oracle Corporation
    • 5 Essential Characteristics
    • Broad network access
    • Resource pooling
    • Rapid elasticity
    • On-demand self-service
    • Measured service
    • 3 Service Models
    • SaaS
    • PaaS
    • IaaS
    • 4 Deployment Models
    • Public Cloud
    • Private Cloud
    • Community Cloud
    • Hybrid Cloud
  • What the Hell, I have a Cloud Computing © 2010 Oracle Corporation
    • 5 Essential Characteristics
    • Broad network access
    • Resource pooling
    • Rapid elasticity
    • On-demand self-service
    • Measured service
    • 3 Service Models
    • SaaS
    • PaaS
    • IaaS
    • 4 Deployment Models
    • Public Cloud
    • Private Cloud
    • Community Cloud
    • Hybrid Cloud
  • Private Cloud Building Blocks © 2010 Oracle Corporation Infrastructure as a Service Platform as a Service Virtualization OS Management Shared Components Self-Service Interface Database Middleware Management
  • Private IaaS vs. Private PaaS PaaS Is the Natural Strategy for Enterprises App App App App More to build Less to build Disparate components Inconsistent foundation Consistent foundation Common/shared components
    • More freedom
    • More work
    • More secure
    • More manageable
    • More agile
    • More efficient
    IaaS PaaS © 2010 Oracle Corporation IaaS PaaS Virtualization OS Management Virtualization OS Database Middleware Management
  • Private PaaS Lifecycle The Model Driving Our Approach
    • Set up PaaS
    • Set up shared components
    • Set up self-service portal
    App Developer App Users 1. Set Up Cloud 2. Build App 3. Use App 4. Scale up/down App
    • Assemble app using shared components
    • Deploy through self-service
    • Adjust capacity based on policies
    • Monitor via self-service
    App Owner 5. Chargeback
    • Meter usage and charge back to app owners or departments
    © 2010 Oracle Corporation Self-Service Interface Shared Components IT PaaS Foundation
  • Private PaaS Requirements Definitive Capabilities for PaaS Infrastructure 1. Shared Infrastructure with Dynamic Scaling 3. Support for Fast Deployment 4. Support for Self-Service 5. Management and Automation 2. Support for Component Sharing App 1. Shared Infrastructure with Dynamic Scaling © 2010 Oracle Corporation Self-Service Interface Shared Components PaaS Foundation
  • Automated Dynamic Capacity Adjustment Application Grid and Database Grid Application Grid Database Grid App Server cluster nodes Data Grid cluster nodes Database A+A cluster nodes © 2010 Oracle Corporation Dept App 1 Dept App 2 Shared Service Shared Service Managing Console Shared Service Dept App 1 Sense demand spike Sense demand spike Sense demand spike Adjust capacity Adjust capacity Adjust capacity
  • Private PaaS Requirements Definitive Capabilities for PaaS Infrastructure 3. Support for Fast Deployment 4. Support for Self-Service 5. Management and Automation 2. Support for Component Sharing App © 2010 Oracle Corporation 1. Shared Infrastructure with Dynamic Scaling Self-Service Interface Shared Components PaaS Foundation
  • SOA: Building Shared Services and Processes © 2010 Oracle Corporation Registry/ Repository Service Bus SOA (BPMN2.0 + BPEL) Application Grid create processes create services IT Dept App Proc Svc Svc Svc Svc Svc Proc Proc Proc Managing Console Self Svc register and connect Proc Svc find components Department App Owner build app include components Database Grid Unified Front-End Centralized GRC
  • Private PaaS Requirements Definitive Capabilities for PaaS Infrastructure 3. Support for Fast Deployment 4. Support for Self-Service 5. Management and Automation 2. Support for Component Sharing App © 2010 Oracle Corporation 1. Shared Infrastructure with Dynamic Scaling Self-Service Interface Shared Components PaaS Foundation
  • Appliances and PaaS
      • Key to successful PaaS: what is exposed as “configurable” by Departmental App Owners in each appliance
    © 2010 Oracle Corporation Self-Service Interface PaaS Foundation Department App Owner
    • Departmental App Owners create applications based on appliances
    Dept App App Server VE Application App Server VE Application App Server VE Application Central IT
    • Central IT creates appliances as shared components
    Shared Components
  • The Next Level: Assemblies Applications Are Often Multi-Tier And Distributed Web Tier AppTier Database Tier
    • Assembly = appliances + metadata describing:
      • Configuration
      • Connections
      • Startup sequence
    © 2010 Oracle Corporation VM VM VM VM AS AS SOA Svc Web Web Grid Grid Assembly Builder Assembly Metadata
  • Assemblies and PaaS
    • Assemblies enhance PaaS:
      • Ability to pre-build more complex app foundations for platform
      • Accelerate deployment
      • Reduce risk of configuration error
      • Simplify runtime operation through standardization and consistency
    © 2010 Oracle Corporation Self-Service Interface PaaS Foundation Shared Components Central IT
    • Central IT creates shared assemblies
    Department App Owner Dept App
    • Departmental App Owner creates app from assembly and deploys on cloud platform
  • Private PaaS Requirements Definitive Capabilities for PaaS Infrastructure 3. Support for Fast Deployment 4. Support for Self-Service 5. Management and Automation 2. Support for Component Sharing App © 2010 Oracle Corporation 1. Shared Infrastructure with Dynamic Scaling Self-Service Interface Shared Components PaaS Foundation
  • Enterprise Manager Enables Self-Service Provisioning, Monitoring, and Management App Owners © 2010 Oracle Corporation App Set policies Monitor and adjust Self-Service Interface Shared Components Deploy applications Find components Chargeback VM on top of Naked HW Open Standards OS Data Base Grid App Grid Managing Console
  • Private PaaS Requirements Definitive Capabilities for PaaS Infrastructure 3. Support for Fast Deployment 4. Support for Self-Service 5. Management and Automation 2. Support for Component Sharing App © 2010 Oracle Corporation 1. Shared Infrastructure with Dynamic Scaling Self-Service Interface Shared Components PaaS Foundation
  • Enterprise Manager Enables Large-Scale Automation Policy-Based Resource Management and Automation Shared Components Department App Owners App Users © 2010 Oracle Corporation Self-Service Interface Dept App Dept App Dept App Central IT set policies adjust allocation fail over add resources monitor use apps VM on top of Naked HW Open Standards OS Data Base Grid App Grid Managing Console
  • Oracle Private PaaS Case Study:
    • Centralized deployment of 200+ applications
    • 35% reduction in operating costs (Run the Bank costs)
    • Up to 30% reduction in project costs (Change the Bank costs)
    • Prevented 44% increase of power consumption in 4 years, while doubling the capacity
    • No downtime incidents 3 years in a row (2007-09)
    • No service disruption due to DST patching on stack
    Detailed Credit Suisse presentation available
    • Platforms – a key to efficiency
    • JAP – Java Application Platform
    • CHP – Compute Hosting Platform
    • DHP – Database Hosting Platform
    © 2010 Oracle Corporation JAP Charging Unit (VE) price evolution 70 85 100 115 130 145 160 175 190 205 220 235 250 H1 2005 H2 2005 H1 2006 H2 2006 H1 2007 H2 2007 H1 2008 H2 2008 H1 2009 VE Price Linear Reduction
  • © 2010 Oracle Corporation