السحابة المتعددة: Azure وGCP

واقع التعدد السحابي

18 دقيقة الدرس 1 من 28

واقع التعدد السحابي

ادخل إلى أي مراجعة بنية تحتية في شركة من قائمة فورتشن-500 وستجد على الأرجح خدمات تعمل على مزودَّي سحابة على الأقل — وكثيرًا ما تكون ثلاثة. هذا ليس مصادفةً، ولا خطأً، ولا دليلًا على ضعف الحوكمة. بل هو النتيجة المتوقعة لطريقة نمو المؤسسات الكبيرة واستحواذها على الشركات وتفاوضها على العقود وإدارتها للمخاطر. فهم الأسباب الحقيقية وراء التعدد السحابي — والحدود الصعبة لفكرة "قابلية النقل السحابي" — هو الأساس الذي يحتاجه كل مهندس DevOps أول قبل أن يلمس وحدة Terraform واحدة أو شبكة VPN عابرة للسحاب.

كيف تنتهي المؤسسات فعليًا إلى التعدد السحابي

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

الاندماجات والاستحواذات. تستحوذ شركتك على ناشئة تعمل بالكامل على GCP. يتوقع مجلس الإدارة إتمام الصفقة في ستة أشهر. ترحيل 200 خدمة إلى AWS في هذه النافذة الزمنية أمر غير ممكن. المسار الواقعي هو اتصال شبكة هجينة (VPN أو Interconnect) بينما تخطط لتوحيد أطول أمدًا — غالبًا لا يكتمل أبدًا لأن الخدمات المستحوَذ عليها تُطلق مزايا جديدة أسرع من أن تحصل تذاكر الترحيل على الأولوية.
خدمات متخصصة بارزة من كل مزود. BigQuery هو محرك التحليلات الرائد في فئته. Azure Active Directory (Entra ID) هو بالفعل مزود الهوية المؤسسية لأن الشركة كانت تعتمد Microsoft قبل نقل أعباء العمل إلى AWS. Snowflake يعمل على السحابة التي اختارها فريق البيانات قبل أن يوجد فريق هندسة المنصات. كل فريق يختار الأداة الأنسب لعمله، وتمتد هذه الأدوات عبر مزودين مختلفين.
الرافعة التفاوضية. إنفاق سنوي بقيمة 20 مليون دولار على السحابة يمنحك قوة تفاوضية حقيقية — لكن فقط إذا آمن المزود بأنك قادر على الانتقال. الإبقاء على حمل عمل حقيقي على مزود ثانٍ، حتى لو كان صغيرًا، يُبرَّر داخليًا في كثير من الأحيان كتحوط ضد ارتفاع الأسعار والقيد على مزود واحد. فرق المالية تفهم هذه الحجة حتى حين تقاوم الفرق الهندسية العبء التشغيلي.
متطلبات تنظيمية وإقامة البيانات. بعض الولايات القضائية تشترط بقاء البيانات داخل الحدود، وليس لكل مزود منطقة محلية في كل سوق منظَّم. شركة SaaS عالمية قد تخدم عملاء الاتحاد الأوروبي من AWS eu-central-1، وعملاء اليابان من GCP asia-northeast1، وعملاء الشرق الأوسط من Azure UAE North — ليس لأن البنية أنيقة، بل لأن هذه هي الخيارات الوحيدة التي تستوفي متطلبات إقامة البيانات في كل سوق.
تنويع المخاطر عقب انقطاع كبير. انقطاع AWS في us-east-1 عام 2021، وحدث GCP متعدد المناطق عام 2022، وحادثة CrowdStrike عام 2024 — ذكَّرت جميعها المؤسسات بأن أي مزود منفرد يمكن أن يتعطل لساعات. مجالس الإدارة وكبار مسؤولي أمن المعلومات (CISO) يشترطون بشكل متزايد قدرة توثيقية على التحول لمزود ثانٍ للخدمات الحرجة، بغض النظر عن التكلفة الهندسية.

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

أسطورة قابلية النقل

كل مزود سحابي — وكل بائع Kubernetes — يروّج لفكرة أن منصته قابلة للنقل: انقل أعباء عملك إلى أي مكان. الواقع أكثر تقييدًا. قابلية النقل موجودة في طبقات مختلفة، ولكل طبقة تكلفتها الخاصة.

