BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Entendendo o Serverless: Dicas e recursos para construção de aplicações Servicefull

Entendendo o Serverless: Dicas e recursos para construção de aplicações Servicefull

Favoritos

Pontos Principais

  • Serverless é mais do que funções como serviço;
  • Não tema a dependência de um fornecedor. Utilize a capacidade que o mesmo provém a partir da integração por eventos;
  • Ferramentas Open source podem ajudar a simplificar a construção de aplicações complexas.
  • Utilize soluções de Infraestrutura como Código como CloudFormation para definir a arquitetura serverless e simplificar o processo de DevOps.
  • Soluções poderosas de monitoramento podem prover visibilidade de funções e desempenho das integrações com gerenciamento apurado de custos e ferramentas de estimativa.

Embora a tecnologia serverless tenha crescido rapidamente em popularidade nos últimos anos, ainda existem muitos conceitos equivocados e preocupações em relação às soluções. A dependência de fornecedores, o ferramental, o gerenciamento de custos, cold start, o monitoramento e o ciclo de vida de desenvolvimento do fornecedor são tópicos importantes no que diz respeito a essa tecnologia. Este artigo tem como objetivo abordar algumas dessas áreas, além de compartilhar dicas e recursos para orientar os novatos na arquitetura serverless a criar aplicações poderosas, flexíveis e econômicas.

Equívocos na tecnologia serverless

Um dos principais equívocos é pensar que o serverless e as Funções como serviço (ou FaaS) são a mesma coisa e, portanto, não é uma mudança particularmente radical que vale a pena adotar. Embora o AWS Lambda certamente tenha sido uma das estrelas da revolução serverless e, sem dúvida, um dos elementos mais populares dessa arquitetura, há muito mais a ser explorado no serverless que apenas no FaaS.

Um dos princípios básicos do serverless é que não precisamos nos preocupar com o gerenciamento de infraestrutura ou do dimensionamento e pagamos apenas pelo que usamos. Dado esses parâmetros, existem muitos serviços aos quais isso se aplica, como AWS DynamoDB, S3, SNS ou SQS, Graphcool, Auth0, Now, Netlify ou Firebase (dentre vários outros). Por fim, a arquitetura serverless oferece o poder da computação em nuvem sem o ônus e a responsabilidade de gerenciar a infraestrutura ou otimizar a escalabilidade. Essa abstração também significa que a segurança na camada de infraestrutura não é mais uma preocupação, o que, ao considerar a dificuldade e a complexidade de manter os padrões de segurança, é um benefício enorme. Por último, mas não menos importante, nos casos em que não estivermos usando toda a infraestrutura provisionada, não seremos cobrados por isso.

O serverless também pode ser considerada um "estado de espírito", uma mentalidade que se toma quando se trata de projetar a arquitetura de uma solução. Evite abordagens que exijam a manutenção de qualquer infraestrutura pois com o serveless estamos tentando redirecionar nosso tempo trabalhando em nosso projeto para coisas que têm um impacto mais direto e beneficiam nossos usuários, como lógica comercial robusta, interfaces de usuário envolventes e APIs responsivas e confiáveis. Se pudermos evitar o gerenciamento e a manutenção de uma plataforma de pesquisa de texto livre, contratando o serviço Algolia, por exemplo, é isso que faremos. A criação de aplicações seguindo esse modelo pode reduzir bastante o tempo de lançamento no mercado, pois não precisamos mais nos preocupar em gerenciar uma infraestrutura complexa. Evite a responsabilidade e o custo de gerenciar a infraestrutura e concentre-se na criação das aplicações e serviços que os clientes estão procurando. Patrick Debois se referiu a essa abordagem como "servicefull", que é um termo adotado pela comunidade serverless. As funções devem ser consideradas como a cola que une nossos serviços e conceituada como uma unidade implementável (em vez de implantar uma biblioteca ou uma aplicação Web inteira), permitindo um controle incrivelmente granular sobre implantações e alterações nas aplicações. Se não for possível implantar funções dessa maneira, pode haver uma possibilidade de código indicando que a função tem muita responsabilidade e deve ser refatorada.

