Slides from the presentation "Open CD for Open Infrastructure - Hybrid and Multi-Cloud Deployments with Spinnaker" at OpenDev 2018, by Andrew Phillips. See https://www.youtube.com/watch?v=EC_zxrk2NQc

2. Andrew Phillips
Community member
Spinnaker

3. ● Been on most sides of this space: developer,
infra builder, product owner, evangelist and
more
● Long-standing open-source contributor
● Author and regular conference and meetup
presenter
● Co-organizer of ContainerDays Boston & NYC
The bio slide

4. Breaking down app deployment & Continuous Delivery
The deployment complexity scale & tooling implications
Spinnaker as a dedicated tool for app rollouts, application
management and domain-specific “secret sauce”
Agenda
Demo
Q&A

5. Beyond a certain level of deployment complexity it makes sense to
consider a dedicated deployment automation tool
A good deployment automation tool supports deployment and
operational best practice for rollouts and application management
Spinnaker embodies a lot of these best practices and includes
additional domain-specific “smarts” with proven value
3 takeaways

6. Breaking down CD

7. Breaking down CD
Common thought pattern: CI = glue, CD = more glue (or some combination
of “balls of mud” and “blobs of glue”

8. Breaking down CD
+

9. Breaking down CD
Not very useful as it really only talks about implementation details and less
about types of value delivered
Makes it hard to decide which kind of tooling is needed and how to choose it

10. Value
Instead, let’s look at it from a different perspective, motivated by the fact
that deployment sits at that critical boundary between build & manage (a.k.a.
dev and Ops)

11. Value = AR + AM + DS
Three components of value:
• Application rollout
• Application management
• Domain smarts

12. AR = application rollout
= the part of CD that generally comes to mind
Process of moving a release candidate through a number of verification
phases to production
Can be triggered once per code commit (“combined CI/CD”) but also (esp.
in more complex situations) independently of code changes (“decoupled
CI/CD”, e.g. release trains)

13. AR = application rollout
A sequence of commands, so often initially implemented with a
general-purpose orchestrator/automation tool
Ranges from simple one-shot git push <runtime> to long-running,
multi-step processes
More complex sequences already run into challenges specific to the domain:
access control, complex step sequences, concern about current state, need
for recoverability etc.
Some essential complexity across teams, but often incidental divergence

14. AM = application management
= often considered more of an operational issue
Fundamental question: “Which versions of which applications are/were
running in which environment?”
Generally not well supported either by GPOs (no representation of runtime
state) or monitoring tools (insufficient application/service model)
Becomes a significantly harder problem across different target runtimes
E.g. how to represent a set of VMs and a set of serverless functions in a
consistent way?

15. AM = application management
Not just about understanding the current state of the application landscape
and its evolution, but also about performing maintenance, troubleshooting
etc. actions
E.g. diverting load/traffic, scaling up or down, taking part of an application
offline, rolling back part of an application etc.
Want to do so safely - happens in high-pressure situations where the risk of
making a follow-on mistake is increased (limited review of changes etc.)

16. DS = domain smarts
Generally not well (or not at all) served by general-purpose orchestrators
Ex. updating an auto-scaling group or watching a Kubernetes deployment
Retrieving artifact information from triggers or context
Tasks for de-/reactivating current or previous application version, scaling
them up or down, directing traffic to/away from them etc.

17. DS = domain smarts
Support for various models of best practice sharing (locked-down and/or
use-as-template)
Traffic guards, judgements and requests for input, execution windows,
flexible failure-handling modes
Consistent domain model across runtime platforms
Traffic management, canary analysis etc. etc.
...

18. The deployment complexity scale

19. We all start with the GPO
Application deployment is not a “one size fits all” tooling problem
Almost every team that runs some kind of automated tasks on code commit
(e.g. a CI build) has a general-purpose orchestrator already
Natural choice to also start using this for application deployment

20. The GPO gets painful
At some point, using a GPO becomes pretty painful

21. The GPORGD gets painful

22. The GPO gets painful
At some point (“the Rube Goldberg stage”), using a GPO becomes pretty
painful
Still, investing time into addressing this is always tricky
Natural reluctance to adopt additional tools
“Something we want to fix next time”

23. Deployment complexity
When is “enough” enough?
Deployment complexity as a useful guide

24. Deployment complexity
When is “enough” enough?
Deployment complexity as a useful guide
DC = MR / pi * e ^ -i * RP

25. Deployment complexity
Just joking ;-)
Not rigorous science; just a rough guide to evaluating your scenario

26. Deployment complexity
Common dimensions:
• # teams
• # runtime platforms
• # process executions (esp. if scalability starts to bite)
• Complexity of rollouts (many components, many stages)
• Separation of concerns
• Regulatory/compliance/audit requirements
• Safe overview and management
• ...

27. How to use this?
Ask yourself these questions
If you recognize pain in more than two or three dimensions, consider taking
a look at a deployment tool
Timebox the effort and create your own evaluation criteria based on your
pain points
No analyst-provided spreadsheets! No check-box exercises! No endless
bake-offs!

28. How to use this?
No free lunch - will take effort, time, require training etc.
But lots of free snacks - many features you will find useful even if you initially
didn’t see much need for them
Don’t underestimate the draw of contributing to a funky open-source
project!

29. Spinnaker

30. What is Spinnaker?
Open-source project led by Netflix, Google and other CI/CD thought leaders
Aims to embody deployment and operational good practice and incorporate
domain-specific “smarts” across many teams and runtime platforms
“We built Spinnaker because the other CD tools on the market don’t scale to
Netflix’s needs.”
“Spinnaker is the dream: [...] an abstraction layer. Something that’s
long-term sustainable.”

34. What is Spinnaker?
Scales far beyond most other tools in this space
...but also non-trivial to configure and operate (area of ongoing work)
“Provider model” to support different target runtimes in a consistent way
...working on improving the single-runtime experience
Also lots of integration capabilities with upstream and downstream tools and
information sources, e.g. source repositories, build tools, monitoring
systems etc.

35. Demo time!

36. Demo
Let’s deploy some code!
Rollout process
Application management
Domain smarts

37. Demo
Let’s deploy some code!
Rollout process
Application management
Domain smarts
Let’s go
already!

38. Rollout process

42. Application management

49. Domain smarts

57. Site: spinnaker.io
Install: spinnaker.io/setup/
Kubernetes codelab:
codelabs.developers.google.com/codelabs/cloud-spinnaker-kubernetes-cd/
Forum: community.spinnaker.io
Slack: join.spinnaker.io
Source: github.com/spinnaker/spinnaker
Kayenta: github.com/spinnaker/kayenta
Some links

58. Beyond a certain level of deployment complexity it makes sense to
consider a dedicated deployment automation tool
A good deployment automation tool supports deployment and
operational best practice for rollouts and application management
Spinnaker embodies a lot of these best practices and includes
additional domain-specific “smarts” with proven value
3 takeaways

59. Thank you!

60. Site: spinnaker.io
Install: spinnaker.io/setup/
Kubernetes codelab:
codelabs.developers.google.com/codelabs/cloud-spinnaker-kubernetes-cd/
Forum: community.spinnaker.io
Slack: join.spinnaker.io
Source: github.com/spinnaker/spinnaker
Kayenta: github.com/spinnaker/kayenta
Questions?