Ultimamente, tenho visto muitos outtakes serverless e opiniões mistas online. Eles agitaram a comunidade e começaram uma discussão, o que é sempre bom.
Nesta postagem, refletirei sobre o estado atual do serverless, compartilharei minhas ideias sobre artigos da comunidade sobre serverless e discutirei o futuro do serverless.
Índice
Introdução
Mesmo que já tenham se passado quase cinco anos desde que comecei a usar serverless, ainda parece mágica para mim. Implantar código sem gerenciar a infraestrutura subjacente é libertador.
Além disso, a capacidade de criar arquiteturas orientadas a eventos construídas a partir de recursos gerenciados pela AWS ou integrações diretas que substituem o código dos contêineres é alucinante. Você pode construir serviços que, de outra forma, levariam anos em apenas alguns minutos. Ainda estou surpreso com o desempenho de replicação entre regiões das tabelas globais do DynamoDB.
A realidade é que o Serverless não é mais o garoto mais novo do pedaço (sim, GenAI, estou falando de você). O Lambda comemorou seu 10º aniversário este ano. É uma loucura — já são 10 anos! E você também pode argumentar que o primeiro serviço serverless foi o SQS, que foi lançado há duas décadas! O hype mudou, e isso é normal.
Qualquer tecnologia amadurece com o tempo. O Kubernetes não é mais "novo". Caramba, até o ChatGPT não é mais "novo". Escrevi um post sobre ele há um ano sobre como minha avó queria usá-lo.
Em algum momento, tecnologias e produtos atingem a maturidade, que é onde estamos atualmente. Minha opinião é que o Serverless amadureceu e se tornou um verdadeiro "cavalo de batalha" da nuvem - uma tecnologia incrível, escalável e confiável que resolve muitos problemas, mas (como qualquer outra) vem com seu próprio conjunto de limitações e aprendizados (mais sobre isso depois).
Leituras sem servidor na Web
Ultimamente, tenho visto muitos outtakes serverless e opiniões mistas online. Eles agitaram a comunidade e começaram uma discussão, o que é sempre bom.
Gostaria de compartilhar minhas ideias sobre alguns erros de serverless que vi nos últimos meses.
Artigos de Clickbait
Esta é uma generalização de uma tendência de artigos que vi: " A equipe X parou de usar o serverless e agora está 1000% melhor ".
Há muita desinformação e equívocos sobre serverless. Normalmente, nesses artigos, eles se referem somente ao Lambda.
Estamos em 2024 e, por algum motivo, as pessoas ainda veem o serverless apenas como Lambda (* facepalm *).
Há um mundo serverless lindo por aí com serviços básicos: S3, SNS, SQS, DynamoDB, EventBridge e muitos outros, que você pode (e deve!) usar com seu cluster K8S. Por que operar o Kafka quando você obtém a mesma, se não melhor, experiência com MSK ou SQS sem o custo de manutenção?
Segundo, como qualquer outra tecnologia, Lambda não é uma solução mágica para todos os problemas. Há problemas para os quais Lambda não se encaixa ( *suspiro* ) ou não faz sentido, e tudo bem!
Às vezes, você precisa de sessões de longa duração, com mais de 15 minutos. Ou usar GPU. Ou você quer lidar com padrões de tráfego previsíveis e OK com a construção no ECS Fargate. Os contêineres são fantásticos, e não ter que gerenciar a infraestrutura subjacente é ainda melhor.
O ponto principal que esses artigos ignoram é que só porque o Lambda não foi usado em um caso de uso específico não significa que o Lambda seja uma tecnologia falha. Significa apenas que ele não se encaixava nos requisitos daquele serviço específico.
Aliás, não tem problema misturar. Eu projetei um serviço em que parte é Lambda e parte contêineres. Não escolha uma solução porque é o que você sabe e sempre fez. Werner Vogels discutiu isso no AWS re:Invent 2023. Escolha a solução que se encaixa MELHOR nos requisitos e restrições do problema, ponto final, e não tenha medo de fazer as coisas de forma diferente do que você está acostumado.
Sem servidor e IA
A menos que você tenha vivido em uma caverna no mês passado, você provavelmente leu o post de Luc van Donkersgoed sobre serverless e IA. Se por acaso você perdeu, pedi ao ChatGPT para resumir para você:
Luc expressa preocupação de que o foco intenso da AWS em Generative AI (GenAI) ofusque a engenharia de nuvem tradicional e a infraestrutura principal. Ele destaca como os eventos e anúncios recentes da AWS têm sido predominantemente centrados em GenAI, deixando menos atenção e recursos para outras áreas essenciais, como bancos de dados, infraestrutura escalável e aplicativos sustentáveis. Luc argumenta que, embora o GenAI tenha seus benefícios, ele não pode substituir os elementos fundamentais da engenharia de nuvem e insta a AWS a equilibrar seu foco para melhor dar suporte aos desenvolvedores e às necessidades comerciais existentes. - ChatGPT 4o
Como engenheiro e arquiteto, concordo que prefiro ver menos recursos de IA e mais recursos sem servidor ou de infraestrutura. Estou cansado de ouvir sobre novos recursos de IA, mas não posso ignorar que o GenAI me tornou um engenheiro melhor e mais rápido. Não posso negar que alguns deles são realmente legais e têm um potencial incrível, como agentes Bedrock chamando APIs (veja meu post e impressões aqui ).
Agora, assumindo o aspecto de obsessão do cliente da AWS e suas necessidades comerciais. Eu não sou um cliente da AWS; minha empresa é, e essa é uma distinção significativa. Os clientes corporativos da CyberArk - querem que criemos recursos de IA e muitos deles. Há uma demanda real, e algumas das implementações estão melhorando a vida de nossos clientes. Então, dessa perspectiva, a AWS está fazendo o que seus clientes querem. No entanto, como a AWS chegou tarde ao jogo, estamos vendo essa onda interminável de recursos de IA.
Olhando para o futuro, acredito que a loucura da IA da AWS vai se acalmar em um ou dois anos, à medida que eles diminuírem a diferença, pelo menos até que a próxima onda surja.
Serverless como um produto Halo
Gregor Hohpe publicou outra leitura interessante intitulada: " AWS Lambda é um produto Halo? - Brilhante, avançado, com muitos fãs, mas sem adoção generalizada — as marcas registradas de um produto Halo. Parece AWS Lambda?".
Há alguns pontos positivos e outros sobre os quais tenho uma opinião diferente.
Vamos discutir o aspecto mainstream. O que isso realmente significa? É publicamente conhecido e usado, ou são apenas números de participação de mercado puros?
Lambda não substituirá completamente ECS ou EC2. Não era para ser.
Como mencionei acima, cada um tem seu lugar. É mainstream? Sim. As pessoas sabem disso e usam em empresas de grande porte.
Posso dizer isso com segurança porque, quando faço entrevistas para cargos de desenvolvedor na CyberArk, recebo currículos de engenheiros que afirmam conhecer Lambda, SQS, DynamoDB e outros serviços sem servidor — e eles realmente os conhecem.
Vamos continuar.
Discordo de frases como "Eu uso serverless principalmente para demonstrações" ou "EC2s são confiáveis" (dando a entender que Lambda não é?); bem, como escrevi no começo, serverless é mais do que apenas Lambda. Outros serverless são úteis mesmo se você estiver executando EC2s ou K8s.
Além disso, muitas empresas corporativas usam serverless na produção, e é altamente confiável. Na verdade, os resumos de eventos pós-falha da AWS dos últimos 13 anos mostram que o EC2 teve quatro interrupções específicas no ano anterior, com o Lambda tendo apenas uma.
Vamos falar sobre a seguinte citação:
Essas instâncias do EC2 não são tão atraentes, mas são bem compreendidas, confiáveis e têm custos previsíveis.
De acordo com o item número 4 do relatório sobre o estado dos custos da nuvem da DataDog, e eu cito:
Mais de 80 por cento dos gastos com contêineres são desperdiçados em recursos ociosos. Cerca de 54 por cento desses gastos desperdiçados são em cluster ocioso, que é o custo do superprovisionamento da infraestrutura do cluster.
Vamos ler isso de novo: 80%! Uau, que desperdício de recursos e dinheiro alucinante. Talvez os EC2s que hospedam soluções baseadas em contêineres e Kubernetes não sejam tão compreendidos assim, afinal?
Com o serverless, você não paga por recursos ociosos e não precisa gerenciar sua infraestrutura, o que reduz drasticamente seus custos — uma grande vitória para o serverless.
Vamos discutir a manutenção contínua.
Proteger EC2s ao longo do tempo não é fácil. Lidar com atualizações de SO e biblioteca às vezes não é nada simples. Nós literalmente tivemos uma das maiores interrupções em anos na semana passada — obrigado, CrowdStrike ! Fale sobre ter um custo de manutenção previsível.
Dê uma olhada no K8s também. Você ouve muitas histórias de terror sobre atualizações de versão, configuração de um cluster ou malha de serviço e outros problemas. Então por que o serverless está recebendo tanto calor? Isso porque, com o K8s, a equipe de infra cuida disso.
Com o serverless, cada desenvolvedor precisa aprender e entender os conceitos e escrever IaC que constrói as partes móveis da arquitetura serverless.
Vamos expandir esse ponto.
Desafios sem servidor
Gregor também faz bons pontos. Serverless, e Lambda como parte dele, é único (halo-ish), e como tal, você precisa aprender a tecnologia; você precisa REALMENTE entender para aproveitar ao máximo. Eu tropecei em um artigo de Sheen Brisals que discute se serverless é difícil ou não. Eu sugiro fortemente que você o leia.
Vamos discutir em detalhes o estado atual das dificuldades do serverless. Quero esclarecer: qualquer tecnologia vem com seu próprio conjunto de desafios. Cada desafio serverless que menciono é solucionável; é apenas uma questão de custo, conhecimento e ter as pessoas certas para conduzir a tecnologia dentro da sua organização.
Serverless não é uma solução mágica
O grande poder do serverless é que começar e se tornar produtivo é muito mais fácil. Pense em quanto tempo levaria para um desenvolvedor que nunca viu Lambda ou Kubernetes implantar um backend Hello World com API pública em ambos. Conforme você começa a construir aplicativos de produção mais realistas, a complexidade aumenta. Você deve cuidar da observabilidade, segurança, otimização de custos, tratamento de falhas, etc. Com o não serverless, essa responsabilidade geralmente recai sobre a equipe de operações. Com o serverless, geralmente recai sobre os desenvolvedores, onde há uma confusão considerável.
Vamos voltar ao exemplo da entrevista que eu estava usando.
Os desenvolvedores conheciam conceitos serverless. No entanto, a maioria deles se atrapalhou e falhou no segundo em que perguntei sobre técnicas de teste ou tratamento de falhas com DLQ e retries .
Serverless não é uma solução mágica que remove a complexidade de construir e executar aplicativos em nuvem. Ele pode ajudar você a reduzir significativamente a complexidade da manutenção da infraestrutura e focar na camada de aplicativo. No entanto, isso também vem com a nova complexidade de entender e aplicar padrões de aplicativos serverless, como usar DLQ , conceitos de arquitetura orientada a eventos e muito mais.
Desenvolvedores fazendo DevOps e engenharia de plataforma
Algumas empresas temem a mudança ou querem evitar o custo para fazer a mudança. O serverless requer uma mudança de cultura, melhor integração de desenvolvedores e alguém liderando o caminho nas melhores práticas e governança. Na minha empresa, tem sido a responsabilidade da engenharia de plataforma . Isso tem sido parte do meu trabalho. No entanto, muitas empresas não conectam a engenharia de plataforma com o serverless. Em escala, é essencial; você precisa de governança, segurança, otimizações de FinOps, melhores práticas gerais e alguém para possuí-lo.
Se não houver um proprietário concreto, a responsabilidade recai sobre cada desenvolvedor, e é demais.
Uma experiência de desenvolvedor deficiente e muitas opções
Se usar o serverless fosse tão fácil e óbvio, eu não precisaria escrever mais de 50 artigos ou compartilhar minhas visões pragmáticas sobre serverless noAWS re:Invent 2023 com meu parceiro no crime, Heitor Lessa.
Problemas como testes sem servidor, observabilidade sem servidor, aprender a escrever um manipulador Lambda adequado, lidar com isolamento de locatários, trabalhar com ferramentas de infraestrutura como código (muitas opções de AWS — SAM, CDK, Chalice, qual escolher e por quê?) e aprender todas as melhores práticas sobrecarregam desenvolvedores e gerentes.
A AWS publicou artigos sobre a maioria dos tópicos, mas há muitas opiniões, muitos projetos "olá, mundo" que são descontinuados em seis meses e poucos casos de uso avançados.
A AWS deve fornecer uma melhor experiência ao desenvolvedor para que eles não precisem se preocupar com esses tópicos e se concentrem em escrever lógica de negócios.
É solucionável
É solucionável, mas adotar qualquer nova tecnologia sempre, sempre, sempre (!) requer investimento . Na CyberArk, reduzimos esses desafios criando blueprints de autoatendimento e codificando blueprints e padrões arquitetônicos para que nossos desenvolvedores obtenham todas as melhores práticas imediatamente. Adicione workshops internos e compartilhamento de conhecimento a isso, e você estará no caminho certo. Escalamos de 10 desenvolvedores sem servidor para centenas.
Isso pode ser feito.
Compartilhei muitos insights sobrewebinars de horário comercial sem servidor da AWS e um artigo sobre a AWS e compartilharei nossa jornada no AWS Community Day DACH em setembro em Munique.
A Comunidade Sem Servidor
A comunidade sem servidor é nada menos que incrível .
Há eventos globais, dias sem servidor, dia do CDK, dias da comunidade AWS com toneladas de conteúdo sem servidor, defensores de desenvolvedores sem servidor AWS, construtores de comunidades AWS especializados em servidores sem servidor, heróis sem servidor AWS, boletins informativos sem servidor e assim por diante.
Especialistas estão compartilhando conhecimento como nunca antes. Até mesmo a documentação da AWS melhorou. E com a revolução da IA, escrever código serverless é mais fácil.
Quatro anos atrás, não era assim.
Bibliotecas de código aberto como Powertools para AWS Lambda mudaram a indústria. Elas recentemente ultrapassaram 100 bilhões de integrações de API por semana. O Powertools está tornando a vida dos clientes muito mais fácil no mundo todo.
Há até uma nova comunidade serverless no Discord chamada 'Believe in Serverless ', onde você pode facilmente se conectar com especialistas serverless e se envolver em discussões sobre a tecnologia. Este é um acesso sem precedentes a conselhos pragmáticos daqueles que realmente usam a tecnologia.
O futuro do serverless
Vamos esclarecer esta seção. Não sou um profeta; esta é apenas uma lista de desejos.
O futuro sem servidor será brilhante; o serverless não vai a lugar nenhum e não está morrendo.
No entanto, se a AWS quiser aumentar sua adoção, ela precisa melhorar os seguintes problemas:
Foco na experiência do desenvolvedor para recursos atuais e novos. Não libere o serviço sem logs de depuração (estou olhando para seus pipes do EventBridge , que levaram um ano para trazer logs de falhas).
Mais AWS Powertools, por favor ! Mais suportes de tempo de execução (RUST, Golang) e faça com que todos eles tenham paridade de recursos com a variação do Python, e estenda-a para contêineres, não apenas para Lambda. Por favor, invista nessa incrível equipe AWS DevEx.
Não coloque a tag 'serverless' em serviços que NÃO são genuinamente serverless . Se eu precisar configurar uma VPC ou pagar por tempo ocioso, não é serverless. Serviços mais novos, como Permissões Verificadas que atendem a esses requisitos, são incentivados.
Todos os novos serviços não computacionais DEVEM ser serverless . Não quero gerenciar infraestrutura nunca mais, então serverless deve ser o padrão.
Concentre-se em uma ferramenta IaC e faça o melhor possível. Para mim, a escolha óbvia é CDK. Concentre-se em lançar melhores construções CDK L2 e L3 que implementem as melhores práticas e segurança para transformar construções empadrões produtizados , como Jeremy Daly diz.
Teste e definição de função de passo - isso ainda é muito difícil de fazer. Vamos mudar isso. É um serviço obrigatório que recebe ódio dos desenvolvedores devido ao DevEx ruim.
Mantenha os projetos de exemplo do GitHub por pelo menos dois anos após a publicação e descontinue os projetos que não forem mais mantidos.
Seja mais pragmático. Começa com as sessões do AWS Summit e vai até o AWS re:Invent. Por favor, traga mais casos de uso técnico do cliente. Queremos aprender com ambientes de produção reais, não apenas com a teoria.
Forneça blueprints prontos e seguros para produção e configurações de projeto recomendadas, semelhantes ao que eu criei, o AWS Lambda handler cookbook . Talvez até mesmo endosse projetos da comunidade se você não tiver capacidade para criá-los.
Ajude-nos a lidar com o isolamento de inquilinos de uma maneira mais genérica e segura. Cada empresa lida com isso de forma diferente, e é muito propenso a erros.
Vamos ver a IA se infiltrar no serverless, especialmente no domínio IaC, e isso é bom. Ainda não experimentei o AWS App Studio . Por favor, não exagere (como Luc escreveu).
Esforce-se para tornar os recursos transparentes - insights do Lambda, por exemplo, em vez de ter eu, como usuário, anexando uma extensão do Lambda e gerenciando sua versão (o que não é uma ótima experiência; veja minha postagem sobre camadas do Lambda ), deixe-me fornecer um sinalizador CDK para a construção do Lambda, e você anexará a extensão nos bastidores e a gerenciará para mim.
O acesso entre contas em escala com serverless e EDA é desafiador; podemos e devemos simplificá-lo. Esses são desafios que vêm com essa arquitetura. Eu discuto isso na minha postagem de segurança .
Resumo
Houve muitos outtakes sem servidor e opiniões mistas online. Eles agitaram a comunidade e começaram uma discussão, o que é sempre bom. Isso me fez parar um momento para pensar sobre o estado atual e organizar meus pensamentos.
Espero que você tenha gostado de ler minha visão. O tempo dirá se eu estava certo ou não.
Obrigado Anton Aleksandrov, Bill Tarr e Johannes Koch por revisarem esta postagem e oferecerem insights.