Achieve business agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaS
•Als PPTX, PDF herunterladen•
1 gefällt mir•1,379 views
This document discusses how Platform as a Service (PaaS) can help achieve business agility through cloud APIs, cloud-aware applications, and cloud DevOps. It describes how PaaS provides on-demand infrastructure, multi-tenancy, automated provisioning and deployment, and cost advantages over traditional hosting through high container utilization rates and pay-per-use models. The document advocates adopting cloud-native architectures and patterns like microservices, asynchronous communication, and shared-nothing designs to develop cloud-aware applications on PaaS.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Achieve business agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaS
Ähnlich wie Achieve business agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaS (20)
Mehr von WSO2
Mehr von WSO2 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Achieve business agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaS
- 1. Achieve business agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaS Chris Haddad @cobiacomm on Twitter http://blog.cobia.net/cobiacomm Read more about Platform as a Service at http://blog.cobia.net/cobiacomm/tag/paas/
- 3. Cloud Delivers The Speed of Now • Time to create project workspace • Time to build, integrate, test • Time to approve, promote • Time to deploy, release • Dwell time – time waiting for the next operation to commence or complete
- 4. Cloud Yields
- 7. Resource Tier Cloud Scale and Distributed Providers Functional Role Client Tier API aggregation and orchestration API aggregation and orchestration Resource Services Functional Role Presentation and Mashups Functional Role Functional code Presentation Role Presentation and Mashups Presentation and Mashups Resource Services Private Applications Public Cloud Services Business Proces Business Process Business ProcessBusiness Process and Business Rules
- 8. Cloud Architecture Best Practices Transitioning to a New normal – Traditional practices may not apply • Distributed and federated interactions – Event based, heterogeneous systems, network latency • Configurable containers and engines – Declarative data, rules, and process definitions • De-normalized and simplified data models – Hadoop/BigTable, Hypertext media, simple NoSQL entities • Expect failure – Systems span transactional control • Applications decomposed into distinct services – Federated environment drives autonomy, statelessness, and composition
- 9. Cloud Application Patterns and Anti-Patterns 18 Deterministic performance Deploy and execute on optimum topology Separation of concerns Embarrassingly Parallel / Shared Nothing ArchitectureMinimal Consumption Failure Resilient Leaky interfaces Tightly coupled modules Monolithic footprint Single threaded, serial execution Resource locks Single tenancy model
- 10. Cloud Aware Application Goals and Underlying Cloud Patterns • Maximize utilization – Requires deterministic performance – Load balance based on tenant, service, and workload, context • Increase reliability, availability, scalability – Shared nothing architecture – Stateless server-side elements – Consensus protocols • Ecosystem platform – Monetize assets based on business value – Tenant/Consumer personalization and isolation – Sharing domain specific business capabilities
- 11. Architectural Difference Between Web Application and Cloud-aware Application Web Application • Synchronous request-reply interaction • Centralized state (i.e. single database) and session management • Clustered server instances • Silo architecture Cloud-aware Application • Asynchronous interaction • Queues and workers • Scale out across datacenters and providers • Distributed state and session management • Autonomous service instances • Tenant context personalization • Shared JVM / Shared Schema • Shared nothing architecture
- 12. Shift towards Cloud-aware Application Programming Model • 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 • API/Service orchestration • Functional programming • MapReduce – and the Thirteen Dwarf patterns
- 14. PaaS Architecture What is a tenant? • An isolated or personalized run-time environment context that cannot be shared across PaaS consumers • Tenant specific personalization can occur across multiple personalization dimensions • Information access privileges • Information aggregation and composition • Business processes and rules • Service levels and Quality of Service • Security policies, subscriber entitlements, and social network access privileges • Monetization rates • Personalization may require loading code, configuration files, or data • Tenant isolation dictated by expected performance, security requirements, and legacy technology. • PaaS security managers, code deployers, and tenant-aware load balancing influences required container-level isolation
- 15. PaaS Architecture What is a container? • A standalone, Internet addressable node offering application platform services • Web application hosting, API management, integration endpoint hosting, ESB mediation, registry services, identity management, relational database • Containers host tenant resources and context • Code, configuration files, data, process definitions, rules, policies, entitlements • Containers may serve • a single tenant at a time (dedicated), or • multiple-tenants at a time (shared)
- 16. PaaS Architecture What is a partition? • Partitions define distinct container resource pools • Partition containers to tune container sharing, service resource allocation, QoS, and utilization • Containers may be assigned into service-specific or tenant specific partitions
- 18. Consider Enhanced Virtualization Models WSO2 Stratos 2.0 supports all models and model combinations Stratos Carbon (Shared Process) Agility Resource Optimization Pure Hardware Virtual Machine Stratos Cartridge (LXC) IaaS Machine Instance
- 19. Cloud Native PaaS Difference
- 20. Partitioning and Container Tenancy Impact Tenant-First = Three Tenants and 5 Containers
- 21. Partitioning and Container Tenancy Impact Service-First = Three Tenants and 3 Containers 40% footprint reduction
- 22. Tenant-aware and Service-aware Load Balancing
- 23. Total Cost of Ownership Levers • Rapid elasticity • Provides ability to turn-on additional containers only when demand requires more capacity • Provides ability to turn-off under utilized containers and lower expense • Measured Service and Pay Per Use • No foundational infrastructure investment required • Possibly a minimal up-front registration investment • Only charged for usage (e.g. platform up-time, deployed application count, transaction count) • Resource Pooling • Minimize usage cost by sharing and re-using resources • On-demand self-service • Create and provision platform without third party participation
- 24. Total Cost of Ownership Advantage • Rapid elasticity • Containers shared across multiple tenants • Capacity managed per service, not per tenant • Single, flat container partition space enables maximum sharing • Containers may be partitioned by service • Resource Pooling • Application footprint lower than single tenant, dedicated container deployment • Lazy loading further minimizes footprint
- 25. Total Cost of Ownership Advantage • Measured Service and Pay Per Use • Cloud infrastructure investment recaptured after 4 tenants subscribe (at full-time usage per tenant) • Can meter and bill based on business transaction usage, application count • On-demand self-service • Application teams do not have to specify infrastructure topology (i.e. server count) • Subscribe to application platform services instead of application server instances
- 26. Attributes influencing Total Cost of Ownership • Container sharing and tenant isolation level • Tenant Density per JVM or Application Server • Container license cost •Read entire methodology at •http://blog.cobia.net/cobiacomm/2012/05/13/ paas-tco-and-paas-roi-multi-tenant-shared- container-paas/
- 27. Open Source PaaS Cloud Native Architecture http://blog.cobia.net/cobiacomm/2013/04/18/cloud-native-paas-architecture/
- 28. WSO2 Architecture Advantage Availability Scalability Management Load monitor Tenant partitioning Private jet mode Cloud controller Balancing and failover across hybrid clouds Ghost deployment BigData Logging infrastructure State replication and session replication BAM 2.0 architecture Artifact Distribution Controller and Deployment synchronization Multiple load balancers with keepalived or DNS RR Auto-scaling P2 Repository Native multi-tenancy Elastic Load Balancer Consistent management and infrastructure services across entire platform Dynamic Clustering Multi-tenant shared container Management console 28
- 29. Close the Loop between Cloud-apps, Cloud PaaS, and Cloud Infrastructure • Specify Scale Parameters – Tenancy and sessions – Partitioning and sharing • Monitor Quality of Service – Service tier – Performance and utilization – Expected load per API call or web request • Trigger Provisioning and Deployment Events – Automated Provisioning – Automated Deployment
- 31. Automated App Deployment Service
- 32. Fast Time to Value with On-demand Contextual Personalization Increase agility • Rapidly adapt and fulfill new market demand • Reduce time to introduce new services, applications, and products into long tail market(s) On-demand Contextual Personalization • Information access and social network access privileges • Information aggregation and composition • Business processes and rules • Service levels, Quality of Service, and monetization rates • Security policies
- 33. Cloud Business Value For Development Teams 33 Lower development barriers • Provide on-demand Application Development project infrastructure and run-time environments • Catalogue of re-usable open APIs, cloud services, and domain frameworks Lower adoption barriers • On-demand web application and Cloud API subscriptions via a self-service provisioning portal • Establish searchable registry of app, service, api, and data descriptors • Reliable, available, and scalable solutions
- 34. Best Practice Adoption and Process Repeatability • Cost-effective, development, collaboration, and deployment infrastructure enabling a long tail of application development • Architecture templates and application platform services • A shared environment for cross-organization application development and delivery • Governed, iterative lifecycle management across hybrid clouds and composite applications • IT Business performance metrics and analytics • Infrastructure enabling user experience composition across multiple disparate application providers
- 35. Enterprise DevOps PaaS Bridging Development with Deployment
- 36. DevOps Streamlines Iterations A developer’s perspective
- 37. Service Performance Metrics • Foundational – Time to Market • Optimization – Portfolio Efficiency • Transformational – Productivity
- 38. 7 +/- 2 Cloud Roadmap Objectives 1. Engage stakeholders in a collaborative development workspace 2. Promote best practice workflow, architecture, and governance practices 3. Deploy applications into a Cloud run- time environment 4. On-demand application subscriptions via a self-service provisioning portal 5. Share applications across multiple tenants (e.g. departments, workgroups, employees, partners) 6. Scale run-time to meet usage 7. Deploy Open APIs 8. Encourage API adoption via API Store 9. Track business activity and analyze Cloud service usage, performance, and cost 38
Hinweis der Redaktion
- Achieve Business Agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaSTo match today’s rapid business pace; teams are adopting flexible Cloud-Native architecture and composing APIs into business-driven, Cloud-aware solutions. This workshop will describe how you can adopt API-first practices, remix Cloud services, and accelerate agility using DevOps PaaS. As teams reshape IT architecture, new business model innovations are possible.
- The Breakup of the CorporationAgile, Collaborative EcosystemsThe Long TailKeeping pace with IT innovation
- In the abstract, business agility can be defined as your ability to rapidly change business vectors. A business vector is your business speed and direction. The direction may lead into nIew markets and new products, or engaging with new participants. Reducing time to IT solution delivery increases your team’s ability to adjust the business vector and match business opportunity.With adequate instrumentation, IT delivery agility can be quantified. Consider the following agility metric recommendations:Time to create project workspaceTime to build, integrate, testTime to approve, promoteTime to deploy, releaseDwell time – time waiting for the next operation to commence or completeAfter application project inception and before coding commences, systems administrators must create project workspaces. How long does your team wait before gaining access to source code management repositories, requirement management projects, and defect tracking projects?Moving code through build, integration, and test tools is often a time and labor-intensive process. The entire team waits while applications assets are built, integrated, and tested. When teams use iterative development processes, the wait time aggregates over several hundred or thousands cycles. How long does your team wait during build, integration, and test phases?When one team member finishes a task and the work enters an approval phase, how long does the team wait? After the work is approved to move through phase gate, how long before the project is promoted into the next phase?
- When defining a roadmap to align IT’s pace with business agility expectations, establish IT team objectives that quicken IT solution development and delivery, offer new technology as on-demand shared services, and enhance your team’s ability to rapidly satisfy emerging business use cases (e.g. social collaboration, mobile application connectivity, ecosystem partnering).Open source PaaS, Open APIs, and Open Ecosystems are accelerating agility, empowering developers, and enabling innovative business strategies. In a recently published white paper, I describe how adopting a New IT plan can create a responsive IT team.The path to New IT requires moving away from traditional application platforms, traditional team structure, and traditional information flows. Responsive IT teams are adapting their infrastructure, processes and tooling to re-invent the application platform and re-think application delivery. The New IT architecture underlying Responsive IT intelligently incorporates Cloud Platforms, BigData Analytics, Enterprise DevOps, and API first development.
- 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
- 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 invocationRESTful interactionsDynamic recoverabilityConsensus protocolsAsynchronous rather than synchronous interactionsShared nothing architectureData partitioning and shardingFederated data queriesService orchestrationFunctional programmingMapReduce 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.
- New Agile, Multi-Purpose Toolshttp://www.candlepowerforums.com/vb/showthread.php?140691-The-Official-Atwood-collectors-thread/page7
- Containers host resourcesApplication platform as a service (aPaaS) containers Host database connection pools, resource bundles, network transport listeners, mediators, flows, sessionsPlatform as a Service (PaaS) containersHost application servers, database servers, Enterprise Service Bus serversInfrastructure as a service (IaaS) containers Host operating systems or file systems
- Cloud platforms exhibiting Cloud Native PaaS architecture provide an opportunity to increase business innovation and creativity. Cloud native platform solutions shield teams from infrastructure details and inject new behavior into the application.Cloud native PaaS architecture requires infrastructure innovation in provisioning, service governance, management, deployment, load-balancing, policy enforcement, and tenancy. Cloud native, innovative provisioning infrastructure increases tenant density and streamlines code deployment and synchronization. Multi-tenancy within middleware containers enables teams to customize applications and services per consumer by changing run-time configuration settings instead of provisioning new instances.A Cloud platform may automate governance and enforce policies (i.e. security, service level management, usage) through enterprise PaaS services. Cloud provisioning may fulfill enterprise deployment requirements across all service providers and technologies used by solution delivery teams.To re-invent the platform and achieve benefits, new Cloud Native platform architectural components and services are required. Traditional client-server and N-tier web application architectures do not exhibit requisite cloud characteristics (i.e. elastic scalability, multi-tenancy, resource pooling, or self-service). Figure 1 below depicts the new Cloud Platform architectural components and services. The PaaS controller layer deploys, scales, monitors, and manages an elastic middleware Cloud. PaaS Foundation services provide common solution building blocks. A complete, comprehensive, and Cloud-aware middleware container layer delivers new cloud-aware capabilities to business applications.The middleware container layer should not be tightly coupled to the PaaS foundation. Acartridge or droplet pattern is used to support running any application or service container on the PaaS. By providing a cartridge plug-point, Cloud Native PaaS environments can run any language, framework, or server (after appropriate integration via the cartridge API and agents).WSO2 Stratos: Complete middleware middleware PaaS, providing capabilities for application and service hosting, integration, business processes, identity management, storage, and more – all the capabilities of the WSO2 Carbon platform – in a self-service, elastic, multi-tenant platform.Stratos Foundation Services: Core platform services available in the system, including security, registry, messaging, logging, storage, task management, and billing.Stratos Cartridge: A wrapper allowing a runtime product (e.g. WSO2 Carbon middleware) to run “as-a-Service” within the Stratos platform. A cartridge can be architected to support shared-process multi-tenancy, or a single-tenant legacy runtime can be encapsulated for management by the Stratos system.WSO2 Carbon Service Types: Each WSO2 Carbon family product is available as a cartridge that allows it to be exposed as a multi-tenant service, including Enterprise Service Bus, Application Server, Governance Registry, Identity Server, etc.Stratos Controller: Core services supporting self-service, elastic scaling and control of underlying IaaS layer, and automated network, workload, and artifact distribution.Elastic Load BalancerElastic Load Balancer (ELB) balances load across cloud service instances on-premise or in the cloud. The ELB should provide multi-tenancy, fail-over, and auto-scaling of services in line with dynamically changing load characteristics. Cloud Native Elastic Load Balancers are tenant-aware, service-aware, partition-aware, and region-aware. They can direct traffic based on the consuming tenant or target service. Cloud Native Elastic Load Balancers manage traffic across diverse topologies (i.e. private partitions, shared partitions, hybrid cloud), and direct traffic according to performance, cost, and resource pooling policies. A Cloud Native ELB is tightly integrated with the Service Load monitor component and dynamically adjusts to topology changes. Service Load MonitorThe Service Load Monitor component acquires load information from multiple sources (e.g. app servers, load balancers) and communicates utilization and performance information to an Elastic Load Balancer responsible for distributing requests to the optimal instances, based on tenant association, load balancing policies, service level agreements, and partitioning policies. When the level of abstraction is raised above Infrastructure as a Service (IaaS) instances, Teams no longer have direct access to specific virtual machines. New Cloud Native components are required to flexibly distribute applications, services, and APIs across a dynamic topology. A Cloud Controller, Artifact Distribution Server, and Deployment Synchronizer perform DevOp activities (i.e. continuous deployment, instance provisioning, automated scaling) without requiring a hard, static binding to run-time instances.Cloud ControllerA Cloud Native Cloud Controller (or auto-scaler) component creates and removes cloud instances (virtual machines or Linux containers) based on input from the Load Monitor component. The Cloud Controller right-sizes the instance number to satisfy shifting demand, and conforms instance scaling with quota and reservation thresholds (i.e. minimum instance count, maximum instance count). The Cloud Native Cloud Controller may provision instances on top of bare metal machines, hypervisors, or Infrastructure as a Service offerings (e.g. Amazon EC2, OpenStack, Eucalyptus).Artifact Distribution ServerThe Artifact Distribution Server takes complete applications (i.e. application code, services, mediation flows, business rules, and APIs) and breaks the composite bundle into per-instance components, which are then loaded into instances by a Deployment Synchronizer. The Artifact Distribution Server maintains a versioned repository of run-time artifacts and their association with Cloud service definitions.Deployment SynchronizerThe Deployment Synchronizer checks out and deploys the right code for each Cloud application platform instance (e.g. application server, Enterprise Service Bus, API Gateway). With infrastructure and servers abstracted and encapsulated by the Cloud, a Cloud Native PaaS Management Console allows control of tenant partitions, services, quality of service, and code deployment by either Web UI or command-line tooling.Cloud Native PaaS Architecture Business BenefitsCloud Native PaaS architecture accelerates innovation, increases operational efficiency, and reduces cost.The traditional, keep-the-lights-on, operational run-rate consumes precious resources and limits innovative new projects. By optimizing project footprint across pooled resources on a shared Cloud Native PaaS infrastructure, Responsive IT can reduce operational spend, improve total cost of ownership (TCO), and make more projects financially viable. Multi-tenant delivery models create an efficient delivery environment and significant lower solution deployment cost. For more information on the financial benefits of multi-tenant, Cloud Native platforms, read the white paper.By building a Cloud Native PaaS environment, you provide your teams with a platform to rapidly develop solutions that address connected business use cases (i.e. contextual business delivery, ecosystem development, mobile interactions). Recommended ReadingA Path to Responsive ITPaaS ServicesDoes your PaaS architecture show a paradigm shift?Cloud-aware Applications and PaaS Architecture
- eTrade: API, consumers must submit application for code review* compliance focus * *automation* enables long tail *Cloud is a game changing enabler use cases
- Traditional application PaaS (aPaaS) environments do not help organizations build apps, but simply serve as a cloud run-time environment. DevOps PaaS brings no waits, faster phase execution, widespread accessibility, rapid grassroots innovation, and increased resource availability to IT projects.DevOps PaaS delivers development, test, and production run-time clouds that are integrated into development workspaces containing source code management, defect tracking, requirements management, test automation frameworks, and continuous build. Figure 2 describes the infrastructure topology underlying a DevOps PaaS.By automating software activities, workflow, and phase approval gates, a DevOps PaaS decreases software development and delivery times. A rapid IT timeframe closely matching today’s fast business-pace will accelerate revenue growth and enhance customer retention rates. A New IT model driven by DevOps PaaS will expand development team participation, lower IT cost, and increase business agility.Recommended ReadingDevOps Meets ALM in the CloudPaaS Performance MetricsMulti-tenant, shared container PaaS TCOWSO2 App Factory Product Page
- Agile and DevOps principles must be applied across a cross-functional team and the entire lifecycle (e.g. project inception, design, development, deployment, and management).Operations activities related to deployment and release management often hinders agility and time-to-market. The level of effort required to deploy a real-world application is often non-trivial. Continuous deployment technology automates operations activities and replaces manual intervention.While dwell time sounds cozy and refreshing, excessive wait states and downtime between activities diminishes team efficiency and engagement. Automated notifications eliminate dwell time between hand-offs. Automated project workspace creation, Cloud environment provisioning, and on-demand self-service access reduces wait time between software development phases.A DevOps focus on continuous activity execution (e.g. continuous build, continuous integration, continuous test, continuous delivery) creates a ‘no wait’ environment. Teams do not have to wait for the next script to run or for the next activity to commence. By incorporating automation into developer and operations processes, teams bypass time consuming manual tasks and gain faster phase execution. Both DevOps and PaaS promote simple, on-demand self-service environments that shield team members from complexity and reduce skill hurdles. By offering on-demand self-service access, rapid business innovation and experimentation is possible. By reducing complexity, team members are not required to obtain special training and skills before consuming IT services and infrastructure.To read more about Enterprise DevOps PaaS accelerating team agility, read a recent blog post.
- Foundational performance metrics focus on time to market. Key metrics include:Time and effort to create new application environmentTime to redeploy applicationTime to promote application into a new lifecycle phaseOptimization performance metrics focus on portfolio efficiency. Key metrics includeAbility to dynamically right-size infrastructure and elastic scalabilityAbility to re-use existing platform services and business services from resource pool instead of re-building solution stackTransformational performance metrics focus on productivity. Key metrics include: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 measured against the value provided by the application or transaction.