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/
Cloud IT Drivers
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
Cloud Yields
Cloud-‐Oriented Delivery Domains
Cloud Architecture Crossroads
Innovation
Familiarity
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
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
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 interfacesTightly coupled
modules
Monolithic footprint
Single threaded, serial execution
Resource locks Single tenancy model
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
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
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
Source: h,p://edcforums.com/threads/the-‐atwood-‐collectors-‐thread-‐part-‐2.101226/page-‐5
Redesigned Tools
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
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)
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
Cloud ParEEoning Strategies
Consider Enhanced VirtualizaEon Models
WSO2 Stratos 2.0 supports all models and model combina7ons
Stratos Carbon (Shared Process)
Agi
lity
Resource Optimization
Pure Hardware
Virtual Machine
Stratos Cartridge (LXC)
IaaS Machine Instance
Cloud NaEve PaaS Difference
ParEEoning and Container Tenancy Impact
Tenant-‐First = Three Tenants and 5 Containers
ParEEoning and Container Tenancy Impact
Service-‐First = Three Tenants and 3 Containers 40% footprint reducEon
Tenant-‐aware and Service-‐aware Load Balancing
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
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
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
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/
Open Source PaaS Cloud NaEve Architecture
h,p://blog.cobia.net/cobiacomm/2013/04/18/cloud-‐naDve-‐paas-‐architecture/
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
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
Automated Provisioning Service
Automated App Deployment Service
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
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
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
Enterprise DevOps PaaS Bridging Development with Deployment
DevOps Streamlines IteraEons A developer’s perspec;ve
Service Performance Metrics
• FoundaDonal – Time to Market
• OpDmizaDon – Por;olio Efficiency
• TransformaDonal – ProducDvity
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