Get best of the week

نصائح ومصادر لإنشاء تطبيقات بدون خادم


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

مفاهيم خاطئة بخصوص تقنيات الخوادم


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

المبدأ الأساسي للتقنيات بدون خادم هو أنك لا داعي للقلق بشأن إدارة وتوسيع البنية التحتية ، فأنت تدفع فقط مقابل ما تستخدمه. العديد من الخدمات مناسبة لهذه المعايير - AWS DynamoDB و S3 و SNS أو SQS و Graphcool و Auth0 و Now و Netlify و Firebase وغيرها الكثير. بشكل عام ، يعني عدم وجود الخادم استخدام جميع إمكانات الحوسبة السحابية دون الحاجة إلى إدارة البنية التحتية وتحسينها من أجل التوسع. وهذا يعني أيضًا أن الأمان على مستوى البنية التحتية لم يعد مشكلتك ، ولكنه يمثل ميزة كبيرة ، نظرًا لصعوبة الامتثال لمعايير الأمان وتعقيدها. أخيرًا ، لست بحاجة إلى شراء البنية التحتية المقدمة لك للاستخدام.

يمكن اعتبار انعدام الخادم "حالة ذهنية": عقلية معينة في تصميم الحلول. تجنب الطرق التي تتطلب صيانة أي بنية تحتية. من خلال نهج بدون خادم ، نقضي وقتًا في حل المشكلات التي تؤثر بشكل مباشر على المشروع وجلب الفوائد لمستخدمينا: نحن ننشئ منطقًا تجاريًا مستدامًا ، ونطور واجهات المستخدم ونطور واجهات برمجة تطبيقات تكيفية وموثوقة.

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

يتم الخلط بين البعض من خلال تبعية البائعين في تطوير التطبيقات السحابية. الشيء نفسه مع التقنيات بدون خادم ، وهذا بالكاد نتيجة للالتباس. في تجربتنا ، إنشاء تطبيقات بدون خادم على AWS مع قدرة AWS Lambda على تكامل خدمات AWS الأخرى - كل هذا يشكل جزئياً مزايا البنيات بدون خادم. هذا مثال جيد على التآزر عندما تكون نتيجة الدمج أكثر من مجرد مجموع المصطلحات. في محاولة لتجنب تبعية البائع ، قد تواجه مشاكل أكبر. عند العمل مع الحاويات ، من الأسهل إدارة مستوى التجريد الخاص بك بين موفري السحابة. ولكن عندما يتعلق الأمر بالحلول الخالية من الخوادم ، فلن تثمر الجهود ، خاصة إذا تم أخذ الكفاءة الاقتصادية في الاعتبار منذ البداية. تأكد من معرفة كيفية تقديم البائعين للخدمات.تعتمد بعض الخدمات المتخصصة على نقاط التكامل مع البائعين الآخرين ، ويمكنها توفير اتصال التوصيل والتشغيل خارج الصندوق. من الأسهل توفير اتصال Lambda من نقطة نهاية API للبوابة بدلاً من إرسال الطلب إلى حاوية معينة أو مثيل EC2. يوفر Graphcool تكوينًا سهلًا مع Auth0 ، وهو أسهل من استخدام مصادقة الطرف الثالث.

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

يعتبر:

  • ما هي الخدمات التي تحتاجها ولماذا.
  • ما هي الخدمات التي يقدمها مزودو الخدمات السحابية وكيف يمكنك دمجها باستخدام حل FaaS المحدد.
  • ما هي لغات البرمجة المدعومة (مع كتابة ديناميكية أو ثابتة ، أو تجميعها أو تفسيرها ، وما هي المعايير الموجودة ، وما هو الأداء في البداية الباردة ، وما هو النظام البيئي مفتوح المصدر ، وما إلى ذلك).
  • ما متطلبات الأمان لديك (SLA و 2FA و OAuth و HTTPS و SSL وما إلى ذلك).
  • كيفية إدارة CI / CD الخاصة بك ودورات تطوير البرمجيات.
  • ما حلول فئة البنية التحتية كرمز يمكنك الاستفادة منها؟

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

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


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

نظرًا لتوفير التكاليف وسهولة التوسع ، فإن الحلول الخالية من الخوادم قابلة للتطبيق بشكل متساوٍ على كل من الأنظمة الداخلية والأنظمة الخارجية ، حتى تطبيق ويب مع جمهور متعدد الملايين. الحسابات لا تقاس باليورو ، ولكن بالسنت. إن استئجار أبسط مثيل لـ AWS EC2 (t1.micro) لمدة شهر سيكلف 15 يورو ، حتى إذا لم تفعل أي شيء به (الذي لم ينس أبدًا إيقاف تشغيله؟!). وبالمقارنة ، من أجل تحقيق مثل هذا المستوى من الإنفاق بالفعل خلال نفس الفترة الزمنية ، ستحتاج إلى تشغيل Lambda 512 ميجا بايت لمدة ثانية واحدة حوالي 3 ملايين مرة. وإذا كنت لا تستخدم هذه الوظيفة ، فلا تدفع شيئًا.

