11
obrenoalvim
2 min de leitura ·

AWS vs GCP: depois de usar os dois, o que ninguém te conta antes de escolher

Trabalhei com AWS por 3 anos e migrei para GCP em um projeto recente. Aqui está o que aprendi que ninguém documentou direito.

O que a AWS faz melhor

Ecossistema. São 200+ serviços. Se existe um problema em infra, provavelmente tem um serviço da AWS para ele. A documentação é extensa e a comunidade é enorme — qualquer erro que você cometer, alguém já documentou a solução.

Integrações de terceiros. Bibliotecas, ferramentas de observabilidade, frameworks: tudo tem suporte para AWS primeiro.

O que o GCP faz melhor

BigQuery. Se você trabalha com dados em escala, não tem comparação. O modelo de precificação por query e a velocidade são difíceis de bater.

Kubernetes. Faz sentido — o Kubernetes nasceu no Google. O GKE tem menos atrito do que o EKS na maioria dos casos que vi.

Rede. A rede global do Google é genuinamente melhor para latência em regiões específicas.

O que ninguém conta

O suporte da AWS é caro e frustrante. O do GCP também, só que de formas diferentes.

A curva de aprendizado da AWS é real. Você não "aprende AWS" — você aprende serviços específicos. IAM sozinho é uma especialidade.

O GCP tem UX melhor no console, mas documentação pior para casos de uso fora do padrão.

A escolha real

Na prática a decisão quase nunca é técnica: é onde sua equipe já tem expertise, qual tem contrato enterprise negociado, qual o cliente usa.

Você alguma vez escolheu cloud por razão genuinamente técnica, ou foi sempre contexto?

Carregando publicação patrocinada...
5

Você alguma vez escolheu cloud por razão genuinamente técnica, ou foi sempre contexto?

Antes de 2010 existia o Google Application Engine (também chamado de app engine). Celulares não eram touch. Um colega indicou para mim e eu experimentei. Na época o painel deles era duas telas... e a documentação boa.
Eu usei até ~2020 com intervalos grandes... anos entre uma utilização e outra.
Eu (de certo modo) usei o 'predecessor' do GCP
GCP inda tem uma seção appengine, mas acho que antes o gcp era só o appengine.
Eu sempre usei a versão free.

Tenho uma história pra contar que pode impressionar:
Antes de o-auth httpsDefault...
A versão antiga do appengine começou com isso de login social (usar credencial de um server (google) para logar em outro)
a primeira vez que vi isso foi num teste meu do appengine

O projeto era para estudo. Basicamente base de dados txt manipulado por code python. 2 ou 3 crud. Na v1.0 eu tinha cadastro de user/senha. Fuçando na documentação vi que dava para usar o login do google.

Não era outra aba/tab/guia nem outra janelinha do browser com a tela de login do google. Meu site tinha um link unico (projeto id) que ia na url para a tela de login do google na mesma tab/aba/guia. O 'user' logava e voltava logado pra tela anterior. Muito rápido. Uma sensação de que meu sitezinho que eu testava estava no googleserver.
Imagina como o pessoal via...

2

Cara, isso é exatamente o tipo de coisa que ninguém fala quando discute OAuth. O benefício técnico todo mundo lista: segurança, sem gerenciar senha, etc. Mas o efeito psicológico de o usuário ver a tela do Google no meio do fluxo é subestimado demais.

A pessoa inconscientemente associa a velocidade e a confiabilidade do Google ao seu produto. Você não construiu isso, mas o crédito vai para você de qualquer forma.

Você ainda usa esse modelo de redirect na mesma aba ou migrou para popup? Tenho visto times debatendo os dois. O popup evita o "susto" de sair da página, mas perde exatamente esse efeito que você descreveu.

3

Eu não tô programando nada server-side processing a muitos anos. Tô só no client-side. Tenho usado o githubPages como host de páginas. Eu procuro oportunidades de voltar a programar sites e sistemas com bancos de dados e tudo mais, mas eu tava numa fase meio turbulenta da vida. Pra você ter ideia, cara, eu tô sem acessar email a quase 10 meses. E tô sem celular a esse tempo também.

1

Passar 10 meses sem email e sem celular e ainda assim continuar programando pelo GitHub Pages é uma forma diferente de se manter conectado. O client-side com GitHub Pages tem uma elegância nisso: você produz, versiona, publica, sem depender de nada externo. Quando as coisas se organizarem e você quiser voltar para o lado server-side, o que você mais sente que ficou pra trás ou quer explorar primeiro?

