Alternativa apenas UE a Google Cloud Platform.

O Google Cloud é o menor dos três hyperscalers dos EUA em quota de mercado na UE, mas tem a marca mais forte em engenharia de dados. Essa marca é o desafio da migração: BigQuery, Vertex AI, Spanner e o resto do catálogo do GCP são ferramentas excelentes, e não existe uma substituição soberana da UE equivalente para algumas delas. A resposta honesta é que, para a maioria dos workloads do mid-market - aplicações web, APIs, e-commerce - a stack soberana da UE é uma boa adequação. Para workloads especializados de engenharia de dados ou ML, a conversa é mais nuançada. Nós dizemos-lhe em que categoria o seu workload se enquadra.

Estados Unidos Stack de substituição, apenas UE 14 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: Google Cloud Platform
Sede: Mountain View, CA
Jurisdição: Estados Unidos
Regime jurídico: CLOUD Act, FISA 702, EO 12333

"Região UE" não é soberania. Quatro perguntas decidem.

A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.

Residência

Onde os dados estão fisicamente armazenados?

Não "na cloud": que centro de dados, em que país, sob que jurisdição.

Subprocessadores

Quem mais está no seu caminho de dados?

Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.

Jurisdição

Quais leis podem forçar a divulgação?

Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.

Custódia de chaves

Quem detém realmente as chaves de cifragem?

Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.

Não cumpre AWS · Azure · GCP · Região da UE

Falha em jurisdição e custódia de chaves.

Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.

Cumpre Stack gerida pela Binadit

Passa nos quatro.

Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.

Porque é que as equipas estão a sair Google Cloud Platform

As saídas do GCP que dimensionámos tendem a surgir de um de dois ângulos: um workload regulado que começou pequeno no GCP e agora precisa de conformidade com Schrems II para crescer, ou um SaaS B2B cujos clientes empresariais (bancos alemães, governo francês, saúde neerlandesa) exigiram explicitamente no contrato nenhum processador sob jurisdição dos EUA. Os desafios legais de 2024 ao Data Privacy Framework UE-EUA acrescentaram um terceiro fator - preocupação ao nível da liderança com outra reversão do mecanismo de transferência de dados. As ofertas soberanas licenciadas melhoram a documentação, mas herdam a tecnologia subjacente dos EUA.

Google Cloud Platform serviços e os seus equivalentes apenas na UE

Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Google Cloud Platform com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Google Cloud Platform serviço	O que usamos no lugar	Nota de engenharia
Compute Engine (GCE)	Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.	O preço por vCPU é drasticamente mais baixo em provedores europeus; instâncias reservadas são desnecessárias na escala típica.
Cloud Storage	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.	APIs compatíveis com S3 em todas estas opções; as alterações no SDK são mínimas.
Cloud SQL	Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.	A replicação em streaming permite-nos fazer a transição com segundos de downtime em vez de uma janela de manutenção, e as restaurações são testadas periodicamente em vez de assumidas.
GKE (managed Kubernetes)	Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.	O GKE Autopilot não tem equivalente direto; para a maioria dos workloads, K8s managed é suficiente. Talos em bare metal é a nossa configuração preferida de alta confiança.
Cloud Run	Binadit Managed Cloud Platform. Imagens Docker construídas no GitLab CI e implantadas no Kubernetes, com review environments por branch.	Knative é o upstream do Cloud Run; a migração é essencialmente um redeploy num cluster Knative hospedado na UE.
BigQuery	Binadit Managed Cloud Platform. ClickHouse ou PostgreSQL com extensões columnar, modelado com dbt.	Não existe um equivalente soberano 1:1 na escala do BigQuery. ClickHouse self-hosted é o padrão de produção; para verdadeira conformidade com Schrems II, esta é a carga de trabalho que a maioria dos clientes mantém num híbrido documentado.
Cloud Pub/Sub	Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, dependendo das garantias de entrega.	Kafka é o padrão para streams de eventos de alto volume; NATS é mais leve.
Cloud Functions	Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.	A migração de functions é mecânica; o desempenho de cold-start em opções soberanas na UE é competitivo.
Cloud DNS	Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.	Migração de zona padrão via AXFR ou exportação de zona.
Cloud CDN / Cloud Armor	Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.	A CDN é uma das poucas camadas que não operamos nós mesmos. Escolhemos o provedor europeu, configuramos cache headers, estratégia de purge e origin shielding, e operamos como parte do serviço gerido.
IAM / Cloud Identity	Binadit Managed Cloud Platform. Keycloak ou Authentik como identity provider, com OIDC e SAML.	A migração de OIDC/SAML é um caminho bem conhecido; a identidade do Workspace é uma decisão separada.
Cloud Operations (Stackdriver)	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrados com OpenTelemetry.	A instrumentação com OpenTelemetry torna a migração do lado da aplicação trivial.
Vertex AI / model APIs	Binadit Private Infrastructure. Modelos open-weight self-hosted em hardware GPU dedicado, servidos através de vLLM ou Ollama.	Esta é a linha onde é mais provável dizermos-lhe honestamente que a resposta é um híbrido. A qualidade dos modelos de fronteira não é algo que o self-hosting consiga igualar hoje.
Firestore / Firebase	Binadit Managed Cloud Platform. Replica sets MongoDB, ou PostgreSQL com JSONB onde o modelo de documentos é mais simples do que parece.	A sincronização em tempo real do Firestore é a peça mais difícil de substituir; para cargas de trabalho de documentos, PostgreSQL + LISTEN/NOTIFY costuma ser adequado.

