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