نظرًا لأن التكنولوجيا بدون خادم تعتمد في المقام الأول على الأحداث ، فمن السهل إلى حد ما إضافة بنية أساسية بدون خادم إلى الأنظمة القديمة. على سبيل المثال ، باستخدام AWS S3 و Lambda و Kinesis ، يمكنك إنشاء خدمة تحليلية لنظام بيع بالتجزئة قديم يمكنه استقبال البيانات من خلال واجهة برمجة التطبيقات.

تدعم معظم الأنظمة الأساسية بدون خادم لغات مختلفة. غالبًا ما تكون Python و JavaScript و C # و Java و Go. عادة لا توجد قيود على استخدام المكتبات بجميع اللغات ، لذا يمكنك استخدام مكتباتك المفتوحة المصدر المفضلة. ومع ذلك ، يُنصح بعدم إساءة استخدام التبعيات بحيث تؤدي وظائفك على النحو الأمثل ولا تلغي فوائد قابلية التوسع الهائلة للتطبيقات التي لا تستخدم خادمًا. كلما زاد عدد الحزم التي تحتاج إلى تحميلها في الحاوية ، ستستغرق البداية الباردة وقتًا أطول.

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

على الرغم من أن AWS قد أصدرت خادم SQL SQL Serverless Serverlessومع ذلك ، فإن قواعد بيانات SQL ليست مثالية لمثل هذا التطبيق ، لأنه عند إجراء المعاملات ، فإنها تعتمد على الاتصالات ، والتي يمكن أن تصبح بسرعة عنق الزجاجة مع الكثير من حركة المرور على AWS Lambda. نعم ، يعمل المطورون على تحسين Serverless Aurora باستمرار ، ويجب أن تجربه ، ولكن اليوم أصبحت حلول NoSQL مثل DynamoDB أفضل كثيرًا للأنظمة التي لا تحتوي على خادم . ومع ذلك ، لا شك في أن هذا الوضع سيتغير قريبًا جدًا.

تفرض مجموعة الأدوات أيضًا الكثير من القيود ، خاصة في مجال الاختبار المحلي. على الرغم من وجود حلول مثل Docker-Lambda و DynamoDB Local و LocalStack ، إلا أنها تتطلب عملًا شاقًا وكمية كبيرة من التكوين. ومع ذلك ، كل هذه المشاريع تتطور بنشاط ، لذا فهي مسألة وقت فقط قبل أن تصل الأدوات إلى المستوى الذي نحتاجه.

تأثير التقنيات بدون خادم على دورة التطوير


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

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

لدى DevOps مخاوف أقل لأنها تحتاج فقط للتأكد من أن المطورين لديهم التكوين الصحيح. لم تعد بحاجة إلى إدارة المثيلات أو الموازنات أو مجموعات الأمان. لذلك ، يتم استخدام مصطلح NoOps بشكل متزايد ، على الرغم من أنه لا يزال من المهم أن تكون قادرًا على تكوين البنية التحتية ، خاصة عندما يتعلق الأمر بتكوين IAM وتحسين موارد السحابة.

هناك أدوات مراقبة وأدوات بصرية قوية جدًا مثل Epsagon و Thundra و Dashbird و IOPipe. فهي تسمح لك بمراقبة الحالة الحالية للتطبيقات التي لا تحتوي على خادم ، وتوفير السجلات والتتبع ، ومقاييس الأداء القياسية واختناقات البنية ، وإجراء تحليل للتكاليف والتنبؤ ، وغير ذلك الكثير. فهي لا تمنح مهندسي DevOps والمطورين والمهندسين المعماريين فكرة شاملة عن كيفية عمل التطبيقات فحسب ، بل تسمح أيضًا للمديرين بمراقبة الوضع في الوقت الفعلي ، مع تكلفة الموارد في الثانية والتنبؤ بالتكلفة. إدارة هذا ببنية تحتية مُدارة أكثر صعوبة.

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

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

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

أدوات وتقنيات لبناء تطبيقات بدون خادم


