Google Cloud para profissionais da AWS: computação

Atualizado em 21 de novembro de 2017

Compare os serviços de computação que a Amazon Web Services (AWS) e o Google Cloud fornecem nos respectivos ambientes de nuvem. Os serviços de computação normalmente são oferecidos em quatro modelos:

  • Infrastructure as a Service (IaaS), em que os usuários têm acesso direto e sob demanda a máquinas virtuais, bem como a um conjunto de serviços relacionados para automatizar tarefas comuns.
  • Platform as a Service (PaaS), em que a camada de máquina é completamente abstraída e os usuários interagem com os recursos por meio de APIs e serviços de alto nível.
  • Funções como serviço (FaaS, na sigla em inglês), uma plataforma de computação sem servidor que permite executar funções individuais em resposta a uma variedade de acionadores.
  • Contêineres como serviço (CaaS, na sigla em inglês), um híbrido de IaaS/PaaS que abstrai a camada da máquina, mas mantém grande parte da flexibilidade do modelo IaaS.

O foco deste artigo são os serviços de IaaS, PaaS, FaaS e CaaS oferecidos pelo Google Cloud e pela AWS.

Comparação de IaaS

Para IaaS, a AWS oferece o Amazon Elastic Compute Cloud (EC2), e o Google Cloud oferece o Compute Engine. O Google e a Amazon adotam abordagens semelhantes aos serviços de IaaS. Tanto o Amazon EC2 quanto o Compute Engine são:

  • componentes fundamentais do ambiente de nuvem deles;
  • usados para executar quase todo tipo de carga de trabalho na plataforma deles.

Em um alto nível, a terminologia e os conceitos do Amazon EC2 são mapeados para os do Compute Engine.

Recurso Amazon EC2 Compute Engine
Máquinas virtuais Instâncias Instâncias
Imagens de máquina Amazon Machine Image Imagem
Máquinas virtuais temporárias Instâncias spot VMs preemptivas
Firewall Grupos de segurança Regras de firewall do Compute Engine
Escalonamento automático de instâncias Escalonamento automático Autoescalador do Compute Engine
Disco anexado local Disco temporário SSD local
Importação de VM Formatos compatíveis: RAW, OVA, VMDK e VHD Formatos compatíveis: RAW, OVA, VMDK e VHD
Localidade da implantação Por zona Zona

Instâncias de máquina virtual

As instâncias de máquina virtual do Compute Engine e do Amazon EC2 compartilham muitos dos mesmos recursos. Nos dois serviços, você:

  • cria instâncias a partir de imagens de disco armazenadas;
  • inicia e encerra instâncias sob demanda;
  • gerencia as instâncias sem restrições;
  • marca as instâncias;
  • instala uma série de sistemas operacionais disponíveis na instância.

Acesso à máquina

O Compute Engine e o Amazon EC2 abordam o acesso à máquina de maneiras um pouco diferentes:

  • O Amazon EC2 requer que você inclua sua própria chave SSH para ter acesso de terminal à instância.
  • O Compute Engine permite que você crie a chave quando precisar, mesmo que a instância já esteja em execução.
  • Use o terminal SSH baseado em navegador do Compute Engine, que está disponível no Console do Google Cloud, sem precisar armazenar chaves em sua máquina local.

Tipos de instância

O Amazon EC2 e o Compute Engine oferecem várias configurações de instâncias predefinidas com quantidades específicas de RAM, rede e CPU virtual.

  • O Amazon EC2 se refere a essas configurações como tipos de instância.
  • O Compute Engine refere-se a elas como tipos de máquina.
  • O Compute Engine permite que você altere as configurações predefinidas, personalizando a CPU e a RAM da instância de acordo com a carga de trabalho.

As instâncias predefinidas podem ser categorizadas aproximadamente pelo uso pretendido, conforme descrito nesta tabela:

Tipo de máquina Descrição
Núcleo compartilhado

Máquinas que são executadas em uma parte de uma única CPU física.

Adequado para tarefas que não exigem muitos recursos, mas precisam permanecer on-line por longos períodos de tempo.

Padrão

Máquinas que fornecem um equilíbrio de recursos de computação, rede e memória.

Adequado para a maioria das aplicações gerais sem demandas específicas de recursos.

Alta memória

Máquinas que têm uma proporção maior que a padrão de memória para as vCPUs.

Adequado para aplicativos que usam muita memória e que não exigem muita computação. Alguns exemplos incluem aplicativos de banco de dados de alto desempenho, aplicativos que precisam manter grandes caches de dados e aplicativos grandes, orientados a dados, como sistemas de gerenciamento corporativo.

Alta CPU

Máquinas que têm uma proporção maior que a padrão de vCPUs para a memória.

Adequado para aplicativos com uso intensivo de computação que não têm necessidades de memória excepcionalmente altas. Alguns exemplos incluem software de transformação de dados, como os de codificação de vídeo, software de simulação para ciência e engenharia e servidores Web de tráfego intenso.

GPU

Máquinas que incluem unidades de processamento gráfico (GPUs, na sigla em inglês) distintas.

Adequado para aplicações que exigem processamento matemático muito elevado. Um exemplo típico é o aprendizado de máquina, mas há muitas outras tarefas que se beneficiam do aumento da eficiência do processamento matemático avançado fornecido pelas GPUs.

Armazenamento SSD

Máquinas que têm armazenamento local em unidade de estado sólido (SSD, na sigla em inglês).

Adequado para aplicativos que dependem de alta capacidade para armazenamento. O armazenamento SSD oferece acesso a dados mais rápido que o armazenamento magnético.

Armazenamento denso

Máquinas que incluem armazenamento de mídia magnética de alta capacidade.

Adequado para aplicativos que mantêm grandes quantidades de dados em discos locais. Em muitos casos, aplicativos com grandes requisitos de armazenamento podem armazenar dados em outros serviços da Web, em vez de em discos conectados a VMs.

A tabela a seguir lista os tipos de instância dos dois serviços em maio de 2016.

