3 ms·
The first rule of rewrites is don't. That is almost always the correct decision. Like Lucy and the football, if you're sure that this rewrite is different, you
by jmyeet 3y ago
The first rule of rewrites is don't. That is almost always the correct decision. Like Lucy and the football, if you're sure that this rewrite is different, you need to consider how that'll happen.
If you build in parallel, you need to decide what work will go into the existing system and how long the new system will take. Do you pause new features? If yes, I guarantee you that'll be an issue. I also guarantee it'll take longer than you think it will. If you don't pause new features, you'll be chasing moving goal posts so it'll take even longer. All of this is significant extra effort that you have to hope to recoup somehow with the new system.
Remember that it won't take that long before your new system is also considered legacy.
Once you have that new system, how do you deploy it? Dropping it in place is generally a high-risk strategy that'll greatly slow your migration.
Instead of the above, what you generally want is to do partial rewrites in-place using infrastructure you may need to build but you'll want anywhere. Here is the progression of, for example, a backend migration:
1. Double-write to the old and new backends. The new system is just a dummy, eseentially. You won't be using it (yet). Do offline verification on the old and new backends. Look at metrics for double-writes vs single-writes (eg latency, general performance, crashes);
2. Start reading from the old and new backends. Do a comparison of the data retrieved from both. Log and flag any instances where the data differs. You've now verified the new backend;
3. Start reading from the new backend;
4. Stop writing to the old backend.
This requires things like a robust experiment framework so you can, for example, double-write for 1% of your users and then compare the two groups easily across a wide range of metrics to see if there is any unexpected regression.
The point of all this is you can do partial rollouts of any of these steps and, more importantly, a rollback is trivial.
- samus 3y agoThe ease of accommodating new features along the way is actually a fine opportunity for the design of the new system to prove its mettle. If new features turn out to be troublesome, the new design is probably flawed as well.
- karussell 3y agoI once was involved in a bigger rewrite/refactoring of a backend where in a few areas we didn't have enough tests and I found goreplay to be very helpful as you do not need to explicitly write into two backends but the request data will be "doubled". Still stateful requests were a bit problematic but you can write so called "Middleware" for goreplay (in different languages) and I was able to solve it this way.
- marginalia_nu 3y ago> what you generally want is to do partial rewrites in-place using infrastructure you may need to build but you'll want anywhere. Worked in a place where they were embarking on their third generation of failed incremental replacement of a system originally built in COBOL. No indication third time was the charm either. Big problem these projects is they ran for so long that whatever they were using stopped being the hot new thing half way through, so they always needed to restart with a new paradigm before the old one was fully implemented.
- aspaviento 3y ago> backend migration That's cute. I'm in the middle of a migration of a vb6 app, no separation of concerns, database access from the app, no tests, no documentation, no code homogenisation, tons of function calls that end up in an empty string and with MS threatening to end vb6 support just around the corner.