This document discusses the benefits of adopting a microservices architecture, including enabling independent life cycles, independent scalability, and failure isolation. It provides examples of how microservices allow developing and deploying parts of an application independently, scaling specific services rather than the entire monolith, and isolating failures to prevent bringing down the whole system. The document advocates for a responsible and data-driven approach to migrating from a monolith to microservices over time.

1. Responsible
Microservices
@ntschutta
ntschutta.io
Nathaniel Schutta

2. https://tanzu.vmware.com/
content/ebooks/thinking-
architecturally

3. https://tanzu.vmware.com/
content/ebooks/responsible-
microservices-ebook

4. Ah “the cloud!”

5. So. Many. Options.

6. For better or worse…

7. Many developers think:
cloud === microservices.

8. Lot of time spent on
domain driven design.

9. Looking for bounded contexts…

10. De
fi
ning a ubiquitous language.

11. Forming two pizza teams.

12. –Ian Malcolm
“Your [developers] were so
preoccupied with whether they could,
they didn't stop to think if they should.”

13. And that has led to
some serious pain.

14. http://evolutionaryarchitecture.com

15. Oops.

16. There are a number of good
reasons to adopt microservices.

17. But there are no free lunches.

18. We have to consider the cost of
the added complexity.

19. Does your application
actually bene
fi
t?

20. Or are you just adding
accidental complexity?

21. When should we
consider microservices?

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

23. Microservices

24. Reaction to monoliths and
heavy weight services.

25. As well as cloud environments.

26. Monoliths hurt.

27. Developer productivity takes a hit.

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

29. Long ramp up times
for new developers.

30. Small change results in building
and deploying everything.

31. Scaling means scaling the
entire application!

32. Not just the part that
needs more capacity.

33. Hard to evolve.

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

35. Otherwise known as a
teenagers bedroom.

36. The universe really
wants to be disordered.

37. Software is not immune
from these forces!

38. Modularity tends to
break down over time.

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

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

41. Enter the microservice.

42. No “one” de
fi
nition.

43. In the eye of the beholder…

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

45. Anything that can be
rewritten in two weeks or less.

48. https://twitter.com/grady_booch/status/1382231412242190336

49. Think in terms of characteristics.

50. Suite of small, focussed services.

51. Do one thing, do it well.

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

53. Independently deployable.

54. Independently scalable.

55. Evolve at different rates.

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

57. Built around business capabilities.

58. The 0th Law of Computer Science:

59. High cohesion, low coupling…

60. Applied to services.

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

63. Despite what some
developers may have said.

65. Use them wisely.

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

67. https://twitter.com/mstine/status/1390373898286518274

68. Modularity
Distributability
Big Ball
of Mud
Microservices
Distributed
BBoM
Modular
Monolith
Right Sized
Services?

69. https://twitter.com/mstine/status/1390015229292130304

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

71. Multiple Rates
of change

72. Some parts of your system
change all the time.

73. Others haven’t changed
in months. Or years.

74. If parts of your system evolve at
different speeds…

75. You might need microservices!

76. For your consideration…the
Widget.io Monolith!

77. Widget.io Monolith
Recommendation
Engine
Order Processing Search
Cart Inventory
Account
Administration

78. The Cart module probably
doesn’t change much.

79. Maybe the Inventory
system is really stable.

80. But our product owners constantly
tweak the Recommendation Engine.

81. And we are always
improving Search.

82. In a monolith, everything has to
move at the same rate.

83. Why a quarterly release?

84. Because that is when all the
changes were ready.

85. And since we had to push the
entire monolith anyway…

86. Today we have options.

87. Splitting them out allows us to
iterate those features faster.

88. Widget.io Monolith
Order Processing
Cart Inventory
Account
Administration
Recommendation
Engine
Microservice
Search
Microservice

89. Enables us to deliver
business value quickly.

90. How do we
fi
nd the components
that change far faster than the rest?

91. You probably have an inkling
already in your systems.

92. Trust your gut instincts!

93. But it can be very helpful to
have, well, some data.

94. Start with your source code
management tool…

95. You can get a “heat map” of
sorts just by looking at history.

96. git log --pretty=format: --name-only |
sort | uniq -c | sort -rg | head -10

97. Running that against Spring…

