Pontos-chave

• Há vários anos, temos a promessa de que a computação sem servidor (serverless) abrirá uma nova era sem um sistema operacional específico para executar aplicativos. Disseram-nos que tal estrutura resolveria muitos problemas de escalabilidade. Na verdade, tudo é diferente.
• Embora muitos vejam a tecnologia sem servidor como uma ideia nova, suas raízes remontam a 2006 com Zimki PaaS e Google App Engine, ambos usando uma arquitetura sem servidor.
• Há quatro razões pelas quais a revolução sem servidor estagnou, desde suporte limitado a linguagens de programação até problemas de desempenho.
• A computação sem servidor não é tão inútil. Longe disso. No entanto, eles não devem ser vistos como substitutos diretos dos servidores. Para algumas aplicações, eles podem ser uma ferramenta útil.

O servidor está morto, viva o servidor!

Este é o grito de guerra dos adeptos da revolução sem servidor. Uma rápida olhada na imprensa do setor nos últimos anos é suficiente para concluir que o modelo tradicional de servidor está morto e que em alguns anos estaremos todos usando arquiteturas sem servidor.

Como qualquer pessoa do setor sabe, e como também apontamos em nosso artigo sobre o estado da computação sem servidor, isto está errado. Apesar de muitos artigos sobre os méritos revolução sem servidor, isso nunca aconteceu. Na verdade, estudos recentes mostramque esta revolução pode ter chegado a um beco sem saída.

Algumas das promessas para modelos sem servidor certamente se tornaram realidade, mas não todas. Nem todos.

Neste artigo quero considerar as razões para esta condição. Por que a falta de flexibilidade dos modelos serverless ainda é um obstáculo à sua adoção mais ampla, embora continuem úteis em circunstâncias específicas e bem definidas.

O que os adeptos da computação sem servidor prometeram

Antes de passarmos aos problemas da computação sem servidor, vamos ver o que eles têm a oferecer. Promessas de uma revolução sem servidor eram numerosos e - por vezes - muito ambiciosos.

Para quem não está familiarizado com o termo, aqui está uma breve definição. A computação sem servidor define uma arquitetura na qual aplicativos (ou partes de aplicativos) são executados sob demanda em ambientes de tempo de execução que normalmente são hospedados remotamente. Além disso, sistemas sem servidor podem ser hospedados. A construção de sistemas robustos sem servidor tem sido uma grande preocupação dos administradores de sistemas e empresas de SaaS nos últimos anos, já que (afirma-se) esta arquitetura oferece várias vantagens importantes sobre o modelo cliente/servidor "tradicional":

1. Os modelos sem servidor não exigem que os usuários mantenham seus próprios sistemas operacionais ou mesmo criem aplicativos compatíveis com sistemas operacionais específicos. Em vez disso, os desenvolvedores criam código compartilhado, carregam-no em uma plataforma sem servidor e observam sua execução.
2. Os recursos em estruturas sem servidor geralmente são cobrados por minuto (ou até segundos). Isso significa que os clientes pagam apenas pelo tempo que realmente executam o código. Isso se compara favoravelmente com a VM em nuvem tradicional, onde a máquina fica ociosa a maior parte do tempo, mas você tem que pagar por isso.
3. O problema da escalabilidade também foi resolvido. Os recursos em estruturas sem servidor são atribuídos dinamicamente para que o sistema possa lidar facilmente com picos repentinos de demanda.

Resumindo, os modelos sem servidor fornecem soluções flexíveis, de baixo custo e escaláveis. Estou surpreso por não termos pensado nessa ideia antes.

Esta é realmente uma ideia nova?

Na verdade a ideia não é nova. O conceito de permitir que os usuários paguem apenas pelo tempo que o código realmente é executado existe desde que foi introduzido sob o Zimki PaaS em 2006, e na mesma época, o Google App Engine apresentou uma solução muito semelhante.

Na verdade, o que hoje chamamos de modelo “sem servidor” é mais antigo do que muitas das tecnologias agora chamadas de “nativas da nuvem”, que fornecem quase o mesmo. Conforme observado, os modelos sem servidor são essencialmente apenas uma extensão do modelo de negócios SaaS que existe há décadas.

Também vale a pena reconhecer que o modelo serverless não é uma arquitetura FaaS, embora exista uma conexão entre os dois. FaaS é essencialmente a parte centrada na computação de uma arquitetura sem servidor, mas não representa o sistema inteiro.

Então, por que todo esse hype? Bem, à medida que a taxa de penetração da Internet nos países em desenvolvimento continua a disparar, o mesmo acontece com a procura de recursos informáticos. Por exemplo, muitos países com sectores de comércio electrónico em rápido crescimento simplesmente não possuem a infra-estrutura informática para aplicações nestas plataformas. É aqui que entram as plataformas pagas sem servidor.

Problemas com modelos sem servidor

O problema é que os modelos sem servidor têm… problemas. Não me interpretem mal: não estou dizendo que eles sejam ruins por si só ou que não forneçam valor significativo para algumas empresas em algumas circunstâncias. Mas a principal afirmação da “revolução” – que a arquitetura sem servidor substituirá rapidamente a tradicional – nunca se concretiza.

É por isso.

Suporte limitado para linguagens de programação

A maioria das plataformas sem servidor permite a execução apenas de aplicativos escritos em determinadas linguagens. Isto limita severamente a flexibilidade e adaptabilidade destes sistemas.

