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.
Em geral, as semelhanças são muitas. Ambos os serviços são serverless, se encaixando na categoria conhecida como FaaS (Function as a Service), o que reduz a necessidade de gerenciar e manter servidores. Além disso, eles fornecem escalonamento automático com base na quantidade de requisições recebidas. Uma outra característica é que ambos são serviços que se enquadram dentro de uma arquitetura orientada a eventos (Event-Driven) muito conhecida de quem trabalha com mensageria.
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. No entanto, há algumas diferenças na forma como essas estruturas são implementadas em cada plataforma.
Na AWS, a estrutura de datacenter é composta por AZs (Zonas de Disponibilidade), que representam um data center físico isolado, dentro de uma região. Por exemplo, a região "us-east-1", costa leste dos Estados Unidos, abrange várias AZs, identificadas por letras como "us-east-1a", "us-east-1b" e assim por diante. Assim, uma região na AWS é uma área que abrange múltiplas AZs.
Por outro lado, na GCP, a região "us-west1" representa a costa oeste dos Estados Unidos e contém múltiplas zonas, como "us-west1-a", "us-west1-b" e "us-west1-c" também identificadas por letras. Cada região corresponde a uma área geográfica específica onde os recursos podem ser implantados.
Resumindo: Zonas = Zonas de Disponibilidade = 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 termos mais conhecidos
| Type | AWS | GCP |
|---|---|---|
| Serverless Functions | Lambda Function | Cloud Functions |
| API endpoints | API Gateway | Cloud Endpoints |
| Content Delivery Network (CDN) | Cloudfront | Cloud CDN |
| Kubernetes (K8s) Service | EKS | GKE |
| Messaging Queue Service | SQS e SNS | Cloud Pub/Sub |
| Operation, Log and Monitoring | CloudWatch | Cloud Logging e Cloud Monitoring |
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.
Outro fator semelhante com critérios diferentes é o nível gratuito oferecido por ambos os provedores. Por exemplo, o AWS Lambda oferece 1 milhão de solicitações gratuitas por mês e 400 mil GB-segundos de tempo de computação, enquanto o Google Cloud Functions oferece 2 milhões de solicitações, 400.000 GB-segundos de memória provisionada e 200.000 GHz-segundos de tempo de CPU.
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 de Execução:
Outra distinção importante é o tempo de execução e a capacidade de personalização. No Cloud Functions (1ª geração) do Google, a duração máxima do tempo limite é de 9 minutos (540 segundos), enquanto no Cloud Functions (2ª geração), esse tempo é de 60 minutos (3.600 segundos) para funções HTTP e 9 minutos (540 segundos) para funções orientadas a eventos. Já nas Lambdas Functions da AWS, o tempo limite padrão é de 3 segundos, mas pode ser ajustado em no máximo de 15 minutos (900 segundos).
O tempo de execução é um aspecto importante a ser considerado, especialmente se o projeto fizer uso de requisições externas síncronas. Se a latência média for alta ou instável, isso pode resultar no encerramento do Lambda antes que ele seja concluído.
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 profunda e 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. A GCP tem uma integração HTTP muito mais simplificada.
07. Desempenho e Could Start
Não pretendo aprofundar muito nesse aspecto, pois nenhum dos provedores divulga publicamente suas métricas de tempo de inicialização.
Buscando informações por cima na internet percebi que nativamente as Cloud Functions da GCP iniciam com um tempo menor, mas é bem complicado elaborar um comparativo para essa diferença. No entanto, pude observar que na AWS, uma Lambda em Python em estado inativo leva em média 200ms para iniciar. Isso sem considerar o recurso de "provisioned concurrency", que é uma funcionalidade que permite eliminar o Cold Start na AWS.
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. Em última análise, a AWS Lambda é mais madura enquanto o Cloud Functions tem alguns recursos a menos, mas ainda é bastante comparável à AWS. A escolha entre um provedor ou outro não é necessariamente uma questão de uma ser melhor do que a outra, mas sim de entender as nuances e adaptar-se às diferenças.
Além disso, percebi a importância de considerar não apenas os aspectos técnicos, mas também os custos associados, à experiência do desenvolvedor e também o contexto do projeto. Essa migração me proporcionou uma visão mais ampla do cenário de computação em nuvem e me capacitou a tomar decisões mais informadas sobre a infraestrutura de meus projetos futuros.
Top comments (1)
Parabéns pelo artigo, você trouxe muitos pontos importantes a serem analisados para comparação dos serviços. Eu utilizo só a AWS e achei interessante conhecer esses pontos da CGP tamém!