A pilha de servidor PHP não mudou muito nos últimos anos. Ainda é praticamente a mesma a cada ano, com alguns pequenos ajustes aqui e ali. Mas 2015 pode ser o ano em que alguns desses serviços serão trocados por novos e melhores. Só o tempo dirá, claro, mas aqui expresso minha opinião sobre a pilha de servidor PHP para 2015 (e, esperamos, para ainda mais tempo).

Varnish

Para quase todos os projetos (obviamente, isso não se limita somente ao PHP), o Varnish é uma parte padrão da configuração. Em 2015, o Varnish 4.0 será o novo padrão, já que atualmente a maior parte os servidores executa o Varnish 3.x.

O Varnish continuará a servir o seu propósito em execução na porta 80 do seu servidor, pronto para lidar com a maior parte da carga de tráfego. Se você puder evitar usar PHP com banco de dados, faça isso – não importa o quão rápido o parsing PHP esteja prestes a se tornar.

Apache ou Nginx

O servidor web mais utilizado ainda será Nginx ou Apache, dependendo da experiência do administrador do servidor com qualquer um dos servidores web ou dos requisitos para o projeto. O servidor web em si será configurado para ser tão “burro” quanto possível: servir arquivos estáticos, realizar compressão e enviar a solicitação para o serviço PHP para posterior processamento.

Os dias de mod_php e scripts lentos com FastCGI/CGI passarão longe.

Terminação SSL via proxies

A fim de utilizar plenamente o cache Varnish, todas as requisições precisam passar por ele. Mas solicitações SSL são terminadas na porta 443, e o Varnish é incapaz de executar o protocolo SSL. Dependendo do servidor de sua escolha, Apache ou Nginx, ele será configurado para atuar como um proxy SSL para atender a esses casos.

Todos os pedidos que chegam via HTTPS são transmitidos através do proxy, que só faz a interpretação de SSL/criptografia e passa a solicitação para o Varnish na porta: 80. Uma vez no Varnish, ele vai querer servir uma página de cache ou encaminhar o pedido para o host virtual executando em outra porta.

O benefício será ter o cache Varnish, juntamente com a criptografia SSL para seu projeto.

PHP-FPM ou HHVM

Enquanto o HHVM do Facebook é mais rápido do que o PHP-FPM hoje, o novo php-ng pode ser capaz de mudar isso. Os resultados de velocidade apresentados pelo php-ng variam, mas há rumores de que ele deverá ser pelo menos tão rápido quanto o HHVM. O que é agora conhecido como php-ng provavelmente irá tornar-se PHP 7, e estou esperançoso de vê-lo lançado em 2015.

Próximo passo: compatibilidade de código, já que a próxima grande versão pode realizar quebras de código para versões incompatíveis. Código escrito hoje provavelmente não funcionará no PHP 7.

Agora, para o desempenho bruto, será usado HHVM. Mas o PHP-FPM também tem seus méritos, com configurações flexíveis, vários pools suportam melhor desempenho na versão 5.5 e posteriores. Para a maioria das configurações, PHP 5.5 ou 5.6 em execução como PHP-FPM será o padrão, e isso será suficiente. Para os projetos que precisam de mais desempenho, o HHVM deve ser considerado até que o php-ng seja liberado.

O PHP-FPM ou o HHVM serão executados como um socket Unix local, ou em uma porta TCP/IP quando for executado em um sistema remoto, e receberá todas as solicitações com as quais antes o servidor não poderia lidar.

MariaDB e MongoDB

A maioria dos administradores de sistemas substituiu o amado MySQL pelo MariaDB há algum tempo. O Nesse período, o MariaDB 5.5 foi considerado o padrão, mas 2015 será o ano em que o MariaDB 10.0 verá maior adoção. Ainda vamos ver servidores executando MySQL, mas estes estarão em declínio: o MariaDB está assumindo como padrão na maioria das distribuições RDMS Unix desde que a Oracle mudou as licenças para o MySQL, e devemos simplesmente aderir à mudança básica sobre o MariaDB substituir o MySQL.

Na comunidade PHP, o MongoDB aparece para clamar seu espaço como vencedor na categoria de armazenamento de dados. Há uma abundância de (dignas) alternativas, mas 2015 ainda favorecerá o MongoDB sobre esses outros.

Memcached ou Redis

Durante anos, o Memcached tem sido a infraestrutura de camada de cache para muitos desenvolvedores PHP. Sua configuração e utilização simples tornam muito fácil sua implementação e gerenciamento. É um simples protocolo mais fácil de depurar.

