Phenquestions
Computadores Físicos
Percorremos um longo caminho desde os enormes servidores da era pontocom. Naquela época, a infraestrutura de servidor era principalmente no local. Uma empresa executou suas soluções em um servidor físico. As pessoas usaram servidores inteiros separados para diferentes fins (backup, servidor de e-mail, servidor da web, etc). Quando um determinado servidor não conseguiu acompanhar as necessidades crescentes da empresa, ele foi substituído por um servidor mais novo e mais rápido. Você escalou obtendo um hardware melhor. Você escalou verticalmente.
Hipervisores
Então veio a era dos hipervisores. Ele ganhou impulso com o surgimento do VMWare e as pessoas perceberam que podem ter um rack para comandar todos eles. Um rack para executar todos os vários casos de uso e provisionar cada um deles com sua própria máquina virtual separada. Isso também deu origem à computação em nuvem e as empresas pararam de investir em hardware de servidor, diretamente, e optaram por 'alugar' servidores virtuais.
Centros de dados enormes e caros eram gerenciados por provedores de nuvem em todo o mundo. As empresas tiraram proveito disso ao provisionar seus serviços globalmente, usando a maior variedade possível de data centers. Isso foi feito principalmente para reduzir as latências, melhorar a experiência do cliente e atingir um mercado maior.
Isso também fez os autores de software pensarem em termos de sistemas distribuídos. Eles escreveram software para rodar não em um único computador gigante, mas em muitos computadores medíocres de uma forma consistente e confiável. Você escalou horizontalmente.
Você ainda pode escalar verticalmente. Na verdade, por causa da virtualização, provisionar mais recursos tornou-se mais fácil. Você desligou a VM, ajustou seus recursos e pagou ao seu provedor de nuvem um pouco mais. Pedaco de bolo.
Os servidores físicos subjacentes não desapareceram. Os provedores de nuvem agora são responsáveis por gerenciar complexidades de interfaces de rede, compatibilidade de sistema operacional e outras patologias aterrorizantes.
Recipientes
Então vieram os contêineres. Os contêineres eram uma abstração incrível e leve. Um ambiente virtual com um sistema operacional que permite que o software seja empacotado e implantado como uma unidade única. Como máquinas virtuais, cada contêiner é executado sem reconhecer outros contêineres, mas eles compartilham o mesmo kernel do sistema operacional.
Isso permitiu que as pessoas implantassem software em servidores (físicos ou virtuais, não importa) em um nível ainda mais alto de abstração. Você não se importou com o sistema operacional de produção. Contanto que fosse compatível com sua tecnologia de conteinerização, ele executaria seu software. Além disso, os contêineres são mais fáceis de girar, o que torna os serviços mais escalonáveis do que nunca.
Isso aumentou ainda mais a flexibilidade dos sistemas distribuídos. Com tecnologias como o Kubernetes, você pode ter legiões de contêineres executando uma gama complexa de serviços. Os sistemas distribuídos oferecem muitos benefícios: alta disponibilidade, robustez e capacidade de se recuperar de uma falha de nó.
Ao mesmo tempo, por serem tão complexos, também são mais difíceis de projetar, implantar, manter, monitorar e depurar. Isso vai contra a tendência original de abstrair a complexidade do seu software e delegar essa responsabilidade ao seu provedor de nuvem. É aqui que entra a arquitetura sem servidor.
Serverless ou Function-as-a-Service (FaaS)
A ideia de sem servidor ganhou força principalmente por causa do AWS Lambda, e aqui vou usar isso como um modelo para falar sobre sem servidor. Os princípios nos quais o FaaS se baseia são:
- Você paga pelo que usa
- Você não precisa se preocupar com o dimensionamento
- Você se concentra em seu código, deixa o gerenciamento de infraestrutura para a AWS
Quando ninguém está acessando seus serviços, os serviços não estão ativos. Este não era o caso nas soluções de hospedagem tradicionais, onde você paga por um VPS que está sempre instalado e funcionando, mesmo que fique ocioso, sem fazer nada mais útil do que ouvir um novo pedido.
Na arquitetura sem servidor, seu serviço não está em execução a menos que alguém realmente queira usá-lo. Quando uma solicitação chega, um serviço é criado rapidamente para lidar com ela.
Como funciona?
Sua função (por exemplo, um programa Python, Go ou Java) fica como um arquivo no AWS Lambda. Com esta função, você associa certos eventos de gatilho, como um gateway de API, ou um novo objeto entrando em seu bucket S3. E certos recursos como um banco de dados ou outro armazenamento de objeto ou uma instância EC2.
Em resposta a qualquer um dos eventos de gatilho associados, o AWS Lambda cria um contêiner com sua função dentro dele. A função é executada e dá uma resposta. Por exemplo, se uma nova imagem entrar em seu intervalo S3, o AWS Lambda pode ter um código de aprendizado de máquina dentro dele, que analisaria essa imagem e gravaria sua saída em um DynamoDB (um dos serviços de armazenamento de dados da AWS).
Você não precisa pagar por um servidor inteiro, mas apenas pela quantidade de memória que alocou para sua função, o número de solicitações que você recebe e por quanto tempo sua função é executada.
Além disso, você não precisa se preocupar com o escalonamento de contêineres em resposta a uma grande carga de trabalho de entrada. Se muitos eventos de gatilho acontecerem simultaneamente, a AWS cuidará de criar novos contêineres e agendar cargas de trabalho entre eles e todas as outras complexidades.
Não é uma solução completa
Quando as máquinas virtuais surgiram, os servidores físicos não deixaram de existir. Quando os contêineres chegaram, ainda usávamos VMs. O FaaS é uma abstração de alto nível e se encaixa muito bem com o design moderno de APIs RESTful, serviços sem estado e linguagens leves como Node.js ou Python.
No entanto, ainda é executado em um servidor físico (gerenciado pela AWS, por exemplo), ele ainda escuta as solicitações de entrada (você só não paga por isso diretamente) e você ainda precisa armazenar dados de forma persistente, por isso tem integrações para S3, EC2 e outros serviços. É uma abstração útil, no entanto.