98. (Not a monolith but for
pedagogical reasons…)

100. Gives you a place to start.

101. Software archeology time!

102. Roll up your sleeves and root
around your codebase.

103. Look for (apologies Isaac Newton)
smoother pebbles and prettier shells.

104. Look for what Michael
Feathers coined “churn”.
https://www.stickyminds.com/article/getting-empirical-about-refactoring

105. Where should we refactor?

106. When you look at your project,
there will be a “long tail.”

107. Some
fi
les are updated constantly,
others just initial commit.

108. Chad Fowler created Turbulence
based on churn vs. complexity.
https://github.com/chad/turbulence

109. There are “code forensic” tools
we can leverage as well.

110. CodeScene.
https://codescene.io/about

118. Who is working on what?

121. Maybe you don’t want to leverage
something like CodeScene.

122. Once again we can turn
to our SCM tool.

124. Last commit around the Super
Blue Blood Moon Eclipse?

125. Probably not a great candidate
for microservices then!

126. Find a spot that “always be
changing”? Dig deeper!

127. Look at your bug tracker -
look for defect density.

128. Look at your backlog. Where
is the locus of attention?

129. We have some good
candidates…now what?

130. The Strangler Fig
Pattern to the rescue.

131. https://twitter.com/martinfowler/status/483603425008304129

132. Strangler Fig Application.
https://martinfowler.com/bliki/StranglerFigApplication.html

134. In a nutshell, build the new
around the edges of the old.

135. Gradually replace
the heritage bits.

136. Reduces the risk of a
big bang cutover.

137. Incrementally delivers
business value as you go.

138. Able to show regular
progress to stakeholders.

139. We can go a step further and
apply a data driven approach.

140. What would you say the old
system does exactly?

141. ¯_(ツ)_/¯

142. Odds are we don’t understand
all the nuance of the old bits.

143. Leads to bugs, no one knew
about that edge case…

144. What if we had real world data?

145. https://mobile.twitter.com/GregChase/status/938592224924725248

146. Put a proxy layer between the
client and the legacy system.
https://content.pivotal.io/slides/strangling-the-monolith-
with-a-data-driven-approach-a-case-study

147. Log the results -
requests and responses.

148. You now know what the
old system does.

149. Drives test cases for
the new functionality.

150. Legacy Monolith
Source System A Source System B Source System C
Proxy Layer
Client
Request/
Response
Data
New Microservice

151. You can run the new in
parallel with the old.

152. Route requests to both
modules - compare the results.

153. If they match, #winning.

154. In they don’t, you can use
the “heritage” response…

155. And then add tests to
fi
gure out
which result is correct.

156. Don’t be surprised if the
old system is wrong!

157. Independent
Life cycles

158. Monoliths are big ships - they
don’t turn on a dime.

159. But that doesn’t work today.

160. Always be changing.

161. Run experiments. A/B testing.

162. Respond to business changes.

163. Deliver in days not months.

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

165. Speed matters.

166. Disruption impacts every business.

167. Your industry is not immune.

168. Returning to our
Widget.io Monolith…

169. What if our business identify a
new opportunity…

170. But it requires us to iterate
and deliver in days.

171. The quarterly release cycle
won’t cut it. What do we do?

172. Widget.io Monolith
Order Processing
Cart Inventory
Account
Administration
Recommendation
Engine
Microservice
Search
Microservice
Project X
Microservice

173. As a microservice, Project X is
independent of the rest.

174. It has its own repository
and build pipeline.

175. In other words it has an
independent life cycle.

176. But we don’t just get
speed to market.

177. Increases developer productivity!

178. Monoliths often have dictionary
sized getting started guides.

179. Build times measured in
phases of the moon.

180. It can take months for a new
developer to get up to speed.

181. What was your longest stretch to
get to productive team member?

182. Smaller scope === less to get
your head wrapped around.

183. Builds take a minute or two.

184. Build breaks are
fi
xed promptly.

185. Testing can be far simpler.

186. Goodbye 80 hour manual
regression suites.

187. Hello
fi
ne grained tests
that run on every commit.

188. Forget the one-off
performance test.

189. Use the right tools for the job!

190. Shared life cycles put us at the
mercy of the longest tent pole.

191. We are no longer forced into a
one size
fi
ts none approach.