Alguns arquitetos se preocupam com a dependência de um fornecedor ao desenvolver aplicações em nuvem. Com serverless, essa preocupação não é diferente e a princípio, isso decorre de um mal-entendido sobre o que realmente é o servidor. A experiência mostra que, construindo aplicações serverless na AWS, por exemplo, e abraçando as maneiras como o AWS Lambda trabalha, pode gerar a dependência com outros serviços da AWS, e justamente isso é parte do poder das arquiteturas serverless. É um exemplo forte de onde a soma é maior que as partes. Tentar evitar a dependência do fornecedor pode realmente causar problemas maiores do que imaginamos que estamos resolvendo. Ao trabalhar com containers, pode ser mais fácil gerenciar nossa própria camada de abstração entre provedores de nuvem, mas quando se trata de serverless, o esforço não valeria o custo, principalmente se consideramos a natureza econômica dos servidores serverless. Certifiquemos que estamos considerando como os fornecedores provém instalações para expor os serviços, já que alguns serviços especializados dependem de fortes pontos de integração com outros fornecedores e podem fornecer ganchos no estilo plug-and-play que já estão prontos para uso. É mais fácil projetar uma função Lambda que possa ser chamada de um endpoint no API Gateway do que projetá-la para ser uma chamada de um proxy de um container já existente ou de uma instância EC2. O Graphcool fornece uma configuração simples com Auth0, que é mais fácil do que usar um provedor de identidade personalizado.

Escolher o fornecedor certo para a aplicação serverless é uma decisão arquitetural. Nós não criamos uma aplicação serverless de forma que um dia possamos voltar ao gerenciamento de servidores. Escolher um fornecedor de nuvem não é diferente de escolher construir uma aplicação usando containers ou em qual banco de dados decidamos usar, ou mesmo em qual idioma escrevemos nosso código.

É bom considerar:

  • Quais serviços precisamos e por quê.
  • Os diferentes serviços em nuvem providos pelos fornecedores e como podemos utilizá-los integrados à implementação de FaaS escolhida.
  • Quais linguagens de programação são suportadas (digitação dinâmica versus estática, código compilado versus interpretado, benchmarking, desempenho de cold start, ecossistema de código aberto, etc.).
  • Quais são os nossos requisitos de segurança (SLAs, 2FA, OAuth, HTTPS, SSL etc.).
  • Como gerenciar o CI/CD e os ciclos de desenvolvimento de software.
  • Que tipo de solução de infraestrutura como código podemos aproveitar.

Se estivermos estendendo uma aplicação existente e adicionando recursos serverless de forma incremental, poderemos limitar um pouco nossas opções, mas quase todas as tecnologias serverless podem fornecer alguma forma de API (via endpoints REST ou filas de mensagens) que permitiria o desenvolvimento de extensões de aplicações independente da aplicação principal, mas com um ponto fácil de integração. Precisamos procurar por serviços que fornecem APIs compreensíveis, documentação sólida e comunidades fortes. Muitas vezes, quando se trata de tecnologias serverless, a simplicidade da integração pode ser nossa principal métrica e é provavelmente um dos maiores fatores que contribuem para o sucesso da AWS desde o lançamento do Lambda em 2015.

Em quais situações o serverless pode ser benéfico

O serverless pode ser usado em qualquer lugar, embora os benefícios vão além dos casos de uso. A barreira de entrada atual é tão baixa para a computação em nuvem devido às tecnologias serverless. Se um desenvolvedor tiver uma ideia, mas não souber como gerenciar a infraestrutura de nuvem e como otimizar os custos, não precisará se preocupar em encontrar alguém com experiência em engenharia para ajudá-lo. Se uma startup está tentando construir uma plataforma, mas está preocupada com os custos, pode ficar tranquila com uma abordagem serverless.

