Managed Service Patterns in Pivotal Cloud Foundry

A draft lexicon to talk about different ways to manage stateful services in a BOSH-orchestrated environment.

Transcript

1. Pa#erns  of  Pla,orm  Services  
   An  Architecture  Overview  
   Global  Ecosystem  Team,  Pivotal  
   

   View Slide

2. What  do  we  care  about?  
   •  Scale:  App  count  (total  number  using  service)  
   •  Scale:  App  size  (amount  of  service  consumed  by  a  
   single  app)  
   •  IsolaHon  between  tenants  (noisy  neighbor,  side-­‐
   channel  a#acks)  
   •  Fault  tolerance  (for  VM  and  process  failure)  
   •  Ease  of  development  
   

   View Slide

3. VM  
   Process   Process  
   Type  A1:  Process  MT  
   Single  Service  Instance  
   Single  VM  
   MulHtenant  via  processes  
   VM  
   Process   Process  
   App  1   App  N  
   …  
   uuid:pass@genericIP:uniquePort  
   PROS:  
   Fast  to  build  
   Doesn’t  require  MT  service  
    
   CONS:  
   Very  limited  scale  on  app  
   size  and  app  count  
   Limited  MT  isolaHon  
   No  fault  tolerance  or  HA  
   VM  
   VM  
   Type  A2:  Clustered  Process  MT  
   Single  Service  Instance  
   MulHple  VMs  (staHc  quanHty)  
   MulHtenant  via  processes  
   Process  
   App  1   App  N  
   …  
   uuid:pass@uniqueIP:uniquePort  
   PROS:  
   Fast  to  build  
   Doesn’t  require  MT  service  
    
   CONS:  
   Manual  scaling    
   Limited  scale  on  app  size  
   Limited  MT  isolaHon  
   No  fault  tolerance  or  HA  
   Process-­‐level  
   MulH-­‐Tenancy  
   Process  
   Subway  Proxy  
   

   View Slide

4. Type  B1:  Service  MT  
   Single  Service  Instance  
   Single  VM  
   MulHtenant  in  the  service  
   VM  
   Service  
   App  1   App  N  
   …  
   uuid:pass@genericIP:genericPort  
   PROS:  
   Very  Fast  to  build  
    
    
   CONS:  
   Very  limited  scale  on  app  
   size  and  app  count  
   Limited  MT  isolaHon  
   Requires  MT  Service  
   No  fault  tolerance  or  HA  
   VM  
   VM   VM  
   Type  B3:  Distributed  Service  MT  
   Single  Service  Cluster  
   MulHple  VM  Cluster  
   MulHtenant  in  the  service  
   VM  
   Distributed  Service    
   App  1   App  N  
   …  
   uuid:pass@genericIP:genericPort  
   PROS:  
   Fault  tolerant  and  HA  
    
   CONS:  
   Manual  scaling  
   Limited  MT  isolaHon  
   Requires  MT  Service  
   Requires  Clustered  Service  
   Service  LB  Proxy  
   Service-­‐level  
   MulH-­‐Tenancy  
   VM  
   VM  
   VM  
   Type  B2:  Clustered  Service  MT  
   Single  Service  Cluster  
   MulHple  VMs,  not  clustered  
   MulHtenant  in  the  service  AND  VMs  
   Service   Service  
   App  1   App  N  
   …  
   uuid:pass@uniqueIP:uniquePort  
   PROS:  
   Balance  of  scale  and  operability  
   Does  not  require  clustered  service  
    
   CONS:  
   Manual  scaling    
   Limited  scale  on  app  size  
   Limited  MT  isolaHon  
   Requires  MT  Service  
   No  fault  tolerance  or  HA  
   Subway  Proxy  
   (note:  not  all  distributed  
   services  require  a  load-­‐
   balancing  proxy;  some  
   provide  a  list  of  
   endpoints  to  each  
   applica?on.)  
   

   View Slide

5. VM  
   VM   VM  
   VM  
   Distributed  Service    
   Service  LB  Proxy  
   VM  
   VM   VM  
   VM  
   Distributed  Service    
   Service  LB  Proxy  
   Dynamic  clusters  
   w/  VM-­‐level    
   MulH-­‐Tenancy  
   Type  C2:  Dynamic  Clustered  Service  
   MulHple  Service  Instances  
   MulHple  VM  cluster  per  instance  
   Single  tenant  per  VM  cluster  
   App  1   App  N  
   …  
   uuid:pass@uniqueIP:genericPort  
   PROS:  
   HA  and  Fault-­‐Tolerant  
   Strong  MT  isolaHon  
   Scales  for  both  app  count  and  size  
    
   CONS:  
   Requires  Clustered  Service  
   Type  C1:  Dynamic  Service    
   MulHple  Service  Instances  
   Single  VM  per  instance  
   Single  tenant  per  VM  
   VM  
   Service  
   App  1   …  
   uuid:pass@uniqueIP:genericPort  
   PROS:  
   Scales  to  large  app  count  
   Strong  MT  isolaHon  
   Does  not  require  clustered  service  
    
   CONS:  
   Limited  on  app  size  
   No  fault  tolerance  or  HA  
    
    
   VM  
   Service  
   App  N  
   

   View Slide

6. CAVEATS(!)  
   •  We  have  le^  pool-­‐allocated  pa#erns  out  on  
   purpose  (as  they  have  no  advantages  to  
   dynamic  allocaHon  and  significant  drawbacks)  
   A  single  service  broker  can  offer  plans  from  
   several  architectures  
   

   View Slide