केवल यूरोपीय विकल्प Oracle Cloud (OCI).

Oracle Cloud Infrastructure EU mid-market में major hyperscalers में सबसे छोटा है लेकिन Oracle Database lock-in के कारण regulated industries में अपने आकार से बड़ी भूमिका निभाता है। Oracle Corporation एक US company है; OCI EU regions (Frankfurt, Amsterdam, Marseille, Milan, Madrid, Stockholm, Zurich) EU में स्थित हैं लेकिन CLOUD Act के तहत US-controlled हैं। Oracle 2023 से "EU Sovereign Cloud" का मार्केटिंग कर रहा है - operationally separated EU regions जिनमें EU-resident staff हैं - लेकिन parent jurisdiction अपरिवर्तित है। Schrems II-strict analyses के लिए, यह पूर्ण sovereignty नहीं है।

United States केवल-EU रिप्लेसमेंट स्टैक 12 services मैप किए गए
प्रदाता
Oracle Cloud (OCI)
मुख्यालय
Austin, TX
न्यायाधिकार
United States
विधिक शासन
CLOUD Act, FISA 702, EO 12333

"EU क्षेत्र" संप्रभुता नहीं है। चार प्रश्न इसे तय करते हैं।

डेटा रेजिडेंसी आपको बताती है कि बिट्स कहाँ स्थित हैं। सॉवरेनिटी आपको बताती है कि कौन-सी लीगल सिस्टम एक्सेस के लिए मजबूर कर सकती है। जवाब चारों पर सही होना चाहिए - नहीं तो स्टैक सॉवरेन नहीं है।

रेजीडेंसी

डेटा भौतिक रूप से कहाँ संग्रहीत है?

"cloud में" नहीं - बल्कि कौन सा datacenter, किस देश में, किस jurisdiction के अंतर्गत।

सबप्रोसेसर

आपके डेटा पथ में और कौन है?

हर विक्रेता जो डेटा को छूता है: CDN, ईमेल रिले, त्रुटि ट्रैकर, एनालिटिक्स पाइप।

न्यायाधिकार

किसके कानून प्रकटीकरण के लिए मजबूर कर सकते हैं?

US-headquartered प्रोवाइडर FISA 702 और CLOUD Act के अंतर्गत आता है - भले ही डेटा Frankfurt में हो।

कुंजी अभिरक्षा

वास्तव में एन्क्रिप्शन कुंजियाँ कौन रखता है?

अगर cloud provider के पास data और keys दोनों हैं, तो data उनके द्वारा पढ़ा जा सकता है - किसी भी DPA के बावजूद।

Fails AWS · Azure · GCP · EU रीजन

न्यायाधिकार और कुंजी अभिरक्षा पर असफल।

EU डेटा, अमेरिकी मुख्यालय वाली मूल कंपनी, डिफ़ॉल्ट पथ में अमेरिकी सबप्रोसेसर, प्रदाता-प्रबंधित कुंजियाँ।

पास होता है Binadit प्रबंधित स्टैक

सभी चारों पर सफल।

EU में होस्टेड EU मुख्यालय वाले बुनियादी ढांचे पर। डिफ़ॉल्ट पथ में शून्य अमेरिकी सबप्रोसेसर। ग्राहक-धारित या EU-KMS कुंजियाँ। आपके अनुच्छेद 28 DPA में नाम से सूचीबद्ध।

टीमें क्यों बाहर निकल रही हैं Oracle Cloud (OCI)

हमने जो Oracle exits किए हैं उनमें लगभग हमेशा infrastructure के अलावा एक database migration भी शामिल रहा है - typically Oracle DB → PostgreSQL, जो अपने आप में एक substantial project है। triggers: DORA के तहत एक financial services audit जो Oracle को US-jurisdictional concentration risk के रूप में flag करता है, एक cost review जिसने cloud पर वास्तविक Oracle DB licensing exposure उजागर किया, या Oracle dependency को पूरी तरह हटाने का एक strategic decision। जब OCI infrastructure cost और Oracle DB licence cost दोनों समाप्त हो जाते हैं तो mid-term saving नाटकीय होती है।

Oracle Cloud (OCI) सेवाएँ और उनके केवल-EU समकक्ष

माइग्रेशन "एक बॉक्स को दूसरे से बदलना" नहीं है। नीचे दी गई मैपिंग वह है जो हम निम्न को छोड़ने वाले ग्राहकों के लिए चलाते हैं: Oracle Cloud (OCI) Schrems II आधार पर - पूरी EU jurisdiction, data path में कोई US parent नहीं।

Compute Instances

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Debian या Ubuntu पर KVM virtual machines, Terraform से provision और Ansible से configure किए गए।
इंजीनियरिंग टिप्पणी
स्टैंडर्ड VM माइग्रेशन; image rebuild और rebase। Oracle Linux को बिना application पर असर डाले Rocky या Alma से बदला जा सकता है।

Object Storage

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. MinIO या Ceph RGW, S3-compatible।
इंजीनियरिंग टिप्पणी
OCI Object Storage में एक non-S3-compatible API है; रीराइट छोटा है लेकिन इसमें SDK बदलाव आवश्यक हैं।

Autonomous Database

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. failover के लिए Patroni के साथ PostgreSQL या MySQL, और point-in-time recovery के लिए pgBackRest.
इंजीनियरिंग टिप्पणी
सबसे लंबा सिंगल माइग्रेशन टास्क। ora2pg और Cybertec के migrator जैसे टूल्स में काफी सुधार हुआ है। schema की जटिलता के अनुसार 3-9 महीने की parallel run की योजना बनाएं।

OKE (Oracle Kubernetes Engine)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Debian या Talos पर Kubernetes, Cilium networking और certificates के लिए cert-manager के साथ।
इंजीनियरिंग टिप्पणी
Helm charts और YAML आसानी से transfer हो जाते हैं; OKE-specific features (Container Engine for Kubernetes managed nodepools) को standard equivalents से replace किया जाता है।

Block Volumes

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Ceph RBD, या Kubernetes-native volumes के लिए Longhorn।
इंजीनियरिंग टिप्पणी
snapshot + restore के जरिए volume migration।

Virtual Cloud Network (VCN)

इसके बजाय हम क्या चलाते हैं
Binadit Private Infrastructure. site-to-site और operator access के लिए WireGuard के साथ isolated VLANs.
इंजीनियरिंग टिप्पणी
OCI VCN concepts (subnets, route tables, NAT gateways) सीधे standard cloud networking पर मैप होते हैं।

Functions (FaaS)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. आपके Kubernetes cluster पर Knative या OpenFaaS।
इंजीनियरिंग टिप्पणी
Migration mechanical है; OCI Functions, Fn Project पर built है इसलिए runtime model portable है।

Streaming (Kafka-compatible)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Apache Kafka या Redpanda, जो Kafka-protocol के अनुकूल है।
इंजीनियरिंग टिप्पणी
Kafka migration एक producer/consumer redirect है; data replication MirrorMaker के ज़रिए होती है।

API Gateway

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Traefik या Kong, edge पर rate limiting और OIDC के साथ.
इंजीनियरिंग टिप्पणी
KrakenD का headquarter Spain में है और यह एक मज़बूत sovereign choice है।

Load Balancer

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. HAProxy या Nginx, failover के लिए keepalived के साथ।
इंजीनियरिंग टिप्पणी
स्टैंडर्ड L4/L7 load balancing।

Vault (KMS)

इसके बजाय हम क्या चलाते हैं
Binadit Private Infrastructure. Key management के लिए Vault Transit, जहां compliance regime की जरूरत हो वहां HSM-backed keys के साथ।
इंजीनियरिंग टिप्पणी
Vault production-grade sovereign जवाब है।

Logging / Monitoring

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Prometheus, Grafana, Loki और Tempo, OpenTelemetry के साथ जुड़े हुए.
इंजीनियरिंग टिप्पणी
OpenTelemetry instrumentation application-side migration को मैकेनिकल बना देता है।

हम कैसे माइग्रेट करते हैं Oracle Cloud (OCI)

एक सामान्य mid-market माइग्रेशन तीन फेज़ में चलता है। नीचे दिए गए आंकड़े 6-10 लोगों की इंजीनियरिंग टीम और मध्यम रूप से कॉम्प्लेक्स एप्लिकेशन स्टैक को मानकर दिए गए हैं।

  1. हफ्ते 1-4

    Database scope decision

    इस्तेमाल में हर Oracle DB-specific feature (PL/SQL, Oracle Text, partitioning, materialized views, hierarchical queries, Oracle Spatial) को मैप करें। निर्णय बिंदु: PostgreSQL में पूर्ण माइग्रेशन या hybrid (compatibility-critical workloads को Oracle-compatible PostgreSQL distribution पर)। यही task schedule को तय करता है।

  2. सप्ताह 4-10

    Infrastructure migration

    Compute, networking, storage को EU sovereign stack में move किया गया। K8s workloads move किए गए। Object storage को जहां ज़रूरी हो वहां API rewrites के साथ migrate किया गया। CI/CD को repoint किया गया।

  3. सप्ताह 8-24

    Database cutover

    Schema को ora2pg से convert किया गया। Live workloads के लिए logical replication या change-data-capture के जरिए data माइग्रेट किया गया। Application code को Oracle-specific SQL के लिए रिव्यू किया गया। पूरी rollback plan के साथ cutover window शेड्यूल किया गया।

पूर्ण Oracle exits (infrastructure + database) का 5-वर्षीय TCO: आमतौर पर 50-70% सस्ता। सबसे बड़ी बचत Oracle DB licensing को समाप्त करने से आती है (per-core enterprise pricing बेहद महंगी है), इसके बाद EU IaaS का equivalent specs पर OCI की तुलना में ~40% सस्ता होना। database conversion project स्वयं सबसे बड़ी one-time cost है लेकिन इसका payback दूसरे वर्ष के भीतर हो जाता है।

अक्सर पूछे जाने वाले प्रश्न

सभी अक्सर पूछे जाने वाले प्रश्न देखें

Oracle EU Sovereign Cloud के बारे में क्या?
Oracle EU Sovereign Cloud (2023 में लॉन्च, मैड्रिड और फ्रैंकफर्ट में regions) EU-निवासी Oracle staff द्वारा non-EU Oracle से operational separation के साथ operate किया जाता है। कई regulated workloads के लिए documentation story में यह एक सुधार है - लेकिन data का legal owner अब भी Oracle Corporation ही है। parent jurisdiction पर निर्भर Schrems II analyses के लिए, यह पूर्ण sovereignty नहीं है।
क्या हम Oracle DB रख सकते हैं और सिर्फ OCI छोड़ सकते हैं?
हाँ। एक Oracle-compatible PostgreSQL distribution अधिकतर workloads के लिए SQL और PL/SQL level पर compatibility बनाए रखता है। mid-complexity Oracle applications के लिए यह एक viable रास्ता है जिसमें पूरे database को फिर से लिखने की जरूरत नहीं पड़ती।
डेटाबेस माइग्रेशन प्रोजेक्ट वास्तव में कितना बड़ा है?
एक सामान्य mid-market Oracle DB (50-500GB, मामूली PL/SQL surface, standard SQL से आगे कोई Oracle-specific features नहीं) के लिए: 3-6 महीने parallel-run, और cutover के लिए ही 2-4 हफ्ते। भारी PL/SQL या Oracle-feature-dependent application के लिए: 9-18 महीने। ईमानदार scoping उन्हीं लोगों द्वारा सबसे अच्छी होती है जिन्होंने यह पहले किया हो।
Oracle Fusion Apps और Oracle ERP Cloud के बारे में क्या?
ये SaaS हैं, इंफ्रास्ट्रक्चर नहीं - Microsoft 365 या Salesforce जैसी ही बातचीत। इनसे हटने का फैसला रणनीतिक है, इंफ्रास्ट्रक्चरल नहीं। हम OCI इंफ्रास्ट्रक्चर लेयर पर फोकस करते हैं; SaaS माइग्रेशन आमतौर पर एक अलग प्रोजेक्ट होता है जिसे बिज़नेस-सिस्टम्स कंसल्टेंसी चलाती है।
क्या OCI वाकई pricing पर competitive है?
OCI की headline IaaS pricing AWS/Azure/GCP की तुलना में competitive है। OCI जहां महंगा हो जाता है वह है cloud पर database licensing (Oracle DB BYOL costs अधिक हैं)। शुद्ध compute के लिए, EU sovereign stack अभी भी 30-40% सस्ता है। Oracle DB workloads के लिए, तुलना licence द्वारा dominate होती है, न कि compute द्वारा।
Oracle एग्ज़िट एंड-टू-एंड में कितना समय लगता है?
सिर्फ infrastructure के लिए (कोई DB migration नहीं): 8-14 हफ्ते। PostgreSQL migration सहित पूर्ण exit के लिए: database की जटिलता के अनुसार 6-18 महीने का समय लगता है। शेड्यूल का जोखिम पूरी तरह database की तरफ है।

अपनी निकास योजना बनाएँ Oracle Cloud (OCI).

30-मिनट का स्कोपिंग कॉल। हम आपके स्टैक को केवल-EU विकल्पों के विरुद्ध मैप करते हैं, माइग्रेशन प्रयास का अनुमान लगाते हैं, और आपको बताते हैं कि क्या यह सही निर्णय है।