Microservices in a Legacy Environment

Principles and examples to help you reduce tech debt and enable new feature development, with microservices when you've got a whole lot of legacy applications.

Transcript

1. Microservices In a Legacy Environment Principles & examples to help you reduce tech debt with microservices
2. David Julia @DavidJulia djulia@pivotal.io Associate Director Pivotal Labs Chicago
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 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. An example: Large fast food restaurant chain writing a mobile app Replace rewards points vendor with their own system
15. • Cut cost • Show reward points on iOS app • Set ourselves up to add new features Motivation
16. First, let’s tackle viewing current rewards point balance on iOS
17. Let’s look at our systems!
19. Let’s look at our Ball of Mud POS!
21. 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.
22. Sprout Method & Sprout Class Sprouting = extracting new behavior to a new method or class.
24. And now sprout component (jar)
27. But is it safe? i.e. “Does it match the website’s balance?”
28. Remember that web interface? ...Record any Δ’s as bugs, and fix them.
31. We’re liking what we’re seeing… No Δ’s
32. “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 :)
33. Now Let’s extract a service!
34. 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
35. 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
37. Finally, add a mobile API Gateway and iOS app!
39. 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 ;)
40. Thanks! ...Questions?
41. 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