SpringOne Platform 2016
Speaker: David Julia; Associate Director, Pivotal
Building Microservices in a green field environment is amazing! But the realities of some of our largest and oldest institutions is that there is a lot of value in existing legacy systems. When you're building on top of legacy systems, there are many challenges that green field development does not even have to consider. Join me for a 30 minute session in which we look at some patterns that we have employed over the last 2 years of building Spring Boot based microservices in the context of legacy systems. I'll speak to tried and true strategies for creating "strangler applications", strategies for moving away from the database as an integration point, and how to start carving off bounded contexts for your new microservices. I'll also speak to a handful of pit-falls to be avoided as you make the journey to a bootiful microservice landscape.
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
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
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
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
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
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
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