The server stack surrounding PHP hasn’t change much in the last few years. It’s still roughly the same as every year, give or take a few minor tweaks here and there. But 2015 may be the year where some of these services get swapped out for new, improved, ones. Only time will tell of course, but here’s my take on the PHP server stack for 2015 (and hopefully, later).
Varnish
For just about every project (obviously not limited to PHP), Varnish is a standard part in the setup. In 2015, Varnish 4.0 will be the new standard, where it’s currently mostly Varnish 3.x.
Varnish will continue to serve its purpose running on port :80 of your server, ready to handle the bulk of the load. If you can avoid hitting PHP and the database, you should – no matter how fast PHP parsing is about to become.
Apache or Nginx
The webserver will still be either Nginx or Apache, depending on the experience of the sysadmin with either of the webservers, or the requirements for the project. The webserver itself will be configured to be as “dumb” as possible: serve static files, perform compression and send the request to the PHP service for further processing.
The days of mod_php and slow FastCGI/CGI scripts are far gone.
SSL termination via proxies
In order to fully utilise the Varnish cache, all requests need to pass by it. But SSL requests are terminated on port :443, and Varnish is unable to perform SSL. Depending on the webserver of your choice, Apache or Nginx, it’ll be set up to act as a SSL proxy.
All requests that come in via HTTPs are passed via the proxy, that only does the SSL termination / encryption, and passes the request on to Varnish on port :80. Once in Varnish, it’ll either serve a page from cache or forward the request to the real virtual host running on another port.
The benefit of having the Varnish cache, together with SSL encryption for your project.
PHP-FPM or HHVM
While Facebook’s HHVM is faster than PHP-FPM today, the new php-ng may be able to change that. The speed results of php-ng do vary, but it’s rumoured that at release, it should be at least as fast as HHVM. What’s now known as php-ng will most likely become PHP 7, and I’m hopeful to see it released in 2015.
Next up: code compatibility, as a next major version can perform backwards incompatible code breaks. Code written today will probably not work on PHP 7.
Right now, for raw performance it needs to be HHVM. But PHP-FPM has its merits as well, with flexible configs, multiple pools supported and decent performance in the 5.5 version and later. For most setups, PHP 5.5 or 5.6 running as PHP-FPM will be the default, and it will suffice. For those projects that need more performance, HHVM should be consider, until php-ng is released.
PHP-FPM or HHVM will run as Unix socket on the local box, or on a TCP/IP port when it’s run on a remote system, and will receive all requests from the webserver that it couldn’t handle.
MariaDB and MongoDB
Most have replaced their beloved MySQL with MariaDB for a few years now. In those years, MariaDB 5.5 was considered the standard, but 2015 will be the year where MariaDB 10.0 will see greater adoption. We’ll still see MySQL server as well, but it’s in the decline: MariaDB is taking over as default RDMS on most Unix distros since the Oracle license change to MySQL, and we should embrace the choice. MariaDB has replaced MySQL.
In the PHP community, MongoDB appears to clear winner in the key/value and document datastore. There’s plenty of (worthy) alternatives, but 2015 will still favor MongoDB over those others.
Memcached or Redis
For years, Memcached has been caching layer for many PHP developers. Its simple setup and usage make it very easy to implement and master. It’s simple protocol make it easy to debug.
The new kid on the block that made its appears a few years ago is Redis, which offers some additional benefits to Memcached (such as persistence to disk, transactions, clustering, > 1MB of data per object, …). Yet I’ve not seen Redis be used that often. And I’m doubtful as to whether 2015 will make a big change in that.
Memcached does the job perfectly: persistence is not needed in a caching layer (for 95% of all projects out there), clustering has historically always been handled either in the PHP code or in the PHP.INI configs (for instance, for the session handling in Memcached) and has proven its worth. Redis seems like it’s too complex for a simple task as acting as a caching layer.
However, if you’re going beyond just caching and are working on pub/sub messaging, need more availability from your cache or are looking for a queue’ing mechanisme, Redis can be used to replace the current Memcached. There’s probably little point in running both Memcached and Redis, so Redis would replace the Memcached service.
NodeJS
NodeJS isn’t PHP, obviously. But it’s used more and more as a supplement to PHP code. Need to run background jobs, process queue’s and more? Then the step from PHP to NodeJS isn’t that big. It’s JavaScript, on the server-side. And PHP developers know JavaScript.
The choice for MongoDB is also supported by the rising of NodeJS in the PHP community, as it’s most often used as the backend for NodeJS operations.
Deployment tools
There’s just too much choice out there. There isn’t a right tool, nor is there a perfect tool. They all perform their jobs, as long as you configure them properly.
For me, the clear winners remain Phing and Capistrano, where Phing could be considered the easiest to setup as it’s built on PHP, whereas Capistrano has additional Ruby + Gem requirements.
As long as your build-chain is automated and doesn’t rely on manual actions, you’re good to go – no matter what tool you’ve built this on.
DevOps Automation
For those PHP developers that manage their own servers, the configs will go into a Configuration Management System like Puppet, Chef, Ansible, SaltStack, … Whatever technology you’re most comfortable with, will be the winner.
It’s perfectly combined with Vagrant for local development that is an identical setup of your production setup. If you haven’t been using Config Management in 2014, be sure to put in on your todo-list for 2015. And if you’re just getting started, do not have a too complex of a server setup and want to get started quickly, consider Ansible.
Docker
PHP’s default shared-nothing architecture make it ideal to be placed in containers like Docker. In 2015, we’ll see more PHP projects be placed into Docker containers, but it’ll be the minority. Since Docker introduces additional complexity and management, it’ll only be considered by projects that have an actual problem to solve, where Docker can be the answer.
Eventually, Docker can supplement Vagrant for quicker development environments (instead of having Vagrant boot/manage VirtualBox VMs) and can replace the existing deployment tools for continuous integration.
Docker is on my 2015-todo-list, for a variety of reasons.
Conclusion
Since PHP has a long trackrecord already, it’s in a stable position. The current PHP 5.5 and 5.6 setups are built on years of experience, of learning from mistakes and making continuous improvements to the configs.
2015 will not be a dramatic change to this: HHVM or php-ng will make their grand appearance, but virtually all other parts of the stack remain as they are now. After all, why change a winning team?
As for the deployment or automation side, Docker can be a real game-changer, but so far hasn’t been adopted widely by the PHP community.