AWS ו- IBM: השוואת שירותי IoT: 4 שלבים

2024 מְחַבֵּר: John Day | [email protected]. שונה לאחרונה: 2024-01-30 09:15

כיום אנו משווים שתי ערימות המאפשרות לפתח יישומי IoT בהיבט של הצעות שירות שונות.

שלב 1: פונקציות כשירות

FaaS היא קטגוריה של שירותי ענן המשמשים לבניית ארכיטקטורה "ללא שרת". FaaS מאפשר ללקוחות לפתח, להפעיל ולנהל פונקציות יישומים מבלי לבנות ולתחזק את התשתית.

אמזון מציעה AWS Lambda, IBM מציעה IBM Cloud Functions. שירותים אלה דומים למדי, אולם למבדה הייתה הראשונה מסוג זה. באמצעות FaaS ניתן להריץ פיסות קוד בענן וכל שירות תומך בשפות תכנות שונות.

פונקציות ענן של IBM: 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 קל לשימוש בסקריפטים שנכתבו בשפות אחרות. ניתן לעשות זאת גם עם למבדה אך זה אינו מיידי. אתה יכול לקרוא דוגמה כאן:

לשני השירותים יש מגבלות שימוש, אנו מדווחים עליהם בטבלה ומדגישים את הטובים ביותר.

המחיר מבוסס על GigaBytes לשניות (RAM) בתוספת מספר הבקשות עבור AWS Lambda. לכל שירות יש תוכנית בחינם והן כמעט שוות ערך. כפי שאתה יכול לראות למבדה הוא קצת יותר זול עבור GB/s אבל יש לו עלות הקשורה לבקשות שאין ל- Cloud Functions ולכן העלות כמעט זהה באופן כללי. כמובן, אם אתה צריך להריץ משימות שאוכלות זיכרון ומשתמשות בקשות מועטות, עליך להשתמש בלמבדה. היתרון העיקרי של IBM Cloud Function, לדעתנו, הוא שהערימה שלה היא קוד פתוח. הוא מבוסס לחלוטין על Apache OpenWhisk וניתן לפרוס אותו גם על תשתית פרטית.

שלב 2: למידת מכונה

תחום שבו ערימות IBM ו- AWS מציעות שירותים דומים הוא של למידת מכונות: אמזון עם SageMaker שלה ו- IBM עם ווטסון מכונת למידה. שני השירותים דומים בהיבטים רבים מאוד: שניהם מציגים את עצמם ככלי לסייע למדעני נתונים ומפתחים לבנות, להכשיר ולאחר מכן לפרוס בסביבות מוכנות לייצור את המודלים שלהם ללמידת מכונה, אך הפילוסופיות ששתי החברות מאמצות משתנות לא מעט. שני השירותים מאפשרים לך לבחור בין דרגות שליטה שונות בדגמים שבהם אתה משתמש. ב- Watson ML, יש לך כמה דגמים מובנים שכבר הוכשרו לבצע כמה משימות מאוד ספציפיות: למשל, אם אתה רוצה לזהות אילו אובייקטים קיימים בתמונה, אתה פשוט מייבא את מודל VisualRecognitionV3 ומעביר לו את התמונה שאתה רוצה לנתח. אתה יכול גם לבנות "דגם מותאם אישית", אך ב- Watson ML זה בעיקר אומר לקחת דגם שנבנה כבר ולעשות עליו את ההכשרה שלנו, כך שההתאמה האישית מוגבלת למדי. עם זאת חשוב לשים לב כי לא SageMaker או ווטסון ML אינם הדרכים היחידות לבצע למידת מכונה על ערימות המפתחים שלהם, אלא רק שירותים שמטרתם להקל על חייהם של המפתחים. פלטפורמת ווטסון ML תומכת גם ברבות מהספריות הפופולריות ביותר ללמידת מכונות, כך שתוכל אפילו לבנות דגם מאפס באמצעות PyTorch, Tensorflow או ספריות דומות. או שאתה משתמש ישירות בספריות האלה, או שאתה משתמש במודלים שהוכנו מראש, אין דרך ביניים. כמו כן ווטסון ML אינה תומכת בספריית הבחירה של אמזון, Apache MXNet, שבמקום זאת יש תמיכה מהשורה הראשונה ב- SageMaker.

