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

رسم خريطة الخدمات عبر السحابات

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

رسم خريطة الخدمات عبر السحابات

لا يقارن مهندس DevOps المحترف الشعارات عند تقييم هجرة بين السحابات أو تصميم بنية قابلة للنقل — بل يقارن عقود الخدمة. S3 من AWS وBlob Storage من Azure وCloud Storage من Google كلها تخزّن الكائنات، غير أن نماذج الاتساق وأبعاد التسعير وصياغة قواعد دورة الحياة وسلوك الأعطال تختلف اختلافاً جوهرياً يظهر أثره في بيئة الإنتاج في أسوأ الأوقات. تبني هذه الدرس جدولك الذهني للترجمة: التخزين، والمراسلة، وقواعد البيانات المُدارة، والحوسبة بلا خوادم عبر AWS وAzure وGCP — وليس الأسماء فحسب، بل الفوارق السلوكية والتشغيلية التي تهم فعلاً على نطاق واسع.

تخزين الكائنات: S3 مقابل Blob Storage مقابل Cloud Storage

يُعدّ تخزين الكائنات أول ما يرسمه المهندسون في خريطة السحابات لأن كل خدمة تقريباً تعتمد عليه — الحزم المبنية والسجلات ومجموعات بيانات تعلم الآلة والأصول الثابتة. يتقارب المزودون الثلاثة في شكل الواجهة البرمجية الأساسية لكنهم يتباعدون في الدلالات.

AWS S3 يضع المعيار الفعلي للصناعة. تقع الكائنات في حاويات فريدة عالمياً في منطقة محددة. يوفر S3 اتساقاً قوياً للقراءة بعد الكتابة لعمليتي PUT وDELETE منذ ديسمبر 2020 — لا توجد نافذة بيانات قديمة بعد كتابة كائن. وتُعدّ قواعد دورة الحياة والتدرج الذكي والانتقالات إلى Glacier وS3 Object Lambda الأكثر نضجاً في المجال. يعتمد التحكم في الوصول على ثلاث طبقات: سياسات IAM وسياسات الحاوية وقوائم التحكم بالوصول ACL (وهي مُهمَلة في الأعمال الجديدة — أوقف تفعيلها بإعداد BucketOwnerEnforced).

Azure Blob Storage تنظّم الكائنات داخل حاويات داخل حسابات تخزين. حساب التخزين هو حدود الفوترة والشبكة — تفصيل يفاجئ المهندسين القادمين من AWS الذين يتوقعون نموذج حاوية مسطحة. الطبقات هي: Hot وCool وCold وArchive؛ وتُعرَّف قواعد دورة الحياة في سياسات إدارة JSON. تقدم Azure مفهوم الفضاء الهرمي (ADLS Gen2) الذي يحوّل Blob Storage إلى نظام ملفات متوافق مع POSIX لأعباء العمل الكبيرة — لا يوجد ما يعادله في GCS أو S3.

Google Cloud Storage هو الأقرب إلى S3 في النموذج: حاويات فريدة عالمياً بلا حاوية حساب وسيطة، واتساق قوي في كل الأحوال. يُعدّ GCS البيئة الأصيلة للجداول الخارجية في BigQuery ومجموعات بيانات Vertex AI مما يمنحه ميزة نظام بيئي لأعباء التحليلات. تم استبدال أداة gsutil بـgcloud storage (إصدار عام في 2024) وهي أسرع بكثير في النقل المتوازي.

خريطة التكافؤ بين خدمات AWS وAzure وGCP — أربع فئات وثلاث سحابات، والفوارق السلوكية مخفية تحت السطح.

المراسلة: الطوابير والمواضيع وناقلات الأحداث

المراسلة هي الفئة الأكثر إرباكاً في الأسماء. لدى AWS وحدها أربع خدمات متداخلة؛ وقد اتخذت Azure وGCP خيارات بنيوية مختلفة تعكس فلسفات متباينة حول ما ينبغي أن يفعله عنصر المراسلة الأساسي.

AWS SQS طابور قائم على الاستطلاع — يستقصي المستهلكون الرسائل ويحذفونها عند النجاح، ويحتفظ الطابور بها حتى تنتهي مدة الرؤية. يوفر SQS Standard التسليم مرة واحدة على الأقل؛ أما SQS FIFO فيوفر الترتيب الحصري مع سقف إنتاجية 3,000 رسالة في الثانية بالمجمّع. SNS هو نظام pub/sub للنشر المتوسع: نشر واحد لمشتركين متعددين. EventBridge هو ناقل أحداث قائم على القواعد — يوجّه الأحداث من خدمات AWS أو تطبيقاتك إلى أهداف بناءً على مطابقة أنماط JSON. في عام 2025، أصبح EventBridge طبقة التكامل المفضلة للبنى الجديدة بلا خوادم.

Azure Service Bus هو المكافئ للمؤسسات لـSQS FIFO — يدعم الجلسات (الترتيب لكل كيان) وطوابير الرسائل الميتة وتأجيل الرسائل. Azure Event Grid يقابل SNS: توجيه تفاعلي بالدفع لأحداث موارد Azure. Azure Event Hubs شيء مختلف تماماً — سجل مقسّم مشابه لـApache Kafka، مصمم للبث التدفقي لملايين الأحداث في الثانية.

Google Cloud Pub/Sub يوحّد ما تقسّمه AWS بين SQS وSNS: هو في آنٍ واحد طابور ونظام نشر متوسع. للموضوع اشتراكات متعددة؛ كل اشتراك يحتفظ بموضعه الخاص في سجل الرسائل ويسلّم باستقلالية. Eventarc هو إجابة GCP على EventBridge — يوجّه سجلات Cloud Audit وMessages إلى Cloud Run وCloud Functions بناءً على مرشّحات الأحداث.

الفارق السلوكي الجوهري: تُحذف رسائل SQS من المستهلك بعد التأكيد. تُحتفظ برسائل Pub/Sub لنافذة قابلة للضبط (7 أيام افتراضياً) ويقرأها كل اشتراك باستقلالية — أقرب إلى نموذج consumer-group في Kafka منه إلى SQS. هذا يغيّر طريقة تفكيرك في إعادة التشغيل والضغط الخلفي ومعالجة الرسائل الميتة عند الهجرة بين السحابات.

قواعد البيانات المُدارة: العلائقية وNoSQL والطبقة الاحتكارية

يمتلك رسم خريطة قواعد البيانات ثلاث طبقات: مفتوحة المصدر مُدارة (MySQL وPostgreSQL)، علائقية مقيّسة احتكارية، ومخازن NoSQL للمستندات.

قواعد البيانات العلائقية مفتوحة المصدر المُدارة هي الصف الأبسط في الجدول: AWS RDS يقابله Azure Database for PostgreSQL / MySQL وCloud SQL. الثلاثة تشغّل Postgres أو MySQL الأصلي مع نسخ احتياطية آلية ونسخ للقراءة واسترداد لحظي. فوارق بسيطة: RDS يدعم Oracle وSQL Server؛ Cloud SQL أضاف AlloyDB (متوافق مع Postgres بتسريع عمودي) في 2023؛ Azure Flexible Server يدعم HA متكرراً بمنطقتين دون وكيل احتياطي.

قواعد البيانات العلائقية المقيّسة الاحتكارية هي حيث يتباعد المزودون بشدة. Amazon Aurora يفصل الحوسبة عن طبقة تخزين موزعة مشتركة — تُوسّع عمليات القراءة أفقياً وينمو التخزين تلقائياً حتى 128 تيرابايت. Azure SQL Hyperscale يفعل الشيء ذاته لأعباء SQL Server. Google Spanner يذهب أبعد من ذلك: قاعدة بيانات علائقية موزعة عالمياً باتساق خارجي وتوسّع أفقي تشغّل SQL عبر مناطق دون أي تقسيم على مستوى التطبيق. لا يوجد ما يعادل نموذج الاتساق العالمي لـSpanner في AWS أو Azure على نطاق البيتابايت.

مخازن NoSQL والمستندات: DynamoDB مقابل Cosmos DB مقابل Firestore. الثلاثة قواعد بيانات بلا خوادم موزعة عالمياً تستهدف زمن استجابة بضعة أجزاء من الميلي ثانية. الفوارق التشغيلية الحاسمة: يتطلب DynamoDB اختيار نموذج الاتساق لكل عملية قراءة (الاتساق المتأخر أرخص — بنصف تكلفة RCU)؛ يكشف Cosmos DB خمسة مستويات اتساق قابلة للضبط عالمياً لكل حساب؛ يستخدم Firestore اتساقاً قوياً داخل المنطقة. تسعير DynamoDB قائم على وحدات السعة (RCU/WCU) — غير قابل للتنبؤ لحركة المرور المتقلبة ما لم تستخدم وضع الطلب عند الطلب.

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

الحوسبة بلا خوادم: Lambda مقابل Azure Functions مقابل Cloud Functions / Cloud Run

رسم خريطة الدوال بلا خوادم بسيط ظاهرياً — الثلاثة يشغّلون كودك عند الطلب دون إدارة خوادم — لكن الخصائص التشغيلية تختلف بما يكفي للتأثير على قرارات التصميم المعماري.

AWS Lambda يدعم حتى 15 دقيقة تنفيذ و10 غيغابايت ذاكرة و10 غيغابايت تخزين مؤقت. تتراوح فترات الإقلاع البارد من ~100 ميلي ثانية (Node.js أو Python بلا VPC) إلى عدة ثوانٍ (Java أو C# داخل VPC). Lambda مُدمج عمقاً مع كل خدمة AWS ويُطلَق أصلياً من أحداث S3 ورسائل SQS وتدفقات DynamoDB وKinesis وEventBridge وعشرات أخرى.

Azure Functions يعمل على خطة Consumption (بلا خوادم حقيقي، يُفوتر لكل تنفيذ) أو خطة Premium (نسخ مُسخَّنة مسبقاً، بلا إقلاع بارد، تكامل VNet). تضيف امتداد Durable Functions تنسيقاً ذا حالة — مكافئ لـAWS Step Functions — مبني مباشرة في وقت تشغيل الدوال. هذه ميزة معمارية مهمة لسير العمل المعقدة طويلة الأمد.

Google Cloud Functions (الجيل الثاني) مدعوم الآن بـCloud Run — منصة GCP للحوسبة بلا خوادم القائمة على الحاويات. Cloud Run يشغّل أي حاوية (وليس حزم دوال خاصة بوقت تشغيل محدد)، يتعامل مع طلبات حتى 60 دقيقة، ويتوسّع إلى الصفر. للفرق التي تضع كل شيء في حاويات مسبقاً، غالباً ما يكون Cloud Run الهدف الأفضل — يجسر الفجوة بين بلا خوادم والحاويات التي لا تسدّها Lambda بشكل كامل رغم دعمها لصور الحاويات.

# ---- نشر دوال بلا خوادم مكافئة عبر السحابات ----

# AWS Lambda (Node.js 20، من ملف مضغوط)
aws lambda create-function \
  --function-name process-order \
  --runtime nodejs20.x \
  --role arn:aws:iam::123456789012:role/lambda-exec \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --timeout 30 \
  --memory-size 256

# Azure Functions (Node.js 20، خطة Consumption)
az functionapp create \
  --resource-group myRG \
  --consumption-plan-location eastus \
  --runtime node \
  --runtime-version 20 \
  --functions-version 4 \
  --name process-order-fn \
  --storage-account mystorageacct

# GCP Cloud Run (قائم على الحاويات، يتوسّع إلى الصفر)
gcloud run deploy process-order \
  --image gcr.io/my-project/process-order:latest \
  --platform managed \
  --region us-central1 \
  --allow-unauthenticated \
  --memory 256Mi \
  --timeout 60

قواعد دورة الحياة: مقارنة صياغة ملموسة

توضّح قواعد دورة حياة تخزين الكائنات كيف أن الميزات المتطابقة مفهومياً تتطلب صياغة تهيئة مختلفة تماماً — ولهذا لا تستطيع وحدة Terraform واحدة في الغالب تجريدها بشفافية كاملة.

# ---- قاعدة دورة حياة AWS S3 (JSON عبر CLI) ----
aws s3api put-bucket-lifecycle-configuration \
  --bucket my-artifacts \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "expire-old-artifacts",
      "Status": "Enabled",
      "Filter": { "Prefix": "builds/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }]
  }'

# ---- سياسة إدارة Azure Blob Storage (ARM JSON) ----
# az storage account management-policy create \
#   --account-name mystorageacct --resource-group myRG \
#   --policy @policy.json
# policy.json يتضمن:
# tierToCool بعد 30 يوماً
# tierToArchive بعد 90 يوماً
# delete بعد 365 يوماً

# ---- قاعدة دورة حياة GCS (JSON عبر gcloud) ----
# gcloud storage buckets update gs://my-artifacts \
#   --lifecycle-file=lifecycle.json
# lifecycle.json يتضمن:
# SetStorageClass إلى NEARLINE بعد 30 يوماً
# SetStorageClass إلى COLDLINE بعد 90 يوماً
# Delete بعد 365 يوماً

أنماط الإخفاق في الإنتاج الفريدة لكل خدمة

يجب أن تتضمن كل عملية رسم خريطة للخدمات أنماط الإخفاق التي لا تظهر في الوثائق الرسمية لكنها تظهر في تنبيهات الاستجابة للحوادث في الثالثة صباحاً.

أحداث S3 + Lambda: إشعارات أحداث S3 إلى Lambda لا تضمن الترتيب وقد تسلّم نفس الحدث أكثر من مرة. إذا لم تكن دالة Lambda خاصتك ذات قيم ثابتة لعمليات متعددة (idempotent) ستتلف البيانات في ظروف الكتابة العالية. صمّم جميع الدوال المدفوعة بالأحداث لتكون قابلة للإعادة أولاً.
انتهاء صلاحية قفل رسائل Azure Service Bus: إذا استغرق معالجة رسالة وقتاً أطول من مدة القفل (60 ثانية افتراضياً)، يُحرر Service Bus القفل ويلتقطها مستهلك آخر مسببةً معالجة مكررة. اضبط دائماً مدة القفل على ضعف وقت المعالجة عند النسبة المئوية 99، وجدّد القفل برمجياً للعمليات الطويلة.
تراكم اشتراكات Pub/Sub: تحتفظ Pub/Sub بالرسائل لكل اشتراك حتى يُؤكَد استلامها. إذا انهار مستهلك ونما تراكم الاشتراك لساعات، فإن إعادة تشغيل المستهلك تطلق فيضاناً من الرسائل قد يرهق الخدمات المجانبة. استخدم التحكم في التدفق (الحد الأقصى للرسائل المعلّقة) في عميل Pub/Sub للتحكم في التسليم عند إعادة التشغيل.
أقسام DynamoDB الساخنة: يوزع DynamoDB القراءات والكتابات عبر الأقسام بالمفتاح الأساسي. المفتاح الأساسي ذو الكثافة المنخفضة (مثل حقل status بثلاث قيم فقط) يركّز حركة المرور على أقسام قليلة مطلقاً ProvisionedThroughputExceededException حتى مع معدل نقل إجمالي أقل من الحد. صمّم مفاتيح الأقسام ذات كثافة عالية — معرّف المستخدم أو معرّف الطلب أو مفتاح مركّب.
تقنين RU في Cosmos DB: تُطبّق Cosmos DB حدود وحدات الطلب لكل قسم منطقي. ارتفاع مفاجئ في قراءات مستند شهير يستنفد ميزانية RU لذلك القسم ويُعيد HTTP 429 لجميع الطلبات في ذلك القسم — حتى لو كانت أقسام أخرى لديها مساحة متبقية. استخدم سياسة الإعادة المدمجة في SDK مع التراجع الأسي.

فخ الإنتاج — افتراض تكافؤ الخدمات بين السحابات: أخطر خطأ في الهجرة هو نقل تصميم من سحابة واحدة وافتراض أن الخدمات المكافئة تتصرف بشكل متطابق. طوابير SQS Standard قد تسلّم رسالة لمستهلكين في آنٍ واحد في الظروف الاعتيادية — وليس فقط أثناء الأعطال. Pub/Sub لا تفعل ذلك. جلسات FIFO في Azure Service Bus لا يعادلها شيء في SQS Standard. تحقق دائماً من الافتراضات السلوكية في وثائق SLA والـSDK الخاصة بالخدمة المستهدفة — لا المصدر — قبل الإطلاق.

اختيار طبقة التجريد المناسبة

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

أغلفة رفيعة مع تهيئة خاصة بالمزود: استخدم وحدات Terraform تكشف واجهة مشتركة (مثل object_storage وmessage_queue) لكنها تولّد موارد أصيلة للمزود تحتها. يمنحك هذا إمكانية النقل على طبقة التوفير دون إخفاء مقابض خاصة بالمزود ستحتاجها في الإنتاج.
برمجيات وسيطة مفتوحة المصدر: استخدم أوقات تشغيل مستقلة عن المزود — MinIO للتخزين المتوافق مع S3، وNATS أو Apache Kafka للمراسلة، وDapr للتجريد على مستوى pub/sub والحالة — أمام الخدمة السحابية الأصيلة. هذا يتبادل التعقيد التشغيلي مقابل قابلية النقل. مبرر للخدمات من الدرجة الأولى حيث قابلية النقل شرط صارم؛ إفراط في الغالبية العظمى من أعباء العمل.
التجريد على مستوى التطبيق: قيّد عقد الخدمة في واجهة تطبيقك (مثل StoragePort أو QueuePort في البنية السداسية) وبدّل التطبيقات لكل بيئة نشر. هذا يبقي الكود الخاص بالسحابة في المحوّلات وطريقة عملك الأساسية محمولة تماماً — النهج الذي تستخدمه فعلياً معظم المنظمات واسعة النطاق للخدمات الأساسية.

جدول الترجمة في هذه الدرس ليس أكاديمياً — هو الأساس لاتخاذ قرارات معمارية بدقة بدلاً من التخمين. أتقن الخدمات تماماً، واعرف أين تتطابق وأين تتباعد، وستُبنى بنيتك متعددة السحابات على أرض صلبة لا على افتراضات متفائلة.