“Sunsetting.”
It sounds so pleasant — a sky of golden rays flanked by purples and reds and oranges. The end of the day.
Or, for software developers, the end of life of a technology or version of that technology that can, depending on the prevalence of the technology, invoke feelings of concern, dread, or even near-panic.
The Python project announced recently that they will really, truly be End-of-Life-ing Python 2.x and fully focusing on Python 3. The proverbial sun will dip below the horizon on January 1, 2020.
This means that the core Python development community will no longer be updating the Python 2 project and this includes source code security patches. You can assume that every black-hat hacker’s ears perked up at that news.
While the sunsetting of some technologies raises barely a blip on the development community’s radar, mostly because usually EOL-ing is done to technologies that no one is using anymore. This particular news, however, has raised quite a bit of commotion. That’s because if you’ve developed a Python application in the past, there is a very high probability that it was written in Python 2x. Additionally, many other Python projects (eg., Pandas, TensorFlow, SciPy, etc.) have pledged to abandon Python 2.x as well. Application developers who used Python 2.x in their technology stack must have a plan for the abandonment of Python 2, even if it’s to do nothing at all.
So, the first option, as noted above, is to maintain the application in Python 2 and reactively address any issues that arise out of that decision. The key issue here is that there will be no security patches to the Python 2 codebase that will leave developers/companies open to attack.
Additionally, for this option, there’s also the issue of dependencies. While the rest of the world migrates to Python 3, the likelihood of finding the libraries and Python-based solutions required to run your application grows slimmer and slimmer by the day. You’ll age yourself into a corner. But regardless of those concerns, status quo may be the right option right now, especially if you had roadmapped to rewrite the application in a couple of years or if the application exists to serve a non-critical function inside of your organization, for instance.
On the opposite end of the spectrum, you may wish to take the opportunity to rewrite your legacy code from scratch using current tools and frameworks, including Python 3. This may be an option for applications critical to your enterprise, which you anticipate using for the foreseeable future, and for which you’d already planned to update sooner rather than later. In that case, this approach can be an opportunity to pull the trigger on new functionality and features you’ve deferred or to take advantage of newer technology innovations.
The third option in this Goldilocks trio may be “juuuust right” for you and your team if you want to keep the application secure and highly available but also don’t have the stomach, plans, or funds for a complete rewrite. The application can be migrated to Python 3, along with all of its dependencies (eg, If your application expects to use a framework targeting Python 2, you’ll need to upgrade that as well.). With generic Python code, the update to Python 3 may be relatively painless. However, with larger codebases or more complex solutions, updating dependencies to support Python 3 may require much more effort and planning. If that’s your situation, the migration requires some strategy, but it can be a nice solution addressing the issue in relatively smaller prioritized bites. The key here is to weigh the effort to migrate over the effort to rewrite and which best fits your business objectives. It’s sort of the question of whether to reupholster a couch or just buy a new one and sell the old. Sometimes the ROI isn’t all that clear and can only be determined by carefully discussing options with company stakeholders.
Regardless of the ‘bed you choose to lie in," a company like Art+Logic can provide the technical expertise to evaluate, advise, and support you in weighing your options and, as a company with a long and deep history of writing and supporting Python applications, we’d welcome the opportunity to have a discussion with you about your requirements.