Graças aos aspectos de redução de custos e dimensionamento, a abordagem serverless é tão aplicável a um sistema interno de TI quanto a um aplicativo da web com vários milhões de usuários em escala global. Quando se trata de cobrança, em vez de falarmos em reais (ou qualquer que seja a moeda), podemos falar em centavos. Isso é algo incrivelmente poderoso. Até a instância mais básica do AWS EC2 (t1.micro) por um mês custará 15 euros, mesmo que não façamos nada (quem não esqueceu de desativar uma). Para comparação, precisaríamos executar uma função Lambda de 512 MB com duração de 1 segundo até 3 milhões de vezes no mesmo período para termos o mesmo custo. Da mesma forma, se não fizermos nada com essa função, não nos custará nada.

Como o serverless é predominantemente baseado em eventos, pode ser fácil adicionar uma infraestrutura serverless aos sistemas legados. Por exemplo, é possível criar um serviço de análise para um sistema legado do varejo usando o AWS S3, Lambda e Kinesis que pode receber dados a partir dos endpoints do API Gateway ou melhorar um sistema de pesquisa de texto livre usando os fluxos DynamoDB e Algolia.

A maioria das plataformas oferece suporte a múltiplas linguagens, sendo as mais comuns Python, JavaScript, C#, Java e Go. Geralmente, não há limitações quanto às bibliotecas usadas em cada linguagem, portanto, não existem barreiras para o uso de bibliotecas de código aberto que mais se adequem ao problema. No entanto, é importante pensar na baixa dependência para garantir que as funções tenham o melhor desempenho possível e ajudar a tirar proveito da escalabilidade colossal da aplicação serverless. Quanto mais pacotes o container precisar carregar, maior será o tempo de cold start.

O cold start é tempo que o container e o manipulador de funções precisam para serem inicializados antes do uso. Isso pode levar cerca de 3 segundos, o que não é ideal quando estamos tentando fornecer uma resposta a usuários impacientes. No entanto, o cold start ocorre apenas na primeira chamada após vários minutos de uma função estar ociosa. Muitos consideram isso um pequeno inconveniente que pode ser contornado ao executar um ping na função para que não fique ociosa ou simplesmente ignorada por completo.

Embora a AWS tenha lançado o Serverless Aurora, um banco de dados SQL serverless, os bancos de dados SQL não são um caso de uso ideal, pois dependem de conexões para executar transações que podem rapidamente se tornar um gargalo quando o AWS Lambda recebe uma alta taxa de transferência. Enquanto o Serverless Aurora está melhorando constantemente e vale a pena conferir, as soluções NoSQL, como o DynamoDB, são consideravelmente mais adequadas às soluções de computação serverless atualmente. Sem dúvida, essa situação vai mudar nos próximos meses.

As ferramentas também são uma limitação, especificamente em relação aos testes locais. Embora existam soluções como docker-lambda, DynamoDB Local e LocalStack, geralmente podem ser complexas e requerem configuração considerável. No entanto, existe um desenvolvimento ativo em todos esses projetos, e é apenas uma questão de tempo até que as ferramentas atinjam o padrão com o qual estamos acostumados.

O impacto da arquitetura serverless no ciclo de vida de desenvolvimento

Como a infraestrutura é apenas configuração, é possível especificar e implantar o código usando scripts. Isso pode ser simplesmente shell scripts ou é possível usar uma configuração como solução de código como o AWS CloudFormation. Um ponto positivo no CloudFormation é que, embora não forneça configuração para todas as áreas, permite especificar recursos personalizados que podem ser simplesmente funções Lambda. O que possibilita, caso o CloudFormation falhe, a possibilidade de escrever um recurso personalizado (uma função lambda) que permitirá preencher essa falha. É possível usar um recurso personalizado suportado pelo Lambda para fazer praticamente qualquer coisa, até configurar dependências fora do ambiente da AWS.

Novamente, como tudo é apenas configuração, é possível parametrizar os scripts de implantação por ambiente/região/usuário, principalmente se usarmos uma solução de Infraestrutura como Código, como o CloudFormation. Por exemplo, podemos implantar uma réplica da nossa infraestrutura para cada filial em nosso repositório para testá-las durante o desenvolvimento em completo isolamento umas das outras, o que reduz drasticamente o ciclo de feedback dos desenvolvedores que tentam descobrir se o código deles funciona adequadamente em um ambiente ativo. Os gerentes não precisam se preocupar com o custo de quantos ambientes estão implantados, pois serão cobrados por uso.

