Achieve	  business	  agility	  with	  	  Cloud	  APIs,	  Cloud-­‐aware	  Apps,	  and	  	  Cloud	  DevOps	  PaaS	  Chris	  ...
Cloud	  IT	  Drivers	  
Cloud	  Delivers	  The	  Speed	  of	  Now	  •  Time	  to	  create	  project	  workspace	  •  Time	  to	  build,	  integrat...
Cloud	  Yields	  
Cloud-­‐Oriented	  Delivery	  Domains	  
Cloud	  Architecture	  Crossroads	  InnovationFamiliarity
Resource	  Tier	  Cloud	  Scale	  and	  Distributed	  Providers	  	  FuncDonal	  Role	  Client	  Tier	  API	  aggregaDon	 ...
Cloud	  Architecture	  Best	  PracEces	  TransiDoning	  to	  a	  New	  normal	  –	  TradiDonal	  pracDces	  may	  not	  ap...
Cloud	  ApplicaEon	  PaFerns	  	  and	  AnE-­‐PaFerns	  18DeterministicperformanceDeploy and execute on optimum topologySe...
Cloud	  Aware	  ApplicaEon	  Goals	  and	  Underlying	  Cloud	  PaFerns	  •  Maximize	  uDlizaDon	  –  Requires	  determin...
Architectural	  Difference	  Between	  Web	  ApplicaEon	  and	  Cloud-­‐aware	  ApplicaEon	  Web	  ApplicaEon	  •  Synchron...
ShiK	  towards	  Cloud-­‐aware	  ApplicaEon	  Programming	  Model	  • Actor	  model	  (i.e.	  message	  passing	  instead	...
Source:	  h,p://­‐atwood-­‐collectors-­‐thread-­‐part-­‐2.101226/page-­‐5	  Redesigned	  Tools	  
PaaS	  Architecture	  What	  is	  a	  tenant?	  •  An	  isolated	  or	  personalized	  run-­‐Dme	  environment	  context	 ...
PaaS	  Architecture	  What	  is	  a	  container?	  •  A	  standalone,	  Internet	  addressable	  node	  offering	  applicaD...
PaaS	  Architecture	  What	  is	  a	  parEEon?	  •  ParDDons	  define	  disDnct	  container	  resource	  pools	  •  ParDDon...
Cloud	  ParEEoning	  Strategies	  
Consider	  Enhanced	  VirtualizaEon	  Models	  WSO2	  Stratos	  2.0	  	  supports	  all	  models	  and	  model	  combina7o...
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%	  foo...
Tenant-­‐aware	  and	  Service-­‐aware	  Load	  Balancing	  
Total	  Cost	  of	  Ownership	  Levers	  •  Rapid	  elasDcity	  •  Provides	  ability	  to	  turn-­‐on	  addiDonal	  conta...
Total	  Cost	  of	  Ownership	  Advantage	  •  Rapid	  elasDcity	  •  Containers	  shared	  across	  mulDple	  tenants	  •...
Total	  Cost	  of	  Ownership	  Advantage	  •  Measured	  Service	  and	  Pay	  Per	  Use	  •  Cloud	  infrastructure	  in...
AFributes	  influencing	  	  Total	  Cost	  of	  Ownership	  •  Container	  sharing	  and	  tenant	  isolaDon	  level	  •  ...
Open	  Source	  PaaS	  Cloud	  NaEve	  Architecture	  h,p://­‐naDve-­‐paas-­‐arc...
WSO2	  Architecture	  Advantage	  Availability	   Scalability	   Management	  Load	  monitor	  	  Tenant	  parDDoning	  Pr...
Close	  the	  Loop	  between	  Cloud-­‐apps,	  Cloud	  PaaS,	  and	  Cloud	  Infrastructure	  •  Specify	  Scale	  Paramet...
Automated	  Provisioning	  Service	  
Automated	  App	  Deployment	  Service	  
Fast	  Time	  to	  Value	  with	  	  On-­‐demand	  Contextual	  PersonalizaEon	  Increase	  agility	  •  Rapidly	  adapt	 ...
Cloud	  Business	  Value	  For	  Development	  Teams	  33	  Lower	  development	  barriers	  	  •  Provide	  on-­‐demand	 ...
Best	  PracEce	  AdopEon	  and	  	  Process	  Repeatability	  •  Cost-­‐effecDve,	  development,	  collaboraDon,	  and	  de...
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	  •  Trans...
7	  +/-­‐	  2	  Cloud	  Roadmap	  ObjecEves	  1.  Engage	  stakeholders	  in	  a	  collaboraDve	  development	  workspace	...
Upcoming SlideShare
Loading in …5

Achieve business agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaS


Published on

o 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.

Published in: Technology
  • Be the first to comment

Achieve business agility with Cloud APIs, Cloud-aware Apps, and Cloud DevOps PaaS

  1. 1. Achieve  business  agility  with    Cloud  APIs,  Cloud-­‐aware  Apps,  and    Cloud  DevOps  PaaS  Chris  Haddad  @cobiacomm  on  Twi,er  h,p://      Read  more  about  Pla;orm  as  a  Service  at    h,p://          
  2. 2. Cloud  IT  Drivers  
  3. 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. 4. Cloud  Yields  
  5. 5. Cloud-­‐Oriented  Delivery  Domains  
  6. 6. Cloud  Architecture  Crossroads  InnovationFamiliarity
  7. 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. 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. 9. Cloud  ApplicaEon  PaFerns    and  AnE-­‐PaFerns  18DeterministicperformanceDeploy and execute on optimum topologySeparation of concernsEmbarrassingly Parallel /Shared Nothing ArchitectureMinimalConsumptionFailure Resilient Leaky interfacesTightly coupledmodulesMonolithic footprintSingle threaded,serial executionResource locks Single tenancy model
  10. 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. 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. 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. 13. Source:  h,p://­‐atwood-­‐collectors-­‐thread-­‐part-­‐2.101226/page-­‐5  Redesigned  Tools  
  14. 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. 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. 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. 17. Cloud  ParEEoning  Strategies  
  18. 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. 19. Cloud  NaEve  PaaS  Difference  
  20. 20. ParEEoning  and  Container  Tenancy  Impact  Tenant-­‐First  =  Three  Tenants  and  5  Containers  
  21. 21. ParEEoning  and  Container  Tenancy  Impact  Service-­‐First  =  Three  Tenants  and  3  Containers  40%  footprint  reducEon  
  22. 22. Tenant-­‐aware  and  Service-­‐aware  Load  Balancing  
  23. 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. 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. 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. 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://­‐tco-­‐and-­‐paas-­‐roi-­‐mulD-­‐tenant-­‐shared-­‐container-­‐paas/  
  27. 27. Open  Source  PaaS  Cloud  NaEve  Architecture  h,p://­‐naDve-­‐paas-­‐architecture/  
  28. 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. 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. 30. Automated  Provisioning  Service  
  31. 31. Automated  App  Deployment  Service  
  32. 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. 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. 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. 35. Enterprise  DevOps  PaaS  Bridging  Development  with  Deployment  
  36. 36. DevOps  Streamlines  IteraEons  A  developer’s  perspec;ve  
  37. 37. Service  Performance  Metrics  •  FoundaDonal  – Time  to  Market  •  OpDmizaDon  – Por;olio  Efficiency  •  TransformaDonal  – ProducDvity  
  38. 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