على الرغم من أن التقنيات التي لا تحتاج إلى خادم اكتسبت شعبية كبيرة في السنوات الأخيرة ، لا يزال هناك العديد من المفاهيم الخاطئة والمخاوف المرتبطة بها. الاعتماد على البائع ، والأدوات ، وإدارة التكلفة ، والبدء البارد ، والمراقبة ، ودورة حياة التطوير كلها مواضيع ساخنة عندما يتعلق الأمر بالتقنيات التي لا تحتاج إلى خادم. في هذه المقالة ، سوف نستكشف بعض الموضوعات المذكورة ، بالإضافة إلى مشاركة النصائح والروابط لمصادر المعلومات المفيدة لمساعدة المبتدئين في إنشاء تطبيقات بدون خادم قوية ومرنة وفعالة من حيث التكلفة.
المفاهيم الخاطئة حول تقنيات Serverless
يعتقد الكثير من الناس أن المعالجة بدون خادم وبدون خادم (، FaaS) هي نفس الشيء تقريبًا. هذا يعني أن الاختلاف ليس كبيرًا جدًا ويستحق تقديم حداثة. على الرغم من أن AWS Lambda كان أحد النجوم في ذروة عصر عدم الخوادم وأحد العناصر الأكثر شيوعًا في بنية عدم الخوادم ، إلا أن هذه البنية أكثر بكثير من FaaS.
المبدأ الأساسي وراء التقنيات الخالية من الخوادم هو أنه لا داعي للقلق بشأن إدارة البنية التحتية الخاصة بك وتوسيع نطاقها ، فأنت تدفع فقط مقابل ما تستخدمه. تتوافق العديد من الخدمات مع هذه المعايير - AWS DynamoDB و S3 و SNS أو SQS و Graphcool و Auth0 و Now و Netlify و Firebase وغيرها الكثير. بشكل عام ، يعني عدم وجود خادم استخدام القوة الكاملة للحوسبة السحابية دون الحاجة إلى إدارة البنية التحتية وتحسينها للتوسع. وهذا يعني أيضًا أن الأمان على مستوى البنية التحتية لم يعد مصدر قلق لك ، وهي ميزة كبيرة نظرًا لصعوبة وتعقيد تلبية معايير الأمان. أخيرًا ، ليس عليك شراء البنية التحتية المقدمة لك.
يمكن اعتبار Serverless "حالة ذهنية": عقلية معينة عند تصميم الحلول. تجنب الأساليب التي تتطلب صيانة أي بنية تحتية. من خلال نهج بدون خادم ، نقضي وقتًا في حل المهام التي تؤثر بشكل مباشر على المشروع وتحقيق الفوائد لمستخدمينا: نقوم بإنشاء منطق عمل مستدام ، ونطور واجهات مستخدم ، ونطور واجهات برمجة تطبيقات قابلة للتكيف وموثوقة.
على سبيل المثال ، إذا كان من الممكن تجنب إدارة وصيانة منصة بحث نصية مجانية ، فهذا ما سنفعله. يمكن أن يؤدي هذا النهج لبناء التطبيقات إلى تسريع وقت التسويق بشكل كبير ، لأنك لم تعد بحاجة إلى التفكير في إدارة البنية التحتية المعقدة. تخلص من مسؤوليات وتكاليف إدارة البنية التحتية وركز على بناء التطبيقات والخدمات التي يحتاجها عملاؤك. دعا باتريك ديبوا هذا النهج ، تم اعتماد المصطلح في المجتمع بدون خادم. يجب النظر إلى الوظائف على أنها رابط للخدمات كوحدات قابلة للنشر (بدلاً من نشر مكتبة كاملة أو تطبيق ويب). يوفر هذا دقة لا تُصدق لإدارة النشر والتغييرات في التطبيق. إذا لم تتمكن من نشر الوظائف بهذه الطريقة ، فقد يشير ذلك إلى أن الوظائف تؤدي العديد من المهام وتحتاج إلى إعادة هيكلة.
يشعر البعض بالارتباك بسبب الاعتماد على البائع عند تطوير التطبيقات السحابية. وينطبق الشيء نفسه على التقنيات التي لا تحتاج إلى خادم ، وهذا ليس مفهومًا خاطئًا. من واقع خبرتنا ، فإن بناء تطبيقات بدون خادم على AWS ، جنبًا إلى جنب مع قدرة AWS Lambda على تجميع خدمات AWS الأخرى معًا ، هو جزء من قوة البنى بدون خادم. هذا مثال جيد على التآزر ، عندما تكون نتيجة الجمع أكثر من مجرد مجموع المصطلحات. يمكن أن تواجه محاولة تجنب التبعية للبائعين المزيد من المشاكل. عند العمل مع الحاويات ، يكون من الأسهل إدارة طبقة التجريد الخاصة بك بين موفري السحابة. ولكن عندما يتعلق الأمر بالحلول التي لا تحتاج إلى خادم ، فإن الجهد لن يؤتي ثماره ، خاصة إذا تم أخذ فعالية التكلفة في الاعتبار من البداية. تأكد من معرفة كيفية تقديم البائعين للخدمات. تعتمد بعض الخدمات المتخصصة على نقاط التكامل مع البائعين الآخرين وقد توفر إمكانية التوصيل والتشغيل خارج الصندوق. من الأسهل توفير استدعاء Lambda من نقطة نهاية واجهة برمجة تطبيقات البوابة بدلاً من تفويض الطلب إلى حاوية أو مثيل EC2. يوفر Graphcool تكوينًا سهلاً مع Auth0 ، وهو أسهل من استخدام أدوات المصادقة الخاصة بطرف ثالث.
يعد اختيار البائع المناسب لتطبيقك بدون خادم قرارًا معماريًا. عند إنشاء تطبيق ، لا تتوقع العودة يومًا ما إلى إدارة الخوادم. لا يختلف اختيار مورد السحابة عن اختيار استخدام الحاويات أو قاعدة البيانات أو حتى لغة البرمجة.
يعتبر:
- ما هي الخدمات التي تحتاجها ولماذا.
- ما هي الخدمات التي يقدمها مقدمو الخدمات السحابية وكيف يمكنك دمجها مع حل FaaS الذي اخترته.
- ما هي لغات البرمجة المدعومة (مع الكتابة الديناميكية أو الثابتة ، المترجمة أو المفسرة ، ما هي المعايير ، ما هو الأداء عند البداية الباردة ، ما هو النظام البيئي مفتوح المصدر ، وما إلى ذلك).
- ما هي متطلبات الأمان الخاصة بك (SLA ، 2FA ، OAuth ، HTTPS ، SSL ، وما إلى ذلك).
- كيفية إدارة دورات تطوير البرامج والبرامج و CI / CD.
- ما هي حلول البنية التحتية كرمز يمكنك الاستفادة منها.
إذا قمت بتوسيع تطبيق موجود وإضافة وظائف بدون خادم بشكل متزايد ، فقد يحد هذا من الإمكانات المتاحة إلى حد ما. ومع ذلك ، توفر جميع التقنيات التي لا تحتوي على خادم تقريبًا نوعًا من واجهة برمجة التطبيقات (عبر REST أو قوائم انتظار الرسائل) التي تتيح لك إنشاء امتدادات مستقلة عن جوهر التطبيق وبتكامل سهل. ابحث عن خدمات ذات واجهات برمجة تطبيقات واضحة ، ووثائق جيدة ، ومجتمع قوي ، ولا يمكنك أن تخطئ. غالبًا ما تكون سهولة التكامل مقياسًا رئيسيًا ، وربما تكون أحد الأسباب الرئيسية لنجاح AWS منذ إصدار Lambda في عام 2015.
عندما يكون Serverless جيد
يمكن تطبيق التقنيات بدون خادم في كل مكان تقريبًا. ومع ذلك ، فإن مزاياها لا تقتصر على طريقة واحدة فقط للتطبيق. إن حاجز الدخول إلى الحوسبة السحابية اليوم منخفض جدًا بفضل التقنيات التي لا تحتوي على خادم. إذا كانت لدى المطورين فكرة ، لكنهم لا يعرفون كيفية إدارة البنية التحتية السحابية وتحسين التكاليف ، فلن يحتاجوا إلى البحث عن نوع من المهندسين للقيام بذلك. إذا أرادت شركة ناشئة بناء نظام أساسي لكنها تخشى أن تخرج التكاليف عن نطاق السيطرة ، فيمكنها بسهولة اللجوء إلى حلول بدون خادم.
نظرًا لتوفير التكاليف وسهولة التوسع ، فإن الحلول التي لا تحتاج إلى خادم قابلة للتطبيق بشكل متساوٍ على كل من الأنظمة الداخلية والخارجية ، حتى تطبيق ويب يضم عدة ملايين من الجمهور. يتم قياس الحسابات وليس باليورو ، ولكن بالسنت. سيكلف استئجار أبسط مثيل لـ AWS EC2 (t1.micro) لمدة شهر 15 يورو ، حتى لو لم تفعل شيئًا به (من لم ينس أبدًا إيقاف تشغيله؟!). بالمقارنة ، للوصول إلى هذا المستوى من الإنفاق خلال نفس الفترة الزمنية ، ستحتاج إلى تشغيل 512 ميجابايت من Lambda لمدة ثانية واحدة حوالي 1 ملايين مرة. وإذا كنت لا تستخدم هذه الميزة ، فلن تدفع أي شيء.
نظرًا لأن عدم وجود خادم يعتمد بشكل أساسي على الأحداث ، فمن السهل إلى حد ما إضافة بنية أساسية بدون خادم إلى الأنظمة القديمة. على سبيل المثال ، باستخدام AWS S3 و Lambda و Kinesis ، يمكنك إنشاء خدمة تحليلات لنظام بيع بالتجزئة قديم يمكنه تلقي البيانات من خلال واجهة برمجة تطبيقات.
تدعم معظم المنصات التي لا تحتاج إلى خادم لغات متعددة. غالبًا ما تكون Python و JavaScript و C # و Java و Go. عادة لا توجد قيود على استخدام المكتبات بجميع اللغات ، لذا يمكنك استخدام مكتباتك مفتوحة المصدر المفضلة. ومع ذلك ، يُنصح بعدم إساءة استخدام التبعيات حتى تعمل وظائفك على النحو الأمثل ولا تلغي فوائد قابلية التوسع الهائلة للتطبيقات التي لا تحتاج إلى خادم. كلما زاد عدد العبوات التي يجب تحميلها في الحاوية ، كلما طال وقت بدء التشغيل على البارد.
البداية الباردة هي عندما تحتاج أولاً إلى تهيئة الحاوية ووقت التشغيل ومعالج الأخطاء قبل استخدامها. لهذا السبب ، يمكن أن يصل التأخير في تنفيذ الوظائف إلى 3 ثوانٍ ، وهذا ليس الخيار الأفضل للمستخدمين غير الصبورين. ومع ذلك ، يبدأ البرودة عند المكالمة الأولى بعد بضع دقائق من وضع الخمول. يعتبر الكثيرون أن هذا مصدر إزعاج بسيط يمكن حله عن طريق اختبار اتصال الوظيفة بانتظام لإبقائها في وضع الخمول. أو يتجاهلون هذا الجانب تمامًا.
على الرغم من إصدار AWSومع ذلك ، فإن قواعد بيانات SQL ليست مثالية لهذا التطبيق ، لأنها تعتمد على الاتصالات لإجراء المعاملات ، والتي يمكن أن تصبح بسرعة عنق الزجاجة مع حركة المرور الكثيفة على AWS Lambda. نعم ، يعمل المطورون باستمرار على تحسين Serverless Aurora ، ويجب أن تجربها ، ولكن اليوم حلول NoSQL مثل. ومع ذلك ، ليس هناك شك في أن هذا الوضع سيتغير قريبًا جدًا.
تفرض مجموعة الأدوات أيضًا الكثير من القيود ، خاصة في مجال الاختبار المحلي. على الرغم من وجود حلول مثل Docker-Lambda و DynamoDB Local و LocalStack ، إلا أنها تتطلب عملاً شاقًا وقدرًا كبيرًا من التكوين. ومع ذلك ، يتم تطوير كل هذه المشاريع بنشاط ، لذا فهي مسألة وقت فقط قبل أن تصل مجموعة الأدوات إلى المستوى الذي نحتاجه.
تأثير التقنيات بدون خادم على دورة التطوير
نظرًا لأن البنية الأساسية الخاصة بك هي مجرد تكوين ، يمكنك تعريف ونشر التعليمات البرمجية باستخدام البرامج النصية ، مثل البرامج النصية لـ shell. أو يمكنك اللجوء إلى حلول فئة التكوين كرمز مثل . على الرغم من أن هذه الخدمة لا توفر تكوينًا لجميع المناطق ، إلا أنها تسمح لك بتحديد موارد معينة لاستخدامها كوظائف Lambda. هذا هو ، حيث يفشل CloudFormation ، يمكنك كتابة المورد الخاص بك (وظيفة Lambda) التي ستغلق هذه الفجوة. بهذه الطريقة يمكنك فعل أي شيء ، حتى تكوين التبعيات خارج بيئة AWS الخاصة بك.
نظرًا لأنه مجرد تكوين ، يمكنك تخصيص البرامج النصية للنشر لبيئات ومناطق ومستخدمين معينين ، خاصة إذا كنت تستخدم حلول البنية الأساسية كرمز مثل CloudFormation. على سبيل المثال ، يمكنك نشر نسخة من البنية الأساسية لكل فرع في المستودع بحيث يمكنك اختبارها بشكل منفصل أثناء التطوير. يؤدي هذا إلى تسريع التعليقات بشكل كبير للمطورين عندما يريدون فهم ما إذا كانت التعليمات البرمجية الخاصة بهم تعمل بشكل مناسب في بيئة حية. لا يحتاج المديرون إلى القلق بشأن تكلفة نشر بيئات متعددة ، لأنهم يدفعون فقط مقابل الاستخدام الفعلي.
لدى DevOps مخاوف أقل لأنها تحتاج فقط للتأكد من أن المطورين لديهم التكوين الصحيح. لم تعد بحاجة إلى إدارة الطبعات أو الموازنات أو مجموعات الأمان. لذلك ، يتم استخدام مصطلح NoOps بشكل متزايد ، على الرغم من أنه لا يزال من المهم أن تكون قادرًا على تكوين البنية التحتية ، خاصة عندما يتعلق الأمر بتكوين IAM وتحسين موارد السحابة.
هناك أدوات مراقبة وتصور قوية جدًا مثل Epsagon و Thundra و Dashbird و IOPipe. إنها تسمح لك بمراقبة الحالة الحالية للتطبيقات التي لا تحتوي على خادم ، وتوفير التسجيل والتتبع ، والتقاط مقاييس الأداء والاختناقات الهيكلية ، وإجراء تحليل التكلفة والتنبؤ ، والمزيد. فهي لا تمنح مهندسي DevOps والمطورين والمهندسين المعماريين رؤية شاملة لأداء التطبيق فحسب ، بل تتيح أيضًا للمديرين مراقبة الموقف في الوقت الفعلي ، مع تكاليف الموارد في الثانية والتنبؤ بالتكلفة. من الصعب جدًا تنظيم ذلك باستخدام بنية تحتية مُدارة.
يعد تصميم التطبيقات بدون خادم أسهل بكثير لأنك لست مضطرًا لنشر خوادم الويب ، وإدارة الأجهزة أو الحاويات الافتراضية ، وخوادم التصحيح ، وأنظمة التشغيل ، وبوابات الإنترنت ، وما إلى ذلك. من خلال التخلص من كل هذه المسؤوليات ، يمكن أن تركز بنية بدون خادم على جوهر - الحل - احتياجات العمل والعملاء.
في حين أن مجموعة الأدوات يمكن أن تكون أفضل (تتحسن كل يوم) ، يمكن للمطورين التركيز على تنفيذ منطق الأعمال وتوزيع تعقيد التطبيق بشكل أفضل عبر خدمات مختلفة داخل البنية. تعتمد إدارة التطبيقات بدون خادم على الأحداث ويتم استخلاصها من قِبل موفر السحابة (مثل SQS أو أحداث S3 أو تدفقات DynamoDB). لذلك ، يحتاج المطورون فقط إلى كتابة منطق الأعمال للرد على أحداث معينة ، ولا داعي للقلق بشأن أفضل السبل لتنفيذ قواعد البيانات وقوائم انتظار الرسائل ، أو كيفية تنظيم العمل الأمثل مع البيانات في مخازن أجهزة معينة.
يمكن تشغيل التعليمات البرمجية وتصحيحها محليًا ، كما هو الحال مع أي عملية تطوير. اختبار الوحدة يبقى كما هو. تتيح القدرة على نشر بنية أساسية كاملة للتطبيق مع تكوين مكدس مخصص للمطورين الحصول بسرعة على ملاحظات مهمة دون التفكير في تكلفة الاختبار أو التأثير على البيئات المدارة باهظة الثمن.
أدوات وتقنيات لبناء تطبيقات بدون خادم
لا توجد طريقة محددة لإنشاء تطبيقات بدون خادم. فضلا عن مجموعة من الخدمات لهذه المهمة. AWS هي الشركة الرائدة بين الحلول القوية بدون خادم اليوم ، ولكن انظر أيضًا , и . إذا كنت تستخدم AWS ، فإن الطريقة الموصى بها لتجميع التطبيقات هي (SAM) ، خاصة عند استخدام C # ، لأن Visual Studio به أدوات رائعة. يمكن لـ SAM CLI القيام بكل ما يمكن لبرنامج Visual Studio القيام به ، لذلك لن تفقد أي شيء إذا قمت بالتبديل إلى IDE آخر أو محرر نصوص. بالطبع ، يعمل SAM مع لغات أخرى أيضًا.
إذا كنت تكتب بلغات أخرى ، فإن Serverless Framework هي أداة ممتازة مفتوحة المصدر تسمح لك بتهيئة أي شيء باستخدام ملفات تكوين YAML قوية جدًا. يدعم Serverless Framework أيضًا العديد من الخدمات السحابية ، لذلك نوصي به لأولئك الذين يبحثون عن حل متعدد السحابة. لديه مجتمع ضخم أنشأ مجموعة من المكونات الإضافية لأي حاجة.
بالنسبة للاختبار المحلي ، فإن الأدوات مفتوحة المصدر Docker-Lambda و Serverless Local و DynamoDB Local و LocalStack مناسبة تمامًا. لا تزال التقنيات التي لا تحتاج إلى خادم في مراحلها الأولى من التطوير ، وكذلك الأدوات الخاصة بها ، لذلك عند الإعداد لسيناريوهات الاختبار المعقدة ، سيتعين عليك العمل بجد. ومع ذلك ، فإن مجرد نشر المكدس في بيئة واختبارها رخيص للغاية. ولست بحاجة إلى عمل نسخة محلية دقيقة من بيئات السحابة.
استخدم طبقات AWS Lambda لتقليل حجم الحزم المنشورة وتسريع التنزيلات.
استخدم لغات البرمجة المناسبة لمهام محددة. اللغات المختلفة لها مزاياها وعيوبها. هناك العديد من المعايير ، ولكن JavaScript ، و Python ، و C # (.NET Core 2.1+) هم رواد من حيث أداء AWS Lambda. قدمت AWS Lambda مؤخرًا واجهة برمجة تطبيقات Runtime ، والتي تتيح لك تحديد لغة التشغيل والبيئة المرغوبة ، لذا جربها.
حافظ على أحجام الحزم صغيرة للنشر. كلما كانت أصغر ، زادت سرعة تحميلها. تجنب استخدام المكتبات الكبيرة ، خاصة إذا كنت تستخدم ميزتين منها. إذا كنت تقوم بالبرمجة باستخدام JavaScript ، فاستخدم أداة إنشاء مثل Webpack لتحسين التصميم الخاص بك وتضمين فقط ما تحتاجه بالفعل. يحتوي .NET Core 3.0 على QuickJit و Tiered Compilation الذي يحسن الأداء ويساعد كثيرًا في البدايات الباردة.
يمكن أن يؤدي اعتماد الوظائف التي لا تحتوي على خادم على الأحداث إلى صعوبة تنسيق منطق الأعمال في البداية. في هذا الصدد ، يمكن أن تكون قوائم انتظار الرسائل وآلات الحالة مفيدة للغاية. يمكن لوظائف Lambda الاتصال ببعضها البعض ، ولكن لا تفعل ذلك إلا إذا كنت لا تتوقع استجابة ("أطلق وانس") - لا تريد أن تتم محاسبتك على انتظار اكتمال وظيفة أخرى. تعد قوائم انتظار الرسائل مفيدة لعزل أجزاء من منطق الأعمال ، وإدارة اختناقات التطبيق ، ومعالجة المعاملات (باستخدام قوائم انتظار FIFO). يمكن تعيين وظائف AWS Lambda إلى قوائم انتظار SQS كقوائم انتظار رسائل معلقة تتعقب الرسائل الفاشلة لتحليلها لاحقًا. AWS Step Functions (آلات الحالة) مفيدة جدًا لإدارة العمليات المعقدة التي تتطلب تسلسل الوظائف. بدلاً من استدعاء دالة Lambda لوظيفة أخرى ، يمكن لوظائف الخطوة تنسيق انتقالات الحالة وتمرير البيانات بين الوظائف وإدارة الحالة العامة للوظائف. يتيح لك هذا تحديد شروط إعادة المحاولة ، أو ما يجب فعله عند حدوث خطأ معين - أداة قوية جدًا في ظروف معينة.
اختتام
في السنوات الأخيرة ، تطورت التقنيات التي لا تحتاج إلى خوادم بوتيرة غير مسبوقة. هناك بعض المفاهيم الخاطئة المرتبطة بهذا التحول في النموذج. من خلال تجريد البنية التحتية وإدارة التوسيع ، تقدم الحلول التي لا تحتوي على خادم مزايا كبيرة ، من عمليات التطوير المبسطة و DevOps إلى التخفيضات الهائلة في تكاليف التشغيل.
في حين أن النهج غير الخوادم لا يخلو من عيوبه ، إلا أن هناك أنماط تصميم قوية يمكن استخدامها لبناء تطبيقات قوية بدون خادم أو دمج عناصر بدون خادم في البنى القائمة.
المصدر: www.habr.com