הגישה של אמזון SageMaker, אפילו בעת שימוש באפשרויות מובנות, היא קצת יותר נמוכה: במקום לגרום לך לבחור מתוך דגמים מוכנים מראש, היא מאפשרת לך לבחור מתוך שפע של אלגוריתמי אימון שכבר יושמו, בהם תוכל להשתמש בעת בניית מודל בצורה מסורתית יותר. אם אלה לא מספיקים, אתה יכול גם להשתמש באלגוריתם משלך. דרך זו לעשות דברים בהחלט דורשת יותר ידע על אופן הלמידה המכונה לעומת השימוש במודל מאומן ב- Watson ML.

במבט ראשון נראה כי ווטסון ML היא הדרך "הקלה ומהירה", כאשר אמזון SageMaker היא הדרך המורכבת יותר להתקנה. יתכן שזה לא לגמרי נכון מכמה נקודות מבט, מכיוון ש- SageMaker בנוי כך שהכל יופעל על מחברת Jupyter, בעוד שבאותן התכונות ב- Watson ML יהיה עליך להגדיר שירותי משנה רבים ושונים מממשק המשתמש באינטרנט. לעיבוד המקדים של הנתונים יש גם חללים ייעודיים בשירות IBM, בעוד ש- SageMaker מסתמך על שתעשה הכל מהקוד במחברת שלך. זה פלוס העובדה שמחברות Jupyter אינן בדיוק הבחירה הטובה ביותר מבחינת הנדסת תוכנה, עשויות למנוע מ- SageMaker להתדרדר היטב בייצור. לשני השירותים מנגנונים די טובים ופשוטים לפרוס את המודל שלך ולהפוך אותו לממשקי API זמינים בעולם החיצון.

לסיכום, ווטסון ML מתפקדת טוב יותר בפרויקטים ענקיים בהם מחברות Jupyter מתחילות להראות את גבולותיהן, ושאין צורך בהרבה התאמה אישית במה שהדגם עצמו עושה. SageMaker הרבה יותר טוב כשאתה צריך יותר גמישות בהגדרת האלגוריתמים, אבל כשאתה משתמש בו אתה צריך לקחת בחשבון את העובדה שאתה צריך להסתמך על מחשבי Jupyter Notebook, שעשויים להיות לא קנה מידה טוב בייצור. פתרון יכול להיות לנתק את שאר הקוד מהדגם כמה שיותר, כך שהקוד במחברות בפועל לא יגדל מדי ונוכל לארגן טוב יותר את התוכנה שלנו במודולים האחרים שפשוט משתמשים בממשק ה- API של הדגם שלנו..

שלב 3: הזרמת נתונים וניתוח

שירותי הזרמת נתונים הם בעלי חשיבות מכרעת בטיפול וניתוח זרימות גדולות של נתונים בזמן אמת. זרימה זו יכולה להיות מהענן למכשיר המשתמשים, כמו הזרמת וידאו, או מהמשתמשים לענן, כמו טלמטריה של IoT וקריאות חיישן. במיוחד במקרה השני, יכול להיות מצב בו מקורות בודדים מעלים כמויות קטנות של נתונים, אך כאשר אנו שוקלים את התפוקה הכוללת, הנובעת מכל המכשירים, היא צורכת רוחב פס ניכר, ולכן הגיוני להשתמש בשירות המתמחה בטיפול כזה זרימות נתונים. בלי לטפל ישירות בזרימה רציפה זו, נצטרך לחבוט את המידע הנכנס לאחסון זמני ובפעם השנייה לעבד אותו עם מנוע חישובי כלשהו. הבעיה של גישה אחרונה זו היא שנצטרך לתאם שירותים שונים יותר כדי להשיג את מה ששירות זרם נתונים אחד כבר עושה לבד, ומגדיל את מורכבות התחזוקה והתצורה של היישום. בנוסף, החוצץ יכול באופן עקרוני להפוך את הבקשה שלנו לא עוד לזמן אמת, שכן כדי שעיבוד פריט יש צורך שגם כל שאר הפריטים לפניו יעובדו, והוספת מדיניות עדיפות למאגר יכולה, שוב, להגדיל את המורכבות באופן דרסטי. לסיכום, שירותי הזרמת הנתונים מציעים טיפול בזרימת נתונים בזמן אמת, עם תצורה קלה, ויכולים לספק ניתוח על הנתונים הנכנסים. כאן אנו משווים את שני שירותי הסטרימינג העיקריים של מחסנית IBM ו- AWS, כלומר IBM Streams ו- AWS Kinesis.

אנו מתחילים לציין כי כל התכונות הבסיסיות שאנו עשויים לרצות משירות סטרימינג מוצעות הן על ידי IBM והן על ידי AWS. תכונות אלה כוללות קצב עיבוד כמעט אינסופי, זמן השהיה נמוך וניתוח נתונים בזמן אמת. מכיוון שאנו מדברים על שירותים מקצועיים, שניהם מציעים כלים ברמת ייצור לפריסה ואוטומציה.

כשמדברים על ניתוח נתונים, שני השירותים מציעים זאת כאופציה, מה שגורם לך לשלם רק אם אתה צריך את זה או לא. במקרה של Kinesis, כאשר אינך צריך ניתוח אלא רק טיפול בזרימת נתונים, המחירים נגבים לכל GB מעובד במקום זמן עיבוד, כמו במקרה של IBM. התמחור ל- GB יהיה בדרך כלל פחות יקר מהמחיר לכל פעם, מכיוון שאתה משלם רק עבור התנועה הנכנסת. להמשך פוסט זה נשקול הן IBM Streams והן AWS Kinesis כשהתכונה לניתוח נתונים מופעלת.

זרמים וקינסיס מספקים אינטגרציה עם שירותים שונים לעיבוד מראש וסינון הנתונים הנכנסים לפני שהם מעבירים אותם לניתוח נתונים, בהתאמה עם Apache Edgent ו- AWS Lambda. שירותים אלה אמנם שונים זה מזה זה מזה, אך נדון בהם רק מנקודת מבטם של שני שירותי הסטרימינג. ההבדל המהותי בין השניים הוא ש- Apache Edgent מבצעת במכשיר, בעוד AWS Lambda מבצעת בענן. זה מביא הרבה יתרונות וחסרונות: מצד למבדה יש לנו שירות גמיש וקל לשימוש עם אינטגרציה חלקה עם Kinesis, אבל זה דורש את העלאת הנתונים כבר לענן, ובכך להפסיד ביעילות ולשלם גם ל- Kinesis עבור הנתונים שבסופו של דבר יימחקו. מצד אדג'נט במקום זאת, יש לנו שרוב החישוב נעשה, ובכן, בקצה הרשת (ובכך במכשירים) לפני העלאת נתונים חסרי תועלת בענן. החיסרון העיקרי הוא ש- Edgent היא מסגרת גדולה, שעשויה לדרוש זמן התקנה ויכולה להיות מורכבת לתחזוקה. הבדל נוסף שיכול להיות רלוונטי בבחירת הפלטפורמה הוא שאדג'נט היא קוד פתוח לחלוטין, למבדה לא. אפשר לראות את זה כאחד המקצוען, שכן גישה לקוד שאתה או הלקוח שלך תבצע זה תמיד דבר חיובי, שניהם בתור חיסרון, כי יתכנו מצבים שבהם אתה זקוק לתמיכה דחופה שלא ניתן לספק בה. כל סביבות קוד פתוח.

תכונות נוספות שאנו יכולים להזכיר הן ההרחבה האוטומטית של קינסיס של המשאבים שהוקצו. ואכן, החומרה שהיא מציעה מורכבת ממספר יחידות עיבוד Kinesis (KPUs) הפועלות במקביל, כאשר KPU אחת מציעה 1 vCore ו -4 GB זיכרון RAM. מספרם תלוי בצרכי האפליקציה והם מוקצים באופן דינמי ואוטומטי (מה שאתה משלם הוא אכן זמן המעבד כפול מספר ה- KPU), רק זכור שזו מדיניות Kinesis לחייב אותך ב- KPU אחד יותר אם אתה משתמש ב- Java יישום. IBM Streams, במקום זאת, אינה מספקת גמישות מסוג זה, ומציעה לך מיכל עם חומרה קבועה, פרטים נוספים כאשר אנו מדברים על תמחור. מצד שני, IBM Streams פתוח יותר מקינסיס, מכיוון שהוא מתממשק ל- WAN באמצעות פרוטוקולים נפוצים כמו HTTP, MQTT וכן הלאה, בעוד קינסיס סגור למערכת האקולוגית של AWS.

