It seems like a new cloud-native technology or project is launched every week, and though there are technical changes required for building and operating cloud-native applications, technology alone isn’t a silver bullet. It turns out that how you build your applications is critical to enable seamless scaling and resiliency to failures. What do you have to do to ensure your applications can fully leverage the power and flexibility the cloud offers? The 12-Factor principles have been around for a decade and have proven themselves as core, foundational principles for cloud-native applications. But they require changes to how you design your applications, the way teams collaborate on code, and more. Understanding the 12-Factor principles is a strong foundation for adopting cloud-native patterns and practices. Join Pivotal's Nate Schutta, developer advocate, to learn: ● Which of the 12 Factors are most critical to building scalable applications ● Which of the 12 Factors are most likely violated by your heritage applications ● What you can do to make your existing applications more 12-Factor compliant ● Which of the 12 Factors are most critical to applications moving to the cloud ● How to externalize state and configuration in order to simplify scaling and code changes Presenter :Nate Schutta, Software Architect

1. 12 Factor
Applications
@ntschutta
ntschutta.io
Nathaniel Schutta

2. Ah “the cloud!”

3. So. Many. Options.

4. Microservices. Modular monoliths.

5. Container all the things?

6. What about serverless?

7. Functions. As a Service.

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

9. What the heck are the 12
factors? Why 12? Why not 11?

10. Is *my* app 12 factor?

11. What should I do with my
heritage portfolio?

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

13. What is cloud
Native?

14. https://mobile.twitter.com/as_w/status/1090763452241534976

15. Applications designed to take
advantage of cloud computing.

16. Fundamentally about how we
create and deploy applications.

17. Cloud computing gives us
some very interesting abilities.

18. Scale up. Scale down. On demand.

19. Limitless compute.*

20. * Additional fees may apply.

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

22. Combination of practices,
techniques, technologies.

23. Agile development.

24. Continuous delivery.

25. Automation.

26. Containers.

27. Microservices.

28. Functions.

29. Changes our culture.

30. DevOps.

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

32. We’ve seen this massive shift.

33. Servers used to be home grown.

34. Bespoke. Artisanal.

35. Spent days hand crafting them.

36. Treated them like pets…

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

39. Servers were a heavily
constrained resource.

40. They were really expensive!

41. Had to get our money’s worth…

42. Thus was born app servers.

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

44. Maximize the return on investment.

45. But that has some
unintended side effects.

46. Shared resources.

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

48. Coordinating changes hurts.

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

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

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

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

53. #YodaOps

54. Move code from one
server to another…

55. Worked in dev…but not test.

56. Why?!?

57. The environments are
the same…right?

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

59. Can I change careers?

60. Things started to change.

61. Servers became commodities.

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

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

64. Prices dropped.

65. Servers were no longer the
constraining factor.

66. People costs eclipsed
hardware costs.

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

68. Shared servers became a liability.

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

71. New abstractions.

72. Containers and PaaS
changed the game.

73. Package the app up with
everything it needs.

74. Move *that* to a
different environment.

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

76. So. Much. Win.

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

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

79. Moves the value line.

80. Less “undifferentiated heavy lifting”.

81. Changes development.

82. Always be changing.

83. Run experiments. A/B testing.

84. Respond to business changes.

85. Deliver in days not months.

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

87. Speed matters.

88. Disruption impacts every business.

89. Your industry is not immune.

90. Amazon Prime customers can
order from Whole Foods.

91. Some insurance companies
view Google as a competitor.

92. We’re all technology
companies today.

93. 12 factors

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

95. Characteristics shared by
successful apps.

96. At least at Heroku.

97. 1. One codebase in version control,
multiple deploys.
2. Explicitly define your dependencies.
3. Configuration must be separate from
the code.
4. Backing services are just attached
resources.
5. Build, release, run.

98. 6. Stateless - share nothing.
7. Export services via port binding.
8. Scale via process.
9. Start up fast, shut down gracefully.
10.Dev/Prod parity.
11.Logs as event streams.
12.Admin tasks run as one off
processes.

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. https://mobile.twitter.com/stuarthalloway/status/1134806008528809985

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

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

120. Recovery. Scaling.

121. VII. Export services via port binding.

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

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

124. VIII. Scale via process.

125. In other words, scale horizontally.

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

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

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

129. Ideally, start up is seconds.

130. Also can handle
unexpected terminations!

131. X. Dev/Prod parity.

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

133. Definitely not weeks.

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

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

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

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

138. XI. Logs as event streams.

139. Don’t write logs to the filesystem!

140. It won’t be there later…

