Orchestrating VM &
Container Deployments
Google's Motivations
● Tooling has always been a priority at Google
● 2B lines of code
● 50% of code changes monthly
● 30k submits / day
● 6000 builds / hour
● 9000 releases / day
Google's Motivations
● Netflix and Spinnaker’s core tenets align with Google’s
● Take advantage of massive elastic infrastructure
● Immutable infrastructure
● Continuous delivery
● Self-service tools
Google's Motivations
● Our internal platform and tooling is container oriented
● Develop out the Google Cloud Platform toolset for VMs, containers and PaaS
● Spinnaker is a great starting point for VM oriented tooling
● Contribute to OSS that aligns with our culture and goals
● Kubernetes, Bazel
● Working towards an open cloud - choices, transition, flexibility
● Long term commitment to the Spinnaker project
● Dedicated engineering team
● Several internal (and external!) teams are using Spinnaker
Google's (OSS) Motivations
Quick Spinnaker Project History
● Started by Netflix in 2014
○ An evolution of earlier Netflix projects (incl. Asgard)
● Google involved since early on
● Many additional companies and individuals are involved now
○ Target, Veritas, Microsoft, Schibsted, Pivotal, Kenzan, Armory, ...
● Support for many cloud platforms, and growing
● Open sourced in November 2015
Terminology & Cluster Management
Spinnaker promotes model of:
Build candidate → Test in running system → Push to production
Similar process used internally at Google
Bake Deploy Disable or
Destroy
Trigger
OSPKG (.deb)
Webhook
Build/TestPush
Commit
Your favorite CI system
Deployment Strategy
New Auto
Scaling Group
Old Auto
Scaling Group
AWS/EC2
images
Old Managed
Instance
Group
New Managed
Instance
Group
images
Deployment Strategy
GCE
Bake & Deploy VM Demo
Bake Deploy Disable or
Destroy
Trigger
Old Managed
Instance
Group
New Managed
Instance
Group
images
Deployment Strategy
GCE
Deployment Strategy
New Replica
Set
Old Replica
Setdocker
images
OSPKG (.deb)
Webhook
Build/TestPush
Commit
Kubernetes
Trigger
Same operations for containers!
Docker
Registry
Kubernetes Deployments API
Great for limiting resource utilization.
Ensures deployments are rolled out slowly.
Puts little pressure on downstream dependencies.
Kubernetes Deployments API
Can’t be paused deterministically for validation.
High rollback cost.
Rollouts are always linear.
Rolling Red Black
Rollout user-defined target percentages. (1% → 2% → 10% → 50% → 100%)
Validation at every stage.
Puts little pressure on downstream dependencies.
Fast rollbacks.
Rolling Red Black
Overprovisioning comes at the cost of rollback speed.
(Fake) Rolling Red Black Demo
Target Percentages = 1% → 2% → 10% → 50% → 100%
Over Provisioning = 10%
Rolling Red Black
Old Server Group New Server Group
Enabled: 100
Running: 100
Enabled: 0
Running: 0
Rolling Red Black
Old Server Group New Server Group
Enabled: 99
Running: 100
Enabled: 1
Running: 1
Rolling Red Black
Old Server Group New Server Group
Enabled: 98
Running: 100
Enabled: 2
Running: 2
Rolling Red Black
Old Server Group New Server Group
Enabled: 90
Running: 100
Enabled: 10
Running: 10
Rolling Red Black
Old Server Group New Server Group
Enabled: 50
Running: 60
Enabled: 50
Running: 50
Rolling Red Black
Old Server Group New Server Group
Enabled: 0
Running: 10
Enabled: 100
Running: 100
Future Spinnaker Plans
● Native canary support
● Template language for Pipelines
● Easier configuration using Halyard
○ Support for target platforms contributed by multiple companies
● “1.0” release in April
Key Takeaways
● Google is committed to the Spinnaker project
● There’s more to Continuous Delivery than updating a server group
● Spinnaker makes it easy for developers to confidently rollout to production
● Spinnaker provides orchestration not possible with your cloud alone
Thank you
● Provision Spinnaker with Helm:
https://github.com/kubernetes/charts/tree/master/stable/spinnaker
● Questions?
spinnaker.io

