قدمت AWS مؤخرًا وضع CloudFormation السريع، وهو خيار نشر يمكنه تقليل أوقات نشر البنية التحتية عن طريق وضع علامة على اكتمال عمليات المكدس بمجرد تطبيق تكوين المورد، بدلاً من انتظار التثبيت الكامل للموارد.
في الوضع السريع، يضع CloudFormation علامة اكتمال العملية بمجرد نجاح استدعاء واجهة برمجة التطبيقات (API) للإنشاء أو التحديث أو الحذف. ونتيجة لذلك، ربما لا تزال الموارد قيد التهيئة، أو ليست جاهزة بعد لخدمة حركة المرور، أو لا تزال قيد الحذف.
لا يتطلب الخيار الجديد تغييرات في القالب، ويدعم ميزات CloudFormation الحالية مثل الحزم المتداخلة ومجموعات التغيير، وهو مخصص لسير عمل تطوير أسرع حيث لا يلزم الاستعداد الفوري لحركة المرور. يؤدي تمكين الوضع Express على المكدس الأصلي إلى تطبيق الوضع Express تلقائيًا على جميع الأكوام المتداخلة. كتب تشاني يون، المدافع الرئيسي عن المطورين في AWS:
يستفيد الوضع السريع من حالتين استخدام أساسيتين: سير عمل التطوير التكراري وسيناريوهات الإنتاج حيث تشعر بالارتياح تجاه التثبيت النهائي. تتضمن حالات الاستخدام هذه التكرار على تكوينات البنية التحتية أثناء التطوير، واختبار المكونات الفردية لتطبيقك، وتطوير البنية التحتية بمساعدة الذكاء الاصطناعي التي تستفيد من حلقات التعليقات التي لا تزيد عن دقيقة واحدة.
حتى الآن، كانت كل عملية نشر لـ CloudFormation تتضمن فحوصات تثبيت إلزامية بعد تكوين الموارد للتأكد من استعدادها للتعامل مع حركة المرور قبل نقلها. لا يعد الوضع السريع CloudFormation هو الوضع الافتراضي ويتم تمكينه في AWS CLI باستخدام الخيار التالي:
--deployment-config '{"mode": "EXPRESS"}'
وفقًا للإعلان، يستغرق إنشاء قائمة انتظار SQS مع قائمة انتظار الأحرف الميتة أكثر من دقيقة في الوضع القياسي ولكن أقل من 10 ثوانٍ في الوضع السريع. وبالمثل، فإن حذف وظيفة Lambda مع مرفقات واجهة الشبكة يستغرق من 20 إلى 30 دقيقة إلى ثوانٍ. ويضيف يون:
إذا كنت تريد أن تكون الموارد جاهزة للعمل بكامل طاقتها قبل متابعة حركة المرور أو الاختبار، فتابع استخدام سلوك النشر الافتراضي، الذي يقوم بإجراء عمليات التحقق من التثبيت قبل الاكتمال.
كان الاحتكاك التشغيلي الناتج عن انتظار عمليات نشر CloudFormation بمثابة شكوى طويلة الأمد من مجتمع AWS، حيث قال العديد من المطورين في الماضي إنهم يفضلون Terraform بسبب التجربة. على LinkedIn، يقول يان كوي، AWS Hero والخبير في مجال الخدمات غير الخادمة:
يعد وضع CloudFormation Express الجديد مفيدًا لبيئات التطوير (…)، لكنني لا أتفق مع إطار الذكاء الاصطناعي “تطوير البنية التحتية بمساعدة الذكاء الاصطناعي الذي يستفيد من حلقات ردود الفعل التي لا تزيد عن دقيقة واحدة”. لقد كانت حلقة ردود الفعل السريعة مهمة دائمًا! وهذا هو السبب الرئيسي وراء تفضيل الكثيرين لـ Terraform على CloudFormation لسنوات. لا يختلف الوقت المستغرق في انتظار انتهاء نشر CloudFormation عن الوقت المستغرق في انتظار انتهاء وكيل الذكاء الاصطناعي.
بينما يشيد ممارسون آخرون بالخيار الجديد، إلا أنهم يسلطون الضوء على المفاضلات. يحذر Michał Piszczek، الرئيس التنفيذي للتكنولوجيا في Archdesk:
التراجع معطل افتراضيًا هو التفاصيل التي سيتخطاها الأشخاص. يعد هذا أمرًا جيدًا بالنسبة لوكلاء الذكاء الاصطناعي الذين يقومون بتوفير مكدسات سريعة، وهو أمر محفوف بالمخاطر بالنسبة لأي شيء يتعين على الإنسان تصحيحه في الساعة 3 صباحًا.
في إعلان منفصل، قامت AWS أيضًا بتوسيع نطاق التحقق من صحة ما قبل النشر لـ CloudFormation ليتم تشغيله تلقائيًا في كل عملية إنشاء وتحديث مكدس، مما يساعد على اكتشاف أخطاء القالب قبل توفير الموارد. يقدم التحديث أيضًا عمليات تحقق إضافية من الصحة، وأمر cdk validate جديد لمشروعات AWS CDK، وخيارًا لتعطيل التحقق من الصحة لعمليات نشر محددة عند الحاجة.
يتوفر كل من الوضع السريع والتحقق الجديد في جميع المناطق التي يتم فيها دعم CloudFormation، دون الحاجة إلى الاشتراك ودون تكاليف إضافية.
