كانت لدينا مشكلة مثيرة للاهتمام منذ بضع سنوات. نحن شركة نبعد تمامًا عن جميع برامجنا على السحابة. وكان لدينا مجموعة من تطبيقات Spring Boot التي تعمل على حاويات مع Infrastructure كرمز. لكننا كنا بحاجة إلى مرونة في العمل.

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

نحن شركة تكنولوجيا ذات استراتيجية جريئة

في عام 2022، أنشأنا سجل قرار للهندسة المعمارية (ADR) الذي يقول، "الحاويات التي لا تحتاج إلى خدمة أولاً والحاويات حسب الحاجة". وأثار النقاش بين ما يقرب من 40 فريق هندسي.

لنشرح بعض المصطلحات أولاً

لا يقتصر استخدام Serverless-first على الوظائف كخدمة فحسب. وهي أيضًا مجموعة من الخدمات المدارة من مقدمي الخدمات السحابية التي: 

  • خفض النفقات العامة التشغيلية من خلال عدم إدارة البنية التحتية

  • قم بالقياس حسب الحاجة، بما في ذلك القياس إلى الصفر لجعلها مرنة تمامًا

  • لديك أسعار مرنة (تدفع فقط مقابل ما تستخدمه) 

في G-P، يشير مصطلح بدون خادم أولاً إلى استخدامنا لـ AWS Lambda، و EventBridge، و Step Functions، و Fargate، و SQS، و SNS، و API Gateway، و S3، و DynamoDB، وغيرها.

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

يوضح "الحاويات حسب الحاجة" أن بدون خادم أولاً لا يعني بدون خادم فقط. هناك أوقات نحتاج فيها إلى حاويات (على سبيل المثال، تثبيت منتج برنامج COTS) - ولا بأس بذلك.

استراتيجية تقنية تعطي الأولوية للعملاء

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

المبدأ الرئيسي في G-P هو: "أنت تبنيه، وتديره." تمتلك فرقنا برامجها. لذلك، لا نلقي البرامج على الحائط على فريق DevOps فحسب. 

فوائد "بدون خدمة أولاً"

إن بدون خادم هو بطبيعته مدفوع بالحدث.

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

تمكين القيود

وبصفتنا شركة global employment platform ، فإننا نأخذ الامتثال على محمل الجد. بنيتنا التحتية السحابية مصممة بشكل جيد، ونستخدم استراتيجية متعددة الحسابات تفصل أعباء العمل وتؤتمت الامتثال السحابي. تساعدنا خدمة بدون خادم على تطبيق معايير عالية من خلال التحكم في كيفية توفيرنا للموارد السحابية.

إلغاء تحميل العمل

يدير مزود الخدمات السحابية لدينا خدماتنا بدون خادم. مجموعة واحدة من اللبنات الأساسية - المتكاملة، والمضمونة، والموالفة، والتمكين، والصيانة من قِبل AWS - تُحرّرنا من التركيز بشكل أكبر على سلسلة القيمة للعملاء.

أعباء العمل المهيكلة جيدًا

تتم مراجعة كل عبء عمل ننشئه مع إطار عمل AWS Well-Architected Framework. نحن نركز على النطاق والأمان والموثوقية وتحسين التكلفة لضمان أننا لا نفي فقط بل نتجاوز أيضًا اتفاقية مستوى الخدمة (SLA). وهذا يُمكّن فرقنا الهندسية بينما نواصل التطور مع البيئات السحابية. 

نبذة عن فرقنا

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

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

النتيجة

لقد أحرزنا تقدمًا استثنائيًا خلال عامين. هناك العديد من الفوائد للتحديث (انظر مقالنا حول AWS / القيمة التجارية المعروفة للتحديث السحابي). وعلى وجه التحديد، لاحظنا ما يلي:

1. السرعة: تسمح الطريقة التي قمنا بها بتقسيم نظامنا للفرق والمنتجات بالابتكار والتطور بشكل مستقل. وهذا له تأثير كبير على مرونة الأعمال.

2. الامتثال: نستخدم إطار عمل AWS المُصمم جيدًا لمراجعة جميع أحمال العمل. نظرًا لأننا نستخدم العديد من خدمات AWS المدارة، يمكننا الاعتماد على تميزهم التشغيلي والبدء من مكان عالي الجودة.

3. التفكير في النظام: كان علينا توحيد العديد من عملياتنا حتى نتمكن من التفكير في النظام والموثوقية وقيمة الأعمال. نحن لا نقضي الوقت في العمل على المكونات منخفضة القيمة.

4. الابتكار: بدون خادم يعني أن كل شيء عبارة عن واجهة برمجة تطبيقات. يتطلب هذا القيد الإجباري نهجًا قائمًا على واجهة برمجة التطبيقات أولاً. عندما نفكر في أنفسنا كمنصة، يمكننا الوصول إلى مستوى جديد من الابتكار من خلال ربط الأنظمة بسهولة عبر واجهات برمجة التطبيقات، مثل توصيل G-P Gia™ بقاعدة معرفية جديدة.

5. الملكية: تملك AWS بنيتنا التحتية، لكننا نمتلك مجال أعمالنا. لقد أجبرنا التصميم القائم على المجال بدون خادم أولاً على التركيز على مشكلة الأعمال. وهذا يحافظ على وضوح ملكية القدرات.

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

بينما نشارك قصتنا، سيصبح من الواضح السرعة التي نعمل بها، وهي نتيجة مباشرة لـ بدون خادم أولاً. ترقبوا ذلك.