Evolving to Cloud-Native - Nate Schutta (1/2) at SpringOne Platform Chicago 2018

1. Evolving to
Cloud Native
@ntschutta
ntschutta.io
Nathaniel Schutta

2. https://content.pivotal.io/
ebooks/thinking-architecturally

3. Ah “the cloud!”

4. So. Many. Options.

5. Microservices. Modular monoliths.

6. Container all the things?

7. What about serverless?

8. Functions. As a Service.

9. Did someone say Polycloud?
https://www.thoughtworks.com/radar/techniques/polycloud

10. How do we make
sense of all this?!?

11. There are real engineering
issues to overcome.

12. Many believe in magic
sparkle ponies...

13. How do we avoid pitfalls?

14. And a strong case of
resume driven design?

15. What is cloud
Native?

16. Applications designed to take
advantage of cloud computing.

17. Fundamentally about how we
create and deploy applications.

18. Cloud computing gives us
some very interesting abilities.

19. Scale up. Scale down. On demand.

20. Limitless compute.*

21. * Additional fees may apply.

22. Cloud native isn’t just an
architectural pattern.

23. Combination of practices,
techniques, technologies.

24. Agile development.

25. Continuous delivery.

26. Automation.

27. Containers.

28. Microservices.

29. Functions.

30. Changes our culture.

31. DevOps.

32. Infrastructure is a different
game today isn’t it?

33. We’ve seen this massive shift.

34. Servers used to be home grown.

35. Bespoke. Artisanal.

36. Spent days hand crafting them.

37. Treated them like pets…

39. Did whatever it took to keep
them healthy and happy.

40. Servers were a heavily
constrained resource.

41. They were really expensive!

42. Had to get our money’s worth…

43. Thus was born app servers.

44. Put as many apps as
possible on a server.

45. Maximize the return on investment.

46. But that has some
unintended side effects.

47. Shared resources.

48. One application’s bug could
take down multiple apps.

49. Coordinating changes hurts.

50. “Your app can’t get this feature
until all other apps are ready.”

51. Currency === 18 months of
freezes, testing, frustration.

52. Organizations ignored currency
issues…pain wasn’t “worth it”.

53. –Yoda
“Fear is the path to the dark side.
Fear leads to anger. Anger leads
to hate. Hate leads to suffering.”

54. #YodaOps

55. Move code from one
server to another…

56. Worked in dev…but not test.

57. Why?!?

58. The environments are
the same…right?

59. “Patches were applied in a
different order…”

60. Can I change careers?

61. Things started to change.

62. Servers became commodities.

63. Linux and Intel chips replaced
custom OS on specialized silicon.

64. https://mobile.twitter.com/linux/status/936877536780283905?lang=en

65. Prices dropped.

66. Servers were no longer the
constraining factor.

67. People costs eclipsed
hardware costs.

68. Heroku, AWS, Google App
Egine, Cloud Foundry, Azure.

69. Shared servers became a liability.

70. Treat them like cattle…when
they get sick, get a new one.

72. New abstractions.

73. Containers and PaaS
changed the game.

74. Package the app up with
everything it needs.

75. Move *that* to a
different environment.

76. Works in dev? You’re testing the
exact same thing in test.

77. So. Much. Win.

78. Your app needs a spiffy
new library? Go ahead!

79. It doesn’t impact any other app
because you are isolated.

80. Moves the value line.

81. Less “undifferentiated heavy lifting”.

82. https://mobile.twitter.com/onsijoe/status/598235841635360768?lang=en

83. Changes development.

84. Always be changing.

85. Run experiments. A/B testing.

86. Respond to business changes.

87. Deliver in days not months.

88. https://mobile.twitter.com/ntschutta/status/938109379995353088

89. Speed matters.

90. Disruption impacts every business.

91. Your industry is not immune.

92. Amazon Prime customers can
order from Whole Foods.

93. Some insurance companies
view Google as a competitor.

94. We’re all technology
companies today.

95. 12 factors

96. Twelve Factor App.
https://12factor.net

97. Characteristics shared by
successful apps.

98. At least at Heroku.

99. I. One codebase in version
control, multiple deploys.

100. Version control isn’t
controversial. Right?!?

101. Sharing code? It better
be in a library then…

102. II. Explicitly define your
dependencies.

103. Do not rely on something just
“being there” on the server.

104. If you need it, declare it.

105. III. Configuration must be
separate from the code.

106. The things that vary from
environment to environment.

107. Could you open source
that app right now?

108. IV. Backing services are just
attached resources.

109. Should be trivial to swap out a
local database for a test db.

110. In other words, loose coupling.

111. V. Build, release, run.

112. Deployment pipeline anyone?

113. Build the executable…

114. Deploy the executable with the
proper configuration…

115. Launch the executable in a
given environment.

116. VI. Stateless - share nothing.

117. State must be stored via some
kind of backing service.

118. In other words, you cannot rely
on the filesystem or memory.

119. Recovery. Scaling.

120. VII. Export services via port binding.

121. App exports a port, listens for
incoming requests.

122. localhost for development,
load balancer for public facing.

123. VIII. Scale via process.

124. In other words, scale horizontally.

125. IX. Start up fast, shut
down gracefully.

126. Processes aren’t pets,
they are disposable.

127. Processes can be started (or
stopped) quickly and easily.

128. Ideally, start up is seconds.

129. Also can handle
unexpected terminations!

130. X. Dev/Prod parity.

131. From commit to production
should be hours…maybe days.

132. Definitely not weeks.

133. Developers should be involved
in deploys and prod ops.

134. Regions should be identical. Or
as close as possible to identical.

135. Backing services should be the
same in dev and prod.

136. Using one DB in dev and
another in prod invites pain.

137. XI. Logs as event streams.

138. Don’t write logs to the filesystem!

139. It won’t be there later…

140. Write to stdout.

141. Stream can be routed any
number of places.

142. And then consumed via a
wide variety of tools.

143. XII. Admin tasks run as
one off processes.

144. Database migrations for instance.

145. REPL for the win.

146. Run in an identical environment
to the long running processes.

147. Your legacy apps will
violate some factors.

148. Maybe all 12!

149. In general…

150. II. Explicitly define your
dependencies.

151. Probably one of the
harder ones to satisfy.

152. Do we really need this library?

153. “It works, don’t touch it.”

154. III. Configuration must be
separate from the code.

155. Many an app has
hardcoded credentials.

156. Hardcoded database connections.

157. VI. Stateless - share nothing.

158. Also can be challenging.

159. Many apps were designed
around a specific flow.

160. Page 2 left debris for Page 3!

161. “Just stash that in session”.

162. IX. Start up fast, shut
down gracefully.

163. Many apps take way
too long to start up…

164. Impacts health checks.

165. X. Dev/Prod parity.

166. Environments should be consistent!

167. Shorten code to prod cycle.

168. “It worked in test…”

169. Do your applications have to be
fully 12 factor compliant?

170. Nope.

171. Is it a good goal?

172. Sure.

173. But be pragmatic.

174. Certain attributes lessen the
advantages of cloud.

175. Long startup time hurts elastic
scaling & self healing.

176. Think of it as a continuum.

177. 12 Factor Compliance
Benefits of Cloud Deployment

178. Developers also talk
about 15 factor apps.

179. aka Beyond the Twelve-Factor App.
https://content.pivotal.io/blog/beyond-the-twelve-factor-app

180. However you define it…

181. To maximize what
the cloud gives us…

182. Applications need to be
designed properly.

183. Legacy applications will fall short.

184. Opportunistically refactor!

185. Building greenfield?