Introduction to PaaS

Editor's Notes

• #2: Platform as a Service (PaaS) can transform your development, governance, and service level management activities. PaaS can serve as a solid foundation for running IT as a business, increasing agility, optimizing budgets, and reducing time to market. IT professionals require a clear adoption roadmap and evaluation framework, which maximizes Cloud characteristics, adds architecture components, enhances infrastructure capabilities, and improves IT practices.   Chris Haddad will explain cloud characteristics, cloud architecture, and Platform as a Service (PaaS) capabilities. He will describe: How to evaluate Platform as a Service offerings How to establish a roadmap guiding PaaS projects How to quickly deliver a proof of concept demonstrating Platform as a Service benefits
• #4: The company's cloud adoption and legacy modernization strategies will dictate relative priorities of their application migration goals. Rapidly deliver new capabilities Provide access to all devices, customers, and partners Integrate with other Web and Cloud applications Reduce time to market Re-use existing investments Cost effectively scale environment to meet business demand Avoid operating expenses and preserve capital Increase operational efficiency Reduce data center footprint
• #5: What do I need to learn? Determine how to allocate, provision, monitor, manage, and administer resources across multiple tenants Manage resource capacity to ensure consumer demand is satisfied while maximizing resource utilization Scale workload processing while minimizing infrastructure spend
• #6: Platform as a Service resides within the space between Software as a Service (SaaS) and Infrastructure as a Service (IaaS). IaaS delivers basic network, storage, and compute- processing capabilities as standardized, scalable service offerings. Example IaaS offerings include Amazon EC2/S3, Windows Azure VM Role, and RackSpace Cloud Servers). Software as a Service delivers business software capabilities (e.g. expense reporting, logistics, benefits enrollment) and information feeds as online web applications and web services. Pioneered in the early 2000’s, SaaS was used to by independent software vendors to efficiently deliver an application without requiring on-premise installation, remote updates, and cost prohibitive instance management. Platform as a Service is application middleware offered as a service to developers, integrators, and architects. Infrastructure as a Service offers development team a bare-bones infrastructure environment, which requires adding middleware, application frameworks, and infrastructure services (i.e. identity, entitlement, application logging). IaaS encapsulates hardware complexity and applies operational best practices. Operation teams create IaaS Clouds by applying virtualization, automation, and standardization to hardware provisioning and allocation tasks. As teams look to apply provisioning and automation to the application platform, interest in DevOps has grown. The DevOps movement creates a collaborative environment bridging development and operation team members. DevOps enables team members to jointly design, build, and deploy business application and service solutions. The environment closes the gap between business requirements, policies, available run- time resources, and solution development. Development and operation teams use Platform as a Service to design, build, and deliver customized applications or information services. Instead of relying on standardized SaaS, teams using PaaS have more control over solution architecture, quality of service, user experience, data models, identity, integration, and business logic. PaaS offerings often support DevOp practices, which include self-service, automated provisioning, continuous integration, and continuous delivery. Figure 1 illustrates the Platform as a Service space, which incorporates IaaS DevOps practices and increases solution customization options. IaaS could be considered an unfinished house requiring appliances, cabinetry, and fixtures. At the other spectrum extreme, SaaS offers a fully furnished dwelling with little customization. Even if purple dotted lime décor is not your personal style, a SaaS may require you to sit on the purple dotted lime green couch. Alternatively, a PaaS offers a finished house with an array of personalized furniture choices. Because the industry broadly defines PaaS as the level above hardware infrastructure and below business applications, development teams do not commonly have clear comparison criteria to intelligently evaluate frameworks or determine adoption benefits. At a minimum, PaaS offerings differ from traditional application platforms by shielding teams from direct infrastructure ownership, management, and complexity. Figure 1. Relationship between Platform as a Service and other Cloud service layers
• #7: To maximize business benefit, PaaS offerings should significantly exhibit essential Cloud characteristics. The NIST Draft – Cloud Computing Synopsis and Recommendations defines Cloud characteristics as: • On-demand self-service • Broad network access • Resource pooling • Rapid elasticity • Measured service Measured service or pay per use The first Cloud characteristic, measured service, enables pay-as-you-go consumption models and user subscription to metered services. Usage is monitored, and the system generates bills based on charging model. To close the perception gap between business end-users and IT teams, the Cloud solution should bill for business value or business metrics instead of billing for IT resources. Business end-users do not easily correlate business value with an invoice for CPU time, network I/O, or data storage bytes. In contrast, business focused IT teams communicate value and charges based on number of users, processed forms, received marketing pieces, or sales transactions. A cloud native PaaS supports monitoring, metering, and billing based on business oriented entities. Rapid Elasticity A stateful monolithic application server cluster connected to a relational database does not efficiently scale with rapid elastically. Dynamic discoverability and rapid provisioning can instantiate processing and message nodes across a flexible and distributed topology. Applications exposing stateless services (or where state is transparently cached and available to instances) will seamlessly expand and contract to execute on available resources. A cloud native PaaS will interoperate with cloud management components to coordinate spinning up and tearing down instances based on user, message, and business transaction load in addition to raw infrastructure load (i.e. CPU and memory utilization). Resource Pooling Development and operation teams are familiar with resource pooling. Platform environments commonly pool memory, code libraries, database connections, and resource bundles for use across multiple requests or application instances. But because hardware isolation has traditionally been required to enforce quality of service and security, hardware resource utilization has traditionally been extremely low (~5-15%). While virtualization is often used to increase application-machine density and raise machine utilization, virtualization efforts often result in only (~50-60%) utilization. With PaaS level multi-tenancy, deterministic performance, and application container level isolation, an organization could possible shrink it’s hardware footprint by half. Sophisticated PaaS environments allocate resources and limit usage based on policy and context. The environment may limit usage by throttling messages, time slicing resource execution, or queuing demand.   Integration and SOA run-time infrastructure supports the resource sharing and interoperability required to deliver effective resource pools. As teams start to pool resources beyond a single Cloud environment, integration is required to merge disparate identities, entitlements, policies, and resource models. As teams start to deliver application capabilities as Cloud services, a policy aware SOA run-time infrastructure pools service instances, manages service instance lifecycle, and mediates access. On-demand self-service On-demand self-service requires infrastructure automation to flexibly assign workloads and decrease provisioning periods. If teams excessively customize an environment, they will increase time to market, lower resource pooling, and create a complex environment, which is difficult to manage and maintain. Users should predominantly subscribe to standard platform service offerings, and your team should minimize exceptions.
• #8: Some solution architects find Cloud characteristics and supporting PaaS attributes too abstract and infrastructure focused. Architects may be more interested in delivering measurable business value, shielding IT personnel from complex dependencies, and deliver a productive development and operations (i.e. DevOps) environment. The following PaaS capabilities (See Figure 4) are used to achieve these objectives: DevOps Tooling Automated Governance Service Level Management Consumption based pricing   Figure 4: Platform as a Service (PaaS) Capabilities and supporting practices   DevOps Tooling DevOps tooling creates an environment fostering collaboration between development and operations team members. Practice and tooling enable teams to implement self-service configuration, automated provisioning, policy configuration, and process automation practices which bridge the design, build, deploy, and manage phases within the software development life-cycle. By integrating DevOps tooling with on-demand resource instances, teams can reduce time to market and increase agility. Automated Governance Governance is a practice, which defines policies, people, and processes. Effective governance mitigates risks, improves performance, and facilitates correct actions. Automated governance enables application and infrastructure services to efficiently scale across numerous consumers and providers while effectively monetizing, maintaining, and securing assets and consumer-provider interactions. By publishing a service catalogue offering tiered levels of service, teams can promote standard offerings that meet customer requirements. By streamlining access and approval, automated governance encourages customers to choose standard offerings and reduce cost. Scaling a Cloud environment while right-sizing available capacity is non-trivial, and the infrastructure must support demand management and capacity management activities. When organizations move beyond their first Cloud service release, automated lifecycle management becomes a predominant concern. To effectively manage the service lifecycle, the infrastructure must report on service versions, subscribed consumers, and usage trends. In the run-time environment, an infrastructure authority component makes resource allocation decisions, which are enforced by service level management components. Service Level Management Service level management enforces governance policies. PaaS infrastructure should integrate service level management activities throughout the solution stack (i.e. network, processing, storage, managed code container, application platform engines, and application logic). Resource monitoring, resource management, performance management, and traffic orchestration must monitor, manage, and optimize machine node instances, message routing, application service location, tenant security, and session state. Intelligent service level management on Cloud native PaaS infrastructure has the ability to raise infrastructure utilization while maintaining quality of service. Consumption Based Pricing Today, cloud consumption based pricing reflects IT asset monetization (e.g. machine instance per hour, network I/O, storage bytes). However, business users don’t really care how many instances are running in the Cloud. Business users care about business entities, business activity performance, and associated cost. Table 1 below illustrates various pricing units. For example, the number of market leads generated by a marketing piece, or cost to process an insurance policy. Decoupling metering and billing from IT assets and shifting the reporting model to focus on business activity and holistic IT cost will positively change the IT investment conversation. Coupling multi-tenant metering and billing with business activity monitoring and reporting will facilitate the shift.   “Cloud consumers of PaaS can employ the tools and execution resources provided by cloud providers to develop, test, deploy and manage the applications hosted in a cloud environment. PaaS consumers can be application developers who design and implement application software, application testers who run and test applications in cloud-based environments, application deployers who publish applications into the cloud, and application administrators who configure and monitor application performance on a platform. PaaS consumers can be billed according to, processing, database storage and network resources consumed by the PaaS application, and the duration of the platform usage.” Source: http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/NIST_SP_500-292_-_090611.pdf “For PaaS, the Cloud Provider manages the computing infrastructure for the platform and runs the cloud software that provides the components of the platform, such as runtime software execution stack, databases, and other middleware components. The PaaS Cloud Provider typically also supports the development, deployment and management process of the PaaS Cloud Consumer by providing tools such as integrated development environments (IDEs), development version of cloud software, software development kits (SDKs), deployment and management tools. The PaaS Cloud Consumer has control over the applications and possibly some the hosting environment settings, but has no or limited access to the infrastructure underlying the platform such as network, servers, operating systems (OS), or storage.” Source: http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/NIST_SP_500-292_-_090611.pdf
• #9: Cloud computing, PaaS, and DevOps tooling is an opportunity to raise infrastructure abstraction. Figure 5 demonstrates the continuum from hardware infrastructure to business entities. DevOps tooling integrated with PaaS should shield developers from hardware infrastructure concerns and expose business entities. While Cloud washed PaaS does often facilitates hardware infrastructure configuration, enables rapid infrastructure installation, and delivers machine level access to Cloud machines, the Cloud washed PaaS environment does not shield development team members from hardware infrastructure complexity. Development team members must still be experts in machine sizing, Java Virtual Machine (JVM) configuration, and network topologies.   Some PaaS environments do hide hardware infrastructure concerns and instead expose application platform entities. Application developers can work with familiar application platform entities (i.e. .war files, application frameworks, application sessions), easily install applications on the Cloud, and configure application instances. Cloud environment exposing application platform entities will deliver a familiar application development model and provide the team with a high level of control.   With both the hardware infrastructure and application platform abstraction levels, teams can often forklift existing applications into the Cloud with few modifications. The migrated applications will run in the Cloud, but will not be purpose-built for the Cloud. If Cloud benefits are derived by delivering capabilities ‘as a service’, business entities should be exposed, composed, connected, consumed, and orchestrated as services. A business entity perspective is required to decompose applications and flexibly distribute the entities across Cloud nodes. PaaS environments exposing APIs, services, and communication channels deliver application building blocks at an appropriate abstraction level. Multi-tenancy is extended inside the application, and tenancy can be applied to users, workspaces, and transactions.
• #10: A Platform as a Service offering should promote deploying applications onto a flexible, distributed topology. To maximize Cloud characteristics, a PaaS should facilitate scaling way out (e.g. across cloud zones, data centers) and automatically distribute fine-grained service component resources. Figure 6 presents a logical view of a cloud application executing across a distributed topology. The Integration Services PaaS service component is used to connect application service components and external cloud services by message passing, not function invocation. Integration services commonly include a Enterprise Service Bus (ESB), service governance registry, service gateways, and message brokers.   Figure 6: Cloudy Topology
• #11: The diagram shows a target architecture for an application deployed on aPaaS. This architecture emphasizes the "services," not the technology stack. Not just infrastructure services like security, but application services (messaging, data stores, integration) have been factored out. Separate tiers into distinct executing units. Developers can only do topology tricks if they have service design principles baked into software design: clean separation of concerns, loose coupling and functionality refactored into services. Shared nothing is preferable. Importance of service contract and service interface is paramount. When you start to pull things apart like this you need well described interfaces. You want to normalize those interfaces — to avoid n (to power of m) relationships. Cloud target architecture blends patterns such as distributed caching, asynchronous messaging and parallel processing. When everything is a service, middleware itself is virtualized. A mind-set switch is required — IT becomes a service provider, not a technology provider. Public aPaaS providers like Google, Microsoft amd Amazon understand this. Using networked managed services instead of including them in an app/package on a VM, e.g., App Engine: BigTable, TaskQueues, Memcache; Azure: SQL Azure, AppFabric; Amazon: RDS and SQS. Burton has talked about this for 10 years as the Infrastructure Services Model. The "service" in aPaaS is not just services for operating the platform, but also a collection of application services for building systems.
• #12: Definition: "Rebuild" your solution on a provider's application platform, while discarding code for an existing application. Rebuild requires rearchitecting the application for a new container (e.g., from Java to .NET). "Forward-compatible" or incompatible PaaS tends to result. Not all existing programming models, frameworks, and languages will be retained. What services am I consuming? An externally managed application platform to build and run applications. Audience: Professional and "citizen" developers.Examples: Building a force.com application for order management; Modernizing a C and FORTRAN financial risk calculation application by redesigning it in C#, then using Windows Azure platform libraries and tools to deploy it to Microsoft's cloud.Advantages: Developer productivity is improved with tools that allow application templates and data models to be customized, metadata-driven engines, and communities that supply prebuilt components. Transparent automatic scalability. Allows non-professional developers the opportunity to develop and deploy simple applications into production. Multitenancy means the provider manages upgrades and patches. Disadvantages: Lock-in and PaaS immaturity are the primary disadvantages. Abandoning familiar programming languages and frameworks means that second sourcing strategies to mitigate lock-in risk may not work.
• #15: As an application platform in the Cloud, PaaS should facilitate Cloud characteristics (i.e. elastic scale, on-demand self service, resource pooling, and consumption based pricing). While all middleware vendors purport to deliver a platform product or service powering the Cloud, all PaaS offerings do not deliver appropriate granularity, abstraction, capabilities, simplicity, and solution breadth. When attempting to achieve Cloud characteristics, development teams often specify the following goals   Ensure an application satisfies consumer demand while maximizing resource utilization Scale workload processing and increase performance while minimizing infrastructure spend Allocate, provision, monitor, manage, and administer resources and policies across multiple tenants, nodes, and locations Rapidly deploy application and service components on a preferred topology that meets deterministic performance requirements (e.g., replication, utilization, latency, bandwidth, and coherency) To achieve these goals, PaaS offerings can be evaluated and compared across the following criteria categories: Cloud Characteristics Measures characteristics (i.e. on-demand self-service, resource pooling, rapid elasticity, and measured service) used to distinguish Cloud solutions from traditional application solutions. Cloud Dimensions Measures how widely the solution can be shared (i.e. private, public, community), who is responsible for PaaS environment management (i.e. internal, external), and where the PaaS is located (i.e. on-premise, outsourced) options Production Ready Measures PaaS maturity and suitability for enterprise, mission critical level use DevOps Activities and Lifecycle Phases Measures how to design, construct, deploy, and manage applications and services using DevOps practices (i.e. continuous integration, continuous delivery, automated release management, and incremental testing) Cloud Architecture Measures architecture principles, concepts, and patterns enabling applications to dynamically execute parallel workloads across a highly distributed environment Platform Services Measures how completely the PaaS satisfies development of complex applications by providing comprehensive application middleware components and services Programming Model Measures programming languages and frameworks, which facilitates building applications and services exhibiting Cloud characteristics
• #16: Cloud characteristics define how the Cloud solution differs from traditional, terrestrial infrastructure. As defined by NIST, Cloudy solutions exhibit the following characteristics: On-demand self-service Resource pooling Rapid elasticity Measured service or pay per use   On-demand self-service breadth and depth are key evaluation sub-criteria. Can solution architects and end-users subscribe to applications, services, data repositories, and communication channels? Alternatively, is the on-demand self-service capability a lower level mechanism that can reserve and allocate hardware infrastructure (e.g. machine instances, storage)   Resource pools can be reserved on a fixed or dynamic basis. While fixed reservations deliver higher assurance of faster application response, dynamic resource reservation optimizes expense. Just in time resource allocation in conjunction with true measured service where charges are applied only when an application is processing a service request will lower expense. Many organizations pay for warm application instances, which are infrequently used. Sophisticated PaaS environments allocate resources and limit usage based on policy and context. The environment may limit usage by throttling messages, time slicing resource execution, or queuing demand.   PaaS offerings score high (10) when they exhibit cloud characteristics at the appropriate abstraction level (i.e. application component, application service, data set, business process), and score low (1) when they only enable self-service, pooling, elasticity, and pay per use for IT infrastructure assets (i.e. machine, network I/O, storage bytes).   For more information on Cloud characteristics, read the NIST Draft - Cloud Computing Synopsis and Recommendations.
• #17: This evaluation criteria measures how widely the solution can be shared (i.e. private, public, community), who is responsible for PaaS environment management (i.e. internal, external), and where the PaaS is located (i.e. on-premise, outsourced) options. Before selecting PaaS infrastructure, understand how sharing, location, and responsibility impact your decision. Public, private, or community attributes specify how widely the cloud service is shared; a sharing dimension. Internal or external denote the consumer's view of the Cloud's service interface. The view is associated with a consumer's responsibility for service development, operations, and management; a responsibility dimension. A third dimension, on-premise or outsourced, describes where the service assets are located; a location dimension. A hybrid cloud strategy delivers, spans, and connects clouds across all dimension attributes.   Your organization and team will often be confronted with delivering, connecting, and spanning solutions across diverse private and public Cloud environments. Your Platform as a Service architecture and platform service offering should provide a holistic hybrid environment consistently applying governance and policies across internal and external Clouds. Hybrid cloud use cases require interoperability, federation, SOA principles, and infrastructure services to bridge Cloud environments into a unified platform.   PaaS offerings score high (10) when they can run within all dimension coordinates, and score low (1) when they only run within a subset of the dimensions.   For more information on Cloud dimensions, view Chris’ blog post.
• #18: This category measures PaaS maturity and suitability for enterprise, mission critical level use. The production ready criteria category measures whether: The service provider offers production support warranties The PaaS offering services a significant number of paying customers The PaaS service maturity The Service Level Agreement (SLA) quality The Quality of Service (QoS) warranted by the service provider A production ready PaaS offering will be supported by sophisticated service level management capabilities. The PaaS offering should include the following service level management capabilities: Resource monitoring Resource management Resource quota management Performance management Traffic orchestration (i.e. message throttling, message routing, message correlation)   PaaS offerings score high (10) when they are fully supported, mature, and fulfill comprehensive service level and quality of service requirements. PaaS offerings score low (1) when they are pre-production releases and do not warrant service levels.
• #19: This criteria category measures support for DevOps activities across software development life-cycle phases (i.e. design, develop, test, build, deploy, manage). The category describes the tools and processes used manage application construction and maintenance tasks. Relevant sub-categories include: PaaS integration with on-premise software development life-cycle tooling PaaS integration with on-premise automated service governance tooling and policy repositories Supported DevOps activities (e.g. automated provisioning, self-service configuration, process automation, continuous integration, continuous deployment) Automated governance including: Service catalogue and service tiers Demand and capacity management Life-cycle management Infrastructure Authority integration   PaaS offerings score high (10) when they are well integrated with preferred software development life-cycle tooling across all application life-cycle phases. PaaS offerings score low (1) when they deliver a disconnected and siloed design, development, deployment, and management experience.
• #20: This category measures architecture principles, concepts, and patterns enabling applications to dynamically execute parallel workloads across a highly distributed environment. The PaaS architecture model should shield application developers, integrators, and architects from infrastructure, natively support cloud characteristics, and exhibit Cloudy architectural attributes (i.e. tenancy, dynamic discovery). Cloud architectural attributes should span the entire solution stack, and not be constrained to components below the application server. The Cloud Architecture criteria category measures conformance with architecture principles enabling: Measured service or pay per use Evaluate the PaaS solution for fine-grained metering, billing, and reporting of business entities, activities, and interactions. For example, can the PaaS meter the number of workspaces created, users added, or business transactions executed?   Rapid elasticity Mature PaaS offerings scale discrete application service instances rather than scaling monolithic application instances. An ability to rapidly provision small footprint services based on user demand will increase application density and infrastructure utilization. PaaS offerings should exhibit rapid service provisioning, flexible resource allocation, and distributed topologies. Implicit support for shared nothing architecture and the Thirteen Dwarf patterns (e.g. MapReduce) enables application decomposition, parallel processing, and resource coordination.   On-demand self-service Mature PaaS offerings do more than push application bits to a Cloud node. Mature PaaS offerings perform flexible, run-time workload assignment and automated startup of standard service offerings. Cloud architecture components include a Cloud controller, Cloud service provisioning, and Cloud load balancer.   Resource Pooling Mature PaaS offerings supply shared everything containers to hosted applications. Multi-tenancy is incorporated throughout the solution stack (i.e. network, processing, storage, managed code container, application platform engines, frameworks, and application logic). Resource utilization is tracked by business transaction or business entity access, and resource allocation conforms to well-defined policies. Distributed caches are used to share resources across entitled tenants while enforcing security.   PaaS offerings score high (10) when they deliver enhanced capabilities at high abstraction and fine granularity. PaaS offerings score low (1) when they do not extend capabilities beyond levels offered by traditional application platform infrastructure.
• #21: This category measures how completely the PaaS satisfies development of complex applications by providing comprehensive application middleware components and services. Teams compose platform services to rapidly design, develop, deliver, deploy, and manage applications. Platform services span the following broad categories: Presentation services Application and service container services Business process and business rule services Integration services and message brokers Composite application services (i.e. mashups and orchestration) Complex event processing services Data access and persistence services Development governance Application life-cycle management Automated run-time governance services Policy registry and repository services Identity management Security Service level management Compute, network, and storage infrastructure services A complete, unified platform decreases integration cost, reduces solution complexity, and enables uniformly applying policy and process. PaaS offerings score high (10) when they deliver a comprehensive platform service list and score low (1) when they offer a small subset of the platform required to effectively deliver complex applications and services.
• #22: The programming model category measures programming languages and frameworks, which facilitates building applications and services exhibiting Cloud characteristics. The Cloud programming model is fundamentally different from the web programming model which fueled Java EE’s popularity. To maximize cloud benefits, development teams must adopt new programming models, architecture patterns, and frameworks. The actor model, service composition, RESTful interactions, policy injection, and tenant aware frameworks extend Java into the Cloud.   A Cloud programming model facilitates building applications and services, which exhibit Cloud characteristics. The programming model should be congruent with Cloud architecture principles and patterns. Example detailed criteria include: Actor model (i.e. message passing instead of function invocation RESTful interactions Dynamic recoverability Consensus protocols Asynchronous rather than synchronous interactions Shared nothing architecture Data partitioning and sharding Federated data queries Service orchestration Functional programming MapReduce   PaaS offerings score high (10) when the programming model explicitly supports parallel processing, distributed interactions, shared nothing architecture, workload decomposition, and hide infrastructure complexity. PaaS offerings score low (1) when they expose data center infrastructure concepts (i.e. machines, storage parameters, network addresses) and do not elastically scale beyond traditional application server clusters.
• #23: See blog post: http://blog.cobia.net/cobiacomm/2011/11/02/paas-evaluation-framework-for-cios-and-architects/
• #24: Agreeing on a strategic goal and gaining stakeholder buy-in is only the first step. Teams should define key metrics, baseline current performance, and create a quick start project plan to prove PaaS benefits. Metrics can be divided into foundational, optimal, and transformational categories. A few example metrics to consider are:   Foundation Time to create new application environment Time to redeploy application Optimize Minimum and maximum scale Scale frequency (i.e. time to scale up/down) Transformation Time and effort required integrating business process, event processor – creating a complex app. Time and effort required to apply policy across tenant(s) Cost to operate application per user or transaction
• #25: In today’s IT environment, demonstrating tangible improvement is often illusive. Rather than simply stating a goal, randomly selecting a PaaS provider, installing an application on the PaaS, and declaring success, your team has an opportunity to demonstrate and prove how PaaS capabilities can improve agility, efficiency, or platform economics. Your team should correlate quick start demonstration use cases with PaaS capabilities and key metrics. The following listing details a sample plan:
• #26: DevOps Tooling and On-demand self-service Use Cases Rapidly provision application environment Rapidly provision application tenant Allocate, provision, monitor, manage, and administer resources across multiple tenants, nodes, and locations Develop complex, composite integrated applications Key metrics Time to create new application environment Time to redeploy application
• #27: Automated Governance Use Cases Create users and configure rights Deploy on preferred topology that meets deterministic performance requirements (e.g., replication, utilization, latency, bandwidth, and coherency) Create service throttling and security governance (XACML) policies Key Metrics Time and effort required integrating business process, event processor – creating a complex app. Time and effort required to apply policy across tenant(s)
• #28: Service level management and elastic scale Use cases Ensure application satisfies consumer demand while maximizing resource utilization Scale workload processing and increase performance while minimizing infrastructure spend Load test application service Demonstrate multi-tenant web application Key Metrics Minimum and maximum scale Scale frequency (i.e. time to scale up/down)