PHP’s Legacy Problem
March 1, 2021 Alex Woodie
PHP is one of the most popular languages on the Web, with arguably billions of lines of code in use across hundreds of thousands of applications. But that long history of successful use exposes a problem for PHP that IBM i shops will be all-too familiar with: a severe reluctance to upgrade. A recent survey by Perforce puts PHP’s legacy situation in perspective.
In January, Perforce (which owns Zend) published its 2021 PHP Landscape Report, which is based on a survey of 670 developers and administrators that Perforce conducted last fall. That was just before the delivery of PHP 8.0 in early December, so some of the statistics about PHP usage may be off by a bit. But even with 8.0 adoption starting to kick in, it’s not likely to have a big impact on one of the most eyebrow-raising statistics to come out of the report: The fact that more than half of PHP users are running versions of PHP that are no longer supported.
“A whopping 52 percent of respondents are on end-of-life versions,” said Matthew Weier O’Phinney, a PHP expert with Zend and the product manager for Laminas (formerly Zend Framework) during a February 16 webinar presenting the results of the survey.
“PHP 7.2 reached end-of-life this past November. It’s no longer getting security patches from the open source community. 7.1 reached end of life before that, and 5.6 reached end of life quite a long time ago!” he continues. “Knowing we have something like one-third of respondents saying their applications are on PHP 7.1 – that’s crazy! It’s one of those things where you start thinking: Is maybe the PHP lifecycle a little too fast for most organizations to keep up to date with?”
Zend senior solutions architect Erwin Earley, who co-presented the webinar alongside Weier O’Phinney and is an expert in PHP on IBM i, had seen this picture before.
“In the enterprise space, they’re loathe to upgrade. They want to stay on a version as long as possible,” Earley said. “And it’s not just PHP, although we see it in PHP in spades. It’s in the operating system. I have seen numerous customers that will stay on a version of, in my world, the IBM i operating system, for years past when IBM has dropped support and pay huge dollars for [extended] maintenance. When we talk to IBM i customers about PHP, the number of customers that we see on 5.6 I guarantee you is higher that the percentage we’re showing here.”
PHP 5.6 remains popular, at 11 percent of the total (per the survey), despite the fact that it has been out of support for more than two years. The code has yet to be deprecated by Zend due to the connections it has with CentOS and Red Hat Enterprise Linux 7, which will be supported until 2024. That means that PHP 5.6 won’t be deprecated, forcing users to upgrade, Weier O’Phinney said.
But the long tail of PHP versions goes back even farther than PHP version 5.6 on IBM i, which has supported PHP since 2006. “The customers we see on versions 5.3 and 5.2 – honestly, the only word I can use is alarming. They’re just really, really slow to upgrade,” Earley said. “It’s not just an IBM i trend if you will. It’s across the board. It’s kind of scary, in a way.”
Staying on old releases of anything – whether its cars or computers – introduces a unique set of challenges. The odds of something breaking goes up the longer you stay with a given piece of technology, and the costs of fixing those breaks goes up too. But that’s just one side of the equation. On the other side are the costs associated with dealing with broken software integrations (if you don’t bother to test) or the many hours you spend running regression tests to find those broken integration points and fix them before going live (if you do).
In many ways, it’s “pay me now or pay me later.” Companies are reluctant to upgrade for fear of breaking software compatibility and causing a disruption to their business, so they delay the upgrades as long as possible. Only when the upgrade window starts to close and the possibility of being stuck on an extremely old release that cannot be easily upgraded do some companies start thinking about moving. And even then, some companies will just take their chances with older releases and never move up.
Weier O’Phinney said he spends months testing new PHP releases to ensure that it doesn’t break anything in the Laminas framework.
“Quite often they’ll work just fine,” he said. “But we have to go through and test and every single one of our packages to make sure that it works against them, that there’s no deprecation or minor. . . stuff that we’ve missed. As much as the PHP project likes to make sure that they follow sematic versioning, it seems like every single time there’s some little tweak that has happened in the code, it makes one little thing over here just not work the same way it did before. And that can have a disastrous effect if you have an expectation that it’s just going to continue working the same way.”
It doesn’t help that PHP can be difficult to upgrade. There are tools that will point out where the incompatibilities exist, but in most cases, there is no automated tool that will bring your code from point A to point B.
“That’s one of those things that’s surprising to a lot of people, that when you actually go and do it, it takes a whole lot more time than they were expecting,” Weier O’Phinney said. “We did a white paper on this last year about doing PHP upgrades, the hidden cost of them. We often don’t think of doing all these pieces that go along with it.”
PHP 8.0, which isn’t yet available for IBM i, brings a number of compelling new features, including a Just In Time (JIT) compiler. Weier O’Phinney said the JIT compiler will give PHP the performance characteristics of other scripting languages, like Python and Ruby, which will open up a number of new use cases, such system programming for machine learning and big data.
Adoption of PHP version 8.0 is not expected to move quickly, because of the aforementioned aversion to risk. What that means is, in the PHP world, version 7 is going to stick around for a long time (there was no version 6 release, you will remember). The open source community is no longer providing support for those old releases, but Zend offers support packages for these older releases for a fee.
“A lot of people are going to stay with version 7 for a while, because it’s safe. They know it’s stable,” Weier O’Phinney said. “One of the things we had an argument in our engineering team recently is which version are we going to mark as the current stable version when do our installer for Zend PHP for IBM i and the engineering team made a really compelling argument that we should go with whatever version that is currently being supported by PHP that has been out the longest.”
The honor went to PHP version 7.3 for the Zend PHP distro. “It’s the most stable version and, for those companies that are wanting to make sure that what they’re using isn’t going to be changing a lot, that it has bug fixes and everything, they’re going to go with that version,” Weier O’Phinney said. “Of course…you’re going to have to start thinking about, OK what do I do once it reaches end-of-life in the community? Are there options for me, our organization, to continue getting support, making sure that we have security patches and everything going forward, even if the community isn’t doing it?”
By the way, Zend still supports PHP 5.6 on IBM i and other platforms. The end-of-life distribution has received a reprieve from second death three times now, and Zend will continue to support PHP 5.6 until January 2023, Weier O’Phinney said. But there’s a limit as to how long Zend wants to keep these zombie releases from finalizing their proud legacies. Eventually, security concerns will dictate the time to put PHP 5.6 the digital equivalent of six feet under.
“The further it gets away from current version of PHP, the harder it is to determine if a current particular vulnerability still affects the later version,” Weier O’Phinney said. “So it’s harder to know if it’s secure.”
To read more about the 2021 PHP Landscape Report, click here.