Alternativa apenas UE a Oracle Cloud (OCI).

A Oracle Cloud Infrastructure é a menor das grandes hyperscalers no mid-market da UE, mas tem um peso desproporcional em setores regulados devido ao lock-in do Oracle Database. A Oracle Corporation é uma empresa dos EUA; as regiões UE da OCI (Frankfurt, Amesterdão, Marselha, Milão, Madrid, Estocolmo, Zurique) estão localizadas na UE mas são controladas pelos EUA ao abrigo do CLOUD Act. A Oracle tem promovido a "EU Sovereign Cloud" desde 2023 - regiões UE operacionalmente separadas com staff residente na UE - mas a jurisdição da empresa-mãe mantém-se inalterada. Para análises que exigem rigor Schrems II, isso não constitui soberania plena.

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

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: Oracle Cloud (OCI)
Sede: Austin, TX
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 Oracle Cloud (OCI)

As saídas da Oracle que temos executado envolvem quase sempre uma migração de base de dados além da infraestrutura - tipicamente Oracle DB → PostgreSQL, o que é um projeto substancial por si só. Os gatilhos: uma auditoria de serviços financeiros ao abrigo do DORA a assinalar a Oracle como risco de concentração jurisdicional nos EUA, uma revisão de custos que revelou a verdadeira exposição do licenciamento Oracle DB na cloud, ou uma decisão estratégica de eliminar totalmente a dependência da Oracle. A poupança a médio prazo é dramática quando tanto o custo de infraestrutura OCI como o custo de licenciamento Oracle DB são eliminados.

Oracle Cloud (OCI) 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 Oracle Cloud (OCI) com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Oracle Cloud (OCI) serviço	O que usamos no lugar	Nota de engenharia
Compute Instances	Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.	Migração de VM padrão; reconstrução e rebase da imagem. O Oracle Linux pode ser substituído por Rocky ou Alma sem impacto na aplicação.
Object Storage	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.	O OCI Object Storage tem uma API não compatível com S3; a reescrita é pequena, mas requer alterações no SDK.
Autonomous Database	Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.	A tarefa de migração individual mais longa. Ferramentas como o ora2pg e o migrator da Cybertec melhoraram significativamente. Planeie uma execução paralela de 3 a 9 meses, dependendo da complexidade do schema.
OKE (Oracle Kubernetes Engine)	Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.	Os Helm charts e YAML transferem-se sem problemas; funcionalidades específicas do OKE (nodepools managed do Container Engine for Kubernetes) são substituídas por equivalentes standard.
Block Volumes	Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn para volumes Kubernetes-native.	Migração de volume via snapshot + restauração.
Virtual Cloud Network (VCN)	Binadit Private Infrastructure. VLANs isoladas com WireGuard para acesso site-to-site e de operadores.	Os conceitos de OCI VCN (subnets, route tables, NAT gateways) mapeiam diretamente para o networking cloud padrão.
Functions (FaaS)	Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.	A migração é mecânica; o OCI Functions é construído sobre o Fn Project, pelo que o modelo de runtime é portável.
Streaming (Kafka-compatible)	Binadit Managed Cloud Platform. Apache Kafka ou Redpanda, compatível com o protocolo Kafka.	A migração do Kafka é um redirecionamento de producer/consumer; replicação de dados via MirrorMaker.
API Gateway	Binadit Managed Cloud Platform. Traefik ou Kong, com rate limiting e OIDC na edge.	A KrakenD tem sede em Espanha e é uma forte escolha soberana.
Load Balancer	Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.	Load balancing L4/L7 padrão.
Vault (KMS)	Binadit Private Infrastructure. Vault Transit para gestão de chaves, com chaves suportadas por HSM onde o regime de compliance o exigir.	O Vault é a resposta soberana de nível de produção.
Logging / Monitoring	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 mecânica.

Compute Instances

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: Migração de VM padrão; reconstrução e rebase da imagem. O Oracle Linux pode ser substituído por Rocky ou Alma sem impacto na aplicação.

Object Storage

O que usamos no lugar: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
Nota de engenharia: O OCI Object Storage tem uma API não compatível com S3; a reescrita é pequena, mas requer alterações no SDK.

Autonomous Database

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 tarefa de migração individual mais longa. Ferramentas como o ora2pg e o migrator da Cybertec melhoraram significativamente. Planeie uma execução paralela de 3 a 9 meses, dependendo da complexidade do schema.

OKE (Oracle Kubernetes Engine)

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: Os Helm charts e YAML transferem-se sem problemas; funcionalidades específicas do OKE (nodepools managed do Container Engine for Kubernetes) são substituídas por equivalentes standard.

Block Volumes

O que usamos no lugar: Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn para volumes Kubernetes-native.
Nota de engenharia: Migração de volume via snapshot + restauração.

Virtual Cloud Network (VCN)

O que usamos no lugar: Binadit Private Infrastructure. VLANs isoladas com WireGuard para acesso site-to-site e de operadores.
Nota de engenharia: Os conceitos de OCI VCN (subnets, route tables, NAT gateways) mapeiam diretamente para o networking cloud padrão.

Functions (FaaS)

