Embora as tecnologias sem servidor tenham ganhado popularidade rapidamente nos últimos anos, ainda existem muitos equívocos e medos associados a elas. Dependência de fornecedores, ferramentas, gerenciamento de custos, inicialização a frio, monitoramento e ciclo de vida de desenvolvimento são tópicos importantes quando se trata de tecnologias sem servidor. Neste artigo, exploraremos alguns dos tópicos mencionados, bem como compartilharemos dicas e links para fontes úteis de informações para ajudar os iniciantes a criar aplicativos sem servidor poderosos, flexíveis e econômicos.
Equívocos sobre tecnologias sem servidor
Muitas pessoas pensam que o processamento sem servidor e sem servidor (, FaaS) são quase a mesma coisa. Isso significa que a diferença não é muito grande e vale a pena apresentar uma novidade. Embora o AWS Lambda tenha sido uma das estrelas do apogeu sem servidor e um dos elementos mais populares da arquitetura sem servidor, essa arquitetura é muito mais do que FaaS.
O princípio básico por trás das tecnologias sem servidor é que você não precisa se preocupar em gerenciar e dimensionar sua infraestrutura, você só paga 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. Em geral, sem servidor significa usar todo o poder da computação em nuvem sem a necessidade de gerenciar a infraestrutura e otimizá-la para dimensionamento. Isso também significa que a segurança no nível da infraestrutura não é mais sua preocupação, o que é um grande benefício, dada a dificuldade e a complexidade de atender aos padrões de segurança. Finalmente, você não precisa comprar a infraestrutura fornecida a você.
Serverless pode ser considerado um “estado de espírito”: uma certa mentalidade ao projetar soluções. Evite abordagens que exijam manutenção de qualquer infraestrutura. Com uma abordagem sem servidor, gastamos tempo resolvendo tarefas que afetam diretamente o projeto e trazem benefícios para nossos usuários: criamos lógica de negócios sustentável, desenvolvemos interfaces de usuário e desenvolvemos APIs adaptáveis e confiáveis.
Por exemplo, se for possível evitar o gerenciamento e manutenção de uma plataforma de pesquisa de texto livre, é isso que faremos. Essa abordagem para criar aplicativos pode acelerar muito o tempo de lançamento no mercado, porque você não precisa mais pensar em gerenciar uma infraestrutura complexa. Elimine as responsabilidades e os custos do gerenciamento de infraestrutura e concentre-se na criação dos aplicativos e serviços de que seus clientes precisam. Patrick Debois chamou essa abordagem , o termo é adotado na comunidade serverless. As funções devem ser pensadas como um link para serviços como módulos implantáveis (em vez de implantar uma biblioteca inteira ou aplicativo da web). Isso fornece uma granularidade incrível para gerenciar a implantação e as alterações no aplicativo. Se você não puder implantar funções dessa maneira, isso pode indicar que as funções executam muitas tarefas e precisam ser refatoradas.
Alguns ficam confusos com a dependência do fornecedor ao desenvolver aplicativos em nuvem. O mesmo se aplica às tecnologias sem servidor, e isso não é um equívoco. Em nossa experiência, a criação de aplicativos sem servidor na AWS, combinada com a capacidade do AWS Lambda de agrupar outros serviços da AWS, faz parte da força das arquiteturas sem servidor. Este é um bom exemplo de sinergia, quando o resultado da combinação é mais do que a soma dos termos. Tentar evitar a dependência do fornecedor pode gerar ainda mais problemas. Ao trabalhar com contêineres, é mais fácil gerenciar sua própria camada de abstração entre provedores de nuvem. Mas quando se trata de soluções sem servidor, o esforço não compensa, especialmente se o custo-benefício for levado em consideração desde o início. Certifique-se de descobrir como os fornecedores fornecem serviços. Alguns serviços especializados dependem de pontos de integração com outros fornecedores e podem fornecer conectividade plug-and-play pronta para uso. É mais fácil fornecer uma chamada do Lambda de um endpoint de API de gateway do que fazer proxy da solicitação para algum contêiner ou instância do EC2. O Graphcool fornece configuração fácil com Auth0, que é mais fácil do que usar ferramentas de autenticação de terceiros.
Escolher o fornecedor certo para seu aplicativo sem servidor é uma decisão de arquitetura. Quando você cria um aplicativo, não espera um dia voltar a gerenciar servidores. Escolher um fornecedor de nuvem não é diferente de escolher usar contêineres ou um banco de dados, ou mesmo uma linguagem de programação.
Considerar:
- Quais serviços você precisa e por quê.
- Quais serviços os provedores de nuvem fornecem e como você pode combiná-los com a solução FaaS escolhida.
- Quais linguagens de programação são suportadas (com tipagem dinâmica ou estática, compilada ou interpretada, quais são os benchmarks, qual é o desempenho na inicialização a frio, qual é o ecossistema de código aberto, etc.).
- Quais são seus requisitos de segurança (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
- Como gerenciar seus ciclos de CI/CD e desenvolvimento de software.
- Quais soluções de infraestrutura como código você pode aproveitar.
Se você estender um aplicativo existente e adicionar incrementalmente a funcionalidade sem servidor, isso poderá limitar um pouco os recursos disponíveis. No entanto, quase todas as tecnologias sem servidor fornecem algum tipo de API (via REST ou filas de mensagens) que permite criar extensões independentes 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 facilidade de integração geralmente pode ser uma métrica importante e é provavelmente uma das principais razões pelas quais a AWS tem sido tão bem-sucedida desde que o Lambda foi lançado em 2015.
Quando sem servidor é bom
As tecnologias sem servidor podem ser aplicadas em quase todos os lugares. No entanto, suas vantagens não se limitam a apenas uma forma de aplicação. A barreira de entrada para a computação em nuvem hoje é tão baixa graças às tecnologias sem servidor. Se os desenvolvedores têm uma ideia, mas não sabem como gerenciar a infraestrutura de nuvem e otimizar custos, não precisam procurar algum tipo de engenheiro para fazer isso. Se uma startup deseja construir uma plataforma, mas teme que os custos fiquem fora de controle, ela pode recorrer facilmente a soluções sem servidor.
Devido à economia de custos e à facilidade de dimensionamento, as soluções sem servidor são igualmente aplicáveis para sistemas internos e externos, até um aplicativo da Web com um público de vários milhões. As contas são medidas em vez de euros, mas em centavos. Alugar a instância mais simples do AWS EC2 (t1.micro) por um mês custará 15€, mesmo que não faça nada com ela (quem nunca se esqueceu de desligar?!). Em comparação, para atingir esse nível de gastos no mesmo período de tempo, você precisaria executar um Lambda de 512 MB por 1 segundo cerca de 3 milhões de vezes. E se você não usar esse recurso, não paga nada.
Como o serverless é principalmente orientado a eventos, é bastante fácil adicionar uma infraestrutura sem servidor a sistemas mais antigos. Por exemplo, usando AWS S3, Lambda e Kinesis, você pode criar um serviço de análise para um sistema de varejo antigo que pode receber dados por meio de uma API.
A maioria das plataformas sem servidor oferece suporte a vários idiomas. Na maioria das vezes é Python, JavaScript, C#, Java e Go. Normalmente não há restrições quanto ao uso de bibliotecas em todos os idiomas, portanto, você pode usar suas bibliotecas de código aberto favoritas. No entanto, é aconselhável não abusar das dependências para que suas funções tenham um desempenho ideal e não anule os benefícios da enorme escalabilidade de seus aplicativos serverless. Quanto mais pacotes precisarem ser carregados no contêiner, mais tempo levará a inicialização a frio.
Uma inicialização a frio é quando você precisa inicializar o contêiner, o tempo de execução e o manipulador de erros antes de usá-los. Por conta disso, o atraso na execução das funções pode chegar a 3 segundos, não sendo esta a melhor opção para usuários impacientes. No entanto, as partidas a frio ocorrem na primeira chamada após alguns minutos de função ociosa. Muitos consideram isso um pequeno aborrecimento que pode ser contornado fazendo ping regularmente na função para mantê-la ociosa. Ou eles ignoram esse aspecto completamente.
Embora a AWS tenha lançadoNo entanto, bancos de dados SQL não são ideais para esta aplicação, pois dependem de conexões para realizar transações, o que pode rapidamente se tornar um gargalo com tráfego intenso no AWS Lambda. Sim, os desenvolvedores estão constantemente aprimorando o Serverless Aurora e você deve experimentá-lo, mas hoje soluções NoSQL como. No entanto, não há dúvida de que essa situação mudará muito em breve.
O kit de ferramentas também impõe muitas restrições, especialmente no campo de testes locais. Embora existam soluções como Docker-Lambda, DynamoDB Local e LocalStack, elas exigem muito trabalho e uma quantidade significativa de configuração. No entanto, todos esses projetos são desenvolvidos ativamente, portanto, é apenas uma questão de tempo até que o kit de ferramentas atinja o nível de que precisamos.
O impacto das tecnologias sem servidor no ciclo de desenvolvimento
Como sua infraestrutura é apenas uma configuração, você pode definir e implantar código usando scripts, como shell scripts. Ou você pode recorrer a soluções de classe de configuração como código, como . Embora esse serviço não forneça configuração para todas as áreas, ele permite que você defina recursos específicos para usar como funções do Lambda. Ou seja, onde o CloudFormation falhar, você pode escrever seu próprio recurso (função Lambda) que fechará essa lacuna. Dessa forma, você pode fazer qualquer coisa, até mesmo configurar dependências fora do seu ambiente AWS.
Como tudo é apenas configuração, você pode personalizar seus scripts de implantação para ambientes, regiões e usuários específicos, especialmente se estiver usando soluções de infraestrutura como código, como o CloudFormation. Por exemplo, você pode implantar uma cópia da infraestrutura para cada ramificação no repositório para que possa testá-los completamente de forma isolada durante o desenvolvimento. Isso acelera drasticamente o feedback para os desenvolvedores quando eles querem entender se seu código funciona adequadamente em um ambiente ao vivo. Os gerentes não precisam se preocupar com o custo de implantação de vários ambientes, pois pagam apenas pelo uso real.
Os DevOps têm menos preocupações, pois precisam apenas garantir que os desenvolvedores tenham a configuração correta. Você não precisa mais gerenciar instâncias, balanceadores ou security groups. Portanto, o termo NoOps é cada vez mais usado, embora ainda seja importante poder configurar a infraestrutura, principalmente quando se trata de configuração de IAM e otimização de recursos de nuvem.
Existem ferramentas de monitoramento e visualização muito poderosas como Epsagon, Thundra, Dashbird e IOPipe. Eles permitem que você monitore o estado atual de seus aplicativos sem servidor, forneça registro e rastreamento, capture métricas de desempenho e gargalos de arquitetura, realize análises e previsões de custos e muito mais. Eles não apenas fornecem aos engenheiros, desenvolvedores e arquitetos do DevOps uma visão abrangente do desempenho do aplicativo, mas também permitem que os gerentes monitorem a situação em tempo real, com custos de recursos por segundo e previsão de custos. É muito mais difícil organizar isso com uma infraestrutura gerenciada.
Projetar aplicativos sem servidor é muito mais fácil porque você não precisa implantar servidores da Web, gerenciar máquinas virtuais ou contêineres, corrigir servidores, sistemas operacionais, gateways de Internet, etc. Ao abstrair todas essas responsabilidades, uma arquitetura sem servidor pode se concentrar no núcleo - a solução. as necessidades do negócio e do cliente.
Embora o kit de ferramentas pudesse ser melhor (fica melhor 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 em diferentes serviços dentro da arquitetura. O gerenciamento de aplicativos sem servidor é baseado em eventos e abstraído pelo provedor de nuvem (por exemplo, eventos SQS, S3 ou fluxos do DynamoDB). Portanto, os desenvolvedores precisam apenas escrever a lógica de negócios para responder a determinados eventos e não precisam se preocupar com a melhor forma de implementar bancos de dados e filas de mensagens ou como organizar o trabalho ideal com dados em armazenamentos de hardware específicos.
O código pode ser executado e depurado localmente, como em qualquer processo de desenvolvimento. O teste de unidade continua o mesmo. A capacidade de implantar toda uma infraestrutura de aplicativos com uma configuração de pilha personalizada permite que os desenvolvedores obtenham feedback importante rapidamente sem pensar no custo do teste ou no impacto em ambientes gerenciados caros.
Ferramentas e técnicas para criar aplicativos sem servidor
Não há uma maneira específica de criar aplicativos sem servidor. Bem como um conjunto de serviços para esta tarefa. A AWS é líder entre as poderosas soluções sem servidor hoje, mas veja também , и . Se você estiver usando a AWS, a abordagem recomendada para coletar aplicativos é (SAM), especialmente ao usar C#, porque o Visual Studio possui ótimas ferramentas. A SAM CLI pode fazer tudo o que o Visual Studio pode fazer, então você não perderá nada se mudar para outro IDE ou editor de texto. Claro, o SAM também funciona com outros idiomas.
Se você estiver escrevendo em outros idiomas, o Serverless Framework é uma excelente ferramenta de código aberto que permite configurar qualquer coisa com arquivos de configuração YAML muito poderosos. O Serverless Framework também oferece suporte a vários serviços em nuvem, por isso recomendamos para quem procura uma solução multi-cloud. Tem uma enorme comunidade que criou vários plugins para qualquer necessidade.
Para testes locais, as ferramentas de código aberto Docker-Lambda, Serverless Local, DynamoDB Local e LocalStack são adequadas. As tecnologias sem servidor ainda estão em seus estágios iniciais de desenvolvimento, assim como as ferramentas para elas, portanto, ao configurar cenários de teste complexos, você terá que trabalhar muito. No entanto, simplesmente implantar a pilha em um ambiente e testá-lo é incrivelmente barato. E você não precisa fazer uma cópia local exata dos ambientes de nuvem.
Use AWS Lambda Layers para reduzir o tamanho dos pacotes implantados e acelerar os downloads.
Use as linguagens de programação corretas para tarefas específicas. Diferentes idiomas têm suas próprias vantagens e desvantagens. Existem muitos benchmarks, mas JavaScript, Python e C# (.NET Core 2.1+) são os líderes em termos de desempenho do AWS Lambda. O AWS Lambda introduziu recentemente a API de tempo de execução, que permite especificar o idioma e o ambiente de tempo de execução desejados, então experimente.
Mantenha os tamanhos de pacote pequenos para implantação. Quanto menores eles são, mais rápido eles carregam. Evite usar bibliotecas grandes, especialmente se você usar alguns recursos delas. Se você estiver programando em JavaScript, use uma ferramenta de compilação como o Webpack para otimizar sua compilação e incluir apenas o que você realmente precisa. O .NET Core 3.0 possui QuickJit e Compilação em camadas que melhoram o desempenho e ajudam muito em partidas a frio.
A dependência de funções sem servidor em eventos pode dificultar a coordenação da lógica de negócios no início. Nesse sentido, filas de mensagens e máquinas de estado podem ser incrivelmente úteis. As funções do Lambda podem chamar umas às outras, mas faça isso apenas se você não estiver esperando uma resposta ("disparar e esquecer") - você não deseja ser cobrado por aguardar a 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). As funções do AWS Lambda podem ser atribuídas a filas SQS como filas de mensagens travadas que rastreiam as mensagens com falha para análise posterior. AWS Step Functions (máquinas de estado) são muito úteis para gerenciar processos complexos que requerem encadeamento de funções. Em vez de uma função Lambda chamar outra função, as funções Step podem coordenar transições de estado, passar dados entre funções e gerenciar o estado global das funções. Isso permite que você defina as condições de repetição ou o que fazer quando ocorrer um erro específico - uma ferramenta muito poderosa em determinadas condições.
Conclusão
Nos últimos anos, as tecnologias sem servidor têm se desenvolvido em um ritmo sem precedentes. Existem certos equívocos associados a essa mudança de paradigma. Ao abstrair a infraestrutura e dimensionar o gerenciamento, as soluções sem servidor oferecem benefícios significativos, desde processos simplificados de desenvolvimento e DevOps até reduções massivas nos custos operacionais.
Embora a abordagem sem servidor tenha suas desvantagens, existem padrões de design robustos que podem ser usados para criar aplicativos robustos sem servidor ou integrar elementos sem servidor em arquiteturas existentes.
Fonte: habr.com