Os DevOps têm menos com o que se preocupar, pois precisam apenas garantir que os desenvolvedores tenham as configurações corretas. Não há mais instâncias, balanceadores de carga ou grupos de segurança para gerenciar. O termo "NoOps" costuma ser mencionado nesse sentido, mas ainda é importante ter experiência em configuração de infraestrutura, especialmente quando se trata da configuração do IAM e da otimização dos recursos da nuvem.

Existem ferramentas de monitoramento e visibilidade muito poderosas, como Epsagon, Thundra, Dashbird e IOPipe, para fornecer visibilidade e rastreabilidade de aplicações serverless que podem fornecer informações como registro, rastreamento, métricas de desempenho de funções, gargalos arquiteturais, análise e estimativas de custos e muito mais. Isso não apenas fornece aos engenheiros, desenvolvedores e arquitetos DevOps uma excelente visão sobre o desempenho da aplicação, mas também fornece ao gerenciamento uma imagem muito melhor dos custos de recursos em tempo real, a cada segundo bem como projeções de cobrança. Isso é consideravelmente mais difícil de fazer com uma infraestrutura gerenciada.

A arquitetura de aplicações serverless é consideravelmente mais simples, uma vez que não é preciso mais considerar servidores Web, gerenciar VMs ou containers, patches de servidor, sistemas operacionais, gateways da internet, jump boxes, etc. A abstração dessas responsabilidades permite que as arquiteturas serverless se concentrem no que é mais importante, atender às necessidades dos negócios e dos clientes.

Embora as ferramentas possam ser melhores (estão melhorando a cada dia), a experiência do desenvolvedor é ótima, pois se concentram em escrever a lógica de negócios e na melhor maneira de descarregar a complexidade da aplicação para diferentes serviços na arquitetura. A orquestração de aplicações serverless é baseada em eventos e abstraída pelo provedor de nuvem (como eventos SQS, S3 ou fluxos DynamoDB). Portanto, tudo que um desenvolvedor precisa fazer é especificar como a lógica de negócios responderá a esses eventos e não se preocupar mais com a melhor implementação de bancos de dados, filas de mensagens ou como operar os dados em um dispositivo de armazenamento específico da melhor maneira possível.

O código pode ser executado e depurado localmente, como faríamos com qualquer outro processo de desenvolvimento de aplicações. O teste unitário não muda. Como mencionado anteriormente, a capacidade de implantar toda a infraestrutura de aplicações usando uma configuração de pilha personalizável permite que os desenvolvedores obtenham feedback crítico rapidamente, sem precisar se preocupar com o custo dos testes ou o impacto em ambientes gerenciados e caros.

Ferramentas e técnicas para construção de aplicações serverless

Não há uma maneira definitiva de como criar uma aplicação serverless nem dos serviços para construir a aplicação. A AWS é um líder em oferecer soluções serverless robustas, mas vale a pena conferir o Google Cloud, Zeit e Firebase. Para casos em que estejamos usando a AWS, é aconselhável considerar o SAM (Serverless Application Model) como uma abordagem para a criação de aplicações, em particular se a linguagem adotada for a C#, uma vez que a suíte de ferramentas do Visual Studio são de grande valia. Tudo o que o Visual Studio pode fazer, a SAM CLI também faz, então não é necessário preferir o uso de um ou outro com receio de perda de recursos. Além disso, o SAM também trabalha com outras linguagens.

Ao trabalhar com outras linguagens, o Serverless Framework é uma excelente ferramenta de código aberto e permite que tudo seja configurado por arquivos de configuração YAML, o que faz esse recurso ser muito poderoso. A estrutura serverless também oferece suporte a vários provedores de nuvem, portanto se procuramos uma solução multi-cloud, esse framework certamente facilitará nossa vida, inclusive tem uma comunidade enorme, com vários plugins para atender várias necessidades.

