- This post
- Part 2
I've been thinking a reading a lot about how to overcome vendor lock-in in general. Seems to be a very tricky problem to solve!
Of course, it depends a lot on what your project looks like. Any ball of mud is hard to work with, and replacing parts is never easy. In my situation, I'm looking at how to migrate an application slowly away from Python/Django and to... Well, to anything really, but in my situation, I'm looking at C#/.NET.
In the context of Django, it becomes tricky, because the whole stack, all the way from presentation and down to the database is controlled by Django, and every single layer is closely coupled to the ORM.
The goal
The end result would be moving an existing stack over to a new stack, but more importantly, the goal is to do so incrementally, without changing the user experience for the worse, and without the users actually feeling it. The app should work the same, but the tech underneath gets swapped out.
The challenge is to do it in meaningful increments. I could of course dig in and spend the next two years just rewriting everything, and once it is good and done, do a big swap. This isn't feasible though. I would need to validate my redesign along the way. Actually release something, measure the impact, tune it, redesign along the way. An iterative approach. There is the idea that rewriting all the crap will make it better; but in a corporate setting, this rewrite always takes too long and ends up being rushed, and then you end with another mess.
Approaches
So how would I do it? As I see it, there are a few valid approaches. All of them focus on finding the right cut, and then working through it in a particular order:
- Bottom-up: Rip out the data layer, reimplement it in .NET and have the Django app fetch the data through an API.
- Top-down: Re-implement the user interface in .NET MVC fashion, and then make calls to Django API to get the data.
There are pros and cons to both approaches, but both will depend on finding some vertical slices in the application domain and testing it out.
For my particular case, it'll probably make the most sense to work top-down. The current UI layer is a mess, and it is served both from backend and with some React islands here and there. It would make sense to "get it right" in the new setup, and then rely on the exising Django solution for a data API, where we already have all the domain rules defined.
The steps
As I see it, the approach would be:
- Define vertical slices in the app
- For each vertical slice, reimplement the UI in .NET (So there will be a Django process and a .NET process running, and there will be some routing and session sharing between them, so they appear as one app to the client)
- Once the entire UI is rewritten (all the vertical slices), start rewriting the backend from being a Django served API to .NET
Sounds simple when I list it like this, but I'm sure there are pitfalls along the way that I haven't identified. Those will probably be separate posts, either discussing the challenges up-front, OR as battle stories after I've botched the deployment ;)
I suppose we'll see how it plays out.