O que usamos no lugar: Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.
Nota de engenharia: A migração é mecânica; o OCI Functions é construído sobre o Fn Project, pelo que o modelo de runtime é portável.

Streaming (Kafka-compatible)

O que usamos no lugar: Binadit Managed Cloud Platform. Apache Kafka ou Redpanda, compatível com o protocolo Kafka.
Nota de engenharia: A migração do Kafka é um redirecionamento de producer/consumer; replicação de dados via MirrorMaker.

API Gateway

O que usamos no lugar: Binadit Managed Cloud Platform. Traefik ou Kong, com rate limiting e OIDC na edge.
Nota de engenharia: A KrakenD tem sede em Espanha e é uma forte escolha soberana.

Load Balancer

O que usamos no lugar: Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.
Nota de engenharia: Load balancing L4/L7 padrão.

Vault (KMS)

O que usamos no lugar: Binadit Private Infrastructure. Vault Transit para gestão de chaves, com chaves suportadas por HSM onde o regime de compliance o exigir.
Nota de engenharia: O Vault é a resposta soberana de nível de produção.

Logging / Monitoring

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 mecânica.

Como migramos de Oracle Cloud (OCI)

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-4

Decisão sobre o escopo da base de dados

Mapeamos todas as funcionalidades específicas do Oracle DB em uso (PL/SQL, Oracle Text, particionamento, materialized views, queries hierárquicas, Oracle Spatial). Ponto de decisão: migração completa para PostgreSQL ou híbrida (workloads críticos em termos de compatibilidade numa distribuição PostgreSQL compatível com Oracle). Esta é a tarefa que define o cronograma.
Semanas 4-10

Migração de infraestrutura

Compute, rede e storage movidos para stack soberana UE. Workloads K8s movidos. Object storage migrado com reescritas de API onde necessário. CI/CD reapontado.
Semanas 8-24

Cutover de base de dados

Esquema convertido com ora2pg. Dados migrados com replicação lógica ou change-data-capture para workloads em produção. Código da aplicação revisto para SQL específico da Oracle. Janela de cutover agendada com plano de rollback completo.

TCO a 5 anos em saídas completas da Oracle (infraestrutura + base de dados): normalmente 50-70% mais barato. As maiores poupanças vêm da eliminação do licenciamento da Oracle DB (o pricing enterprise por core é brutal), seguido do IaaS na UE ser ~40% mais barato que a OCI em specs equivalentes. O próprio projeto de conversão de base de dados é o maior custo único, mas amortiza-se dentro do segundo ano.

Perguntas frequentes

Ver todas as perguntas frequentes

E quanto à Oracle EU Sovereign Cloud?

A Oracle EU Sovereign Cloud (lançada em 2023, com regiões em Madrid e Frankfurt) é operada por staff da Oracle residente na UE, com separação operacional da Oracle não-UE. É uma melhoria na documentação para muitas cargas de trabalho reguladas - mas a Oracle Corporation continua a ser a proprietária legal dos dados. Para análises Schrems II que dependem da jurisdição da empresa-mãe, isto não constitui soberania total.

Podemos manter o Oracle DB e apenas abandonar o OCI?

Sim. Uma distribuição PostgreSQL compatível com Oracle mantém a compatibilidade ao nível de SQL e PL/SQL para a maioria das cargas de trabalho. Para aplicações Oracle de complexidade média, este é um caminho viável que não exige uma reescrita completa da base de dados.

Qual é a real dimensão do projeto de migração de base de dados?

Para uma base de dados Oracle típica de mid-market (50-500GB, superfície PL/SQL modesta, sem funcionalidades específicas da Oracle além do SQL padrão): 3-6 meses de execução paralela, 2-4 semanas para o cutover em si. Para uma aplicação fortemente dependente de PL/SQL ou de funcionalidades Oracle: 9-18 meses. O dimensionamento honesto é melhor feito por quem já o fez antes.

E quanto ao Oracle Fusion Apps e ao Oracle ERP Cloud?

Isto é SaaS, não infraestrutura - a mesma conversa que Microsoft 365 ou Salesforce. A decisão de sair deles é estratégica, não de infraestrutura. Focamo-nos na camada de infraestrutura OCI; a migração de SaaS é tipicamente um projeto separado conduzido por uma consultoria de sistemas de negócio.

A OCI é realmente competitiva em preço?

Os preços de destaque do IaaS da OCI são competitivos face a AWS/Azure/GCP. Onde a OCI se torna cara é no licenciamento de base de dados na cloud (os custos do Oracle DB BYOL são elevados). Para compute puro, a stack soberana da UE continua a ser 30-40% mais barata. Para workloads Oracle DB, a comparação é dominada pela licença, não pelo compute.

Quanto tempo demora uma saída do Oracle de ponta a ponta?

Apenas para infraestrutura (sem migração de base de dados): 8-14 semanas. Para saída completa incluindo migração para PostgreSQL: 6-18 meses de tempo decorrido, dependendo da complexidade da base de dados. O risco de cronograma está inteiramente do lado da base de dados.

Planeie a sua saída de Oracle Cloud (OCI).

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