Alternativa apenas UE a Oracle Cloud (OCI).
Oracle Cloud Infrastructure is the smallest of the major hyperscalers in EU mid-market but punches above its weight in regulated industries because of the Oracle Database lock-in. Oracle Corporation is a US company; OCI EU regions (Frankfurt, Amsterdam, Marseille, Milan, Madrid, Stockholm, Zurich) are EU-located but US-controlled under the CLOUD Act. Oracle has marketed "EU Sovereign Cloud" since 2023 - operationally separated EU regions with EU-resident staff - but the parent jurisdiction is unchanged. For Schrems II-strict analyses, that is not full sovereignty.
- Fornecedor
- Oracle Cloud (OCI)
- Sede
- Austin, TX
- Jurisdição
- United States
- 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.
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.
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)
Oracle exits we have run almost always involve a database migration in addition to infrastructure - typically Oracle DB → PostgreSQL, which is a substantial project on its own. The triggers: a financial services audit under DORA flagging Oracle as a US-jurisdictional concentration risk, a cost review that uncovered the true Oracle DB licensing exposure on cloud, or a strategic decision to remove the Oracle dependency entirely. The mid-term saving is dramatic when both the OCI infrastructure cost and the Oracle DB licence cost are eliminated.
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.
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.
-
Weeks 1-4
Database scope decision
Map every Oracle DB-specific feature in use (PL/SQL, Oracle Text, partitioning, materialized views, hierarchical queries, Oracle Spatial). Decision point: full migration to PostgreSQL or hybrid (compatibility-critical workloads on an Oracle-compatible PostgreSQL distribution). This is the schedule-defining task.
-
Weeks 4-10
Infrastructure migration
Compute, networking, storage moved to EU sovereign stack. K8s workloads moved. Object storage migrated with API rewrites where needed. CI/CD repointed.
-
Weeks 8-24
Database cutover
Schema converted with ora2pg. Data migrated with logical replication or change-data-capture for live workloads. Application code reviewed for Oracle-specific SQL. Cutover window scheduled with full rollback plan.
5-year TCO on full Oracle exits (infrastructure + database): typically 50-70% cheaper. The largest savings come from eliminating Oracle DB licensing (per-core enterprise pricing is brutal) followed by EU IaaS being ~40% cheaper than OCI on equivalent specs. The database conversion project itself is the largest one-time cost but pays back inside year 2.
Perguntas frequentes
What about Oracle EU Sovereign Cloud?
Can we keep Oracle DB and just leave OCI?
How big is the database migration project really?
What about Oracle Fusion Apps and Oracle ERP Cloud?
Is OCI actually competitive on pricing?
How long does an Oracle exit take end-to-end?
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.