ملخص
- الوحدة الاستراتيجية لـ HashiCorp هي التغيير المعتمد للبنية التحتية: خطة Terraform يفهمها المراجعون، نتيجة سياسة تحترمها المؤسسة، تحديث حالة لا يزال يعكس السحابة الحقيقية، عقد إيجار سري لا يتجاوز صلاحيته، ومسار استرداد يعمل عندما يظهر الانحراف.
- يستبدل Terraform و HCP Terraform جزءًا كبيرًا من العمل اليدوي في لوحات التحكم السحابية، والتزويد بالنصوص البرمجية وحركة الموافقات العشوائية، لكنهما لا يزيلان الملكية. لا يزال البشر يصممون الوحدات، ويوافقون على الخطط المحفوفة بالمخاطر، ويصونون المزودين، ويكتبون السياسات، ويديرون حدود الحالة، ويتعاملون مع الاستثناءات ويتحملون عواقب التطبيق المدمر.
- أقوى دليل على HashiCorp ليس اقتباسًا من عميل واحد أو مخرجات خطة نظيفة. بل هي الآلية الصريحة للمنتج حول الحالة والخطط ومراحل التشغيل وفحوصات السياسة وتقييم الانحراف وأقفال المزودين وعقود Vault. أضعف نقطة هي أن الأدلة العامة لا تُظهر معدل فشل عام، أو معدل نجاح الاسترجاع، أو تكلفة التغيير المعتمد عبر البيئات الحقيقية.
- السؤال التجاري هو ما إذا كان تقليل التغييرات اليدوية وزيادة الحوكمة يفوقان تكاليف التراخيص والموارد المدارة والترحيل وصيانة الوحدات وانحراف المزودين وإصلاح الحالة ودوران الأسرار والتدريب والقفل التجاري. تبدو HashiCorp أقوى حيث تكون تغييرات البنية التحتية متكررة وقابلة للتكرار وقابلة للقياس؛ وتبدو أضعف حيث تشتري الفرق الأداة ولكنها تترك نموذج التشغيل دون تغيير.
التغيير هو المنتج
يفتح مهندس منصة طلب سحب يغير موازن تحميل ويضيف مجموعة معلمات قاعدة بيانات ويعدل قاعدة هوية لخدمة جديدة. الطريقة القديمة مألوفة: شخص ما يتنقل في لوحة تحكم سحابية، وآخر يفحص تذكرة، ويتم تشغيل نص برمجي من حاسوب محمول، وتُنسخ كلمة مرور إلى خط أنابيب، وتمتلئ قناة عمليات بلقطات شاشة بعد الحدث. إذا نجح التغيير، تتذكر المؤسسة الشخص الذي عرف ماذا ينقر. وإذا فشل، تبدأ قصة الاسترداد بعمل تحري.
وعد HashiCorp ليس أن البنية التحتية تصبح سهلة. بل أن هذا النوع من التغيير يمكن أن يصبح كيانًا محكومًا. يتم تدوين حالة البنية التحتية المقترحة. يقارن Terraform تلك الحالة المرغوبة بما هو معروف عن البيئة الحقيقية. تُظهر الخطة ما سيتم إنشاؤه أو تحديثه أو تدميره. يمكن للمراجع قراءة الخطة. يمكن لـ HCP Terraform وضع التشغيل في قائمة انتظار، وإظهار تاريخه، وإيقافه للتأكيد، وفحص السياسة، وتشغيله في بيئة خاضعة للرقابة والاحتفاظ بجدول زمني. يمكن لـ Vault تغيير كيفية إصدار بيانات الاعتماد وإبطالها. يمكن لـ Consul و Boundary و Packer توسيع نفس فكرة التشغيل لتشمل اكتشاف الخدمات والوصول وممارسات بناء الصور.
لهذا السبب فإن القاسم المفيد هو التغيير المعتمد للبنية التحتية. ليس أمرًا ناجحًا. ليس معيارًا. ليس ادعاء إطلاق. التغيير المعتمد هو تعديل مقترح للبنية التحتية يمكن للفريق المسؤول فهمه والموافقة عليه وتطبيقه ومراقبته والتعافي منه. يتم اعتماده فقط عندما يوافق أصحاب السلطة على أن الخطة تتطابق مع النية، وأن الضوابط مستوفاة، وأن نتيجة التطبيق تتوافق مع الواقع وأن أي شك متبقٍ يكون مرئيًا.
هذا معيار صارم، وينبغي أن يكون كذلك. تغييرات البنية التحتية عادية ومتكررة وخطيرة بقدر روتينها. يمكن لشركة أن تنجو من ترحيل استثنائي لمرة واحدة بغرفة عمليات ومشغلين أبطال. لكنها لا تستطيع تشغيل بنية سحابية كبيرة بالبطولات كل ثلاثاء. يجب أن يكون التغيير اليومي مملًا بما يكفي لمراجعته وموثقًا بما يكفي لعكسه. هذا هو المكان الذي تكسب فيه HashiCorp قيمتها أو تخسرها.
كما تبقي الأطروحة HashiCorp ضمن حدودها الصحيحة.أكملت IBM استحواذها على HashiCorpفي فبراير 2025، وتمتلك IBM الآن السياق التجاري. لكن السؤال الهندسي في هذه المقالة ليس استراتيجية الاستحواذ. بل هو ما إذا كانت المنتجات التي تسيطر عليها HashiCorp، وخاصة Terraform و HCP Terraform و Vault، تحافظ على السيطرة عندما تتغير البنية التحتية بشكل متكرر عبر السحب والفرق والوقت.
ما الذي تستبدله HashiCorp، وما لا تستبدله
قبل أن يصبح Terraform طبيعيًا في العديد من فرق المنصات، كان عمل البنية التحتية غالبًا ما يقع بين إدارة التغيير الرسمية والحرفية غير الرسمية. وصفت تذكرة النية. تنقل مسؤول سحابة في لوحة تحكم. عدّل مهندس كبير نصًا برمجيًا. فحص مراجع أمني جدول بيانات. أصدر مالك الأسرار بيانات اعتماد. وثق مدير الإصدارات بأن الشخص الذي يجري التغيير قد اتبع الممارسة المحلية. كان لدى بعض المؤسسات أتمتة ناضجة قبل Terraform، لكن التوتر الأساسي كان نفسه: تحتاج البنية التحتية إلى انضباط تسليم البرمجيات دون أن تصبح نظامًا برمجيًا مخصصًا آخر.
Terraformيستبدل عدة خطوات من تلك. يمنح الفرق ملف تكوين تصريحي بدلاً من ذاكرة النقرات على لوحة التحكم. يستخدم مزودين للتحدث إلى واجهات برمجة تطبيقات السحابة والخدمات. يبني خطة قبل التطبيق. يسجل الحالة بحيث يكون للعمليات المستقبلية خريطة بين الموارد المعلنة والكائنات البعيدة. يمكنه تشغيل نفس سير العمل الأساسي عبر AWS و Azure و Google Cloud و Kubernetes و خدمات DNS وأدوات المراقبة والعديد من الأهداف الأخرى من خلال ملحقات المزودين.
HCP Terraformيستبدل طبقة أخرى من الممارسة المحلية. بدلاً من أن يقوم كل مهندس بتشغيل خطة من حاسوب محمول مختلف، يمكن وضع التشغيلات عن بُعد في نظام مشترك مع قائمة انتظار وأذونات وفحوصات سياسة وتاريخ تشغيلوحالة مشتركة. يصبح التشغيل قطعة أثرية مرئية، وليس مجرد سجل أوامر. يمكن للمراجع رؤية التسليم والحالة الحالية والجدول الزمني ومخرجات الخطة ومخرجات التطبيق. يمكن لمساحة العمل التوقف في حالة تأكيد. يمكن لمستخدم لديه إذن التأكيد أو التجاهل أو الإلغاء أو قفل مساحة العمل.
يستبدل Vault عادة التعامل مع الأسرار على أنها نصوص دائمة. يمكن أن تصبح بيانات اعتماد قاعدة بيانات أو مفتاح سحابة كائنًا مؤجرًا وقابلًا للتدقيق وقابلًا للإبطال بدلاً من قيمة تعيش إلى أجل غير مسمى في خط أنابيب أو ويكي. هذا مهم لأن التغييرات المعتمدة للبنية التحتية غالبًا ما تحتاج إلى سلطة. أخطر خطة لا تزال خطيرة إذا تم تنفيذها ببيانات اعتماد واسعة جدًا أو قديمة جدًا أو من المستحيل إبطالها بسرعة.
ما يبقى بشريًا كبير. لا يزال الناس يقررون كيفية تقسيم البنية التحتية إلى مساحات عمل، وأي الوحدات موثوقة، وأي إصدارات المزودين مسموح بها، وأي التغييرات تتطلب موافقة، وأي السياسات يجب أن تمنع التشغيل، وأي الاستثناءات مقبولة، وأي الأسرار يمكن إصدارها، وأي الحسابات السحابية في النطاق وماذا يعني الاسترجاع. ينتقل العمل من التنفيذ اليدوي إلى التصميم والإشراف والصيانة. إذا تظاهر المشتري بأن HashiCorp تزيل الحاجة إلى هؤلاء الأشخاص، فإن النشر سيخيب أمله.
هذه هي الصفقة التجارية. يمكن لـ HashiCorp تقليل الخطوات اليدوية المتكررة وزيادة قابلية المراجعة وجعل تغيير البنية التحتية أقل اعتمادًا على الذاكرة الفردية. في المقابل، يتحمل المشتري عبء تشغيل المنصة: تصميم الحالة، حوكمة الوحدات، صيانة السياسات، اختبار المزودين، تصميم دورة حياة الأسرار، التدريب، الدعم، الترحيل وإدارة الأسعار. التغيير ليس مجانيًا. يصبح أكثر وضوحًا.
الحالة هي سطح السلطة
حالة Terraform هي مركز الأطروحة لأن الحالة هي المكان الذي تتذكر فيه الأداة ما تعتقد أنها تتحكم فيه.وثائق الحالةالخاصة بـ HashiCorp مباشرة: يجب على Terraform تخزين الحالة حول البنية التحتية المدارة والتكوين لمساحة العمل؛ وتستخدم هذه الحالة لربط موارد العالم الحقيقي بالموارد المعلنة، وتتبع البيانات الوصفية وتقرير التغييرات المستقبلية. قبل العمليات، يقوم Terraform بتحديث الحالة مع البنية التحتية الحقيقية.
يبدو ذلك ميكانيكيًا. في بيئة كبيرة، هو حوكمة. إذا قالت الحالة إن موردًا ينتمي إلى وحدة، فقد يقوم Terraform لاحقًا بتحديث أو تدمير ذلك الكائن البعيد عندما يتغير التكوين. إذا حذف مهندس رابطًا دون فهم الكائن البعيد، يمكن أن يفقد Terraform الاتصال بين العالم المعلن والحقيقي. إذا فُقد ملف حالة محلي أو كُشف أو عُدل مباشرة، تصبح سلطة الأداة هشة. إذا كانت الحالة موجودة في نظام تخزين بدون قفل وتحكم آمن في الوصول، فإن عملية التغيير لديها نقطة فشل مفردة خفية.
لذلك يبدأ اختبار التغيير المعتمد قبل أي خطة. هل تعرف المؤسسة أي ملف حالة أو مساحة عمل تمتلك المورد؟ هل تعرف أي الأشخاص والخدمات يمكنهم قراءته؟ هل تعرف ما إذا كانت الأسرار تظهر داخل الحالة؟ هل تمنع التطبيقات المتزامنة التي يمكن أن تدهس بعضها البعض؟ هل تعامل ترحيل الحالة كعملية خاضعة للرقابة بدلاً من مهمة تنظيف؟
هنا يمكن أن تبدو Terraform قوية ولا ترحم في نفس الوقت. في إعداد صحي، تحول الحالة البنية التحتية المبعثرة إلى شيء يمكن للمؤسسة التفكير فيه. تمنح المراجعين خريطة مسبقة. تسمح بتحديد الانحراف. تسمح بحساب الخطط المستقبلية من علاقة معروفة بين التكوين والكائنات البعيدة. في إعداد ضعيف، تصبح الحالة قاعدة بيانات هشة أخرى، باستثناء أن هذه يمكن أن تصف جدران الحماية وقواعد البيانات وقواعد الهوية وموارد التوجيه.
تكون قيمة HashiCorp أقوى عندما تُعامل الحالة كسجل للسلطة، وليس كملف مُنشأ. يساعد HCP Terraform من خلال تقديم حالة مشتركة آمنة وتنفيذ عن بُعد، لكن المشتري لا يزال يقرر الحدود. يمكن أن تخلق مساحة عمل واحدة لكل شيء نصف قطر انفجار وارتباك في المراجعة. يمكن أن تخلق آلاف مساحات العمل تشتتًا. الحالة المقسمة بدقة شديدة تجعل التفكير في التبعيات صعبًا. الحالة المجمعة على نطاق واسع جدًا تجعل الملكية صعبة. الأداة لا تجعل هذه المقايضات تختفي.
تغير الحالة أيضًا من قام بالعمل من قبل. ربما تذكر المشغل القديم أن شبكة فرعية لقاعدة بيانات تم إنشاؤها خلال حادث ويجب ألا تُلمس أبدًا. لن تتذكر Terraform ذلك ما لم تشفره الحالة والتكوين والسياسة وعملية المراجعة. يجب أن تصبح الذاكرة البشرية قطعة أثرية مُدارة. هذا أقل رومانسية من نموذج الحرفية القديم، لكنه هو المغزى.
الخطة وعد بفترة صلاحية قصيرة
غالبًا ما يُعاملأمر الخطةفي Terraform على أنه الجزء الآمن من البنية التحتية ككود، وهو أكثر أمانًا من التنفيذ الأعمى. يقرأ الحالة الحالية للكائنات البعيدة الموجودة، ويقارن التكوين بالحالة السابقة ويقترح إجراءات من شأنها جعل الكائنات البعيدة تتطابق مع التكوين. لا يقوم هو نفسه بتنفيذ التغييرات المقترحة. هذا الفصل قيم لأنه يمنح المراجعة كائنًا ملموسًا.
لكن الخطة ليست عقدًا دائمًا. تحذر وثائق أوامر HashiCorp نفسها من أنه إذا حدثت تغييرات في النظام المستهدف بين خطة تخمينية والتطبيق النهائي، فقد يختلف التأثير النهائي عما أشارت إليه الخطة السابقة. هذه هي بالضبط مشكلة السحابة اليومية. شخص ما يصلح حادثًا يدويًا. واجهة برمجة تطبيقات مزود تبلغ عن قيمة افتراضية جديدة. مجموعة أمان يتم تغييرها بواسطة نظام آخر. خدمة مُدارة تغير حقلًا. فريق سحابة يضيف وسمًا خارج Terraform. الخطة التي بدت نظيفة صباح الثلاثاء قد لا تكون الخطة التي يجب أن تعمل بعد ظهر الثلاثاء.
لهذا السبب فإن التغيير المعتمد للبنية التحتية هو أكثر من مجرد قطعة أثرية للخطة. يجب أن تكون الخطة حديثة بما فيه الكفاية ومحددة بما فيه الكفاية ومراجعة من قبل شخص يفهم نصف قطر الانفجار. إذا كان التشغيل آليًا، يجب على النظام أن يقرر ما إذا كان يمكن تخطي الموافقة. يدعمأمر التطبيقفي Terraform الموافقة التلقائية، لكن الوثائق تحذر من أنه الأكثر أمانًا فقط عندما لا يمكن للبنية التحتية أن تتغير خارج سير عمل Terraform. هذا معيار مرتفع في معظم المؤسسات.
تخفي الخطة أيضًا سؤالًا دقيقًا: ما هي وحدة الموافقة؟ قد يوافق المراجع على نص خطة دون فهم سلوك المزود وراءها. قد يكون إجراء الاستبدال غير ضار لمثيل قابل للاستهلاك وكارثي لقاعدة بيانات. قد يكون تغيير الوسم طفيفًا حتى تعتمد عليه سياسة الفوترة أو الوصول. قد تبدو قاعدة الشبكة ضيقة ولكنها تؤثر على مسار مشترك. المراجعة البشرية المتبقية ليست احتفالية. إنها حيث يدخل السياق.
يجعلدورة حياة التشغيلفي HCP Terraform هذا السياق أكثر وضوحًا. يمكن أن تمر التشغيلات عبر مراحل معلقة وخطة وتقدير التكلفة وفحص السياسة والتطبيق والاكتمال. يمكنها التوقف في حالة بحاجة إلى تأكيد. يمكن تجاهلها. إذا فشلت السياسة بهدوء، يمكن للمستخدمين ذوي الإذن المناسب تجاوزها. إذا كان التشغيل قيد التخطيط أو التطبيق حاليًا، يمكن للمستخدمين ذوي الإذن إلغاؤه. يمكن أن يكون للإلغاء القسري آثار جانبية خطيرة، بما في ذلك فقدان الحالة والموارد المتروكة.
هذه التفاصيل مهمة لأنها تثبت أن HashiCorp لا تبيع آلة بسيطة "اضغط زر، استلم بنية تحتية". إنها تبيع مستوى تحكم لقرارات التغيير. كل توقف وتجاوز وتجاهل وإلغاء هو دليل على أن العمل يبقى مشروطًا. يمكن للنظام أن يحمل تغييرًا مقترحًا عبر تسلسل قابل للتكرار، لكن المؤسسة لا تزال تقرر متى يُسمح لهذا التسلسل بالانتهاء.
السياسة تجعل المخاطرة مرئية، لا غائبة
السياسة ككودهي واحدة من أقوى حجج HashiCorp المؤسسية. يمكن لـ HCP Terraform فحص الخطط مقابل مجموعات سياسات Sentinel أو OPA. يمكن للسياسة فرض معايير الأمان وقواعد الموقع وقواعد الوسم وضوابط التكلفة أو توقيت الإصدار. يمكن للسياسات الفاشلة إيقاف التشغيلات اعتمادًا على مستوى الإنفاذ، ويتطلب التجاوز إذنًا. أمثلة HashiCorp عملية: التحقق مما إذا كان النشر الإنتاجي يذهب إلى المنطقة الصحيحة، أو منع النشر أيام الجمعة لتقليل مخاطر الحوادث خارج أوقات العمل.
هذا استبدال حقيقي لأعمال المراجعة القديمة. بدلاً من أن يقرأ كل مراجع أمني كل خطة لنفس القاعدة، يمكن تشغيل القواعد المشتركة بشكل متكرر. بدلاً من الاعتماد على الذاكرة بأن حاويات التخزين تحتاج إلى تشفير أو أن موارد الإنتاج تتطلب وسمًا، يمكن للسياسة اختبار الخطة. بدلاً من الجدال بعد التطبيق، يمكن إيقاف التشغيل قبل وصول التغيير إلى السحابة.
لكن السياسة ليست مثل الحكم. إنها تقنن ما تذكرت المؤسسة ترميزه. قد تفوت خدمة جديدة أو منطقة جديدة أو حقل مزود جديد أو استثناء عمل أو علاقة بين الموارد واضحة فقط للشخص. يمكن أن تكون السياسة أيضًا صارمة جدًا وتجبر الفرق على عادات التجاوز. بمجرد أن يصبح التجاوز روتينيًا، يمكن أن يخلق وجود مجموعة سياسات راحة زائفة. يصبح السؤال ليس "هل لديك سياسات؟" ولكن "أي السياسات تمنع، وأيها تحذر، ومن يمكنه التجاوز، وكم مرة يرتبط التجاوز لاحقًا بالحوادث أو إعادة العمل؟"
لهذا السبب فإن صيانة السياسة هي جزء من تكلفة كل تغيير معتمد. يجب على الفرق تحديث السياسات عندما تتغير الخدمات السحابية. يجب عليهم اختبار السياسات مقابل خطط تمثيلية. يجب عليهم مراجعة أنماط الاستثناءات. يجب عليهم أن يقرروا ما إذا كانت السياسة يجب أن تكون عالمية أم خاصة بالمشروع أم خاصة بمساحة العمل. يجب عليهم التأكد من أن مستودعات السياسات وملكيتها لا تنحرف عن البنية التحتية التي تحكمها.
تغير السياسة أيضًا شكل العمل. قد يقوم فريق أمان مركزي بعمل أقل في مراجعة التذاكر المتكررة ولكن المزيد من هندسة السياسات. قد يقوم فريق المنصة بتزويد يدوي أقل ولكن المزيد من تصميم الوحدات وفرز استثناءات السياسة. قد تكتسب فرق التطبيقات استقلالية ولكنها ترث الالتزام بفهم سبب فشل الخطة. هذا نموذج تشغيل أفضل عندما يعمل، لكنه ليس إلغاء للعمل. إنه نقل للعمل.
بالنسبة لـ HashiCorp، هذا مكان معقول للمنافسة. يمكن للمنتج جعل المخاطرة مرئية عند نقطة التغيير، حيث يكون إصلاحها أرخص. الحقيقة غير المحلولة هي كم مرة يحافظ العملاء على تحديث هذه السياسات بما يكفي لتكون ذات أهمية. لا يمكن للوثائق العامة الإجابة عن ذلك. يجب على المشترين قياس ذلك في بيئتهم الخاصة.
الانحراف هو الخصم اليومي
أقوى قصة للبنية التحتية ككود تفترض أن التكوين هو مصدر الحقيقة وأن العالم يتبعه. العمليات الحقيقية أكثر فوضى. تتطلب الحوادث تدخلًا يدويًا. الخدمات السحابية تغير الإعدادات الافتراضية. أنظمة أخرى تغير الموارد. فريق يستورد شيئًا متأخرًا. لوحة تحكم بائع تسمح لمستخدم مميز بتغيير إعداد. مع مرور الوقت، تنحرف البيئة الحقيقية عن التكوين المعلن.
تعامل HashiCorp الانحراف كموضوع من الدرجة الأولى. يمكن لـ Terraform تحديث الحالة. يمكن للتخطيط القائم على التحديث فقط تحديث الحالة والمخرجات لتتوافق مع التغييرات عن بُعد دون تعديل البنية التحتية.تقييمات صحة HCP Terraformتشمل اكتشاف الانحراف، الذي يحدد ما إذا كانت البنية التحتية في العالم الحقيقي تتطابق مع التكوين، والتحقق المستمر، الذي يتحقق مما إذا كانت الشروط المخصصة لا تزال تتحقق بعد التزويد. يشرح برنامج HashiCorp التعليمي للانحراف المشكلة التشغيلية بمزيد من التفصيل من خلالانحراف الموارد. الميزة لها متطلبات: إصدارات Terraform المدعومة، أوضاع التنفيذ عن بُعد أو المتحكم بها، آخر تشغيل ناجح وتطبيق واحد على الأقل للبنية التحتية الحقيقية. يمكن أن تؤثر التشغيلات المتكررة على توقيت التقييم لأن فحوصات الصحة لا تقاطع التشغيلات.
هذا سطح منتج مفيد لأن الانحراف ليس فشلًا غريبًا. إنه حياة سحابية عادية. السؤال المهم هو من يراه ومتى. إذا غير إنسان قاعدة أمان خلال حادث، فقد تحاول الخطة العادية التالية إلغاء ذلك. إذا تم تحديث الحالة دون تحديث مطابق للتكوين، فقد يعترف الفريق بالانحراف دون أن يقرر ما إذا كان التغيير اليدوي مقبولاً. إذا توقف تقييم الصحة لأن آخر تشغيل فشل، فقد تتوقف مساحة العمل عن إنتاج الإشارة التي يتوقعها الفريق.
يسأل اختبار التغيير المعتمد ما إذا كانت معالجة الانحراف جزءًا من الروتين. هل يعرف الفريق أي التغييرات مسموح بها خارج Terraform أثناء الحوادث؟ هل يسجلها؟ هل يوفق التكوين بعد ذلك؟ هل يميز بين انحراف الطوارئ والانحراف غير المصرح به؟ هل يعرف من يمكنه تشغيل تقييم عند الطلب؟ هل يراقب مساحات العمل حيث تكون فحوصات الصحة معطلة أو متوقفة أو بطيئة جدًا لتكون مفيدة؟
هنا يقلل العديد من المشترين من التكلفة. يقلل Terraform من التزويد اليدوي، لكنه لا يزيل الحاجة إلى نظافة الانحراف. شخص ما يجب أن يقرأ نتيجة الانحراف. شخص ما يجب أن يقرر ما إذا كان سيحدث التكوين أو ينعش الحالة أو يستورد موردًا أو يستبدل موردًا أو يترك استثناءً. شخص ما يجب أن يتحقق من أن التصحيح لم يتسبب في أن تصبح خطة أخرى مدمرة.
تتحسن قيمة HashiCorp عندما يتحول الانحراف إلى قائمة انتظار مقبولة من القرارات بدلاً من تراكم خفي للمفاجآت. لا يمكن للمنتج أن يجعل كل انحراف سيئًا أو كل تغيير يدوي ممنوعًا. يمكنه أن يجعل عدم التطابق أصعب في التجاهل.
المزودون هم سلسلة توريد سلطة البنية التحتية
يعمل Terraform من خلال المزودين. المزودون هم ملحقات تسمح لـ Terraform بالتفاعل مع الأنظمة البعيدة. يعلن التكوين عنمصدر المزود وقيود الإصدار؛ توفر كتل المزود المصادقة والمناطق والحجج الخاصة بالمزود؛ يقوم HCP Terraform و Terraform Enterprise بتثبيت المزودين كجزء من التشغيلات. يسجلملف قفل التبعيةإصدارات المزود المحددة بحيث تستخدم التشغيلات المستقبلية نفس الإصدارات افتراضيًا، وتوصي HashiCorp بإيداع هذا الملف في نظام التحكم بالإصدارات للمراجعة.
هذا يجعل المزودين سلسلة توريد. يترجم المزود تكوين Terraform إلى استدعاءات API سحابية ويقرأ الحالة عن بُعد مرة أخرى إلى نموذج Terraform. إذا تغير سلوك المزود، فقد تتغير الخطة. إذا تغيرت API السحابة، فقد يحتاج المزود إلى تحديث. إذا نسي فريق قفل أو اختبار إصدارات المزودين، يمكن أن يصل تحديث من خلال التهيئة الروتينية. إذا ظهر خطأ في المزود، يمكن أن يعبر نصف قطر الانفجار كل مساحة عمل تستخدمه.
ملف القفل هو عنصر تحكم جيد، لكنه ليس علاجًا. يتتبع اختيارات المزودين، وليس كل إصدار وحدة عن بُعد بنفس الطريقة. يساعد الفرق على مراجعة تحديثات المزودين، لكنه لا يثبت أن التحديث آمن لبيئة معينة. لا يمنع خدمة سحابية من تغيير قيمة افتراضية أو إهمال API. لا يجعل المزودين الطرف الثالث متساويين مع المزودين الذين تحتفظ بهم HashiCorp. لا يزيل مشاكل المصادقة أو تغييرات الأذونات أو سلوك حدود المعدل.
هذا مهم للسؤال التجاري لأن صيانة المزودين والوحدات هي تكلفة حقيقية. قد يوفر فريق المنصة آلاف العمليات على لوحة التحكم ومع ذلك يقضي وقتًا كبيرًا في تثبيت الإصدارات واختبار التحديثات ومراجعة تغييرات الوحدات وكتابة ملاحظات التوافق والتعافي من تغييرات سلوك المنبع. التكلفة تستحق الدفع عندما تستبدل مخاطرة يدوية أكبر. تصبح مخيبة للآمال عندما ظن المشتري أن Terraform كان استثمار أتمتة لمرة واحدة.
توضح رؤية سلسلة التوريد أيضًا البدائل. يمكن للبناء الداخلي تجنب تكلفة ترخيص HashiCorp ولكن يجب أن يتحدث إلى APIs السحابة ونمذجة الحالة والتعامل مع الانحراف وإدارة تكاملات تشبه المزودين. يمكن لمنصة SaaS التقليدية توفير سير عمل أضيق ولكنها قد تقلل من قابلية النقل. تتوافق الأدوات السحابية الأصلية مثل CloudFormation أو Azure Bicep أو Deployment Manager بشكل وثيق مع مزود واحد ولكنها تضعف قصة السحب المتعددة. يحافظ OpenTofu على بديل مفتوح للبنية التحتية ككود، لكن الترحيل لا يزال يجب أن يحسب حساب الحالة وتوافق المزودين وسير العمل المستضاف والضوابط المؤسسية وألفة الموظفين.
ميزة HashiCorp ليست أنها تزيل التبعية على المنبع. إنها تنظمها في سير عمل مألوف وقابل للمراجعة. وظيفة المشتري هي أن يقرر ما إذا كان سير العمل هذا يستحق طبقة المنصة الإضافية.
Vault يغير معنى الإذن
يغير Terraform البنية التحتية. يغير Vault السلطة. هاتان العبارتان تنتميان معًا لأن تغيير البنية التحتية المحكوم غالبًا ما يفشل عند حدود بيانات الاعتماد. قد تكون الخطة آمنة، لكن المفتاح المستخدم لتنفيذها قد يكون واسعًا جدًا. قد يكون خط الأنابيب موثوقًا، لكن بيانات اعتماد قاعدة البيانات بداخله قد تكون ثابتة. قد يتم إصدار سر طارئ بشكل صحيح ثم يُنسى. قد يترك التطبيق الناجح وراءه وصولاً لم يعد يتطابق مع البنية التحتية الجديدة.
تصفوثائق Vaultنموذجًا مختلفًا. يركز Vault إدارة الأسرار، ويحكم الوصول من خلال أساليب المصادقة والتفويض، ويدقق النشاط. يمكنمحركات الأسرارتخزين أو توليد أو تشفير البيانات. يمكنمحركات أسرار قواعد البياناتتوليد بيانات اعتماد ديناميكيًا بناءً على الأدوار، مما يمنح كل خدمة بيانات اعتماد فريدة ويجعل مسارات التدقيق أكثر فائدة. الأسرار الديناميكية والرموز من نوع الخدمة لهاعقود إيجارمع قيم مدة الصلاحية. يمكن تجديد عقود الإيجار أو إبطالها، ويمكن إبطال عقود الإيجار منتهية الصلاحية تلقائيًا. يمكن للإبطال القائم على البادئة إبطال أشجار الأسرار لمسار خلفي.
هذا يستبدل بعض الأعمال القديمة مباشرة. بدلاً من أن يصدر إنسان كلمة مرور قاعدة بيانات طويلة العمر لفريق خدمة، يمكن لخدمة طلب بيانات اعتماد قصيرة العمر. بدلاً من تدوير بيانات الاعتماد يدويًا وفقًا لتقويم، يمكن لـ Vault المساعدة في مركزية وأتمتة دورة الحياة تلك. بدلاً من تخمين أي تطبيق استخدم بيانات اعتماد مشتركة، يمكن لبيانات الاعتماد الفريدة أن تجعل الإسناد أسهل.
لكن Vault يخلق اختبار المخرجات المعتمدة الخاص به. المخرج المفيد ليس "تم إصدار سر". إنه "تلقى المدير الصحيح السر الصحيح للمدة الصحيحة، وقامت الخدمة المستهلكة بتجديده أو استبداله بشكل صحيح، ومسار التدقيق مفيد، ويعمل الإبطال عندما يجب أن تنتهي السلطة". إذا انتهت صلاحية عقد إيجار أثناء النشر لأن تطبيقًا لا يجددها، فقد يفشل تغيير البنية التحتية. إذا تسبب تدوير بيانات اعتماد جذر في كسر المستخدمين الديناميكيين، يصبح تحسين الأمان انقطاعًا. إذا كانت السياسات واسعة جدًا، يمكن لـ Vault مركزية الإفراط في الإذن بدلاً من تقليله.
يبقى العمل البشري جادًا. يجب على المشغلين تكوين أساليب المصادقة والمسارات والسياسات والتخزين والنسخ المتماثل وأجهزة التدقيق والنسخ الاحتياطي والاستعادة ونوافذ التدوير والوصول في حالات الطوارئ. يجب على فرق التطبيقات التعامل مع التجديد والفشل. يجب على فرق الأمان مراجعة مدة عقد الإيجار وإجراءات الإبطال. يجب على فرق المنصة تنسيق Terraform و Vault وهوية السحابة بحيث يمكن للتطبيق الحصول على السلطة دون ترك بيانات اعتماد دائمة وراءه.
لهذا السبب يعزز Vault أطروحة التغيير المعتمد لـ HashiCorp. تغيير البنية التحتية ليس فقط عن الموارد. إنه عن من يمكنه إجراء التغيير وأي الأسرار تنجو منه. تمتلك محفظة HashiCorp قصة متماسكة عندما يتم التعامل مع Terraform و Vault كأجزاء من مشكلة تحكم واحدة. تصبح أضعف عندما يتم شراء Vault كمشروع أسرار منفصل دون تغيير كيفية إصدار سلطة البنية التحتية وإنهائها.
المحفظة الأوسع مفيدة فقط إذا بقيت عادية
محفظة HashiCorp الأوسع مهمة لأن تغيير البنية التحتية لا يتوقف عند التزويد. يغطيConsulشبكات الخدمات والاكتشاف وشبكة الخدمة وإدارة حركة المرور وأمان خدمة إلى خدمة. يغطيBoundaryالوصول المدرك للهوية إلى البنية التحتية، مع وصول في الوقت المناسب وضوابط الجلسة. يبنيPackerصور آلات متطابقة لمنصات متعددة من تكوين مصدري واحد. يبقى Nomad جزءًا من قصة تشغيل HashiCorp لجدولة أعباء العمل، على الرغم من أن هذه المقالة مركزة على Terraform و HCP Terraform و Vault.
الإغراء التجاري هو تحويل هذا إلى قصة منصة كبرى. هذا أقل فائدة من السؤال الأصغر: هل يجعل كل منتج نقطة تحكم عادية أسهل في القبول؟ يكون Packer قيمًا عندما تكون الأثر المقبول هو صورة آلة يكون مصدرها ومدخلات بنائها واستخدامها النهائي قابلين للتتبع. يكون Consul قيمًا عندما تكون حالة الشبكة المقبولة هي كتالوج خدمة ومسار قائم على الهوية بدلاً من عناوين تتم صيانتها يدويًا. يكون Boundary قيمًا عندما يتم منح الوصول المقبول من خلال الهوية والسياسة بدلاً من الحصون المشتركة وبيانات الاعتماد الثابتة واستثناءات VPN غير الرسمية. يكون Vault قيمًا عندما تكون السلطة المقبولة مؤجرة وقابلة للتدقيق.
تعزز المنتجات بعضها البعض نظريًا. يمكن لـ Terraform تزويد البنية التحتية. يمكن لـ Packer إنتاج الصور التي تستهلكها البنية التحتية. يمكن لـ Vault إصدار الأسرار. يمكن لـ Consul مساعدة الخدمات في العثور على بعضها البعض وفرض اتصالات الخدمة. يمكن لـ Boundary تقليل توزيع بيانات الاعتماد المباشر للوصول البشري. معًا تدعم الانتقال من أعمال البنية التحتية المدارة بشكل فردي إلى نموذج تشغيل أكثر اتساقًا.
الخطر هو جاذبية التكدس. العميل الذي يتبنى منتج HashiCorp واحد قد يتم تشجيعه نحو عدة منتجات. يمكن للتكامل أن يقلل الاحتكاك، لكنه يمكن أيضًا أن يزيد الاعتماد على رؤية بائع واحد لعمل البنية التحتية. بعد استحواذ IBM، أصبح هذا الاعتماد الآن جزءًا من محفظة برمجيات مؤسسية أكبر. سيرحب بعض المشترين بذلك لأن مشتريات IBM ودعمها وموقعها السحابي الهجين تناسب بيئتهم. سيدرس آخرون ما إذا كان الاستحواذ يغير التسعير أو خريطة الطريق أو ثقافة الدعم أو الانفتاح.
تاريخ الترخيص يشحذ هذا السؤال. تشرحأسئلة ترخيص HashiCorp الشائعةانتقالها إلى ترخيص مصدر الأعمال، مما أدى إلىOpenTofu، وهو مشروع مؤسسة Linux يقدم نفسه كبديل مفتوح المصدر لـ Terraform.وثائق OpenTofuلديها نموذج كتابة وخطة وتطبيق مماثل وقصة بنية تحتية ككود موجهة نحو المزودين. هذا لا يعني أن كل عميل HashiCorp يمكنه التبديل بسهولة. سير العمل المستضاف وإنفاذ السياسة والحالة والسجلات الخاصة والدعم والميزات المؤسسية وممارسة الموظفين كلها مهمة. لكنه يعني أن المشتري لديه بديل حقيقي للتقييم.
يجب أن تشمل اقتصاديات التغيير المعتمد هذه الاختيارية. يجب على المشتري ألا يسأل فقط "هل تعمل HashiCorp؟" ولكن "كم سيكلف المغادرة؟" قد تكون الإجابة مقبولة. يمكن أن يكون نشر ناضج لـ HCP Terraform و Vault يستحق القفل التجاري إذا قلل من المخاطرة أكثر مما يخلق. لكن يجب على المشتري أن يصدر هذا الحكم بشكل صريح، قبل أن تجعل بنية الوحدات والحالة والسياسة والأسرار الخروج مكلفًا.
يجب حساب التسعير لكل تغيير معتمد
تسردأسعار HCP Terraformالعامة فئات قائمة على الموارد: Essentials و Standard و Premium، بأسعار شهرية مختلفة لكل مورد، وتسعير مخصص للنشر المؤسسي المدار ذاتيًا. هذا مفيد، لكنه ليس القاسم الاقتصادي. سعر المورد المدار لا يخبر المشتري كم يكلف تغيير بنية تحتية معتمد واحد.
لنأخذ فريقًا يدير 10,000 مورد. بسعر قائمة Standard العام البالغ 0.47 دولار لكل مورد شهريًا، فإن مكون الموارد وحده حوالي 4,700 دولار شهريًا قبل شروط العقد والضرائب والدعم وتكلفة التنفيذ الخاص ورسوم السحابة والعمالة. إذا أكمل الفريق 1,000 تغيير معتمد في الشهر، فإن مكون الموارد البسيط أقل من خمسة دولارات لكل تغيير معتمد. إذا أكمل 50 تغييرًا معتمدًا، فإن نفس مكون الموارد أعلى بكثير لكل تغيير. لا يشمل أي من الرقمين وقت المراجعة أو الخطط الفاشلة أو إعادة العمل على السياسة أو تنظيف الانحراف أو صيانة الوحدات أو اختبار المزودين أو التدريب أو تكلفة الحوادث.
لهذا السبب يمكن أن يبدو تسعير الموارد إما رخيصًا أو مكلفًا اعتمادًا على النضج التشغيلي. في بيئة عالية التغيير، تتوزع تكلفة المنصة عبر العديد من الإجراءات المراجعة. في بيئة منخفضة التغيير مع نظافة وحدات سيئة، قد يدفع المشتري مقابل آلات حوكمة دون عمل متكرر كافٍ لتبريرها. في بيئة منظمة، قد تكون التكلفة لا تزال مبررة بقابلية التدقيق وتقليل المخاطر حتى لو كان عدد التغييرات الخام منخفضًا. في فريق صغير مع استخدام سحابي بسيط، قد يكون Terraform المحلي أو أداة سحابية أصلية كافية.
القياس الأكثر صدقًا هو التكلفة لكل مخرج معتمد. بالنسبة لـ Terraform و HCP Terraform، يعني ذلك عد الخطط المقترحة والخطط المرفوضة والخطط المعاد العمل عليها والتطبيقات المكتملة والتطبيقات الفاشلة والحوادث المنشأة ونتائج الانحراف وإصلاحات الحالة وتجاوزات السياسة والدقائق البشرية. بالنسبة لـ Vault، عد الأسرار المصدرة والتجديدات الفاشلة والإبطالات المنفذة وحوادث التدوير وطلبات التدقيق المستوفاة. بالنسبة للمحفظة الأوسع، عد الصور المقبولة وتسجيلات الخدمة المقبولة وجلسات الوصول المقبولة.
تظهر قصص العملاء لماذا يمكن أن يكون هذا قيمًا. تقول HashiCorp إنDeutsche Bankبنت منصة بآلاف المطورين ومئات التطبيقات ومئات السياسات ومئات آلاف تشغيلات Terraform والعديد من مناطق الهبوط. تقول HashiCorp إنCieloنقلت تسليم البنية التحتية من حوالي شهر إلى أقل من 15 دقيقة وخفضت الوقت المستغرق في طلبات التغيير. هذه إشارات ذات مغزى لأنها تصف عملًا عاديًا متكررًا، وليس عرضًا واحدًا. لا تزال هذه قصصًا منشورة من البائع. يجب على المشترين معاملتها كأمثلة لما يجب اختباره، وليس كدليل على مردودهم الخاص.
الاقتصاديات أوضح عندما تكون العملية القديمة مكلفة ومرئية. إذا كان كل بيئة جديدة تتطلب شهرًا من التنسيق اليدوي، يمكن أن تكون الوحدة القياسية مع فحوصات السياسة تحويلية. إذا كان كل تدوير سر يخلق مخاطرة تطبيق، يمكن لـ Vault تقليل التعرض وتحسين قابلية التدقيق. إذا كان كل اتصال خدمة يتطلب تحديثات عناوين يدوية، فقد يقلل Consul من تكلفة التنسيق. إذا كانت العملية القديمة منضبطة ومؤتمتة وضيقة بالفعل، يجب على HashiCorp التغلب على معيار أعلى.
للفشل ملاك
تغير أتمتة البنية التحتية من يتحمل عواقب الفشل. يمكن إلقاء اللوم في تغيير يدوي على لوحة تحكم سحابية على مشغل، لكنه قد يكشف أيضًا عن عملية ضعيفة. يمكن إلقاء اللوم في فشل Terraform على مؤلف وحدة أو مراجع أو مزود أو API سحابة أو مالك حالة أو استثناء سياسة أو الشخص الذي نقر تطبيق. يمكن أن ينتمي فشل Vault إلى مصمم سياسة أو فريق تطبيق أو مشغل تخزين أو مالك تدوير أو مستجيب حادث. يجعل النظام السببية أكثر قابلية للتتبع، لكن ليس دائمًا أبسط.
أنماط الفشل المعروفة عادية وخطيرة. يمكن أن يتسبب انحراف الحالة في مفاجأة خطة للمراجعين. يمكن أن يكسر إصدار مزود السلوك. يمكن أن تبدو خطة مدمرة روتينية إذا ركز المراجعون على الجزء الخطأ. يمكن تجاوز سياسة أو تجاوزها للراحة. يمكن أن يفشل تدوير سر في أسوأ وقت. يمكن أن تتناثر مساحات العمل حتى لا يعرف أحد الملكية. يمكن أن تصبح الوحدات مخاطرة سلسلة توريد. يمكن أن يفشل الاسترجاع لأن Terraform يستعيد التكوين المعلن لكنه لا يستطيع استعادة البيانات المفقودة أو الآثار الجانبية الخارجية. يمكن أن يخلق صراع التفرع وقفل البائع شكًا استراتيجيًا.
من يتحمل كل نتيجة؟ إذا دمرت قاعدة بيانات سحابية بخطة معتمدة، يتحمل العميل الانقطاع حتى لو ساهم سلوك مزود. إذا انتهت صلاحية سر وفشل النشر، يمتلك العميل تأثير الخدمة حتى لو فرض Vault عقد الإيجار بشكل صحيح. إذا منعت سياسة إصلاح طارئ صالح، تمتلك المؤسسة التأخير. إذا ترك إلغاء قسري موارد متروكة، يجب على مسؤول مساحة العمل وفريق المنصة إصلاح الحالة. يمكن لـ HashiCorp توفير الأدوات والدعم، لكن العميل يمتلك البيئة.
لهذا السبب يستحق الاسترجاع قراءة رصينة. يمكن لـ Terraform استبدال الموارد وتطبيق التكوين السابق وتحديث الحالة. لا يمكنه ضمان أن خدمة سحابية تستعيد البيانات، أو أن SaaS خارجي يعكس أثرًا جانبيًا، أو أن هوية محذوفة يمكن إعادة إنشائها بنفس العلاقات النهائية، أو أن فتح شبكة قصير لم يتسبب في ضرر. لذلك يجب أن يتضمن التغيير المعتمد للبنية التحتية فرضية استرداد قبل التطبيق، وليس بعد الفشل.
للتغييرات الحرجة، يجب على المشتري أن يسأل ثلاثة أسئلة. أولاً، ماذا ستدمر هذه الخطة أو تستبدل أو تجعل غير قابل للوصول؟ ثانيًا، ما الدليل الذي سيثبت أن التطبيق نجح في البيئة الحقيقية؟ ثالثًا، ما الإجراء الدقيق الذي سيستعيد إذا كانت النتيجة خاطئة؟ إذا كانت هذه الإجابات مفقودة، فإن التغيير ليس معتمدًا بعد، حتى لو نجحت كل سياسة.
يمكن لسطوح منتج HashiCorp المساعدة في الإجابة عن هذه الأسئلة من خلال جعل الخطط وحالات التشغيل ونتائج السياسة والحالة والأسرار مرئية. لا يمكنها جعل مؤسسة تهتم بالإجابات. يبقى ذلك الجزء البشري من النظام.
كيف يجب على المشترين اختبار HashiCorp
التقييم الصحيح هو مجموعة معنونة من التغييرات العادية، وليس عرض شرائح. اختر مهامًا حقيقية ولكن منخفضة المخاطر: أضف وسمًا إلى مورد متحكم به، أنشئ بيئة غير حرجة، دور بيانات اعتماد قاعدة بيانات في نظام اختبار، استورد موردًا موجودًا، اكتشف انحرافًا متعمدًا، امنع انتهاك سياسة، حدث إصدار مزود، ألغ تشغيلاً، تجاهل خطة، وتعاف من تطبيق فاشل في صندوق رمل.
لكل مهمة، سجل الخطة المقترحة وقرار المراجع ونتيجة السياسة ومخرج التطبيق وتغيير الحالة وسلوك السر والوقت البشري وإعادة العمل والاستثناء والاسترداد. عد الخطط المرفوضة بجدية مثل الخطط المعتمدة. الخطة المرفوضة التي تمنع الضرر هي مخرج مفيد. الخطة المرفوضة التي تطلبت ساعتين من الشرح قد لا تكون كذلك. الخطة المعتمدة بسرعة ولكن يتبعها حادث خفي مكلفة.
يجب أن يشمل التقييم البدائل. العمل اليدوي على لوحة التحكم السحابية هو خط الأساس في العديد من الفرق، لكنه ليس الوحيد. يمكن لمنصة داخلية أن تغلف APIs السحابة مباشرة. يمكن لـ OpenTofu الحفاظ على ممارسة البنية التحتية ككود تحت نموذج حوكمة مفتوح. يمكن أن تكون أدوات النشر السحابية الأصلية أبسط للبيئات السحابية المفردة. يمكن لإدارة خدمات تكنولوجيا المعلومات التقليدية الحفاظ على تدفق الموافقة ولكن لا تحل مشكلة الحالة. يمكن لمنصة SaaS أوسع أن تجمع بين ميزات السياسة والتكلفة والانحراف ولكنها قد تقدم مستوى تحكم آخر. تفوز HashiCorp فقط إذا تغلب سجل التغيير المعتمد الخاص بها على هذه البدائل تحت قيود المشتري.
يجب أن يشمل الاختبار أيضًا شروط نشر العميل. هل تمتلك المؤسسة قدرة هندسة منصة كافية لامتلاك الوحدات والحالة؟ هل يمتلك الأمان القدرة على كتابة وصيانة السياسات؟ هل فرق السحابة مستعدة لإيقاف التغييرات اليدوية أو تسويتها بشكل صحيح؟ هل فرق التطبيقات مستعدة لقراءة الخطط؟ هل تفهم المالية التسعير القائم على الموارد؟ هل يهتم التدقيق بالجداول الزمنية للتشغيل وسجلات Vault؟ هل تقبل المشتريات دور IBM؟ هل هناك مسار ترحيل إذا أصبح OpenTofu أو أداة أخرى أكثر جاذبية؟
هذه الشروط أكثر أهمية من العروض التوضيحية للمنتج. شركة ذات عادات منصة قوية يمكن أن تجعل HashiCorp تبدو ممتازة لأن الأداة تضخم الانضباط. شركة ذات ملكية ضعيفة يمكن أن تجعل نفس الأداة تبدو بيروقراطية لأن كل خطة فاشلة تصبح تذكرة منصة وكل سياسة تصبح جدالاً. المنتج لا يمحو التصميم التنظيمي.
الحقائق غير المحلولة التي ستغير الحكم عملية. لا تنشر HashiCorp معدل تغيير معتمد تمثيلي. لا تنشر معدلات نجاح الاسترجاع على مستوى العملاء. لا يكشف التسعير العام عن خصومات العقود أو تكلفة الدعم الكاملة. لا تظهر دراسات حالة البائع التشغيلات الفاشلة أو التغييرات المرفوضة أو الحوادث. تبقى تكلفة الترحيل إلى OpenTofu لعميل HCP Terraform ناضج خاصة بالبيئة. تعتمد موثوقية Vault بشكل كبير على سلوك النشر والتطبيق. هذه الأمور المجهولة ليست أسبابًا لرفض HashiCorp. إنها أسباب لقياسها بشكل صحيح.
الحكم
أقوى ادعاء لـ HashiCorp ليس أنها اخترعت أتمتة البنية التحتية مرة واحدة ولا تزال تمتلك الفئة بالعادة. أقوى ادعاء لها هو أن تغيير البنية التحتية يحتاج إلى قواعد تشغيل دائمة: التكوين والخطة والسياسة والحالة والسلطة السرية والتطبيق واكتشاف الانحراف والتعافي. جعل Terraform هذه القواعد مألوفة. يحول HCP Terraform المزيد منها إلى نظام تشغيل مشترك. يمنح Vault السلطة دورة حياة. توسع المنتجات المحيطة نفس الفكرة لتشمل الصور وشبكات الخدمات والوصول.
هذا موقع قيم لأن البيئات السحابية أصبحت معقدة للغاية بالنسبة لذاكرة لوحة التحكم وذات عواقب كبيرة جدًا بالنسبة للنصوص البرمجية العارضة. كلما زاد عدد السحب والفرق والوحدات وبيانات الاعتماد لدى الشركة، زادت حاجتها إلى طريقة لجعل التغييرات العادية قابلة للمراجعة. تمنح HashiCorp المشترين طريقة ناضجة للقيام بذلك، مع أدلة قوية في الوثائق وقصص عملاء مختارة على أن النمط يتسع.
الخطر هو أن يخلط المشترون بين القواعد الناضجة والجملة المنتهية. يمكن لـ Terraform إنتاج خطة لا يقرأها أحد جيدًا. يمكن لـ HCP Terraform إيقاف تشغيل يوافق عليه الشخص الخطأ. يمكن لسياسة أن تمنع مخاطرة الأمس وتفوت مخاطرة الغد. يمكن أن تصبح الحالة مخزن سلطة هشًا. يمكن لـ Vault مركزية الأسرار بينما يكشف عن تبعية تشغيلية جديدة. يمكن لـ OpenTofu خلق قوة تفاوضية بينما يضيف أسئلة ترحيل. يمكن لملكية IBM أن تساعد المشتريات والدعم لبعض العملاء بينما تشحذ مخاوف القفل التجاري للآخرين.
لذلك فإن التغيير المعتمد للبنية التحتية هو الاختبار العادل الوحيد. إذا سمحت HashiCorp لفريق بشحن تغييرات متكررة بخطوات يدوية أقل ومراجعة أوضح وتحكم أفضل في الحالة وسلطة سرية أكثر أمانًا واكتشاف أسرع للانحراف وتعافٍ قابل للقياس، فهي تستحق أموالاً جادة. إذا كانت فقط تنقل عدم اليقين اليدوي إلى وحدات وسياسات وملفات حالة لا يمتلكها أحد، تصبح طبقة أخرى من البيروقراطية السحابية.
يجب ألا يسأل المشتري ما إذا كان بإمكان HashiCorp أتمتة البنية التحتية. يمكنها ذلك. يجب أن يسأل المشتري كم عدد تغييرات البنية التحتية التي تصبح معتمدة، وكم عدد المرفوضة للأسباب الصحيحة، وكم عدد التي تفشل بعد الاعتماد، ومدى سرعة العثور على الانحراف، وكم مرة تتصرف الأسرار كما هو مقصود، وكم تبقى من عمل المراجعة، وكم سيكلف المغادرة. هذه هي بطاقة أداء HashiCorp الحقيقية.