Por que a revolução Serverless estagnou

O servidor está morto, vida longa ao servidor!

Assim foi o grito de guerra da revolução serverless. Dê uma olhada rápida nas notícias do setor nos últimos anos e será fácil concluir que o modelo de servidor tradicional morreu e que dentro de alguns anos estaremos todos executando as arquiteturas serverless.

Como qualquer pessoa que trabalha no ramo sabe, e também mostramos no artigo The State of Serverless Computing (O estado da computação serverless, no português), isso não é verdade. Apesar de muitos artigos exporem as virtudes da revolução serverless, ela não aconteceu. Na verdade, pesquisas recentes indicam que a revolução pode até ter parado.

Algumas das promessas feitas pelo modelos serverless foram, sem dúvida, cumpridas, mas não todas.

Neste artigo, quero analisar o motivo dos modelos serverless parecer que a falta de agilidade e flexibilidade ainda é um obstáculo para sua adoção de forma mais generalizada, apesar de terem grande utilidade em circunstâncias específicas e bem definidas.

A promessa da computação serverless

Antes de chegarmos aos problemas da computação serverless, vamos ver o que ela deveria fornecer. As promessas da revolução serverless foram muitas e, às vezes, ambiciosas demais.

Para aqueles que são novos no termo, aqui está uma definição rápida. A computação serverless é uma arquitetura na qual aplicações (ou partes delas) são executadas sob demanda e em ambientes de execução que normalmente são hospedados remotamente. É possível também hospedar sistemas serverless em uma estrutura interna. Construir sistemas serverless resilientes tem sido uma grande preocupação dos administradores de sistemas e das empresas SaaS nos últimos anos, isso porque essa arquitetura oferece várias vantagens importantes sobre o servidor "tradicional" e o modelo de cliente:

1. Os modelos serverless não exigem que os usuários mantenham os próprios sistemas operacionais ou mesmo criem aplicações compatíveis com sistemas operacionais específicos. Pelo contrário, os desenvolvedores podem produzir um código genérico e, em seguida, carregá-lo na estrutura serverless e vê-lo em execução;
2. Os recursos usados em estruturas serverless são normalmente tarifados por minuto (ou mesmo por segundo). Isso significa que os clientes pagam apenas pelo tempo em que estão realmente executando o código. Isso contrasta favoravelmente com a máquina virtual tradicional baseada em nuvem, onde muitas vezes acabamos pagando por uma máquina que fica ociosa a maior parte do tempo;
3. A escalabilidade também foi um grande atrativo. Os recursos em estruturas serverless podem ser atribuídos dinamicamente, o que significa que são capazes de lidar com picos repentinos de demanda.

Resumindo, isso significa que os modelos serverless devem fornecer soluções flexíveis, baratas e escaláveis. Quando olhado por esse ponto de vista, é incrível pensar por que não tivemos essa ideia antes.

O Serverless é uma ideia nova?

Na realidade o conceito de permitir que usuários paguem apenas pelo tempo de execução do código existe desde 2006, quando foi introduzido como parte do Zimki PaaS. Na mesma época, o Google App Engine ofereceu uma solução muito semelhante.

Fato é que o que agora chamamos de modelo "serverless" é mais antigo do que muitas das tecnologias agora chamadas de "cloud native" e que realizam praticamente a mesma coisa. Como alguns observaram, os modelos serverless são, em essência, uma extensão do modelo de negócios SaaS que existe há décadas.

Vale a pena dizer que o serverless não é um tipo de arquitetura FaaS, embora haja uma relação entre ambos. O FaaS é a parte que dá ênfase na computação de uma arquitetura serverless e, portanto, pode fazer parte dela, sem representar todo o sistema.

Então, qual o motivo desse hype atual? Bem, como a taxa de penetração da internet no mundo em desenvolvimento continua a aumentar rapidamente, houve uma alta na demanda por recursos de computação. Muitos países com setores de comércio eletrônico em rápido crescimento, por exemplo, simplesmente não têm a infraestrutura para lidar com as aplicações que dão suporte a essas plataformas. É aí que entra as plataformas serverless de aluguel.

Os problemas do Serverless

O problema é que os modelos serverless têm, alguns problemas. Não me entenda mal: Não estou dizendo que eles sejam ruins per se, ou que não forneçam valor substancial para algumas empresas em algumas circunstâncias. Mas a reivindicação central da "revolução", que o modelo serverless substituiria rapidamente as arquiteturas tradicionais, nunca irá acontecer.

Eis o motivo.

Limite de linguagens de programação

A maioria das plataformas serverless permitem apenas a execução de aplicações desenvolvidas em linguagens específicas. Isso limita severamente a agilidade e adaptabilidade desses sistemas.

É certo que a maioria dessas plataformas oferece suporte à maioria das linguagens tradicionais. O AWS Lambda e o Azure Functions também fornecem um pacote que permite executar aplicações e funções em linguagens não suportadas, embora isso geralmente traga um custo de desempenho. Portanto, para a maioria das empresas, na maioria das vezes, essa limitação não fará muita diferença. Supõe-se que uma das vantagens dos modelos serverless é que programas escondidos e que raramente são usados podem ser utilizados de forma mais barata, uma vez que estaremos pagando apenas pelo tempo de execução. E esses programas raramente usados são frequentemente escritos em... linguagens de programação obscuras e raramente usadas.