192. Each microservice can use the
mix of tests that make sense.

193. Use the appropriate linting
rules and code quality scans.

194. Simpli
fi
es the search
for
fi
tness functions.
https://www.thoughtworks.com/insights/blog/
microservices-evolutionary-architecture

195. We can practice hypothesis
driven development.
https://www.thoughtworks.com/insights/blog/how-
implement-hypothesis-driven-development

196. –Niels Bohr (attributed)
“Prediction is very dif
fi
cult,
especially if it's about the future.”

197. Ever debate possible solutions?

198. “My approach will clearly
increase conversions.”

199. How do you know?

200. What happens if you’re wrong?

201. In the monolith, we had
to be conservative.

202. Now - we can test our hypothesis.

203. A/B test it!

204. We believe <this change>
Will result in <this outcome>
We will know we have succeeded
when <we see X change in
this metric>

205. We believe adding a
distributed cache
Will result in faster startup times
We will know we have succeeded if
startup time is less than 15
seconds

206. Can lead to useful
fi
tness functions.

207. A/B used to be limited to tech
giants like Amazon and Google.

208. Now it is within reach for all of us!

209. What customer doesn’t want a
constantly improving product?

210. Of course for this to work…

211. Focus on “paved roads.”

213. Here is a well worn path, we
know it works, we support it.

215. You build it, you own it.

216. Expertise grows with repetition.

217. Deploy early, deploy often.

218. You will improve.

219. Need to develop trust
in the process.

220. We need robust pipelines.

221. Concourse, Circle CI, Travis CI,
Visual Studio Team Services, Jenkins.

222. Not sure how to create a pipeline?

223. Spring Cloud Pipelines.
https://spring.io/blog/2018/11/13/spring-cloud-
pipelines-to-cloud-pipelines-migration

224. Opinionated build/
test/stage/prod
fl
ow.

225. Gives you a place to start -
modify to your hearts content.

226. Independent life cycles very
under appreciated bene
fi
t.

227. “That’s how we’ve always done it”
won’t cut it anymore.

228. Scale Independently

229. The monolith forced us to
make decisions early.

230. Often when we knew the least.

231. For example - how much
capacity will you need?

232. ¯_(ツ)_/¯

233. Take worst case…double it…add
some buffer. Then a bit more.

234. Just in case.

235. We have a six week (aka month)
lead time on all requests.

236. Lots of tickets.

237. And meetings.

238. And email.

239. And followup.

240. It was in our best interest to
over allocate resources.

241. Better to have it and not need it…

242. Dif
fi
cult to add more capacity later.

243. Gave us single digit
resource utilization.

244. “Our traf
fi
c is predictable.”

245. “Our traf
fi
c is predictable.”

246. Of course not all traf
fi
c is
predictable is it?

247. Matters were much worse if we
had unexpected demand.

248. We can plan for a big new initiative.

249. But a shout out on social media
might double our traf
fi
c in minutes.

250. Things were no easier for
our operations staff.

251. Annual budgets make it dif
fi
cult
to add capacity smoothly.

252. Cloud environments and
microservices
fl
ip the script.

253. Today we can add, and remove,
capacity on demand.

254. We can wait for the last
responsible moment.

255. Instead of swags and guesses.

256. Not surprisingly, the monolith
suffered from the same issue.

257. There was no way to scale “just
the parts that needed it”.

258. It was all or nothing.

259. Which again, meant we were
often heavily over allocated.

260. Harkening back to the
Widget.io example…

261. Odds are the order processing
system has a unique scaling needs.

262. Widget.io Monolith
Cart Inventory
Account
Administration
Recommendation
Engine
Microservice
Search
Microservice
Order Processing
Microservice
Order Processing
Microservice
Order Processing
Microservice
Project X
Microservice

263. With a microservices approach,
we can fully utilize compute.

264. But, how do we know which
components need more capacity?

265. Monitoring to the rescue!

266. Monitoring is vital to a thriving
microservices architecture.

267. https://landing.google.com/sre/book.html

268. Four Golden Signals.
https://landing.google.com/sre/book/chapters/monitoring-
distributed-systems.html#xref_monitoring_golden-signals

269. Latency - how long does it take
to service a request.

