إدارة واجهات برمجة التطبيقات (API) في البيئات الهجينة والمتعددة السحابية: التحديات والخيارات

1. متعدد السحابة والسحابة الهجينة

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

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

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

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

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

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

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

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

2. الحاجة إلى إدارة واجهات برمجة التطبيقات في سيناريوهات متعدد السحابة والسحابة الهجينة

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

هل تدير إدارة متعددة العناقيد

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

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

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

هل تدير التعاون

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

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

هل يمكن أن تعمل على أي بنية تحتية

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

3. القرارات

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

حلول مختلفة على سحابات مختلفة

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

تشمل المزايا:

1. تكلفة استخدام منخفضة للغاية، مع عدم الحاجة إلى النشر أو الصيانة.
2. عادةً ما يدعم الدفع حسب الاستخدام؛ قد يتطلب الاستخدام المبكر تكاليف بسيطة فقط.

تشمل العيوب:

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

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

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

حل بوابة واجهات برمجة التطبيقات مفتوحة المصدر

كبديل لاستخدام حلول مختلفة عبر سحابات مختلفة، يمكن للمستخدمين التفكير في استخدام حلول بوابات واجهات برمجة التطبيقات مفتوحة المصدر مثل Apache APISIX، Kong، Tyk، Traefik، إلخ. يسمح هذا النهج للمستخدمين باستخدام نفس بوابة واجهات برمجة التطبيقات عبر جميع السحابات، بما في ذلك مراكز البيانات الخاصة، وبالتالي تجنب مشكلات التوافق بين الحلول المختلفة. يمكن أن تساعد بوابة واجهات برمجة التطبيقات مفتوحة المصدر الناضجة والقوية المستخدمين في حل العديد من المشكلات في سيناريوهات مختلفة. حتى إذا لم تغطي جميع السيناريوهات، فإن هذه البوابات تسمح عادةً للمستخدمين بتوسيعها بطرق مختلفة. على سبيل المثال، تسمح Apache APISIX للمستخدمين بتوسيعها باستخدام لغات وتقنيات مثل Go، Java، Python، Lua، WASM، إلخ.

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

شراء خدمة SaaS لمنتج بوابة واجهات برمجة التطبيقات على مستوى المؤسسة

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

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

بالطبع، يتطلب شراء خدمات SaaS الحذر. لذلك، قبل تأكيد الطلب، يجب على المستخدمين تقييم خدمة SaaS من الجوانب التالية:

1. هل يمكن لهذه الخدمة تلبية احتياجات الاستخدام الحالية والمستقبلية؟
2. هل مزود خدمة SaaS محترف وموثوق؟ ما نوع حالات الاستخدام التي لديهم؟
3. هل هذه الخدمة متوافقة مع GDPR ولديها تقارير تدقيق SOC2؟
4. هل تحتوي هذه الخدمة على شروط SLA واضحة؟
5. كيف يتم فرض رسوم على هذه الخدمة؟ هل يمكن للمستخدمين تقدير الإنفاق المستقبلي لمدة عام أو بضع سنوات؟

التطوير الذاتي بالكامل

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

4. الخلاصة

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

لمزيد من المعلومات حول بوابة واجهات برمجة التطبيقات، يرجى زيارة مدوناتنا أو الاتصال بنا.