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.