Unlocking Features with Microservices in a Legacy Environment

Longer form talk given at SpringOne 2016 about how to unlock valuable functionality that's "stuck" in a legacy app.

Transcript

1. Microservices In a Legacy Environment Principles & Examples
2. David Julia @DavidJulia djulia@pivotal.io Associate Director Pivotal Labs Chicago
3. What’s this talk about!?
4. Move fast and break things!
5. Move fast and break things! Fine for startups & innovation projects with a small customer base
6. For established products, Move fast, and don’t break anything!
7. IT Agility Organizational Change Team Structure Roles Incentives Technical Change Development Process Change as a first class citizen in designs Implies changes
8. In a Microservices Architecture Services are cheap and fast to deploy and change independently.
9. We have the tools Simple and cheap to spin up a new microservice! Autoconfiguration for standard boilerplate config
10. Legacy Environment: An environment wherein many systems that are hard to change are in dire need of replacement or augmentation to meet business demands.
11. Many legacy Systems live here “unknown unknowns”
12. Oftentimes, you must treat the legacy system as a black box with unknown unknowns.
13. 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.
14. 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
15. Appcontinuum.io Evolving Components & Services
16. How do I break them out safely?
18. 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
19. Succession Patterns let’s talk about a few
20. 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
21. An example: Large fast food restaurant chain writing a mobile app Replace rewards points vendor with their own system
22. • Cut cost • Show reward points on iOS app • Set ourselves up to add new features Motivation
23. 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!
24. First, let’s tackle viewing current rewards point balance on iOS
25. Let’s look at our systems!
27. Let’s look at our Ball of Mud POS!
29. 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.
30. Sprout Method & Sprout Class Sprouting = extracting new behavior to a new method or class.
32. And now sprout component (jar)
35. But is it safe? i.e. “Does it match the website’s balance?”
36. Remember that web interface? ...Record any Δ’s as bugs, and fix them.
39. We’re liking what we’re seeing… No Δ’s
40. “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 :)
41. Now Let’s extract a service!
42. 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
43. 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
45. Finally, add a mobile API Gateway and iOS app!
47. 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
48. How do we evaluate our solution? • Reusability • Improved value stream ◦ Cost of smallest change • Reduced risk of change
49. 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
50. Thanks! ...Questions?
51. 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