Tipo de máquina Elastic Compute Cloud Compute Engine
Núcleo compartilhado t2.micro - t2.large f1-micro
g1-small
Padrão m3.medium - m3.2xlarge
m4.large - m4.10xlarge
n1-standard-1 - n1-standard-64
Muita memória r3.large - r3.8xlarge
x1.32xlarge
n1-highmem-2 - n1-highmem-64
Muita CPU c3.large - c3.8xlarge
c4.large - c4.8xlarge
n1-highcpu-2 - n1-highcpu-64
GPU g2.2xlarge
g2.8xlarge
Adicionar GPUs à maioria dos tipos de máquina
Armazenamento SSD i2.xlarge - i2.8xlarge n1-standard-1 - n1-standard-64
n1-highmem-2 - n1-highmem-64
n1-highcpu-2 - n1-highcpu-64*
Armazenamento denso d2.xlarge - d2.8xlarge N/D

* Embora o Compute Engine não ofereça tipos de máquina que correspondam exatamente a esses tipos de instância da AWS, conectar o armazenamento SSD local a outros tipos de máquina pode causar o mesmo resultado.

O Compute Engine e a AWS compartilham várias famílias de alto nível de tipos de instância, incluindo padrão, memória alta, CPU alta e núcleo compartilhado. No entanto, o Compute Engine não tem categorias específicas para instâncias que usam armazenamento SSD local. Todos os tipos de instância não compartilhados do Compute Engine são compatíveis com a adição de discos SSD locais. Consulte Armazenamento conectado localmente para ver uma comparação mais detalhada de como cada ambiente implementa SSDs conectados localmente.

No momento, o Compute Engine não oferece grande armazenamento magnético.

Instâncias temporárias

Instâncias temporárias são máquinas virtuais executadas em ciclos de reposição de recursos alocados para outros processos. O resultado é uma VM com disponibilidade imprevisível e um custo menor do que uma VM criada com recursos dedicados. As instâncias temporárias são úteis para:

  • jobs que podem ser interrompidos sem a perda do trabalho;
  • jobs de baixa prioridade que não exigem conclusão dentro de um prazo específico;
  • recursos extras para jobs que se beneficiam de uma otimização da capacidade de processamento, quando disponível. A renderização de vídeo é um exemplo disso.

O Amazon EC2 oferece instâncias temporárias denominadas instâncias spot e o Compute Engine oferece instâncias semelhantes denominadas VMs preemptivas. Ambas fornecem funcionalidade semelhante, mas têm modelos de preços diferentes.

Tanto as instâncias spot quanto as VMs preemptivas são:

  • restritas a um conjunto menor de tipos de instância e imagens de máquina disponíveis do que as instâncias regulares sob demanda;
  • capazes de proporcionar o mesmo desempenho das instâncias sob demanda durante a execução;
  • totalmente controláveis durante a execução.

As instâncias spot do Amazon EC2 têm duas variedades:

  • As instâncias spot comuns:
    • são leiloadas no mercado spot;
    • são iniciadas quando um lance é aceito;
    • ficam ativas até você encerrá-las ou a AWS interrompê-las.
  • Os blocos spot:
    • recebem um preço fixo abaixo da taxa normal sob demanda;
    • são limitados ao máximo de seis horas com a taxa de desconto.

As VMs preemptivas do Compute Engine têm as seguintes diferenças em relação às instâncias spot:

  • O preço é fixo. Dependendo do tipo de máquina, os preços das VMs preemptivas podem ter quase 80% de desconto em relação à taxa sob demanda.
  • Se não forem recuperadas pelo Compute Engine, as VMs preemptivas serão executadas por no máximo 24 horas e, em seguida, serão encerradas automaticamente.
  • Se você usar um sistema operacional Premium com uma taxa de licença, o custo total da licença ao usar essa VM preemptiva será cobrado.

Imagens de máquina

O Compute Engine e o Amazon EC2 usam imagens de máquina para criar novas instâncias. A Amazon chama essas imagens de Amazon Machine Images (AMIs, na sigla em inglês), e o Compute Engine as chama simplesmente de imagens.

O Amazon EC2 e o Compute Engine são semelhantes o bastante para que você consiga usar o mesmo fluxo de trabalho para a criação de imagens nas duas plataformas. Por exemplo, as AMIs do Amazon EC2 e as imagens do Compute Engine contêm um sistema operacional. Elas também podem conter outros softwares, como servidores Web ou bancos de dados. Além disso, ambos os serviços permitem que você use imagens publicadas por fornecedores de terceiros ou imagens personalizadas criadas para uso particular.

O Amazon EC2 e o Compute Engine armazenam imagens de maneiras diferentes. Na AWS, você armazena imagens no Amazon Simple Storage Service (S3) ou no Amazon Elastic Block Store (EBS). Se você criar uma instância com base em uma imagem armazenada no Amazon S3, terá latência maior durante o processo de criação do que com o Amazon EBS.

No Google Cloud, as imagens são armazenadas no Compute Engine. Para ver as imagens disponíveis ou criar ou importar imagens, acesse a página de imagens do Cloud Console ou use a ferramenta de linha de comando gcloud no SDK do Cloud.

Ao contrário do Amazon EC2, o Compute Engine não tem um mecanismo para tornar uma imagem publicamente disponível nem um repositório da comunidade de onde retirar imagens disponíveis. No entanto, você pode compartilhar imagens de maneira informal ao exportá-las para o Google Cloud Storage e torná-las publicamente disponíveis.

As imagens de máquina da Amazon estão disponíveis apenas em uma região específica. Em contrapartida, as imagens de máquina do Compute Engine estão globalmente disponíveis.

Imagens públicas

O Amazon EC2 e o Compute Engine oferecem uma variedade de imagens públicas com sistemas operacionais comumente usados. Nas duas plataformas, se você optar por instalar uma imagem premium com um sistema operacional que exija uma licença, pagará uma taxa de licença além dos custos normais da instância.

Nos dois serviços, você pode acessar imagens de máquina para a maioria dos sistemas operacionais comuns. Para ver a lista completa das imagens disponíveis no Compute Engine, consulte a lista de imagens públicas.

O Amazon EC2 é compatível com algumas imagens de sistemas operacionais que não estão disponíveis como imagens públicas no Compute Engine:

  • Amazon Linux
  • Windows Server 2003 (Premium)
  • Oracle Linux (Premium)

Importação de imagens personalizadas

O Amazon EC2 e o Compute Engine oferecem maneiras de importar imagens de máquina existentes para os respectivos ambientes.

