اختيار تقنية قاعدة بيانات جديدة بدون خادم في وكالة (دراسة حالة)

تم دعم هذه المقالة من قبل أصدقائنا الأعزاء في Fauna الذين يجعلون العمل مع البيانات التشغيلية منتجًا وقابلًا للتطوير وآمنًا لكل فريق تطوير برمجيات. شكرا لك!

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

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

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

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

ومع ذلك ، يتم تكليف وكيل وكالة جيد برعاية الفكرة العظيمة لشخص آخر وتقديمها إلى العالم. علينا التعامل معها بعناية أكبر مما نتعامل معه في مشاريعنا الخاصة. عندما أكون على وشك إجراء المكالمة الأخيرة بشأن تقنية جديدة ، غالبًا ما أفكر في هذه الحكمة من المؤسس المشارك Stack Overflow Joel Spolski:

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

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

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

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

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

عند تقييم تقنية جديدة ، ألقي نظرة على ثلاثة مجالات شاملة:

1. التكنولوجيا
2. تجربة المطور
3. العمل

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

التكنولوجيا

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

سأطرح على نفسي أسئلة مثل:

1. هل يحل على الأقل المشكلة التي يحلها الحل الحالي؟
2. بأي طرق يكون هذا الحل أفضل؟
3. بأي طرق يكون الأمر أسوأ؟
4. بالنسبة للمناطق التي هي أسوأ ، ما الذي يتطلبه الأمر للتغلب على أوجه القصور هذه؟
5. هل ستحل محل أدوات متعددة؟
6. ما مدى استقرار التكنولوجيا؟

لماذا لدينا؟

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

لنأخذ React كمثال. لماذا قررنا اعتماد React عندما كان jQuery أو Vanilla JavaScript يؤدي المهمة؟ في هذه الحالة ، أبرز استخدام إطار العمل كيف كانت هذه طريقة أفضل بكثير للتعامل مع الواجهات ذات الحالة. أصبح من الأسرع بالنسبة لنا بناء أشياء مثل ميزات التصفية والفرز من خلال العمل مع هياكل البيانات بدلاً من معالجة DOM المباشرة. كان هذا توفيرًا للوقت وزيادة استقرار حلولنا.

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

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

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

أين كنا ...

بصفتنا وكالة ، استخدمنا سابقًا مجموعة واسعة من قواعد البيانات بما في ذلك على سبيل المثال لا الحصر MySQL و PostgreSQL و MongoDB و DynamoDB و BigQuery و Firebase Cloud Storage. تركزت الغالبية العظمى من عملنا حول ثلاث قواعد بيانات أساسية: PostgreSQL و MongoDB و Firebase Realtime Database. كل واحدة من هذه ، في الواقع ، لديها عروض شبه خوادم ، ولكن بعض الميزات الرئيسية للعروض الجديدة جعلتنا نعيد تقييم افتراضاتنا السابقة. دعنا نلقي نظرة على تجربتنا التاريخية مع كل من هؤلاء أولاً ولماذا تركنا نفكر في البدائل في المقام الأول.

عادةً ما نختار PostgreSQL للمشاريع الأكبر وطويلة المدى ، لأن هذا هو المعيار الذهبي الذي تم اختباره في المعركة لكل شيء تقريبًا. وهو يدعم المعاملات الكلاسيكية والبيانات المعيارية ومتوافق مع ACID. هناك ثروة من الأدوات وأدوات إدارة السجلات (ORMs) المتاحة في كل لغة تقريبًا ويمكن حتى استخدامها كقاعدة بيانات NoSQL مخصصة مع دعم عمود JSON الخاص بها. إنه يتكامل بشكل جيد مع العديد من الأطر والمكتبات ولغات البرمجة الموجودة ، مما يجعله العمود الفقري الحقيقي للعمل في أي مكان. إنه أيضًا مفتوح المصدر ، وبالتالي لا يجعلنا محبوسين في أي بائع واحد. كما يقولون ، لم يُطرد أحد من قبل لاختياره Postgres.

