Get best of the week

Dicas e fontes para criar aplicativos sem servidor


Embora as tecnologias sem servidor tenham ganhado popularidade rapidamente nos últimos anos, ainda existem muitos conceitos errôneos e preocupações associados a elas. Dependência de fornecedores, ferramentas, gerenciamento de despesas, partida a frio, monitoramento e ciclo de vida do desenvolvimento - todos esses tópicos são discutidos ativamente quando se trata de tecnologias sem servidor. Neste artigo, examinaremos alguns dos tópicos mencionados e também compartilharemos dicas e links para fontes de informações úteis, com as quais os iniciantes podem criar aplicativos sem servidor poderosos, flexíveis e econômicos.

Equívocos sobre tecnologias sem servidor


Muitos acreditam que a falta de servidor e o processamento de dados que não sejam de servidor ( Funções como Serviço , FaaS) são quase a mesma coisa. Portanto, a diferença não é muito grande e vale a pena introduzir um novo produto. Embora o AWS Lambda tenha sido uma das estrelas no auge das tecnologias sem servidor e um dos elementos mais populares da arquitetura sem servidor, essa arquitetura é mais do que o FaaS.

O princípio básico das tecnologias sem servidor é que você não precisa se preocupar em gerenciar e dimensionar a infraestrutura, apenas paga pelo que usa. Muitos serviços são adequados para esses critérios - AWS DynamoDB, S3, SNS ou SQS, Graphcool, Auth0, Now, Netlify, Firebase e muitos outros. Em geral, a ausência de servidor significa usar todos os recursos da computação em nuvem sem a necessidade de gerenciar a infraestrutura e sua otimização para o dimensionamento. Isso também significa que a segurança no nível da infraestrutura não é mais seu problema, mas uma grande vantagem, dada a dificuldade e a complexidade de cumprir os padrões de segurança. Por fim, você não precisa comprar a infraestrutura fornecida para uso.

A ausência de servidor pode ser considerada um "estado de espírito": uma certa mentalidade no design de soluções. Evite abordagens que exijam manutenção de qualquer infraestrutura. Com uma abordagem sem servidor, gastamos tempo resolvendo problemas que afetam diretamente o projeto e trazem benefícios aos nossos usuários: criamos uma lógica de negócios sustentável, desenvolvemos interfaces com o usuário e desenvolvemos APIs adaptáveis ​​e confiáveis.

Por exemplo, se você pode evitar gerenciar e manter a plataforma de pesquisa de texto livre, é isso que faremos. Essa abordagem para criar aplicativos pode acelerar bastante o lançamento do produto no mercado, porque você não precisa mais pensar em gerenciar infraestrutura complexa. Livre-se das responsabilidades e custos de gerenciar sua infraestrutura e concentre-se na criação dos aplicativos e serviços de que seus clientes precisam. Patrick Debois chamou essa abordagem de 'serviço completo', esse termo é adotado na comunidade sem servidor. As funções devem ser consideradas como um link de conexão para serviços na forma de módulos implementáveis ​​(em vez de implantar uma biblioteca ou aplicativo da Web inteiro). Isso fornece uma granularidade incrível no gerenciamento de implantação e alterações no aplicativo. Se você não pode implantar funções dessa maneira, isso pode indicar que as funções executam muitas tarefas e devem ser refatoradas.

Alguns ficam confusos com a dependência do fornecedor no desenvolvimento de aplicativos em nuvem. O mesmo acontece com as tecnologias sem servidor, e isso dificilmente é consequência de confusão. Em nossa experiência, a criação de aplicativos sem servidor na AWS em combinação com a capacidade do AWS Lambda de integrar outros serviços da AWS - tudo isso em parte forma as vantagens das arquiteturas sem servidor. Este é um bom exemplo de sinergia quando o resultado da combinação é mais do que apenas a soma dos termos. Tentando evitar a dependência do fornecedor, você pode ter 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 serão recompensados, especialmente se a eficiência econômica for levada 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, prontos para o uso, podem fornecer conectividade plug-and-play. É mais fácil fornecer uma chamada Lambda a partir do terminal da API do gateway do que fazer proxy da solicitação para algum contêiner ou instância do EC2. O Graphcool fornece uma configuração fácil com o Auth0, mais fácil do que usar autenticação de terceiros.

Escolher o fornecedor certo para seu aplicativo sem servidor é uma solução em nível de arquitetura. Ao criar um aplicativo, você não espera que um dia retorne ao gerenciamento de servidores. Escolher um fornecedor de nuvem não é diferente de optar por usar contêineres ou banco de dados, ou mesmo uma linguagem de programação.

Considerar:

  • Quais serviços você precisa e por quê.
  • Quais serviços são fornecidos pelos provedores de nuvem e como você pode combiná-los usando a solução FaaS selecionada.
  • 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 em uma partida a frio, qual é o ecossistema de código aberto, etc.).
  • Quais são os seus requisitos de segurança (SLA, 2FA, OAuth, HTTPS, SSL etc.).
  • Como gerenciar seus ciclos de desenvolvimento de CI / CD e software.
  • De quais soluções de classe de infraestrutura como código você pode tirar proveito?

