מדריך לשימוש באפליקציות דו-צדדיות עם מחשוב קצה

כולם מדברים על מחשוב קצה בימינו, אך מעטים מבינים מה זה, הרבה פחות מה לעשות איתו. באופן תמציתי, מחשוב קצה פירושו עיבוד קרוב למקור הנתונים, בין על החיישן או קרוב לשער. אם תרצה לדעת כיצד ה- IT יכול לנהל בצורה הטובה ביותר את מחשוב הקצה כחלופה, בדוק את "צריך IT לחשוב על מחשוב 5G ו- Edge Cloud", טור מאת וויין ראש, עמיתי ותורם ה- PCMag IT Watch. אך לעניין מאמר זה, נוכל להתחיל בהסבר של חברת מחקר השוק IDC, המגדירה את מחשוב הקצה כ"רשת רשת של מרכזי מיקרו-נתונים "שיש בהם" טביעת רגל של פחות מ -100 מטרים רבועים."

בדומה לרוב המונחים החדשים במרחב הטכנולוגי, "מחשוב קצה" נמצא בשימוש נרחב וקושר למגוון טכנולוגיות buzzword אחרות, כולל blockchain, רשתות מסירת תוכן (CDNs), מחשוב רשת, מחשוב רשת ו- peer-to- מחשוב עמיתים. המשימה הנפוצה, כל הטכנולוגיה שמטמיעה בשילוב עם מחשוב קצה, היא להאיץ כל ניתוח נתונים ופעולות קשורות על ידי קיצור המרחק בין היכן שעובדים הנתונים לאיפה לתוצאה הסופית של פלט זה תהיה השפעה.

כשמדובר בהפיכת תובנות הבינה העסקית המנוסה שלך (BI) לתובנות מעשיות, זהו שיקול מרכזי. אבל למרות ש- BI (במיוחד ניתוחים בעלי זמן אחוי נמוך) ומחשוב קצה נראה כי הם תואמים בשמים הטכניים, יש הרבה מה לקחת בחשבון לפני שמשלבים את השניים.

אנליטיקס בקצה לעומת סטרימינג אנליטיקס

החשיבות של מחשוב קצה לאנליטיקה ברורה ברגע שאתה מבין שאין דרך מעשית אחרת להעביר צונאמי מתמשך של Internet of Things (IoT) לענן מבלי ליצור השהיה בלתי ניתנת לבלתי נשמעת ונקודה אחת של פקק רשת. נושא ההשהיה הזה יכול להוות קטלני ביישומי אנליטיקה מתעוררים רבים, כמו נהיגה אוטונומית. הצפת הנתונים תעביר אותך מפס רחב לצוואר בקבוק בפחות זמן מכפי שנדרש לומר "הזרם את זה, סקוטי."

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

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

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

קצה ענן מול ענן

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

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

"לא רק שהם מגיבים לתנאים שנצפו, אלא שהם לומדים ומתאימים את עצמם לאורך זמן", אמר ג'ונתן וי קרי, PhD., מדען / מהנדס מערכות משובצות ואלחוטיות במעבדה הלאומית בצפון-מערב השקט האמריקני (PNNL). "לדוגמה, מערכות הזרקת דלק מודרניות ישגיחו על דפוסי הנהיגה של המכונית על מנת לייעל את צריכת החשמל ואת יעילות הדלק. אופי בזמן אמת של נתונים אלה לא יאפשר לעבד בשום מקום אחר מאשר בקצה."

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

Vee Cree, "כשמדברים על מכשירי IoT, השיקולים כמעט מנוגדים לענן. "בדרך כלל מכשירי IoT בעלי אחסון ועיבוד מוגבלים, קישוריות לסירוגין לעולם החיצון, ועשויים להיות מופעלים על ידי סוללה. ערך המפתח במכשירים אלה הוא היכולת שלהם להפוך את ערכי החיישן הגולמי העומדים לרשותם למידע משמעותי."

מכשירי מחשוב קצה הגרפיים למעלה הודפסו מחדש עם אישור מחברת TECHnalysis.

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

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

