The document discusses cloud native applications and architectures. It explains that cloud native applications are designed to take advantage of cloud computing abilities like scaling up and down on demand and limitless compute. Being cloud native isn't just an architectural pattern but a combination of practices like agile development, continuous delivery, automation, containers, and microservices that change development culture and move to a DevOps model. It also discusses concepts like serverless computing, functions as a service, microservices, and twelve factor applications.

1. Cloud Native 101
@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. Is that cloud native?

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

10. What is cloud
Native?

11. Applications designed to take
advantage of cloud computing.

12. Fundamentally about how we
create and deploy applications.

13. Cloud computing gives us
some very interesting abilities.

14. Scale up. Scale down. On demand.

15. Limitless compute.*

16. * Additional fees may apply.

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

18. Combination of practices,
techniques, technologies.

19. Agile development.

20. Continuous delivery.

21. Automation.

22. Containers.

23. Microservices.

24. Functions.

25. Changes our culture.

26. DevOps.

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

28. We’ve seen this massive shift.

29. Servers used to be home grown.

30. Bespoke. Artisanal.

31. Spent days hand crafting them.

32. Treated them like pets…

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

35. Servers were a heavily
constrained resource.

36. They were really expensive!

37. Had to get our money’s worth…

38. Thus was born app servers.

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

40. Maximize the return on investment.

41. But that has some
unintended side effects.

42. Shared resources.

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

44. Coordinating changes hurts.

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

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

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

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

49. #YodaOps

50. Move code from one
server to another…

51. Worked in dev…but not test.

52. Why?!?

53. The environments are
the same…right?

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

55. Can I change careers?

56. Things started to change.

57. Servers became commodities.

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

59. Prices dropped.

60. Servers were no longer the
constraining factor.

61. People costs eclipsed
hardware costs.

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

63. Redis is available on
all of those BTW.

64. Shared servers became a liability.

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

67. New abstractions.

68. Containers and PaaS
changed the game.

69. Package the app up with
everything it needs.

70. Move *that* to a
different environment.

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

72. So. Much. Win.

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

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

75. Moves the value line.

76. Less “undifferentiated heavy lifting”.

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

78. Changes development.

79. Always be changing.

80. Run experiments. A/B testing.

81. Respond to business changes.

82. Deliver in days not months.

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

84. Speed matters.

85. Disruption impacts every business.

86. Your industry is not immune.

87. Amazon Prime customers can
order from Whole Foods.

88. Some insurance companies
view Google as a competitor.

89. We’re all technology
companies today.

90. 12 factors

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

92. Characteristics shared by
successful apps.

93. At least at Heroku.

94. 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.

95. 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.

96. Your legacy apps will
violate some factors.

97. Maybe all 12!

98. In general…

99. II. Explicitly define your
dependencies.

100. Probably one of the
harder ones to satisfy.

101. Do we really need this library?

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

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

104. Many an app has
hardcoded credentials.

105. Hardcoded database connections.

106. VI. Stateless - share nothing.

107. Also can be challenging.

108. Many apps were designed
around a specific flow.

109. Page 2 left debris for Page 3!

110. “Just stash that in session”.

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

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

113. Impacts health checks.

114. X. Dev/Prod parity.

115. Environments should be consistent!

116. Shorten code to prod cycle.

117. “It worked in test…”

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

119. Nope.

120. Is it a good goal?

121. Sure.

122. But be pragmatic.

123. Certain attributes lessen the
advantages of cloud.

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

125. Think of it as a continuum.

126. 12 Factor Compliance
Benefits of Cloud Deployment

127. Developers also talk
about 15 factor apps.

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

129. However you define it…

130. To maximize what
the cloud gives us…

131. Applications need to be
designed properly.

132. Legacy applications will fall short.

133. Opportunistically refactor!

134. Building greenfield?

135. Go cloud native!

136. Don’t build legacy.

137. Microservices

138. Reaction to monoliths and
heavy weight services.

139. As well as cloud environments.

140. Monoliths hurt.

141. Developer productivity takes a hit.

142. Hard to get your head wrapped
around a huge code base.

143. Long ramp up times
for new developers.

144. Small change results in building
and deploying everything.

145. Scaling means scaling the
entire application!