1
1

Continuar programando enquanto espera a oportunidade certa é a parte mais importante. Portfolio ativo pesa mais do que tempo esperando. O GitHub Pages como plataforma para isso faz sentido: você publica, fica visível, o trabalho fala por si. Quando você falar em server-side remunerado, tem alguma stack específica que quer reativar primeiro, ou está aberto para qualquer coisa que aparecer?

1

Eu queria algo fora do que já estou acostumado a fazer que é php/mysql.
Eu acho que queria mesmo era um cargo de "Gerência de Projetos" (eu tive aulas dessa matéria na faculdade. 6 meses. Na época eu não gostava nem um pouco porque eu só queria saber de programar)

1

Gerência de projetos e programação são mais complementares do que opostos. Quem sabe programar e consegue gerenciar escopo, risco e comunicação com stakeholders é raro e bem valorizado, especialmente em times pequenos onde você precisa das duas habilidades. PHP e MySQL ainda têm mercado, mas entendo a vontade de sair da zona de conforto. Se o interesse em gestão é real, vale explorar tech lead ou product engineer, que ficam no meio do caminho entre código e decisão. O que te afastou da gerência na época: era o perfil das aulas, a burocracia do processo, ou era simplesmente a fase errada para pensar nisso?

5

Minha impressão usando gcp há mais de 10 anos: parece que você precisa aprender tudo a cada novo projeto. Os caras mexem tudo dos lugares e vc fica procurando configurações que deveriam estar ali. O foda é que você configura um projeto e fica 1 ano nele, quand você volta para iniciar o próximo, tem que aprender tudo novamente.
Ja o aws parece mais lógico. Quand eles querem fazer mudança, criam outro produto. As coisas sao mais fáceis de achar. O gcp exige conhecimento técnico que nem todo mundo tem pra configurar coisas básicas. Quer criar uma máquina com uma porta específica liberada? Na aws é um clique. No gcp vc precisa criar rede, vpc, colocar regras de de ingress, criar firewall, e depois repetir tudo novamente dentro do container.
Acho muito merda aquele estilo. Às vezes a pessoa só quer subir um serviço básico e fica lá horas tentando acertar a configuração.

1

Dez anos de GCP e você ainda precisa redescobrir onde colocaram as configurações. Isso não é curva de aprendizado, é produto mal pensado.

O ponto que você levantou sobre a filosofia dos dois é o mais honesto que já vi nessa discussão. A AWS tem o vício de acumular produtos (hoje são mais de 200 serviços com sobreposição absurda), mas pelo menos o que você configurou ano passado ainda está onde você deixou. O GCP reorganiza a console com uma frequência que parece intencional para te fazer sentir que está sempre começando do zero.

O exemplo da porta liberada é perfeito. Na AWS você abre o security group, adiciona a regra de inbound, acabou. No GCP você literalmente precisa entender a hierarquia de rede do projeto antes de fazer qualquer coisa. Para quem não cresceu dentro da infraestrutura do Google, é contraintuitivo de um jeito que frustra.

Nos projetos em que você tinha liberdade de escolha, chegou a migrar para AWS ou ficou no GCP por conta de algum serviço específico que não tinha equivalente? BigQuery e Vertex AI são os dois que mais ouço como "motivo para aguentar o resto do GCP".

2
1

VPS mais Cloudflare é uma combinação que aparece cada vez mais. Você tem o controle do servidor sem pagar o overhead das clouds grandes, e a Cloudflare resolve edge, CDN e proteção sem precisar de infra adicional. Para a maioria dos projetos é suficiente. O que te fez ir para VPS: custo mesmo, ou cansaço de lidar com a complexidade do GCP? Pergunto porque parece que o gatilho é diferente pra cada dev, alguns saem por conta, outros por frustração com a experiência.

3
1

Essa config funciona muito bem pra projetos rápidos. Você controla a infra no VPS, Cloudflare entra sem atrito, e limitar GCP ao OAuth é mais honesto do que puxar cloud completa só por uma feature. O que eu ainda sinto falta comparado a nuvem gerenciada é observabilidade nativa, mas pra maioria dos projetos não faz diferença real.

3

Como desenvolvedor já há muito tempo não utilizo a interface de ambos os provedores, e sempre crio a infra usando código.
Sobre o suporte, em ambos já tive dificuldade, porém na empresa atual temos pessoas dedicadas, o que tem facilitado em muito resolver qualquer situação nos dois provedores.