O Amazon EC2 oferece um serviço denominado VM Import/Export (em inglês). Esse serviço é compatível com vários tipos de imagem de máquina virtual, como RAW, OVA, VMDK e VHD. Também é compatível com vários sistemas operacionais, incluindo variações do Windows, Red Hat Enterprise Linux (RHEL), CentOS, Ubuntu e Debian. Para importar uma máquina virtual, você usa uma ferramenta de linha de comando que agrupa a imagem da máquina virtual e faz o upload dela para o Amazon Simple Storage Service (S3) como uma AMI.

O processo e os requisitos para a importação de imagens de máquina para o Compute Engine são semelhantes aos do Amazon EC2. Assim como o VM Import/Export, a ferramenta de importação do Compute Engine é compatível com os tipos de imagem RAW, OVA, VMDK e VHD e os sistemas operacionais Windows, RHEL, CentOS, Ubuntu e Debian. Para importar uma máquina virtual, carregue a imagem no Cloud Storage e use a ferramenta de linha de comando gcloud ou Console do Cloud para concluir o processo de importação da imagem para o Compute Engine. Para mais detalhes sobre como importar imagens e outros recursos virtuais para o Compute Engine, consulte Como escolher um método de importação.

Se você cria seus próprios sistemas operacionais personalizados e planeja executá-los no Compute Engine, verifique se atendem aos requisitos de kernel e suporte de hardware para imagens personalizadas.

Além do custo de armazenar uma imagem no Amazon S3 ou no Cloud Storage, nem a AWS nem o Google Cloud cobram pelos respectivos serviços de importação.

Escalonamento automático de instâncias

Tanto o Compute Engine quanto o Amazon EC2 são compatíveis com escalonamento automático, em que as instâncias são criadas e removidas de acordo com políticas definidas pelo usuário. Esse escalonamento é usado para manter um número específico de instâncias em um determinado momento ou para ajustar a capacidade em resposta a determinadas condições. As instâncias do escalonamento são criadas a partir de um modelo definido pelo usuário.

O Compute Engine e o Amazon EC2 implementam o escalonamento automático de maneiras semelhantes:

  • O escalonamento automático da Amazon escalona as instâncias de um grupo. O autoescalador cria e remove instâncias de acordo com o plano de escalonamento selecionado. Cada nova instância do grupo é criada com base em uma configuração de inicialização.
  • O autoescalador do Compute Engine faz o escalonamento das instâncias de um grupo de instâncias gerenciadas. Ele cria e remove as instâncias de acordo com uma política de escalonamento automático. Cada nova instância do grupo é criada com base em um modelo de instância.

O escalonamento automático da Amazon permite três planos de escalonamento:

  • Manual, em que você instrui manualmente o escalonamento automático como horizontal ou vertical.
  • Programado, em que você configura o escalonamento automático como horizontal ou vertical em horários programados.
  • Dinâmico, em que o escalonamento automático realiza o escalonamento com base em uma política. É possível criar políticas com base em métricas do Amazon CloudWatch ou em filas do Amazon Simple Queue Service (SQS).

Em contrapartida, o autoescalador do Compute Engine só é compatível com escalonamento dinâmico. Você pode criar políticas com base em utilização média da CPU, capacidade de veiculação do balanceamento de carga HTTP ou métricas do Cloud Monitoring.

Redes internas

Tanto no Compute Engine quanto no Amazon EC2, instâncias novas são automaticamente conectadas a uma rede interna padrão. Além disso, você cria uma rede alternativa e inicia instâncias nessa rede nos dois serviços. Para ver uma comparação completa entre as redes do Google Cloud e da AWS, consulte o artigo Rede.

Firewalls

O Amazon EC2 e o Compute Engine permitem que os usuários configurem políticas de firewall para permitir e negar seletivamente o tráfego para instâncias de máquinas virtuais. Por padrão, os dois serviços bloqueiam todo o tráfego de entrada oriundo de fora de uma rede, e os usuários precisam definir uma regra de firewall para que os pacotes cheguem a uma instância.

O Amazon EC2 e o Amazon Virtual Private Cloud (VPC) usam grupos de segurança e listas de controle de acesso à rede (NACLs, na sigla em inglês) para permitir ou negar o tráfego de entrada e saída. Os grupos de segurança do Amazon EC2 bloqueiam as instâncias no Amazon EC2-Classic, enquanto as NACLs e os grupos de segurança da Amazon VPC protegem tanto as instâncias quanto as sub-redes da rede em uma Amazon VPC.

O Compute Engine usa regras de firewall para proteger redes e instâncias de máquinas virtuais do Compute Engine. Você cria uma regra especificando o intervalo de endereços IP de origem, o protocolo, as portas ou as tags definidas pelo usuário que representam os grupos de origem e de destino de instâncias de máquina virtual.

Armazenamento em bloco

O Amazon EC2 e o Compute Engine são compatíveis com armazenamento em bloco conectado em rede e localmente. Para ver uma comparação detalhada dos serviços de armazenamento em blocos deles, consulte Armazenamento em blocos.

Custos

Esta seção compara os modelos de preços do Compute Engine e do Amazon EC2.

Preços sob demanda

O Compute Engine e o Amazon EC2 têm modelos de preços sob demanda semelhantes para a execução de instâncias:

  • O Amazon EC2 cobra por segundo, com uma cobrança mínima de um minuto. Em sistemas operacionais Premium, como Windows ou RHEL, a cobrança é feita por hora e arredondada para a hora seguinte.
  • O Compute Engine cobra por segundo, com uma cobrança mínima de um minuto.

Os dois serviços permitem que você execute a instância indefinidamente.

Preços com desconto

O Compute Engine e o Amazon EC2 abordam preços com desconto de maneiras muito diferentes.

Preços com desconto são oferecidos no Amazon EC2 com o provisionamento de instâncias reservadas:

  • É necessário se comprometer com determinado número de instâncias por um ou três anos.
  • Você recebe um custo menor por essas instâncias.
  • Com o compromisso de três anos, você tem descontos maiores do que com o compromisso de um ano.
  • Quanto mais adiantado você pagar, maior o desconto.
  • As instâncias reservadas são vinculadas a um tipo de instância específico e a uma zona de disponibilidade no ato da compra.
  • É possível alternar as zonas de disponibilidade e trocar as instâncias reservadas apenas por tipos de instância diferentes na mesma família.

