מחשבות על Nano Scale

Print Friendly, PDF & Email

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

קחו לדוגמא את עניין הוירטואליזציה ואם תקפצו ל-IBM, תראו שהחברה מימשה רעיונות וירטואליציה הרבה לפני כולם ב-Main Frame שלה. קונטיינרים? קיימים במערכות יוניקס במימושים שונים כבר עשרות שנים. עם הזמן המימושים השתפרו ולעולם ה-PC נכנסה הוירטואליזציה ע"י כל מיני חברות ובראשם VMWare ובכל מה שקשור לקונטיינרים – Sun, IBM ואחרות מימשו בצורות שונות עד שהגענו ללינוקס עם קונטיינרים כפי שהם מוכרים היום ולאחרונה גם מיקרוסופט הצטרפה לעגלת הקונטיינרים (הם נכנסו לוירטואליזציה מעט אחרי ש-ESXI-3 של VMWare יצא).

תחומים "חדשים" (שוב, הם היו ממזמן ב-Main Frame במימוש שונה בעבר) היו ה-Micro Services, ה-Serverless ומושגים שהיום חזרו להיות טרנדיים רק שהם היום הרבה יותר נוחים. קחו לדוגמא את אמזון שממשת את עניין ה-Serverless בעזרת מספר חלקים קריטיים כמו Lambda, DynamoDB ועוד. בתצורה הזו אתה לא חושב על שרתים, אתה לא חושב על קונטיינרים או על תצורת מחשוב קלאסית. המושגים שונים לגמרי.

בעולם המחשוב כיום, כשמריצים אפליקציה על VM או על קונטיינר, כמעט תמיד יווצר בזבוז משאבים. אתה מקים VM של 4 ג'יגהבייט בשעה שהאפליקציה צריכה 2.5 ג'יגהבייט.נכון, טכנולוגיית Memory Balooning פותרת בעיה זו בוירטואליזציה מקומית כמו ESXI, אבל מה קורה בענן ציבורי? שם הספק לא כל כך יכול להשתמש בטכנולוגיה כזו כי הוא לא "משחק" את המשחקים של Over Provisioning מטורף כמו ספקי הוסטינג קטנים. ב-ESXI אפשר לקבוע שמכונה תוזז למכונה פיזית אחרת אם היא פתאום צריכה הרבה יותר משאבים ממה שהיא היתה צריכה לפני זמן קצר, בענן קצת קשה לעשות זאת וכלקוח אינך יכול להעביר את ה-Instance שלך ממכונה פיזית אחת לשניה כמו ב-vSphere. הבעיה קיימת פחות (אך עדיין קיימת) עם קונטיינרים – גם שם אתה צריך להגדיר לקונטיינר כמה זכרון יהיה לאפליקציה/ות בתוך הקונטיינר אולם אם הן לא משתמשות בזכרון, אז נוצר בזבוז (שוב, עם אותם הסתייגויות כמו ל-VM).

הפתרון של Micro Servicess הוא פתרון טוב, אבל לעניות דעתי פתרון טוב יותר יהיה ברמת ה-Nano.

בוא נדמיין משהו: יש לכם שדה גדול בגודל מספר דונמים שבו אנו מגדלים ירקות מסויימים. איך נשקה את השדה? או עם ממטרות, או עם טפטפות, לא? הבעיה עם 2 הפתרונות זה שלא מדובר בפתרון מדויק. ממטרות יכולות להתיז כמה מטרים קדימה ברדיוס מסוים, אבל אז צריך להתחשב בצמחים שנמצאים מתחת לרדיוס הזה ואותם ממטרה אחרת צריכה להשקות. בטפטפות העניין יותר מדויק כי שמים את הצינורות קרוב לצמחיה, אבל עדיין הכל תלוי בשורשים ואורכם. 2 השיטות עובדות, אבל השיטה הטבעית לעומת זאת (גשם) עושה עבודה הרבה יותר טובה מכיוון שהיא מכסה את כל השטח בצורה אחידה וכל עוד הגשם לא "נתקע" במקום או שאינו מגיע בצורות מזיקות (סופות, ברד) – הצמחים יקבלו 100% מצרכי השתיה שלהם. תחשבו על כך: טיפות גשם שכל אחת מהם היא כמות מאוד קטנה (ב-CC) לא עושה כמעט כלום – אבל בתצורת גשם – היא פותרת בעיה קריטית.

אותו דבר בתחם אחר (שבינתיים אנחנו שומעים עליו, הרבה פחות רואים אותו בשטח) – ה-Nano Bots, רובוטים מאוד מזעריים שאמורים להיות מוחדרים לגוף בזריקה (או בליעה? תלוי בטכנולוגיה) ואמורים לעשות פעילות ספציפית מסויימת. נניח לתקוף תאי סרטן ולהרוג אותם, כלומר הרובוטים הללו אינם מתוחכמים, הם אמורים להגיע לנקודה X, לעשות משהו ספציפי נקודתי וזהו.

תארו לכם שאפליקציות שיש כיום – יהיה ניתן לפרק אותם ל-Nano Scale, כלומר פיסות קוד שצריכות קילובייטים (ולא מגהבייטים או ג'יגהבייטים) והם יכולים לתקשר עם פיסות קוד אחרות במהירות ללא צורך בבנייה של תשתית עם האמצעים הרגילים כמו Load Balancer או HAProxy או דברים כאלו. פיסות הקוד (בחלוקה לדוגמא שכל פונקציה היא "נאנו מכונה") יוכלו לבצע פעולות, לשדר את התוצאה ולמות ופיסות אחרות יכולות לקום והכל תוך מילישניות – לפי הצרכים. הדבר שכן קיים כיום בתצורה מאוד דומה היא ב-GPU (כמו של nVidia) ששם יש אלפי ליבות וכל ליבה יכולה לעשות דברים מאוד בסיסיים אך עבודה של מאות ליבות ביחד יוצרת משהו שלם שמועבר למחשב.

כיום יש לנו משהו קרוב לכך ב-Micro Services יחד עם ה-Serverless שנותן בערך את אותו רעיון, אך עדיין זהו דבר בעייתי מכמה סיבות:

  • קשה לתרגם אפליקציה קלאסית לתצורה זו
  • החלקים אינם קטנים מספיק (זה לא בעיה כשזה רץ בענן, זה כן בעיה אם זה ירוץ על Micro Controller Unit – כלומר MCU) או על IOT או על מערכות IOT עם כמות זכרון קטנה וכו'.
  • הפתרונות הטכנולוגיים הללו עדיין לא זמינים בתצורה קלה ונוחה להרצה מקומית על תשתית וירטואליזציה של חברות או על PC מקומי בקלות.

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

השאלה – מי ירים את הכפפה.

2 תגובות בנושא “מחשבות על Nano Scale”

  1. האם יש כבר חברות שעשו את המהלך?

    כמה הפתרון שהצעת יעיל יותר בהשוואה לפתרונות העכשיווים?

     

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

להגיב על אריק לבטל

האימייל לא יוצג באתר. שדות החובה מסומנים *

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