הבלוג של חץ ביז

לטלטל את הספינה

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

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

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

ישראל זכתה למקום די גבוה אצל חברות רבות בתנאים שציינתי לעיל, ומקומות גבוהים גם זוכים להשקעות מאותן חברות ופרויקטים יוקרתיים יגיעו לאותן סניפים באותן מדינות. קחו לדוגמא את אמזון שמפתחת את ה"כתר" שלה מבחינת מעבדים (מעבדי ה-Graviton) פה בהרצליה פיתוח, אינטל שמפתחת פה מעבדי דסקטופ שונים, אפל שפיתחה שבבים מסויימים וכנראה תפתח פה מעבדים חדשים מתוצרתה, נבידיה (לשעבר Mellanox) שפיתחו ביוקנעם את ה-DPU הראשון ויש דוגמאות רבות נוספות. כל אלו מפותחים פה בארץ ולא במדינות כמו סין שגם שם יש לאותן חברות R&D, מכיוון שהסיכוי לגניבת IP בסין הרבה הרבה יותר גבוה מהסיכון בישראל. בגלל זה פה מפתחים מעבדים, ושם מפתחים דרייברים/מודולים.

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

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

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

הפרטים לגבי הפריצה ל-Lastpass

בימים האחרונים יצאו החדשות העדכניות והנכונות לגבי הפריצה ל-Lastpass שאירעה לפני מספר חודשים. בהתחלה החברה לא ממש ששה לספר בהרחבה מה נפרץ ומה נגנב, ואילו עתה – יש יותר פרטים.

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

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

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

אולם לשם פריצת ה"כספת" – הפורץ יצטרך את כתובת המייל והסיסמא. בלי הפרטים הללו, ה"כספת" היא לא יותר מאשר ערימת זבל דיגיטלי, ולכן – מי שהגדיר סיסמא מורכבת, סביר להניח שהפורצים לא יצליחו לפרוץ ל"כספת" הגנובה שלו. מצד שני, למי שהגדיר סיסמא כמו abcd1234! – יכול להיות ששם הפורצים כן יצליחו לפרוץ, אם הן ינסו את הסיסמא מול ערימה שלמה של כתובות מייל. מכיוון שהמידע גנוב ונמצא (בסבירות גבוהה) offline, הפורצים יכולים להריץ סקריפטים של שילוב כתובות מייל + Rainbow Table על מנת להצליח אולי לפרוץ לחלק מאותן "כספות".

האם כניסה לאתר או לתוסף ושינוי הסיסמא יעזור? הדבר יכול אולי לעזור במקרים עתידיים אם יפרצו ויגנבו "כספות" שוב, אולם לגבי מה שנגנב – שינוי סיסמא לא יסייע במאומה.

אז, אם יש לך חשבון ב-Lastpass ושמרת דרכו סיסמאות רבות לאתרים חדשים, אך סיסמת ה-master שלך (אותה סיסמא שמקישים כדי להיכנס ל-Lastpass) היתה סיסמא קלה לניחוש, יהיה מומלץ שתיכנס לתוך אותו Vault ותתחיל לחפש מהם האתרים החשובים שנמצאים, ולשנות סיסמא בכל אחד מהם. תהליך ארוך, מייגע – אבל זה המחיר לסיסמאות חלשות.

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

המעבר ל-DPU

(הערת Off topic: פוסט זה ופוסטים בעתיד יכתבו בלשון נקבה. מדוע? הפרטים נמצאים כאן)

עולם הוירטואליזציה קיים כבר יותר מ-20 שנה, והפתרונות עברו מספר "סבבים" של שינויים מהותיים בפתרונות, להלן פירוט (ברשותכם, אינני מתכוונת להיכנס לפרטים של רמת Hypervisor וכו' שגם הם השתנו, אך הדבר אינו רלוונטי לפוסט זה):

סיבוב ראשון – פתרונות כמו ESX/ESXI ופתרונות וירטואליזציה של מתחרים התמקדו בכך שישנם חלקים פיזיים שונים שמרכיבים את פתרון הוירטואליזציה: יש פתרון אחסון יעודי, יש מתגים ונתבים, יש חומת אש יעודית ועוד מספר "ברזלים" שנותנים שרותים משלימים – ויש את כל שרותי ה-Compute שמתקבלים מהשרתים. כל דבר – בנפרד.
סיבוב שני – קונסולידציה – פתרונות כמו vSAN של VMware ופתרונות מתחרים – מעבירים את השרותים המשלימים ל-Compute – אל תוך ה-Nodes עצמם. אחסון? הכנס דיסקים ונקים. רשת? יש NSX ופתרונות אחרים שייתרו פתרונות "ברזלים" יעודיים לטובת פתרון וירטואלי, כך שבסופו של יום, מערכת כזו תהיה בנויה משרתים עם דיסקים, כרטיסי רשת ומספר מתגים פשוטים ותו לא. הכל מוקם, מוגדר ומתוחזק בתוך פתרון הוירטואליזציה.

הסיבוב הנוסף הוא בעצם "חצי סיבוב". השינוי העיקרי הפעם הוא שאנחנו מוציאים החוצה מעבודת המעבד כל מה שקשור לאבטחה, תעבורת רשת, אחסון, הצפנה וכו' – ואנחנו מעבירים את הכל לדבר שנקרא SmartNIC (או כפי ש-NVIDIA ו-AMD ואחרים רוצים שתקראו לזה: DPU. אינטל רוצים שתקראו לזה: IPU).

להלן תרשים שיפשט את הדברים:

(קרדיט: The Next Platform)

כפי שאנו רואים, ה-DPU (מצד שמאל למטה בתרשים לעיל) הוא זה שיריץ את שרותי ה-ESXI וכל שרותי ה-Management (לשם כך ה-DPU מכיל מעבד ARM עם מספר ליבות וזכרון) והשרת עצמו יריץ מערכת מינימלית שמכילה Hypervisor או כל מערכת הפעלה יעודית "על הברזל" – והמערכת תתממשק אל ה-DPU, כך שה-DPU בעצם ינהל את השרת והשרותים.

מדוע בעצם עושים זאת? הסיבה לכך די פשוטה: אין זה משנה איזה מעבד X86-64 קיים לך בשרת, בין אם מדובר ב-Xeon של אינטל או ב-EPYC של AMD, המעבדים הללו טובים בדברים מסויימים כמו Compute, אך פחות טובים בכל מה שקשור לתקשורת, הצפנות, תעבורת רשת גבוהה, אחסון ברמה ובביצועים של SAN וכו', ודברים אלו יכולים להתבצע ביעילות עם שבבים יעודיים (ASIC או FPGA, תלוי ביצרן, בפתרון וכו') ולשם גם VMWare וגם היצרניות האחרות (חוץ מ-AMD, אינטל ו-NVIDIA, גם חברות אחרות מתכוונות להציע DPU משלהן, כמו Marvell, ברודקום וכו') רוצות להיכנס, ובמילים אחרות – מה שהיה פרויקט Project Monterey בעבר, עכשיו זה חלק אינטגרלי מ-vSphere 8 שיוצא.

מאיפה בעצם הגיע הרעיון לכך? התשובה די פשוטה: ספקי ענן ציבורי, ובמיוחד AWS. רוב השרתים ב-AWS (הסתכלו לדוגמא על AWS Nitro) כוללים בעצם מערכת שמכילה KVM לינוקסי מינימלי שמריץ רק מכונות וירטואליות, וכל שאר השרותים מתקבלים דרך כרטיסי PCIe Express בעלי שבבים יעודיים (דוגמת Pensando של AMD) שנותנים שרותים יעודיים כמו אחסון, תקשורת, הצפנה ושרותים נוספים לפי הצורך, כך שבעצם המעבדים בשרת לא מריצים כמעט מאומה – זולת ה-Compute של הלקוחות וה-Hypervisor המינימלי. בשיטה זו רמת האבטחה היא הרבה יותר גבוהה, וגם אם מאן דהוא יצליח לפרוץ לשרת, אין שרות אחסון שרץ מקומית בשרת שניתן להתחבר אליו ולגנוב ממנו מידע (כל התחברות בין VM לאחסון דרך הכרטיס היעודי מבוססת הצפנה עם מפתח יעודי פר VM ויש עוד מספר אלמנטים לאבטחה).

יש גם נקודת לינוקס בכל העניין: מכיוון ש-DPU מכיל במקרים רבים מעבדי ARM עם אחסון וזכרון עצמאיים נפרדים מהשרת, אפשר לתכנת אותם, ו-Linux Foundation, יחד עם יצרני חומרה נוספים הקימו פרויקט שנקרא Open Programmable Infrastracture Project (ובקיצור – OPI) כדי לעודד חברות תוכנה לכתוב אפליקציות ודברים נוספים עבור אותם DPU.

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

… שלא מתאים לכולם.

למען האמת – אפילו לא לרוב אלו שיש להם מספר קטן עד בינוני של שרתי ESXI.

אני חושבת שיש צורך לספר משהו אחד פשוט לגבי אותם IPU/DPU שהולכים להיות מוצעים: כל הפתרונות הללו נבנו בראש ובראשונה עבור ספקי ענן ציבורי (אז'ור, AWS, GCP, אני בספק אם אורקל משתמשת בכך), ואותן יצרניות החלו להוסיף ולשנות את הפתרונות כך שיוכלו לעבוד עם Project Monterey, כך שבסופו של יום – מדובר על פתרון שהוא מאוד חדש, ואינני בטוחה אם אפשר לקרוא לו "יציב", ובכל מקרה – מחירי כרטיסים כאלו – גבוהים מאוד, ויש צורך גם במתגים עם תמיכה במהירויות גבוהות (25 או 50 ג'יגהביט כמינימום!) – כך שגם אלו שרוצים פתרונות DPU כאלו, לא בטוח שזה יתאים להם.

לסיכום: DPU הוא פתרון מעולה, כאשר יש לארגון עשרות רבות, מאות או אלפי שרתי ESXi. לשאר הארגונים, מעבדי X86-64 כמו Xeon או EPYC – יתנו עבודה כלל לא רעה, ובמיוחד במעבדים העתידיים של שתי החברות ששואפות להכניס רכיבי האצה שונים לתוך מעבדיהן – ואת התוצאות לכך נוכל לראות בחודשים הקרובים.

רעיון קטנטן ליצרני פתרונות אחסון

במדינתנו הנחמדה, לא חסרות חברות המפתחות פתרונות אחסון כמעט לכל דבר – מגיבוי ועד Cloud Native, עם תמיכה בכל הפרוטוקולים הידועים, ועם ביצועים מאוד מרשימים. אם אינכם מכירים את שמות החברות, הנה מדגם קטן: Lightbits, Kaminario, Infinidat ויש עוד כמה וכמה, רובן חברות ישראליות או חברות בינלאומיות עם מו"פ בארץ.

אחד הדברים היותר מעניינים שיצא לי לראות בשנים האחרונות – זה המרחק הענק בין מה שחברות אלו מייצרות ומה שמוצריהם נותנים מבחינת שרידות, מהירות העברת נתונים וכו' – לבין מה שחברות רבות בארץ רוכשות לעצמן כשהן מחפשות סטורג'. כיום, ב-2022, יש עדיין לא מעט חברות שרוכשות אחסון המבוסס על דיסקים מכניים עם SSD שמשמש כ-Cache, ואלו היותר מתקדמים – רוכשים דיסקים SSD שמהירות הכתיבה שלהם איטית (Read Intensive) ועם עוד SSD או 2 הכוללים Flash מסוג SLC או MLC לצורך כתיבה מהירה. את אותם פתרונות אחסון מחברים לשרתים המריצים vSphere עם חיבורים של 10 ג'יגהביט חיבור נחושת או +SFP (עם DAC או סיב), או שעדיין משתמשים בחיבורים הישנים בסיבים במהירות עד 16 ג'יגהביט.

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

מכיוון שיצא לי להכיר את שתי ה"עולמות" של פתרונות האחסון, ניסיתי לשוחח עם אנשי IT בחברות וארגונים שונים שחושבים לשדרג את התשתית שלהם – מדוע הם לא מסתכלים על הפתרונות שמפותחים פה בארץ. אחרי הכל, כל החברות יודעות להציע פתרונות שיכולים לבצע Scaling לאורך ולרוחב, לתת ביצועים שיכולים לגדול מתי שצריך וכו'.

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

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

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

כשאני מדבר על "ברזל זמני", אני חושב שכל יצרן אחסון יכול בעצם לבנות שרת 2U פשוט, עם מעבד EPYC (בשביל כל ה-PCIe Lanes ל-SSD ולציוד הנוסף) וכמות קטנה יחסית של אחסון נטו (נאמר: 4 טרהבייט) עם הציוד המינימלי שצריך כדי לתת ביצועים די טובים (לא צריך להשקיע יותר מדי כמו הוספה של סוויצ', אפשר להשתמש בחיבורי JBOF חיצוניים לדוגמא). שרת כזה ניתן להשאלה לארגון מתעניין ל-30 יום כדי שיחברו ו"ישחקו" איתו – יאחסנו נתונים, יבדקו ביצועים, ויראו איך פתרון כזה יכול להשתלב בחברה.

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

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

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

מוגש כחומר למחשבה.

שימוש ב-Wireguard כפתרון VPN מלא

יש לא מעט מקרים בהם VPN הוא דבר חיוני ונדרש, בין אם בחיבור בין 2 אתרים (Site to site), בין אם חיבור חיצוני לתשתית בענן ציבורי, בין אם חיבור מהבית לתשתית בעבודה וכמובן – כשרוצים להתחבר לתשתית בבית כדי לבדוק דברים או כדי להשתמש בשרותים שונים שרצים בבית – מבחוץ.

עד כה הפתרונות המוכרים ורצים במקומות שונים, היו פתרונות כמו IPsec, או OpenVPN או פתרונות קנייניים של יצרנים שונים (גם יצרני נתבים ביתיים כמו ASUS הוציאו פתרונות VPN כמו Instant Guard … שלא נתמך ב-Windows , Mac או לינוקס אלא רק למובייל) שעובדים בצורה מעולה. הבעיה בדרך כלל כשמדובר על גוף עם תקציב קטן (או ברצון לא להוציא כסף) – הפתרונות הנ"ל לא היו יכולים לבוא בחשבון, ומה שכן בא בחשבון סבל ממגבלות של רישוי (OpenVPN – מקסימום 2 משתמשים), ניצול גרוע של רוחב פס (במיוחד כשמתחברים לתשתית ביתית או upload בכמות מגהביט מזערית) והבעיה הגדולה מכולן – חוסר עדכונים לפתרונות הללו. בנוסף, פתרונות רבים מבוססי נתבים ביתיים מקבלים כמות קטנה מאוד של עדכוני תוכנה, כך שפתרון VPN מבוסס נתבים כאלו יכול להיות פתרון די מסוכן.

הפתרון שמקבל תאוצה בשנים האחרונות מגיע מכיוון אחר, מעולם הלינוקס, והוא פתרון ה-Wireguard. למי שלא מכיר, Wireguard מממש פתרון VPN, אולם הוא עושה זאת תוך שימוש בצופנים מודרניים שאינם "חונקי מעבד" ולא מצריכים פתרונות חומרה במעבדים. כך לדוגמא, Wireguard שרץ על Raspberry Pi 4 ויכול לתת תעבורה מוצפנת במהירות של 400 מגהביט, מספר הרבה יותר גבוה מ-OpenVPN (שנותן רבע או שליש מזה) ובחלק מהמקרים הוא עוקף פתרונות IPSec שונים מבחינת ביצועים ורוחב פס.

ל-Wireguard יש מספר יתרונות גדולים:

ההגדרות עצמן די קלות, ולמי שמסתבך, יש כלי שנקרא PiVPN (שגם רץ על דביאן ואובונטו על מכונות X86-64) שעוזר להגדיר את ה"שרת" ואת ה-Clients בקלות.
אין צורך בהגדרות משתמשים וסיסמאות. שרת ה-VPN צריך בסך הכל את המפתח הציבורי של ה-Client וה-Client צריך את המפתח הציבורי של השרת. השאר – הם הגדרות כתובת IP, DNS ומספר דברים נוספים לא ממש מורכבים.
מבחינת שינויים בנתב – השינוי היחיד שצריך לבצע הוא הגדרת Port forward ב-UDP אל המכונה שמריצה את ה-Wireguard כשרת. אפילו הנתבים של בזק יכולים לתת זאת בלי בעיה. (הערה: בימים האחרונים פרסמתי כי יש לי בעיה בנתבים מסויימים עם הגדרות ל-Wireguard, מסתבר כי זו היתה בעיית הגדרה של firewalld במכונה)
אתה יכול לנצל את מלוא רוחב הפס Upload שיש לך להנאתך. במקרים של חיבורים כמו DSL או כבלים, רוחב ה-Upload הוא מספר נמוך מאוד של Megabits (בד"כ עד 5) ופתרונות VPN מתחרים יוציאו מתוך זה אולי 1-2 מגהביט. עם Wireguard לפי נסיון שערכתי – מתוך 4 מגהביט Upload, קיבלתי רוחב פס של כ-3.5 מגהביט מוצפן החוצה (Upload).
מבחינת Clients – כל מערכת הפעלה תומכת ב-Wireguard – כל הפצות הלינוקס, אנדרואיד, iOS, מק, Windows, כולל Tizen (אם יש לך את ה-SDK ואתה רשום כמפתח..).
הגדרות Client די קלות במובייל – צור Tunnel, צלם תמונה (עקוב אחר ההוראות של PiVPN), שמור. נגמר. ההגדרות גם קלות ב-Windows ומק – העבר קובץ conf שיצרת עבור ה-client למערכת ההפעלה הנבחרת, הפעל Wireguard client, בצע יבוא (Import tunnel) והפעל.
הקץ להעברת כל התעבורה דרך VPN – הגדרת AllowedIPs תאפשר להגדיל ניתוב VPN רק לתשתית מסויימת (Split DNS), וכל השאר יעבור בצורה רגילה דרך האינטרנט. הקץ לגלישה שעושה "טיול" בחו"ל – לאתרים מקומיים.
כשמדברים על מערכות עם עדכוני אבטחה, כל הפצת לינוקס שתתקין (למעט Fedora) תגיע עם הבטחת עדכונים ל-5 שנים לפחות (גרסאות כמו Rocky/Alma/Oracle לינוקס – ל-10 שנים)

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

השוואת Proxmox למתחרים

יוצא לי מדי פעם לקבל טלפונים מקוראי הבלוג ואחרים – שמבקשים לדעת האם פתרון Proxmox יכול להיות פתרון טוב ותחליף לפתרונות יקרים יותר (vSphere) או אם הוא יכול לעמוד בתחרות מול Xen Server, או Hyper-V ואחרים, ולפיכך החלטתי לכתוב את הפוסט הזה כדי להסביר את הדברים בצורה יותר קלה ומובנת.

קצת מידע על Proxmox – מדובר מערכת ותיקה שהחלה את חייה עוד לפני שלמעבדי X86 היו יכולות וירטואליות בחומרה כמו שיש להם כיום, ולפיכך המערכת תמכה בפתרון וירטואליזציה כמו OpenVZ – הרצת מערכת לינוקס (ומערכות אחרות, אך לא Windows) בקונטיינר (אם כי פורמט הקונטיינר שונה מפורמט כמו של Docker וכו'). מאוחר יותר, כש-KVM בלינוקס צבר עם QEMU פופולריות, הוא הוטמע בפתרונות רבים (כל ספקי הענן הציבורי משתמשים ב-KVM הלינוקסי, מיקרוסופט ב-Azure משתמשת ב-KVM ב-Instances המאפשרים Nested Virtualization) וגם ב-Proxmox וכיום כשמקימים מכונה וירטואלית ב-Proxmox, היא תרוץ עם KVM.

כשזה מגיע לוירטואליזציה, Proxmox עומד בכבוד מול המתחרים ויש לו כמעט את כל מה שיש בפתרונות Hypervisor מתחרים. אין בעיה להצמיד ב-VM חומרה מסוגים וחיבורים שונים, המערכת תקבל בשמחה כל דיסק עם כל File system כ-Storage, כולל ext3, ext4,btrfs, zfs,ceph, glusterfs, והמערכת גם כוללת תמיכה שיתופית באחסון: יש לך דיסקים במכונה אחת אך לא במכונה אחרת? אין בעיה! בהגדרת ה-Storage, בחר ב-All Nodes (ראו תמונה לעיל, לחצו להגדלה) והמערכת תייצר עבורך NBD מבלי שתצטרך להרים NFS או CIFS עם כל ההגדרות. גם כשזה מגיע לשרידות, יש ל-Proxmox מה להציע (כל עוד יש לך 3 מכונות פיזיות) – הגדר את המכונות הוירטואליות שאתה מעוניין שישרדו, והמערכת תבצע להן מיגרציית Live אם אחד השרתים יורד בצורה מסודרת, או שהיא תריץ את ה-VM מחדש במכונה אחרת (כל עוד האחסון מבוסס על NFS או CIFS. קצת בעייתי לבצע שרידות שכל הדיסקים יושבים על שרת אחד שבדיוק מכבים אותו)…

אפשר להמשיך עוד ועוד – אך אקצר ואומר: Proxmox זה בהחלט פתרון שיכול להתאים לחברות Hosting בהם אין לספק מושג מה הלקוח יבצע ל-VM (ולכן ניתן להגביל דברים רבים, כולל רוחב פס, לדוגמא) או למקומות בהם רוצים לבצע מעבר P2V בתקציב מאוד נמוך וכמות המכונות תהיה קטנה.

מה קורה אם ניקח את Proxmox ונשווה אותו לפתרונות יותר גדולים כמו oVirt/RHV או vSphere של VMware? התשובה פשוטה: אין ל-Proxmox סיכוי להתחרות, הואיל ו-Proxmox לא כולל חלקים רבים. קחו לדוגמא עניין כמו איזון עומסים של מכונות VM בשרתים (ב-VMWare זה נקרא DRS, ב-oVirt/RHV זה נקרא Scheduling Policies) – זה לא קיים ב-Proxmox. עוד דוגמא קשורה לניצול כל הדיסקים הקיימים בשרתים ליצירת מערך אחסון גדול ושורד. נכון, יש GlusterFS שנתמך ב-Proxmox, אולם ל-Proxmox אין מושג ירוק מה קורה עם ה-GlusteFS – אתה יכול לבצע Mount וזהו. ב-VMware לעומת זאת, פתרון vSAN ליצירת אחסון מדיסקים – נלקח הרבה יותר ברצינות (ב-oVirt/RHV היה פתרון Hyperconverged מבוסס GlusterFS אולם הוא היה פתרון חצי אפוי והוחלט בשקט לבעוט אותו החוצה). אם נבחן לדוגמא את עניין הרשתות ושימוש ברשתות וירטואליות, הממשק ב-Proxmox מאוד אנמי (אין לך אפשר להגדיר דברים כמו VLAN, Slaves ודברים רבים דרך הממשק, אין לך אפילו אפשרות לראות אם החיבור נפל או לא, ואם אתה מתעקש להגדיר, אתה צריך לעבוד בדרכים הישנות, כמו לפני ש-NetworkManager או Netplan היו קיימים) ואילו ב-vSphere או RHV הדברים נלקחים בצורה הרבה יותר רצינית (הנה דוגמא ב-oVirt), ועוד לא דיברנו על ההתעקשות של מפתחי Proxmox לא לשלב את libvirt – ה-API הגדול והמשמעותי ביותר לכל ענייני וירטואליזציה בלינוקס ובמערכות הפעלה אחרות.

לסיכום: Proxmox הוא פתרון מעולה, למצבים מסוימים – אם רוצים להעביר משרד קטן P2V לשימוש ב-Thin clients כשהכל רץ על שרת אחד או שניים, לסטארט אפ קטן שאין לו תקציבים כרגע להשקיע בתשתית והוא לא רוצה/לא יכול להתחיל לעבוד בענן ציבורי ועוד, אך מעבר לכך – ארגונים גדולים, חברות גדולות, מוסדות ועוד – מומלץ שימשיכו להשתמש בפתרונות של VMware (או Nutanix) ומומלץ גם להכיר מה הולך לקרות ב"גל" הבא – ועל כך אפרסם פוסט נפרד.

על חוות שרתים מעל ומתחת לאדמה

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

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

התשובה עצמה – קצת מורכבת, וברשותכם – אפרט.

ישנם כאלו שמתכננים או משתמשים בענן, כאילו מדובר באיזו חוות שרתים של סלקום/נטויז'ן או פרטנר או בזק: הם מקימים פתרון DR שאמור לעבוד באופן ידני או אוטומטי, במקרה של תקלת חשמל, תקשורת וכו'. כלומר אותם לקוחות מראש "ננעלים" על חוות שרתים זו או אחרת של ספק ענן ציבורי, וכאן המציאות העגומה עלולה לטפוח בפרצופו של הלקוח שעובד כך: אם חיזבאללה מחר ירה טילים כבדים לאזורים בהם נמצאים חוות שרתים והוא יפגע באותו בניין או מבנה עם חוות שרתים – ישנו סיכוי גבוה מאוד כי חוות השרתים תושבת, בין אם השרתים נמצאים מעל האדמה או 20 קומות מתחת לאדמה! מה שלא מספרים לאנשים, זו העובדה הפשוטה שיש תשתית שלמה (שאינה כוללת שרתים) שנמצאת מעל האדמה (מה לעשות, אותה תשתית דורשת חמצן…) וכשטיל פוגע באותה חווה, יש סיכוי גבוה שאותה תשתית שנמצאת למעלה – תושבת, וכתוצאה מכך, גם השרתים שנמצאים למטה יהיו מושבתים או מנותקים, כך שבסופו של יום, בין אם השרתים נמצאים עמוק באדמה או מעליה, הסיכוי גדול כי הפגיעה תשבית את התשתית.

מה שתמיד מומלץ ללקוחות לעשות, זה לעבוד עם הכלים והפלטפורמות של ספקי הענן הציבורי הגדולים בכל הקשור לשרידות, ולהזניח את שיטות ה-DR הקלאסיות. שלושת ספקי הענן הגדולים, לדוגמא, מאפשרים להקים תשתית וירטואלית של שרותים ומכונות VM שפועלות במקביל במספר Availability zones (או Regions), כך שאם AZ או Region (תלוי בטרמינולוגיה של ספק הענן הציבורי) נופל או נפגע, התשתית הוירטואלית של הלקוח תמשיך לפעול מה-AZ או ה-Region האחר שנמצא גיאוגרפית במיקום שונה. לאלו שמוכנים להשקיע עוד, ניתן אפילו לבנות זאת בצורה של שימוש ב-3 Regions (או Region נוסף מחוץ לישראל ו-2 Availability zones), כך שלא חשוב מה יקרה בישראל, המערכת של הלקוח עדיין תמשיך לעבוד. אפשרות נוספת (ותמיד מומלצת) היא שימוש ב-Multi Cloud תוך שימוש בשרותים של ספקי ענן ציבורי שונים והקמה של התשתית אצל ספקי ענן ציבורי שונים, כך שאם קורה מקרה נדיר בה כל התשתית של ספק ענן ציבורי כלשהו נופלת – המערכת של הלקוח תפעל אוטומטית מהתשתית של ספק ענן ציבורי אחר.

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

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

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

אז מה עושים אם יש לנו מכונת אובונטו מגירסה ישנה כמו 14? זה כבר לא נתמך במסגרת ה-LTS (כלומר Long Term Support) שלא לדבר על המקרים בהם הותקנה גירסת אובונטו אך משום מה לא התקינו גירסת LTS…

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

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

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

קבלת תמיכה בהתאם לחבילה – מענה תוך שעה, 4 שעות וכו' – לתמיכה ל-OS עצמו
קבלת תמיכה לאפליקציות מסויימות תוך עמידה ב-SLA, כולל תיקוני באגים.

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

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

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

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

ההזדמנויות הבאות לחברות אינטגרציית שרותי ענן

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

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

נעבור מכאן ל"נימבוס", פרויקט הענן הגדול בשיתוף גוגל ואמזון. המכרז נסגר, הזוכים הוכרזו ובמשרדי ממשלה וגופים ציבוריים שונים – החלו תהליכי תכנון מעבר בין מתשתיות On prem ל-AWS או GCP, ובין מ-Azure ל-GCP או AWS.

אחת הנקודות שרבים פספסו לגבי הפרויקט, החשכ"ל וגופים ציבוריים ומשרדי ממשלה – הוא עניין ההגירה מ-Azure, הווה אומר: משרד ממשלתי או גוף ציבורי שאימץ את כללי חשכ"ל – יצטרך להעביר את התשתיות שלו מ-Azure אל GCP או AWS, ובמידה ואותו משרד או גוף ציבורי מתכנן מעבר תשתיות מ-On Prem, הספקים היחידים שהוא יוכל להקים אצלם תשתית ענן הם אמזון (AWS) או גוגל (GCP) או שילוב של שניהם (Multi Cloud).

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

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

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

בהצלחה לכולם 🙂

כמה מילים לגבי בזק והסתכלות קדימה

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

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

להלן מספר נקודות למחשבה:

יו"ר בזק, גיל שרון, ציין בכתבה כי "הרכישה נועדה להשלים ולחזק את היכולות שלנו בתחום הענן. זהו תחום צומח מאוד, בין היתר לאור מכרז נימבוס למגזר הציבורי, ובעקבותיו ההגעה של חברות הענן הגלובליות לישראל….". נחמד, אך אם הוא היה שואל מספר אנשים, אולי היה נודע לו כי משרדי ממשלה וגופים ציבוריים רבים ינטשו בקרוב את Azure, ובמילים אחרות – הרווח הצפוי להתקבל ממשרדי ממשלה על שרותים אלו – יחתך בצורה משמעותית מאוד.
החברה שבזק רוכשים, מתמחה באינטגרציה של שרותי מיקרוסופט/Azure, אך אין שום דבר שמציין כי לחברה יש נסיון עשיר במתן שרותי אינטגרציה בעננים אחרים כמו AWS או GCP. אם נסתכל על הסעיף הקודם, נראה כי משרדי ממשלה וגופים ציבוריים יצטרכו לעזוב, ובעצם ההכרזה כי CloudEdge מוכרת רק שרותים של מיקרוסופט, הם יוצרים "עבודה קלה" למתחרים, שיחפשו בדיוק "לחטוף" את הנתח היוקרתי הזה לטובת מתן שרותי אינטגרציה על העננים הציבוריים המתחרים. תמהני אם בבזק לא חשבו על כך.
עוד נקודה אחת: האם בזק ניסו לבדוק את שוק חברות האינטגרציה, עם דגש על מתן שרותי אינטגרציה למגוון ספקי ענן ציבורי? אם לא, מדוע בזק חושבים שמיקרוסופט תזכה בכל העוגה כאן? אדרבא, דווקא ארגונים גדולים ורבים בארץ (כולל מוסדות פיננסיים גדולים וידועים) עושים צעדים לעבור ל-AWS וזהו דבר ידוע, אז מדוע להתעלם מכך?

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

לטובת המעורבים, כולי תקווה שאני טועה.