ومع ذلك ، وجدنا أنفسنا تدريجياً نستخدم PostgreSQL أقل فأقل حيث أصبحنا أكثر من متجر موجه نحو العقدة. لقد وجدنا أن ORM's لـ Node باهتة وتتطلب المزيد من الاستعلامات المخصصة (على الرغم من أن هذا أصبح أقل إشكالية الآن) وشعرت NoSQL أنها أكثر ملاءمة عند العمل في وقت تشغيل JavaScript أو TypeScript. ومع ذلك ، غالبًا ما كان لدينا مشاريع يمكن إنجازها بسرعة كبيرة باستخدام النماذج العلائقية الكلاسيكية مثل سير عمل التجارة الإلكترونية. ومع ذلك ، فإن التعامل مع الإعداد المحلي لقاعدة البيانات ، وتوحيد تدفق الاختبار عبر الفرق ، والتعامل مع عمليات الترحيل المحلية كانت أشياء لم نحبها وسعدنا بتركها وراءنا نظرًا لأن NoSQL ، أصبحت قواعد البيانات المستندة إلى السحابة أكثر شيوعًا.

كانت MongoDB بشكل متزايد قاعدة بيانات الانتقال الخاصة بنا حيث اعتمدنا Node.js على أنها النهاية الخلفية المفضلة لدينا. العمل مع MongoDB Atlas جعل من السهل تطوير واختبار قواعد البيانات التي يمكن لفريقنا استخدامها. لفترة من الوقت ، لم يكن MongoDB متوافقًا مع ACID ، ولم يدعم المعاملات ، وأثبط الكثير من عمليات الانضمام الداخلية ، وبالتالي بالنسبة لتطبيقات التجارة الإلكترونية ، ما زلنا نستخدم Postgres في أغلب الأحيان. ومع ذلك ، هناك ثروة من المكتبات التي تتوافق معها ، وقد أعطتنا لغة استعلام Mongo ودعم JSON من الدرجة الأولى السرعة والكفاءة التي لم نختبرها مع قواعد البيانات العلائقية. أضاف MongoDB دعمًا لمعاملات ACID مؤخرًا ، ولكن لفترة طويلة ، كان هذا هو السبب الرئيسي الذي جعلنا نختار Postgres بدلاً من ذلك.

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

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

استخدمنا أيضًا Firebase Realtime Database لعدد قليل من المشاريع. كان هذا في الواقع عرضًا بدون خادم حيث تتزايد قاعدة البيانات وتنخفض عند الطلب ، وبتسعير الدفع أولاً بأول ، كان من المنطقي بالنسبة للتطبيقات التي لم يكن النطاق معروفًا فيها مسبقًا وكانت الميزانية محدودة. استخدمنا هذا بدلاً من MongoDB للمشاريع قصيرة العمر التي تتطلب بيانات بسيطة.

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

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

مثالنا

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

1. بدون خادم من الناحية التشغيلية مع نطاق حسب الطلب
2. النمذجة المرنة (مخطط)
3. لا الاعتماد على عمليات الترحيل أو ORMs
4. المعاملات المتوافقة مع ACID
5. يدعم العلاقات والبيانات الموحدة
6. يعمل مع كل من الخلفيات الخلفية التقليدية بدون خادم

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

مثال من مجال آخر هو إذا كنت ترغب في الحصول على التحقق من الكتابة المطبوعة في عرض القالب الخاص بك ، فأنت بحاجة إلى استخدام TSX و React. إذا ذهبت مع خيارات مثل Svelte أو Vue ، فيمكنك الحصول عليها - جزئيًا ولكن ليس بالكامل - من خلال عرض القالب . لذا فإن الحل الذي أعطاك البصمة الصغيرة وسرعة Svelte مع فحص مستوى القالب من React و TypeScript يمكن أن يكون كافيًا للتبني حتى لو كان يفتقد ميزة أخرى. سوف يتغير التوازن بين الرغبات والاحتياجات من مشروع إلى آخر. الأمر متروك لك لمعرفة أين ستكون القيمة وتحديد كيفية تحديد النقاط الأكثر أهمية في تحليلك.

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

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

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

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

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

تجربة المطور

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

بالنسبة للوكالات ، أعتقد أن هناك عقبتين رئيسيتين تظهران فيما يتعلق بتجربة المطور:

1. وقت الإعداد والتكوين
2. قابلية التعلم

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