لا توجد طريقة محددة لإنشاء تطبيقات بدون خادم. وكذلك مجموعة من الخدمات لهذه المهمة. AWS هي الشركة الرائدة بين الحلول القوية الخالية من الخوادم اليوم ، ولكن انتبه إلى Google Cloud و Zeit و Firebase . إذا كنت تستخدم AWS ، فيمكن التوصية بنموذج تطبيق بدون خادم (SAM) كنهج لجمع التطبيقات ، خاصة عند استخدام C # ، نظرًا لأن Visual Studio عبارة عن مجموعة أدوات رائعة. يمكن لـ SAM CLI القيام بكل شيء مثل Visual Studio ، لذلك لن تفقد أي شيء إذا قمت بالتبديل إلى IDE أو محرر نصوص آخر. بالطبع ، تعمل SAM أيضًا مع لغات أخرى.

إذا كنت تكتب بلغات أخرى ، فإن Frameworkless Framework أداة ممتازة مفتوحة المصدر تتيح لك تكوين أي شيء بمساعدة ملفات YAML ذات التكوين القوي جدًا. يدعم Serverless Framework أيضًا الخدمات السحابية المختلفة ، لذلك نوصي به لأولئك الذين يبحثون عن حل متعدد السحابة. لديه مجتمع ضخم أنشأ مجموعة من المكونات الإضافية لأي احتياجات.

للاختبار المحلي ، فإن الأدوات مفتوحة المصدر Docker-Lambda و Serverless Local و DynamoDB Local و LocalStack مناسبة تمامًا. لا تزال التقنيات التي لا تحتوي على خادم في مرحلة مبكرة من التطوير ، وكذلك الأدوات المتاحة لها ، لذلك عند الإعداد لسيناريوهات الاختبار المعقدة ، سيكون عليك التعرق. ومع ذلك ، فإن مجرد توسيع المكدس في البيئة والاختبار هناك أصبح رخيصًا بشكل لا يصدق. ولا تحتاج إلى عمل نسخة محلية دقيقة من البيئات السحابية.

استخدم طبقات AWS Lambda لتقليل حجم الحزم المنشورة وتسريع التحميل.

استخدم لغات البرمجة الصحيحة لمهام محددة. اللغات المختلفة لها مزاياها وعيوبها. هناك العديد من المعايير ، ولكن JavaScript و Python و C # (.NET Core 2.1+) هم رواد من حيث أداء AWS Lambda. ظهرت واجهة برمجة تطبيقات Runtime مؤخرًا في AWS Lambda ، مما يسمح لك بتحديد اللغة ووقت التشغيل المطلوبين ، لذا جربها.

اجعل حجم الحزمة صغيرًا للنشر. كلما كانت أصغر ، كلما كانت أسرع في التحميل. تجنب استخدام المكتبات الكبيرة ، خاصة إذا كنت تستخدم ميزتين منها. إذا كنت تقوم بالبرمجة في JavaScript ، فاستخدم أدوات البناء مثل Webpack لتحسين جهازك وتضمين ما تحتاجه فقط. يحتوي .NET Core 3.0 على QuickJit و Tiered Compilation التي تعمل على تحسين الأداء وتساعد كثيرًا في البداية الباردة.

قد يؤدي اعتماد الدالات بدون خادم على الأحداث في البداية إلى تعقيد تنسيق منطق الأعمال. في هذا الصدد ، يمكن أن تكون قوائم انتظار الرسائل وآلات الحالة مفيدة بشكل لا يصدق. وظائف Lambda قادرة على الاتصال ببعضها البعض ، ولكن لا تفعل ذلك إلا إذا كنت لا تتوقع تلقي إجابة ("أطلق النار ونسيت") - لا تريد الحصول على حساب في انتظار إتمام وظيفة أخرى. قوائم انتظار الرسائل مفيدة لعزل أجزاء من منطق الأعمال ، وإدارة اختناقات التطبيق ، ومعالجة المعاملات (باستخدام قوائم الانتظار FIFO). يمكن تعيين وظائف AWS Lambda لقوائم انتظار SQS كقوائم انتظار الرسائل التي تتعقب الرسائل الفاشلة لتحليلها لاحقًا. وظائف AWS Step (آلات الحالة) مفيدة جدًا لإدارة العمليات المعقدة التي تتطلب إنشاء سلاسل الوظائف.بدلاً من استدعاء دالة Lambda وظيفة أخرى ، يمكن لوظائف Step تنسيق انتقالات الحالة ، ونقل البيانات بين الوظائف ، والتحكم في الحالة العامة للوظائف. هذا يسمح لك بتحديد شروط إعادة المحاولة ، أو ما يجب القيام به عند حدوث خطأ معين - تحت ظروف معينة ، أداة قوية للغاية.

استنتاج


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

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles