3 razões pelas quais as equipes abandonam o AWS Lambda

Quando a Amazon Web Services introduziu o Lambda pela primeira vez em novembro de 2014, ela o apresentou como um serviço de computação “que executa seu código em resposta a eventos e gerencia automaticamente os recursos de computação para você, facilitando a construção de aplicativos que respondem rapidamente a novas informações”.

Foi um grande negócio porque elevou o nível de abstração ao máximo que você poderia imaginar em termos de operacionalização do código: escreva uma função e o Lambda cuida do resto.

O modelo de preços baseado no consumo também foi revolucionário porque você pagava apenas pela quantidade de computação realmente usada e as funções eram reduzidas a zero quando não utilizadas.

No entanto, o custo total de execução de funções (quando você considera computação, rede e outros serviços da AWS necessários para acionar e orquestrar as funções) pode ser maior do que o custo de computação em uma abstração mais simples como AWS EC2 (se você contar ciclos de computação ativos somente) — é o preço que você paga pela quantidade de valor agrupado na abstração de nível superior. Também significa menos flexibilidade em termos do que você realmente pode fazer a partir do código da sua função e das linguagens de programação disponíveis para uso.

Para explicar isso à minha mãe, eu disse a ela que é como a diferença entre pedir comida para entrega e cozinhar você mesmo: pedir uma refeição por um aplicativo de delivery é muito conveniente, mas há menos opções e é mais caro. Cozinhar você mesmo oferece toda a liberdade de escolha a um custo mais barato, mas é necessário mais investimento inicial para preparar sua refeição. Principalmente se você quiser fazer pad Thai (foto acima), que requer alguns ingredientes incomuns (pelo menos na Europa), como pasta de tamarindo.

Às vezes, o valor da comida para viagem compensa o custo mais elevado e a escolha reduzida quando comparado ao esforço necessário para preparar a mesma refeição em casa.

Vamos nos aprofundar nos três principais motivos pelos quais algumas equipes migraram do AWS Lambda para abstrações de computação de nível inferior. Continue lendo até o final para obter dicas sobre como migrar facilmente do Amazon Lambda para funções em execução no Amazon EKS.

Razão nº 1: Custo

É muito fácil começar a usar um serviço como o AWS Lambda. Se você faz parte de uma equipe pequena iniciando um novo projeto, deseja maximizar suas chances de chegar ao mercado rapidamente e obter feedback o quanto antes. O Lambda permite que você envie rapidamente, transformando o máximo possível de despesas de capital em despesas operacionais.

Mas, em algum momento, os custos mais elevados das funções sem servidor, quando comparados com abstrações de computação de nível inferior, como máquinas virtuais ou contêineres, podem se tornar um problema, especialmente quando um aplicativo começa a receber muito tráfego.

Este tópico ganhou destaque recentemente, quando uma equipe que trabalha no Amazon Prime Video cortou custos em 90% ao passar de Lambdas para um monólito no EC2. Eles se beneficiaram amplamente da mecânica de escalonamento sem servidor, mas ao migrar tudo para um monólito, reduziram enormemente os custos de orquestração e transferência de dados.

Razão nº 2: focar em uma única abstração

Existem muitos tipos de cargas de trabalho que você provavelmente não deseja executar no AWS Lambda. Por exemplo, o processamento de dados ETL ou orquestrações de serviços não aproveitarão os benefícios de escalabilidade fornecidos pelo Lambda e provavelmente atingirão os limites impostos pela AWS, como o tempo total de execução. Quando uma equipe de plataforma precisa oferecer suporte a vários paradigmas de computação para os desenvolvedores de sua organização, como lambdas e contêineres, acrescenta complexidade ao seu trabalho.

Lambdas e contêineres exigem soluções diferentes para gerenciar várias etapas do ciclo de vida de desenvolvimento de software. A maneira como você desenvolve, testa, implanta, protege e monitora uma função do AWS Lambda é muito diferente de como você faria o mesmo para uma carga de trabalho em contêiner executada em um orquestrador de contêiner, como o serviço Kubernetes gerenciado da Amazon, EKS. O que ouvimos da comunidade TriggerMesh (você pode falar com eles diretamente no Slack) é que as equipes de operações às vezes preferem unificar suas operações em uma única abstração, como contêineres, rodando em Kubernetes, em vez de ter que resolver os mesmos problemas em diferentes maneiras em múltiplas abstrações. Isso tem alguns outros benefícios:

• Isso torna o cenário mais simples para os desenvolvedores na organização: um paradigma único para implantação de código significa um paradigma único para aprender e dominar.
• Ele permite que as equipes aproveitem sua experiência em Kubernetes e otimizem o uso dos recursos disponibilizados em seus clusters.
• Ele cria uma maneira mais independente da nuvem e portátil de escrever lógica de negócios, com menos dependência dos serviços de um fornecedor de nuvem específico, o que nos leva ao motivo nº 3.

É claro que nem todas as equipes de plataforma têm as habilidades ou o desejo de basear todas as suas operações no Kubernetes; alguns irão preferir sistemas mais simples como ECS ou Fargate, por exemplo.

Razão nº 3: Portabilidade

Um aplicativo portátil é aquele que pode ser executado em diferentes plataformas com alterações mínimas no código do aplicativo. A “plataforma” de um aplicativo nativo da nuvem é composta de computação, armazenamento, rede e outros serviços gerenciados usados ​​pelo aplicativo e fornecidos pela plataforma de nuvem subjacente. Portanto, a portabilidade de uma aplicação nativa da nuvem pode ser definida em duas dimensões:

