Dirty Old Code — Part 1
Part 1 in a three part series where we quickly and simply explain our move of Precogs products to serverless infrastructure.
I’ll chop you down like an old dead tree
— Ewan MacColl (Dirty Old Town)
It is fashionable for everything to be available “As A Service”, and the more technical the offering, the more technical gaps there are to fill. In the case of migrating infrastructure, this ‘technical debt’ can have disastrous effects on your business if not managed properly.
Any time we want to migrate to a new architecture that includes a significant shift, then we have to take into account the technical debt and establish a strategy to prevent the breakage or degradation of the service through any gaps. This is the first in a series of three posts, about moving from Ruby on Rails to a serverless infrastructure and how we had to manage the shift from our monolithic code base.
For most migration projects, there are three possible strategies. Here are the pros and cons of each:
OPTION 1:
Completely stop any development of the old version and concentrate all effort on the new infrastructure. Then switch to the new infrastructure when it is ready.
Pros:
- Faster migration
- No communication required between the old and the new infrastructure
Cons:
- No evolution time for the development of the new infrastructure
- Dev time can be long if there is a lot to migrate
- No bug fixes on the old version once development stops
OPTION 2:
Develop the old and new versions in parallel, adding new features to both as you go. Switch across to the new version when the feature set matches.
Pros:
- Continuous evolutions through the development phase
- Bugfixes
Cons:
- Very long migration (it can be endless!)
- Twice the effort required to maintain both
OPTION 3:
Fix bugs and make minor changes to the old version. Develop new features on the new version, integrate to the old (still live) version piece by piece. Old and new versions work in parallel for a while.
Pros:
- New features: product may continue to evolve despite the migration
- ‘soft’ transition: no sudden break
Cons:
- Two different systems must coexist together, meaning it is necessary to identify, cut and synchronize
- Skills needs on both systems
In the end, for our move from Ruby on Rails to serverless infrastructure, we chose Option 3. It gave us the greatest stability without taking up an inordinate amount of time.
Step 1 — Choosing the provider: AWS -> migrate the old servers to Ec2
Step 2 — Choosing a Managed DB -> RDS
Step 3 — Communication between the old system and the new
The next steps are in my next post!
