Towards FutureOps: Stable, Repeatable environments from Dev to Prod
2 likes681 views
The document discusses future trends in tools and techniques for operations, emphasizing the importance of embracing heterogeneity in technology and adopting a declarative approach to deployment and security. It highlights the necessity for efficient resource management, multi-cloud strategies, and app-level security in an increasingly complex tech environment. The ultimate goal is to enhance collaboration across development and operations teams, enabling rapid deployment and secure communication among applications.
![Homogeneity means one of:
1.) Change won’t happen [for us]](https://image.slidesharecdn.com/towardsfutureops-stablerepeatableenvironmentsfromdevtoprod-170319163441/85/Towards-FutureOps-Stable-Repeatable-environments-from-Dev-to-Prod-13-320.jpg)
![Homogeneity means one of:
1.) Change won’t happen [for us]
2.) Change is atomic (A → B)](https://image.slidesharecdn.com/towardsfutureops-stablerepeatableenvironmentsfromdevtoprod-170319163441/85/Towards-FutureOps-Stable-Repeatable-environments-from-Dev-to-Prod-14-320.jpg)
![Homogeneity means one of:
1.) Change won’t happen [for us]
2.) Change is atomic (A → F)
3.) Change is gradual (A → A’ → … → F)](https://image.slidesharecdn.com/towardsfutureops-stablerepeatableenvironmentsfromdevtoprod-170319163441/85/Towards-FutureOps-Stable-Repeatable-environments-from-Dev-to-Prod-15-320.jpg)
Towards FutureOps: Stable, Repeatable environments from Dev to Prod
- 1. LOOKING FORWARD The Future of Tools and Techniques in Operations
- 3. LOOKING FORWARD The Future of Tools and Techniques in Operations
- 4. Effectively deliver and maintain applications.
- 7. Idea: More technologies in use, not less.
- 8. HOMOGENEITY • A single paradigm: VMs, containers, etc. • A single tech stack: Java, LAMP, etc. • A single cloud provider: Amazon
- 9. Reality!
- 10. Things change for the better.* * Sometimes it takes a few changes
- 11. ∴
- 12. Homogeneity means one of:
- 13. Homogeneity means one of: 1.) Change won’t happen [for us]
- 14. Homogeneity means one of: 1.) Change won’t happen [for us] 2.) Change is atomic (A → B)
- 15. Homogeneity means one of: 1.) Change won’t happen [for us] 2.) Change is atomic (A → F) 3.) Change is gradual (A → A’ → … → F)
- 16. A → A’ → … → F
- 17. A → A’ → … → F
- 18. A → A’ → … → F1
- 19. A → A’ → … → F1 B → … → F2
- 20. A → A’ → … → F1 B → … → F2 C → … → F3
- 21. A → A’ → … → F1 B → … → F2 C → … → F3 D
- 23. Heterogeneity
- 24. Embrace things will be different.
- 25. Heterogeneity • Embrace things will be different • Choose tooling that aligns with that reality • Hire people who align with that reality • Be mindful of change
- 26. Multi-cloud
- 28. Multi-Cloud Motivation • Regions • Features
- 29. Multi-Cloud Motivation • Regions • Features • Pricing
- 30. Multi-Cloud Motivation • Regions • Features • Pricing • Lock-in avoidance
- 31. Multi-tech
- 32. Multi-Tech Motivation • Right tool for the job • Job Market • Forced requirements (SDK, walled garden, etc.)
- 33. Multi-compute
- 34. Multi-Compute Motivation • Requirements (performance, legacy, security, etc.) • Existing knowledge, experience
- 35. Challenges • Management of resources and cost • Speed of light
- 37. Solutions • Terraform, Kubernetes, etc… • Unrelated workloads on different tech
- 39. Idea: DC as single shared resource rather than a collection of devices.
- 40. Today
- 44. App App
- 48. TEST: Can I unplug your servers? Is that okay?
- 49. Reality!
- 50. Number of servers, apps growing at a breakneck pace.
- 51. ∴
- 52. Choices:
- 53. Choices: 1.) Growth will slow down
- 54. Choices: 1.) Growth will slow down 2.) Train and hire
- 55. Choices: 1.) Growth will slow down 2.) Train and hire 3.) Lower cost/complexity
- 57. Lower cost/complexity = DC as Computer
- 59. Separate application from the resources it runs on.
- 61. RAM: 500 MB CPU: 200 MHz DISK: 50 IOPS, SSD{
- 63. App App App
- 64. App App App
- 65. App App App
- 66. App App App
- 67. App App App
- 68. Allows for choice in lower level components.
- 69. Challenges • Management is complex • Not all apps fit this model easily • Trust
- 71. Solutions • Schedulers • Complex, years to mature • State: Ephemeral vs. Sticky vs. Persistent • Heterogeneity!
- 72. Declarative
- 73. Idea: Goal-driven tooling where we describe what, not how.
- 74. Today
- 76. I need the web server AMI updated to ami-abcd1234. I need to spin up 3 more servers. And I need to change the maintenance window for the database.
- 77. WHOA. Let’s break that down. Let’s start with the updated AMIs, write down a plan, test it out for a few weeks, then schedule a full day to roll it out.
- 79. Reality!
- 80. Change requires a burden of knowledge too large.
- 82. ∴
- 83. Choices:
- 84. Choices: 1.) Hire or train more experts
- 85. Choices: 1.) Hire or train more experts 2.) Enable non-experts through higher level abstractions.
- 87. Declarative
- 88. Describe your goal, not the steps to get there.
- 91. Benefits • Flexible choices for how • Easier to educate, knowing what you want is usually easier than how. • Complex tasks are easily modeled
- 92. Challenges • Trust, trust, TRUST! • Lack of control (trust) • Difficult problem, large scope
- 94. Solutions • Schedulers, Terraform, EC2 • “Plan” as a fundamental primitive
- 96. Idea: App-level security in addition to network and server level.
- 97. Today
- 100. “Us” vs. “Them”
- 101. Historically • External vs. Internal • Server to Server (iptables, route tables, etc.) • Hand-curated set of rules • Unencrypted internal communication
- 102. Reality!
- 103. Clouds blur the line.
- 104. Clouds blur the line. Threats come from within.
- 105. Clouds blur the line. Threats come from within. Orders of magnitude more apps.
- 106. ∴
- 107. Choices:
- 108. Choices: 1.) Manually curate all rules all the time
- 109. Choices: 1.) Hire or train more experts 2.) Enforce security at the app-level
- 110. App-Level Security
- 111. End-to-end encryption, identity for all connections, permission-checked APIs.
- 113. “Hi, I’m Alice!”
- 114. “Hey there, I’m Bob!”
- 115. “Hey there, I’m Bob!”
- 116. “I need to bill Charles $34.”
- 117. “Okay! Charles has been billed $34”
- 118. “Hi, I’m Alice!”
- 119. “No, I don’t think you are.”
- 120. “I need to bill Charles $34.”
- 121. “Sorry, Alice, you can’t do that.”
- 122. App-Level Security • All connections have identity • All connections are encrypted • All requests are checked for permission
- 124. Done in addition to perimeter security.
- 125. Challenges • TLS is hard • Identity is hard • Modifying apps is hard
- 127. Solutions • “Security Server” (Vault) • Scheduler can orchestrate setup • Secure introduction
- 128. DevOps
- 129. Idea: Dev, Ops, Sec must be able to work together to streamline deployment.
- 130. “DevOps”
- 131. Dev Ops Sec
- 132. Dev Ops Sec
- 134. DevOps • Increased efficiency through parallelization of work. • Requires both tooling and cultural change.
- 135. Our Glorious Future
- 136. Globally distributed set of available resources, available on demand. (Cloud, Heterogeneity)
- 137. Utilizing this in most cases is as simple as “double click to run.” (Schedulers, DC as Computer)
- 138. Build and deploy by describing what you want, not how to do it. (Declarative)
- 139. App-to-app secured communications with a known identity. (App-Level Security)
- 140. Deploying 10s, 100s, 1000s of apps quickly and efficiently. (DevOps)
- 141. NOTICE: Workflows, not technologies.