Application strangulation

Strangulation is a mechanism by which a very large disruptive change is made in an application or service that, does not disrupt its ability to go live, even while partially complete. Martin Fowler named this practice (see references below) after the strangler vines that creep up existing trees, in order to steal sunlight at canopy level of a jungle.

The trick is to have a mechanism to route invocations of logic between the old and new solutions for the same. Say you are an Airline, and you had written your first online purchasing experience in Perl. You’re now wanting to do ‘Elixir’ and its web framework ‘Phoenix’.

Strangulation is where you would use the Apache server that you doubtless had fronting Perl, to conditionally route HTTP requests to Erlang/Elixir/Phoenix. Say your first completed milestone was ‘Loyalty Account View/Edit’ you would route based on the URLs the browser was seeking pages for. Obviously agreeing on URLs (and cookies) is key for the old Perl and new Elixr app. So is deployment in lockstep.

At some point in the strangulation, you might put Elixir in front Apache/Perl and have traffic drop through to it instead. That is the residual situation before you delete the last lines of code of Perl and snip that delegation when the strangulation is complete.

This relates a little to Branch by Abstraction. Strangulation is a strategy for incompatible languages (they are not in the same process), whereas Branch by Abstraction is where the ‘from’ and ‘to’ languages are the same (say Java -> Java), or compatible (Java -> Scala).

References elsewhere

show references