Para testes locais, docker-lambda, Serverless Local, DynamoDB Local e LocalStack são ótimas ferramentas de código aberto. A abordagem serverless ainda está engatinhando, assim como as ferramentas que a compõe, portanto, geralmente é necessário um pouco de trabalho para que os testes locais funcionem em casos em que os cenários são mais complexos. No entanto, é incrivelmente barato implantar uma solução no nosso ambiente e testá-la. A vantagem dessa abordagem é que não temos a necessidade de nos preocupar com a replicação precisa dos ambientes na nuvem para os ambientes locais.

Use o AWS Lambda Layers para reduzir o tamanho dos pacotes implantados e melhorar o tempo de carregamento.

Precisamos verificar se estamos usando a linguagem de programação correta para o trabalho. Linguagens diferentes têm vantagens e desvantagens. Existem muitos benchmarks publicados, mas JavaScript, Python e C# (.NET Core 2.1+) são líderes claros no que diz respeito ao desempenho do AWS Lambda, que introduziu recentemente a API Runtime, que permite especificar a linguagem e o tempo de execução que desejamos utilizar. Podemos ficar à vontade para experimentarmos outras linguagens, como por exemplo C++.

Mantenha os pacotes de implantação pequenos. Pacotes menores são mais rápidos para carregar. Evite incluir bibliotecas grandes, principalmente se estivermos usando apenas um ou dois recursos. Se a linguagem utilizada for o JavaScript, use uma ferramenta de compilação como o Webpack para otimizar a compilação e incluir apenas exatamente o que é necessário. O .NET Core 3.0 apresenta o QuickJit e a compilação em camadas, que melhoram o desempenho em geral e ajudam muito no cold start.

Pela natureza baseada em eventos das funções serverless é possível que a coordenação da lógica de negócios seja mais difícil no início. Filas de mensagens e máquinas de estado podem ser incrivelmente úteis nesse sentido. As funções do Lambda podem chamar umas às outras, mas realmente devemos fazer isso apenas se não estivermos esperando por uma resposta (pense na abordagem processe e esqueça) e não desejamos ser cobrados por esperar que outra função seja concluída. As filas de mensagens são úteis para desacoplar áreas da lógica de negócios, controlar gargalos de aplicações e processar transações (ao usar filas FIFO). As funções do AWS Lambda podem receber filas SQS como filas de devoluções que acompanharão os eventos com falha para análise. O AWS Step Functions (uma máquina de estado) é incrivelmente útil ao gerenciar processos complexos que exigem o encadeamento de funções. Em vez de uma função Lambda chamar outra função, as Funções de Etapa podem coordenar transições de estado, transmitir dados entre funções e gerenciar o estado global da função, permitindo especificar condições de nova tentativa ou o que fazer quando ocorrerem erros específicos, o que pode ser incrivelmente poderoso.

Conclusão

As tecnologias serverless se desenvolveram a um ritmo incrível nos últimos anos. Essa mudança de paradigma não ocorre sem alguns mal-entendidos. As soluções serverless têm grandes vantagens em todo o ciclo de vida do desenvolvimento, desde a simplificação do desenvolvimento e DevOps até a redução significativa dos custos operacionais, graças à infraestrutura abstraída e ao gerenciamento de dimensionamento. Embora a abordagem serverless não exija ressalvas, existem técnicas e padrões de projeto sólidos que podem ser usados para criar aplicações serverless fortes ou integrar elementos serverless nas arquiteturas existentes.

Sobre o Autor

Christopher Paton é desenvolvedor sênior da Johnson Controls em Cork, Irlanda. Trabalhou em vários setores, da mídia de transmissão a organizações do setor público, no Reino Unido e na Irlanda. Usa tecnologias serverless desde que o Lambda foi lançado em 2015. Falou nos Grupos de Usuários da AWS em serverless e hospeda o Meetup sobre Serverless Framework em Cork. Fez uma palestra na RebelCon intitulada "Desenvolva e implante rapidamente com Serverless".

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT