orchestrating vm & container deployments

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 orDestroy

Trigger

OSPKG (.deb)

WebhookBuild/TestPush

Commit

Your favorite CI system

Deployment Strategy

New AutoScaling Group

Old AutoScaling Group

AWS/EC2images

Old ManagedInstance Group

New ManagedInstance Group

images

Deployment Strategy

GCE

Bake & Deploy VM Demo

Bake Deploy Disable orDestroy

Trigger

Old ManagedInstance Group

New ManagedInstance Group

images

Deployment Strategy

GCE

Deployment Strategy

New Replica Set

Old Replica Setdocker

images

OSPKG (.deb)

WebhookBuild/TestPush

Commit

Kubernetes

Trigger

Same operations for containers!

DockerRegistry

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 BlackOld Server Group New Server Group

Enabled: 100Running: 100

Enabled: 0Running: 0

Rolling Red BlackOld Server Group New Server Group

Enabled: 99Running: 100

Enabled: 1Running: 1

Rolling Red BlackOld Server Group New Server Group

Enabled: 98Running: 100

Enabled: 2Running: 2

Rolling Red BlackOld Server Group New Server Group

Enabled: 90Running: 100

Enabled: 10Running: 10

Rolling Red BlackOld Server Group New Server Group

Enabled: 50Running: 60

Enabled: 50Running: 50

Rolling Red BlackOld Server Group New Server Group

Enabled: 0Running: 10

Enabled: 100Running: 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