هندسة معمارية لا خادمية أولاً (Serverless-First Architecture)

لا يناسب serverless-first جيدًا العمليات طويلة الأمد التي تتجاوز 15 دقيقة، وأعباء العمل التي تتطلب اتصالات WebSocket مستمرة، والتطبيقات ذات حركة المرور العالية والمستمرة حيث تكون السعة المحجوزة أرخص، والأنظمة التي تحتاج إلى تكوين OS أو شبكة على مستوى منخفض. تقوم MicrocosmWorks بتقييم كل عبء عمل مقابل هذه القيود أثناء تصميم البنية وتوصي بأساليب هجينة حيث يتعامل serverless مع نقاط نهاية API ومعالجة الأحداث بينما تقوم containers أو VMs بتشغيل أعباء العمل التي تحتاج إلى persistent compute. يتجنب هذا النهج العملي الخطأ الشائع المتمثل في إجبار كل مكون على serverless عندما لا يكون مناسبًا.

تخفف MicrocosmWorks من Lambda cold starts من خلال provisioned concurrency لـ critical endpoints، وfunction bundle optimization لتقليل initialization time، والاستخدام الاستراتيجي لـ Lambda SnapStart لـ Java workloads الذي يقلل من cold starts من ثوانٍ إلى ميلي ثانية. كما نقوم بتصميم applications بحيث تستخدم latency-sensitive paths lightweight runtimes مثل Node.js أو Python مع minimal dependencies، مع الحفاظ على cold starts أقل من 200ms حتى بدون provisioned concurrency. لـ endpoints حيث يكون حتى هذا latency غير مقبول، نستخدم Lambda@Edge أو CloudFront Functions لـ sub-10ms responses.

تقوم MicrocosmWorks بإعداد بيئات التطوير المحلية باستخدام أدوات مثل SST (Serverless Stack) أو LocalStack أو وضع عدم الاتصال (offline mode) لـ Serverless Framework، التي تحاكي الخدمات السحابية على جهاز المطور بدقة قريبة من الإنتاج. نحن نطبق مجموعات اختبار التكامل التي تعمل مقابل بيئات سحابية مؤقتة يتم تشغيلها لكل pull request، بحيث يمكن للمطورين التحقق مقابل خدمات AWS الحقيقية دون مشاركة بيئة اختبار (staging environment). يوفر هذا النهج المزدوج حلقات تكرار محلية سريعة للتطوير مع اكتشاف المشكلات الخاصة بالسحابة قبل أن يصل الكود إلى الإنتاج.

وجدت MicrocosmWorks أن serverless أرخص بكثير للتطبيقات ذات أنماط حركة المرور المتغيرة أو المتذبذبة—غالبًا ما تكون أقل بنسبة 70-90% من عمليات نشر الـ containers المكافئة التي تعمل دائمًا—ولكن الميزة التنافسية للتكلفة تضيق عند مستويات الإنتاجية المستدامة التي تتجاوز 10-20 مليون استدعاء شهريًا. نقوم ببناء نماذج لتوقع التكلفة أثناء تصميم البنية تقارن تسعير serverless لكل استدعاء مقابل سعة الـ container المحجوزة لأنماط حركة المرور الخاصة بك، بما في ذلك التكاليف الخفية مثل رسوم API Gateway ورسوم نقل البيانات. خدمة التحسين لدينا، والمتاحة بأسعار استشارية تتراوح بين 10-35 دولارًا في الساعة، تراجع فواتير serverless بانتظام لتحديد الهدر الناتج عن الذاكرة المخصصة بشكل زائد، أو مدة تشغيل الوظائف المفرطة، أو الاستخدام غير الضروري لـ API Gateway.

تستخدم MicrocosmWorks وكلاء تجميع الاتصالات (connection pooling proxies) مثل Amazon RDS Proxy أو PgBouncer، يتم نشرها كطبقة دائمة بين دوال Lambda وقاعدة البيانات، والتي تضاعف آلاف اتصالات Lambda في مجموعة قابلة للإدارة من اتصالات قاعدة البيانات الفعلية. كما نصمم التطبيقات اللاخادمية لتفضيل DynamoDB أو قواعد البيانات الأخرى عديمة الاتصال (connection-less) لأعباء العمل عالية التزامن حيث سيظل تجميع الاتصالات (connection pooling) يسبب اختناقات. بالنسبة للتطبيقات التي يجب أن تستخدم قواعد البيانات العلائقية، ننفذ حدود توسيع نطاق واعية بالاتصال (connection-aware scaling limits) التي تحد من استدعاءات Lambda المتزامنة لتتناسب مع سعة اتصال قاعدة البيانات.