The document discusses moving from monolithic applications to microservices and serverless architectures. It outlines the benefits of these approaches, such as improved developer productivity, scalability, and operational efficiencies. It also notes some challenges, such as increased complexity. The document provides guidance on planning the transition, including assessing applications, creating a roadmap, and piloting changes on select applications before full migration.

1. Go cloud native!

2. Don’t build legacy.

3. Microservices

4. Reaction to monoliths and
heavy weight services.

5. As well as cloud environments.

6. Monoliths hurt.

7. Developer productivity takes a hit.

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

9. Long ramp up times
for new developers.

10. Small change results in building
and deploying everything.

11. Scaling means scaling the
entire application!

12. Not just the part that
needs more capacity.

13. Hard to evolve.

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

15. Otherwise known as a
teenagers bedroom.

16. The universe really
wants to be disordered.

17. Software is not immune
from these forces!

18. Modularity tends to
break down over time.

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

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

21. Enter the microservice.

22. No “one” definition.

23. In the eye of the beholder…

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

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

27. Think in terms of characteristics.

28. Suite of small, focussed services.

29. Do one thing, do it well.

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

31. Independently deployable.

32. Independently scalable.

33. Evolve at different rates.

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

35. Built around business capabilities.

36. High cohesion, low coupling…

37. Applied to services.

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

40. Despite what some
developers may have said.

42. Use them wisely.

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

44. –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

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

46. Serverless

47. From IaaS to CaaS to PaaS…

48. What about serverless?

49. Functions.

50. As a Service.

51. I hear that is *the* in thing now.

52. But we just refactored to cloud
native microservices…

53. !

54. ( °□°)

55. Don’t throw that code away just yet!

56. Fair to say FaaS is a
subset of serverless.

57. Though many use the
terms interchangeably.

58. First things first. There
are still servers.

59. We are just (further)
abstracted away from them.

60. We don’t have to spend time
provisioning, updating, scaling…

61. In other words it is
someone else’s problem.

62. https://mobile.twitter.com/samnewman/status/952610105169793025

63. https://mobile.twitter.com/starbuxman/status/959366771462496256

64. IaaS
Containers
Container
Container
Scheduling
Primitives for
Networking,
Routing, Logs and
Metrics
Platform
Application
Container Images
L7 Network
Logs, Metrics,
Monitoring
Services
Marketplace
Team, Quotas &
Usage
Container
Serverless
Function
Function Execution
Function Scaling
Event Stream
Bindings
Container
Developer
Provided
Tool
Provided

65. Different levels of abstraction.

66. Hardware
IaaS
Containers
Platforms
Serverless
More Flexibility
Fewer Standards
Lower Complexity
Operational Efficiency
Push as many workloads up the stack as feasible.

67. Veritable plethora of options.

68. AWS Lambda, Azure Functions,
Google Cloud Functions…

69. riff, OpenWhisk, Kubeless, Knative…

70. Definitely suffers from the
shiny new thing curse.

72. And everything that entails.

74. There *are* very good reasons
to utilize this approach!

75. But it isn’t just a new a way to cloud.

76. There are serious efficiency gains
to be had with this approach!

77. Development efficiencies.

78. Functions push us further up
the abstraction curve.

79. Allows us to focus on
implementation not infrastructure.

80. Do you know what OS your
application is running on?

81. Do you care?

82. What *should* you care about?

83. Where is the “value line” for you?

84. We want to get out of the business
of “undifferentiated heavy lifting”.

85. Focus on business problems,
not plumbing problems.

86. Resource efficiencies.

87. Function hasn’t been
called recently?

88. Terminate the container.

89. Request comes in? Instance
springs into existence.

90. First million (or two)
requests are free*.

91. * Additional fees may apply.

92. For example: data transfer fees
or other services you leverage.

93. Functions aren’t free however.

94. A fractional cost per request.

95. Charged based on # of requests,
run duration & resource allocation.

96. Can be challenging to determine
just how much it will cost…

97. But for certain workloads,
it is very cost effective.

98. Operational efficiencies.

99. Serverless ops?

100. Again, less for us to worry about.

101. Rely on a platform.

102. Very valuable tool.

103. It isn’t a good fit for every workload.

104. https://twitter.com/ntschutta/status/1010109588832702464

105. But you knew that.

106. Plan the journey

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

108. You need to assess the applications.

109. Some will be great
candidates, others…

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

111. Technical characteristics.

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

113. How many users?

114. How many transactions per
second (estimate)?

115. What components do we use?

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

117. What are the data integrations?

118. What is the data access technology?

119. Do we use any internal frameworks?

120. Are there any batch jobs?

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

122. What do we have for test coverage?

123. We need to assess the
refactoring effort.

124. Look for certain red flags.

125. Vendor dependencies.

126. Writing to the file system.

127. Reading from the file system.

128. Long startup times.

129. Long shut down times.

130. Non-HTTP protocols.

131. Hard coded configuration.

132. Container based shared state.

133. Distributed transactions.

134. Evaluate your applications for
12 Factors compatibility.

135. Again, it is a sliding scale.

136. How far out of alignment is the app?

137. This effort requires
application expertise.

138. And it will take time.

139. At least a few hours per.

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

141. Excel is not an application
platform. Cough.

142. Unless you have a small portfolio…

143. Assessments will bucket
your applications.

144. Low/Medium/High.

145. Or red/yellow/green.

146. Whatever works!

147. “Cutoffs” likely arbitrary.

148. Sanity check it.

149. What is the business value
of the application?

150. Consider the life cycle
of the application.

151. Is it strategic?

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

153. Or is it going to be retired soon?

154. Retirement isn’t a hard no though.

155. *When* matters. A lot.

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

157. That was 25 years ago. Still running.

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

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

160. Now we need to do some planning.

161. What is your desired end state?

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

163. Legacy apps will require refactoring.

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

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

166. Strongly recommend
a pilot app or two.

167. Get a feel for it.

168. Usually a few weeks or so.

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

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

171. Help teams migrate.

172. Should *pair* with the
application area.

173. Need to grow the skills.

174. Create a roadmap.

175. When can the applications move?

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

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

178. Move what you can.

179. Again, the terminology
can be challenging…

180. Look to opportunistically
migrate what you can.

181. But have a rough idea of when.

182. Does that satisfy your stakeholders?

183. What can you do to
accelerate the plan?

184. Good luck!

185. September 24–27, 2018
Washington DC
Gaylord, National Harbor Discount Code
S1P200_NSchutta
Register
Today &
Save!

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