لماذا انتقلنا إلى الحوسبة بدون خادم لنشر الإصدارات المخصصة

نشرت: 2018-11-22
إعداد الخادم للحوسبة السحابية بدون خادم.

تصوير بانوماس نيخومخاي من Pexels

كجزء من التزامنا بتمكين المسوقين ذوي الأداء من القيام بالمزيد ، بأقل ، وبدون قلق ، تبحث الفرق في TUNE دائمًا عن طرق جديدة لخدمة عملائنا. في هذه الحالة ، اكتشف فريق هندسة الحلول لدينا تقنية تبسط كيفية نشرها ودعمها للبنيات المخصصة على نظامنا الأساسي. ونتيجة لذلك ، يمكنهم الآن قضاء المزيد من الوقت (وأموال أقل) في العمل مع المزيد من العملاء لبناء الحلول التي يحتاجون إليها.


في TUNE ، نفخر بأنفسنا لتوفير نظام أساسي مرن وشامل لتسويق الأداء يسمح للشبكات والمعلنين بإدارة حملاتهم التسويقية الرقمية ، وعلاقات الناشرين ، والمدفوعات ، وغير ذلك - مباشرة من الصندوق ، دون الحاجة إلى كتابة سطر واحد من التعليمات البرمجية . ولكن في بعض الأحيان ، كما هو الحال مع أنظمة SaaS الأخرى المُدارة بالكامل ، يحتاج عملاؤنا إلى تكوينات أو وظائف أو عمليات تكامل مخصصة لا يمكن تحقيقها إلا من خلال تشمير سواعدنا وإطلاق محرر الكود القديم. في الآونة الأخيرة ، انتقلنا إلى تقنية جديدة غيرت الطريقة التي نبني بها هذه الحلول: الحوسبة بدون خادم.

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

التحدي: مواكبة الطلب على الحلول المخصصة

عندما بدأنا فريق هندسة الحلول لأول مرة في TUNE ، تعاملنا مع كل بناء عميل مخصص كبنية منفصلة. تحتوي معظم هذه البنيات على مكون أمامي ، والذي عادة ما يتم نشره كصفحة مخصصة على نظامنا الأساسي ، ومكون خلفي يتكون من خادم وقاعدة بيانات وأي بنية أساسية أخرى مطلوبة للحفاظ على الخوادم محدثة -تاريخ والتشغيل.

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

ولكن مع زيادة عدد البنيات ، بدأنا نواجه مشكلات:

  • عدد كبير جدًا من الخوادم! كما يمكنك أن تتخيل ، أدى توفير ما لا يقل عن صندوقين لكل بناء إلى وجود عدد كبير جدًا من الخوادم. كان العدد الهائل من الخوادم وكل الآلام المصاحبة لها (مثل التحديثات الأمنية والنسخ الاحتياطية) تكلفنا وقتًا أطول مما نود أن نعترف به.
  • حافظ على هذه الخوادم. نظرًا لأن كل خادم هو كيانه الخاص ، فقد كنا مسؤولين عن التأكد من أن كل خادم يعمل دائمًا.
  • PHP ليست مناسبة لي. يتم نسج معظم تصميماتنا من صورة Docker PHP الأساسية. ولكن مع نمو فريقنا ، عرفنا أن إجبار الأشخاص على كتابة إصدارات العملاء الخاصة بهم في PHP 5.0 عندما كانوا من ساحر Python لم يكن له أي معنى.
  • هذا أصبح مكلفا. مع نشر جميع خوادمنا على ec2 / RDS ، بدأنا نرى تكلفة شهرية كبيرة.
  • السلامة اولا. نظرًا لأن هذه الخدمات تتعامل مع بيانات العملاء الحساسة ، كان علينا توفير طريقة مصادقة لعناوين URL العامة لضمان أمان تلك البيانات.
  • Crons صعبة. تتألف الكثير من الخدمات الخلفية من نصوص cron النصية ، ولم يكن لدينا طريقة فعالة لإدارة هذه البرامج.

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

الحل: الحوسبة بدون خادم إلى الإنقاذ

إذا لم تكن قد سمعت عن الحوسبة بدون خادم ، فقد تتساءل عن نفس الشيء الذي كنا عليه عندما سمعنا عنها لأول مرة. كيف يمكنك تنفيذ التعليمات البرمجية بدون خادم؟ (لا تقلق ؛ لا يزال فهمك الأساسي للبرمجة صحيحًا ، ولا ، لم نقم بإساءة استخدام الساعة السعيدة الخاصة قبل كتابة هذا.)

"Serverless" مصطلح محير حقًا لتقنية جديدة ، لأنه - دعونا لا نكون سخيفين - لا يزال هناك بالتأكيد خادم يقوم بتنفيذ التعليمات البرمجية. إذن ما هو بالضبط بدون خادم؟

الحوسبة بدون خادم هي نموذج تنفيذ الحوسبة السحابية حيث يعمل موفر السحابة كخادم ، ويدير بشكل ديناميكي تخصيص موارد الجهاز. - ويكيبيديا

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

عملية الإعداد بدون خادم

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