1

Bom artigo Breno.

Agora, pq nao fazer colocation? Além da grande economia, é possível alcançar facilmente grande qualidade fora das grandes clouds públicas.

1

Colocation faz sentido em escala, mas o ponto de entrada é diferente. Quando você está validando produto, a elasticidade de subir e derrubar infra em minutos vale mais do que a economia em hardware. Em projetos maduros com carga previsível, a conta muda bastante: o custo de cloud pública fica difícil de justificar comparado ao controle que você tem com colocation. O problema é que poucas equipes chegam nessa maturidade com disciplina de ops suficiente para gerenciar o hardware sem dor. Qual o porte e estágio do projeto que você está pensando em fazer colocation?

3

Entendo o teu ponto. Como trabalho com sysadmin e devops faz muito tempo valeu a pena comprar um hardware e fazer colocation.

Um servidor com 40 threads de 2.4ghz e 192GB-Ram estava por 6mil reais no Mercado livre. E o colocation por R$2000/mês. É muito recurso pra explorar com projetos e hospedar meus próprios serviços.

O colocation está valendo muito a pena. Principalmente pela previsao de gasto, o valor é o mesmo todo mês. Vejo que a maior barreira é quando a empresa tem seus funcionários viciados em gcp,aws ou azure, mas isso é só um fantasma que é facilmente resolvido com treinamento.

1

Colocation faz sentido quando você tem o skill de gerenciar hardware e rede. O problema que a maioria das empresas ignora é o custo oculto: quem acorda às 3h quando o disco falha? Quando você é sysadmin, esse custo está no seu salário. Quando não é, aparece na conta do SRE ou na migração de emergência.

Para projetos pessoais e times pequenos com esse perfil, concordo que a relação custo/recurso é imbatível. R$2k por mês para 192GB de RAM seria impossível em cloud.

A questão do vício em cloud que você levantou é real, mas acho que o problema maior é o oposto: times que foram para cloud sem jamais ter gerenciado infra própria não sabem o que estão pagando para não fazer. Você acha que essa percepção muda com o tempo, ou é algo que só quem veio do on-prem realmente entende?

1

Esta é uma decisão estratégica e gostei dos pontos levantados, porque refletem uma experiência real com o uso dos serviços, e este projetos nasceram para suprir necessidade de outras empresas, então uma escolha pessoal é algo raro mas que pode ser também muito lucrativo para estas empresas caso o objetivo de suas escolhas ganhem escala.

Eu considero bom ambos, mas sempre opto por GCP porque ele resolve bem dores que vejo importantes que são os suportes e DX agradável.

1

GCP ganhando pelo suporte e DX faz sentido dependendo do contexto. Na minha experiência, o Console da GCP é visivelmente mais organizado do que o da AWS, especialmente pra quem está entrando em um projeto já rodando.

O que me fez ficar na GCP no projeto atual foi o BigQuery integrado com o resto do ecossistema. Para analytics a custo baixo, AWS não tem nada equivalente fácil de configurar.

Você usa GCP em projetos pessoais também ou só em contexto profissional?

1

Minha experiência é: se for pra usar serviços básicos (vps, storage, k8s, etc), não vejo problema no GCP, mas não usaria pra qualquer outro serviço mais especializado. A qualquer momento eles podem matar o serviço e te deixar na mão. Aconteceu comigo, onde tive que reescrever toda a arquitetura pq eles mataram o serviço de IoT - por sorte o parque instalado era pequeno, mas imagina se tivesse milhares de dispositivos pra atualizar? Que eu saiba, a AWS em toda a sua história, nunca derrubou nenhum dos produtos oferecidos (mesmo os depreciados). Já a Google, você pode ir lá no site que tem o cemitério de produtos.

1

Esse ponto do cemitério de produtos do Google é real e subestimado na hora de escolher. Passei por situação parecida: integrações que precisaram ser replanejadas porque o serviço mudou de plano drasticamente. A AWS tem histórico bem mais conservador nisso, você raramente vê eles depreciarem algo com urgência. O problema é que esse conservadorismo também aparece no ritmo de inovação: eles levam mais tempo para lançar coisas novas. Para IoT em particular, essa falta de confiança no GCP é crítica porque é exatamente onde você não quer surpresa. Depois do episódio, você migrou tudo para AWS ou foi mais seletivo por serviço?