Diferenças entre as Funções Serverless da GCP e as Funções Lambda da AWS - Um Guia Comparativo de Migração

Versão em inglês aqui

Já se passaram alguns meses desde que migrei de uma ambiente GCP (Google Cloud Platform) para um ambiente AWS (Amazon Web Services). No começo eu achei que ia estranhar e ter dificuldade de me adaptar pois já ouvi relatos de profissionais no caminho inverso reclamando, mas para minha surpresa, isso não aconteceu.

E nessa transição eu decidi escrever e compartilhar de forma didática as diferenças sutis com as quais me deparei. Em vez de apresentar um confronto direto, optei por um guia de comparação para ajudar outros profissionais que possam estar considerando uma transição semelhante.

Os padrões de cloud que utilizamos hoje são um esforço principalmente do NIST (Instituto Nacional de Padrões e Tecnologia). Esses padrões têm orientado o desenvolvimento e a implementação de tecnologias de nuvem, garantindo uma abordagem consistente e segura em todos os provedores de computação em nuvem. Por causa desses padrões as semelhanças são muitas entre os serviços de FaaS (Function as a Service) da AWS e da GCP.

Dos pontos práticos que são relevantes conhecer:

---

01. Infraestrutura:

Ambas as plataformas, AWS e GCP, adotam um modelo de divisão de infraestrutura em regiões e zonas, seguindo os padrões estabelecidos pelo NIST (Instituto Nacional de Padrões e Tecnologia).

No contexto da computação em nuvem, uma região refere-se a uma área geográfica específica onde os recursos podem ser implantados. Dentro de cada região, existem as Zonas de Disponibilidade, que representam datacenters físicos distintos, isolados uns dos outros, onde os serviços são executados.

É importante observar que, em ambas as plataformas, alguns serviços podem não estar disponíveis em todas as regiões. No entanto, para serviços de funções serverless, eles estão presentes na região brasileira, conhecida como sa-east-1 na AWS e southamerica-east1 na GCP.

Um ponto que se destaca nas diferenças é a nomenclatura das Zonas de Disponibilidade, onde profissionais da GCP se referem a elas apenas como "zona", enquanto os profissionais da AWS as chamam de "AZ".

---

02. Nomes diferentes, serviços similares

Mesmo falando aqui basicamente de Funções serverless no dia a dia do desenvolvimento precisamos saber bem mais do arcabouço envolvido para desenvolvimento, integração, implantação e monitoramento dos nossos projetos, dessa forma abaixo apresento um de-para para os serviços mais conhecidos

O Google oferece uma lista mais completa que inclui outros serviços e fica disponível nessa comparação.

---

03. Custos

A estrutura de preços é quase idêntica entre a AWS e a GCP. Os principais fatores que impactam no custo em ambos os serviços são o número de solicitações e o tempo de execução. É importante colocar aqui que outras tarifas podem ser cobradas por serviços paralelos, como transferência de dados ou custos de armazenamento, mas essas dependem do contexto do projeto.

Um detalhe importante que pode causar diferença entre os valores é como o tempo de computação é calculado em cada provedor. Na AWS, o tempo de execução é cobrado em incrementos de 1 milissegundo. Isso significa que cada milissegundo adicional é cobrado separadamente.

No Google Cloud Functions, o tempo de execução é arredondado para cima para cada intervalo de 100 milissegundos após o primeiro 100 milissegundos. Isso significa que, se a execução da função durar menos de 100 milissegundos, você não será cobrado por esse tempo. No entanto, se durar mais de 100 milissegundos, você será cobrado pelo tempo total arredondado para o próximo incremento de 100 milissegundos. Exemplo: uma função executada por 260 ms seria faturada como 300 ms.

Além disso, outro detalhe imporante sobre preço é que na GCP, o tempo de computação é medido considerando a alocação de memória (GB por segundo) e de poder de processamento da CPU (GHz por segundo).

Podemos analisar também os níveis gratuitos oferecidos pelos provedores de nuvem para seus serviços de funções serverless.

Como fazer cálculos de processamento:

500.000 invocações / 40 ms duração / 128 MB

• 40 ms = 0,04 seg
• 128 MB = 0,125 GB

Tempo de uso: 500.000 invocações/mês * 0,04 seg/invocação = 20.000 seg/mês

Memória Provisionada: 20.000 seg/mês * 0,125 GB = 2,5 GB-seg/mês

3.000.000 invocações / 230 ms duração / 1024 MB

• 230 ms = 0,23 seg
• 1024 MB = 1 GB

Tempo de uso: 3.000.000 invocações/mês * 0.23 seg/invocação = 690.000 seg/mês

Memória Provisionada: 690.000 seg/mês * 1 GB = 690 GB-seg/mês

Calculadoras online

• AWS: https://calculator.aws/#/createCalculator/Lambda
• GCP: https://cloud.google.com/products/calculator/
• FAAS Calc: https://faascalc.com/

Ps.: Eu não confio muito na calculadora do Google 🤷

---

04. Linguagens Suportadas:

Ambos os serviços foram certeiros em incluir uma variedade boa de linguagens suportadas. Enquanto o suporte do Cloud Functions do Google inclui Node.js, Python, Go e Java, Ruby, PHP e .NET, as Lambda Function da AWS tem uma lista um pouco mais extensa, facilitando o uso de TypeScript (usando ambiente de Node) e incluindo Rust e PowerShell.

