How would you keep the same Python 2.7 app running for years to come?

Publish Date: Jul 13 '20

2 9

I've recently came across a new interesting challenge.

One of the app I'm working on is an old app written in 2016 using Python 2.7. It's basically a website/web platform where people can do stuff.

The platform is going to be discontinued soon, but needs to process data for the next 5-8 years nevertheless. The business context led to the decision of disabling new sign-ups and only allow existing users to sign in, so that they can access their data for years to come.

Not only the project is being discontinued, but the staff behind it too. Resources are scarce to say the least.

The goal now is to keep the platform in an operational condition, without making any changes to it. (or, as little as possible)

As you probably know, Python 2 is completely outdated and support is being dropped on many tools, such as pip which will drop support in January 2021, 6 months from now.

The challenge at hand here is to find a way to keep such a project in operational condition and keep it running for all those years to come.

But, I know it will eventually break. At some point, running pip install will not work anymore, whether due to pip itself or one of the thousands of the project's dependencies.

I've spent a good deal of time on this challenge already, and eventually chose to keep our current hosting provider for now (fully managed).

I also considered making a Docker instance so that the whole infrastructure gets "frozen", but even though I'm not sure the underlying provider (AWS, etc.) wouldn't deprecate such instances within 5-8 years of time and force us to move it to something different, which may lead to issues when reinstalling everything years later, with a different staff unfamiliar with the project.

Of course, rewriting the whole app is not an option, due to time/budget constraints. Also, the project being discontinued, it'd really not make any sense, financially wise.

So, I'm not asking for a magical solution. But I'm interested in similar experiences and feedback about what to do and not to do from peers who've known such a challenge. Would love to hear your story!

Comments 9 total

Jing XueJul 15, 2020
Docker, or some kind of containerization in general, would be my first thought too. I don't get what you mean by "deprecating such instances."

You wouldn't need to run pip or any other updates regularly. The only scenario where you would need to update anything is when you must apply some security patch.
- VadorequestJul 17, 2020
  Docker would need to live within a server, and that server could get deprecated by its hosting provider, which could mean reinstalling the docker project on a new server, and potentially run into the same issues.
  - Jing XueJul 17, 2020
    Obviously I don't know much about the nature of your app, but I don't see docker upgrading being a major maintenance issue, as long as when dockerizing your app you don't rely on docker features that are in danger of being deprecated themselves.
    - VadorequestJul 17, 2020
      It's not so much about upgrading docker, but more about reinstalling the app if the container has to change.
      
      Like, if I need to run pip install again, it may break for various reasons 6 years from now.
      
      I could also install everything in the dockerized app, including everything related to pip modules, python version, etc. So that nothing has to be installed again, even if I spawn a new docker container.
      - Jing XueJul 17, 2020
        Ok, well, I assumed by "dockerizing" you would put all the dependencies into the image along with the app. IOW you'd end up with a self-contained image. Then you deploy it in, say, AWS ECS Fargate. As long as ECS can provision the required computing resources (CPUs, memory, etc.), you wouldn't have to worry about AWS switching hosts from underneath. If you just put the app itself in the image, but leave the dependencies on, say, a host volume, of course it's liable to break at some point, but that's kind of defeating the purpose of containerization, isn't it?
        
        VadorequestJul 17, 2020
        Yes, you're right, it could work if the container itself is frozen (everything already installed), so that nothing changes even if it's needed to launch a new container at some point.
        
        Only temporary files would be a concern, like logs and so. (if transitioning)
        
        Jing XueJul 17, 2020
        For files produced by the app, if you need to post-process/archive them, perhaps consider the Sidecar Pattern. Basically you keep the main app container frozen, and put the post-processing logic in a separate container - it could be as simple as backing up the log files to S3.
Jonathan BowmanJul 16, 2020
I like the containerized approach, as well.

I am curious how many lines of code this is. Have you considered using six or 2to3 or python-future to give updating the code a try?
- VadorequestJul 17, 2020
  Too much code too bad written. :/
  
  Lots of encoding issue stuff, code in French, I'll let you guess the maintainability level of such crap :D

Add comment

Vadorequest @vadorequest

How would you keep the same Python 2.7 app running for years to come?

Comments 9 total