وقت الإعداد والتكوين

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

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

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

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

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

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

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

قابلية التعلم

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

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

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

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

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

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

العمل

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

• ما مدى سهولة تسعيرها ودمجها في خطط الدعم الخاصة بنا؟
• هل يمكننا تحويله إلى العملاء بسهولة؟
• هل يمكن إعداد العملاء لهذه الأداة إذا لزم الأمر؟
• ما مقدار الوقت الذي توفره هذه الأداة بالفعل إن وجد؟

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

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

قواعد البيانات ليست استثناء. نحن نحب الاعتماد على خدمات مثل Mongo Atlas أو Heroku Postgres لجعل هذه العملية سهلة قدر الإمكان. عندما بدأنا في رؤية المزيد والمزيد من رأس المكدس الخاص بنا في أدوات بدون خوادم مثل Vercel أو Netlify أو AWS Lambda - كان لابد أن تتطور احتياجات قاعدة البيانات الخاصة بنا مع ذلك. تعد قواعد البيانات التي لا تحتوي على خادم مثل Firebase و DynamoDB و Fauna رائعة لأنها تتكامل جيدًا مع التطبيقات التي لا تحتوي على خادم ولكنها أيضًا تحرر أعمالنا تمامًا من التزويد والتوسيع.

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

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

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

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

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

كان الأمر أكثر صعوبة عندما يتعلق الأمر بأدوات أخرى بدون خادم. في تقييم قواعد البيانات التي لا تحتوي على خادم ، يدعم Firebase تقسيم المدفوعات حسب المشروع . في حالة Fauna أو DynamoDB ، هذا غير ممكن ، لذا يتعين علينا القيام ببعض الأعمال لمراقبة الاستخدام في لوحة القيادة الخاصة بهم ، وإذا أراد العميل ترك خدمتنا ، فسيتعين علينا نقل قاعدة البيانات إلى حسابه الخاص.

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

خاتمة

قد يكون اعتماد تقنية جديدة كوكالة مهمة صعبة. بينما نحن في وضع فريد للعمل مع مشاريع جديدة جديدة لديها فرص لتقنيات جديدة ، يتعين علينا أيضًا التفكير في الاستثمار طويل الأجل لهذه المشاريع. كيف سيؤدون؟ هل سيكون شعبنا منتجًا ويستمتع باستخدامها؟ Can we incorporate them into our business offering?

You need to have a firm grasp of where you have been before you figure out where you want to go technologically. When evaluating a new tool or platform it's important to think of what you have tried in the past and figure out what is most important to you and your team. We took a look at the concept of a serverless database and passed it through our three lenses – the technology, the experience, and the business. We were left with some pros and cons and had to strike the right balance.

After we evaluated serverless databases, we decided to adopt Fauna over the alternatives. We felt the technology was robust and ticked all of our boxes for our technology filter. When it came to the experience, virtually zero configuration and being able to leverage our existing knowledge of relational data modeling made this a winner with the development team. On the business side serverless provides clear wins to efficiency and productivity , however on the pricing side and account management there are still some difficulties. We decided the benefits in the other areas outweighed the pricing difficulties.

Overall, we highly recommend giving Fauna a shot on one of your next projects. It has become one of our favorite tools and our go-to database of choice for smaller serverless projects and even more traditional large backend applications. The community is very helpful, the learning curve is gentle, and we believe you'll find levels of productivity you hadn't realized before with existing databases.

When we first use a new technology on a project, we start with something either internal or on the smaller side. We try to mitigate the risk by wading into the water rather than leaping into the deep end by trying it on a large and complex project. As the team builds understanding of the technology, we start using it for larger projects but only after we feel comfortable that it has handled similar use cases well for us in the past.

In general, it can take up to a year for a technology to become a ubiquitous part of most projects so it is important to be patient. Agencies have a lot of flexibility but also are required to ensure stability in the products they produce, we don't get a second chance. Always be experimenting and pushing your agency to adopt new technologies, but do so carefully and you will reap the benefits.

قراءة متعمقة

• Serverless Database Wishlist - What's Missing Today
• Relational NoSQL: Yes, that is an option
• Concerning toolkits - A great piece about the merits of zero configuration on developer experience