- Workload pattern
-
Entender o padrão operacional do seu aplicativo é o fator mais importante na seleção de serviços sem servidor. Diferentes padrões de carga de trabalho exigem diferentes combinações de serviços. O processamento de dados sem servidor se enquadra, em grande parte, nos seguintes padrões:
Processamento assíncrono: processamento de arquivos, manipulação de imagens, transformações em lote e webhooks. Essas cargas de trabalho processam eventos que não exigem uma resposta imediata e se beneficiam de filas para armazenamento em buffer e distribuição para processamento paralelo.
Síncrono request/response: APIs da Web, back-ends móveis e microsserviços. Essas cargas de trabalho precisam de computação de baixa latência que responda às solicitações HTTP individuais e se adapte ao tráfego simultâneo.
Streaming: telemetria de IoT, análise de fluxo de cliques, análise em tempo real e processamento de transações. Essas cargas de trabalho ingerem dados contínuos e de alta velocidade que devem ser processados quase em tempo real.
Orquestração: fluxos de Multi-step aprovação, canais de ETL e padrões de saga. Essas cargas de trabalho coordenam tarefas com lógica de ramificação, tratamento de erros e gerenciamento de estado.
Cada padrão usa uma combinação diferente de serviços sem servidor. Para obter exemplos detalhados e combinações de serviços recomendadas para cada padrão, consulte a seção Escolher.
- Execution duration and concurrency
-
Os serviços de computação sem servidor diferem significativamente no tempo em que permitem a execução de uma única execução e na forma como lidam com a simultaneidade. Diferentemente dos servidores tradicionais, as funções de eventos do Lambda não são executadas constantemente. Quando uma função é acionada por um evento, isso é chamado de invocação. As funções de eventos do Lambda são limitadas a 15 minutos de duração, mas, em média, em todos os AWS clientes, a maioria das invocações dura menos de um segundo.
Short-lived, as invocações orientadas por eventos são melhor atendidas pelo Lambda, que oferece suporte a durações de execução de até 15 minutos e escala automaticamente por solicitação para milhares de invocações simultâneas. O serviço Lambda executa instâncias de sua função somente quando necessário e escala automaticamente de zero solicitações por dia para milhares por segundo. Você paga somente pelo tempo de computação realmente usado, portanto, não há cobrança quando seu código não está em execução. O faturamento por milissegundo do Lambda pode reduzir o custo de cargas de trabalho de curta duração.
Há muitos tipos de eventos de invocação que podem acionar funções de curta duração. Alguns exemplos incluem uma solicitação HTTP do API Gateway, uma programação gerenciada por uma EventBridge regra, uma mensagem de um dispositivo de IoT ou uma notificação de que um arquivo foi carregado em um bucket do Amazon S3.
Sessões interativas e dinâmicas, como sandboxes de codificação de IA, notebooks interativos e ambientes de CI multilocatários, precisam de ambientes isolados que mantenham o estado entre as interações do usuário. As microVMs Lambda têm um formato computacional diferente das Funções de Eventos: elas usam um modelo de Dockerfile-based programação, alocam um ambiente por sessão (não por solicitação) e faturam com base em um modelo básico mais um modelo de intermitência em vez de por milissegundo. As microVMs fornecem VM-level isolamento com recursos completos do sistema operacional, inicialização rápida baseada em instantâneos, vida útil de até 8 horas e para reduzir os custos ociosos. suspend/resume
Long-running ou processos em estado estacionário, como trabalhos em lote, WebSocket conexões persistentes ou serviços que exigem mais de 15 minutos de processamento contínuo, são melhor atendidos pelo Fargate, que pode ser executado indefinidamente. Para obter detalhes sobre como o Fargate e o Lambda escalam de forma diferente, consulte a guia Modelo de escalabilidade e latência. O Fargate fornece alocação consistente de recursos para cargas de trabalho que excedem o tempo limite ou os limites de computação do Lambda. Além disso, as funções duráveis do Lambda permitem execuções de longa duração em várias etapas que persistem no estado em várias invocações. Cada invocação individual ainda respeita o limite de 15 minutos. As funções duráveis verificam automaticamente o progresso e retomam de onde pararam, de modo que a duração total do fluxo de trabalho pode exceder em muito 15 minutos sem exigir Fargate ou orquestração externa.
Considere o tempo médio e máximo de execução de suas cargas de trabalho. Uma função do Lambda que ocasionalmente excede 15 minutos falha de forma imprevisível e exige um redesenho arquitetônico. A arquitetura e as necessidades do seu aplicativo determinam como invocar uma função. Por exemplo, os padrões de processamento em lote têm requisitos diferentes do processamento de dados sob demanda. O Fargate é adequado para um microsserviço que lida principalmente com o processamento de dados em lote. O Lambda é mais simples de implantar e manter para processamento sob demanda.
- Cost model and predictability
-
Uma das principais vantagens do desenvolvimento sem servidor é que você paga somente pelos recursos que consome. As tecnologias sem servidor são pagas conforme o uso, o que significa que você pode aumentar e diminuir a escala conforme as necessidades do seu aplicativo mudarem, sem pagar pela capacidade ociosa. No entanto, diferentes serviços AWS sem servidor usam modelos de preços diferentes que favorecem diferentes padrões de uso.
Pay-per-use os preços (Lambda, Step Functions Express EventBridge) são cobrados com base nas invocações e na duração reais, sem custo quando inativo. Para o Lambda, você é cobrado com base no número de solicitações para suas funções e na duração da execução do código. Não haverá cobranças quando seu código não estiver em execução. Esse modelo é adequado para cargas de trabalho imprevisíveis ou pontiagudas, nas quais o tráfego pode cair para zero, e para aplicativos em estágio inicial, onde a demanda é incerta.
Capacity-based preços (Fargate, Amazon Aurora Serverless, modo provisionado do DynamoDB) cobranças pela capacidade reservada de computação ou taxa de transferência. Embora isso possa gerar custos durante períodos de baixo tráfego, torna-se mais econômico em uma escala sustentada e previsível, em que o preço por solicitação excederia a capacidade reservada equivalente. Por exemplo, o modo provisionado do DynamoDB permite ajustar a capacidade de transferência de suas tabelas conforme necessário, o que pode ser mais econômico para cargas de trabalho com padrões de tráfego consistentes.
Os preços híbridos (DynamoDB sob demanda, API Gateway) oferecem preços por solicitação que escalam linearmente sem compromisso inicial. Isso fornece previsibilidade de custos sem a necessidade de prever a capacidade, mas pode se tornar caro com uma taxa de transferência muito alta em comparação com as alternativas provisionadas.
O preço básico e o preço máximo (Lambda MicroVMS) cobram pelos recursos de linha de base configurados enquanto a microVM está em execução, com a capacidade de aumentar até 4 vezes a linha de base durante o pico de atividade. As microVMs suspensas reduzem os custos e preservam o estado. Esse modelo é adequado para cargas de trabalho interativas com atividades variáveis e períodos de inatividade.
Modele seus padrões de tráfego esperados em ciclos diários, semanais e sazonais. Cargas de trabalho com altas taxas de pico em relação à média favorecem os preços por uso. Steady-state as cargas de trabalho podem se beneficiar dos preços baseados na capacidade. Você também pode usar uma combinação: por exemplo, Lambda com pagamento por uso para computação variável junto com o modo provisionado do DynamoDB para padrões previsíveis de acesso aos dados.
- Operational complexity
-
As estruturas tradicionais de aplicativos da Web agrupam roteamento, acesso a dados, pools de conexão e integrações em uma única base de código que você implanta e mantém como uma unidade. Instalar, configurar e manter as estruturas, os ambientes de tempo de execução e a infraestrutura retarda a entrega de recursos e correções de erros. À medida que os aplicativos crescem e dependem de mais sistemas externos, essa complexidade aumenta o tempo de inicialização para novos desenvolvedores, torna mais difícil rastrear a origem dos bugs e atrasa a entrega de novos recursos.
Os serviços sem servidor existem em um espectro de responsabilidade operacional que reduz ou elimina essa sobrecarga. Em vez de gerenciar tudo em um único pacote, você compõe serviços vagamente conectados, em que cada um faz uma coisa bem com o mínimo de dependências possível.
Gerenciamento mínimo: o Lambda, o API Gateway, o DynamoDB, o Amazon SQS, o Amazon SNS e o Step Functions não exigem provisionamento EventBridge, aplicação de patches ou planejamento de capacidade do servidor. Você não precisa configurar grupos de conexões, configurar ambientes de execução ou gerenciar a infraestrutura de escalabilidade. Você pode se concentrar inteiramente em escrever ou gerar código que resolva problemas de negócios.
Gerenciamento de contêineres: o Fargate exige a criação e manutenção de imagens de contêineres, a configuração de definições de tarefas e o gerenciamento de pipelines de implantação. Você não gerencia a infraestrutura subjacente, mas é dono do ciclo de vida do contêiner. Esse modelo é adequado para equipes que precisam de tempos de execução personalizados ou têm cargas de trabalho em contêineres existentes que desejam executar sem gerenciar clusters.
Infraestrutura como complexidade de código: AWS Serverless Application Model
minimiza a complexidade do IaC para arquiteturas somente sem servidor com sintaxe abreviada e testes locais. AWS Cloud Development Kit (AWS CDK) e Terraform fornecem mais potência para aplicativos complexos ao custo de curvas de aprendizado mais acentuadas e de mais código para manter.
Considere as habilidades existentes da sua equipe, o número de serviços a serem gerenciados e os padrões operacionais da sua organização. Se suas equipes estão gastando mais tempo mantendo a infraestrutura do que criando recursos, migrar para a extremidade mínima de gerenciamento do espectro pode liberar recursos para trabalhos de maior valor.
- Scaling model and latency
-
A forma como um serviço se expande afeta diretamente a capacidade de resposta do seu aplicativo sob carga. Em arquiteturas sem servidor, o escalonamento acontece automaticamente, mas serviços diferentes usam mecanismos diferentes que afetam a latência e a taxa de transferência.
Per-request o scaling (Lambda) cria um novo ambiente de execução para cada solicitação simultânea. O Lambda invoca sua função em um ambiente de execução, que fornece um ambiente de execução seguro e isolado que gerencia os processos e recursos necessários para executar a função. Isso fornece uma resposta quase instantânea aos picos de tráfego, escalando de zero a milhares de execuções simultâneas em segundos.
No entanto, a escalabilidade por solicitação introduz inícios a frio, que são atrasos na inicialização que ocorrem quando o Lambda cria um novo ambiente de execução. O maior contribuinte para o tempo de inicialização a frio é o tempo que o Lambda gasta inicializando a função, o que inclui carregar o código da função, iniciar o tempo de execução e inicializar o código da função. Para cargas de trabalho Java, Python e .NET, o Lambda SnapStart pode melhorar o desempenho da inicialização em até 10 vezes sem custo adicional, tirando um instantâneo do ambiente de execução inicializado e armazenando-o em cache para acesso de baixa latência. Para outros tempos de execução, você pode reduzir os inícios a frio com a simultaneidade provisionada por um custo adicional.
Task-level o scaling (Fargate) adiciona ou remove instâncias de contêiner com base em métricas como utilização de CPU, uso de memória ou contagem de solicitações. O escalonamento adiciona novas tarefas em segundos ou minutos e evita inícios a frio de solicitações tratadas por tarefas existentes. Quando uma tarefa é executada, ela permanece aquecida por toda a vida útil, fornecendo latência consistente para todas as solicitações processadas.
Throughput-based a escalabilidade (DynamoDB, Kinesis) ajusta a read/write capacidade ou a contagem de fragmentos com base na demanda. O modo sob demanda do DynamoDB é escalado instantaneamente para acomodar os padrões de tráfego da sua carga de trabalho. O modo provisionado exige configuração de escalabilidade automática, mas fornece uma taxa de transferência previsível com custos mais baixos por solicitação. Com a arquitetura sem servidor e o DynamoDB, os pools de conexão não são necessários para conectar e escalar rapidamente o banco de dados. Em vez disso, você ajusta a capacidade de produção de suas tabelas conforme necessário.
Para requisitos estritos de latência (abaixo de 100 ms P99), avalie cuidadosamente o comportamento de partida a frio. O Lambda com simultaneidade provisionada ou SnapStart o Fargate com tarefas pré-aquecidas fornecem latência previsível para cargas de trabalho de API. Para cargas de trabalho de processamento de dados em que a latência é menos crítica, o escalonamento padrão do Lambda geralmente é suficiente.
- Integration and composability
-
As arquiteturas sem servidor são compostas por vários serviços que se comunicam por meio de eventos. Um evento representa uma mudança no estado ou uma atualização. Por exemplo, um item colocado em um carrinho de compras, um arquivo carregado em um sistema de armazenamento ou um pedido pronto para envio. A profundidade da integração nativa entre os serviços afeta a rapidez com que você pode criar e a quantidade de código personalizado que você precisa escrever.
Integração nativa profunda: o Lambda se integra a mais de 200 AWS serviços como fontes de eventos. Alguns serviços podem acionar funções do Lambda diretamente. Por exemplo, quando uma imagem é adicionada a um bucket do Amazon S3, o Lambda pode ser acionado para redimensioná-la. Alguns serviços não podem invocar o Lambda diretamente, mas você pode usar um mapeamento da fonte de eventos, que é um mecanismo de pesquisa que lê a partir de uma fonte de eventos e invoca uma função do Lambda. Você pode usar mapeamentos de origem de eventos para processar itens de um stream ou fila em: DynamoDB Streams, Amazon Kinesis, Amazon MQ, Amazon MSK, autogerenciado e Amazon SQS. Apache Kafka
Flexibilidade de roteamento de eventos: EventBridge fornece roteamento baseado em conteúdo com regras de filtragem, permitindo que um único barramento de eventos direcione eventos para destinos diferentes com base no conteúdo do evento. O Amazon SNS fornece distribuição baseada em tópicos para entregar mensagens a vários assinantes simultaneamente. O Amazon SQS fornece buffer ponto a ponto em que os consumidores pesquisam ativamente as mensagens da fila. As combinações comuns incluem o roteamento EventBridge de eventos do Amazon SNS para uma fila do Amazon SQS como um buffer para consumidores downstream, a extração de eventos de um stream ou fila com o EventBridge Pipes e o roteamento de eventos para o Kinesis para análise.
Padrões de integração de API: o API Gateway oferece duas abordagens de integração. As integrações de proxy passam diretamente todas as informações da solicitação para uma função do Lambda para processamento, que é mais simples de configurar. Non-proxy integrações (personalizadas) podem transformar dados antes que eles cheguem à sua função e antes que a saída retorne aos clientes, o que é útil para a migração de código legado ou para manter o código da função focado na lógica de negócios. A API REST fornece o conjunto de recursos mais amplo, incluindo armazenamento em cache, validação de solicitações e WAF. A API HTTP fornece a menor latência e custo. AWS AppSync fornece assinaturas em tempo real e GraphQL. Os URLs de função do Lambda fornecem o endpoint HTTPS de função única mais simples sem exigir o API Gateway. Para comunicação bidirecional em que o servidor precisa enviar dados aos clientes, as WebSocket APIs do API Gateway fornecem conexões persistentes adequadas para bate-papo, painéis em tempo real e jogos multijogador.
Devido ao acoplamento frouxo entre os componentes de um sistema orientado por eventos, suas funções de computação não estão cientes de outras atividades na arquitetura. Você pode escalar componentes de forma independente, um serviço pode falhar sem afetar outros serviços e os eventos podem ser roteados, armazenados em buffer de forma flexível e fornecer um registro para auditoria.
- Portability and standards
-
Sua escolha de serviços sem servidor afeta a portabilidade de sua arquitetura em todos os ambientes. Os aplicativos sem servidor geralmente incluem vários AWS serviços, integrados ao código personalizado executado nas funções do Lambda. Embora o Lambda possa ser integrado à maioria dos AWS serviços, você deve considerar a compensação entre a integração profunda da plataforma e a capacidade de executar cargas de trabalho em outros ambientes.
AWS os serviços nativos (Lambda, Step Functions EventBridge, DynamoDB) fornecem a integração mais profunda e a menor sobrecarga operacional. Você pode usar qualquer um desses serviços por meio do AWS SDK sem precisar instalar aplicativos ou configurar servidores. Tornar-se proficiente no uso desses serviços por meio de código em suas funções do Lambda é uma etapa importante para produzir aplicações com tecnologia sem servidor bem projetadas. No entanto, esses serviços criam acoplamento a APIs e formatos AWS de eventos específicos, o que significa que a migração para outra nuvem exige uma refatoração significativa.
Standards-based serviços (Fargate com Docker contêineres, Amazon MQ comAMQP, Amazon MSK comApache Kafka) são executados em protocolos abertos ou tecnologias de código aberto. Se precisar de um tempo de execução personalizado que não seja fornecido pelo AWS, você pode criar e implantar uma imagem de contêiner personalizada no Fargate. O Amazon MSK oferece Apache Kafka compatibilidade para equipes com experiência existente em Kafka. Essas opções tornam a portabilidade da carga de trabalho mais viável ao custo de maior complexidade operacional e menor integração com outros serviços. AWS
Estruturas de implantação: AWS Serverless Application Model AWS Cloud Development Kit (AWS CDK)
geram CloudFormation modelos e são AWS somente. AWS Serverless Application Model se estende CloudFormation com sintaxe abreviada focada em acelerar o desenvolvimento sem servidor, oferecendo definições otimizadas para recursos do API Gateway, Lambda e Step Functions, além de testes locais do Lambda por meio da CLI do SAM. Terraformfornece definição de infraestrutura multinuvem usando um único fluxo de trabalho entre fornecedores, mas com menos ferramentas específicas sem servidor e recursos limitados de testes locais do Lambda.
Contêineres e mensagens baseadas em padrões podem melhorar a portabilidade para requisitos de várias nuvens. Os serviços nativos sem servidor oferecem uma integração próxima com outros AWS serviços, o que pode simplificar o desenvolvimento quando sua carga de trabalho é executada principalmente em funcionamento. AWS