270. Traf
fi
c - level of demand on the
system. Requests/second. I/O rate.

271. Errors - failed requests. Can be
explicit, implicit or policy failure.

272. Saturation - how much of a
constrained resource is left.

273. Important to consider the
sampling frequency.

274. High resolution can be costly.

275. Aggregate data.

276. Number of tools from Wavefront
to Dynatrace to New Relic.

277. Spring Boot Actuator!
https://docs.spring.io/spring-boot/docs/current/
reference/html/production-ready-metrics.html

279. Takes time to get monitoring right.

280. Do you even SRE?

281. Beware the metric that is
easy to measure…

282. Might not be meaningful. Sorry.

283. Also key to understand
the business drivers.

284. What could cause a
spike in demand?

285. How does that translate
to speci
fi
c services?

286. Be realistic!

287. We can’t all be a third
of internet traf
fi
c!

288. Independent scalability is a
massive win. If you need it!

289. Failure isolation

290. No service is an island.

291. –Obi-Wan Kenobi
“You've taken your
fi
rst step
into a larger world.”
https://www.youtube.com/watch?v=535Zy_rf4NU

292. No microservice works alone.

293. Name implies as much!

294. Integrations are as old as software.

295. Often use bailing
twine and duct tape…

297. Sometimes those 3rd party
dependencies don’t meet our SLO.

298. They fail.

299. Failures, uh
fi
nd a way.

300. Our customers don’t care why.

301. We can use microservices to
isolate those failure cases!

302. You might already know where
the problem code lives.

303. But don’t be afraid to perform
an architectural review.

304. Look for failure points.

305. Draw up the architecture.

306. What happens if *this* fails?

307. It can’t fail? Yeah it can -
what happens if it does?

308. Think through how our
service could fail.

309. “When month end falls on the
Super Blue Blood Moon.”

310. It is hard. We are really good at
thinking through the happy path.

311. But we need to think about
the road less traveled.

312. What systems does our service
talk to? How do they integrate?

313. Is it a direct call? Through a proxy?

314. What are the SLOs?

315. Do we all have a shared
understanding of what the app?

316. There will be gaps in knowledge.

317. Feature not a bug.

318. We now understand the failure
cases, what do we do about it?

319. How should we react?

320. Error message?

321. Call a backup service?

322. Do we need to cache data?

323. Do we return a default answer?

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

325. The circuit breaker pattern.
https://martinfowler.com/bliki/CircuitBreaker.html

326. Originally described by
Michael Nygard.

327. Closed
on call / pass through
call succeeds / reset count
call fails / count failure
threshold reached / trip
breaker
Half-Open
on call / pass through
call succeeds / reset
call fails / trip breaker
Open
on call / fail
on timeout / attempt reset
trip
breaker
reset
trip
breaker

328. Circuit breaker watches the calls.

329. Once they exceed a failure
threshold, the circuit is opened.

330. Redirects to the
fallback mechanism.

331. Periodically checks to see if the
service is repaired.

332. If so, circuit is closed.

333. You won’t think of everything.

334. https://github.com/Net
fl
ix/SimianArmy

335. Chaos engineering.
http://principlesofchaos.org

336. Indirection layer

337. As an architect there is
one pattern I use often.

338. Another layer of indirection.

339. Sometimes it is overkill.

340. When was the last time you
swapped out your database?

341. OK, it happens…

342. Same basic concept as failure
isolation. With a twist.

343. Now we protect our service
from things that change.

344. Or things that are complex to use.

345. Could be a vendor dependency.

346. Could be something large
like an ERP system.

347. Or maybe just a library for
currency conversion.

348. An indirection layer isolates the
things we need to change.

349. If we have to swap something out,
we don’t update every client.

350. Basic proxy pattern.

351. Can also be an
instance of an adaptor.

352. Make this US plug
fi
t into
an EU outlet for example.

353. We can also use it to
simplify the interaction.

354. Many 3rd party dependencies
solve a lot of problems.

355. Many of which may
not matter to us.

356. Our microservice can facade
that interaction. Simplify it.

357. Nothing new here - classic
Gang of Four pattern!

358. These facades can also
supply context.

359. Maybe a payment gateway
needs your CHQ address.

360. Or you need an
authorization token.

361. That won’t change call to call.