Você tem um desconto por uso prolongado nas instâncias do Compute Engine:

  • O Compute Engine aplica os descontos automaticamente às instâncias, dependendo de quanto tempo as instâncias ficam ativas em determinado mês.
  • Quanto mais tempo uma instância for usada em um determinado mês, maior será o desconto.
  • Com os descontos por uso prolongado, é possível economizar até 30% da taxa padrão sob demanda.

Comparação de FaaS

Para as funções como serviço (FaaS, na sigla em inglês), a Amazon oferece o AWS Lambda e o Google Cloud oferece o Cloud Functions. Esses serviços têm modelos semelhantes:

  • Ambos são plataformas de computação sem servidor que possibilitam executar funções individuais em resposta a uma variedade de acionadores.
  • Você só é cobrado enquanto as funções estão em execução.
  • Eles fornecem uma maneira econômica de hospedar serviços com padrões de uso desiguais.

Comparação do modelo de serviço

Os termos e conceitos da AWS Lambda correspondem aos do Cloud Functions da seguinte maneira:

Recurso AWS Lambda (links em inglês) Cloud Functions
Código de ingestão Upload do zip, ambiente de desenvolvimento integrado on-line e no desktop, Amazon S3 Upload do ZIP, ambiente de desenvolvimento integrado on-line, Cloud Storage, GitHub
Latência de atualização do código Normalmente em segundos Normalmente em menos de 2 minutos
Execuções simultâneas máximas 1.000 por região, por padrão 1.000 por função, por padrão
Tamanho máximo da implantação 50 MB compactado, 250 MB não compactado 100 MB compactado, 500 MB não compactado
Gatilhos S3, DynamoDB, Kinesis Streams e Firehose, SNS, SES, Cognito, CloudFormation, CloudWatch, CodeCommit, eventos programados, alterações de configuração da AWS, Amazon Echo, Amazon Lex, API Gateway (HTTP), botão IoT, CloudFront HTTP, Cloud Storage, Pub/Sub, Firebase, Cloud Logging
Linguagens suportadas Node.js, Java, Python, C#, Go Node.js 6, Node.js 8, Python
Alocações de memória 128 MB a 1,5 GB em incrementos de 64 MB 128 MB, 256 MB, 512 MB, 1 GB, 2 GB
Limites de tempo limite 1 segundo a 15 minutos 1 segundo a 9 minutos
Versões Integrado Por meio do Cloud Source Repositories
Escalonamento automático Sim Sim
Como gerar registros Amazon CloudWatch Cloud Logging
Localidade da implantação Regional Por região
Modelo de preços Por solicitação, duração em incrementos de 0,1s e transferência de dados. O custo da duração aumenta com o uso de memória. Por solicitação, duração em incrementos de 0,1s e transferência de dados. O custo da duração aumenta com o uso de memória e CPU.

Inicialização e escalonamento

O AWS Lambda e o Cloud Functions compartilham uma série de recursos. Ambos oferecem execução de código sem servidor com uma variedade de acionadores e escalonam automaticamente quando necessário. Os dois oferecem recuperação de falhas, implantação e escalonamento simples. A arquitetura inicia um contêiner de computação com uma cópia do seu código e escalona automaticamente o número de instâncias para lidar com a carga da solicitação. Nenhuma configuração ou gerenciamento é necessário para o escalonamento depois que a função é implantada.

O Google utiliza uma arquitetura de geração de imagem preemptiva que reduz significativamente a latência para as primeiras solicitações em qualquer nova instância. Isso pode ser uma vantagem significativa para aplicativos em tempo real ou situações em que seu aplicativo previsa escalonar muito rapidamente.

Linguagens e gatilhos compatíveis

O Lambda está disponível há mais tempo que o Cloud Functions e, consequentemente, é compatível com mais linguagens e tipos de gatilhos. O Cloud Functions é compatível com gatilhos do Firebase, Pacote de operações do Google Cloud e Pub/Sub. Com essas ferramentas, é possível acionar um Cloud Function a partir de praticamente qualquer outro serviço ou evento do Google Cloud.

Limites de tempo de execução

Como as plataformas FaaS são criadas para serem puramente transacionais, implantando instâncias por solicitação, não é possível depender delas para executar código continuamente além da solicitação inicial. É recomendável projetar seu aplicativo para ser sem estado e de curta duração. Isso se aplica tanto ao Lambda quanto ao Cloud Functions:

  • A AWS encerra a execução após 5 minutos.
  • O Cloud Functions encerra a execução após 9 minutos.

Implantação de FaaS

A Amazon e o Google adotam abordagens um pouco diferentes para implantar FaaS. O AWS Lambda permite a implantação a partir de um arquivo zip ou jar ou por meio do CloudFormation ou S3 (em inglês). Além dos arquivos zip, o Cloud Functions do Google Cloud pode ser implantado a partir de um repositório Git no GitHub ou no Cloud Source Repositories. O suporte do Git vincula o Cloud Functions ao seu processo de implantação. É possível até configurar atualizações automatizadas com base em webhooks.

Custos

O preço do AWS Lambda (em inglês) inclui uma taxa básica por solicitação, mais uma taxa variável com base na alocação de RAM e no tempo de computação. A cobrança de transferência de dados é feita pelo AWS Lambda com base na taxa EC2 padrão.

O Cloud Functions cobra uma taxa variável com base na quantidade de memória e CPU provisionada, além da taxa de invocação. Da mesma forma que o AWS Lambda, o Cloud Functions cobra taxas padrão pela largura de banda de saída e não cobra pelo tráfego de entrada.

Para detalhes, consulte a página de preços do Cloud Functions. Para estimar o custo da carga de trabalho específica, teste a calculadora de preços do Google Cloud.

Comparação de PaaS

Para PaaS, a AWS oferece o AWS Elastic Beanstalk, e o Google Cloud oferece o App Engine. Os dois serviços têm funcionalidades semelhantes:

  • É possível publicar aplicativos enviando o código para um serviço de plataforma gerenciada.
  • O serviço gerencia:
    • infraestrutura subjacente;
    • escalonamento automático;
    • controle de versões de aplicativos.

Comparação do modelo de serviço

O AWS Elastic Beanstalk configura e implanta um conjunto de recursos da AWS subjacentes, como instâncias do Amazon EC2 ou bancos de dados do Amazon RDS, para criar um tempo de execução apropriado para seu aplicativo, com base na configuração de entrada.

