Pontos-chave
- Há vários anos, afirmam-nos que a computação sem servidor (serverless) abrirá uma nova era sem um sistema operativo específico para a execução de aplicações. Disseram-nos que essa 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 o surgimento do Zimki PaaS e do Google App Engine — em ambos os casos, utiliza-se uma arquitetura sem servidor.
- Existem quatro razões pelas quais a revolução sem servidor chegou a um impasse: desde o suporte limitado a linguagens de programação até problemas de desempenho.
- A computação sem servidor não é de todo inútil. De forma alguma. No entanto, não deve ser vista como uma substituição direta aos servidores. Para algumas aplicações, pode ser uma ferramenta conveniente.
O servidor está morto, viva o servidor!
Esse é o grito de guerra dos defensores da revolução sem servidor. Basta uma rápida olhada na imprensa do setor nos últimos anos para chegar facilmente à conclusão de que o modelo tradicional de servidor está morto e que, em poucos anos, todos estaremos utilizando arquiteturas sem servidor.
Como qualquer um no setor sabe, e como também indicamos em nosso artigo sobre , isso não é verdade. Apesar de vários artigos sobre os méritos , ela nunca realmente aconteceu. Na verdade, , que essa revolução pode ter chegado a um impasse.
Algumas das promessas para modelos sem servidor foram, sem dúvida, realizadas, mas não todas. Longe disso.
Neste artigo, quero examinar as razões para esse estado. Por que a falta de flexibilidade dos modelos sem servidor ainda é um obstáculo para sua adoção mais ampla, mesmo que eles continuem a ser úteis em circunstâncias específicas e bem definidas.
O que os defensores da computação sem servidor prometeram
Antes de abordarmos os problemas da computação sem servidor, vamos ver o que deveriam oferecer. foram numerosas e — às vezes — muito ambiciosas.
Para aqueles que não estão familiarizados com o termo, aqui está uma breve definição. A computação sem servidor refere-se à arquitetura em que aplicativos (ou partes de aplicativos) são executados sob demanda em ambientes de execução que normalmente são hospedados remotamente. Além disso, os sistemas sem servidor podem ser hospedados localmente. Nos últimos anos, a criação de sistemas sem servidor eficientes tem sido a principal preocupação de administradores de sistemas e empresas de SaaS, uma vez que (supostamente) essa arquitetura oferece várias vantagens-chave em relação ao modelo tradicional de cliente-servidor.
- Os modelos sem servidor não exigem que os usuários mantenham seus próprios sistemas operacionais ou criem aplicativos compatíveis com sistemas específicos. Em vez disso, os desenvolvedores criam código comum, o carregam em uma plataforma sem servidor e monitoram sua execução.
- Os recursos em estruturas sem servidor geralmente são cobrados por minuto (ou até por segundo). Isso significa que os clientes pagam apenas pelo tempo em que o código está realmente sendo executado. Isso se destaca em relação à máquina virtual em nuvem tradicional, onde a máquina permanece ociosa a maior parte do tempo, mas ainda assim é paga.
- O problema da escalabilidade também foi resolvido. Os recursos em estruturas sem servidor são alocados dinamicamente, permitindo que o sistema lide facilmente com picos inesperados de demanda.
Em resumo, os modelos sem servidor oferecem soluções flexíveis, econômicas e escaláveis. É surpreendente que não tenhamos pensado nessa ideia antes.
É realmente uma ideia nova?
Na verdade, a ideia não é nova. O conceito de permitir que os usuários paguem apenas pelo tempo em que o código está realmente em execução existe desde que foi introduzido no âmbito de em 2006, e mais ou menos na mesma época, o Google App Engine ofereceu uma solução muito semelhante.
Na verdade, o que agora chamamos de modelo "sem servidor" é mais antigo do que muitas tecnologias que hoje chamamos de "nativas de nuvem" e que proporcionam quase as mesmas funcionalidades. Como já foi mencionado, os modelos sem servidor são essencialmente uma continuação do modelo de negócios SaaS, que já existe há várias décadas.
É importante reconhecer que o modelo serverless não é uma arquitetura FaaS, embora haja uma conexão entre eles. FaaS é, na essência, a parte da arquitetura serverless voltada para computação, mas não representa todo o sistema como um todo.
Mas qual é toda essa agitação? Bem, à medida que a velocidade de penetração da internet nos países em desenvolvimento continua a crescer rapidamente, a demanda por recursos computacionais também aumenta. Por exemplo, em muitos países com setores de comércio eletrônico de rápido crescimento, simplesmente não há infraestrutura computacional para aplicativos nessas plataformas. É aqui que as plataformas serverless pagas entram em cena.
Problemas dos modelos serverless
A questão é que os modelos serverless têm… problemas. Não me entenda mal: não estou dizendo que eles são ruins por si só ou que não oferecem valor significativo para algumas empresas em certas circunstâncias. Mas a principal alegação da 'revolução' — que a arquitetura serverless rapidamente substituirá a tradicional — nunca se concretizará.
Aqui está o porquê.
Suporte limitado a linguagens de programação
A maioria das plataformas serverless permite executar apenas aqueles aplicativos que são escritos em determinadas linguagens. Isso limita severamente a flexibilidade e a adaptabilidade desses sistemas.
Acredita-se que as plataformas serverless suportam a maioria das principais linguagens. AWS Lambda e Azure Functions também fornecem um contêiner para executar aplicativos e funções em linguagens não suportadas, embora isso muitas vezes venha com custos de desempenho. Assim, para a maioria das organizações, essa limitação geralmente não é muito significativa. Mas aqui está o detalhe. Supõe-se que uma das vantagens dos modelos serverless é que programas pouco conhecidos e raramente utilizados podem ser usados de forma mais econômica, uma vez que você paga apenas pelo tempo de execução deles. E programas pouco conhecidos e raramente usados muitas vezes são escritos em… linguagens de programação pouco conhecidas e raramente utilizadas.
Isso mina uma das principais vantagens do modelo serverless.
Vinculação ao fornecedor
O segundo problema com plataformas serverless ou, pelo menos, como elas estão sendo implementadas atualmente, é que geralmente não se parecem umas com as outras em nível operacional. Praticamente não há padronização em termos de escrita de funções, implantação e gerenciamento. Isso significa que a migração de funções de uma plataforma para outra leva um tempo extremamente longo.
A parte mais difícil da transição para o modelo serverless não são as funções computacionais, que geralmente são apenas fragmentos de código, mas como as aplicações estão conectadas a sistemas adjuntos, como armazenamento de objetos, gerenciamento de identidade e filas. As funções podem ser movidas, mas o restante da aplicação não pode. Isso é o oposto completo das plataformas prometidas como baratas e flexíveis.
Alguns afirmam que os modelos serverless surgiram recentemente e que não houve tempo para padronizar seu funcionamento. No entanto, eles não são tão novos assim, como já mencionei acima, e muitas outras tecnologias em nuvem, como contêineres, já se tornaram muito mais convenientes devido ao desenvolvimento e à ampla adoção de boas normas.
Desempenho
O desempenho computacional das plataformas serverless é difícil de medir, em parte porque os fornecedores tentam manter as informações em segredo. A maioria afirma que as funções em plataformas serverless remotas funcionam tão rápido quanto em servidores internos, com exceção de alguns problemas inevitáveis de latência.
No entanto, alguns fatos individuais indicam o contrário. Funções que não eram executadas em uma determinada plataforma ou que não foram executadas por algum tempo, exigem um certo tempo para inicialização. Provavelmente, isso se deve ao fato de que seu código foi transferido para um armazenamento de dados menos acessível, embora — como no caso dos benchmarks — a maioria dos fornecedores não informe sobre a transferência de dados.
Claro, existem algumas maneiras de contornar isso. Uma delas é otimizar as funções para qualquer linguagem de nuvem que sua plataforma serverless utilize, mas isso compromete um pouco a afirmação de que essas plataformas são "flexíveis".
Uma abordagem alternativa consiste em garantir a execução regular de programas críticos para o desempenho, para que eles permaneçam "frescos". Essa segunda abordagem, é claro, contraria um pouco a afirmação de que plataformas serverless são mais econômicas, pois você paga apenas pelo tempo em que seus programas estão em execução. Os provedores de nuvem implementaram novas maneiras de reduzir os tempos de inicialização a frio, mas muitos deles exigem "escalonamento para um" (scale to one), o que compromete o valor inicial do FaaS.
O problema do "início a frio" pode ser parcialmente resolvido ao executar sistemas serverless por conta própria, mas isso vem com seus próprios custos e continua sendo uma opção de nicho para equipes bem financiadas.
Você não pode executar aplicativos inteiros.
Finalmente, talvez a razão mais importante pela qual arquiteturas serverless não substituirão os modelos tradicionais tão cedo: em geral, não é possível executar aplicativos inteiros nelas.
Mais precisamente, isso não é economicamente viável. Seu monólito bem-sucedido provavelmente não vale a pena ser convertido em um conjunto de quatro dezenas de funções ligadas por oito gateways, quarenta filas e uma dúzia de instâncias de banco de dados. Por essa razão, serverless é mais adequado para novos desenvolvimentos. Praticamente nenhum aplicativo existente (arquitetura) pode ser transferido. Você pode migrar, mas terá que começar do zero.
Isso significa que, na grande maioria dos casos, plataformas serverless são usadas como um complemento aos servidores internos para executar tarefas que exigem grande poder de computação. Isso as diferencia muito das outras duas formas de tecnologia em nuvem — contêineres e máquinas virtuais, que oferecem uma maneira integrada de realizar computações remotas. Isso ilustra uma das dificuldades de transição de microsserviços para sistemas serverless.
Claro, isso nem sempre representa um problema. A capacidade de usar periodicamente enormes recursos computacionais, sem precisar comprar hardware próprio, pode trazer benefícios reais e duradouros para muitas organizações. Mas se alguns aplicativos estão em servidores internos e outros estão em arquiteturas de nuvem sem servidor, a gestão se torna significativamente mais complexa.
Viva a revolução?
Apesar de todas essas reclamações, eu não sou contra soluções sem servidor como um todo. Palavra de honra. Apenas os desenvolvedores devem entender — especialmente se estiverem explorando modelos sem servidor pela primeira vez — que essa tecnologia não é uma substituição direta dos servidores. Em vez disso, consulte nossas dicas e recursos sobre e decida como aplicar melhor esse modelo.
Fonte: habr.com