141. Write to stdout.

142. Stream can be routed any
number of places.

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

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

145. Database migrations for instance.

146. REPL for the win.

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

148. Your legacy apps will
violate some factors.

149. Maybe all 12!

150. In general…

151. II. Explicitly define your
dependencies.

152. Probably one of the
harder ones to satisfy.

153. Do we really need this library?

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

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

156. Many an app has
hardcoded credentials.

157. Hardcoded database connections.

158. VI. Stateless - share nothing.

159. Also can be challenging.

160. Many apps were designed
around a specific flow.

161. Page 2 left debris for Page 3!

162. “Just stash that in session”.

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

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

165. Impacts health checks.

166. X. Dev/Prod parity.

167. Environments should be consistent!

168. Shorten code to prod cycle.

169. “It worked in test…”

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

171. Nope.

172. Is it a good goal?

173. Sure.

174. But be pragmatic.

175. Certain attributes lessen the
advantages of cloud.

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

177. Think of it as a continuum.

178. 12 Factor Compliance
Benefits of Cloud Deployment

179. Developers also talk
about 15 factor apps.

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

181. However you define it…

182. To maximize what
the cloud gives us…

183. Applications need to be
designed properly.

184. Legacy applications will fall short.

185. Opportunistically refactor!

186. Building greenfield?

187. Go cloud native!

188. Don’t build legacy.

189. Plan the journey

190. Before you start, figure
out where you are.

191. You need to assess the applications.

192. Some will be great
candidates, others…

193. We need to understand a few
things about our applications.

194. Technical characteristics.

195. What is the tech stack?
What version are we on?

196. How many users?

197. How many transactions per
second (estimate)?

198. What components do we use?

199. What 3rd party things does the
application use?

200. What are the data integrations?

201. What is the data access technology?

202. Do we use any internal frameworks?

203. Are there any batch jobs?

204. Do we have CI/CD? What are
we using to build the apps?

205. What do we have for test coverage?

206. We need to assess the
refactoring effort.

207. Look for certain red flags.

208. Vendor dependencies.

209. Writing to the file system.

210. Reading from the file system.

211. Long startup times.

212. Long shut down times.

213. Non-HTTP protocols.

214. Hard coded configuration.

215. Container based shared state.

216. Distributed transactions.

217. Evaluate your applications for
12 Factors compatibility.

218. Again, it is a sliding scale.

219. How far out of alignment is the app?

220. This effort requires
application expertise.

221. And it will take time.

222. At least a few hours per.

223. Consider building a little
application for all the data.

224. Excel is not an application
platform. Cough.

225. Unless you have a small portfolio…

226. Assessments will bucket
your applications.

227. Low/Medium/High.

228. Or red/yellow/green.

229. Whatever works!

230. “Cutoffs” likely arbitrary.

231. Sanity check it.

232. What is the business value
of the application?

233. Consider the life cycle
of the application.

234. Is it strategic?

235. Is it something we’re
going to invest in?

236. Or is it going to be retired soon?

237. Retirement isn’t a hard no though.

238. *When* matters. A lot.

239. “When I started, this app
was marked sunset…”

240. That was 25 years ago. Still running.

241. If it is going away in a few
months…not worth it.

242. Going to be around for a
few years, probably is.

243. Now we need to do some planning.

244. What is your desired end state?

245. Cloud native? Just get it
running on cloud?

246. Legacy apps will require refactoring.

247. How long does it take to
forklift an application?
https://blog.pivotal.io/pivotal-cloud-foundry/features/the-forklifted-application

248. https://twitter.com/KentBeck/status/596007846887628801

249. Strongly recommend
a pilot app or two.

250. Get a feel for it.

251. Usually a few weeks or so.

252. Ask the experts.
https://pivotal.io/application-transformation

253. Consider staffing up a “lab”
team with expertise.

254. Help teams migrate.

255. Should *pair* with the
application area.

256. Need to grow the skills.

257. Create a roadmap.

258. When can the applications move?

259. It doesn’t have to be
the entire application!

260. Some deployable units will
be easy, others hard.

261. Move what you can.

262. Again, the terminology
can be challenging…

263. Look to opportunistically
migrate what you can.

264. But have a rough idea of when.

265. Does that satisfy your stakeholders?

266. What can you do to
accelerate the plan?

267. Good luck!

268. Nathaniel T. Schutta
@ntschutta
ntschutta.io
Thanks!
I’m a Software
Architect,
Now What?
with Nate Shutta
Modeling for
Software
Architects
with Nate Shutta
Presentation
Patterns
with Neal Ford & Nate Schutta