O App Engine emprega o mesmo modelo. No entanto, o App Engine fornece dois ambientes distintos: ambiente padrão e ambiente flexível, cada um com foco em casos de uso específicos.

  • No ambiente padrão do App Engine, o código é implantado em instâncias de contêiner que são executadas na infraestrutura do Google. Como esse ambiente não depende das instâncias subjacentes de VM do Compute Engine, ele é escalonado mais rapidamente do que o ambiente flexível do App Engine. No entanto, as opções de personalização do ambiente padrão do App Engine são mais limitadas do que as do ambiente flexível, e você precisa usar um ambiente de execução com base no conjunto predefinido de ambientes de execução do serviço.
  • No ambiente flexível do App Engine, o código é implantado nos contêineres do Docker em execução nas instâncias de VM do Compute Engine. Esses contêineres são gerenciados pelo App Engine. A lista de ambientes de execução permitidos é maior do que a do ambiente de execução padrão do App Engine. É possível criar tempos de execução parcial ou totalmente personalizados. No entanto, durante picos de alto tráfego, o aplicativo pode ser escalonado mais lentamente do que no ambiente padrão do App Engine. Para informações sobre como determinar o melhor ambiente do App Engine para você, consulte Como escolher um ambiente do App Engine.

O Elastic Beanstalk pode ser integrado a estes serviços:

  • Amazon DynamoDB: banco de dados NoSQL totalmente gerenciado capaz de armazenar e recuperar qualquer quantidade de dados
  • Amazon RDS: serviço gerenciado de banco de dados relacional, com tecnologia MySQL, PostgreSQL, MariaDB, Amazon Aurora, Oracle, Microsoft SQL Server;
  • escalonamento automático e balanceamento de carga;
  • ambientes do Worker Tier com integração a SQS, que permitem o processamento de tarefas periódicas e em segundo plano;
  • Outros serviços e APIs da AWS

Os dois ambientes do App Engine podem usar o mesmo conjunto de serviços de plataforma, como:

  • Firestore: armazenamento persistente com consultas, classificação e transações
  • Cloud SQL: banco de dados relacional com tecnologia MySQL ou PostgreSQL (atualmente na versão Beta)
  • escalonamento automático e balanceamento de carga;
  • filas de tarefas assíncronas para realizar trabalhos fora do escopo de uma solicitação;
  • tarefas programadas para acionar eventos em horários específicos ou intervalos regulares;
  • integração com outros serviços e APIs do Google Cloud

Principais componentes

Tanto o AWS Elastic Beanstalk quanto o App Engine operam em um conjunto semelhante de componentes-chave. Do ponto de vista de um desenvolvedor, o AWS Elastic Beanstalk consiste nos seguintes componentes-chave:

  • Versão do aplicativo: uma iteração nomeada/rotulada do código implantável enviada pelo desenvolvedor.
  • Ambiente: uma instância em execução de uma versão de aplicativo específica implantada em recursos da AWS.
  • Configuração do ambiente: uma coleção de parâmetros e configurações que controlam o modo como o Elastic Beanstalk implanta e configura os recursos subjacentes da AWS em relação a uma determinada versão do aplicativo associada a um ambiente específico.
  • Aplicativo: um bucket lógico para uma coleção de ambientes, configurações de ambiente e versões de aplicativos.

O App Engine consiste nos seguintes componentes-chave:

  • Versão: uma iteração nomeada do código implantável enviada pelo desenvolvedor e um arquivo de configuração especificando como implantar esse código no App Engine para criar um serviço.
  • Serviço: um aplicativo do App Engine é composto de um ou mais serviços, que podem ser configurados para usar diferentes tempos de execução e operar com diversas configurações de desempenho. Cada serviço tem o código-fonte e um arquivo de configuração.
  • Arquivo de configuração de serviço: um arquivo que especifica como os caminhos de URL correspondem aos gerenciadores de solicitação e arquivos estáticos. Este arquivo também contém informações sobre o código do aplicativo, como ID e identificador da versão mais recente.
  • Instância: um recurso subjacente de computação em que um serviço está sendo executado. Para o ambiente flexível do App Engine, uma instância é um contêiner do Docker em uma instância de VM do Compute Engine. Para o ambiente padrão do App Engine, uma instância é um contêiner em execução na infraestrutura do Google.
  • Aplicativo: um bucket lógico que inclui um ou mais serviços. Esse bucket pode ser configurado para usar diferentes tempos de execução e operar com diversas configurações de desempenho.

Em um nível mais elevado, as plataformas podem ser comparadas da seguinte maneira:

Recurso AWS Elastic Beanstalk Ambiente padrão do App Engine Ambiente flexível do App Engine
Tempos de execução da linguagem compatível Java, PHP, .NET, Node.js, Python (2.6, 2.7, 3.4), Ruby, Go Python 2.7, Java 7, PHP 5.5, Go 1.6 Python (2.7, 3.5), Java 8, Node.js, Go 1.8, Ruby, PHP (5.6, 7), .NET
Tempos de execução personalizados Sim Não Sim
Escalonamento automático Sim Sim Sim
Nível gratuito disponível Sim (com base no nível gratuito dos recursos AWS subjacentes) Sim (28 horas de instância por dia) Não
Opções de armazenamento Amazon S3, Amazon RDS, Amazon EFS, Amazon ElastiCache, Amazon DynamoDB Cloud Storage, Cloud SQL, Memcache, Firestore Cloud Storage, Cloud SQL, Memcache, Firestore
Papéis de IAM Sim Sim Sim
Locais disponíveis EUA, EMEA, APAC EUA, EMEA, APAC EUA, EMEA, APAC
Autenticação e autorização do usuário do aplicativo Não, precisam ser desenvolvidas no aplicativo Sim, com Firebase (vários provedores de identidade), Google Cloud Identity, OAuth 2.0 e OpenID Sim, com Firebase (vários provedores de identidade), contas do Google e G Suite, OAuth 2.0 e OpenID
Filas de tarefas e de mensagens Sim, usando SQS Sim, usando o Pub/Sub e a API Task Queue Sim, usando o Pub/Sub e a API Task Queue
Upgrades de aplicativos e testes A/B Atualização contínua com escalonamento baseado em capacidade de back-end, implantação azul/verde com troca de tráfego única. Round-robin ponderado é possível com abordagem baseada em DNS. Sim, com divisão de tráfego granular entre as versões Sim, com divisão de tráfego granular entre as versões
Monitoramento Sim, relatórios de integridade, registros de instâncias e stream de eventos do ambiente Sim, com o Pacote de operações do Google Cloud (solicitação/resposta e registros de atividades), verificações de tempo de atividade Sim, com o Pacote de operações do Google Cloud (registros de atividade/solicitação e resposta), verificações de tempo de atividade, métricas personalizadas e alertas para recursos subjacentes do Compute Engine
Rede Pode ser colocado em um VPC Sem controles de rede, apenas pontos de extremidade IP expostos à Internet Pode ser colocado em uma rede VPC
Preços Com base no custo dos recursos subjacentes do AWS Baseados na instância escolhida por hora O preço tem 3 parâmetros:
  • vCPU por núcleo/hora
  • memória por GB/hora
  • disco permanente por GB por mês
