Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Managed Service Patterns in Pivotal Cloud Foundry

Managed Service Patterns in Pivotal Cloud Foundry

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

Joshua McKenty

May 09, 2016
Tweet

More Decks by Joshua McKenty

Other Decks in Programming

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