Modern human history is a story of humans inventing new tools to do more with less. "Doing more" has allowed most of us to no longer worry about producing our own food, collecting water, planning long journeys, etc. Instead, we’re able to specialize, buy what we need for less, and to some extent explore ourselves a lot more. We're far from done, and of course humanity is far from perfect. In this talk, Mitchell Hashimoto discusses the role that automations and computers play in building a brighter future. More details: https://confengine.com/agile-india-2017/proposal/3618/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.

5. EMERGING
BEST PRACTICES

6. Heterogeneity

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

22. → = Heterogeneity

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

27. Multi-Cloud Motivation
• Regions

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

36. Solutions
Heterogeneity

37. Solutions
• Terraform, Kubernetes, etc…
• Unrelated workloads on different tech

38. Datacenter as Computer

39. Idea: DC as single shared
resource rather than a
collection of devices.

40. Today

43. Timmy Janet
Rebecca Charles

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

56. Lower cost/complexity

57. Lower cost/complexity
=
DC as Computer

58. Datacenter 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

70. Solutions
Datacenter as Computer

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.

86. Higher Abstraction
=
Declarative

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

93. Solutions
Declarative

94. Solutions
• Schedulers, Terraform, EC2
• “Plan” as a fundamental primitive

95. App-Level Security

96. Idea: App-level security in
addition to network and
server level.

97. Today

98. Today Historically

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

123. Enables efficient growth.

124. Done in addition to
perimeter security.

125. Challenges
• TLS is hard
• Identity is hard
• Modifying apps is hard

126. Solutions
App-Level Security

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.

142. THANK YOU!
@mitchellh