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”.
Welcome to this session on the Essential Building Blocks of Private Platform-as-a-Service. We’ll start with an overview of what Private PaaS is within the context of cloud computing. The core of the presentation is a discussion of what it takes to create a private PaaS and what Oracle technologies there are—the building blocks—to enable you to set up your own private PaaS. We end by taking a look at some specific examples of how our customers are implementing private PaaS.
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.
So to map Oracle technologies and products to this basic private cloud reference architecture, [click] we have Oracle VM and Oracle Enterprise Linux at the infrastructure layer, [click] Oracle Database and Fusion Middleware above that, [click] and Oracle Enterprise Manager as the management that ties these technologies together. [click] All together these constitute the Oracle PaaS Foundation.
[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.
So with that as background, we’ll turn now to what it takes to actually build a private PaaS.
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.
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.
Let’s zoom in on the role of middleware within our Foundation. A number of Oracle Fusion Middleware components play important roles in the platform, and in particular application grid enables the dynamic capacity adjustment we just discussed.
The idea of application grid is that you have a number of physical resources and a variety of application workloads to support with those resources. Traditionally these were allocated statically in dedicated stacks; [click] with application grid you have pooling and sharing of resources with automated, dynamic adjustment of resources enabled at the application server level. [click] the technologies we’re talking about are the app server itself, WebLogic Server for Java and its counterpart Tuxedo for C, C++, and COBOL, with related supporting technologies such as the Coherence in-memory data grid, JRockit Java Virtual Machine, and Enterprise Manager.
To drill down a bit on WebLogic Server in particular, WebLogic Server has long had industry-leading clustering abilities. Not only can one dynamically add and remove nodes to live clusters, WebLogic Server automatically rebalances workload in such adjustments and can be set up to automatically startup new nodes in the event of node failure. This supports horizontal scale-out AND high availability. And this mechanism can be engaged by external management such as Enterprise Manager for optimization within the bigger application grid context.
Coherence is an in-memory data grid. The basic function of this is to use the memory of multiple machines as if it were all local, appearing to an application as a single contiguous block of memory. Coherence makes effective use of even huge memory on each machine, beyond the several-gigabyte limit normally seen with JVMs on 32-bit machnes. By replicating objects and holding them in memory close to where the computation is carried out, both reliability and performance are greatly improved. Nodes can be added and removed dynamically, meaning Coherence is an important mechanism to support application grid’s dynamic capacity adjustment across shared resources. And Coherence can scale to literally thousands of nodes.
Complementing the dynamic resourcing enabled by application grid is the dynamic resourcing at the database level, also using grid computing techniques. Starting in the middle of our picture, Real Application Clusters, RAC, is the database clustering mechanism that optimizes performance, availability, and scalability. An in-memory database cache is about caching relational data in memory. This complements the clustering enabled by RAC and also complements Coherence is about holding large numbers of Java objects in memory. Oracle In-Memory Database Cache allows us to build database caches in the memory of the application servers and process the data locally to the application. By caching the most commonly accessed subsets of rows and columns, fast consistent response times with high transaction throughputs can be achieved. Data remains synchronized with Oracle Database through a standard SQL interface. Automatic Storage Management creates a grid of storage for a database that can also be adjusted dynamically and automatically.
Drilling in a bit on RAC, RAC is unique in database technologies in its support of grid architecture and mechanisms, particularly with its ability to adjust dynamically and automatically. Not only does this support the elastic capacity required by private cloud, it substantially enhances ongoing management tasks such as upgrades, patches, and migration without compromising zero-downtime requirements.
Oracle In-Memory Database Cache is an OPTION of Oracle Database. It is based on TimesTen. Why fast? Entire database in memory, avoid slow disk accesses; deployed in middle tier, closer to the application, avoids round trip to the database server; optimized, short code path Automatic data synchronization Updates in cache propagated to Oracle database Updates in Oracle database refreshed to in-memory cache tables Supports read-only and updateable caches
ASM brings the clustering, pooling, sharing, and dynamic adjustment of grid computing that we’ve been talking about to the area of database storage.
You may have heard about Oracle’s most recent hardware offering, the Exadata database machine. This is world’s highest performance database machine along a number of dimensions. It is also an important option for enterprises looking to create a private cloud on consolidated infrastructure. Performance Facts… #1 in I/O Throughput – Up to 65 GB per second (uncompressed data) – scans can now access disk and flash simultaneously, going beyond 50 GB per second of Flash-only. #1 in I/O Rate – Up to 1 million I/O’s per second (full rack) #1 in Compression – 3x to 15x data compression (we have seen over 70x compression on some data sets)
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. [click] 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.
[click] Here we look at the case for UI components. In a similar fashion as for SOA and BPM components, Central IT creates the reusable components, and each cloud tenant finds the ones he needs via the self-service interface and includes them as appropriate. [click] Now let’s say we have multiple apps owned by different Department tenants (App Owners) and sharing the same UI components. [click] Central IT needs to make an important change to the corporate branding or policy and modifies one of the platform’s shared UI components accordingly. The beauty of the platform is that the centrally-made change is immediately picked up by all the tenant apps sharing that platform component.
Now let’s turn to the third PaaS requirement, support for fast deployment.
At the bottom of the stack, one of the most powerful enablers of fast deployment is server virtualization. Let’s contrast it with our traditional world, where for every app one typically has to procure and configure hardware, install and configure all the layers of the stack from OS up through middleware, and then ultimately install the app. This approach is time consuming and more prone to human error and administrative churn. In a virtualized server world, the stack can be pre-packaged as essentially a file—these packages are often referred to as virtual machine images, or templates, or appliances. Once a stack has been packaged into an appliance, that appliance can be deployed onto virtualized servers practically instantly, and can scale to tens, hundreds or even thousands of servers. Once an appliance instance is running, it can be moved or “live migrated” to different virtual servers for resource optimization.
Oracle VM is Oracle’s server virtualization offering. It is based on the open source Xen hypervisor, runs Oracle as well as non-Oracle software including Linux, Windows, and other operating systems. It is free to download and distribute. Xen 是一个开放源代码虚拟机监视器,由剑桥大学开发。它打算在单个计算机上运行多达 100 个满特征的操作系统。操作系统必须进行显式地修改(“移植”)以在 Xen 上运行(但是提供对用户应用的兼容性)。这使得 Xen 无需特殊硬件支持,就能达到高性能的虚拟化。
Moving up the stack, there’s an exciting new innovation in Oracle Fusion Middleware that allows you to get even more out of server virtualization: WebLogic Server Virtual Edition. WebLogic Server Virtual Edition is a variant of WebLogic Server designed to run directly on a virtualized server with no operating system. This is significant because, not only does it greatly improve the performance of Java apps running in virtualized environments, it makes the appliances themselves substantially smaller given the absence of the OS. WebLogic Server Virtual Edition appliances are thus faster and easer to create since there’s no OS to configure, faster to deploy since a much smaller appliance image is being transmitted to and started on the virtual server, and faster to live-migrate, since again there are fewer bits to transfer. These appliances are also easer to administer since there is no OS to patch and upgrade, and more secure since there is no OS presenting opportunities for breech.
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.
The second critical area is security. Let’s again extend our PaaS lifecycle model. Central IT creates and registers shareable platform components, but now we highlight how they can set policies using Oracle Identity Management Suite and Oracle Enterprise Manager. Subsequently, when a departmental app owner logs into the self-service interface to create app, he is presented with only the components for which he is authorized based on his role and the policies in place.
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.
Now, with that very brief introduction to what a private platform as a service is and how to build one using Oracle technologies, we take a look at how a few customers are evolving toward PaaS environments in their IT shops.
We start with Credit Suisse, a leading global investment bank and important Oracle WebLogic Server and Database customer. To address sprawling, heterogeneous infrastructure that challenged quality assurance and production support, they built a centralized, shared services platform called the Java Applications Platform on WebLogic Server.
We’re talking about a global operation centered at Credit Suisse’s Zurich headquarters, with hubs in Singapore and New York. In Zurich the centralization effort consolidated the resources underlying 190 applications from 2,800 servers down to 400, a substantial 7:1 improvement, leveraging WebLogic Server’s clustering and other consolidation-supporting features.
To truly realize the value of the consolidation enabled by WebLogic Server, Credit Suisse made substantial changes to their human IT processes as well. A customer-focused developer support function guides projects through the entire development process. A Centralized Platform Product function drives the development and release lifecycle according to a well-defined governance model. The Operations department runs applications cost-efficiently with standardized processes. These three processes depend on consistency of architecture guidelines, shared managed components, tool-chain automation, and centralized shared hosting.
The results have been significant: standardization has made for higher quality, greater agility, faster learning, and more transparency on the technical side, resulting significant reduction in operating costs and service issues.
Rakuten Travel (an orbitz.com equivalent in Japan) ,migrate their current system to an ASM based, 10 node 11gR1 system without HACMP. Their prior system was running on a 9 node 10gR2 cluster with HACMP and no ASM. They are a Oracle RAC reference customer in Japan. RAC SCP Customer Migrated from 10g to 11g, moved to a pure Oracle stack off of HACMP. Also grew the number of nodes. OLTP nodes have 16 cores, Batch nodes have 8 cores. Rakuten Travel has 16-cores Machine x 7 and 8-cores Machine x 3 (Total: 10 nodes). Environments run on LPARs, sometimes two of them per physical box. Reason for splitting a larger machine into two LPARs for the cluster include: When they decided to purchase a new server in 2004, they only needed 8cpu more of computing power, so 16-way x 3 was not an option. They wanted to avoid having a mixed cpu count setup (16, 16, 8) at the time (currently they do have a mixed setup ). Having more nodes give them more computing power when a server fails.
For More Information: Press Release - http://www.oracle.com/corporate/press/2008_jan/pge.html Magazine Article - http://www.oracle.com/technology/oramag/oracle/08-jul/o48green.html
We’ll wrap up with a short summary.
We’ve shown here how private platform as a service is a natural strategy for enterprises. It takes centralization, consolidation, and shared services to the next level, providing enterprise departments with self service and automated capacity adjustment in a model that maximizes flexibility and control. Oracle offers the most comprehensive set of building blocks for and enterprise to create a private platform as a service, including unmatched grid capabilities at all layers of the stack backed by years of investment and industry leadership in grid, virtualization, and SOA. Thanks very much for listening, and we wish you the best in your private platform-as-a-service as well as other IT projects.