Depuração Sim, com raios-X Sim, com o Pacote de operações do Google Cloud Sim, com o Pacote de operações do Google Cloud

Tempos de execução personalizados

O AWS Elastic Beanstalk e o ambiente flexível do App Engine permitem que você crie seu próprio tempo de execução personalizado. Com esse recurso, você usa outras linguagens de programação ou usa uma versão ou implementação diferente dos tempos de execução padrão da plataforma.

O AWS Elastic Beanstalk oferece suporte a personalização por meio das plataformas personalizadas, que são imagens de máquina da Amazon (AMI, na sigla em inglês) que contêm os binários necessários para executar seu aplicativo. Você cria plataformas personalizadas com Packer, uma ferramenta de código aberto para criar imagens de máquinas idênticas para várias plataformas a partir de uma única configuração de origem. Usando um modelo de configuração do Packer, você pode personalizar sistemas operacionais, linguagens e bibliotecas, além de metadados e opções de configuração necessários para veicular seu aplicativo.

O ambiente flexível do App Engine é compatível com a personalização por meio dos tempos de execução personalizados. Para criá-lo, você cria um Dockerfile com uma imagem de base que você preferir e, em seguida, adiciona os comandos do Docker que compõem o ambiente de tempo de execução desejado. Seu Dockerfile pode incluir componentes adicionais, como intérpretes de linguagem ou servidores de aplicativos. Você pode utilizar qualquer software que atenda solicitações HTTP.

Em ambos os casos, você é responsável por garantir que todos os componentes sejam compatíveis e funcionem com o desempenho esperado.

O AWS Elastic Beanstalk usa Packer e permite aos usuários controlar toda a imagem do SO. O ambiente flexível do App Engine cria apenas contêineres do Docker, permitindo aos usuários controlar apenas o código do aplicativo e respectivas dependências. Um usuário do ambiente flexível do App Engine não tem permissão para controlar itens como a versão do kernel do SO nas VMs subjacentes.

Escalonamento automático

Tanto o AWS Elastic Beanstalk quanto o App Engine aceitam escalonamento automático. Dessa forma, é possível aumentar ou diminuir automaticamente o número de instâncias do back-end em execução com base no uso de recursos do seu aplicativo.

O escalonamento automático do AWS Elastic Beanstalk pode ser configurado com base nestas opções:

  • Configuração de inicialização: permite escolher acionadores de escalonamento e descrever parâmetros para eles.
  • Escalonamento manual: permite configurar a contagem mínima e máxima de instâncias, as zonas de disponibilidade e o resfriamento do escalonamento.
  • Escalonamento automático: permite configurar parâmetros com base em métricas. Os acionadores compatíveis incluem: entrada/saída de rede, utilização da CPU, operações/bytes de leitura e gravação de disco, latência, contagem de solicitações, contagem de hosts íntegros/não íntegros.
  • Escalonamento baseado em tempo: permite fazer o escalonamento horizontal e vertical das instâncias (configure o número máximo, mínimo e/ou desejado de instâncias) com base na predição de um evento recorrente ou planejado para uma única vez.

O ambiente padrão do App Engine oferece estas opções de escalonamento:

  • Configuração de inicialização: permite que você escolha uma opção de escalonamento e descreva os parâmetros.
  • Escalonamento manual: permite definir o número de instâncias no início do serviço.
  • Escalonamento básico: permite configurar o número máximo de instâncias e o tempo de inatividade. Depois desse tempo, a instância é desligada após o recebimento da última solicitação.
  • Escalonamento automático: permite que definir os níveis mínimo e máximo para o número de instâncias, a latência e as conexões simultâneas de um serviço.

O ambiente flexível do App Engine oferece estas opções de escalonamento:

  • Configuração de inicialização: permite que você escolha uma opção de escalonamento e descreva os parâmetros.
  • Escalonamento manual: funciona da mesma maneira que no ambiente padrão do App Engine.
  • Escalonamento automático: permite definir um número mínimo e máximo de instâncias, período de resfriamento e meta de utilização da CPU.

Atualizações de aplicativos e testes A/B

Para implantar ou atualizar um aplicativo no AWS Elastic Beanstalk e no App Engine, as etapas são semelhantes:

  1. Descreva seu aplicativo em um arquivo de configuração.
  2. Implante a nova versão usando uma ferramenta de linha de comando.

Os dois serviços também oferecem a implantação por meio dos respectivos consoles de gerenciamento.

No AWS Elastic Beanstalk, realizar atualizações no local pode fazer com que seu aplicativo sofra uma breve interrupção. Para evitar o tempo de inatividade, você pode executar uma implantação azul/verde, na qual você implanta a nova versão em um ambiente separado e, em seguida, URLs do ambiente de troca. Você pode veicular apenas uma versão ativa por ambiente. Round-robin ponderado é possível com abordagem baseada em DNS.

O App Engine permite que você implante as atualizações da versão atual sem tempo de inatividade, criando uma nova versão e migrando para ela. Você também pode configurar seu aplicativo do App Engine para dividir o tráfego com base no endereço IP do solicitante ou em um cookie. Você pode veicular diversas versões por serviço por aplicativo.

Depuração

Para depuração, o console do AWS Elastic Beanstalk permite que você execute um daemon de raio X do AWS nas instâncias em seu ambiente de desenvolvimento. Este daemon reúne dados sobre solicitações de servidores e colaboração de aplicativos com outros serviços. Você pode construir um mapa de serviços que o ajude a solucionar problemas no seu aplicativo e encontrar possíveis formas de otimizar.

