As with many technologies, the PHP community too evolves. And over the last 6 or 7 years, a rather remarkable circle has been made by a lot of systems administrators and PHP developers in that regard.
The A in LAMP
For many years, PHP was traditionally run in the “LAMP” stack; Linux, Apache, MySQL and PHP. Apache was the de facto webserver, often combined with PHP running as mod_php or as CGI. It worked, and in the mod_php scenario it was even a fast way of running your PHP apps. But permissions were always a pain, as everything is executed as the Apache user. apache2-mpm-itk tried to solve this, but was never a success.
So as time went by, more and more frustrations emerged with permissions in PHP applications and server setups. And then Nginx happened.
The rise of Nginx
A new webserver came into the picture, promising lightning speeds, extreme scalability, events instead of threads, … it’s here to scale your PHP app to the millions. That was the idea that many sysadmins had when they started migrating from the Apache webserver to Nginx.
And since Nginx doesn’t have something like mod_php, an alternative had to be found to parse PHP. Back when PHP 5.2 was a thing, something called php-fpm emerged. It was, for the PHP world, revolutionary. Suddenly, there was a reliable way of separating the PHP processing from the webserver and it allowed you to properly use a webserver like Nginx for the first time.
Back in those PHP 5.2 days it still felt like a hack though, for systems administrators trying to manage the configs. Since 5.3 and upwards, php-fpm became officially supported in the core of PHP and became more mainstream, and the configs became more easy to manage.
But since Nginx doesn’t have the AllowOverride option from Apache, that allows you to use .htaccess files to overwrite configurations for the webserver (this was, at the time, a large reason why Nginx became popular as well – as AllowOVerride options can prove to be a real bottleneck). That means all rewrites, all caching headers, all additional gzip rules, etc. had to be defined in the Nginx configs. And those configs are usually managed by sysadmins, not developers. So PHP developers that do not manage their own servers, lose the flexibility of overwriting webserver settings from within their app.
As a result, PHP developers and sysadmins had to communicate more – they had to coordinate their changes. I do believe the DevOps movement came, for the PHP community at least, as a result of this: what were normally 2 entirely separated worlds (Devs vs. Ops), now had to communicate and make changes accordingly. Both could give feedback on the requests of the other, since neither could make the change alone.
Alas, as time goes by, this becomes more of a hindrance than it adds value. PHP developers aren’t as flexible anymore, as changes need to go through a sysadmin that needs to modify the configs – assuming the PHP dev doesn’t manage the server himself. And the novelty soon wears of, it all becomes an annoyance. It slows things down.
But at this time, the concept of running a webserver other than Apache, and running your PHP code as PHP-FPM pools, did become more of a commodity. We no longer considered mod_php to be the de facto standard.
Back to ye old faithful, Apache
It’s the move to Nginx that though us a valuable lesson: there’s a different way to run your PHP code. And as a PHP developer, you want to keep independent control of how the webserver, for your particular app, behaves.
I’m not saying Nginx is out of the picture. But I am seeing a movement away from Nginx, and back to Apache. Not the Apache configs that we made 6-7 years ago, with mod_php or CGI. But a config that incorporates the lessons we learned from the Nginx phase, of running PHP as the PHP-FPM daemon (or: multiple daemons) instead of a module in Apache. Of separating the webserver user from the PHP user, without sacrificing performance.
The Apache configs we make these days do still enable AllowOverride. They allow the PHP developer to manage their own rewrites, their own header configs and their own HTTP authentication settings, if they so chose to. And yes, Apache remains vulnerable to SlowLoris attacks (and many other types of attacks), whereas Nginx is more resilient. Yes, Apache has its downsides – it sure does. But it has a lot of great features, and the .htaccess files with AllowOVerride are one of them.
The circle of moving away from Apache, to alternative webservers like Nginx and slowly moving back to Apache, is something I expect we’ll see all the time. In a few years time, we’ll probably move to yet another method of running PHP and configuring our webservers.
So, Nginx is a no-go?
Absolutely not.
While I see a movement of slowly backing down from Nginx, there are still great values in the webserver: the configs need to be managed by sysadmins, they enforce communication between Devs and Ops. The webserver is entirely different from Apache, with its own pros and cons.
Every project needs to make the choice of webserver, and for some Nginx is the best option, for others Apache or yet another webserver. This has always been the case, but in the last year we’ve seen more decisions that fall back to Apache than chose to go with Nginx.