Considera-se que as plataformas sem servidor suportam a maioria dos principais idiomas. O AWS Lambda e o Azure Functions também fornecem um wrapper para executar aplicativos e funções em linguagens não suportadas, embora isso geralmente tenha um custo de desempenho. Portanto, para a maioria das organizações, esta limitação geralmente não é um grande problema. Mas aqui está a questão. Supõe-se que um dos benefícios dos modelos sem servidor é que programas obscuros e raramente usados ​​podem ser usados ​​mais barato porque você só paga pelo tempo que eles são executados. E programas obscuros e raramente usados ​​são frequentemente escritos em... linguagens de programação obscuras e raramente usadas.

Isso prejudica uma das principais vantagens do modelo sem servidor.

Vinculação a um fornecedor

O segundo problema com as plataformas sem servidor, ou pelo menos com a forma como são implementadas atualmente, é que elas geralmente não são parecidas no nível operacional. Praticamente não há padronização em termos de funções de escrita, implantação e gerenciamento. Isso significa que a migração de recursos de uma plataforma para outra consome muito tempo.

A parte mais difícil da mudança para um modelo sem servidor não são os recursos computacionais, que geralmente são apenas trechos de código, mas como os aplicativos se comunicam com sistemas conectados, como armazenamento de objetos, gerenciamento de identidades e filas. As funções podem ser movidas, mas o restante do aplicativo não. Isto é exatamente o oposto das prometidas plataformas baratas e flexíveis.

Alguns argumentam que os modelos sem servidor são novos e não houve tempo para padronizar a forma como funcionam. Mas elas não são tão novas, como observei acima, e muitas outras tecnologias de nuvem, como contêineres, já se tornaram muito mais convenientes devido ao desenvolvimento e à adoção generalizada de bons padrões.

Desempenho

O desempenho computacional de plataformas sem servidor é difícil de medir, em parte porque os fornecedores tendem a manter as informações em segredo. A maioria argumenta que os recursos em plataformas remotas e sem servidor são executados tão rapidamente quanto em servidores internos, exceto por alguns problemas inevitáveis ​​de latência.

No entanto, algumas evidências sugerem o contrário. Funções que não foram executadas anteriormente em uma plataforma específica, ou que não foram executadas há algum tempo, levam algum tempo para serem inicializadas. Provavelmente, isso se deve ao fato de seu código ter sido portado para algum meio de armazenamento menos disponível, embora - como acontece com os benchmarks - a maioria dos fornecedores não informe sobre a portabilidade de dados.

Claro, existem várias maneiras de contornar isso. Uma delas é otimizar recursos para qualquer linguagem de nuvem em que sua plataforma sem servidor seja executada, mas isso prejudica um pouco a afirmação de que essas plataformas são “ágeis”.

Outra abordagem é garantir que os programas críticos para o desempenho sejam executados regularmente para mantê-los “atualizados”. Essa segunda abordagem, é claro, contraria um pouco a afirmação de que as plataformas sem servidor são mais econômicas porque você paga apenas pelo tempo de execução dos seus programas. Os provedores de nuvem introduziram novas maneiras de reduzir os lançamentos frios, mas muitos deles exigem "escala para um", o que prejudica o valor original do FaaS.

O problema de inicialização a frio pode ser parcialmente resolvido com a execução interna de sistemas sem servidor, mas isso ocorre às suas próprias custas e continua sendo uma opção de nicho para equipes com bons recursos.

Você não pode executar aplicativos inteiros

Finalmente, talvez a razão mais importante pela qual as arquiteturas sem servidor não substituirão os modelos tradicionais tão cedo é que elas (geralmente) não conseguem executar aplicativos inteiros.

Mais precisamente, é impraticável do ponto de vista dos custos. Seu monólito de sucesso provavelmente não deveria ser transformado em um conjunto de quatro dúzias de funções unidas por oito gateways, quarenta filas e uma dúzia de instâncias de banco de dados. Por esse motivo, o serverless é mais adequado para novos desenvolvimentos. Praticamente nenhum aplicativo (arquitetura) existente pode ser portado. Você pode migrar, mas precisa começar do zero.

Isso significa que, na grande maioria dos casos, plataformas serverless são usadas como complemento aos servidores back-end para executar tarefas computacionalmente intensivas. Isto é muito diferente das outras duas formas de computação em nuvem, contentores e máquinas virtuais, que oferecem uma forma holística de realizar computação remota. Isso ilustra um dos desafios da migração de microsserviços para sistemas sem servidor.

Claro, isso nem sempre é um problema. A capacidade de usar periodicamente enormes recursos de computação sem comprar seu próprio hardware pode trazer benefícios reais e duradouros para muitas organizações. Mas se alguns aplicativos estiverem em servidores internos e outros em arquiteturas de nuvem sem servidor, o gerenciamento entrará em um novo nível de complexidade.

Vida longa à revolução?

Apesar de todas essas reclamações, não me oponho às soluções sem servidor em si. Honestamente. Só que os desenvolvedores precisam entender – especialmente se estiverem explorando modelos sem servidor pela primeira vez – que essa tecnologia não é um substituto direto dos servidores. Em vez disso, confira nossas dicas e recursos em construindo aplicativos sem servidor e decidir a melhor forma de aplicar este modelo.

Fonte: habr.com