Se você expandir um aplicativo existente e adicionar funções sem servidor de forma incremental, isso poderá limitar as opções disponíveis. No entanto, quase todas as tecnologias sem servidor fornecem algum tipo de API (via REST ou filas de mensagens) que permitem criar extensões, independentemente do kernel do aplicativo e com integração simples. Procure serviços com APIs claras, boa documentação e uma comunidade forte, e você não se enganará. A facilidade de integração geralmente pode ser uma métrica chave, e essa é provavelmente uma das principais razões para o sucesso da AWS desde o lançamento do Lambda em 2015.

Quando a ausência de servidor é útil


Tecnologias sem servidor podem ser aplicadas em quase todos os lugares. No entanto, suas vantagens não se limitam a apenas um aplicativo. Hoje, o limite de entrada na nuvem é tão baixo 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 isso. Se uma startup deseja criar uma plataforma, mas teme que os custos possam ficar fora de controle, pode facilmente recorrer a soluções sem servidor.

Devido à economia de custos e à facilidade de dimensionamento, as soluções sem servidor são igualmente aplicáveis ​​a sistemas internos e externos, até um aplicativo Web com uma audiência de vários milhões. As contas são medidas não em euros, mas em centavos. O aluguel da instância mais simples do AWS EC2 (t1.micro) por um mês custará 15 €, mesmo que você não faça nada com ele (quem nunca esqueceu de desligá-lo?!). Em comparação, para atingir esse nível de despesas já no mesmo período, você precisará executar o Lambda com 512 MB de tamanho por 1 segundo cerca de 3 milhões de vezes. E se você não usar esta função, não pague nada.

Como a tecnologia sem servidor depende principalmente de eventos, é bastante fácil adicionar infraestrutura sem servidor a sistemas mais antigos. Por exemplo, usando o AWS S3, Lambda e Kinesis, você pode criar um serviço analítico para um sistema de varejo antigo que pode receber dados por meio da API.

A maioria das plataformas sem servidor suporta idiomas diferentes. Na maioria das vezes, eles são Python, JavaScript, C #, Java e Go. Normalmente, em todos os idiomas, não há restrições quanto ao uso de bibliotecas; 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 sejam executadas da melhor maneira e não anule as vantagens da enorme escalabilidade de seus aplicativos sem servidor. Quanto mais pacotes você precisar carregar no contêiner, mais longa será a partida a frio.

Uma partida a frio é quando você precisa inicializar o contêiner, o tempo de execução e o manipulador de erros antes de usá-los. Por esse motivo, o atraso na execução das funções pode chegar a 3 segundos, e essa não é a melhor opção para usuários impacientes. No entanto, as partidas a frio ocorrem no primeiro uso após alguns minutos de inatividade. Muitas pessoas consideram isso um pequeno inconveniente que pode ser contornado executando ping regularmente em uma função para mantê-la ociosa. Ou até mesmo ignore esse aspecto.

Embora a AWS tenha lançado o banco de dados SQL sem servidor Aurora sem servidorNo entanto, os bancos de dados SQL não são ideais para esse aplicativo, porque, ao realizar transações, eles dependem de conexões, que podem rapidamente se tornar um gargalo com muito tráfego no AWS Lambda. Sim, os desenvolvedores estão constantemente aprimorando o Serverless Aurora, e você deve experimentar isso, mas hoje as soluções NoSQL como o DynamoDB são muito melhores para sistemas sem servidor . No entanto, é indubitável que esta 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 um trabalho minucioso e uma quantidade significativa de configuração. No entanto, todos esses projetos estão se desenvolvendo ativamente; portanto, é apenas uma questão de tempo até que as ferramentas atinjam o nível necessário.

O impacto das tecnologias sem servidor no ciclo de desenvolvimento


Como sua infraestrutura é apenas uma configuração, é possível definir e implantar código usando scripts, como scripts de shell. Ou você pode recorrer a soluções de classe de configuração como código, como o AWS CloudFormation . Embora este serviço não forneça configuração para todas as áreas, ele permite definir recursos específicos para uso como funções do Lambda. Ou seja, onde o CloudFormation o decepciona, você pode escrever seu próprio recurso (função Lambda), que fechará essa lacuna. Dessa forma, você pode fazer qualquer coisa, até configurar dependências fora do seu ambiente da AWS.

Como tudo isso é apenas uma configuração, é possível parametrizar seus scripts de implantação para ambientes, regiões e usuários específicos, especialmente se você usar soluções de classe de infraestrutura como código, como CloudFormation. Por exemplo, você pode implantar uma cópia da infra-estrutura para cada filial no repositório para testá-las completamente isoladamente durante o desenvolvimento. Isso acelera drasticamente os desenvolvedores a receber feedback quando desejam entender se seu código funciona adequadamente em um ambiente ativo. Os gerentes não precisam se preocupar com o custo da implantação de vários ambientes, porque apenas o uso real é pago.

O DevOps tem menos preocupações porque eles só precisam garantir que os desenvolvedores tenham a configuração correta. Você não precisa mais gerenciar instâncias, balanceadores ou grupos de segurança. Portanto, o termo NoOps está sendo cada vez mais usado, embora ainda seja importante poder configurar a infraestrutura, principalmente no que diz respeito à configuração do IAM e à otimização dos recursos da nuvem.