No Google Cloud, você pode usar o Cloud Debugger para inspecionar o estado de um aplicativo do App Engine em qualquer local de código sem usar instruções de geração de registros e sem interromper ou atrasar seus aplicativos. Os usuários não são afetados durante a depuração. Usando o depurador na produção, você pode capturar as variáveis locais e a pilha de chamadas e vincular essas variáveis de volta a um local de linha específico em seu código-fonte. Você pode usar o Debugger para analisar o estado de produção de seu aplicativo e entender o comportamento de seu código em produção.

Monitoramento

O monitoramento de ambientes AWS Elastic Beanstalk no AWS Management Console consiste em métricas básicas, como utilização da CPU e rede, dentro e fora. O Amazon CloudWatch adiciona integridade de ambiente, bem como métricas básicas de monitoramento EC2 para instâncias subjacentes. O usuário também pode adicionar alarmes para cada uma dessas métricas. Todas as instâncias do EC2 geram registros que você pode usar para solucionar problemas de aplicativos.

O monitoramento de aplicativos do App Engine no painel do Console do Google Cloud fornece visibilidade de parâmetros como total de solicitações, utilização de CPU e memória, latência e tempo de atividade da instância. O pacote de operações do Google Cloud permite que você crie alertas para diferentes parâmetros e armazene registros.

Rede

O AWS Elastic Beanstalk permite gerenciar a conectividade dos recursos do AWS usados pelo ambiente. Você pode solicitar que o Elastic Beanstalk adicione VMs do EC2 a um VPC específico e configure Grupos de Segurança nessas instâncias. Isso permite que os aplicativos do Elastic Beanstalk atinjam um nível de transparência de conectividade de rede semelhante ao ambiente flexível do App Engine.

O ambiente padrão do Google App Engine abstrai completamente a configuração de rede. As únicas configurações relacionadas à rede com que você precisa trabalhar aplicam-se ao balanceamento de carga e ao nome de domínio personalizado referentes ao endereço externo do seu aplicativo. Também é possível aplicar o serviço de proteção DOS usando o arquivo dos.yaml para estabelecer uma "lista de proibições" da rede. Quando implantado junto com seu aplicativo, ele solicita que o App Engine exiba uma página de erro em resposta a solicitações provenientes de intervalos de IPs proibidos.

O ambiente flexível do Google App Engine usa máquinas virtuais (VMs) do Compute Engine para hospedar seu aplicativo em contêineres do Docker. É possível:

  • configurar as VMs gerenciadas pelo ambiente flexível do App Engine para serem conectadas às redes VPC. As redes VPC podem residir no mesmo projeto que o aplicativo Flex ou ser compartilhadas por vários projetos;
  • configurar as redes VPC com as instâncias de ambiente flexível do App Engine para serem conectadas a outros destinos usando o Cloud VPN;
  • aplicar as configurações do Firewall às instâncias do ambiente flexível do App Engine usando as tags da instância;
  • mapear as portas de rede nas instâncias Flex para as portas de contêiner do Docker para depuração e criação de perfis.

Essa flexibilidade é útil quando você cria aplicativos do ambiente flexível do App Engine que exigem conectividade transparente com outros serviços, em execução no Google Cloud ou fora dele (local ou em outra nuvem).

Custos

O AWS não cobra nenhuma taxa adicional pelo Elastic Beanstalk. Você paga apenas pelas instâncias do EC2 subjacentes e outros recursos.

O ambiente padrão do Google App Engine cobra por minuto de execução das instâncias. O faturamento começa quando uma instância começa e termina quinze minutos depois que uma instância manual é desligada ou quinze minutos depois que uma instância básica termina de processar sua última solicitação. Não há faturamento para instâncias inativas acima do número máximo de instâncias inativas definido nas configurações de desempenho. Há também uma cota gratuita: 28 horas de instância gratuitas por dia para módulos de escalonamento automático e 9 horas de instância gratuitas por dia para os módulos de escalonamento básico e manual.

O ambiente flexível do Google App Engine cobra por recursos de tipos de máquinas virtuais que você especifica. O custo é determinado pelo uso de parâmetros:

  • vCPU (por núcleo/hora)
  • memória (por GB/hora)
  • disco permanente por GB por mês

Estas cobranças são por minuto, com uma cobrança mínima de dez minutos de uso.

Para detalhes, consulte a página de preços do Compute Engine. Para estimar o custo da carga de trabalho específica, teste a calculadora de preços do Google Cloud.

Comparação entre CaaS

Para o CaaS, a AWS oferece o Amazon EC2 Container Service (ECS), e o Google Cloud oferece o Google Kubernetes Engine.

O GKE e o Amazon ECS têm modelos de serviço muito semelhantes. Em cada serviço, você cria um cluster de nós de contêiner. Cada nó é uma instância de máquina virtual, e cada um deles executa um agente de nó para sinalizar a inclusão dele no cluster. Cada nó também executa um daemon de contêiner, como o Docker, para que o nó possa executar aplicativos em contêiner. Você cria uma imagem do Docker que contém os arquivos do aplicativo e as instruções para executá-lo e, em seguida, implanta o aplicativo no cluster.

O Amazon ECS é desenvolvido e mantido pela Amazon. O Google Kubernetes Engine é baseado no Kubernetes, um sistema de gerenciamento de contêineres de código aberto.

Em um nível superior, a terminologia e os conceitos do Amazon ECS são mapeados para os do GKE da seguinte maneira:

Recurso Amazon ECS GKE
Nós do cluster Instâncias do Amazon EC2 Instâncias do Compute Engine
Daemons compatíveis Docker Docker ou rkt
Agente do node Amazon ECS Agent Kubelet
Grupo de contêineres Tarefa Pod
Serviço de dimensionamento de implantação Serviço Controlador de replicação
Ferramenta de linha de comando Amazon ECS CLI kubectl ou gcloud
Portabilidade Executado somente no AWS Executado onde quer que o Kubernetes funcione

Componentes da plataforma

Clusters

