Já subi aplicações para rodar em produção de diversas maneiras: FTP, servidor próprio (máquina virtual), PaaS e Serverless.
Muito do que aprendi aqui foi mérito de outras pessoas que trabalhavam comigo e que implementaram as soluções que eu ajudei a nascer e manter.
Segue neste texto alguns aprendizados sobre os benefícios e desvantagens de cada uma delas.
FTP – Protocolo de Transferência de Arquivos
Sabe qual a beleza do FTP? É exatamente o fato de ser apenas sobre transmissão de arquivos. Nada mais.
FTP é extremamente usado em aplicações como WordPress e sites estáticos, raramente úteis para aplicações do tipo SaaS, mas muito valorosas para colocar um site ou um plugin WordPress no ar.
FTP é simples, não exige acesso à máquina e pode ser uma boa escolha para quando não se quer dar acesso SSH para evitar problemas de modificações de ambiente e segurança.
Eu já tive até vergonha de fazer algo por FTP porque é considerado de nível técnico inferior. Mas hoje em dia, se precisar por algum cliente não quiser liberar acessos SSH, vou em frente cheio de amor (e paciência, porque FTP é lento, aliás, SFTP, usem Secure FTP).
Servidor Próprio (Virtual Machines)
Quando falo em servidor próprio, me refiro geralmente à uma máquina virtual na qual você pode controlar o sistema operacional, instalar o que quiser, desinstalar, enfim, você tem a liberdade de fazer a merda que quiser, mas tem também, O PODER.
Poucas coisas são tão poderosas do no mundo do software web do que dominar linux o suficiente para controlar sua(s) VM(s) na nuvem.
Com os recursos de aplicações diversas do mundo open source e o baixo custo das VM’s hoje em dia, é possível fazer muita coisa com apenas 10 dólares por mês na Linode por exemplo.
Hoje interpreto uma VM como sinônimo de PODER e LIBERDADE em aplicações para internet.
Mas como todo PODER traz grandes RESPONSABILIDADES, esse é o contraponto. É mais difícil e exige muito mais dedicação e conhecimento técnico cuidar de um sistema operacional rodando em um computador conectado à internet 24×7.
É sem dúvida minha opção favorita em dois casos:
- 1) Quando preciso começar com muito baixo custo e o software tem uma demanda razoavelmente previsível e regular (ou que se aplica aqui também, demandas de usos de um único cliente ou processamentos esporádicos).
- 2) Quando tenho uma equipe de infraestrutura competente o bastante para fazer a gestão de um conjunto de VM’s operando em um software de maior porte (hoje em dia, provavelmente com o apoio de Kubernetes, Docker, etc para orquestrar os diversos serviços).
PaaS – Plataforma como um Serviço
O principal software que cuido hoje roda no Heroku, um serviço que oferece a plataforma completa para colocar no ar e escalar aplicações de pequeno à grande porte.
Esse tipo de plataforma prepara “builds” para diversas linguagens, simplifica processos de deploy e de escalabilidade da aplicação, tanto vertical como horizontal, e cria ecossistemas de “plugins” que entregam funcionalidades que de outra forma você teria que implantar por si próprio em uma VM.
Traz grande tranquilidade para escalar a aplicação quando precisa, pagar somente por isso e depois voltar ao padrão de uso normal.
Para funcionar, a sua aplicação precisa bater com os requisitos de uma plataforma como esta, geralmente elas são amplas o suficiente para atender um bom número de tipos de aplicação diferentes, mas quanto mais específico for o seu negócio, menos ela será útil.
Por exemplo, o Heroku tem um limite rígido de 30 segundos para uma requisição. E ponto final. Toda requisição que demorar mais do que 15 segundos para ser processada é finalizada. Isso faz com que o software que rode no Heroku quase que obrigatoriamente vai ter que trabalhar com fila de tarefas. Todas as plataformas terão limites.
Outra limitação comum é que geralmente estes serviços trabalham de uma forma que você não tem uma máquina com sistema de arquivos persistente, ou seja, geralmente você não pode salvar arquivos ou instalar o banco de dados na mesma “máquina“.
Para ter sua aplicação com sistema de arquivos você vai precisar contratar um serviço adicional de banco de dados (como o RDS da Amazon) ou um serviço adicional de storage (como o S3).
Basicamente ao usar um PaaS você começa a vincular a sua aplicação a uma série de serviços externos de apoio. No Heroku, até a “cron” tem que ser feita com um plugin. Não demora para você ter pelos menos uns 5 serviços adicionais atrelados como log, banco de dados, balanceador de carga, armazenamento estático e gerenciador de fila de tarefas.
Isso gera um benefício bastante positivo que é desenvolver uma aplicação que não guarda estado dependente de um sistema de arquivos persistente e que acaba criando formas de se integrar com serviços externos que você pode mudar de tempos em tempos.
Digamos que, embora um pouco mais difícil de desenvolver, a aplicação tende a se tornar mais versátil e “comunicativa” do que quando criamos algo para um servidor próprio com banco de dados, logs e cron tudo no mesmo lugar.
Serverless
As opções serverless são um passo adiante do conceito de PaaS. Quando você contrata uma PaaS, geralmente você compra algo semelhante a uma VM, pagando por hora, mas pré-configurada, que você apenas usa, sem se preocupar em instalar nem manter, e no máximo, manda escalar horizontal ou verticalmente quando precisa.
Mas no caso do serverless você nem mesmo vê isso. Você publica seu código, vai ser cobrado por uso e não vai nem saber quantos servidores estão sendo usados, onde eles estão, nem nada. Não se preocupa com escalabilidade, nada. Simplesmente funciona.
O segredo aqui é restringir ainda mais a quantidade de acesso à recursos que o software tem, é apenas código e variável de ambiente. Tudo o mais funciona com serviços externos.
Um caso que tenho experiência de uso graças a um grande companheiro de trabalho que nos trouxe essa escolha é o CloudFlare Pages. O CloudFlare Pages permite hospedar conteúdo estático em modo serverless. Eu não sei nada sobre os servidores onde minha aplicação roda, mas ela roda, e com toda a estrutura da CloudFlare em torno. Um requisito aqui, por exemplo, é que é só código estático, não tem backend (e aí, existe um outro serviço, chamado workers, que funciona mais ou menos como um código backend para executar algumas tarefas, mas também, cheio de limitações).
Outras estruturas de serverless já focam mais no backend permitindo rodar micro serviços com muita liberdade de preocupação com carga de servidor e monitoramento.
O desafio aqui é que escrever código serverless exige controlar o gargalo do processamento em outros pontos da aplicação como o banco de dados e lidar com as limitações de uso de recursos impostas por cada fornecedor.
Conclusões
Escolher o tipo de infraestrutura de produção é um desafio crucial para o sucesso da aplicação no longo prazo.
Hoje em dia, para um grande número de aplicações, rodar em PaaS é a melhor solução, um equilíbrio entre custo e benefício tende a ser o mais eficiente e adequado nas diversas fases do projeto.
Agora, se você puder ter uma VM própria e rodar algumas aplicações menos críticas em um servidor próprio, é outro patamar de liberdade, embora também o seja de problemas, mas você aprende muito mesmo, sofre um pouco, mas se diverte também.
Para rodar aplicações de grande porte em uma VM própria aí precisa ser algo que faça muito sentido no seu contexto e você tenha domínio do que está fazendo porque os riscos de perda de dados e problemas de segurança são maiores.
Já as opções serverless provavelmente serão boas em alguma parte da sua aplicação, mas usar elas para 100% da aplicação eu imagino que deva funcionar em alguns casos, mas particularmente não tenho essa experiência.
Por fim, nunca despreza um ágil e seguro SFTP nem julgue as pessoas que estão ainda usando infraestruturas de produção mais simples. É inegável que as hospedagens compartilhadas com acesso via FTP ainda tem seu lugar de baixíssimo custo para quem está iniciando com seus primeiros sites e sistemas online.