قابلية النقل على طبقة الحاوية (عالية، رخيصة): صورة Docker مبنية لـ linux/amd64 أو linux/arm64 تعمل بشكل متطابق على EKS وGKE وAKS. طبقة الحوسبة قابلة للنقل فعلًا. هذه هي الطبقة التي صُمِّم Kubernetes لتوحيدها.
قابلية النقل على طبقة البنية التحتية (متوسطة، مكلفة): وحدات Terraform تجرِّد واجهات برمجة المزودين خلف واجهة HCL متسقة، لكن وحدة تُنشئ AWS ALB لا تستطيع إنشاء Azure Application Gateway بتغيير متغير واحد. تحتاج إلى وحدات متوازية، وملفات حالة متوازية، وخطوط CI متوازية. تكلفة التجريد وقت هندسي حقيقي.
قابلية النقل على طبقة الخدمات المدارة (منخفضة، مكلفة جدًا): Aurora PostgreSQL ليست Postgres. Cloud Spanner ليست أي معيار مفتوح. لهجة SQL في BigQuery واستراتيجيات التقسيم والتسعير القائم على الـ slot لا مقابل لها على AWS أو Azure. في اللحظة التي يستخدم فيها تطبيقك خدمة مدارة تتجاوز Postgres الأساسية المتوافقة مع RDS، فأنت قبلت القيد على المزود في طبقة البيانات — وهذا القيد هو الأصعب في التراجع عنه.
قابلية النقل التشغيلية (الأدنى، الأصعب): فريقك يعرف CloudWatch، لا Azure Monitor. كتيبات الاستجابة لديك تشير إلى aws ec2 describe-instances، لا az vm list. العبء المعرفي حقيقي. التعدد السحابي يضاعف مساحة الأدوات التي يجب على مهندسيك متابعتها.

فخ التجريد: تحاول الفرق أحيانًا حل قابلية النقل ببناء طبقة تجريد داخلية — واجهة برمجية للمنصة تخفي AWS وGCP خلف واجهة مشتركة. يبدو هذا أنيقًا وينتهي بكارثة. ستبني أبطأ نسخة وأقلها مزايا من كل مزود سحابي، ستملك كل الثغرات، وستمنع فرقك من استخدام المزايا الأصيلة لكل مزود التي كانت ستحل مشاكلهم في يوم واحد. جرِّد على طبقة العمليات (أنماط IaC، مخططات Helm، خطوط الرصد) لا على طبقة واجهة برمجة التطبيقات.

ما تُوحِّده الشركات الكبرى فعليًا

بدلًا من مطاردة قابلية النقل الكاملة، تُوحِّد المؤسسات عالية الأداء الأمور التي تهم فعليًا عبر السحاب:

الهوية والوصول: مزود هوية واحد (Okta أو Entra ID أو Google Workspace) متحد مع الأسحبة الثلاث عبر SAML/OIDC. يسجل المهندسون دخولهم مرة واحدة؛ افتراض الأدوار خاص بكل مزود لكنه محكوم مركزيًا.
إدارة الأسرار: HashiCorp Vault (أو مقابله السحابي) كمصدر الحقيقة الوحيد للأسرار، مع أنظمة مصادقة خلفية خاصة بكل مزود. لا تُخزَّن أسرار في مديري الأسرار السحابيين بمعزل — تُدار جميعها عبر واجهة Vault البرمجية.
الرصد والمراقبة: لوحة تحكم واحدة — Datadog أو Grafana Cloud أو مجموعة Prometheus/Thanos ذاتية الاستضافة — تستوعب المقاييس والسجلات والتتبعات بغض النظر عن المزود. مقاييس CloudWatch تُصدَّر؛ مقاييس GCP Cloud Monitoring تُصدَّر. يرى المهندسون لوحة تحكم واحدة للأسطول بأكمله.
رؤية التكلفة: منصة FinOps (Apptio Cloudability أو CloudHealth أو OpenCost مفتوح المصدر) تُوحِّد الإنفاق عبر المزودين في تقرير واحد بتصنيف وسوم متسق.
الشبكات: بنية عبور محددة — عادةً AWS Transit Gateway مع GCP HA VPN أو اتصالات مخصصة — مع إدارة متسقة لعناوين IP (IPAM) لمنع تداخل CIDR عبر المزودين. تداخل CIDRs في شبكة متعددة السحاب هو من أكثر مشاكل الإنتاج إيلامًا في المعالجة.

# ── اكتشاف تداخل CIDR قبل إنشاء اتصال الإقران عبر السحاب ────────────────────
# هذا فحص ما قبل الإقلاع يُنفَّذ قبل توفير VPN أو Interconnect.

AWS_CIDR="10.10.0.0/16"
GCP_CIDR="10.10.128.0/18"   # يتداخل مع كتلة AWS أعلاه!

python3 - <<'EOF'
import ipaddress, sys
aws = ipaddress.ip_network("10.10.0.0/16")
gcp = ipaddress.ip_network("10.10.128.0/18")
if aws.overlaps(gcp):
    print(f"تداخل مكتشف: {aws} و {gcp} يشتركان في عناوين.")
    print(f"النطاق المتداخل: {list(aws.address_exclude(gcp))}")
    sys.exit(1)
else:
    print("لا تداخل — آمن للمتابعة بالإقران.")
EOF

طبقات قابلية النقل السحابي: الحاويات قابلة للنقل بشكل حقيقي؛ الخدمات المدارة والعمليات تشكل القيد الأعمق.

إطار قرار عملي: متى تتجه إلى التعدد السحابي

قبل إضافة مزود سحابي ثانٍ، أجرِ هذا الفحص بصدق. كل "لا" يزيد الدين التشغيلي الذي ستتحمله:

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

# ── تدقيق سريع: اكتشاف موارد السحابة التي تعمل بالفعل ─────────────────────────
# نفِّذ هذا في shell مُهيَّأ بـ AWS وGCP وAzure CLI.

echo "=== AWS: خوادم EC2 النشطة لكل منطقة ==="
aws ec2 describe-regions --query 'Regions[].RegionName' --output text | \
  tr '\t' '\n' | while read region; do
    count=$(aws ec2 describe-instances --region "$region" \
      --filters Name=instance-state-name,Values=running \
      --query 'length(Reservations[].Instances[])' --output text 2>/dev/null)
    [ "$count" -gt 0 ] 2>/dev/null && echo "  $region: $count instances"
  done

echo ""
echo "=== GCP: Compute instances per zone ==="
gcloud compute instances list --format="table(zone,name,status)" \
  --filter="status=RUNNING" 2>/dev/null | head -20

echo ""
echo "=== Azure: VMs per resource group ==="
az vm list --show-details \
  --query "[?powerState=='VM running'].[resourceGroup,name,location]" \
  --output table 2>/dev/null | head -20

ابدأ بالرصد لا بالحوسبة: قبل كتابة وحدة Terraform واحدة عابرة للسحاب، ادمج البيئتين في مساحة Grafana أو Datadog واحدة. لا تستطيع تشغيل ما لا تراه. مهندسون في Spotify وNetflix وShopify يُجمعون على أن الرصد الموحَّد هو الخطوة الأولى الأعلى عائدًا في أي مبادرة للتعدد السحابي — يكشف أنماط الحركة الحقيقية وأوضاع الفشل ومحركات التكلفة التي يجب أن تُعلم كل قرار معماري لاحق.

الواقع الصادق للتعدد السحابي في 2025

بعد سنوات من ضجيج التعدد السحابي، استقر الصناعة على توافق عملي: التعدد السحابي النشط-النشط لأعباء عمل عشوائية غير مجدٍ اقتصاديًا لغالبية المؤسسات. ما يعمل على نطاق واسع هو نموذج طبقي:

الطبقة الأولى (السحابة الأساسية — 80-90% من الإنفاق): AWS أو GCP كمنصة أساسية. تكاملات أصيلة عميقة وخدمات مدارة وخبرة خاصة بالمزود. هنا يعمل منتجك.
الطبقة الثانية (السحابة الثانوية — 10-20% من الإنفاق): مزود ثانٍ لأعباء عمل محددة ومبررة — BigQuery للتحليلات، وEntra ID للهوية، وكتلة Kubernetes ثانية للتحوط التنظيمي، أو قاعدة بيانات مدارة تستخدمها وحدة أعمال مستحوَذ عليها.
الطبقة الثالثة (أدوات التوحيد — تمتد على الكل): الاهتمامات العابرة للسحاب المذكورة أعلاه: Vault، ومزود هوية واحد، ورصد موحَّد، وتطبيع للتكلفة. هذه الطبقة ليست مزود سحابي؛ إنها طبقة منصتك الداخلية.

الدروس القادمة ستعلمك Azure وGCP بعمق — نماذجهما في الحوسبة والشبكات وعروض Kubernetes المدارة وسلاسل أدوات DevOps. مع تعلمك كل خدمة، عُد دائمًا إلى سؤال هذا الدرس: لماذا تحتاج مؤسسة إلى هذا فعليًا، وما التكلفة التشغيلية الحقيقية لإضافته؟ هذا السؤال هو ما يُميِّز المهندسين الذين ينشرون البنية التحتية عن المهندسين الذين يُصمِّمونها.