Killing a giant A practical guide through the Martin Fowler’s Strangler Fig pattern 

Hi, I’m Branislav family guy heavily accented director of engineering at 

We eliminate the complexity of the infrastructure to increase developer productivity and accelerate time to market 

Developers bring their code, we bring the rest Platform.sh offers a unified, secure, enterprise-grade platform for building, running and scaling responsibly fleets of websites and applications. 

Reliable laaS + Platform.sh PaaS relies on leading public Cloud providers. They all benefit from the highest possible global security standards (ISO, AICPA, PCI-DSS, CSA, …) SOC-2 certified PaaS solution + SOC 2 describes the controls specifically associated with security and privacy. It is a compliance standard for cloud-based services Compatible GPDR + We consider data protection as a priority. Thus, our policies are strongly based on the relevant laws of the country concerned (GDPR, PIPEDA, BDSG, …). End to end security 

Killing a giant A practical guide through the Martin Fowler’s Strangler Fig pattern 

The genesis of a monolith Billing Subscription management Payments Dunning User management Oauth2 server Support ticket management UX Identity provider Trials Reporting (BI) Use a CMS to reduce the early risk. Extend the existing code base to support a rapidly growing startup. One app to monitor and maintain — easier debugging and less ops work. 

Design stamina hypothesis “Is it worth the effort to design software well?” - Martin Fowler 2007 

The CMS becomes a huge source of technical debt over the years because: + Abuse of the archaic design patterns (code massage). + Uncontrollable changes of the state. + Mutually dependent code (circular dependencies!!!), contrib/custom code hell, patches... + Configuration, content and code, managed inconsistently in code or in databases; difficult revisioning etc. + Infrastructure stuck at the old version of PHP. Technical debt 

A cunning plan: microservices Billing Subscription management Payments Dunning User management Oauth2 server Support ticket management UX Identity provider Trials Reporting (BI) 

Replacing a huge legacy system may be problematic… + Designing a system from the ground up in a holistic way is ridiculously complicated + The data is too complex to be transformed and migrated in a single act + There is a lot of risk in releasing overwhelming changes in a big bang! + A down time must be avoided at all costs 

Martin Fowler’s Strangler Fig Application design pattern 

A way to manage risk when modernizing or rewriting a large, monolithic system. 

No content

[...] gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled. Martin Fowler, 2004 

Phases of the Strangler Application Transform Create a new site Eliminate Remove functionality from the old site. Phase 1: Phase 2: Phase 3: Coexist Leave the existing site. As a new feature was built, redirect to the new site. 

Phase 1: Transform The Proxy The New Service /feature/(.*) The Legacy App /(.*) + First create a proxy between the application and the users. The proxy does not do anything other than passing all the traffic to the application. + Start building the replacement application in the background. Ensure it looks and behaves the same as the legacy application. RewriteEngine On # Serve feature from new service for internal network RewriteCond expr “%{HTTP:X-FORWARDED-FOR} -ipmatch ‘192.168.0.1/24’” RewriteRule ^/feature/(.*)$ ${NEW_SERVICE_URL}/$1 [P,L] # Proxy everything else to legacy application RewriteRule ^/(.*) ${LEGACY_URL}/$1 [P] ProxyPassReverse / ${LEGACY_URL}/ 

Phase 2: Coexist + Proxy requests to the new service as soon as it’s done. + Serve the rest from the legacy application. + Start building another replacement application in the background. The Newer Service /other-feature/(.*) The Proxy The New Service /feature/(.*) The Legacy App /(.*) 

Phase 3: Eliminate + After all the features have been built in the replacement application(s), the legacy app serves no more traffic. + Switch off the legacy app. The Proxy The Legacy App /(.*) The Newer Service /other-feature/(.*) The Proxy The New Service /feature/(.*) The Legacy App Orphaned service The Last Service /last-feature/(.*) … 

The Pattern Allows Shorter Iterations Build a service …and another service Phase 1: Phase 2: Phase 3: Phase 4: Create the new service Add a proxy Build another service Proxy to the new service Iterate until perfect Clean up the monolith …and another Phase 4: 

Strengths ● True zero downtime ● Reduced risk of failures due to frequent small releases ● Faster delivery of the value for customers ● Lesser cognitive load for the engineering team 

Opportunities ● Data driven refactoring + The proxy is a central place to collect the customer requests, log them and allow their analysis to enable prioritization of the refactoring, as well as fixing broken user experience. ● Decoupled frontend + Deciding for the proxy to be exclusively an API proxy allows the frontend engineering team to grow independently; to centralize the API documentation; and provides immediate value to the customers. ● Mutually independent teams and choice of the best tool for the job + Microservices allow using different technologies inside each one, thus avoiding the one-size-fits-all approach and allowing parallelization of the work. 

The result is beautiful and it makes Total Sense™ Billing Subscription management User management Support ticket management UX Trials Reporting (BI) API Proxy + Single unified UX for great customer experience. + API proxy capable of load balancing if needed. + Segregated services, each with own tech stack and engineering team. 

No content

Weaknesses and Threats (the W’s and T’s in SWOT) 

User data migration 2h Weakness: data migration Legacy App The Proxy Auth Service Problem: Inconsistent state during the migration. Where to proxy the traffic? Solution: Close for maintenance — Problem: Long downtime Solution: Data migration strategy which does the most of the work in background — Problem: Rollback strategy in case of failure? Solution: Snapshots Solution: Synchronization back to Legacy App? 

Weakness: shared state Legacy App The Proxy Auth Service Subscription mgmt User management Billing A customer Company Name Address Tax ID Email An owner An ID Address country A user Email Password Address country An ID Problem: Services will be relying on the same data! How to synchronize it between them? Solution: Use the existing restful APIs to GET and PATCH when needed Keeping services in sync… 

Weakness: shared state Billing Subscription management User management Support ticket management Trials Reporting (BI) Problem: Lots of point to point API communication that bring to tight coupling. Solution: Message broker — Problem: Problem of deletion of an entity in a service that then needs to notify all the other services of it. Solution: Tombstones Solution: Message broker — Problem: Message brokers also need engineering – both for development and maintenance 

Threat: fragmentation of entity data Problem: “Store only what you will use” Problem: Business intelligence depends on reports SELECT * FROM users WHERE uid = 123 Solution: Data lake (e.g. fivetran + big query) Solution: Event sourcing? Solution: Consider business when designing new entities The single User entity from monolith now broken down Legacy App The Proxy Auth Service Subscription mgmt User management An owner Billing A customer A user Company Name Address Tax ID Email An ID Email Password Address country An ID Address country 

Threat: a new feature Legacy App The Proxy Subscription mgmt Billing Subscription management Usage records WIP ? Things to consider when deciding where to build a newly requested feature: + The state of the WIP service and the minimal change necessary to make the new feature + The size of the new feature and the amount of engineering debt that would be created if implemented in the legacy application + The urgency of the new feature New product line 

Threat: keeping backward compatibility (At Any Cost™) POST /provision POST /orgs/{id}/provision POST /provision The Proxy Legacy App Subscription management GET /orgs if org # = 0: POST /orgs if org # > 1: Throw Exception Provision project POST /orgs/{id}/stopgap-api 

Other weaknesses and threats ● Heavy on engineering resources + Maintenance overhead for each service + Engineers specialize + Silos within the team + Tiring joggling between building new and rebuilding old features ● Requires real good monitoring + Health of the each of the services + X-service debugging ● Fundamental changes break processes in other teams + CSEs, TAMs, even sales need to be onboarded + Major overhaul of internal and external documentation 

Paradoxically, the strangled application grows during the process! 

Is it worth the effort? 

Thank you! Branislav Bujisic Director of Accounts Engineering Cologne, Germany [email protected]