Isso prejudica uma das principais vantagens do modelo serverless.

Dependência do fornecedor

O segundo problema com as plataformas serverless, ou pelo menos com a forma como são implementadas no momento, é que poucas similaridade que em um nível operacional. Há pouca padronização no que diz respeito à maneira como as funções devem ser escritas, implantadas e gerenciadas. Isso significa que a migração de funções de uma plataforma específica de um fornecedor para outra é extremamente custosa.

A parte mais difícil da migração para serverless não são as funções computacionais, que geralmente são apenas fragmentos de código, mas a maneira como as aplicações se relacionam com os sistemas de armazenamento de objetos, gerenciamento de identidade e filas. As funções podem mudar de lugar, mas o resto da aplicação não é tão portátil. Esse cenário é o oposto das plataformas baratas e ágeis que nos foram prometidas.

Alguns argumentariam que os modelos serverless são novos e que ainda não houve tempo para padronizar a maneira como funcionam. Mas não são tão novos assim, como dito anteriormente, e muitas outras tecnologias cloud native, como containers, já se tornaram muito mais utilizáveis por meio do desenvolvimento e da adoção de padrões fortes baseados na comunidade.

Desempenho

O desempenho computacional de plataformas serverless pode ser difícil de medir, em parte porque as empresas que vendem esses serviços têm interesse em manter essas informações ocultas. A maioria afirma que as funções executadas em plataformas remotas serverless serão executadas com a mesma rapidez com que fariam em servidores internos, evitando portanto alguns problemas de latência.

Evidências anedóticas, no entanto, sugerem o oposto. Funções que não foram executadas em uma plataforma específica antes, ou que não foram executadas há algum tempo, levam tempo para inicializarem. Isso provavelmente ocorre porque o código foi mudado para algum meio de armazenamento menos acessível, embora a maioria dos fornecedores de computação serverless não divulgará se este for o caso, assim como as estatísticas de desempenho.

Existem várias formas de contornar isso, obviamente. Uma é otimizar as funções para qualquer linguagem de programação cloud native em que a plataforma serverless seja executada, mas isso prejudica um pouco a alegação de que essas plataformas são "ágeis".

Outra abordagem seria garantir que os programas de desempenho crítico sejam programados para serem executados em intervalos frequentes, a fim de mantê-los atualizados. É claro, essa segunda abordagem contradiz um pouco a alegação de que as plataformas serverless são mais econômicas porque pagamos apenas pelo tempo de execução das aplicações. Os provedores de cloud introduziram novas maneiras de reduzir o tempo das primeiras execuções, mas muitos exigem um modelo de escalabilidade que prejudica o valor inicial do FaaS.

O problema da primeira execução pode ser reduzido executando sistemas serverless internamente, mas isso vem com os próprios custos e continua sendo uma opção de nicho para equipes com bons recursos.

Não podemos executar as aplicações por inteiro

Finalmente, talvez a razão mais crucial pela qual as arquiteturas serverless não vão substituir os modelos tradicionais tão cedo, é que geralmente não podemos executar as aplicações inteiras nesse modelo.

Ou melhor, até poderíamos, mas não seria a opção mais econômica. A aplicação monolítica de sucesso provavelmente não deve se tornar uma série de quatro dúzias de funções conectadas a oito gateways, quarenta filas e uma dúzia de instâncias de banco de dados. Por esta razão, o serverless é adequado para o desenvolvimento greenfield quando virtualmente nenhuma integração com a aplicação é atingida. Resumindo, podemos migrar, mas é bom considerarmos começar do zero.

Isso significa que, na grande maioria dos casos, as plataformas serverless são usadas como um complemento dos servidores internos, para realizar tarefas que requerem grandes quantidades de recursos computacionais. Isso as torna realmente muito diferentes de duas outras formas de tecnologia cloud native: Contêineres e máquinas virtuais, que oferecem uma maneira holística de realizar computação remota. Esse cenário ilustra uma das dificuldades na transição de microservices para o serverless.

Isso não é necessariamente um problema, é claro. A capacidade de ocasionalmente recorrer a enormes recursos computacionais, sem pagar pelo hardware necessário para conseguir isso internamente, pode ser um benefício real e duradouro em muitas empresas. No entanto, gerenciar a maneira como as aplicações são executadas, com partes em servidores internos e outras partes em arquiteturas cloud serverless, pode trazer outro nível de complexidade na implantação dessas aplicações.

Viva la Revolucion?

Apesar de todas essas reclamações, não sou contra as soluções serverless em si. Prometo! Os desenvolvedores devem perceber, especialmente se estiverem explorando modelos serverless pela primeira vez, que essa tecnologia não é uma substituição direta dos servidores. Em contraponto, recomendo a leitura de nossas dicas e recursos para construir aplicações serverless e decida a melhor forma de implementar este modelo.

Sobre o autor

Bernard Brode é pesquisador de produtos na Microscopic Machines e permanece eternamente curioso sobre para onde a interseção de IA, cibersegurança e nanotecnologia nos levará.