البنية التحتية ككود بمنهجين مختلفين: Terraform أم Pulumi؟

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

ولهذا أصبحت البنية التحتية ككود (Infrastructure as Code - IaC) جزءاً أساسياً من ممارسات DevOps الحديثة. فبدلاً من إعداد الموارد السحابية يدوياً، تستطيع الفرق وصف البنية التحتية في ملفات يمكن مراجعتها وإدارتها عبر Git واختبارها ونشرها من خلال عمليات آلية.

ومن أبرز الخيارات في هذا المجال Terraform وPulumi.

كلاهما يحل المشكلة العامة نفسها، لكن كل أداة تدفع المطورين إلى التفكير في البنية التحتية بطريقة مختلفة. يعتمد Terraform على نموذج بنية تحتية تصريحي ولغة HCL الخاصة به، بينما يسمح Pulumi باستخدام لغات برمجة مألوفة مثل TypeScript وPython وGo وC# وJava وYAML.

لذلك، بالنسبة لشركة تطور تطبيقات سحابية أو منتجات SaaS أو APIs أو بيئات نشر آلية، لا ينبغي أن يكون السؤال ببساطة: أي أداة أكثر قوة؟

السؤال الأفضل هو: أي نموذج للبنية التحتية يتناسب مع الطريقة التي يعمل بها فريقك الهندسي؟

Terraform وPulumi في نظرة سريعة

1. Terraform يبدأ من مفهوم البنية التحتية التصريحية

يطلب منك Terraform وصف البنية التحتية التي تريدها بدلاً من كتابة سلسلة من الأوامر التي تحدد كيفية إنشائها خطوة بخطوة.

تخيل تطبيقاً إنتاجياً يحتاج إلى شبكة افتراضية وشبكات فرعية وقاعدة بيانات مُدارة ومجموعة تطبيقات وموازنة أحمال وتخزين وقواعد أمان.

بدلاً من إنشاء كل مورد يدوياً، يمكن تمثيل البنية التحتية المطلوبة ضمن إعدادات Terraform.

بعد ذلك يقارن Terraform بين الإعدادات المعلنة وحالة البنية التحتية الحالية ويحدد التغييرات المطلوبة.

هذا النموذج مناسب بشكل خاص للمؤسسات التي تريد أن تتم تغييرات البنية التحتية من خلال عملية واضحة وموحدة وقابلة للمراجعة.

2. Pulumi يقرب البنية التحتية من كود التطبيق

يتبع Pulumi مساراً مختلفاً. فبدلاً من الاعتماد على لغة إعداد متخصصة، يسمح بتعريف البنية التحتية باستخدام لغات برمجة عامة.

على سبيل المثال، يستطيع فريق يعمل باستخدام TypeScript استخدام TypeScript نفسه لتعريف موارد السحابة.

ويصبح هذا مفيداً عندما تحتوي البنية التحتية على قدر كبير من المنطق.

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

باستخدام Pulumi، يمكن للمطورين استخدام تراكيب البرمجة المعتادة لتمثيل هذه الحالات وإنشاء مكونات بنية تحتية قابلة لإعادة الاستخدام.

3. HCL مقابل TypeScript وPython وGo وغيرها

هذا هو الفرق الأكثر وضوحاً بين Terraform وPulumi.

يستخدم Terraform لغة HCL المصممة خصيصاً للإعدادات، بينما يدعم Pulumi مجموعة من لغات البرمجة العامة.

يمكن أن تكون لغة Terraform المتخصصة ميزة لأنها تحافظ على إعدادات البنية التحتية واضحة ومركزة.

أما نهج Pulumi فيمكن أن يكون مفيداً لأن المطورين يعرفون مسبقاً مفاهيم مثل:

• الدوال
• الحلقات
• الشروط
• الكائنات
• الوحدات البرمجية
• إدارة الحزم
• اختبارات الوحدات

بالنسبة لفريق يعتمد بشكل كبير على TypeScript أو Python، قد يقلل ذلك المسافة بين تطوير التطبيق وتطوير البنية التحتية.

4. إدارة الحالة أهم مما تبدو عليه

البنية التحتية ككود ليست مجرد تخزين إعدادات السحابة في Git.

تعد إدارة الحالة من أهم المفاهيم في إدارة البنية التحتية.

يحتفظ Terraform بتمثيل للحالة يساعده على فهم العلاقة بين الإعدادات والبنية التحتية الفعلية، وغالباً ما تستخدم الفرق تخزيناً بعيداً للحالة عندما يعمل عدة مهندسين على البنية نفسها.

يحتفظ Pulumi أيضاً بحالة الموارد لتحديد كيفية تغيير البنية التحتية بين عمليات النشر، ويدعم نماذج مختلفة لتخزين الحالة.

يصبح ذلك مهماً جداً عندما يعمل أكثر من مهندس على بيئة واحدة.

يجب ألا يتحول مستودع البنية التحتية الإنتاجية إلى مجموعة من الافتراضات المحلية المتعارضة. يجب أن تكون إدارة الحالة والتحكم في الوصول والنسخ الاحتياطية والحماية والمراجعة جزءاً من التصميم منذ البداية.

5. إعادة الاستخدام تختلف بين الأداتين

نادراً ما تتكون مشاريع البنية التحتية الكبيرة من ملف إعداد واحد.

عادةً ما تنشئ الفرق أنماطاً قابلة لإعادة الاستخدام للشبكات وقواعد البيانات وKubernetes والمراقبة والهوية وبيئات التطبيقات.

يوفر Terraform مفهوم Modules لتغليف إعدادات البنية التحتية القابلة لإعادة الاستخدام.

بينما يوفر Pulumi Packages وComponent Resources لبناء تجريدات أعلى مستوى حول البنية التحتية.

تخيل شركة تنشر عشر بيئات SaaS باستخدام البنية نفسها. بدلاً من نسخ إعدادات البنية التحتية عشر مرات، يمكن إنشاء مكونات قابلة لإعادة الاستخدام وتزويدها بإعدادات خاصة بكل بيئة.

أعد استخدام التصميم المعماري، وليس الإعدادات المنسوخة.

6. منظومة Providers في Terraform تمثل ميزة مهمة

من أهم نقاط قوة Terraform منظومة Providers الواسعة.

غالباً ما تتجاوز البنية التحتية حدود مزود سحابي واحد. فقد يستخدم التطبيق مزوداً سحابياً رئيسياً إلى جانب Cloudflare أو GitHub أو Datadog أو Kubernetes أو منصة قواعد بيانات أو خدمات SaaS أخرى.

تسمح Providers لـ Terraform بالتعامل مع الموارد التي توفرها هذه المنصات المختلفة.

وقد ساعد هذا النظام الواسع Terraform على أن يصبح خياراً مألوفاً في العديد من بيئات DevOps.

إذا كانت المؤسسة تمتلك بالفعل قاعدة كبيرة من Terraform Modules وخبرات داخلية وعمليات CI/CD مبنية على Terraform، فقد يكون الانتقال إلى أداة أخرى غير ضروري ويضيف تكلفة ترحيل لا تحتاج إليها.

7. نموذج Pulumi البرمجي مفيد للبنية المعقدة

يمكن أن يحدث العكس أيضاً.

قد تمتلك المؤسسة منصة بنية تحتية يتم فيها إنشاء عشرات الموارد بشكل ديناميكي بناءً على إعدادات التطبيق.

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

يجعل استخدام Pulumi للغات البرمجة العامة هذا الأسلوب طبيعياً.

على سبيل المثال، يمكن لدالة TypeScript أن تغلف البنية المطلوبة لبيئة تطبيق كاملة وتستقبل معاملات مثل المنطقة وحجم قاعدة البيانات والنطاق ومتطلبات التوسع ونوع البيئة.

وهذا يقدم تجربة مختلفة تماماً عن التعامل مع البنية التحتية باعتبارها إعدادات فقط.

8. اختبار تغييرات البنية التحتية

يمكن للبنية التحتية أن تسبب مشكلات إنتاجية بنفس الطريقة التي يمكن أن يسببها كود التطبيق.

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

لذلك يجب مراجعة واختبار البنية التحتية بالجدية نفسها التي يتم بها التعامل مع كود التطبيق.

تستطيع فرق Terraform التحقق من الإعدادات وإنشاء Plans للمراجعة ودمج هذه العمليات ضمن CI/CD.

كما يسمح استخدام Pulumi للغات البرمجة العامة بالاستفادة من أساليب الاختبار المعروفة في هذه اللغات، إلى جانب أدوات المعاينة والتحقق الخاصة بـ Pulumi.

9. CI/CD هو المكان الذي تصبح فيه IaC عملية فعالة

تصبح البنية التحتية ككود أكثر قيمة عندما ترتبط بدورة تطوير البرمجيات ونشرها.

يمكن أن يبدو سير العمل كالتالي:

Pull Request ← Validation ← Infrastructure Plan/Preview ← Review ← Apply ← Verification

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

ويمكن للمراجعين فحص التغييرات قبل تطبيقها.

هذه إحدى أهم فوائد IaC: تصبح البنية التحتية مرئية وقابلة للمراجعة وقابلة للتكرار.

10. البيئات متعددة السحابة والهجينة

نادراً ما تبقى المؤسسات بسيطة من الناحية المعمارية إلى الأبد.

قد تبدأ الشركة باستخدام مزود سحابي واحد ثم تضيف مزوداً آخر أو Kubernetes أو خدمة SaaS أو بنية محلية.

يدعم كل من Terraform وPulumi التعامل مع البنية متعددة المزودين.

لكن الاعتبار الأهم هو مقدار التجريد الذي تحتاجه المؤسسة فعلاً.

إذا كان الفريق يمتلك Terraform Modules ناضجة عبر عدة بيئات، فقد يكون Terraform الخيار الأقل مخاطرة.

أما إذا كان المطورون يبنون منصة داخلية ويريدون أن تتصرف مكونات البنية التحتية بطريقة تشبه مكتبات البرمجيات، فقد يقدم Pulumi نموذجاً جذاباً.

11. مهارات الفريق يجب أن تؤثر في القرار

يجب أن تأخذ اختيارات التقنية في الاعتبار الأشخاص الذين سيحافظون على النظام.

فريق DevOps يمتلك خبرة واسعة في Terraform وHCL وModules وProviders وعمليات Terraform الحالية سيحقق إنتاجية أسرع غالباً باستخدام Terraform.

بينما قد يجد فريق هندسي يعمل يومياً باستخدام TypeScript أو Python أو Go أو C# أن Pulumi أكثر طبيعية.

لكن هناك نقطة مهمة:

استخدام لغة برمجة مألوفة لا يعني تلقائياً أن البنية التحتية أصبحت أسهل.

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

يقلل Pulumi الحاجة إلى تعلم لغة إعداد متخصصة، لكنه لا يلغي الحاجة إلى فهم البنية التحتية.

12. ماذا عن الأمان؟

لا يجعل Terraform أو Pulumi البنية التحتية آمنة تلقائياً.

أداة IaC هي طبقة واحدة فقط ضمن منظومة الأمان.

يجب أن تهتم الفرق بإدارة الأسرار، وصلاحيات IAM، وحماية الحالة، ومراجعة الكود، وتدوير بيانات الاعتماد، وعزل الشبكات، وفرض السياسات وقابلية التدقيق.

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

13. متى يكون Terraform الخيار الأفضل؟

• عندما تريد نموذج IaC تصريحي وناضج.
• عندما تمتلك المؤسسة خبرة سابقة قوية في Terraform.
• عندما تعتمد على Terraform Modules وProviders موجودة مسبقاً.
• عندما تكون البنية التحتية معتمدة بشكل أساسي على الإعدادات.
• عندما تريد فصل تعريف البنية التحتية عن لغات برمجة التطبيق.
• عندما تكون عمليات CI/CD والحوكمة مبنية بالفعل على Terraform.

14. متى يكون Pulumi الخيار الأفضل؟

• عندما يفضل الفريق TypeScript أو Python أو Go أو C# أو لغة مدعومة أخرى.
• عندما تحتوي البنية التحتية على منطق برمجي وشروط وإعادة استخدام واسعة.
• عندما تريد أن تتعامل مع مكونات البنية التحتية بطريقة تشبه مكتبات البرمجيات.
• عندما سيقوم المطورون بصيانة البنية التحتية بالتوازي مع كود التطبيق.
• عندما تريد الاستفادة من أدوات ولغات البرمجة المألوفة وإدارة الحزم.

15. Terraform مقابل Pulumi لمنتج SaaS متنامٍ

تخيل شركة SaaS تبدأ ببيئة إنتاج واحدة.

مع نمو المنتج، تحتاج الشركة إلى بيئات تطوير واختبار وإنتاج، ونشر في مناطق متعددة، وإنشاء قواعد بيانات بشكل آلي، وبنية للحاويات، ومراقبة، ونطاقات مخصصة، وDNS آلي وسياسات للتوسع.

في البداية قد تعمل أي أداة IaC مناسبة.

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

هنا يبدأ القرار الأول لأداة IaC بالتأثير على المدى الطويل.

يمكن لـ Terraform توفير نموذج تصريحي ومنظم لهذه البيئات، بينما يستطيع Pulumi توفير نموذج برمجي قد يكون مناسباً بشكل خاص عندما تحتاج البنية إلى قدر كبير من التجريد والمنطق.

كيف ينظر Code-Ox إلى البنية التحتية ككود؟

في Code-Ox، تكون البنية السحابية أكثر فاعلية عندما تدعم معمارية التطبيق بدلاً من أن تصبح نظاماً تشغيلياً منفصلاً عنها.

عند تطوير تطبيقات ويب مخصصة ومنصات SaaS وواجهات API وأنظمة آلية، يجب أن تأخذ قرارات البنية التحتية في الاعتبار قابلية التوسع وتكرار النشر والأمان والتكاملات والمراقبة والصيانة المستقبلية.

لذلك ينبغي اتخاذ قرار Terraform أو Pulumi بالتوازي مع قرارات معمارية التطبيق وCI/CD والخدمات السحابية وقواعد البيانات والبيئات والمسؤوليات التشغيلية.

على سبيل المثال، قد يميل فريق يعتمد بشكل كبير على TypeScript إلى Pulumi لأن البيئة الهندسية نفسها يمكن أن تمتد من تطوير التطبيق إلى البنية التحتية. بينما قد تستفيد مؤسسة تمتلك استثماراً كبيراً في Terraform من تحسين بنيتها الحالية بدلاً من إدخال أداة جديدة.

الهدف ليس استخدام أداة البنية التحتية الأحدث، وإنما بناء منصة بنية تحتية تظل واضحة وقابلة للتوقع مع نمو المنتج.

الخلاصة

Terraform خيار قوي عندما يريد الفريق نموذجاً إعلانياً ناضجاً للبنية التحتية، ومنظومة واسعة من Providers، وModules معروفة، وسير عمل IaC واضح.

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

لا تنتج أي من الأداتين بنية تحتية أفضل تلقائياً.

تعتمد جودة النتيجة على المعمارية وإدارة الحالة والأمان والاختبارات وCI/CD والحوكمة والممارسات الهندسية المحيطة بالأداة.

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

إذا كان فريقك يصمم تطبيقاً سحابياً جديداً أو يعيد التفكير في استراتيجية أتمتة البنية التحتية، يمكن لـ Code-Ox المساعدة في ربط معمارية التطبيق والبنية السحابية والأتمتة وعمليات النشر ضمن نهج هندسي واحد قابل للتوسع.

البنية التحتية الجيدة يجب أن تختفي خلف تجربة منتج موثوقة.