Downloaded 17 times
Uploaded byChris Haddad
Achieve business agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaS
This document discusses achieving business agility through cloud technologies like APIs, cloud-aware applications, and cloud DevOps platforms. It covers several topics related to cloud computing including cloud drivers, cloud-oriented delivery domains, cloud architecture best practices, cloud application patterns, and shifting to cloud-aware application programming models. It also provides explanations of key concepts in platform as a service (PaaS) architectures like tenants, containers, and partitions for isolating and allocating resources for different users.
More Related Content
Similar to Achieve business agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaS
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 Twi,er h,p://blog.cobia.net/cobiacomm Read more about Pla;orm as a Service at h,p://blog.cobia.net/cobiacomm/tag/paas/
- 2.
- 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 Dme – Dme waiDng for the next operaDon to commence or complete
- 4.
- 5.
- 6. Cloud Architecture Crossroads Innovation Familiarity
- 7. Resource Tier Cloud Scale and Distributed Providers FuncDonal Role Client Tier API aggregaDon and orchestraDon API aggregaDon and orchestraDon Resource Services FuncDonal Role PresentaDon and Mashups FuncDonal Role FuncDonal code PresentaDon Role PresentaDon and Mashups PresentaDon and Mashups Resource Services Private ApplicaDons Public Cloud Services Business Proces Business Process Business Process Business Process and Business Rules
- 8. Cloud Architecture Best PracEces TransiDoning to a New normal – TradiDonal pracDces may not apply • Distributed and federated interacDons – Event based, heterogeneous systems, network latency • Configurable containers and engines – DeclaraDve data, rules, and process definiDons • De-‐normalized and simplified data models – Hadoop/BigTable, Hypertext media, simple NoSQL enDDes • Expect failure – Systems span transacDonal control • ApplicaDons decomposed into disDnct services – Federated environment drives autonomy, statelessness, and composiDon
- 9. Cloud ApplicaEon PaFerns and AnE-‐PaFerns 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 ApplicaEon Goals and Underlying Cloud PaFerns • Maximize uDlizaDon – Requires determinisDc performance – Load balance based on tenant, service, and workload, context • Increase reliability, availability, scalability – Shared nothing architecture – Stateless server-‐side elements – Consensus protocols • Ecosystem pla;orm – MoneDze assets based on business value – Tenant/Consumer personalizaDon and isolaDon – Sharing domain specific business capabiliDes
- 11. Architectural Difference Between Web ApplicaEon and Cloud-‐aware ApplicaEon Web ApplicaEon • Synchronous request-‐reply interacDon • Centralized state (i.e. single database) and session management • Clustered server instances • Silo architecture Cloud-‐aware ApplicaEon • Asynchronous interacDon • Queues and workers • Scale out across datacenters and providers • Distributed state and session management • Autonomous service instances • Tenant context personalizaDon • Shared JVM / Shared Schema • Shared nothing architecture
- 12. ShiK towards Cloud-‐aware ApplicaEon Programming Model • Actor model (i.e. message passing instead of funcDon invocaDon • RESTful interacDons • Dynamic recoverability • Consensus protocols • Asynchronous rather than synchronous interacDons • Shared nothing architecture • Data parDDoning and sharding • Federated data queries • API/Service orchestraDon • FuncDonal programming • MapReduce – and the Thirteen Dwarf pa,erns
- 13.
- 14. PaaS Architecture What is a tenant? • An isolated or personalized run-‐Dme environment context that cannot be shared across PaaS consumers • Tenant specific personalizaDon can occur across mulDple personalizaDon dimensions • InformaDon access privileges • InformaDon aggregaDon and composiDon • Business processes and rules • Service levels and Quality of Service • Security policies, subscriber enDtlements, and social network access privileges • MoneDzaDon rates • PersonalizaDon may require loading code, configuraDon files, or data • Tenant isolaDon dictated by expected performance, security requirements, and legacy technology. • PaaS security managers, code deployers, and tenant-‐aware load balancing influences required container-‐level isolaDon
- 15. PaaS Architecture What is a container? • A standalone, Internet addressable node offering applicaDon pla;orm services • Web applicaDon hosDng, API management, integraDon endpoint hosDng, ESB mediaDon, registry services, idenDty management, relaDonal database • Containers host tenant resources and context • Code, configuraDon files, data, process definiDons, rules, policies, enDtlements • Containers may serve • a single tenant at a Dme (dedicated), or • mulDple-‐tenants at a Dme (shared)
- 16. PaaS Architecture What is a parEEon? • ParDDons define disDnct container resource pools • ParDDon containers to tune container sharing, service resource allocaDon, QoS, and uDlizaDon • Containers may be assigned into service-‐specific or tenant specific parDDons
- 17.
- 18. Consider Enhanced VirtualizaEon Models WSO2 Stratos 2.0 supports all models and model combina7ons Stratos Carbon (Shared Process) Agility Resource Optimization Pure Hardware Virtual Machine Stratos Cartridge (LXC) IaaS Machine Instance
- 19. Cloud NaEve PaaS Difference
- 20. ParEEoning and Container Tenancy Impact Tenant-‐First = Three Tenants and 5 Containers
- 21. ParEEoning and Container Tenancy Impact Service-‐First = Three Tenants and 3 Containers 40% footprint reducEon
- 22. Tenant-‐aware and Service-‐aware Load Balancing
- 23. Total Cost of Ownership Levers • Rapid elasDcity • Provides ability to turn-‐on addiDonal containers only when demand requires more capacity • Provides ability to turn-‐off under uDlized containers and lower expense • Measured Service and Pay Per Use • No foundaDonal infrastructure investment required • Possibly a minimal up-‐front registraDon investment • Only charged for usage (e.g. pla;orm up-‐Dme, deployed applicaDon count, transacDon count) • Resource Pooling • Minimize usage cost by sharing and re-‐using resources • On-‐demand self-‐service • Create and provision pla;orm without third party parDcipaDon
- 24. Total Cost of Ownership Advantage • Rapid elasDcity • Containers shared across mulDple tenants • Capacity managed per service, not per tenant • Single, flat container parDDon space enables maximum sharing • Containers may be parDDoned by service • Resource Pooling • ApplicaDon 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 aeer 4 tenants subscribe (at full-‐Dme usage per tenant) • Can meter and bill based on business transacDon usage, applicaDon count • On-‐demand self-‐service • ApplicaDon teams do not have to specify infrastructure topology (i.e. server count) • Subscribe to applicaDon pla;orm services instead of applicaDon server instances
- 26. AFributes influencing Total Cost of Ownership • Container sharing and tenant isolaDon level • Tenant Density per JVM or ApplicaDon Server • Container license cost • Read enDre methodology at • h,p://blog.cobia.net/cobiacomm/2012/05/13/ paas-‐tco-‐and-‐paas-‐roi-‐mulD-‐tenant-‐shared-‐ container-‐paas/
- 27. Open Source PaaS Cloud NaEve Architecture h,p://blog.cobia.net/cobiacomm/2013/04/18/cloud-‐naDve-‐paas-‐architecture/
- 28. WSO2 Architecture Advantage Availability Scalability Management Load monitor Tenant parDDoning Private jet mode Cloud controller Balancing and failover across hybrid clouds Ghost deployment BigData Logging infrastructure State replicaDon and session replicaDon BAM 2.0 architecture ArDfact DistribuDon Controller and Deployment synchronizaDon MulDple load balancers with keepalived or DNS RR Auto-‐scaling P2 Repository NaDve mulD-‐tenancy ElasDc Load Balancer Consistent management and infrastructure services across enDre pla;orm Dynamic Clustering MulD-‐tenant shared container Management console 28
- 29. Close the Loop between Cloud-‐apps, Cloud PaaS, and Cloud Infrastructure • Specify Scale Parameters – Tenancy and sessions – ParDDoning and sharing • Monitor Quality of Service – Service Der – Performance and uDlizaDon – Expected load per API call or web request • Trigger Provisioning and Deployment Events – Automated Provisioning – Automated Deployment
- 30.
- 31. Automated App Deployment Service
- 32. Fast Time to Value with On-‐demand Contextual PersonalizaEon Increase agility • Rapidly adapt and fulfill new market demand • Reduce Dme to introduce new services, applicaDons, and products into long tail market(s) On-‐demand Contextual PersonalizaDon • InformaDon access and social network access privileges • InformaDon aggregaDon and composiDon • Business processes and rules • Service levels, Quality of Service, and moneDzaDon rates • Security policies
- 33. Cloud Business Value For Development Teams 33 Lower development barriers • Provide on-‐demand ApplicaDon Development project infrastructure and run-‐Dme environments • Catalogue of re-‐usable open APIs, cloud services, and domain frameworks Lower adopDon barriers • On-‐demand web applicaDon and Cloud API subscripDons via a self-‐service provisioning portal • Establish searchable registry of app, service, api, and data descriptors • Reliable, available, and scalable soluDons
- 34. Best PracEce AdopEon and Process Repeatability • Cost-‐effecDve, development, collaboraDon, and deployment infrastructure enabling a long tail of applicaDon development • Architecture templates and applicaDon pla;orm services • A shared environment for cross-‐organizaDon applicaDon development and delivery • Governed, iteraDve lifecycle management across hybrid clouds and composite applicaDons • IT Business performance metrics and analyDcs • Infrastructure enabling user experience composiDon across mulDple disparate applicaDon providers
- 35. Enterprise DevOps PaaS Bridging Development with Deployment
- 36. DevOps Streamlines IteraEons A developer’s perspec;ve
- 37. Service Performance Metrics • FoundaDonal – Time to Market • OpDmizaDon – Por;olio Efficiency • TransformaDonal – ProducDvity
- 38. 7 +/-‐ 2 Cloud Roadmap ObjecEves 1. Engage stakeholders in a collaboraDve development workspace 2. Promote best pracDce workflow, architecture, and governance pracDces 3. Deploy applicaDons into a Cloud run-‐ Dme environment 4. On-‐demand applicaDon subscripDons via a self-‐service provisioning portal 5. Share applicaDons across mulDple tenants (e.g. departments, workgroups, employees, partners) 6. Scale run-‐Dme to meet usage 7. Deploy Open APIs 8. Encourage API adopDon via API Store 9. Track business acDvity and analyze Cloud service usage, performance, and cost 38