Orchestrating VM & Container Deployments

  • 1.
  • 2.
    Google's Motivations ● Toolinghas always been a priority at Google ● 2B lines of code ● 50% of code changes monthly ● 30k submits / day ● 6000 builds / hour ● 9000 releases / day
  • 3.
    Google's Motivations ● Netflixand Spinnaker’s core tenets align with Google’s ● Take advantage of massive elastic infrastructure ● Immutable infrastructure ● Continuous delivery ● Self-service tools
  • 4.
    Google's Motivations ● Ourinternal platform and tooling is container oriented ● Develop out the Google Cloud Platform toolset for VMs, containers and PaaS ● Spinnaker is a great starting point for VM oriented tooling
  • 5.
    ● Contribute toOSS that aligns with our culture and goals ● Kubernetes, Bazel ● Working towards an open cloud - choices, transition, flexibility ● Long term commitment to the Spinnaker project ● Dedicated engineering team ● Several internal (and external!) teams are using Spinnaker Google's (OSS) Motivations
  • 6.
    Quick Spinnaker ProjectHistory ● Started by Netflix in 2014 ○ An evolution of earlier Netflix projects (incl. Asgard) ● Google involved since early on ● Many additional companies and individuals are involved now ○ Target, Veritas, Microsoft, Schibsted, Pivotal, Kenzan, Armory, ... ● Support for many cloud platforms, and growing ● Open sourced in November 2015
  • 7.
  • 8.
    Spinnaker promotes modelof: Build candidate → Test in running system → Push to production Similar process used internally at Google Bake Deploy Disable or Destroy Trigger OSPKG (.deb) Webhook Build/TestPush Commit Your favorite CI system Deployment Strategy New Auto Scaling Group Old Auto Scaling Group AWS/EC2 images Old Managed Instance Group New Managed Instance Group images Deployment Strategy GCE
  • 9.
  • 10.
    Bake Deploy Disableor Destroy Trigger Old Managed Instance Group New Managed Instance Group images Deployment Strategy GCE Deployment Strategy New Replica Set Old Replica Setdocker images OSPKG (.deb) Webhook Build/TestPush Commit Kubernetes Trigger Same operations for containers! Docker Registry
  • 11.
    Kubernetes Deployments API Greatfor limiting resource utilization. Ensures deployments are rolled out slowly. Puts little pressure on downstream dependencies.
  • 12.
    Kubernetes Deployments API Can’tbe paused deterministically for validation. High rollback cost. Rollouts are always linear.
  • 13.
    Rolling Red Black Rolloutuser-defined target percentages. (1% → 2% → 10% → 50% → 100%) Validation at every stage. Puts little pressure on downstream dependencies. Fast rollbacks.
  • 14.
    Rolling Red Black Overprovisioningcomes at the cost of rollback speed.
  • 15.
    (Fake) Rolling RedBlack Demo Target Percentages = 1% → 2% → 10% → 50% → 100% Over Provisioning = 10%
  • 16.
    Rolling Red Black OldServer Group New Server Group Enabled: 100 Running: 100 Enabled: 0 Running: 0
  • 17.
    Rolling Red Black OldServer Group New Server Group Enabled: 99 Running: 100 Enabled: 1 Running: 1
  • 18.
    Rolling Red Black OldServer Group New Server Group Enabled: 98 Running: 100 Enabled: 2 Running: 2
  • 19.
    Rolling Red Black OldServer Group New Server Group Enabled: 90 Running: 100 Enabled: 10 Running: 10
  • 20.
    Rolling Red Black OldServer Group New Server Group Enabled: 50 Running: 60 Enabled: 50 Running: 50
  • 21.
    Rolling Red Black OldServer Group New Server Group Enabled: 0 Running: 10 Enabled: 100 Running: 100
  • 22.
    Future Spinnaker Plans ●Native canary support ● Template language for Pipelines ● Easier configuration using Halyard ○ Support for target platforms contributed by multiple companies ● “1.0” release in April
  • 23.
    Key Takeaways ● Googleis committed to the Spinnaker project ● There’s more to Continuous Delivery than updating a server group ● Spinnaker makes it easy for developers to confidently rollout to production ● Spinnaker provides orchestration not possible with your cloud alone
  • 24.
    Thank you ● ProvisionSpinnaker with Helm: https://github.com/kubernetes/charts/tree/master/stable/spinnaker ● Questions? spinnaker.io