Do you want to make your releases safer, faster, and less effort? Lots of us now have microservices, kubernetes, maybe even a service mesh. So why are released still banned on fridays? Why is it so hard even know what version is running in production?

1. Cloud-Native
Progressive Delivery
Matt Turner
GOTO, Copenhagen Denmark | November 2021 @mt165 | mt165.co.uk

7. How Does Cloud-Native Enable This?

9. 12 Factor Apps

10. 12 Factor Apps
III. External Config
I. Code in git

12. Docker

13. Docker
II. Isolate Dependencies

14. Docker
II. Isolate Dependencies
V. Strictly separate build
and run

15. Microservices
Gateway
Adaptor
Adaptor
Adaptor
Backend
Backend
Backend

16. Microservices
Gateway
Adaptor
Adaptor
Adaptor

17. Kubernetes

18. Service Mesh

19. Metrics

20. Metrics
“RED”
● Rate - requests / second
● Errors - errors (%)
● Duration - latency of responses

21. Service Levels
● SLA - Service Level Agreement - broad statement of what’s on offer, reads
like a contract
● SLO - Service Level Objective - measurable, quantified target for availability,
performance, etc. Eg error rate %, latency ms.
● SLI - Service Level Indicator - how will we measure the service level? How
are we measuring things? Where? How are we aggregating them?

22. Infrastructure-as-Code & Declarative Systems
● Everything is described as “code” (needs an API)
● Eg Terraform, Kubernetes YAMLs
● No more click-ops!

23. GitOps
● Git as the single source of truth for everything
● Uses IaC to describe the desired state
● Committed to git
● Reconciled to the world
● Enables Operations via git (rather that by ticket)

24. Deployments Now

25. Continuous Integration
● These days actually means Continuous Build
● Original meaning still relevant and coming later

26. Deployment
● Taking a software package and running it

27. Continuous Deployment
● Deploying every time there’s a new build

28. Progressive Delivery

29. Release
● Exposing a piece of software to users

30. Continuous Release
● Exposing users to every new Deployment
● => Exposing them to every new Build

31. Deployment ==
Release?

32. Deployment !=
Release!
We Have the Technology!

33. X. Dev/Prod Parity
Keep development, staging, and
production as similar as possible

34. Build

37. Contract
● Triggered by a new commit to main
● Produces a new container image and push to the registry
● Bottom of the testing pyramid: Linting, Compilation, Unit Testing

38. Deploy

39. ♻

40. ♻

41. ♻
♻

42. ♻
♻

43. ♻
♻
♻

44. Contract
● Triggered by a new image appearing
● Deploys to prod cluster, prod namespace
● No user traffic

45. ♻

46. ♻

47. ♻

48. ♻

49. Isolation
● Does it even start?
● Available for manual testing
● Automated integration testing
● Automated end-to-end testing
● Automated non-functional testing
○ Failed if performance isn’t within SLO

50. ♻

51. ♻
🔍

52. ♻
🔍

53. ♻
🔍

54. Read-Only
● Gets a mirror of user traffic, but responses dropped
● What’s its Service Level? - crash rate, error rate, performance
● Compare results, if helpful

55. Release

56. ♻

57. ♻

58. ♻

59. Progressive Roll-Out
● Sends 1% of user traffic to new version
● Monitor all SLIs for a period of time
● If it’s within the SLOs, add 1% more traffic
Roll-back
● If it fails SLO at any point, all traffic sent back to the old version
● New version left running for inspection
● Alert raised

60. Thanks!
@mt165
Slides
Videos
Demo code
mt165.co.uk