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