Tanto no Amazon ECS quanto no GKE, um cluster é um agrupamento lógico de nós de máquinas virtuais. No Amazon ECS, um cluster usa instâncias do Amazon EC2 como nós. Para criar um cluster, basta fornecer um nome para ele e o Amazon ECS o cria. No entanto, este cluster é vazio por padrão. É preciso iniciar instâncias de contêiner no cluster antes que o aplicativo possa ser iniciado.

No GKE, um cluster usa instâncias do Compute Engine como nós. Para criar um cluster, primeiro você fornece detalhes básicos de configuração definidos para os valores desejados, incluindo:

  • nome do cluster
  • zonas de implantação
  • tipos de máquina do Compute Engine
  • tamanho do cluster

Depois de configurar o cluster, o GKE o cria nas zonas solicitadas.

Grupos de contêineres

Tanto o Amazon ECS quanto o GKE agrupam conjuntos de contêineres interdependentes ou relacionados em unidades de serviço de nível superior. No Amazon ECS, essas unidades são chamadas de tarefas e são definidas por definições de tarefas. No GKE, essas unidades são chamadas de pods e são definidas por um PodSpec. Tanto nas tarefas quanto nos pods, os contêineres são colocalizados e coprogramados, sendo executados em um contexto compartilhado com um endereço IP e um espaço de porta compartilhado.

Daemons de contêiner

Cada máquina de nó precisa executar um daemon de contêiner para ser compatível com serviços de contêiner. O Amazon ECS é compatível com Docker como um daemon de contêiner. O Google Kubernetes Engine é compatível com Docker e rkt.

Agentes de nó

Cada nó do Amazon EC2 executa um agente do Amazon ECS que inicia contêineres em nome do Amazon ECS. Da mesma forma, cada nó do GKE executa um kubelet que mantém a integridade e a estabilidade dos contêineres em execução no nó.

Descoberta de serviço

O Amazon ECS não oferece um mecanismo nativo de descoberta de serviços em um cluster. Como solução alternativa, você pode configurar um serviço de descoberta de serviços de terceiros, como o Consul, para ativar a descoberta de serviços em um determinado cluster.

Os clusters do GKE permitem a descoberta de serviços por meio do complemento DNS do Kubernetes, que é ativado por padrão. Cada serviço do Kubernetes recebe um endereço IP virtual que é estável enquanto o serviço existir. O servidor DNS observa novos serviços da Kubernetes API e, em seguida, cria um conjunto de registros DNS para cada um. Esses registros permitem que os pods do Kubernetes realizem a resolução de nomes de serviços do Kubernetes automaticamente.

Como fazer a programação

O Amazon ECS é compatível somente com o programador nativo.

O GKE é baseado no Kubernetes, que é uma arquitetura plugável. Como tal, o GKE é totalmente compatível com o programador do Kubernetes, que é de código aberto e pode ser executado em qualquer ambiente em que o Kubernetes possa rodar.

Automação de implantação

No Amazon ECS, você pode criar um script para implantar tarefas em cada node. No entanto, esse comportamento não está incorporado ao serviço.

No GKE, é possível usar um DaemonSet para executar uma cópia de um pod específico em cada nó de um cluster. Quando os nós são adicionados ou removidos do cluster, o DaemonSet copia automaticamente o pod para os novos nós ou o lixo coleta os nós antigos. Quando você exclui o DaemonSet, ele limpa todos os pods criados por ele.

Gerenciamento de disco

Como os discos do Amazon ECS são específicos do host, um contêiner que depende de um determinado disco específico não pode ser movido para um host diferente.

Em contrapartida, o GKE pode montar discos de maneira dinâmica em um nó e atribuí-lo a um determinado pod automaticamente. Você não precisa executar um pod em um nó específico para usar um disco específico.

Gerenciamento de identidade e acesso

O Amazon ECS está totalmente integrado ao serviço Identity and Access Management (IAM) da AWS. No momento, o GKE não é compatível com o serviço de IAM do Google Cloud.

Multilocação

No Amazon ECS, você pode conseguir multilocação criando clusters separados e, em seguida, configurando manualmente o IAM da AWS para que limite o uso em cada cluster.

Em contrapartida, o GKE é compatível com namespaces, que permitem que os usuários agrupem clusters logicamente e fornecem um escopo para auxiliar clusters multilocatários. Os namespaces permitem:

  • a criação de várias comunidades de usuários em um único cluster;
  • a delegação de autoridade sobre partições do cluster para usuários confiáveis;
  • a restrição da quantidade de recursos que cada comunidade pode consumir;
  • a restrição de recursos disponíveis para os recursos que são pertinentes a uma comunidade de usuários específica;
  • o isolamento de recursos usados por uma determinada comunidade de usuários de outras comunidades de usuários no cluster.

Verificações de integridade

No Amazon ECS, é possível detectar falhas usando as verificações de integridade do Amazon ELB. O Amazon ELB faz verificações de integridade em HTTP/TCP. Para receber verificações de integridade, todos os serviços em contêiner (mesmo os que não precisam escutar uma porta TCP) precisam configurar um servidor HTTP. Além disso, cada serviço precisa estar vinculado a um ELB, mesmo que o serviço não precise ter balanceamento de carga.

No GKE, é possível realizar verificações de integridade usando sondagens de preparo e ativação:

  • As sondagens de preparo permitem verificar o estado de um pod durante a inicialização.
  • As sondagens de ativação permitem detectar e reiniciar pods que não estão mais funcionando corretamente.

Essas sondagens estão incluídas na API Kubernetes e podem ser configuradas como parte de um PodSpec.

Portabilidade

Como o agente do Amazon ECS só pode ser executado em instâncias do Amazon EC2, as configurações dele só podem ser executadas efetivamente no Amazon ECS. Em contrapartida, como o Google Kubernetes Engine é baseado no Kubernetes, as configurações dele podem ser executadas em qualquer instalação do Kubernetes.

Custos

A Amazon cobra pelas instâncias do Amazon EC2 e pelos volumes de disco do Amazon EBS que você usa na implantação. Não há custo extra para o serviço de gerenciamento de contêineres do Amazon ECS.

O Google Cloud cobra pelas instâncias do Compute Engine e pelos discos permanentes que você usa na implantação. Além disso, o GKE cobra uma taxa horária pelo gerenciamento de clusters. Clusters com cinco nós ou menos não têm essa taxa. Consulte os preços do GKE para saber mais.

A seguir

Confira os outros artigos do Google Cloud para profissionais da AWS: