With 35 million lines of Python code, the Athena trading platform is at the core of JPMorgan’s business operations. A late start to migrating to Python 3 could create a security risk.
Support for Python 2 is ending on January 1, 2020, just over 11 years following the introduction of Python 3—a major restructuring of the language that eliminated duplicate structures and modules in the pursuit of modernization. Given Python’s popularity and ubiquity, the amount of business logic hinging on Python is quite vast, presenting an issue for organizations still clinging to Python 2.
JPMorgan’s Athena trading platform is one of those applications—while access has only been available directly to clients since 2018, the Athena platform is used internally at JPMorgan for pricing, trading, risk management, and analytics, with tools for data science and machine learning. This extensive feature set utilizes over 150,000 Python modules, over 500 open source packages, and 35 million lines of Python code contributed by over 1,500 developers, according to data presented by Misha Tselman, executive director at J.P. Morgan Chase in a talk at PyData 2017.
SEE: Getting started with Python: A list of free resources (TechRepublic)
Migrating 35 million lines of code from Python 2 to Python 3 is quite the undertaking—and JPMorgan is going to miss the deadline, according to eFinancialCareers, stating that JPMorgan’s roadmap puts “most strategic components” compatible with Python 3 by the end of Q1 2020—that is, three months after the end of security patches—with “all legacy Python 2.7 components” planned for compatibility with Python 3 by Q4 2020.
Modern developer practices are needed to maintain a project of this scale—fortunately, JPMorgan uses Continuous Delivery, with 10,000 to 15,000 production changes per week, according to Tselman. CI/CD will be instrumental in a refactoring of this scale, though time is of the essence—the UK National Cyber Security Centre (NCSC) is warning developers of the risks of sticking with Python 2.7, particularly for library writers.
“If you maintain a library that other developers depend on,” the post states, “you may be preventing them from updating to 3. By holding other developers back, you are indirectly and likely unintentionally increasing the security risks of others,” adding that developers who do not publish code publicly should “consider your colleagues who may also be using your code internally.”
For more on Python in the enterprise, check out “How to write four million lines of Python: Lessons from Dropbox on using the programming language at scale” and “Python is eating the world: How one developer’s side project became the hottest programming language on the planet” on TechRepublic.