Embora as tecnologias serverless tenham ganhado popularidade rapidamente nos últimos anos, ainda existem muitos equívocos e preocupações relacionadas a elas. Dependência de fornecedor, ferramentas, gerenciamento de custos, inicialização fria, monitoramento e ciclo de vida do desenvolvimento — todos esses tópicos são amplamente discutidos quando se fala em tecnologias serverless. Neste artigo, vamos explorar alguns dos temas mencionados e compartilhar dicas e links para fontes úteis que ajudarão os novatos a criar aplicações serverless poderosas, flexíveis e econômicas.
Equívocos sobre tecnologias serverless
Muitos consideram que serverless e processamento de dados de forma não servidor (, FaaS) são quase a mesma coisa. Isso significa que a diferença não é muito grande e vale a pena implementar a novidade. Embora o AWS Lambda tenha sido uma das 'estrelas' do auge das tecnologias serverless e um dos elementos mais populares da arquitetura serverless, essa arquitetura representa algo mais do que FaaS.
O princípio fundamental das tecnologias serverless é que você não precisa se preocupar em gerenciar e escalar a infraestrutura, você paga apenas pelo que usa. Muitos serviços se encaixam nesses critérios — AWS DynamoDB, S3, SNS ou SQS, Graphcool, Auth0, Now, Netlify, Firebase e muitos outros. De maneira geral, o serverless implica o uso de todas as capacidades da computação em nuvem sem a necessidade de gerenciar e otimizar a infraestrutura para escalabilidade. Isso também significa que a segurança em nível de infraestrutura não é mais um problema seu, o que é uma enorme vantagem, considerando a dificuldade e complexidade de conformidade com padrões de segurança. Finalmente, você não precisa comprar a infraestrutura que lhe é fornecida.
Serverless pode ser considerado um 'estado de espírito': uma certa mentalidade ao projetar soluções. Evite abordagens que exigem manutenção de qualquer infraestrutura. Com a abordagem serverless, gastamos tempo resolvendo problemas que impactam diretamente o projeto e geram benefícios para nossos usuários: criamos lógica de negócios robusta, desenvolvemos interfaces de usuário e projetamos APIs adaptativas e confiáveis.
Por exemplo, se for possível evitar a gestão e a manutenção de uma plataforma de busca em texto livre, é exatamente assim que agiremos. Essa abordagem para a construção de aplicativos pode acelerar significativamente o lançamento de produtos no mercado, pois você não precisa mais se preocupar em gerenciar uma infraestrutura complexa. Livre-se das responsabilidades e custos de gestão da infraestrutura e concentre-se na criação de aplicativos e serviços que seus clientes precisam. Patrick Debois chamou essa abordagem , este termo foi aceito na comunidade serverless. As funções devem ser vistas como um elo de ligação para serviços na forma de módulos implantáveis (em vez de implantar uma biblioteca inteira ou um aplicativo web). Isso proporciona uma granulação incrível no gerenciamento de implantações e mudanças no aplicativo. Se você não consegue implantar funções dessa maneira, isso pode indicar que as funções estão realizando tarefas demais e precisam ser refatoradas.
Alguns se incomodam com a dependência do fornecedor ao desenvolver aplicações em nuvem. O mesmo se aplica a tecnologias sem servidor, e provavelmente isso não é um equívoco. Com base em nossa experiência, a criação de aplicações sem servidor na AWS, combinada com a capacidade da AWS Lambda de integrar outros serviços da AWS, é um dos fatores que fortalece as vantagens das arquiteturas sem servidor. Este é um bom exemplo de sinergia, onde o resultado da combinação é maior do que apenas a soma das partes. Tentando evitar a dependência do fornecedor, você pode enfrentar problemas ainda maiores. Ao trabalhar com contêineres, é mais fácil gerenciar seu próprio nível de abstração entre os provedores de nuvem. Mas quando se trata de soluções sem servidor, os esforços não compensam, especialmente se desde o início considerarmos a eficiência econômica. Certifique-se de entender como os fornecedores garantem a prestação de serviços. Alguns serviços especializados dependem de pontos de integração com outros fornecedores e podem oferecer a capacidade de conexão de forma plug-and-play. É mais simples invocar Lambda a partir de um endpoint de gateway API do que encaminhar uma solicitação para um contêiner ou instância EC2. A Graphcool oferece uma configuração simples com Auth0, o que é mais fácil do que usar ferramentas de autenticação de terceiros.
Escolher o fornecedor certo para sua aplicação sem servidor é uma decisão de nível arquitetônico. Ao criar uma aplicação, você não espera um dia voltar a gerenciar servidores. A escolha de um fornecedor de nuvem não é diferente de decidir sobre o uso de contêineres ou bancos de dados, ou mesmo uma linguagem de programação.
Considere:
- Quais serviços você precisa e por quê.
- Quais serviços os provedores de nuvem oferecem e como você pode integrá-los com a solução FaaS escolhida.
- Quais linguagens de programação são suportadas (com tipagem dinâmica ou estática, compiladas ou interpretadas, quais são os benchmarks, qual é o desempenho no cold start, como é o ecossistema open source, etc.).
- Quais são suas exigências de segurança (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
- Como gerenciar seu CI/CD e ciclos de desenvolvimento de software.
- De quais soluções da classe infrastructure-as-code você pode se beneficiar.
Se você está expandindo um aplicativo existente e adicionando funções serverless incrementalmente, isso pode limitar um pouco as opções disponíveis. No entanto, quase todas as tecnologias serverless oferecem alguma API (via REST ou filas de mensagens), permitindo que extensões sejam criadas independentemente do núcleo do aplicativo e com fácil integração. Procure serviços com APIs claras, boa documentação e uma comunidade forte, e você não errará. A simplicidade de integração pode muitas vezes ser a métrica-chave, e provavelmente é uma das principais razões para o sucesso da AWS desde que o Lambda foi lançado em 2015.
Quando a serverless é útil
As tecnologias serverless podem ser aplicadas praticamente em qualquer lugar. No entanto, suas vantagens não se limitam apenas aos métodos de aplicação. O ponto de entrada para a computação em nuvem hoje é tão baixo devido precisamente às tecnologias serverless. Se os desenvolvedores têm uma ideia, mas não sabem como gerenciar a infraestrutura em nuvem e otimizar custos, não precisam procurar um engenheiro para isso. Se uma startup quer criar uma plataforma, mas teme que os custos possam sair do controle, ela pode facilmente recorrer a soluções serverless.
Devido à economia de custos e à simplicidade de escalabilidade, as soluções serverless são aplicáveis tanto para sistemas internos quanto externos, até mesmo para um aplicativo web com milhões de usuários. As contas são medidas mais em centavos do que em euros. Alugar a instância mais simples da AWS EC2 (t1.micro) durante um mês custará €15, mesmo que você não faça nada com ela (quem nunca esqueceu de desligá-la?!). Para comparação, para alcançar esse nível de gastos no mesmo período, você precisaria executar o Lambda de 512 MB por 1 segundo aproximadamente 3 milhões de vezes. E se você não usar essa função, não paga nada.
Como a tecnologia serverless depende principalmente de eventos, é bastante fácil adicionar uma infraestrutura serverless a sistemas antigos. Por exemplo, com AWS S3, Lambda e Kinesis, você pode criar um serviço analítico para um antigo sistema de varejo que pode receber dados através da API.
A maioria das plataformas serverless suporta diferentes linguagens. As mais comuns são Python, JavaScript, C#, Java e Go. Geralmente, não há limitações no uso de bibliotecas em todas essas linguagens, então você pode usar suas bibliotecas open-source favoritas. No entanto, é recomendável não exagerar nas dependências, para que suas funções sejam executadas de forma otimizada e não percam as vantagens da enorme escalabilidade de suas aplicações serverless. Quanto mais pacotes precisarem ser carregados no container, mais longo será o tempo de inicialização a frio.
A inicialização a frio é quando é necessário primeiro inicializar o container, o ambiente de execução e o manipulador de erros antes de usá-los. Devido a isso, o tempo de execução das funções pode chegar a 3 segundos, o que não é ideal para usuários impacientes. No entanto, inicializações a frio ocorrem na primeira chamada após alguns minutos de inatividade da função. Portanto, muitos consideram isso um inconveniente menor que pode ser contornado com o ping regular da função, para mantê-la em funcionamento. Ou simplesmente ignoram esse aspecto.
Embora a AWS tenha lançado, os bancos de dados SQL não são ideais para esse tipo de aplicação, já que durante a execução de transações eles dependem de conexões, que podem rapidamente se tornar um gargalo com um grande tráfego no AWS Lambda. Sim, os desenvolvedores estão constantemente melhorando o Serverless Aurora, e você deve experimentar com ele, mas hoje as soluções NoSQL, como, são muito mais adequadas para sistemas serverless. No entanto, é certo que essa situação mudará em breve.
As ferramentas também impõem muitas limitações, especialmente em termos de teste local. Embora existam soluções como Docker-Lambda, DynamoDB Local e LocalStack, elas exigem trabalho meticuloso e uma quantidade significativa de configuração. No entanto, todos esses projetos estão em desenvolvimento ativo, portanto, é apenas uma questão de tempo até que as ferramentas atinjam o nível necessário.
O impacto das tecnologias serverless no ciclo de desenvolvimento
Como sua infraestrutura é apenas uma configuração, você pode definir e implantar o código usando scripts, como scripts de shell. Ou pode optar por soluções do tipo configuration-as-code, como Embora este serviço não forneça uma configuração para todas as áreas, ele permite definir recursos específicos para serem usados como funções Lambda. Ou seja, onde o CloudFormation deixar a desejar, você pode implementar seu próprio recurso (função Lambda) para preencher essa lacuna. Assim, você pode fazer qualquer coisa, até mesmo configurar dependências fora do seu ambiente AWS.
Como tudo isso é apenas configuração, você pode parametrizar seus scripts de implantação para ambientes, regiões e usuários específicos, especialmente se estiver utilizando soluções do tipo infrastructure-as-code como o CloudFormation. Por exemplo, você pode implantar uma cópia da infraestrutura para cada branch no repositório, permitindo testes completamente isolados durante o desenvolvimento. Isso acelera radicalmente o feedback dos desenvolvedores na hora de entender se o código funciona adequadamente em um ambiente ativo. Os gerentes não precisam se preocupar com o custo de implantar múltiplos ambientes, já que apenas o uso real é cobrado.
Os DevOps têm menos preocupações, pois precisam apenas garantir que os desenvolvedores tenham a configuração correta. Não é mais necessário gerenciar instâncias, balanceadores ou grupos de segurança. Por isso, o termo NoOps está se tornando cada vez mais comum, embora ainda seja importante saber como configurar a infraestrutura, especialmente em relação à configuração IAM e à otimização dos recursos de nuvem.
Existem ferramentas muito poderosas para monitoramento e visualização, como Epsagon, Thundra, Dashbird e IOPipe. Elas permitem acompanhar o estado atual de aplicações serverless, fornecem logs e rastreamento, registram métricas de desempenho e gargalos da arquitetura, além de realizar análises e previsões de gastos, entre outros. Essas ferramentas não apenas oferecem aos engenheiros DevOps, desenvolvedores e arquitetos uma visão abrangente do funcionamento das aplicações, mas também permitem que os gerentes monitorem a situação em tempo real, com gastos de recursos por segundo e previsões de custos. Organizar isso com uma infraestrutura gerenciada é muito mais difícil.
Projetar aplicativos sem servidor é significativamente mais fácil, pois não é necessário implantar servidores web, gerenciar máquinas virtuais ou contêineres, aplicar patches em servidores, sistemas operacionais, gateways de internet, etc. A abstração de todas essas responsabilidades permite que a arquitetura sem servidor se concentre no principal: atender às necessidades de negócios e clientes.
Embora as ferramentas possam ser melhores (elas melhoram a cada dia), os desenvolvedores podem se concentrar na implementação da lógica de negócios e na melhor distribuição da complexidade do aplicativo entre os diferentes serviços dentro da arquitetura. O gerenciamento de aplicativos sem servidor é baseado em eventos e abstrato pelo provedor de nuvem (por exemplo, SQS, eventos S3 ou fluxos DynamoDB). Portanto, os desenvolvedores só precisam escrever a lógica de negócios para reagir a certos eventos e não se preocupar com a melhor forma de implementar bancos de dados e filas de mensagens, ou como organizar o trabalho ideal com dados em armazenamento de hardware específicos.
O código pode ser executado e depurado localmente, como em qualquer processo de desenvolvimento. Os testes de unidade permanecem os mesmos. A capacidade de implantar toda a infraestrutura de um aplicativo por meio de uma configuração de pilha personalizável permite que os desenvolvedores obtenham rapidamente feedback importante, sem se preocupar com o custo dos testes ou o impacto em ambientes gerenciados caros.
Ferramentas e métodos para construir aplicativos sem servidor
Não existe uma maneira específica de construir aplicativos sem servidor. Nem um conjunto de serviços para essa tarefa. O líder entre as poderosas soluções sem servidor hoje em dia é a AWS, mas não deixe de considerar também , e . Se você estiver usando a AWS, uma abordagem recomendada para a construção de aplicativos é o (SAM), especialmente ao usar C#, pois o Visual Studio oferece excelentes ferramentas. O SAM CLI pode fazer tudo o que o Visual Studio faz, então você não perderá nada se mudar para outro IDE ou editor de texto. Claro, o SAM também funciona com outras linguagens.
Se você está programando em outras linguagens, o Serverless Framework é uma excelente ferramenta open source que permite configurar qualquer coisa com arquivos de configuração YAML muito poderosos. Além disso, o Serverless Framework suporta diversos serviços em nuvem, sendo recomendado para quem busca uma solução multicloud. Possui uma enorme comunidade que criou uma série de plugins para diferentes necessidades.
Para testes locais, ferramentas open source como Docker-Lambda, Serverless Local, DynamoDB Local e LocalStack são bastante adequadas. As tecnologias serverless ainda estão em uma fase inicial de desenvolvimento, assim como as ferramentas para elas, então a configuração para cenários de teste complexos pode exigir esforço. No entanto, dispor de uma pilha em um ambiente e testá-la é incrivelmente barato. E você não precisa criar uma cópia local exata dos ambientes em nuvem.
Para reduzir o tamanho dos pacotes implantados e acelerar o carregamento, use AWS Lambda Layers.
Use as linguagens de programação corretas para tarefas específicas. Cada linguagem tem suas vantagens e desvantagens. Há muitos benchmarks, mas JavaScript, Python e C# (.NET Core 2.1+) são os líderes em termos de desempenho no AWS Lambda. Recentemente, o AWS Lambda introduziu a Runtime API, que permite especificar a linguagem e o ambiente de execução desejados, então sinta-se à vontade para experimentar.
Mantenha o tamanho dos pacotes de implantação pequeno. Quanto menores forem, mais rápido serão carregados. Evite usar bibliotecas grandes, especialmente se você só utilizar algumas funcionalidades delas. Se programar em JavaScript, use ferramentas de build como Webpack para otimizar a construção e incluir apenas o que realmente precisa. No .NET Core 3.0, há QuickJit e Compilação em Nível que melhoram o desempenho e ajudam bastante em inicializações a frio.
A dependência de funções serverless em eventos pode inicialmente dificultar a coordenação da lógica de negócios. Por isso, filas de mensagens e máquinas de estado podem ser extremamente úteis. Funções Lambda podem invocar umas às outras, mas faça isso apenas se não esperar uma resposta (‘disparou e esqueceu’) — você não quer pagar pela espera da conclusão de outra função. As filas de mensagens são úteis para isolar partes da lógica de negócios, gerenciar gargalos de aplicativos e processar transações (usando filas FIFO). Funções do AWS Lambda podem ser associadas a filas SQS como filas de ‘mensagens pendentes’, que monitoram mensagens com falha para posterior análise. As funções do AWS Step Functions (máquinas de estado) são muito úteis para gerenciar processos complexos que exigem a criação de cadeias de funções. Em vez de uma função Lambda chamar outra função, as Step Functions podem coordenar transições de estado, transferir dados entre funções e gerenciar o estado global das funções. Isso permite definir condições de tentativas novamente, ou o que deve ser feito ao ocorrer um erro específico — em certas condições, uma ferramenta muito poderosa.
Conclusão
Nos últimos anos, as tecnologias serverless têm evoluído a um ritmo sem precedentes. Essa mudança de paradigma está ligada a certos equívocos. Graças à abstração da infraestrutura e do gerenciamento da escalabilidade, soluções serverless oferecem vantagens significativas: desde a simplificação do desenvolvimento e processos de DevOps, até uma grande redução nos custos operacionais.
E embora a abordagem serverless tenha suas desvantagens, existem métodos confiáveis e padrões de design que podem ser utilizados para criar aplicativos serverless robustos ou integrar elementos serverless em arquiteturas existentes.
Fonte: habr.com