Além disso, como trabalho principalmente com Python, pude notar o compromisso dos provedores em manter as tecnologias atualizadas. Na GCP, ainda é possível criar uma Lambda com Python 3.7, mas na AWS isso não é mais permitido. Vale mencionar também que tanto na AWS quanto na GCP, o Python 3.8 será descontinuado ainda este ano (2024). Uma tristeza para as empresas que adeptas da cultura do "Se tá funcionando não mexe".

---

05. Tempo limite de Execução:

O tempo de execução é um fator crucial a ser considerado ao escolher entre o Google Cloud Functions e a AWS Lambda. No Google Cloud Functions, o tempo limite varia de acordo com a geração da função: na primeira geração, o limite é de 9 minutos (540 segundos), enquanto na segunda geração, pode chegar a 60 minutos (3.600 segundos) para funções HTTP e permanece em 9 minutos (540 segundos) para funções orientadas a eventos.

Por outro lado, na AWS Lambda, o tempo limite padrão é de apenas 3 segundos, mas pode ser ajustado para até 15 minutos (900 segundos) conforme necessário. Esses limites podem afetar diretamente o desempenho e a funcionalidade de suas funções serverless, especialmente em casos de requisições externas síncronas.

Abaixo, uma tabela resume os limites de tempo de execução em ambas as plataformas:

---

06. Integração com o Ecossistema:

A integração com o ecossistema foi um dos fatores que mais me surpreenderam durante a transição. A AWS Lambda oferece uma integração bem flexível com todo o ecossistema AWS, o que tem sido extremamente útil na arquitetura atual em que trabalho. Desde integrações perfeitas com o Amazon S3, Amazon DynamoDB e Amazon API Gateway.

No entanto, um ponto negativo é que isso pode gerar um alto nível de acoplamento. Embora ambos os provedores ofereçam suporte à integração HTTP, a AWS exige o provisionamento e configuração de um recurso separado, o API Gateway, que também é cobrado separadamente.

---

07. Desempenho e Could Start

O desempenho e o tempo de inicialização são aspectos críticos a serem considerados ao avaliar as opções de computação serverless entre o Google Cloud Functions e a AWS Lambda. Embora as métricas de tempo de inicialização não sejam divulgadas publicamente pelos provedores, uma análise superficial revela algumas diferenças significativas.

Pesquisas indicam que as Cloud Functions têm um tempo de inicialização nativamente mais rápido em comparação com as Lambdas da AWS. No entanto, é desafiador elaborar um comparativo preciso devido à falta de informações detalhadas.

Na AWS, por exemplo, uma Lambda em Python em estado inativo pode iniciar em média em torno de 200ms, mas vale ressaltar que esse valor não considera o uso do recurso de provisioned concurrency, uma funcionalidade que elimina o Cold Start ao manter instâncias prontas para responder a solicitações.

---

08. Ferramentas de Linha de Comando (CLI)

As ferramentas de linha de comando desempenham um papel importante no gerenciamento das plataformas de nuvem. Ambos os provedores, AWS e GCP, oferecem suas próprias ferramentas CLI para facilitar a automação, implantação e gerenciamento de recursos na nuvem.

8.1 GCP

• gcloud tool: Com o gcloud, os usuários podem criar, modificar e gerenciar recursos como instâncias de máquinas virtuais, bancos de dados e serviços serverless.
• gsutil tool: Com o gsutil é possível fazer a transferência de arquivos, a configuração de políticas de acesso e a execução de várias outras operações em buckets do Cloud Storage. Pouco utilizado no contexto do GCP Cloud Functions.
• bq tool: O bq é uma ferramenta de linha de comando destinada principalmente para o BigQuery, o serviço de análise de dados do GCP. Com o bq, os usuários podem executar consultas SQL, carregar e exportar dados, além de gerenciar conjuntos de dados e tabelas. Essa ferramenta também é pouco utilizada no contexto do GCP Cloud Functions.

8.2 AWS

• AWS tool: A Interface de Linha de Comando da AWS é a principal ferramenta para interagir com os serviços da AWS através da linha de comando. Com a AWS CLI, os usuários podem gerenciar instâncias EC2, buckets S3, funções Lambda e uma variedade de outros serviços AWS.
• SAM tool: O AWS SAM (Serverless Application Model) é uma extensão da AWS CLI que facilita a criação, teste e implantação de aplicativos serverless na AWS. Com o AWS SAM, os desenvolvedores podem definir recursos serverless usando uma sintaxe simplificada e implantá-los com facilidade. O AWS SAM se sobrepõe ao AWS CLI para nos fornecer algumas ferramentas extras úteis.

---

09. Conclusão:

Como dizem, o diabo está nos detalhes. A escolha entre a AWS Lambda e o Google Cloud Functions vai além da comparação de recursos técnicos. Embora a AWS Lambda seja considerada mais madura, o Google Cloud Functions também é uma opção robusta, com sua própria gama de vantagens e funcionalidades. A decisão entre os dois provedores deve ser baseada não apenas nas características técnicas, mas também nos custos associados, na experiência do desenvolvedor e no contexto específico do projeto.

Minha migração da GCP para a AWS foi surpreendentemente tranquila, em contraste com os relatos de dificuldades que ouvi de profissionais que seguiram o caminho inverso. Isso pode ser atribuído às integrações e facilidades oferecidas pela AWS, destacando a importância de escolher uma plataforma que atenda às necessidades específicas do projeto e da equipe de desenvolvimento.

No geral, essa migração não apenas ampliou meu conhecimento sobre cloud computing e cloud native, mas também destacou a importância da independência de plataforma. Desenvolver e implantar software de forma independente dos provedores de nuvem subjacentes não só facilita a portabilidade entre diferentes serviços, mas também maximiza a utilização dos recursos, resultando em economia de custos significativa.