146. Not just the part that
needs more capacity.

147. Hard to evolve.

148. We’re all familiar with the second
law of thermodynamics…

149. Otherwise known as a
teenagers bedroom.

150. The universe really
wants to be disordered.

151. Software is not immune
from these forces!

152. Modularity tends to
break down over time.

153. Over time, takes longer to
add new functionality.

154. Frustration has given birth to a
“new” architectural style.

155. Enter the microservice.

156. No “one” definition.

157. In the eye of the beholder…

158. https://mobile.twitter.com/littleidea/status/500005289241108480

159. Anything that can be
rewritten two weeks or less.

161. Think in terms of characteristics.

162. Suite of small, focussed services.

163. Do one thing, do it well.

164. Linux like - pipe simple things
together to get complex results.

165. Independently deployable.

166. Independently scalable.

167. Evolve at different rates.

168. Freedom to choose the
right tech for the job.

169. Built around business capabilities.

170. High cohesion, low coupling…

171. Applied to services.

172. It is just another approach. An
architectural style. A pattern.

174. Despite what some
developers may have said.

176. Use them wisely.

177. Please Microservice Responsibly.
https://content.pivotal.io/blog/should-that-be-a-
microservice-keep-these-six-factors-in-mind

178. –Simon Brown
“If you can't build a monolith, what makes
you think microservices are the answer?”
http://www.codingthearchitecture.com/2014/07/06/
distributed_big_balls_of_mud.html

179. Sometimes the right answer is a
modular monolith…
https://www.youtube.com/watch?v=kbKxmEeuvc4

180. Redis &
Microservices

181. Redis - Swiss Army Knife of
Microservices Architecture.

182. It isn’t just for breakfast!

183. It is more than just a cache.

184. Application Server
Authentication
Site Pages
Customer Profile
Management
Search and Discovery Product Catalog
Session Store/
Shopping Cart
Order Processing Fulfillment Analytics
Product Catalog
Manager
Site Manager
Order Fulfillment Application Business Intelligence
Message Queue

185. • Session store
• Cache server
• Search engine
• Time-series database
• Analytics database
• Message Broker

187. Top Use Cases.

188. • User Session Store
• Cache
• Translytics
• API Rate Limiting
• Message Broker/Queues
• Blog Posts
• Tags

189. • Instant Messaging / Chat
• User On/Offline Status
• Followers
• Mutual Friends
• User Comments
• User Ratings
• P2P Games
• Leaderboards

190. Manage Session Stores
with Redis Hash.

191. At one time, we could
just use a database.

192. It was a simpler time.

193. Internet Server Database
Traffic
Grows…
Struggles

194. Internet Server Database
Store Session
state on server!

195. Internet Server Database
Ephemeral

196. Internet Server Database

197. Maintain session state
across multiple servers.

198. Can you say hash?

199. HSET lets you save session
variables as key/value pairs.

200. HGET to retrieve values.

201. Managing Queues with Redis Lists.

202. Lots of items to be worked on!

203. Asynchronous processing
reduces block/wait times.

204. Hello lists!

205. LPUSH, RPUSH add values at
beginning or end of queue.

206. RPOPLPUSH – pop from one
queue and push it to another.

207. Managing Tags with Redis Sets.

208. So. Many. Tags.

209. How do we find items
with a particular tag?

210. Sets are unique
collections of strings.

211. SISMEMBER to check if an
article has a given tag.

212. SMEMBERS to get all the
tags for an article.

213. Also useful for
recommending similar things.

214. Managing Leaderboards with
Redis Sorted Sets.

215. But my enterprise
app isn’t a game…

216. What is your top error message?

217. Error message leaderboard!

218. Did someone say sorted sets?

219. ZADD to add/update.

220. ZRANK will get any users
rank instantaneously.

221. Unified Logs with Redis Streams.

222. How do we share state in
distributed systems?

223. Needs to be durable.

224. Ordered data structure.

225. Acts like a master ledger.

226. Streams to the rescue!

227. XADD to append, XRANGE to
read a set of records.

228. So much more than a cache!

229. Technology changes.
Feature, not a bug.

230. We need to evolve along with it.

231. The more things change, the
more they stay the same.

232. Apply the right technology to
solve your problems!

233. Good luck!

234. 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