כהשוואה סופית בואו נדבר על תמחור, ותנו לי לומר ש- IBM לא עובדת מצוין בנקודה זו. הגדרנו פתרונות שונים לשלוש קטגוריות שונות (בסיסיות, מתקדמות, גבוהות במיוחד) הן עבור IBM והן עבור AWS, ואנו הולכים להשוות את המחיר שלהם. בתצורה הבסיסית יש לנו AWS KPU אחד, שהוזכר קודם לכן, נגד פתרון IBM עם אותה חומרה. עבור המתקדמים יש לנו 8 KPUs הפועלות במקביל ל- Kinesis ו- 2 מכולות תמיד במקביל ל- IBM, כל אחת עם 4 vCores ו -12 GB של זיכרון RAM. תמיד יבמ מציעה ברמה הגבוהה במיוחד מיכל יחיד עם 16 vCores ו -128 GB של זיכרון RAM, בעוד שהשמטנו פתרון שווה ערך ל- AWS, שכן אם יישום כלשהו דורש כמות גדולה של זיכרון RAM זה לא היה אפשרי להריץ אותו על KPUs שונים. המחירים שאנו מדווחים מתבטאים בדולר לחודש בהתחשב בשימוש 24/7. עבור התצורה הבסיסית שיש לנו עבור IBM ו- AWS בהתאמה 164 $ ו- 490 $, עבור 1320 $ ו- 3500 $ ברמה הגבוהה ביותר, עבור AWS ברמה הגבוהה ביותר לא נחשב ויש רק IBM עם 6300 $. מתוצאות אלה אנו יכולים לראות כי קינסיס פועל טוב יותר עבור המשתמש היומיומי עד לרמה הארגונית, בעוד שאין לו אפשרויות להתמודד ישירות עם ניתוח נתונים הדורשים כוח מחשוב עצום. Kinesis מספקת יחס ביצועים/דולר טובים יותר מאשר IBM Streams, גם בעזרת הקצאה דינאמית של בלוקים של משאבים קטנים רק בעת הצורך, בעוד IBM מציעה לך מיכל קבוע. בדרך זו, אם עומס העבודה שלך מתאפיין בשיאים, עם IBM אתה נאלץ להעריך יתר על המידה את צרכי היישום שלך ולהגדיר פתרון בתרחיש הגרוע ביותר. IBM מציעה דמי שעות במקום לשלם את החודש המלא, אך היא אינה אוטומטית כקינסיס.

שלב 4: אדריכלות IoT

התצורה של מכשירים עבור aws iot די קלה בהשוואה ל- ibm watson iot. מכיוון שב- ibm watson iot האימות הוא לכל מכשיר עם אסימון וברגע שהוא יציג את האסימון הוא לעולם לא יוצג שוב. מגיע שוב לתמחור ibm watson iot יקר למדי בהשוואה ל- aws iot. לכן, המחיר בחיובי ibm watson iot מבוסס על כל מכשיר, אחסון נתונים, תעבורת נתונים. אבל ב- aws iot אנחנו יכולים לשלם את הסכום פעם אחת ונוכל להוסיף עוד מכשירים ונתונים שפורסמו מהמכשירים ונמסרו למכשירים.

התחל עם המכשיר שלך- בין אם מדובר בחיישן, שער או משהו אחר- ותן לנו לעזור לך להתחבר לענן.

נתוני המכשיר שלך תמיד מאובטחים כאשר אתה מתחבר לענן באמצעות פרוטוקול הודעות MGTT פתוח או קל משקל או HTTP. בעזרת פרוטוקולים ואדום צומת אנו יכולים לחבר את המכשיר שלנו לפלטפורמת iot ולגשת לנתונים חיים והיסטוריים.

השתמש בממשקי ה- API המאובטחים שלנו כדי לחבר בין האפליקציות שלך לנתונים מהמכשירים שלך.

צור יישומים בשירות הענן הנתון שלנו לפרש נתונים.