كانت لدينا مشكلة مثيرة للاهتمام قبل بضع سنوات. نحن شركة تعمل عن بعد بالكامل، وجميع برامجنا موجودة على السحابة. وكان لدينا مجموعة من تطبيقات Spring Boot تعمل على حاويات باستخدام البنية التحتية كبرنامج. لكننا كنا بحاجة إلى مرونة الأعمال. سوق العمل العالمي يتحرك بسرعة، وهناك دائماً طلب على المنتجات الجديدة. كان علينا إيجاد طريقة للحفاظ على ريادتنا في جميع أنحاء الصناعة.
نحن شركة تقنية ذات استراتيجية جريئة
في 2022، أنشأنا ADR (سجل قرارات الهندسة المعمارية) الذي يقول، " بدون خادم أولاً والحاويات حسب الحاجة. " وأثار ذلك نقاشاً بين ما يقرب من 40 فريق هندسي.
دعونا نشرح بعض المصطلحات أولاً
لا يقتصر استخدام Serverless-First على الوظائف كخدمة فقط. إنها أيضًا مجموعة من الخدمات المُدارة من موفري السحابة التي:
- انخفاض النفقات التشغيلية من خلال عدم إدارة البنية التحتية
- قم بالتوسع حسب الحاجة، بما في ذلك التحجيم إلى الصفر لجعلها مرنة تمامًا
- تمتع بأسعار مرنة (تدفع فقط مقابل ما تستخدمه)
في G-P، يشير مصطلح serverless-first إلى استخدامنا لـ AWS Lambda و EventBridge و Step Functions و Fargate و SQS و SNS و واجهة برمجة التطبيقات (API) Gateway و S3 و DynamoDB وغيرها.
يعني مصطلح "الخوادم بدون خوادم أولاً" أنه عندما نختار حلاً للحوسبة أو التخزين أو المراسلة أو ما شابه ذلك، فإننا نرغب في أن تبدأ الفرق بخيار بدون خوادم. ملاحظة هامة: إذا لم تلبي الخدمة بدون خادم الحاجة، فيجب على الفريق اللجوء إلى خدمة أثقل - خدمة تتطلب استثمارًا تشغيليًا أكبر.
يوضح مصطلح "الحاويات حسب الحاجة" أن "الخوادم بدون خادم أولاً" لا يعني "الخوادم بدون خادم فقط". هناك أوقات نحتاج فيها إلى حاويات (على سبيل المثال، تثبيت منتج برمجي جاهز للاستخدام) - وهذا أمر جيد.
استراتيجية تكنولوجية تعطي الأولوية للعملاء
نتحرك بخطى سريعة ومرنة لتلبية احتياجات عملائنا ومستخدمينا. تتميز خدمات مثل Lambda و S3 و DynamoBD بالمرونة والسرعة بشكل لا يصدق. من خلال تفريغ الأحمال الثقيلة غير المتمايزة، يمكننا قضاء المزيد من الوقت في إنشاء ميزات للمستخدمين، بدلاً من العمل على تكوين البنية التحتية العامة.
أحد المبادئ الأساسية في شركة G-P هو: "أنت تبنيه، وأنت تديره". فرقنا تمتلك برامجها الخاصة. لذا، نحن لا نلقي بالبرمجيات ببساطة إلى فريق DevOps.
فوائد «الخادم بدون خادم أولاً»
تعتمد تقنية الحوسبة بلا خوادم بطبيعتها على الأحداث.
تعتمد بنيتنا بالكامل على الأحداث. باستخدام EDA (هندسة البرمجيات الموجهة بالأحداث)، يمكننا توسيع نطاق كل من مؤسستنا وبرامجنا. تُجبرنا تقنية الحوسبة السحابية بدون خوادم على الحفاظ على نطاق تأثير صغير والتواصل بطريقة سحابية أصلية بالكامل عبر الفعاليات.
القيود التمكينية
باعتبارنا شركة توظيف عالمية، فإننا نأخذ الأمر على محمل الجد. تتميز بنيتنا التحتية السحابية بتصميمها الجيد، ونستخدم استراتيجية متعددة الحسابات تفصل أحمال العمل وتؤتمت الامتثال السحابي. تساعدنا تقنية الحوسبة السحابية بدون خوادم على تطبيق معايير عالية من خلال التحكم في كيفية توفير موارد الحوسبة السحابية.
قم بتفريغ العمل
يقوم مزود السحابة الخاص بنا بإدارة خدماتنا بدون خادم. مجموعة واحدة من اللبنات الأساسية - متكاملة ومؤمنة ومضبوطة وممكّنة ومُصانة بواسطة AWS - تتيح لنا التركيز على مستويات أعلى في سلسلة القيمة للعملاء.
أحمال عمل جيدة التصميم
تتم مراجعة كل عبء عمل نقوم بإنشائه باستخدام إطار عمل AWS Well-Architected. نحن نركز على الحجم والأمان والموثوقية وتحسين التكلفة لضمان أننا لا نلبي فقط اتفاقية مستوى الخدمة (SLA) بل نتجاوزها أيضًا. وهذا يُمكّن فرقنا الهندسية بينما نواصل التطور مع بيئات الحوسبة السحابية.
نبذة عن فرقنا
استراتيجيتنا التكنولوجية طموحة، وهذا ما يجعلها مليئة بالتحديات. لم يعمل العديد من المهندسين في بنية بدون خادم (أو بنية موزعة). إن الانتقال إلى البنية بدون خادم ليس بالأمر السهل، ونحن نبحث عن مهندسين يشعرون بالراحة في التعلم والتفكير الكبير والتحرك بخطى سريعة.
بعض المهندسين ليسوا متأكدين من مصطلح serverless (نعم، نحن نعلم أن هناك خوادم) لأن الأسلوب هو أكثر من كتابة التعليمات البرمجية في الوظائف. تتطلب استراتيجيتنا نهجًا شاملاً لمبادئ السحابة الأصلية الكلاسيكية.
النتيجة
لقد حققنا تقدماً استثنائياً خلال عامين. هناك العديد من الفوائد للتحديث (انظر مقالتنا حول القيمة التجارية المعروفة لتحديث الحوسبة السحابية). وبالتحديد، لاحظنا ما يلي:
1. السرعة: إن الطريقة التي قسمنا بها نظامنا تسمح للفرق والمنتجات بالابتكار والتطور بشكل مستقل. وهذا له تأثير هائل على مرونة الأعمال.
2. الإمتثال: نحن نستخدم إطار العمل السنوي المصمم بشكل جيد لمراجعة جميع أعباء العمل. لأننا نستخدم العديد من الخدمات المُدارة، يمكننا الاعتماد على تميزها التشغيلي والبدء من مكان ذي جودة عالية.
3. التفكير النظمي: كان علينا توحيد العديد من عملياتنا حتى نتمكن من التفكير في النظام والموثوقية والقيمة التجارية. لا نضيع وقتنا في العمل على مكونات ذات قيمة منخفضة.
4. الابتكار: بدون خادم يعني أن كل شيء عبارة عن واجهة برمجة التطبيقات (API). يتطلب هذا القيد القسري أسلوب واجهة برمجة التطبيقات (API)-أولاً. عندما نفكر في أنفسنا كمنصة، يمكننا الوصول إلى مستوى جديد من الابتكار من خلال ربط الأنظمة بسهولة عبر واجهات برمجة التطبيقات، مثل توصيل G-P Gia™ بقاعدة معرفية جديدة.
5. الملكية: إن اتفاقية الشراكة السنوية تمتلك البنية التحتية الخاصة بنا، ولكننا نملك مجال أعمالنا. لقد أجبرنا اعتماد أسلوب "الخوادم اللامركزية أولاً" مع التصميم الموجه بالمجال على التركيز على مشكلة العمل. وهذا يحافظ على وضوح ملكية القدرات.
لا يكون Serverless-first دائمًا أسرع، ولكنه أكثر فائدة. نفضل تحسين سرعة النظام بدلاً من سرعة المطور الفردي. لا يتعلق Serverless-first باستخدام الوظائف بقدر ما يتعلق بالتفكير في أن «الكود هو مسؤولية. النظام هو الأصل». كلما قل عدد التعليمات البرمجية التي يتعين علينا كتابتها، زادت قدرتنا على التفكير في نظام الأعمال الذي نقوم ببنائه وتشكيله.
عندما نشارك قصتنا، ستصبح السرعة التي نعمل بها واضحة، وهي نتيجة مباشرة لـ serverless first. ابقوا على اتصال.