362. Don’t want to code it
into every client.

363. The facade is a natural spot
for such functionality.

364. Maybe we want to inject some
behavior before or after calls.

365. A indirection layer provides
a natural extension point.

366. Architecture is often de
fi
ned as the
decisions that are hard to change.

367. Or the decisions we
wish we got right.

368. But we *know* things will change!

369. Isn’t this approach anti agile?

370. Contributes to the “we’re agile, we
don’t have architects” theory.

371. You de
fi
nitely have people
making architectural decisions!

372. Sure hope they are
making good ones…

373. You’ll know in a year or two.

374. “Our app has 4 different
UI frameworks…”

375. 🤔

376. What do we do about that?

377. Maybe we should
change our assumptions.

378. What if our architectures
expected to change?

379. http://evolutionaryarchitecture.com

380. – Building Evolutionary Architectures
“An evolutionary architecture supports
guided, incremental change across
multiple dimensions.”

381. Microservices can provide
additional
fl
exibility.

382. polyglot tech stacks

383. Monoliths forced us to
standardize on a toolkit.

384. Many organizations described
themselves by their stack.

385. As in “we’re a Java/Ruby/.NET shop”

387. Bring me a problem!

388. There are positives to
this approach.

389. Teams develop deep expertise.

390. People can shift teams to cross
pollinate and balance workloads.

391. Simpli
fi
es the hiring and
training processes.

392. Ops can focus on the
primary environment.

393. But one size doesn’t
fi
t all.

394. There are, of course, downsides.

395. Currency is usually constrained
by the slowest moving app.

396. You can’t have nice things
because of the Wombat app.

397. When we did upgrade, odds
are it would take months.

398. And the “new” version would
already be outdated.

399. Of course very few orgs were
really that homogenous.

400. A merger or acquisition ===
another tech stack.

401. Cloud computing removes the one
stack to rule them all constraint.

402. We actually can spin up
multiple different stacks.

403. Polyglot programming isn’t just
a pipe dream anymore!
http://nealford.com/memeagora/2006/12/05/Polyglot_Programming.html

405. Pick the right tool for the job!

406. We aren’t forced down the
square peg round hole path.

407. But.

408. There is always a but.

409. We have to avoid tech sprawl.

410. It’s great right? Each team can use
just the right tool for the job!

411. Every developer will have their
favorite tools, languages, etc.

412. Teams will have their pipeline
preferences, meaningful metrics…

413. Leads to an awful lot of
ways to do a given thing.

414. How do we staff up? Go, Haskell,
Java, .NET, C++, Ruby, Python?

415. How many libraries will we
need to support all of that?

416. Can we stay current?

422. It cannot be a free for all.

423. You will need some guardrails.

424. “Use any language as long
as it runs on the JVM.”

425. Pick from these 3
fl
avors. Won’t
work for you? Let’s talk.

426. Focus on “paved roads.”

428. Here is a well worn path, we
know it works, we support it.

430. You build it, you own it.

431. Sprawl tends to exacerbate our
accumulation of technical debt.

432. The key word here is micro.

433. As in small.

434. We can debate the meaning of
small until the cows come home.

435. Partial to “anything we can
rewrite in 2 weeks or less”.

436. If we chose poorly - we lost
two weeks. An iteration.

437. We can recover from that.

438. More time === more invested.

439. Makes us less likely to change
course. Even if we should.

440. Microservices frees us to
choose the right tech!

441. https://twitter.com/mstine/status/1326916377740005378

442. But we must weigh
the pros and cons.

443. “With great power comes
great responsibility.”
–Uncle Ben

444. You build it, you run it.

445. Avoid the temptation of
resume driven design.

446. Microservices really do offer
some impressive bene
fi
ts.

447. But they come at a price.

448. Don’t pay the complexity tax unless
you get something in return.

449. In other words, no, not everything
should be a microservice!

450. Use them were they make sense.

451. Use them where they add value.

452. If you need one (or more) of the
principles, go forth and prosper!

453. If not…well, there’s
always serverless.

454. 😬

455. Good luck!

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

457. Between Chair and Keyboard
Nate Schutta
Software Architect
VMware
@ntschutta
Most Mondays,
around noon Central
https://www.twitch.tv/vmwaretanzu