Serverless não é sobre servidores, é sobre aplicativos

Há muita confusão em torno do conceito de “computação sem servidor”. Isso pode ser porque o nome dele é bastante errado. Não se trata de servidores ou computação. Pelo menos não no sentido tradicional da palavra, usado pela maioria dos profissionais de TI.

Serverless é muito melhor conhecido como Functions as a Service (FaaS), porque é isso que ele oferece. Da mesma forma que o FaaS não tem servidor, o SaaS também não e, pode-se concluir corretamente, o PaaS. Isso ocorre porque o servidor – a computação – é retirado da equação da perspectiva de seu consumidor, que geralmente é um desenvolvedor. Os recursos de computação (servidor, rede) ficam ocultos, são provisionados, gerenciados e dimensionados automaticamente por meio de uma rede de automação e orquestração, governada, em última análise, pelo provedor do serviço. Você paga por isso, mas nunca precisa ver.

O FaaS sem servidor não substitui o SaaS, o PaaS ou a nuvem em geral. É mais uma opção sobreposta aos modelos existentes que oferece aos desenvolvedores a capacidade interessante de invocar funções sob demanda. Ela é orientada a eventos, o que significa que a função é acionada por um evento. Esse evento é frequentemente a invocação de uma chamada de API, que assume a forma de uma solicitação HTTP com um URI muito específico. Sim, uma chamada de API.

O caso de uso mais citado para FaaS é o processamento de imagens ou vídeos. Isso ocorre porque os recursos necessários são muitas vezes imprevisíveis, tanto em frequência quanto em capacidade. O FaaS fornece um meio acessível e eficiente de processar essa mídia por chamada. Outro exemplo pode estar relacionado ao espaço da IoT, onde ações são acionadas por eventos que ocorrem por meio de um aplicativo controlador ou do próprio dispositivo. E há sempre o caso de uso de backend de API , que geralmente faz mais sentido para a maioria das pessoas do que qualquer outro caso de uso, porque as APIs são frequentemente descritas como URIs que invocam funções.  Independentemente do que a função esteja fazendo, ela será executada somente quando acionada por um evento específico e deverá ser uma função única e isolada.

Isto não é uma nuvem como estamos acostumados a ver ou discutir. Isso ocorre porque a nuvem (IaaS) é sobre infraestrutura e operações, enquanto FaaS (e PaaS e SaaS) são sobre aplicativos. Eles são concebidos como um ambiente de desenvolvimento, no qual os desenvolvedores podem implementar código para executar algumas tarefas como parte de uma iniciativa de aplicativo maior. É possível criar um aplicativo a partir de múltiplas implementações FaaS? Absolutamente. De fato, nesse aspecto, o FaaS é para o SaaS o que os microsserviços são para os monólitos.

Mas é exatamente esse o ponto. FaaS é sobre aplicativos, não servidores. Você não pode implementar uma nuvem com FaaS, mas pode desenvolver um aplicativo. Você não pode levantar e mover um aplicativo para um ambiente “sem servidor”. Ele deve ser desconstruído e então reconstruído, ou melhor, re-arquitetado como uma coleção de FaaS.

As combinações (ou seriam permutações?) são extensas. É possível incorporar FaaS junto com PaaS a partir de um aplicativo implantado em IaaS. O IaaS e o PaaS podem ser locais, enquanto o FaaS é público.

O problema com SaaS, PaaS e FaaS é que você nunca vê os "servidores". Isso não é verdade no IaaS, onde chamamos os servidores de “instâncias” e somos obrigados a gerenciá-los e mantê-los. Isso ocorre porque o IaaS — seja local ou público — trata-se de entrega de infraestrutura e operações, não de aplicativos. Isso sempre foi verdade, mas conseguimos ignorar isso na última década porque “servidor == aplicativo” tem sido a norma por muito tempo.

Mas com o surgimento de microsserviços e APIs, e agora FaaS, não podemos mais operar em um modo onde “servidor == aplicativo” porque isso simplesmente não é mais verdade.

No final das contas, FaaS não é sobre servidores, ou mesmo sobre nuvem (no sentido em que a entendemos). Mas é uma mudança significativa na maneira como podemos arquitetar e desenvolver aplicativos.