משחק הקומבו והענן נפוץ פשוט מכיוון שהוא עובד; זה ממנף את הטוב משני העולמות אבל זה לא המשחק היחיד בעיר. למעשה, 36 אחוז מניתוחי הקצה ממוקמים במרכז הנתונים הארגוני, 34 אחוז בקצה, ו -29 אחוזים בענן, על פי "מחשוב על הקצה: הבהרה בסקר", דו"ח מאת בוב אודונל, הנשיא ואנליסט ראשי במחקר TECHnalysis. משמעות הדבר היא שיש אפשרויות ליישום ניתוח קצה. הבחירה תלויה לחלוטין במה שאתה מנסה לעשות ובתנאים שבהם אתה מנסה להשיג מטרה זו.

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

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

גרפיקה ממחשוב ערפל שלמעלה הודפסה בהרשאה מ- Cisco Systems, Inc.

דה-ערפל בענן הקצה

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

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

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

בקיצור, אין הסכמה לגבי מהי מחשוב קצה, אבל הרבה אנשים שאומרים כי עריכת הבעיה לא עוזרת. על פי דוח מחקר ה- TECHnalysis שהוזכר לעיל, "יותר אנשים חושבים כי מחשוב קצה מורכב מנקודות קצה (29.8 אחוז) מאשר שערים (13.2 אחוזים), אך 44 אחוזים חושבים ששניהם שניהם."

בכל מקרה, "יישום השימוש הסופי מניע בסופו של דבר את צרכי המערכת ומטרתו למצוא איזון בין היתרונות של העיבוד בקצה או הענן", אמר Vee Cree של PNNL.

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

ממשקי API, אפליקציות ומערכות אקולוגיות

באופן כללי, אפליקציות המשמשות יחד עם מחשוב קצה מכוונות להשיג מהירות ויעילות. כאן אתה פחות סביר שתמצא אפליקציות בינה עסקית עצמאית (BI), אלא פונקציות BI משובצות וכמובן, ממשקי תכנות יישומים (API) כדי לחבר נתוני IoT לאפליקציות BI ומסגרות קיימות בענן.

"הרעיון של מחשוב קצה מסייע לחברות לאמץ את היתרונות של מחשוב ענן גם בתרחישים שבהם חביון וקישוריות הם נושאים. יישומים מסוימים עוסקים בגודל של נתונים או בדרישת מהירות האוסרים על טריפה עגולה לענן ובמקרים כאלה טבלו. אנליטיקה המוטמעת באפליקציות המקומיות מספקת תובנות במהירות ", אמר מארק ג'ואט, סמנכ"ל שיווק מוצרים ב- Tableau Software.

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

Tableau הוא לא ספק ה- BI היחיד שעובד או עם נתונים בקצה. מיקרוסופט הצביעה על שניידר אלקטריק, אחד מלקוחותיה כמחקר מקרה. לדברי שניידר אלקטריק, אפליקציית קצה שעושה תחזוקה חזויה על מוט שמן, משתמשת ב- Azure Machine Learning ו- Azure IoT Edge כדי לשפר את הבטיחות ולהקטין אירועים באזורים מרוחקים, אמר דובר מיקרוסופט. עיבוד הנתונים מתבצע במכשיר. ניתן להשיג זאת על ידי הבאת מודיעין ענן - דגמי ML שהם אימנו בענן - למכשיר הקצה עצמו. זה מאפשר זיהוי מהיר יותר של חריגות על בסיס מערך נתוני האימונים הגדול.

בינתיים, IBM Watson מדווחת על מקרים רבים על השימוש בהם, כולל ניתוחי קול ושיחה של התקנים, ניתוח ניתוח תמונות ווידאו ומערכת ניתוח אקוסטית לתחזוקה ובטיחות.

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

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

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

אפליקציות מחשוב קצה לפי המספרים

אם יש לזכור כי מחשוב קצה נמצא בחיתוליו, אין זה מפתיע שרק התנפצות של יישומי מחשוב קצה הם חדשים (39 אחוז), כך על פי מחקר שפרסם TECHnalysis. הרוב (61 אחוז) הם יישומי ענן שהועברו. עם זאת, להלן יישומי המחשוב העליונים:

ניתוח פעולות (44 אחוז)

ניטור תהליכים (35 אחוז)

פיקוח על עובדים (32 אחוז)

ניטור נכסים מרחוק (28 אחוז)

תאימות במקום העבודה / בטיחות (24 אחוז)

תחזוקה חזויה (22 אחוזים)