Existem ferramentas visuais e de monitoramento muito poderosas, como Epsagon, Thundra, Dashbird e IOPipe. Eles permitem que você monitore o estado atual dos aplicativos sem servidor, forneça logs e rastreios, registre métricas de desempenho e gargalos na 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 idéia abrangente de como os aplicativos funcionam, 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. Gerenciar isso com uma infraestrutura gerenciada é muito mais difícil.

Projetar aplicativos sem servidor é muito mais simples, porque você não precisa implantar servidores Web, gerenciar máquinas ou contêineres virtuais, servidores de patches, sistemas operacionais, gateways da Internet etc. A abstração de todas essas responsabilidades permite que a arquitetura sem servidor se concentre no principal - a solução necessidades de negócios e clientes.

Embora o kit de ferramentas possa ser melhor (está melhorando a cada dia), no entanto, os desenvolvedores podem se concentrar na implementação da lógica de negócios e na melhor distribuição da complexidade do aplicativo nos diferentes serviços da arquitetura. Aplicativos sem servidor são orientados a eventos e abstraídos pelo provedor de nuvem (por exemplo, eventos SQS, S3 ou fluxos DynamoDB). Portanto, os desenvolvedores precisam apenas prescrever a lógica comercial para responder a determinados eventos, e você não precisa se preocupar em como implementar melhor bancos de dados e filas de mensagens ou em 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 permanece o mesmo. A capacidade de implantar uma infraestrutura de aplicativos inteira com uma configuração de pilha personalizada permite que os desenvolvedores obtenham rapidamente um feedback importante sem se preocupar com o custo dos testes ou o 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. Hoje, a AWS é líder entre as poderosas soluções sem servidor, mas preste atenção ao Google Cloud , Zeit e Firebase . Se você usa a AWS, o SAM ( Serverless Application Model ) pode ser recomendado como uma abordagem para coletar aplicativos , especialmente ao usar o C #, pois o Visual Studio é um ótimo kit de ferramentas. O SAM CLI pode fazer tudo da mesma forma que o Visual Studio, para que você não perca nada se mudar para outro IDE ou editor de texto. Obviamente, o SAM também funciona com outros idiomas.

Se você escreve em outros idiomas, o Serverless Framework é uma excelente ferramenta de código-fonte aberto que permite configurar qualquer coisa com a ajuda de arquivos YAML de configuração muito poderosos. O Serverless Framework também oferece suporte a vários serviços em nuvem, portanto, recomendamos a quem procura uma solução com várias nuvens. Ele tem uma comunidade enorme que criou vários plug-ins 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 um estágio inicial de desenvolvimento, assim como as ferramentas para elas; portanto, ao configurar para cenários de teste complexos, você precisará suar. No entanto, apenas expandir a pilha no ambiente e testar lá é incrivelmente barato. E você não precisa fazer uma cópia local exata dos ambientes em nuvem.

Use as camadas do AWS Lambda para reduzir o tamanho dos pacotes implantados e acelerar o carregamento.

Use as linguagens de programação corretas para tarefas específicas. Idiomas diferentes têm suas próprias vantagens e desvantagens. Existem muitos benchmarks, mas JavaScript, Python e C # (.NET Core 2.1+) são líderes em termos de desempenho do AWS Lambda. A API de tempo de execução apareceu recentemente no AWS Lambda, que permite especificar o idioma e o tempo de execução desejados, então experimente.

Mantenha o tamanho do pacote pequeno para implantação. Quanto menores, mais rápido eles carregam. Evite usar grandes bibliotecas, especialmente se você usar alguns recursos delas. Se você estiver programando em JavaScript, use ferramentas 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 a princípio pode complicar a coordenação da lógica de negócios. Nesse sentido, filas de mensagens e máquinas de estado podem ser incrivelmente úteis. As funções Lambda são capazes de ligar uma para a outra, mas faça isso apenas se você não espera receber uma resposta (“atire e esqueci”) - você não deseja obter uma conta para 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 mensagens com falha para análise posterior. As 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 chamar uma função Lambda de outra função, as funções Step podem coordenar transições de estado, transferir dados entre funções e controlar o estado global das funções. Isso permite determinar as condições para novas tentativas ou o que precisa ser feito quando ocorrer um erro específico - sob certas condições, uma ferramenta muito poderosa.

Conclusão


Nos últimos anos, as tecnologias sem servidor têm se desenvolvido em um ritmo sem precedentes. Existem certos conceitos errôneos associados a essa mudança de paradigma. Ao abstrair a infraestrutura e gerenciar o dimensionamento, as soluções sem servidor oferecem benefícios significativos: desde processos simplificados de desenvolvimento e DevOps até grandes reduções nos custos operacionais.
Embora a abordagem sem servidor não tenha desvantagens, existem métodos confiáveis ​​de padrões de design que podem ser usados ​​para criar aplicativos sem servidor estáveis ​​ou integrar elementos sem servidor nas arquiteturas existentes.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles