تسارع استراتيجية أوراكل متعددة السحابات: الإتاحة العامة (GA) للربط البيني عبر السحابات، وقاعدة بيانات Exascale، والتوسع الإقليمي، والآثار الصناعية

تسارع استراتيجية Oracle متعددة السحابات: الدلالات الصناعية للترابط العابر للسحابات GA، وقواعد بيانات Exascale، والتوسع الإقليمي

مقدمة

من مايو إلى أغسطس 2026، كشفت Oracle تباعًا على مدونتها الرسمية متعددة السحابات عن سلسلة من التطورات: تحوّل Oracle Interconnect for AWS من التوفر المحدود إلى التوفر العام (GA)، وأدخل كل من Oracle AI Database@AWS وOracle AI Database@Google Cloud، على التوالي، البنية التحتية Exascale وقدرات تخزين Exadata Exascale، مع توسّع التغطية الإقليمية إلى 22 منطقة عالميًا. قد تبدو هذه التحديثات متفرقة، لكنها تشير في الواقع إلى القضية نفسها: عندما تتوزع أحمال عمل المؤسسات بطبيعتها عبر سحابات متعددة، فهل يمكن لأصول قواعد البيانات التي تُعدّ الأصعب في الترحيل أن تعمل عبر السحابات دون إعادة هيكلة التطبيقات؟ بالنسبة لمديري التكنولوجيا (CTO) ومهندسي السحابات، يتصل هذا مباشرةً بهيكل تكاليف الشبكات العابرة للسحابات، وأنماط نشر قواعد البيانات، ومسارات تحقيق إقامة البيانات واستمرارية الأعمال.

أولًا: خلفية الأحداث: دفعة مكثفة على مدى ثلاثة أشهر

لا تبدو الفكرة الجوهرية لـ Oracle متعددة السحابات معقدة: تشغيل خدمات Oracle Database على بنية OCI التحتية المنشورة بالقرب من مناطق سحابية أخرى، وتقديمها إلى العملاء عبر سلسلة أدوات مألوفة وفوترة موحّدة. وتمثل إعلانات صيف 2026 هذه توسّعًا متزامنًا لهذه الفكرة على بُعدي القدرات والجغرافيا.| التاريخ | الحدث | النقاط الرئيسية | | --- | --- | --- | | 15 مايو | Oracle Interconnect for AWS متاح بشكل محدود | أعلن عنه ناثان توماس، نائب الرئيس الأول لإدارة المنتجات في OCI، والهدف هو استبدال الشبكات متعددة السحابات التي يبنيها العملاء بأنفسهم باتصال مُدار | | 20 مايو | OCI GoldenGate متاح عمومًا (GA) على Oracle AI Database@Google Cloud | يمكن تفعيله مباشرة من وحدة تحكم Google Cloud، والدفع باستخدام التزامات Google Cloud | | 20 مايو | Oracle AI Database@AWS يتوفر في ساو باولو | يغطي سوق أمريكا الجنوبية، مع منطقة توفر واحدة مبدئيًا | | 17 يونيو | Oracle AI Database@AWS يبلغ عامه الأول | الإعلان عن التوفر العام (GA) لـ Autonomous AI Database Serverless، والبنية التحتية Exascale على وشك الإطلاق، والتوسع إلى 20 منطقة AWS، وطبقة MAA Platinum، واتفاقية تعاون استراتيجي طويلة الأجل (SCA) | | 23 يونيو | إضافة ستوكهولم وسان خوسيه | يبلغ إجمالي المناطق العالمية 22 | | 29 يوليو | Oracle Interconnect for AWS متاح رسميًا | الإطلاق الأولي في OCI Ashburn وAWS شرق الولايات المتحدة (شمال فرجينيا)، مع طرح المزيد من أزواج المناطق لاحقًا | | 12 أغسطس | ExaDB-XS متاح على Oracle AI Database@AWS | الفوترة وفقًا لـ ECPU واستخدام التخزين، ما يخفض تكلفة البدء، ويُباع عبر AWS Marketplace | | 14 أغسطس | Exadata Exascale يدخل Oracle AI Database@Google Cloud | يمكن للعملاء توفير مجموعات Exadata VM مع تخزين Exascale |

من الجدير بالملاحظة أن إفصاحات هذه الجولة تركزت على طرفي AWS وGoogle Cloud. وتيرة الارتباط العميق أولًا ببعض مزوّدي السحابة فائقي الحجم تشير إلى أن استراتيجية Oracle متعددة السحابات أقرب إلى تكرار القدرات لا إلى التوسع الشامل.

ثانيًا، التحليل التقني: ما المشكلة التي يحلّها كل من الأمور الثلاثة؟

1. الربط البيني بين السحابات: تحويل الشبكة من مشروع إلى خدمةفي المراحل الأولى من الحوسبة متعددة السحابات، كانت هناك طريقتان رئيسيتان لربط سحابتين: تمرير حركة المرور عبر الإنترنت العام، أو بناء نفق مشفّر خاص. فالأولى تنطوي على سطح تعرّض واضح في الأمان والتوافر والسعة؛ أما الثانية، فرغم أنها تستبعد الإنترنت العام، فإنها تُحمّل العميل كامل عبء الشراء والتهيئة وإدارة السعة. وعلى أرض الواقع، يتعيّن على المؤسسات أيضًا التنسيق في الوقت نفسه بين نموذجي توجيه غير مصمّمين لبعضهما البعض، وإدارة العقود مع أطراف ثالثة على الجانبين، وبناء شبكة خاصة بها قبل أن تبدأ أعمالها فعليًا.

وOracle Interconnect for AWS يحاول تغيير هذه الطبقة تحديدًا. فهو يوفّر اتصالًا خاصًا وعالي السرعة ومُدارًا بالكامل بين OCI وAWS، ويستخدم افتراضيًا تشفير IEEE 802.1AE MACsec، ويعتمد تسعيرًا موحّدًا وعالميًا للاتصال من OCI، دون أي رسوم على نقل البيانات، وبدعم مشترك من Oracle وAWS. وبعبارة غير تقنية: هذا أشبه ببناء طريق سريع مخصّص بين مجمّعين، تديره الشركتان معًا، بحيث لم تعد المؤسسة بحاجة إلى رصف الطريق بنفسها، أو شراء الأرض بنفسها، أو صيانة سطح الطريق بنفسها.

2. Exascale: فصل الحوسبة عن التخزين وخفض حاجز الدخول إلى Exadata

كانت Exadata التقليدية أشبه بجهاز متكامل: تتوسّع الحوسبة والتخزين معًا بنسبة ثابتة، وإذا جانبت تخطيط السعة الصواب، فإما أن تهدر الموارد أو أن تقع تحت قيود. أما التغيير الجوهري في Exascale فهو فصل الاثنين.

وعلى جانب AWS، يستند ExaDB-XS إلى نموذج السحابة المرنة متعددة المستأجرين من Oracle، إذ يمكن للعملاء البدء بمجموعة VM صغيرة الحجم، وتوسيع الحوسبة والتخزين بشكل مستقل، والدفع مقابل ECPU والتخزين المستخدمين فعليًا فقط، مع دعم Oracle Database 19c وOracle AI Database 26ai، وتوفير إمكانات thin clone واللقطات والاستنساخ القائمة على redirect-on-write. وعلى جانب Google Cloud، يمكن للعملاء تفعيل مجموعات Exadata VM المزوّدة بتخزين Exascale، وتوسيع التخزين بمرونة مع نمو متطلبات قاعدة البيانات، مع الحفاظ على سمات الأداء والتوافر والموثوقية الخاصة بـ Exadata المخصّصة.

وبالنسبة للمديرين، فإن جوهر هذا التغيير هو تحوّل في منطق الشراء: من شراء السعة كاملة دفعة واحدة إلى الدفع حسب الطلب والتوسّع وفق النمو، مع انتقال جزء أكبر من طبيعة النفقات الرأسمالية إلى النفقات التشغيلية.

3. OCI GoldenGate: مستوى البيانات في سياقات السحابات المتعددةتشغيل قواعد البيانات عبر السحابات لا يمكن أن يخلو من مزامنة البيانات. بعد أن أصبح OCI GoldenGate متاحًا رسميًا على Google Cloud، يمكن للعملاء تفعيل هذه الخدمة المُدارة مباشرةً من وحدة تحكم Google Cloud، والدفع من خلال التزام Google Cloud. وهو يوفر التقاط تغييرات البيانات (CDC) منخفض الكمون والنسخ في الوقت الفعلي، مما يدعم ترحيل قواعد البيانات منخفض المخاطر، والبنى الهجينة ومتعددة السحابات، وتحسين التوافر، والتحليلات شبه الفورية عبر مصادر بيانات Oracle وغير Oracle.

يمكن فهم CDC على أنه سجل تغييرات متجدد باستمرار: يتم التقاط كل تغيير في بيانات قاعدة المصدر ومزامنته إلى الوجهة، بدلاً من انتظار نافذة المعالجة الدفعية لنقلها دفعة واحدة. وهذا يتيح للعمليات والتحليلات وأحمال الذكاء الاصطناعي أن تُبنى على بيانات تُزامن باستمرار.

ثالثًا: تحليل تأثير المؤسسة

هيكل التكلفة. ExaDB-XS يُحاسب وفق ECPU واستخدام التخزين، مما يقلل مباشرة من عتبة تجربة Exadata والبدء بها؛ والتوسع المستقل لـ Exascale يقلل من هدر حجز السعة للذروة. يعتمد Interconnect تسعيرًا موحدًا للاتصال ولا يتقاضى رسومًا على نقل البيانات، مما يجعل نفقات الشبكة عبر السحابات أقرب إلى بند ثابت يمكن التنبؤ به. وتجدر الإشارة إلى أن التكلفة الإجمالية عبر السحابات لا تزال بحاجة إلى تقدير شامل يجمع قواعد الفوترة على الطرفين، والشبكة ليست سوى حلقة واحدة منها.

نمط النشر. بالنسبة لعملاء Oracle الذين يشغلون تطبيقاتهم بالفعل على AWS، فإن عدم إعادة الهيكلة هو نقطة البيع الأساسية في هذه التحديثات: تعمل خدمات قواعد البيانات على بنية OCI التحتية، ولكن يتم نشرها بالقرب من تطبيقات AWS. الترحيل على مراحل، وبنية التطبيقات الموزعة، وتقليل الاعتماد على الشبكة العامة، كلها سيناريوهات قابلة للتنفيذ مباشرة.

العمليات والدعم. توحيد الفواتير، والاستمرار في استخدام سلسلة الأدوات الحالية، وواجهات الدعم المنسقة بين Oracle و AWS، تقلل من الاحتكاك التنظيمي للفرق العاملة عبر السحابات. لكن تعقيد العمليات متعددة السحابات لن يختفي بسبب ذلك، بل ينتقل فقط من الشبكات المُنشأة ذاتيًا وإدارة العقود إلى الهوية الفيدرالية والمراقبة وتحديد الأعطال.

الأمن والامتثال. تشفير MACsec الافتراضي والروابط الخاصة يقللان من سطح التعرض للشبكة العامة. أما التوسع الإقليمي فهو استجابة مباشرة لقضايا الامتثال: ستوكهولم تخدم متطلبات إقامة البيانات في دول الشمال وأوروبا، وسان خوسيه تقترب من التجمعات التقنية والتجارية في غرب الولايات المتحدة، وساو باولو تغطي سوق أمريكا الجنوبية. وبالنسبة للقطاعات الخاضعة للتنظيم، غالبًا ما يكون اختيار المنطقة بهذا الشكل أكثر وزنًا في القرار من مؤشرات الأداء.

رابعًا: تحليل المنافسة في السوقمن منظور المشهد التنافسي، السمة الأبرز في هذه الدفعة من التحديثات هي المنافسة القائمة على التمايز. لم تدخل Oracle في منافسة مباشرة مع مزودي السحابة فائقي الحجم على القدرة الحاسوبية العامة في طبقة IaaS، بل تعاملت مع قاعدة البيانات كمنتج يُسلَّم عبر السحابات، بما يتيح لـ AWS وGoogle Cloud كسب مزيد من أحمال العمل، بينما تكسب هي من استهلاك قواعد البيانات. وهذا أقرب إلى تحالف تكميلي: فقد رسّخت اتفاقية التعاون الاستراتيجي طويلة الأجل (SCA) التي أعلنها الطرفان في 17 يونيو هذه العلاقة أكثر. وقد أفصحت الشركة رسميًا أن Oracle AI Database@AWS، بعد عام من إطلاقه، أصبح مئات العملاء يشغّلون عليه أحمال أعمال حيوية.

من الأطراف التي قد تستفيد: عملاء المؤسسات الذين يمتلكون أصولًا كبيرة من قواعد بيانات Oracle، لكنهم يرغبون في إبقاء تطبيقاتهم على سحابات أخرى؛ وAWS وGoogle Cloud، لأنهما يستضيفان مزيدًا من قواعد البيانات المؤسسية وأحمال عمل الذكاء الاصطناعي؛ والقنوات والمكاملون الذين يعملون حول AWS Marketplace وميزانيات الالتزام في Google Cloud.

ومن الأطراف التي قد تتعرض لضغوط: مقدمو الخدمات من الأطراف الثالثة الذين يتمحور نشاطهم الأساسي حول بناء خطوط خاصة عابرة للسحابات والاستضافة الشبكية، حيث تضعف قيمة عرضهم بسبب الاتصال المُدار والتسعير الموحّد؛ والسردية القائلة بضرورة إعادة كتابة قواعد بيانات الأعمال بالكامل لتصبح قواعد بيانات سحابية أصلية——فدعم Exascale وإصداري 19c/26ai يتيح لمزيد من المؤسسات اختيار مسار تدريجي يقوم على الترحيل أولًا ثم التحديث لاحقًا. وبالمقابل، سترتفع مقاومة الاستبدال التي تواجهها شركات قواعد البيانات السحابية الأصلية عندما تسعى إلى انتزاع أحمال عمل Oracle القائمة.

خامسًا: مراقبة اتجاهات القطاع

ينتقل محور المنافسة في السحابة المتعددة من الاتصال إلى طبقة البيانات. على مدى السنوات القليلة الماضية، كان التحدي الهندسي في السحابة المتعددة يتمثل أساسًا في التشغيل البيني للشبكات؛ غير أن قدرات مثل Exascale وGoldenGate والبحث المتجهي الأصلي بالذكاء الاصطناعي تشير إلى أن المنافسة في المرحلة التالية تدور حول كيفية تدفق البيانات عبر السحابات وكيفية استخدام الذكاء الاصطناعي لها.

ينعكس اتجاه جاذبية البيانات. كان النهج التقليدي نقل التطبيقات إلى جوار البيانات، أما الآن فيُتبع نهج نقل خدمات قواعد البيانات إلى جوار التطبيقات——إذ تعمل قاعدة البيانات على البنية التحتية لـ OCI، لكنها تُنشر في موقع قريب من مناطق AWS أو Google Cloud. وقد يصبح نمط «السحابة داخل السحابة» هذا مسار الترحيل الافتراضي للأنظمة القديمة على مستوى المؤسسات.

تتحول السيادة والتوطين الإقليمي إلى سمات في المنتج. يوضح الإطلاق المتتابع في ستوكهولم وساو باولو وسان خوسيه أن التغطية الإقليمية لم تعد مجرد تحسين لزمن الاستجابة، بل أصبحت بنية تحتية للامتثال تتعلق بإقامة البيانات واستمرارية الأعمال.

تستمر الحدود بين الذكاء الاصطناعي وقواعد البيانات في التلاشي. من تسمية المنتجات إلى مجموعة القدرات (Autonomous AI Lakehouse، والبحث المتجهي الأصلي بالذكاء الاصطناعي، وإصدار 26ai)، تدمج Oracle قدرات الذكاء الاصطناعي داخل طبقة قواعد البيانات، بدلًا من أن تبني المؤسسات خارج قاعدة البيانات مجموعة منفصلة للبحث المتجهي ومنصة للميزات.تشير هذه التغييرات مجتمعة إلى استنتاج واحد: أصبحت السحابة المتعددة تتحول من خيار في بنية الشبكة إلى خيار في بنية البيانات، وستتمحور المنافسة في البنية التحتية السحابية خلال السنوات الخمس المقبلة أكثر حول قابلية نقل خدمات البيانات.

CloudTechDaily Insight

أبرز ما يستحق التسجيل في هذه الدفعة من الإعلانات ليس ميزة بعينها، بل أن وحدة التسعير في المنافسة على السحابة المتعددة تتغير. في الماضي، كانت المؤسسات تقيّم السحابة المتعددة بالنظر إلى عرض النطاق للخطوط المخصصة وحركة الخروج والموارد البشرية للتشغيل والصيانة؛ أما الآن، فقد أصبحت المطروحة على الطاولة هي التكلفة الأولية لقاعدة البيانات (الفوترة حسب ECPU والتخزين)، وطريقة تسعير الاتصال عبر السحابات (تسعير موحد للاتصال، دون رسوم نقل بيانات)، وما إذا كان يمكن استهلاك البيانات بالذكاء الاصطناعي في موقعها. وعندما تتحول هذه العناصر إلى منتجات، تتحول قرارات السحابة المتعددة من مسألة جدوى تقنية إلى مسألة قابلة للحساب ماليًا وتنظيميًا.

على مستوى استراتيجية تقنية المعلومات للمؤسسات، هناك ثلاث نقاط تستحق الإدراج في التقييم. أولًا، لم تعد قاعدة البيانات العابرة للسحابات نقطة نهاية لمشروع ترحيل، بل يمكن أن تصبح حالة تشغيل طويلة الأمد، ويتعين تعديل معايير مراجعة البنية وفقًا لذلك. ثانيًا، بعد تحول طبقة الاتصال إلى خدمة مُدارة، تزداد قابلية التنبؤ بتكلفة العمل عبر السحابات، لكن التبعية تتعمق أيضًا — إذ يحتاج العملاء إلى تقييم درجة اعتمادهم على علاقة تعاون طويلة الأمد بين اثنين من المزوّدين وعلى عمليات الدعم المشترك. ثالثًا، لا يجلب التوسع الإقليمي سوى خيارات امتثال لا مكاسب أداء محضة، وينبغي للقطاعات المنظّمة إدراج قائمة المناطق في تخطيط إقامة البيانات والاستمرارية.

يجب الاعتراف بأن هذا النموذج لا يزال يعتمد على رغبة مزوّدي السحابة فائقي الحجم في التعاون وعلى خارطة طريق منتجاتهم. تركز الكشف في هذه الجولة على AWS وGoogle Cloud، ولا تزال التغطية غير مكتملة؛ كما أن الأداء الفعلي للدعم المشترك في تحديد الأعطال وتوزيع المسؤوليات يحتاج إلى مزيد من التحقق في بيئات الإنتاج. لذا فإن النهج الأكثر عملية هو: التحقق من أداء قواعد بيانات الأعمال الحيوية وتجربة التشغيل والصيانة في بيئة متعددة السحابات عبر عنقود صغير من ExaDB-XS، واستبدال الشبكات العامة الحالية العابرة للسحابات أو الروابط المبنية ذاتيًا بتجربة Interconnect، وإكمال التدقيق المزدوج لنموذج التكلفة وإقامة البيانات قبل توسيع النطاق.

على المدى المتوسط والطويل، من المرجح أن تتحول قاعدة البيانات كخدمة عابرة للسحابات، مثلما حدث مع قواعد البيانات المُدارة في ذلك الوقت، من استثناء إلى إعداد افتراضي في القطاع. وبمجرد أن ينجز كبار مزوّدي قواعد البيانات هذه الخطوة، سيظهر سريعًا ضغط على الشركات ومزوّدي السحابة الآخرين للمواكبة — وهذا هو الأثر الأعمق لهذا الحدث على صناعة الحوسبة السحابية.

---

المصادر المرجعية: مدونة Oracle الرسمية «Oracle Multicloud – What's News»، https://blogs.oracle.com/cloud-infrastructure/oracle-multicloud-whats-new-blog