4 ms·

Martin Fowler suggests an alternative: the Strangler Fig Application[1]. [1] https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.c

Martin Fowler suggests an alternative: the Strangler Fig Application[1]. [1] https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html

emersonrsantos 3y ago
We tried that in the company I worked, project was abandoned 1 year later. Improvements and better practices were incorportated into the old codebase which is still scaling today.
- pc86 3y ago
  This makes me wonder if the system was still capable of supporting improvements, better practices, and increased scale, why was it targeted for a rewrite in a first place?
Tommah 3y ago
I did something similar to that at one of my jobs. We had a Java web app that we wanted to port to Python. I created a new Python web app and ran it alongside the Java app. Then I started reimplementing the Java code in Python, one endpoint at a time. Every time I had a new Python endpoint working, I went into the corresponding Java endpoint, and I replaced its code with a call to the Python app. The Java app, in effect, was becoming a proxy to the Python app. The plan was that once all the code had been ported over, the Java app could just go away. I skipped over some of the details here, but this was a nice way to port the app over without feeling in a rush, and without having that big stressful "throw the giant switch" moment. Ultimately, the company decided to scrap the original app altogether and rewrite from scratch because a lot of the original app was irrelevant to the new direction we were taking... but I got about 20% of the original app ported over in a week or so.
- patrick451 3y ago
  I like this sort of process. I've done something very similar converting scientific code I prototyped in python into c++. I would re-write one function or class at a time in c++, write a binding to it with pybind11, and replace the original python with a call to the binding. There was some extra work with the bindings, but that's such straightforward boilerplate it was worth it.
withinboredom 3y ago
I worked somewhere where this is all we did. Changing things was discouraged (versioned api endpoints) unless it was to fix a bug. I actually loved it. Each time you copy-pasted an endpoint to make a significant change, you didn’t have to. You could just rewrite it from scratch, taking everything you knew from the old versions.
jamietanna 3y ago
One of my colleagues recently described[0] how we applied this at Deliveroo and it worked nicely for incrementally decomposing [0]: https://youtube.com/watch?v=LP0sTNruvaM https://youtube.com/watch?v=LP0sTNruvaM

Martin Fowler suggests an alternative: the Strangler Fig Application[1]. [1] https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html

emersonrsantos 3y ago

We tried that in the company I worked, project was abandoned 1 year later. Improvements and better practices were incorportated into the old codebase which is still scaling today.

pc86 3y ago
This makes me wonder if the system was still capable of supporting improvements, better practices, and increased scale, why was it targeted for a rewrite in a first place?

Tommah 3y ago

I did something similar to that at one of my jobs. We had a Java web app that we wanted to port to Python. I created a new Python web app and ran it alongside the Java app. Then I started reimplementing the Java code in Python, one endpoint at a time. Every time I had a new Python endpoint working, I went into the corresponding Java endpoint, and I replaced its code with a call to the Python app. The Java app, in effect, was becoming a proxy to the Python app. The plan was that once all the code had been ported over, the Java app could just go away. I skipped over some of the details here, but this was a nice way to port the app over without feeling in a rush, and without having that big stressful "throw the giant switch" moment. Ultimately, the company decided to scrap the original app altogether and rewrite from scratch because a lot of the original app was irrelevant to the new direction we were taking... but I got about 20% of the original app ported over in a week or so.

patrick451 3y ago
I like this sort of process. I've done something very similar converting scientific code I prototyped in python into c++. I would re-write one function or class at a time in c++, write a binding to it with pybind11, and replace the original python with a call to the binding. There was some extra work with the bindings, but that's such straightforward boilerplate it was worth it.

withinboredom 3y ago

I worked somewhere where this is all we did. Changing things was discouraged (versioned api endpoints) unless it was to fix a bug. I actually loved it. Each time you copy-pasted an endpoint to make a significant change, you didn’t have to. You could just rewrite it from scratch, taking everything you knew from the old versions.

jamietanna 3y ago

One of my colleagues recently described[0] how we applied this at Deliveroo and it worked nicely for incrementally decomposing [0]: https://youtube.com/watch?v=LP0sTNruvaM https://youtube.com/watch?v=LP0sTNruvaM