Microservices In a Legacy
Environment
Principles & examples to help you reduce tech
debt with microservices
Slide 2
Slide 2 text
David Julia
@DavidJulia
[email protected]
Associate Director
Pivotal Labs Chicago
Slide 3
Slide 3 text
In a Microservices Architecture
Services are cheap and fast to deploy
and change independently.
Slide 4
Slide 4 text
Spring Boot
Simple and cheap to
spin up a new
microservice!
Autoconfiguration for
standard boilerplate
config
Slide 5
Slide 5 text
Legacy Environment:
An environment wherein many systems
that are hard to change
are in dire need of replacement or
augmentation to meet business
demands.
Slide 6
Slide 6 text
This talk is for Developers.
I want to show you how to get to
microservices when you’re starting with a
Big Ball of Mud.
Slide 7
Slide 7 text
The Importance of DDD in Legacy Environments
● Don’t couple your
domain model to
your legacy
systems’ models
● Represent the
latest business
processes in
code
Slide 8
Slide 8 text
Appcontinuum.io (thanks Mike Barinek)!
Evolving Components & Services
Slide 9
Slide 9 text
How do I break them out safely?
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
Succession
/səkˈseSHən/
Noun
The art of taking a single conceptual change, breaking it into
safe steps, and then finding an order for those steps that
optimizes safety, feedback, and efficiency
Slide 12
Slide 12 text
Succession Patterns
let’s talk about a few
Slide 13
Slide 13 text
Strangler Pattern
Gradually create a new system around the edges of the old,
letting it grow slowly over several years until the old system is
strangled
Slide 14
Slide 14 text
An example:
Large fast food restaurant chain
writing a mobile app
Replace rewards points vendor with their
own system
Slide 15
Slide 15 text
● Cut cost
● Show reward points on iOS app
● Set ourselves up to add new features
Motivation
Slide 16
Slide 16 text
First, let’s tackle viewing
current rewards point
balance on iOS
Slide 17
Slide 17 text
Let’s look at our systems!
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
Let’s look at our Ball of Mud
POS!
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
What’s the plan?
● “Sprout” a new class to hold the behavior we want
● Start moving behavior into that class
● Extract a component (JAR) and break dependencies
Could stop here and use the library in our mobile API gateway.
Or continue on and extract a service.
Slide 22
Slide 22 text
Sprout Method & Sprout Class
Sprouting = extracting new
behavior to a new method or
class.
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
And now sprout component
(jar)
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
But is it safe?
i.e. “Does it match the website’s balance?”
Slide 28
Slide 28 text
Remember that web
interface?
...Record any Δ’s
as bugs, and fix them.
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
We’re liking what we’re
seeing… No Δ’s
Slide 32
Slide 32 text
“That differ thing won’t work for me!”
● “I have mutating operations (edits/deletes)!”
Same basic strategy, one modification:
Noop in your new service implementation
Log what you “would have done”
● This is just one example of succession.
Creativity is often required :)
Slide 33
Slide 33 text
Now Let’s extract a service!
Slide 34
Slide 34 text
But first… A note on premature extraction
● Extracting a service too early can be costly
● It’s easier to refactor the system with an in-process component
● Easier to change your abstractions (interface changes)
● Only have to change things in one place
Slide 35
Slide 35 text
Extract a service!
Let’s say we want a separate service**
● Extract a service, implement a remote façade at the seam we created
● Point iOS application API Gateway at the service
● Celebrate!
**for more info on when to extract a microservice vs stay with shared libraries, see
Mike Gehard’s talk
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
Finally,
add a mobile API Gateway
and iOS app!
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
What did we just see
● Started with a ball of mud
● Identified/Extracted behavior into new classes
● Packaged classes as JAR
● Created a new service
● Did all of this safely and with high confidence
● Conveniently left the complex topic of splitting out the data for a future talk ;)
Slide 40
Slide 40 text
Thanks!
...Questions?
Slide 41
Slide 41 text
Appendix/Links
Mike Barinek’s appcontinuum.io
Simon Brown on Modular Monoliths
http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths
Mike Gehard on Microservices
https://vimeo.com/album/4045988/video/172421431
Working Effectively With Legacy Code by Michael Feathers