cloudgraphdev/cliأداة GraphQL API وCSPM العالمية لـ AWS، Azure، GCP، K8s، وtencent.
CloudGraph هي أداة مجانية مفتوحة المصدر وعالمية لـ GraphQL API وإدارة وضع الأمان السحابي (CSPM) لـ AWS و Azure و GCP و K8s. مع CloudGraph تحصل على:
يتيح لك Cloud Graph معرفة السحابة الخاصة بك في 5 دقائق. تم بناؤه وصيانته بحب من قبل الفريق في ❤️ AutoCloud ❤️
💻 التوثيق
💰 احصل على أجر لبناء موفري CloudGraph
** الاستخدام لا يعني التأييد
قامت AWS و Azure و GPC بعمل رائع في بناء حلول تتيح للمهندسين مثلنا إنشاء أنظمة لتشغيل عالمنا المترابط بشكل متزايد. على مدى السنوات الخمس عشرة الماضية، غيرت منتجات مثل EC2 و S3 و RDS و Lambda بشكل أساسي كيفية تفكيرنا في الحوسبة والتخزين وقواعد البيانات.
مع انتشار Kubernetes و Serverless في السنوات الخمس الأخيرة تقريبًا، أصبحت الخدمات السحابية مجردة بشكل متزايد فوق أرفف الخوادم المادية. بالنسبة للمستخدمين النهائيين، كل شيء على السحابة هو مجرد API، لذلك لا نحتاج بالضرورة إلى معرفة كيفية عمل Lambda Functions أو EKS تحت الغطاء لنتمكن من استخدامها لبناء التطبيقات. مع القليل من التوثيق، والوصول إلى API أو وحدة التحكم، والبرنامج التعليمي، يمكن لأي شخص إلى حد كبير إنشاء أي شيء يحتاجه.
أدت هذه التجريدات إلى تحسينات هائلة في الراحة العامة ونطاق عروض خدمات CSP. ما كان في السابق عملية شاقة وتستغرق وقتًا طويلاً وعرضة للخطأ لتوفير خوادم جديدة أو قواعد بيانات أو أنظمة ملفات يمكن الآن القيام به في ثوانٍ بمجرد النقر فوق زر أو نشر IAC. نظرًا لأن كل شيء هو مجرد تجريد API، فعندما يكون CAP جاهزًا لتقديم "منتج" جديد، فإنهم ببساطة يحتاجون إلى كشف API جديد - نعم، أنا بالطبع أبسط الأمر قليلاً :)
أي شخص على دراية بـ CSPs يعرف أن واجهات برمجة تطبيقات الخدمة غالبًا ما تكون مقسمة إلى مساحات أسماء معيارية تحتوي على عشرات، إن لم يكن المئات، من طرق API منفصلة لموارد فردية. على سبيل المثال، تحتوي خدمة AWS EC2 على أكثر من 500 طريقة API مختلفة، مع إضافة طرق جديدة بين الحين والآخر. أي شركة تبني أنظمة كبيرة على CSP من المحتمل أن تستخدم العديد والعديد من الخدمات المختلفة.
على الرغم من أنها تحفة معمارية لمركز البيانات، إلا أن هذا الاختيار لمئات الخدمات وخيارات التكوين يضع عبء المعرفة حول كيفية استخدام هذه الخدمات بشكل صحيح على عاتقنا نحن المهندسين. نتيجة لذلك، نجد أنفسنا مضطرين إلى البقاء على اطلاع دائم بالخدمات الجديدة أو التغييرات. وهذا يتطلب قدرًا كبيرًا من الوقت والطاقة العقلية. كمطورين، قد يكون من الصعب والمستهلك للوقت والمحبط استخدام AWS CLI لإجراء 5 مكالمات API مختلفة لوصف، على سبيل المثال، مجموعة ECS AWS، وخدماتها، وتعريفات المهام، والمهام، وتعريفات الحاويات، إلخ. غالبًا ما نجد أنفسنا ضائعين في التوثيق ونضطر إلى استخدام نصف دستة من واجهات برمجة التطبيقات للحصول على إجابات لأسئلة مثل "ما الذي يعمل بالضبط في هذا VPC؟"
هذا يعني أن AWS و Azure و GCP يمكن أن تصبح ساحقة بسرعة حتى لمهندسي السحابة المتمرسين. بينما تتفوق CSPs في بناء الخدمات الفعلية التي تشغل أعمالنا، لم يتم إحراز تقدم كبير في تبسيط تجربة المستخدم اليومية للاستعلام عن هذه المئات من الخدمات بطريقة منطقية.
حاولت حلول جديدة مثل Cloud Control API لـ AWS إنشاء واجهة موحدة للاستعلام عن العديد من أنواع موارد AWS المختلفة. لسوء الحظ، استخدام Cloud Control API محدود بشدة، ولا يزال المستخدمون بحاجة إلى معرفة كيفية الاستعلام عن بياناتهم بشكل صحيح. وهذا يعني المزيد من الوقت المستغرق في قراءة التوثيق وفهم كيفية عمل الخدمات وعلاقتها ببعضها البعض.
بينما تعتبر نمطية واجهات برمجة تطبيقات CSP نظامًا تنظيميًا منطقيًا رائعًا ولها معنى، إلا أنها تشكل عبئًا على المستخدمين النهائيين من حيث العبء المعرفي ومنحنى التعلم. الاضطرار إلى تذكر كيفية عمل مئات الخدمات المتغيرة باستمرار وكيفية ارتباطها يؤدي إلى إدمان الكافيين وإضاعة الوقت في لعب دور المباحث.
ألن يكون رائعًا لو كان لدينا كمهندسي DevOps/Cloud طريقة أبسط لاستخراج بياناتنا من AWS و Azure و GCP وغيرها؟ طريقة تعكس حاجتنا إلى الاستعلام بسهولة عن أي بيانات حول أي خدمة في أي حساب دون الحاجة إلى قضاء ساعات في التوثيق أو Stack Overflow؟
لهذه الأسباب قمنا ببناء CloudGraph، واجهة GraphQL API لكل شيء سحابي. يقوم CloudGraph باستخراج بياناتك السحابية وتطبيعها ومعالجتها وإثرائها مما يسمح لك بالوصول إلى رؤى عميقة عبر موفري متعددين بجهد ضئيل. اطلع على مقالنا The GraphQL API for everything لمعرفة المزيد.
