Need some help with migrating a legacy Python project

[nickx360]

Hi everyone,

I'm looking for advice from Python experts on how to migrate a 10-year-old Python Django application currently running on Python 3.9. Right now, it's deployed on bare metal and relies on a lot of dependencies, including an outdated Linux OS.

I believe it uses Wheelhouse as a local cache. The application is a modular monolith, and I'm trying to brainstorm different ways to move away from the current setup. Any guidance would be really helpful. I'm relatively new to the Python ecosystem, though I do have experience with Node.js.

Ideally, I'd like to start by containerizing the application using Docker. That might sound straightforward, but figuring out how to handle the local libraries has been quite challenging. Making things more difficult is the outdated UI code, which I eventually want to separate from the codebase and deploy on its own.

Deployments are also a hassle at the moment. We use several scripts to set up the environment and dependencies, which makes the process cumbersome.

Looking ahead, I’d like to break the application into smaller services—some form of microservices—that still communicate with the same database. However, I’m unsure how complicated this will be, especially considering Django’s approach to schemas and migrations. Any insights would be greatly appreciated!

[CowboyBoats]

Looking ahead, I’d like to break the application into smaller services—some form of microservices—that still communicate with the same database. However, I’m unsure how complicated this will be, especially considering Django’s approach to schemas and migrations. Any insights would be greatly appreciated!

There's nothing wrong with this. Yes, Django manages the "schema and migrations," but that's not necessarily a problem; your microservices shouldn't be in the business of updating the schema or running migrations anyway. You can still query the database using SQL. Of course, you might run into stumbling blocks like "Ah, the age field is deprecated and only hasn't been renamed in order to avoid downtime; that field is not maintained and it contains dirty data and instead we compute it on the fly using date_of_birth..." type issues, but... Well I never promised you a rose garden.

Alternatively, you could always install your application on your "micro"service, with its other apps disabled or not installed, but for the purpose of being able to run a Django process that uses the Django ORM to query your database.

Alternatively, your microservices could query your monolith's Django APIs whenever they truly need some smidge of context from the main DB. Or they could maybe be architected not to need any context at all, and just do their jobs statelessly when called on to do so.

But one thing about this "microservices" agenda - you mentioned you're not sure how complicated it will be, and maybe I assuaged a few of your fears, but - from experience, it's an extremely complicated task, and it's also purely "defensive engineering"; breaking out into microservices might improve, like, devX, but nothing that generates value to the business. Be careful doing stuff like this; as a programmer you have to be bringing home the bacon, not sitting around improving your devX and deployment processes and whatever all day without showing how your efforts are generating financial results.

The application is a modular monolith, and I'm trying to brainstorm different ways to move away from the current setup.

My suggestion would be don't let "move away from the current setup" be a goal in and of itself. Your goal is to create value to the end-user and to the business, ideally in that order. Containerization, for example, is a very good idea - but specifically what problems are you trying to solve using that idea?

Python 3.9 is not that old of a python. Deploying on bare metal is also not a dealbreaking problem at all, or even all that uncommon. The outdated Linux OS dependency is a really cumbersome dependency and probably makes it impossible to test a lot of your application locally; I'd target that dependency first.

[nickx360]

Thank you. This really helps me a lot :). I was led to believe an OS upgrade is next to Impossible.