Microservices In a Legacy
Environment
Principles & Examples
Slide 2
Slide 2 text
David Julia
@DavidJulia
[email protected]
Associate Director
Pivotal Labs Chicago
Slide 3
Slide 3 text
What’s this talk about!?
Slide 4
Slide 4 text
Move fast and break things!
Slide 5
Slide 5 text
Move fast and break things!
Fine for startups &
innovation projects with a
small customer base
Slide 6
Slide 6 text
For established products,
Move fast, and don’t break
anything!
Slide 7
Slide 7 text
IT Agility
Organizational Change
Team Structure
Roles Incentives
Technical Change
Development Process
Change as a first class
citizen in designs
Implies
changes
Slide 8
Slide 8 text
In a Microservices Architecture
Services are cheap and fast to deploy
and change independently.
Slide 9
Slide 9 text
We have the tools
Simple and cheap to
spin up a new
microservice!
Autoconfiguration for
standard boilerplate
config
Slide 10
Slide 10 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 11
Slide 11 text
Many legacy
Systems live
here
“unknown
unknowns”
Slide 12
Slide 12 text
Oftentimes, you must treat the legacy
system as a black box with unknown
unknowns.
Slide 13
Slide 13 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 14
Slide 14 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 15
Slide 15 text
Appcontinuum.io
Evolving Components & Services
Slide 16
Slide 16 text
How do I break them out safely?
Slide 17
Slide 17 text
No content
Slide 18
Slide 18 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 19
Slide 19 text
Succession Patterns
let’s talk about a few
Slide 20
Slide 20 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 21
Slide 21 text
An example:
Large fast food restaurant chain
writing a mobile app
Replace rewards points vendor with their
own system
Slide 22
Slide 22 text
● Cut cost
● Show reward points on iOS app
● Set ourselves up to add new features
Motivation
Slide 23
Slide 23 text
Different approaches
● Total rewrite of a component known domain or can redefine business rules
● Extract jar and sense/compare, then extract service
● Direct service extraction with sense/compare
● Extract and pray!
Slide 24
Slide 24 text
First, let’s tackle viewing
current rewards point
balance on iOS
Slide 25
Slide 25 text
Let’s look at our systems!
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
Let’s look at our Ball of Mud
POS!
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 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 30
Slide 30 text
Sprout Method & Sprout Class
Sprouting = extracting new
behavior to a new method or
class.
Slide 31
Slide 31 text
No content
Slide 32
Slide 32 text
And now sprout component
(jar)
Slide 33
Slide 33 text
No content
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
But is it safe?
i.e. “Does it match the website’s balance?”
Slide 36
Slide 36 text
Remember that web
interface?
...Record any Δ’s
as bugs, and fix them.
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
We’re liking what we’re
seeing… No Δ’s
Slide 40
Slide 40 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 41
Slide 41 text
Now Let’s extract a service!
Slide 42
Slide 42 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 43
Slide 43 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 44
Slide 44 text
No content
Slide 45
Slide 45 text
Finally,
add a mobile API Gateway
and iOS app!
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 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 omitted splitting out the data
Slide 48
Slide 48 text
How do we evaluate our solution?
● Reusability
● Improved value stream
○ Cost of smallest change
● Reduced risk of change
Slide 49
Slide 49 text
Other Examples
● Insurance Quoting engine - one LOB, one kind of insurance
● Cost estimation tool rewrite
○ 1000’s of unit tests
○ Captures real requests/responses in prod
○ Compares to legacy app
○ Compares to previous version of new microservice
changes manually approved in CI pipeline
Slide 50
Slide 50 text
Thanks!
...Questions?
Slide 51
Slide 51 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