AWS و IBM: مقارنة خدمات إنترنت الأشياء: 4 خطوات

2024 مؤلف: John Day | [email protected]. آخر تعديل: 2024-01-30 07:39

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

الخطوة 1: الوظائف كخدمة

FaaS هي فئة من الخدمات السحابية تُستخدم لبناء بنية "بدون خادم". تتيح FaaS للعملاء تطوير وظائف التطبيقات وتشغيلها وإدارتها دون بناء البنية التحتية وصيانتها.

تقدم أمازون AWS Lambda ، بينما تقدم IBM وظائف سحابة IBM. هذه الخدمات متشابهة تمامًا ، ولكن Lambda كانت الأولى من نوعها. باستخدام FaaS ، يمكنك تشغيل أجزاء من التعليمات البرمجية في السحابة وتدعم كل خدمة لغات برمجة مختلفة.

وظائف IBM Cloud: JavaScript ، و Swift ، و Java ، و Go ، و Php ، و Python ، و Ruby ، و. NET (C # F # وما إلى ذلك) ، وأي من خلال Docker AWS Lambda: JavaScript ، و Java ، و C # ، و F # ، و Go ، و Python ، و Ruby ، و PowerShell ، و Any عبر Runtime API

تدعم شركة IBM المزيد من اللغات وبواسطة docker يكون من السهل استخدام البرامج النصية المكتوبة بلغات أخرى. يمكن القيام بذلك أيضًا باستخدام Lambda ولكنه ليس فوريًا. يمكنك قراءة مثال هنا: https://aws.amazon.com/blogs/opensource/rust-runt …

كلتا الخدمتين لها حدود استخدام ، ونبلغ عنها في جدول ونبرز الأفضل.

يعتمد السعر على GigaBytes في الثانية (RAM) مع إضافة عدد الطلبات الخاصة بـ AWS Lambda ، كل خدمة لها خطة مجانية وهي متكافئة تقريبًا. كما ترى ، فإن Lambda أرخص قليلاً بالنسبة إلى GB / s ، لكن لها تكلفة مرتبطة بالطلبات التي لا توفرها Cloud Functions وبالتالي فإن التكلفة هي نفسها تقريبًا بشكل عام. بالطبع ، إذا كنت بحاجة إلى تشغيل مهام تستهلك الذاكرة وتستخدم القليل من الطلبات ، فيجب عليك استخدام Lambda. الميزة الرئيسية لوظيفة IBM Cloud ، في رأينا ، هي أن مكدسها مفتوح المصدر. يعتمد بالكامل على Apache OpenWhisk ويمكن أيضًا نشره على بنية تحتية خاصة.

الخطوة الثانية: تعلم الآلة

المجال الذي تقدم فيه حزم IBM و AWS خدمات مماثلة هو التعلم الآلي: Amazon مع SageMaker و IBM مع Watson Machine Learning. تتشابه هاتان الخدمتان إلى حد كبير في العديد من الجوانب: كلاهما يقدمان نفسيهما كأدوات لمساعدة علماء البيانات والمطورين في بناء وتدريب ثم نشر نماذج التعلم الآلي الخاصة بهم في بيئات جاهزة للإنتاج ، لكن الفلسفات التي تتبناها الشركتان تختلف قليلاً. تتيح لك كلتا الخدمتين الاختيار بين درجات مختلفة من التحكم في النماذج التي تستخدمها. في Watson ML ، لديك بعض النماذج المضمنة التي تم تدريبها بالفعل للقيام ببعض المهام المحددة للغاية: على سبيل المثال ، إذا كنت تريد التعرف على الكائنات الموجودة في الصورة ، فأنت تقوم فقط باستيراد نموذج VisualRecognitionV3 وتمريره إلى الصورة التي تريدها تريد أن تحلل. يمكنك أيضًا إنشاء "نموذج مخصص" ، ولكن في Watson ML ، يعني هذا في الغالب أخذ نموذج مبني بالفعل وإجراء تدريبنا عليه ، لذا فإن التخصيص محدود للغاية. من المهم ملاحظة أنه لا SageMaker ولا Watson ML هما الوسيلتان الوحيدتان للقيام بالتعلم الآلي على مجموعات المطورين ، إنهما مجرد خدمات تهدف إلى تسهيل حياة المطورين. تدعم منصة Watson ML أيضًا العديد من مكتبات التعلم الآلي الأكثر شيوعًا ، بحيث يمكنك حتى إنشاء نموذج من البداية باستخدام PyTorch أو Tensorflow أو مكتبات مماثلة. إما أن تستخدم هذه المكتبات مباشرة ، أو تستخدم النماذج المعدة مسبقًا ، فلا يوجد حل وسط. كما أن Watson ML لا يدعم مكتبة اختيار أمازون ، Apache MXNet ، والتي تتمتع بدلاً من ذلك بدعم من الدرجة الأولى في SageMaker.

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

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

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

الخطوة 3: تدفق البيانات والتحليلات

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

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

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

توفر Streams و Kinesis التكامل مع خدمات مختلفة للمعالجة المسبقة وتصفية البيانات الواردة قبل تمريرها إلى تحليلات البيانات ، على التوالي مع Apache Edgent و AWS Lambda. بينما تختلف هذه الخدمات اختلافًا جذريًا عن الأخرى ، فإننا سنناقشها فقط من وجهة نظر خدمتي البث. يتمثل الاختلاف الأساسي بين الاثنين في أن Apache Edgent يعمل على الجهاز ، بينما يتم تشغيل AWS Lambda على السحابة. يجلب هذا الكثير من الإيجابيات والسلبيات: من جانب Lambda ، لدينا خدمة مرنة وسهلة الاستخدام مع تكامل سلس مع Kinesis ، ولكنها تتطلب تحميل البيانات بالفعل إلى السحابة ، وبالتالي فقدان الكفاءة ودفع Kinesis أيضًا للبيانات التي سيتم تجاهلها في النهاية. من جانب Edgent بدلاً من ذلك ، لدينا أن معظم الحسابات تتم ، حسنًا ، على حافة الشبكة (وبالتالي على الأجهزة) قبل تحميل البيانات غير المفيدة على السحابة. العيب الرئيسي هو أن Edgent هو إطار عمل كبير ، والذي قد يتطلب وقتًا لإعداده وقد يكون من الصعب صيانته. هناك اختلاف آخر يمكن أن يكون ذا صلة باختيار النظام الأساسي وهو أن Edgent مفتوح المصدر بالكامل ، بينما Lambda ليس كذلك. يمكن النظر إلى هذا على أنه محترف ، نظرًا لأن الوصول إلى الكود الذي ستقوم أنت أو عميلك بتنفيذه يعد دائمًا أمرًا إيجابيًا ، سواء على أنه خدعة ، لأنه قد تكون هناك مواقف تحتاج فيها إلى دعم عاجل لا يمكن توفيره فيها جميع البيئات مفتوحة المصدر.

الميزات الأخرى التي يمكن أن نذكرها هي قابلية Kinesis للتوسع التلقائي للموارد المخصصة. في الواقع ، يتكون الجهاز الذي يقدمه من عدد مما يسمى بوحدات معالجة Kinesis (KPUs) التي تعمل بالتوازي ، حيث توفر KPU 1 vCore و 4 جيجابايت من ذاكرة الوصول العشوائي. يعتمد عددهم على احتياجات التطبيق ويتم تخصيصه ديناميكيًا وتلقائيًا (ما تدفعه هو بالفعل وقت وحدة المعالجة المركزية مضروبًا في عدد KPUs) ، فقط تذكر أن سياسة Kinesis هي فرض رسوم على KPU واحدة إضافية إذا كنت تستخدم Java تطبيق. بدلاً من ذلك ، لا توفر IBM Streams هذا النوع من المرونة ، حيث تقدم لك حاوية بها أجهزة ثابتة ، والمزيد من التفاصيل عندما نتحدث عن الأسعار. من ناحية أخرى ، يعد IBM Streams أكثر انفتاحًا من Kinesis ، نظرًا لأنه يتفاعل مع WAN عبر البروتوكولات الشائعة المستخدمة ، مثل HTTP و MQTT وما إلى ذلك ، بينما يتم إغلاق Kinesis أمام نظام AWS البيئي.

كمقارنة نهائية ، فلنتحدث عن التسعير ، واسمحوا لي أن أقول إن شركة IBM لا تعمل بشكل جيد في هذه النقطة. لقد قمنا بتكوين حلول مختلفة لثلاث فئات مختلفة (أساسية ، متطورة ، فائقة التطور) لكل من IBM و AWS ، وسنقوم بمقارنة أسعارها. في التكوين الأساسي ، لدينا AWS KPU ، مذكور سابقًا ، مقابل حل IBM بنفس الجهاز. بالنسبة إلى الأجهزة المتطورة ، لدينا 8 KPUs تعمل بالتوازي مع Kinesis وحاويتين دائمًا بالتوازي مع IBM ، لكل منها 4 vCores و 12 جيجابايت من ذاكرة الوصول العشوائي. تقدم شركة IBM دائمًا حاوية واحدة فائقة التطور مع 16 vCores و 128 جيجابايت من ذاكرة الوصول العشوائي ، بينما قمنا بحذف حل مكافئ لـ AWS ، لأنه إذا تطلب بعض التطبيقات هذه الكمية الكبيرة من ذاكرة الوصول العشوائي ، فلا يمكن تشغيلها على KPUs مختلفة. يتم التعبير عن الأسعار التي أبلغنا عنها بالدولار / الشهر مع الأخذ في الاعتبار الاستخدام على مدار الساعة طوال أيام الأسبوع. بالنسبة للتكوين الأساسي لدينا لـ IBM و AWS على التوالي 164 دولارًا و 490 دولارًا أمريكيًا ، وللأحدث 1320 دولارًا و 3500 دولارًا أمريكيًا ، بالنسبة إلى AWS الفائق الجودة لم يتم النظر فيه ولا يوجد سوى IBM بـ 6300 دولار. من هذه النتائج يمكننا أن نرى أن Kinesis يعمل بشكل أفضل للمستخدم اليومي حتى مستوى المؤسسة ، بينما يفتقر إلى الخيارات للتعامل المباشر مع تحليلات البيانات التي تتطلب قدرًا هائلاً من قوة الحوسبة. يوفر Kinesis أداءً / نسبة دولار أفضل من IBM Streams ، ويساعد أيضًا في التخصيص الديناميكي لكتل الموارد الصغيرة فقط عند الحاجة ، بينما تقدم لك IBM حاوية ثابتة. وبهذه الطريقة ، إذا كان عبء العمل الخاص بك يتسم بالذروة ، فستضطر مع شركة IBM إلى المبالغة في تقدير احتياجات التطبيق وتكوين حل في أسوأ السيناريوهات. تقدم شركة IBM رسومًا للساعات بدلاً من دفع الشهر بالكامل ، ولكنها ليست آلية مثل Kinesis.

الخطوة 4: هندسة إنترنت الأشياء

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

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

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

استخدم واجهات برمجة التطبيقات الآمنة لربط تطبيقاتك بالبيانات من أجهزتك.

إنشاء تطبيقات ضمن الخدمة السحابية المقدمة لدينا لتفسير البيانات.