• O grau de acoplamento entre o aplicativo e o mecanismo de computação no qual ele está sendo executado. Por exemplo, qual é o custo de migração de uma função do AWS Lambda para o Google Cloud Functions?
• O grau de acoplamento entre o aplicativo e os serviços em nuvem que ele utiliza. Por exemplo, se um aplicativo assinar notificações para novos arquivos em um bucket AWS S3, com que facilidade ele poderá ser portado para ingerir notificações semelhantes para novos arquivos em um bucket do Google Cloud Storage?

As empresas estão cada vez mais lidando com arquiteturas multicloud. Uma razão recorrente é que, através de fusões e aquisições, as empresas que inicialmente podiam ter apostado tudo num único fornecedor de nuvem acabam por operar software em múltiplas nuvens. Alguns optam por adotar o modo multicloud e manter uma presença em diversas plataformas de nuvem, enquanto outros preferem migrar todos os seus aplicativos para uma única nuvem. Não existe uma resposta certa e cada uma tem seus prós e contras. Mas em ambos os casos, a portabilidade pode trazer benefícios significativos.

Se você estiver migrando aplicativos de uma nuvem para outra, habilitar a portabilidade de aplicativos pode permitir migrações graduais e menos arriscadas. Você altera um pequeno número de variáveis ​​por vez, em vez de fazer uma atualização radical. E se você estiver se comprometendo com a multicloud, criar um certo nível de portabilidade significa que os desenvolvedores poderão consumir mais facilmente recursos, dados e eventos de diferentes nuvens. Sem uma camada de portabilidade, cada desenvolvedor precisa reimplementar a lógica de integração para cada nuvem, o que retarda o desenvolvimento e aumenta a carga cognitiva. As equipes de DevOps estão tentando transferir essas responsabilidades para a plataforma para que os desenvolvedores de aplicativos possam se concentrar no que fazem de melhor.

O que as pessoas devem usar em vez do AWS Lambda?

Os três pontos discutidos nesta postagem levantam a questão: existe uma maneira de migrar as funções Lambda para uma plataforma de computação mais econômica, unificada e portátil?

A boa notícia é que agora existem muitas alternativas estabelecidas e de código aberto que permitem executar funções sem servidor. Isso geralmente inclui, em graus variados, a capacidade de executar código de função e acionar essas funções com diferentes fontes de eventos. Exemplos de tecnologias neste espaço são Knative, OpenFaaS, Apache OpenWhisk e TriggerMesh.

Para equipes de plataforma com foco em Kubernetes, uma receita de três partes está surgindo como uma forma de migrar das funções Lambda tradicionais:

1. Escreva Lambdas usando tempos de execução Lambda personalizados da AWS.
2. Implante as funções no Kubernetes com Knative Serving.
3. Acione as funções com TriggerMesh.

Como as funções do AWS Lambda agora podem ser criadas com contêineres que usam os tempos de execução personalizados do Lambda da AWS, você pode usar essas mesmas imagens de contêiner e implantá-las em qualquer lugar que possa executar contêineres.

O Knative Serving fornece uma maneira de pegar um serviço em contêiner e implantá-lo no Kubernetes de forma que ele seja dimensionado para zero quando ocioso, dimensionado horizontalmente de acordo com a carga e se torne endereçável para que outras cargas de trabalho no Kubernetes possam rotear eventos para ele.

O Knative Serving pode ser facilmente instalado no Amazon EKS.

A última peça da receita é o mecanismo de disparo. Embora o Knative venha com alguns gatilhos prontos para uso, ele não inclui gatilhos para serviços da AWS que você possa estar usando para acionar suas funções do Lambda. TriggerMesh é uma solução popular de código aberto para expandir a gama de gatilhos para suas funções sem servidor Knative e inclui serviços AWS como fontes de eventos, como SQS e S3. E como o TriggerMesh pode ser executado nativamente no Kubernetes, junto com seus serviços Knative e outras cargas de trabalho, ele pode facilmente extrair eventos de fontes externas para o EKS (ou outras distribuições K8s) para que você possa filtrar, transformar e rotear esses eventos para os serviços necessários. acionar. (Dê uma olhada neste guia para ver um exemplo.)

Você deve estar se perguntando se o Amazon EventBridge poderia ser usado para acionar sua função no EKS, pois fornece funcionalidade semelhante ao TriggerMesh, mas como uma solução gerenciada. Mas como o EventBridge é baseado em push e normalmente não está em execução na mesma VPC que seu cluster EKS, não é fácil enviar eventos do EventBridge para o EKS para acionar suas funções.

Escolha o caminho certo para sua organização

Como sempre, o diabo está nos detalhes e não existe uma abordagem única para todas estas questões. Nesta postagem, cobrimos três motivos principais pelos quais algumas equipes estão se afastando do Lambda, e as pessoas levantaram outros relacionados à segurança e atrasos nas atualizações dos tempos de execução do Lambda. No entanto, de acordo com pesquisas do setor, o Lambda é um projeto próspero e fornece uma maneira rápida de fazer com que unidades de lógica de negócios funcionem de maneira confiável na nuvem.

A postagem 3 razões pelas quais as equipes se afastam do AWS Lambda apareceu pela primeira vez em The New Stack.