The so called "Strangler Fig" (aka "Strangler") pattern is a much cited strategy for replacing legacy systems with new, often microservice-based architectures. However, it's not actually a microservice pattern, and there are several - quite different - ways to implement it. Are you confused yet? Fear not: We will have a look at the theory, and then explore together, how Strangler Fig could be used to improve and replace a project worthy being called "The Most Horrible Piece Of Code in the World".

1. 1
Choking the Monolith
The Strangler Pattern Applied
Legacy of SoCraTes, April 1, 2020
Tobias Goeschel @w3ltraumpirat
John Tann from Sydney, Australia / CC BY (https://creativecommons.org/licenses/by/2.0)

2. 2
Choking the Monolith
The Strangler Pattern Applied
Legacy of SoCraTes, April 1, 2020
Tobias Goeschel @w3ltraumpirat
John Tann from Sydney, Australia / CC BY (https://creativecommons.org/licenses/by/2.0)
fig
V

3. 3
John Tann from Sydney, Australia / CC BY (https://creativecommons.org/licenses/by/2.0)
Martin Fowler (2004):
StranglerFigApplication
•Incremental, piece-by-piece
replacement of a larger legacy
system.
•NOT a microservices pattern

4. 4
John Tann from Sydney, Australia / CC BY (https://creativecommons.org/licenses/by/2.0)
Our Agenda:
•Context
•Problem
•Implementation
•Consequences
•Related Patterns
…and what might happen IRL

5. 5
Legacy Code
•Code inherited from someone else
•Code that is unsafe to change
•Code without tests (Michael Feathers)
•“All code, as soon as it’s written”

6. 6
Legacy Code
•Usually code that works
•Contains vast amounts of knowledge
•“The code that earns our money”

7. 7
Almonroth / CC BY-SA (https://creativecommons.org/licenses/by-sa/3.0)
The system needs replacement
•Paradigm shifts / business changes
•Compliance
•Inability to scale
•Cost-effectiveness
•Obsolete platform
•Hard to find developers
•Tools outdated
•Parts of system available as a product /
commodity
•Code has become unmaintainable

8. 8
John Tann from Sydney, Australia / CC BY (https://creativecommons.org/licenses/by/2.0)
Our Agenda:
•Context
•Problem
•Implementation
•Consequences
•Related Patterns
…and what might happen IRL

9. 9
© Frank Schulenburg / CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0/)
Hard to replace:
•Runs vital parts of infrastructure
•Original creators no longer around
•We will likely make many of the same mistakes
(again)
•Replacement will take a long time
•We can’t introduce new features
•Old and new version maintained in parallel
•Production data can only be transformed once

10. 10
John Tann from Sydney, Australia / CC BY (https://creativecommons.org/licenses/by/2.0)
Our Agenda:
•Context
•Problem
•Implementation
•Consequences
•Related Patterns
…and what might happen IRL

11. 11
Legacy System

12. 12
Mixed System

13. 13
Mixed System

14. 14
Mixed System

15. 15
Mixed System

16. 16
Mixed System

17. 17
Mixed System

18. 18
Mixed System

19. 19
Mixed System

20. New System

21. Solution #1: Request Interception (Façade/Proxy)
I II III IV V

22. Solution #1: Request Interception (rev2) (Façade/Proxy)
« Facade » « Facade » « Facade » « Facade »
I II III IV V

23. Solution #2: Event Interception (Message Bus / Queue)
I II III IV V

24. 24
John Tann from Sydney, Australia / CC BY (https://creativecommons.org/licenses/by/2.0)
Our Agenda:
•Context
•Problem
•Implementation
•Consequences
•Related Patterns
…and what might happen IRL

25. 25
Nick Youngson CC BY-SA 3.0 Alpha Stock Images
Benefits over “big bang” rewrite:
•Vital business can run with the least amount of
downtime
•More frequent releases
•Much earlier ROI on new code
•Shorter feedback cycles
•More fine-grained options, more often:
•Some parts of the old system can be left
unchanged / omitted
•New features possible
•Data duplication (vs transformation) allows
experiments

26. 26
Drawbacks:
•Possibly long time of running systems in parallel
•Both systems incur maintenance cost
•Political dismay
•Migration / synchronisation of legacy data may
become a problem

27. 27
John Tann from Sydney, Australia / CC BY (https://creativecommons.org/licenses/by/2.0)
Our Agenda:
•Context
•Problem
•Implementation
•Consequences
•Related Patterns
…and what might happen IRL

28. 28
Related patterns:
•Proxy / Facade (GoF)
•Event Interception (Martin Fowler)
•Asset Capture (Martin Fowler)
•Group changes by “entity”
(or rather, domain object)
➡ Domain Driven Design!
Schnobby / CC BY-SA (https://creativecommons.org/licenses/by-sa/3.0)

29. 29
John Tann from Sydney, Australia / CC BY (https://creativecommons.org/licenses/by/2.0)
Our Agenda:
•Context
•Problem
•Implementation
•Consequences
•Related Patterns
…and what might happen IRL

30. 30

31. 31
Bernard DUPONT from FRANCE / CC BY-SA (https://creativecommons.org/licenses/by-sa/2.0)
When the rubber hits the road:
•New features usually more important than
transformation of old bits
➡ Strong focus on replacing legacy system is key
•Who decides what’s worth keeping?

32. 32
Graham Horn / CC BY-SA (https://creativecommons.org/licenses/by-sa/2.0)
When the rubber hits the road:
•Code issues:
•No well-defined interfaces in place
•Code entangled / hard to change
•Knowledge of old system is lost / hard to find
•Documentation outdated / missing
•People have left the company
•Misleading names
•Misused / badly implemented design patterns

33. 33
Chadica from Jerusalem, Israel / CC BY (https://creativecommons.org/licenses/by/2.0)
When the rubber hits the road:
•Code issues:
•Hidden / obscured logic in
•Frontend
•Stored procedures
•Dirty hacks
•These are all common for legacy code

34. 34
Zach Dischner / CC BY (https://creativecommons.org/licenses/by/2.0)
When the rubber hits the road:
•Use helpful / well-known patterns to enable
strangulation:
•Seam (Michael Feathers)
•Walking Skeleton (Alistair Cockburn)
•Hexagonal Architecture (Alistair Cockburn)
•Branch by Abstraction (Jez Humble)

35. 35
…and now: The Most Horrible Code in the World

36. 36
SomeCms

37. 37
•CMS
•Multi-tenancy
•Several million € revenue
•“histerically grown” since the 1990s
•GWT / Vaadin / Java 8 / Tomcat / MySQL / Gradle
•CMS with edit/publish/versioning
•Uses JSP as template format
•Virtual file system
•Module expansion system
SomeCms

38. 38
•Monorepo
•Gradle build runs ca. 25 min.
(of which, 23 min. is the test suite)
•“Unit tests” that aren’t
•All tests are integrated tests
•A stripped down, but functional instance of the
CMS is injected into the test cases
•Test suite only runs as a whole
SomeCms

39. 39
•Needs running instance for … well, everything
•No well-defined API
•Mixes Java / HTML / javascript output and
functionality
•Makes extensive use of filters / HTTP request/
response manipulation
•Method names are obscure (“export”,
“processRequest”, …)
•Brings its own thread logic, resource locking
•Classpath issues
•“Event Manager” for batch processes
SomeCms

40. 40
•Also rolls its own:
•Auth/Permission logic and session handling
•JSON serialization
•Mail server
•Command shell
•Hungarian Notation
•Everything is static, or final, or both
SomeCms

41. 41
SomeCms
?

42. 42
SomeCms
•Some ideas:
•Publishing moves things from a to b. That could
become a service.
•Publishing could render static HTML
•HTTP filters can be used for interception, forward
some requests selectively
•Perhaps some functionality can be extracted as is,
keep using same DB for synchronization
•Permissions handling is tricky - switching from
sessions to web tokens might be a first step
•Finding ways to modularize and speed up the test
suite is essential

43. codecentric AG
Kreuznacher Str. 30
60846 Frankfurt / Germany
Telefon: +49 (0) 151.14965469
Tobias Goeschel
Principal Consultant
tobias.goeschel@codecentric.de
www.codecentric.de
Innovative - Trustful - Competent - Pragmatic
43