كانت لدينا مشكلة مثيرة للاهتمام قبل بضع سنوات. نحن شركة تعمل عن بعد بالكامل، وجميع برامجنا موجودة على السحابة. وكان لدينا مجموعة من تطبيقات Spring Boot تعمل على حاويات باستخدام البنية التحتية كبرنامج. لكننا كنا بحاجة إلى مرونة الأعمال.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

فوائد «الخادم بدون خادم أولاً»

تعتمد تقنية الحوسبة بلا خوادم بطبيعتها على الأحداث.

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

القيود التمكينية

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

قم بتفريغ العمل

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

أحمال عمل جيدة التصميم

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

نبذة عن فرقنا

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

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

النتيجة

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

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

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

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

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

5. الملكية: تمتلك AWS بنيتنا التحتية، لكننا نمتلك نطاق أعمالنا. لقد أجبرنا Serverless-first مع التصميم المستند إلى المجال على التركيز على مشكلة الأعمال. وهذا يحافظ على وضوح ملكية القدرات.

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

عندما نشارك قصتنا، ستصبح السرعة التي نعمل بها واضحة، وهي نتيجة مباشرة لـ serverless first. ابقوا على اتصال.