Compute Engine (GCE)

O que usamos no lugar: Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.
Nota de engenharia: O preço por vCPU é drasticamente mais baixo em provedores europeus; instâncias reservadas são desnecessárias na escala típica.

Cloud Storage

O que usamos no lugar: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
Nota de engenharia: APIs compatíveis com S3 em todas estas opções; as alterações no SDK são mínimas.

Cloud SQL

O que usamos no lugar: Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.
Nota de engenharia: A replicação em streaming permite-nos fazer a transição com segundos de downtime em vez de uma janela de manutenção, e as restaurações são testadas periodicamente em vez de assumidas.

GKE (managed Kubernetes)

O que usamos no lugar: Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.
Nota de engenharia: O GKE Autopilot não tem equivalente direto; para a maioria dos workloads, K8s managed é suficiente. Talos em bare metal é a nossa configuração preferida de alta confiança.

Cloud Run

O que usamos no lugar: Binadit Managed Cloud Platform. Imagens Docker construídas no GitLab CI e implantadas no Kubernetes, com review environments por branch.
Nota de engenharia: Knative é o upstream do Cloud Run; a migração é essencialmente um redeploy num cluster Knative hospedado na UE.

BigQuery

O que usamos no lugar: Binadit Managed Cloud Platform. ClickHouse ou PostgreSQL com extensões columnar, modelado com dbt.
Nota de engenharia: Não existe um equivalente soberano 1:1 na escala do BigQuery. ClickHouse self-hosted é o padrão de produção; para verdadeira conformidade com Schrems II, esta é a carga de trabalho que a maioria dos clientes mantém num híbrido documentado.

Cloud Pub/Sub

O que usamos no lugar: Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, dependendo das garantias de entrega.
Nota de engenharia: Kafka é o padrão para streams de eventos de alto volume; NATS é mais leve.

Cloud Functions

O que usamos no lugar: Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.
Nota de engenharia: A migração de functions é mecânica; o desempenho de cold-start em opções soberanas na UE é competitivo.

Cloud DNS

O que usamos no lugar: Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.
Nota de engenharia: Migração de zona padrão via AXFR ou exportação de zona.

Cloud CDN / Cloud Armor

O que usamos no lugar: Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.
Nota de engenharia: A CDN é uma das poucas camadas que não operamos nós mesmos. Escolhemos o provedor europeu, configuramos cache headers, estratégia de purge e origin shielding, e operamos como parte do serviço gerido.

IAM / Cloud Identity

O que usamos no lugar: Binadit Managed Cloud Platform. Keycloak ou Authentik como identity provider, com OIDC e SAML.
Nota de engenharia: A migração de OIDC/SAML é um caminho bem conhecido; a identidade do Workspace é uma decisão separada.

Cloud Operations (Stackdriver)

O que usamos no lugar: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrados com OpenTelemetry.
Nota de engenharia: A instrumentação com OpenTelemetry torna a migração do lado da aplicação trivial.

Vertex AI / model APIs

O que usamos no lugar: Binadit Private Infrastructure. Modelos open-weight self-hosted em hardware GPU dedicado, servidos através de vLLM ou Ollama.
Nota de engenharia: Esta é a linha onde é mais provável dizermos-lhe honestamente que a resposta é um híbrido. A qualidade dos modelos de fronteira não é algo que o self-hosting consiga igualar hoje.

Firestore / Firebase

O que usamos no lugar: Binadit Managed Cloud Platform. Replica sets MongoDB, ou PostgreSQL com JSONB onde o modelo de documentos é mais simples do que parece.
Nota de engenharia: A sincronização em tempo real do Firestore é a peça mais difícil de substituir; para cargas de trabalho de documentos, PostgreSQL + LISTEN/NOTIFY costuma ser adequado.

Como migramos de Google Cloud Platform

Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.

Semanas 1-2

Âmbito de auditoria e engenharia de dados

Inventariar os serviços GCP, classificar por necessidade de soberania. Atenção especial ao uso de BigQuery e Vertex - estes definem a forma da migração. Resultado: plano faseado mais a decisão explícita sobre workloads de engenharia de dados.
Semanas 3-6

Edge, dependências leves, preparação de IAM

Cloud DNS, CDN, monitorização e Cloud Storage movidos primeiro. Keycloak implementado em paralelo com Cloud Identity para parallel-run. Pre-stage de compute em infraestrutura UE.
Semanas 6-14

Cutover principal + decisão de analytics

Os workloads GCE/GKE fazem a transição com blue-green. O Cloud SQL é replicado e comutado. O BigQuery é migrado para ClickHouse ou mantido num modelo híbrido documentado com os dados pessoais removidos na fronteira. Os workloads Vertex AI são movidos para Mistral ou equivalentes self-hosted.

TCO a 5 anos em saídas da GCP que já realizámos: 30-50% mais barato para workloads previsíveis. A exceção é analytics intensivo em BigQuery - nesse caso a poupança operacional da GCP muitas vezes justifica mantê-lo em modelo híbrido (com anonimização de dados pessoais na fronteira) em vez de migrar.

Perguntas frequentes

Ver todas as perguntas frequentes

Os "Sovereign Controls" da GCP ou uma oferta soberana licenciada resolvem a questão?

Sovereign Controls (anteriormente Google Cloud Sovereign) adiciona separação operacional: staff residente na UE, controlo de chaves de encriptação, audit logging. Não altera a jurisdição subjacente - a Google LLC continua a ser a proprietária da tecnologia. As ofertas soberanas licenciadas usam a mesma tecnologia sob licença; a ressalva está na camada da tecnologia. Para a maioria das análises Schrems II, ambas são melhorias mas não soberania total.

Podemos manter o BigQuery e migrar tudo o resto?

Sim, e este é um padrão comum. A disciplina: limpar ou anonimizar os dados pessoais na fronteira de ingestão, para que o que entra no BigQuery deixe de estar sujeito ao RGPD. Documente a fronteira no seu DPA. Já implementámos este padrão para várias cargas de trabalho de análise de mid-market.

Qual é a alternativa realista de ML/AI?

Mistral AI (FR) para modelos de fundação com qualidade comparável à classe GPT-4 sob jurisdição europeia. Aleph Alpha (DE) para workloads de LLM soberanos por design. Para treino, hardware GPU dedicado na UE cobre a maioria dos casos de uso. A diferença face ao Vertex AI está no polimento das ferramentas, não na capacidade bruta.

Como se compara a migração do GKE com o AKS ou EKS?

Mecanicamente semelhante - Helm charts, manifests e pipelines de CI/CD transferem-se sem problemas. Addons específicos do GKE (Workload Identity, cert-manager gerido pelo GKE) precisam de ser substituídos por equivalentes standard. Planeie 1-2 semanas para a migração dos addons do K8s.

Quanto tempo demora uma saída do GCP?

Para uma aplicação mid-market (GCE, Cloud SQL, GKE, Cloud Storage, sem BigQuery): 10-14 semanas de tempo decorrido. Com um parceiro de infraestrutura managed: 6-10 semanas. O BigQuery no âmbito adiciona 4-8 semanas dependendo do destino da migração.

E quanto ao Workspace (Gmail, Docs, Drive)?

O Workspace é uma conversa separada da infraestrutura GCP. Muitos clientes optam por um modelo híbrido: infraestrutura GCP substituída, Workspace mantido com exposição documentada. O caminho de migração do mailbox.org para o Workspace é bem suportado.

Planeie a sua saída de Google Cloud Platform.

Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.

Agendar uma chamada Comparar outro fornecedor