1. Microservices In a Legacy
Environment
Principles & Examples

2. David Julia
@DavidJulia
djulia@pivotal.io
Associate Director

3. In a Microservices Architecture
Services are cheap and fast to deploy
and change independently.

4. Spring Boot
Simple and cheap to
spin up a new
microservice!
Autoconfiguration for
standard boilerplate
config

5. Legacy Environment:
An environment wherein many systems
that are hard to change
are in dire need of replacement or
augmentation to meet business
demands.

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

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

8. Appcontinuum.io (thanks Mike Barinek)!
Evolving Components & Services

9. How do I break them out safely?

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

12. Succession Patterns
let’s talk about a few

13. Strangler Application
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

14. Characterization tests - a vice

15. An example:
Large fast food restaurant chain
writing a mobile app
Replace rewards points vendor with their
own system

16. Cut cost
Show reward points on iOS app
Set ourselves up to add new features
Motivation

17. First, let’s tackle viewing
current rewards point
balance on iOS

18. Let’s look at our systems!

20. Let’s look at part of our Ball
of Mud POS!

22. What’s the plan?
● Identify behavior we need.
● “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.

23. Sprout Method & Sprout Class
Sprouting = extracting new behavior
to a new method or class.
Can then add tests/new behavior

25. And now sprout component
(jar)

28. But is it safe?
i.e. “Does it match the website’s balance?”

29. Remember that web interface?
it’s a test oracle!…Record any Δ’s
as bugs, and fix them.

32. We’re liking what we’re
seeing… No Δ’s

33. “That diff 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 :)
*level of caution can be adjusted to your risk profile

34. Now Let’s extract a service!

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

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

38. Finally,
add a mobile API Gateway
and iOS app!

40. 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 (strangler application)
Did all of this safely and with high confidence

41. Next Steps
• Continue to move rewards-specific behavior to our service
• Could refactor the web GUI to use our new service

42. Thanks!
...Questions?

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