במקום מעקב אחר נכסים פיזיים (20 אחוזים)

חמש הסיבות העיקריות להעברת יישומי ענן לקצה, על פי אותו דו"ח מחקר ניתוח TECHnalysis, הן שיפור האבטחה, הפחתת עלויות, הפחתת השהיה, שיפור השליטה המקומית והפחתת תנועת הרשת.

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

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

במקרים כאלה אפליקציות בקצה עובדות רק עם נתונים רלוונטיים; יש שיקראו לזה "נתונים חכמים". מדוע להרתיח את הים כשאפשר לראות בקלות פרטים חשובים? יישומי נתונים חכמים הופכים את השימוש לשימוש בנקודת האיסוף ויכולים גם להחליט אילו נתונים ישלחו לענן לצורך מיזוג וניתוח נוספים ביישומי BI מסורתיים. באופן זה, כריית נתונים מותאמת לאפקט עסקי מרבי.

4 טיפים לאסטרטגיית מחשוב ה- BI וה- Edge שלך

קל יחסית לקפוץ על מגמת מחשוב הקצה ולהחליט להתחיל בהעברת אפליקציות מהענן. אבל הקפצה לפעולה ללא אסטרטגיה תהיה טעות חמורה. זוכר את הימים הראשונים של IoT כאשר דברים אקראיים כמו טוסטרים התחברו במהירות לאינטרנט ואז הוצגו בגאווה ב- CES הבא?

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

1. הערך מחדש את משחק ה- IoT הנוכחי שלך להזדמנויות נוספות לכריית נתונים. לדוגמה, חנווני או יצרן עשויים לרצות להשתמש בנתונים משרשרת האספקה ​​שלו, כמו חיישני קירור והובלה, כדי לקבוע או לאמת את מקור חומרי הגלם. מידע כזה שנוסף לבלוקצ'יין לקיימות יכול לשמש בשיווק כדי למשוך צרכנים מודעים לסביבה.

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

חפש הזדמנויות להפיק יותר מה- IoT שיש לך. מה עוד אפשר לעשות עם הנתונים שהם מייצרים? באילו נתונים אחרים אתה יכול להשתמש בהם כדי לאסוף ולעבד?

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

מקום טוב ללמוד יותר על פיתוח אפליקציות לקצה הוא ועידת OpenDev, המאורגנת על ידי קרן OpenStack. OpenStack הוא פרויקט מחשוב ענן בקוד הפתוח, וזה פשוט קורה שמחשוב קצה הוא נושא חם שם. זה קורה גם שקוד פתוח הוא חם במחשוב קצה, כמו שהוא כמעט בכל המחשוב. תוכל גם לשקול אפליקציות המוצעות על ידי ספקי מחשוב קצה וניתוח משובץ שמספקים ספקי אפליקציות BI.

3. בחר טק חדש שתרצה להשתמש בו. אתה יכול לבקש מהספקים לתת לך הדגמה כדי שתוכל לקבל תחושה באיזה טק אתה רוצה להשתמש, באילו אפליקציות זמינות וקצת הנחיות לפיתוח אפליקציות בשביל זה. לדוגמה, Amazon Web Service (AWS) ו- AWS Greengrass, Microsoft Azure IoT Edge, ו- Cisco ו- IBM Watson IoT מציעים תערובת של טק כמו גם ניתוח ואפליקציות למחשוב קצה IoT.

אתה יכול גם לבדוק מגוון רחב של ספקי משחק טהור על ידי blockchain, CDN, עמית לעמית, וספקים אחרים. אך אל תתעלם מענקיות הטכנולוגיה דוגמת Dell Inc., IBM Corp. ו- Hewlett Packard Enterprise (HPE), אשר כל אלה נדרשו להוסיף יכולות אחסון ומחשוב ואנליטיקה נוספות לחומרה שלהן כדי להפוך אותם למכשירי קצה.

קבל תחושה של האפשרויות שלך לפני שתתחיל להעריך ברצינות ספקים. כמו כן, קח מלאי של סוגי ה- IoT tech שהחברה שלך משתמשת בה כיום ואת הסוגים שהיא רוצה להוסיף, לפני שתתחיל לדבר עם הספקים. ככה, סביר יותר שתשאר על המסלול.

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

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