ملاحظة: هناك العديد من موفري الخدمات السحابية الذين لديهم وظائف بدون خادم. في هذا المثال ، نستخدم AWS Lambda .

    1. أولاً ، أنشئ وظيفة Lambda جديدة وحدد " Blueprints ". ثم اكتب " http " في حقل الكلمة الأساسية ، وحدد إما Python أو Node microservice-http-endpoint. (المخططات عبارة عن كتل تعليمات برمجية مسبقة الصياغة تهدف إلى تسريع عملية التطوير. ما مدى روعة ذلك؟) بمجرد إجراء التحديد ، انقر فوق " تكوين ".
      كيفية تكوين وظيفة على AWS Lambda.

      كيفية تكوين وظيفة على AWS Lambda.

    2. أضف اسم الوظيفة والدور. ثم حدد مشغل بوابة واجهة برمجة التطبيقات مع خيار الأمان " فتح باستخدام مفتاح واجهة برمجة التطبيقات ". ستوفر بوابة واجهة برمجة التطبيقات عنوان URL عامًا يؤدي إلى تشغيل وظيفة Lambda الخاصة بك. توفر إضافة مفتاح API طريقة مصادقة ، يوصى بها بشدة.
      إعداد مفتاح بوابة API مفتوح في AWS Lambda.

      إعداد مفتاح بوابة API مفتوح في AWS Lambda.

    3. بمجرد إنشاء الوظيفة ، يمكنك الآن إجراء تكوينات على التعليمات البرمجية الخاصة بك. كما ترى ، فقد منحك المخطط بالفعل خطاف نقطة دخول رائعًا يسمح لك بالتفاعل مع جدول Dynamo (إذا كنت تبحث عن إضافة قاعدة بيانات). كل ما هو موجود تحت lambda_handler سيتم تنفيذه عند تحميل عنوان URL العام. نظرًا لأننا نضيف أيضًا قاعدة بيانات ، فلننتقل إلى Dynamo وننشئ واحدة.
      إنشاء جدول قاعدة بيانات Dynamo في AWS Lambda.

      إنشاء جدول قاعدة بيانات Dynamo في AWS Lambda.

    4. بمجرد إنشاء جدول Dynamo ، دعنا نتصل بوظيفة Lambda هذه من عنوان URL عام. ارجع إلى وظيفتك وانقر على أيقونة " API Gateway " في الأعلى. يجب أن ترى أنه تم بالفعل إنشاء نقطة النهاية ومفتاح واجهة برمجة التطبيقات من أجلك.
      أين يمكن العثور على رمز API Gateway في وظائف AWS Lambda.

      أين يمكن العثور على رمز API Gateway في وظائف AWS Lambda.

    5. افتح الآن المحطة الطرفية وأضف مفتاح API تحت عنوان " x-api-key" ، ثم أضف اسم الجدول الذي أنشأته ضمن معلمة TableName سلسلة الاستعلام.
      أدخل مفتاحك واسم قاعدة البيانات في الجهاز لإنهاء إعداد البنيات بدون خادم في AWS Lambda.

      أدخل مفتاحك واسم قاعدة البيانات في الجهاز للإنهاء.

هذا هو! لديك الآن نهاية خلفية عاملة وآمنة متصلة بقاعدة بيانات. كل ما تطلبه الأمر هو خمس خطوات سهلة.

كيف تعاملت الحوسبة بدون خادم مع تحدياتنا

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

  • عدد كبير جدًا من الخوادم! بدون خادم ... مما يعني عدم وجود المزيد من الخوادم ، أليس كذلك؟
  • حافظ على هذه الخوادم. نظرًا لأن الحوسبة بدون خادم تتم إدارتها بواسطة موفر الخدمات السحابية ، يمكنك الاستفادة من وجود هؤلاء المزودين (جنبًا إلى جنب مع أساليبهم المشددة والمثبتة في المعركة) لمراقبة الخوادم الخاصة بك. لأولئك منكم الذين يرغبون في لعب Sherlock Holmes ، يمكنك أيضًا رؤية جميع سجلات الخادم الناتجة عن وظيفتك على Cloudwatch .
  • PHP ليست مناسبة لي. تسمح لك النماذج التي لا تحتوي على خادم بالكتابة بلغة C # و Python و NodeJS و Go وحتى Java.
  • هذا أصبح مكلفا. مع الحلول التي لا تحتاج إلى خادم ، يتم قياس التكاليف بناءً على وقت التنفيذ (لكل 100 مللي ثانية) وكمية البيانات المنقولة. على عكس الدفع شهريًا ، والذي يتضمن الوقت الذي تظل فيه خوادمك في وضع الخمول ، فأنت تدفع فقط مقابل ما تستخدمه. مع تكاليف منخفضة تصل إلى 0.000000208 دولار لكل 100 مللي ثانية من التنفيذ ، يمكن أن توفر لك الحوسبة بدون خادم جزءًا كبيرًا من النقود.
  • السلامة اولا. هل الخادم غير آمن؟ مع نظام مصادقة مفتاح API مدمج ، أنت تراهن على ذلك.
  • Crons صعبة. باستخدام نظام إدارة cron الذي تم إنشاؤه أصلاً على Cloudwatch ، ما عليك سوى تعيين نافذة زمنية ونسيانها. تتعامل Cloudwatch مع جميع عمليات التسجيل والتنفيذ.

افكار اخيرة

بالنسبة لفريق هندسة الحلول هنا في TUNE ، كان الانتقال إلى الحوسبة بدون خادم بمثابة تغيير لقواعد اللعبة. لقد غيرت سهولة الاستخدام ، والتوفير في التكاليف ، والميزات المرنة الملائمة الطريقة التي نتعامل بها مع جميع العملاء الجدد. تم إعداد الحلول المستندة إلى السحابة بدون خادم لتغيير عالم الحوسبة من جانب الخادم. لا أعرف عنك ، ولكن هناك شيء واحد مؤكد: فريق TUNE Solutions Engineering جاهز.

لمعرفة المزيد حول منصة TUNE وخدمات التطوير المخصصة التي نقدمها ، تفضل بزيارة صفحة الخدمات الاحترافية .