O ano de 2020 tem sido bem produtivo para mim. Comecei a estudar num ritmo mais constante e aprofundado sobre tudo acerca de desenvolvimento web. E, claro, não tem como falar de web sem falar de deploy.
Baseado nesse assunto, resolvi enfim saber o que é a tal nuvem, porquê minha VPS não era considerada nuvem, mesmo estando na internet, como que as grandes empresas faziam para ter suas aplicações rodando 24h por dia e atendendo milhares de clientes ao redor do mundo.
Vou abordar de maneira simplória todos esses assuntos na visão de um desenvolvedor fullstack.
Porquê minha VPS não é um servidor de nuvem?
VPS nada mais é que uma máquina virtual. Fazendo uma analogia ao mundo real, VPS é um apartamento de um prédio. E esse prédio pode ter N apartamentos, podendo variar entre apartamento simples e bem luxuosos no mesmo prédio.
O motivo que faz um site hospedado numa VPS não ser considerado "estar na nuvem", é o fato da não redundância dos dados.
Geralmente, colocamos a aplicação e o banco de dados todos juntos na mesma VPS. Mas o que acontece se a VPS parar de funcionar de uma hora pra outra?
A resposta é que seu site ficará fora do ar.
Numa arquitetura de nuvem, existe uma redundância dos dados. É como se tivessem várias clones de VPS rodando a mesma aplicação. Se alguma delas cair, a estrutura garante que a aplicação vai continuar funcionando para o usuário (tudo de forma transparente).
E como as grandes empresas operam?
As empresas que recebem grandes volumes de tráfegos de usuários, adotam estratégias de nuvem. Vamos ver um exemplo bem simples de uma dessas arquiteturas:
Cada retângulo é uma máquina conectada na internet (uma VPS ou servidor físico por exemplo).
Veja que todos os clones da aplicação (não importam quantos sejam), nesta arquitetura, apontam sempre para o mesmo banco de dados, pois não importa qual clone seja, os dados devem ser o mesmo (imagine um e-commerce).
Existem arquiteturas mais robustas que implementam uma espécie de "clones de rápido acesso ao BD" e replicam isso quantas vezes quiserem e, esses clones, por sua vez, se comunicam com um único BD original, que é quem vai persistir os dados e servirá de base para os clones.
Esse método é bastante utilizado para diminuir o gargalo que é ter todas requisições para um único BD.
Perceba também que existe uma máquina na arquitetura acima com nome de Load Balancer (balanceador de carga). Esse carinha é responsável por receber todas as requisições de todos os usuários e, a partir daí, ele decide qual requisição vai para qual clone/servidor, dado a quantidade de usuários que cada um destes servidores esta atendendo.
Resumindo, o Load Balancer (LB) vai distribuir os usuários entre os clones da aplicação, de modo que nenhuma máquina fique lenta ou atenda muitos clientes enquanto a outra fica ociosa.
A quantidade de APP-CLONES vai ser determinada pelo número de trafégo que o site recebe. Tem sites que possui 4 clones/servidores, por exemplo.
Informações importantes
Para uma aplicação funcionar bem no ambiente de nuvem, dizemos que esta aplicação deve ser escalável.
O pessoal do Heroku escreveu os "12 mandamentos" que uma aplicação tem que ter para ser escalável. Você pode conferir neste link.
Mas eae? A gente vai ter que fazer deploy em N APP-CLONES pra botar em nuvem? Ter que fazer o git pull, configurar Nginx, gerar certificados?
A resposta é sim e não. Para diminuir a quantidade de trabalho braçal, existe o Docker para nos ajudar a replicar o ambiente de produção. Se você quer estudar mais sobre esse assunto, recomendo que pesquise por assuntos tais como Docker, Kubernetes e Containers. Devem dar uma clareada para que rumo seguir 😄
Conclusão
O ambiente em nuvem na mesma medida que é bacana e legal, pode ser também muito caro para manter. Alguns desenvolvedores querem otimizar tudo de forma precoce, quando, na verdade, o problema de gargalo na aplicação pode estar no código mal feito, geralmente em querys desnecessárias.
O Django possui diversos esqueminhas que podemos fazer para melhorar a performance da aplicação. Posso fazer um post outro dia para falar mais sobre isso, mas dá uma olhada no Django Debug Toolbar e vê o que tu pode melhorar na aplicação.
Também podemos melhorar a capacidade da máquina. Por exemplo, aumentar a quantidade de RAM e processamento da VPS para aguentar mais clientes, as vezes é mais barato do que ter um ambiente em nuvem.