Uma novidade que surgiu há alguns anos é o Redis, que oferece alguns benefícios adicionais para o Memcached (tais como a persistência de disco, transações, clustering, mais de 1 MB de dados por objeto etc.). No entanto, não vi o Redis ser usado com frequência. Estou em dúvida quanto a saber se 2015 vai fazer uma grande mudança para ele.

O Memcached faz o trabalho perfeitamente: persistência não é necessária em uma camada de cache (para pelo menos 95% de todos os projetos lá fora), o agrupamento tem sido historicamente sempre manipulado no código PHP ou nas configurações do arquivo php.ini (por exemplo, para a sessão de manipulação do Memcached) e provou o seu valor. O Redis parece ser muito complexo para uma tarefa simples como agir exatamente como uma camada de armazenamento em cache.

No entanto, se você está indo além do uso voltado apenas para caching e estiver trabalhando em pub/sub messaging, precisará de mais disponibilidade de seu cache ou estará à procura de um mecanismo de enfileiramento de cache. O Redis pode ser usado para substituir o Memcached atual, mas provavelmente há poucos pontos úteis entre o Memcached e Redis que façam o Redis substituir o serviço hoje feito pelo Memcached.

NodeJS

NodeJS não é PHP, obviamente. Mas é cada vez mais utilizado como um complemento ao código PHP para quem precisa executar trabalhos em segundo plano, filas de processos e outras demandas. Em contrapartida, a camada de PHP para NodeJS não é tão grande. É JavaScript, no final das contas, mas no lado do servidor. E os desenvolvedores de PHP sabem JavaScript.

A escolha do MongoDB também é apoiada pelo NodeJS na comunidade PHP, uma vez que ele é usado na maioria das vezes como o backend para operações nodejs.

Ferramentas de deployment

Há muitas escolhas para se fazer neste quesito. Não há uma única ferramenta adequada, nem uma ferramenta perfeita. Todas elas executam seus trabalhos, contanto que você as configure adequadamente.

Para mim, os vencedores mais claros continuam sendo Phing e Capistrano, e o Phing pode ser considerado o mais fácil de configurar, já que é construído em PHP, enquanto o Capistrano tem requisitos adicionais Rubi + Gem.

Enquanto sua cadeia de construção é automatizada e não depende de ações manuais, você está pronto para continuar – não importa com qual ferramenta você construiu seu programa.

Automação DevOps

Para os desenvolvedores PHP que gerenciam seus próprios servidores, as configurações vão migrar para um Sistema de Gestão de Configurações como Puppet, Chef, Ansible, SaltStack etc. Seja qual for a tecnologia com a qual você se sente mais confortável, ela será a vencedora.

É perfeitamente combinado com Vagrant para desenvolvimento local, que é uma configuração idêntica de sua configuração de produção. Se você ainda não usou o recurso de Gerenciamento de Configuração em 2014, não se esqueça de colocar em sua lista de tarefas para 2015. Se você está começando, não tenha um ambiente complexo demais e possua uma configuração de servidor por onde possa começar rapidamente, considere utilizar o Ansible.

Docker

O PHP, por padrão, utiliza uma arquitetura não compartilhada, o que o torna ideal para ser colocado em recipientes como o Docker. Em 2015, vamos ver mais projetos PHP serem colocados em recipientes Docker, mas estes serão a minoria. Desde que o Docker introduziu complexidade e gerenciamento adicional, ele só vai ser considerado por projetos que têm um problema real para resolver, onde o Docker pode ser a resposta.

Eventualmente, o Docker pode complementar o Vagrant para ambientes de desenvolvimento mais rápidos (em vez da necessidade de boot/gerenciamento Vagrant com VMs VirtualBox) e pode substituir as ferramentas de deployment existentes para integração contínua.

O Docker está na minha lista de afazeres de 2015, por uma variedade de razões.

Conclusão

Como o PHP tem uma longa lista de recursos novos e atuais, está em uma posição estável. As configurações dos atuais PHP 5.5 e 5.6 são construídas baseadas em anos de experiência, de aprendizado com os erros do passado e fazendo melhorias contínuas para as configurações no futuro.

2015 não será uma mudança dramática para isso: HHVM ou php-ng vão fazer sua grande aparição, mas praticamente todas as outras partes da pilha vão permanecer como estão agora. Afinal, por que mexer em um time que está ganhando?

Seja para o lado do deployment ou da automação, o Docker pode ser um verdadeiro divisor de águas, mas até agora não tem sido amplamente adotado pela comunidade PHP.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://ma.ttias.be/next-generation-php-server-stack-2015/3/