המעבר ל-10 ג'יגהביט למעבדה קטנה

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

כפרילאנסר, אחת הסברות שאני שומע שוב ושוב בעולם ה-Enterprise מכל מיני מנמר"ים/CTO/CIO – זו התרשמות, שלא לאמר התפעלות – משרתים חדשים שמיוצרים על ידי המובילים: לנובו, Dell, Cisco, HPE, ואחרים. תראה להם מכונה עם 4 מעבדים – והם פותחים עיניים (טוב, עד שהם רואים את תגית המחיר). אותו דבר קורה כשמדברים על ציוד תקשורת – רוב החברות בארץ משתמשות עדיין בתקשורת 1 ג'יגהביט, 10 ג'יגהביט, 25 ג'יגהביט, Infiniband (במקרים מסויימים) במהירות 56 ג'יגהביט היא השיא. 100 ג'יגה ומעלה? נדיר למצוא, גם במקומות שהתקציב מאפשר ועל 400 ג'יגהביט – לא שמעתי שום מקום שמשתמש בזה.

עם כניסת ספקי העננים בשנים האחרונות (או בשמם היותר ידוע: Hyperscalers), חל דבר מעניין מאוד: ברוב מוחלט של המקרים (ואני מדבר על מעל 95%) אף ספק כזה לא היה מוכן לרכוש ציוד של Enterprise – בין אם מדובר בשרתים, סוויצ'ים, סטורג', גיבויים וכו'. הסיבות די פשוטות: הסיבה הראשונה קשורה למחיר החסר פרופורציות לחלוטין פר ברזל, והסיבה השניה – הציוד לא יכול לעמוד בדרישות שלהם, וכך בהחלה כל ספק Hyperscaler החל לתכנן ולבנות את הציוד שלו, ואז הגיעו פייסבוק שחוללו מהפכה והחליטו לפתוח את כל המפרטים של הציוד שלהם, כולל סכימות וכו' תחת מטריית ה-OCP (ר"ת Open Compute Project). לקח קצת זמן עד שענן החשדות מצד ספקי Hyperscalers ירד ואז כולם החלו לשתף את המפרטים. התוצאה: מאות חברות חדשות שקמו שהחלו לתכנן ולמכור את הציוד לספקי ה-Hyperscalers במחירים יותר נמוכים ממה שביקשו ספקי ציוד ה-Enterprise בשעה שהציוד נתן הרבה יותר מבחינת ביצועים.

מאז החלו לזלוג לשוק ה-Enterprise חלק קטן מאותו ציוד: למי שמכיר את הקופסאות JBOD 4U – כן, זה התחיל ב-OCP. מתגי תקשורת שבעבר היו מערכות סגורות עד הקצה – כיום יש יותר ויותר מתגים שמשתמשים במעבד רשת של Broadcom ושבב X86 של אינטל שמריץ לינוקס כדי לנהל את הכל ואתה מבצע בעצם את הכל דרך לינוקס עם הפקודות הידועות והמוכרות.

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

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

  • מחיר המתג וההמרה ל-10 ג'יגהביט יקר מדי
  • בשביל מה צריך את זה? 1 ג'יגהביט מספיק
  • קשה לחבר מעל 2 מחשבים בלי מתג
  • קשה להגדיר

אז נתחיל מהסיבה הפשוטה ביותר: רוחב פס מוגבל. נניח שיש לכם NAS, לא חשוב איזה NAS. נניח שיש בו 4 דיסקים מכניים (בלי להזכיר שום SSD) ונניח שהם מוגדרים ב-RAID כלשהו (לא חשוב איזה). מהירות ממוצעת לקריאה/כתיבה של דיסק מכני היא נעה בין 100-200 מגהבייט לשניה וזה לדיסק יחיד. נכפיל ב-4 לצרכי קריאה לדוגמא, ואנחנו מקבלים מהירות שנעה בין 400 ל-800 מגהבייט. תזכורת: מהירות 1 ג'יגהביט מתורגמת בערך ל-120 מגהבייט, כלומר דיסק יחיד "חונק" את חיבור ה-1 ג'יגהביט. יבואו אנשים ויאמרו "אפשר לצוות מספר חיבורים", שזה נכון, אז בואו נצוות 4 חיבורים של 1 ג'יגהביט ונקבל מהירות ברוטו תיאורתית של … 480 מגהבייט, כלומר את החיבור המצוות אנחנו "נחנוק" עם תעבורה של בערך 2.5 דיסקים קשיחים מכניים (שוב, לא מזכיר SSD שזורק מיד כל חיבור 1 ג'יגהביט).

נעבור למחיר: האם מתג של 10 ג'יגהביט הוא יקר מדי? אם אתה רוצה לרכוש מתג Enterprise של סיסקו או HPE – כן, זה יעלה לך כמה אלפי דולרים. אם לעומת זאת תרכוש מתג של חברת MicroTik, המחיר יפתיע אותך בהחלט. לי לדוגמא, מתג של 16 פורטים +SFP במהירות 10 ג'יגהביט עלה לי 1500 שקל וזה כולל משלוח ומסים. אם אתה רוצה לעומת זאת לחבר רק 2-3 שרתים ואולי מחשב, אז מתג כמו MikroTik CRS305-1G-4S+in יעלה לך 604 שקלים, כולל משלוח מסים (זה המתג שבתמונה).

מה לגבי כרטיסים לחבר למחשבים ושרתים? פה eBay יכול לעזור לך: כרטיס רשת של Mellanox מסוג ConnectX-3 כמו הכרטיס הזה עולה 142 שקל לכרטיס (שימו לב, רוב ההצעות האחרות מדברות על 150+ שקל לכרטיס, ואם אתם משתמשים ב-ESXi רכשו את ה-Connect-X3 ומעלה, לישנים אין יותר תמיכה ב-VMWare), שזה הרבה פחות מהמחיר של כרטיס רשת טוב לשרת במהירות 1 ג'יגה.

כבלים – נחסוך את הרכישה של סיבים אופטיים. לא צריך אותם יותר (בתור אחד שיש לו 3 חתולים שנהנים מדי פעם לבדוק את השיניים שלהם על כבלים כאלו – הם עמידים בצורה מעולה!), במקום זה נשתמש בכבל DAC TwinAX נחושת וכאן תלוי מה האורך שאתם צריכים. אם המחשבים שלכם יושבים במקום אחד וצמודים, כבל של 1 מטר יספיק, והכבל הכי זול שמצאתי זה מהסוחר הזה ב-eBay במחיר של 26.64 שקל. בניגוד לסיבים, לא צריך ג'יביקים ובכלל, המתגים של MicroTik עובדים עם כל כבל – נחושת או סיב או כל GBIC, אין בדיקה ואין חסימות.

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

אז אם יש לנו 3 מחשבים, העלות תהיה: 604 שקל למתג, 426 שקל ל-3 כרטיסים, 80 שקל לכבלים. סך הכל: 1110 שקל. פתאום 10 ג'יגהביט זה לא כזה יקר? 🙂

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

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

 

כשצריך הגנות על מכונות וירטואליות

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

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

אינטל בזמנו פיתחה את ה-SGX, שזו מערכת שמאפשרת לנו ליצור איזור מאובטח שעליו ירוץ קוד בצורה מוצפנת כך שגם מנהל Hypervisor עם תוכנות זדוניות לא יוכל לסרוק את אותו זכרון ולמצוא מה רץ. ה-SGX עצמו כבר נפרץ (אינטל הוציאה תיקון), אבל בכל מקרה הפתרון עצמו היה בעייתי עוד מלכתחילה: האפליקציה המוצפנת היתה צריכה להיות מאוד קטנה (עד 64 מגהבייט זכרון), והביצועים (במיוחד ה-Floating Point) היו, איך נאמר בעדינות … לא משהו להתגאות בו. ב-VMWare לא רצו לנגוע בזה גם עם מקל ארוך.

ואז הגיעה חברת AMD ובשנת 2017 היא פירסמה על תוספות חדשות שיהיו זמינים במעבדים שלה לשרתים (EPYC) ובמעבדים לצרכים מקצועיים (Ryzen Pro): התוספות הן SEV ו-SME (והתוספת החדשה: SEV-ES – להצפין גם רגיסטרים במעבד שמשומשים ע"י אותו VM מוצפן). ה-SEV איפשר להצפין את מכונת ה-VM עם מפתח יחודי שמגיע מתוך מעבד ARM שנמצא במעבד EPYC (כן, מעבד בתוך מעבד) ו-SME שמצפין את הזכרון של ה-VM.

היתרונות של SEV ו-SME הם בכך ש:

  1. אין צורך לעשות שינויים מהותיים ב-VM (רק להחליף Kernel לאחד שתומך ב-SME/SEV)
  2. ההצפנה היא ברמת חומרה, כך שה"קנס" ברמת ביצועים הוא מאוד מינימלי
  3. המפתחות הם יחודיים ולכל VM יש מפתח משלו שמונפק ע"י המעבד. ניתן להנפיק עד 105 מפתחות (כל VM מקבל מפתח אחד, כך שאפשר להריץ עד 105 מכונות VM מוצפנות בשרת עם מעבד EPYC יחיד או 210 בשרת עם שני מעבדי EPYC).

החסרונות:

  1. אי אפשר להצפין מכונות Windows, לפחות עד שמיקרוסופט לא תוסיף את תמיכת ההצפנה ל-OS עצמו.
  2. VMware בשלב זה אינה תומכת בפונקציות אלו מ-AMD או אינטל (תיכף ארחיב על הפתרון של אינטל) – זה יתווסף בגירסה 6.8 או 7.0 ולכן אם אתם צריכים זאת עכשיו, תצטרכו לעבור ל-KVM או על אחת הפלטפורמות שמבוססות על KVM (בכל מקרה יש צורך לבצע את ההחלפת Kernel).

באינטל ראו את הפתרון של AMD והחליטו שגם הם יוציאו משהו דומה: תכירו את TME (כלומר Total Memory Encryption) ואת MKTME (כלומר: Multi Key Total Memory Encryption). אפשר לקרוא על הפתרון הזה בקצרה כאן, אך אני יאמר מראש: אל תבנו על הפתרון הזה, הוא לא זמין באף מעבד נוכחי.

מכיוון שגם אינטל וגם AMD הולכים באותו כיוון (רק של-AMD יש פתרון שאפשר להשתמש בו כיום), אפשר לאמר על הפתרון את הדברים הבאים:

  • כן, הפתרון רץ אך על מנת להשתמש בו, יש צורך בידע טוב בלינוקס. אם צריכים את הפתרון ל"מחר בבוקר" – תצטרכו לבצע שינויים הן ברמת ה-HyperVisor והן ברמת ה-VM.
  • הפתרון אינו מבטיח הגנות נגד דברים אחרים כמו Side Memory Attack, DDoS.
  • הפתרון הוא יחסית צעיר (ב-AMD פיתחו אותו בכלל עבור הגנת הקונסולות של סוני ומיקרוסופט ואז החליטו שזה רעיון מעולה להעביר אותו למעבדים לשרתים) ולפיכך מתגלים בו באגים (ו-AMD משחררת קושחות לתיקון).
  • כיום הפתרון של AMD נמצא בשימוש בשרתים החדשים (דור 10) של HPE שמבוססים על מעבדי EPYC (כלומר DL325 ו-DL385) בשילוב ה-Root of Trust של HPE והחברה (HPE) טוענת שזה הפתרון הכי מאובטח שיש להם להציע לשוק.
  • זה לא לפרודקשן אם ה-VM שלכם צריך לרוץ בחוץ או ה-Hypervisor שלכם מחובר לאינטרנט (יש לא מעט כאלו).

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

לסיכום: השיטה ש-AMD מציגה על מנת להגן על מכונות VM נגד האזנה למכונות VM היא שיטה טובה מאוד (ובגלל זה אינטל גם מעתיקים אותה), אך זהו פתרון חדש, וככזה הוא יכול להתאים למאמצים מוקדמים (Early Adopters) עם ידע בלינוקס. אני מאמין שבעוד שנה, הפתרון יתבגר יותר ובמקביל נראה הצעות מספקי ענן ציבורי לשכור Instances שיתמכו ב-SEV/SME, כך שה-Instances שלכם יהיו מוצפנים מספיק טוב בכדי לא לאפשר (באופן עקרוני) לגורמים זרים שיש להם גישה לברזל – לחטט בזכרון של ה-VM שלכם.

הפתרון למעבר מ-VM לקונטיינר: Kubevirt

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

כל מי שהתחיל ומשתמש בקונטיינרים, Kubernetes וכו' – מבין בוודאי שקונטיינרים אינם מכונות וירטואליות. בניגוד ל-VM, קונטיינר מקבל שרותי OS ממערכת ההפעלה המותקנת על ה-VM (או על הברזל) שמריץ את הקונטיינר, ולפיכך קונטיינרים ברוב המקרים הם דברים די קטנים בהשוואה למערכת הפעלה מלאה שמותקנת ב-VM, גם כשהיא מותקנת כ-Minimal.

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

ישנם גם מקרים שאי אפשר להמיר מכונת VM לקונטיינרים חדשים. מקרים כמו:

  • האפליקציה רצה ומבוססת על Windows
  • האפליקציה רצה על גירסת לינוקס מאוד ישנה
  • האפליקציה רצה על מערכת הפעלה שאינה מבוססת לינוקס
  • ה-VM נבנה ע"י מומחה חיצוני ולאף אחד אין מושג ירוק איך הדברים מוגדרים ב-VM (לדוגמא: Cobol ישן)

במקרים כאלו, קשה מאוד או בלתי אפשרי להמיר ידנית את המכונות הללו לקונטיינרים, וכך פרויקטים לקונטיינריזציה מתעכבים או שממשיכים להריץ את מכונת ה-VM בתוך פתרון וירטואליזציה (vSphere לדוגמא) – אבל אז מפסידים את כל היתרונות של Kubernetes או Openshift.

וכאן נכנסת לתמונה אפליקציית Kubevirt.

אפליקציית Kubevirt מרחיבה בעצם את Kubernetes/OpenShift ומוסיפה למערכת תמיכה בקונטיינרים מסוג נוסף: קונטיינר שמריץ VM. כך בעצם אפשר לקחת VM מהדוגמאות לעיל ו"להכניס" אותו לתוך קונטיינר, כך שנוכל להריץ אותו כמו שאנחנו מפעילים קונטיינרים נוספים, ובכך נוכל להשתמש באפליקציה שרצה ב-VM, נוכל לשכפל את הקונטיינר לפי פרמטרים שנרצה, נוכל לשדרג את הקונטיינר ועוד ועוד.

מאחורי הקלעים, מה ש-Kubevirt עושה, הוא להשתמש ב-KVM (הוירטואליזציה המצויה בכל לינוקס) ובספריית Libvirt וספריות נוספות בכדי ליצור POD ובתוך ה-POD להריץ VM. את אותו VM אנחנו נגדיר בעזרת קבצי YAML, כמו שמגדירים כל דבר ב-Kubernetes, וכך נוכל להגדיר כמות זכרון, היכן הדיסק הוירטואלי יושב, האם ה-VM יהיה בעצם Immutable (כלומר שכל שינוי ל-VM ימחק ברגע שה-VM "כובה"), ועוד פונקציות נוספות. הגישה ל-VM תוכל להתבצע בכלים הרגילים (SSH, RDP) או VNC וחיבור סריאלי וירטואלי (במקרה שמדובר בלינוקס או כל מערכת תואמת UNIX אחרת).

מכיוון שב-Kubernetes אפשר להשתמש בכל מיני "דרייברים" (Storage Classes, Volumes), נצטרך להמיר בשלב ראשון את הדיסקים הוירטואליים של ה-VM מהפורמט הנוכחי (VMDK ב-vSphere) לפורמט ש-KVM ו-libvirt יכולים להבין ולהשתמש. סוג הדיסק שאנחנו נצטרך יהיה RAW וכלי ההמרה (שצריך לרוץ תחת לינוקס) הוא virt-v2v (זה קצת יותר מורכב ממה שהקישור מראה). מהרגע שביצענו זאת, אנחנו "מנתקים" בעצם את ה-VM מהוירטואליזציה הנוכחית (נניח vSphere), אבל ה-VM עדיין נשאר ב-vSphere. ברגע שיש לנו את הקובץ בפורמט RAW, נוכל להשתמש בכלי כמו CDI כדי לבצע Import של ה-Image לתוך Volume שנגדיר. אחרי שהצלחנו (שוב, לא דבר כל כך קל, אלא אם אתם משתמשים ב-Openshift דרך ה-WEB UI), אנחנו נגדיר POD עם ה-VM ושם אנחנו נבחר דברים כמו כמות זכרון, מערכת הפעלה, וכו'. בזמן ההגדרות נוכל להוסיף דיסקים וירטואליים חדשים ל-VM ועוד. לאחר שהתהליך מסתיים ונפעיל את ה-VM, תופיע כתובת IP שדרכה נוכל להתחבר אל ה-VM.

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

  • Kubevirt עובד על כל גירסת Kubernetes מ-1.10 ומעלה, ו-OpenShift 3.11 ומעלה.
  • בשביל לקבל ביצועים טובים עם ה-VM, יש צורך בתמיכת Nested Virtualization (אם ה-Kubernetes שלכם רץ כמכונה וירטואלית).
  • עננים ציבוריים: אם אתם רוצים להריץ Kubevirt על ענן ציבורי, תצטרכו לבחור Instances שכוללים תמיכת Nested Virtualization. גם לאז'ור וגם לגוגל יש מכונות כאלו, ב-AWS אין ולפיכך ב-AWS מכונות VM כאלו ירוצו יותר לאט מאחר ומדובר באמולציית X86-64 בתוכנה.
  • דיסקים וירטואליים: מכיוון שאין Thin Provisioning בשיטה כזו, הווליומים יהיו גדולים (כמה שהגדרתם ב-VM בהתחלה תחת vSphere), לכן אם הגדרתם את ה-VM עם דיסק של 100 ג'יגה אבל השתמשתם רק ב-15 ג'יגה, הקטינו את הדיסק (הוראות נמצאות כאן אם מדובר ב-vSphere).
    נקודה נוספת חשובה לגבי דיסקים וירטואליים: אפשר לצרף אותם ישירות ל-Image של הקונטיינר אך הדבר אינו מומלץ (אלא אם אתם רוצים להפיץ את ה-Image החוצה).
  • קישוריות ל-VM ותקשורת: במקור כברירת מחדל יש ל-VM חיבור רשת יחיד. יחד עם זאת ניתן להשתמש ב-Multus או Genie כדי להוסיף דברים רבים הקשורים לרשת: VLAN, Bridges, אפילו PXE Boot – תשתוללו חופשי.
  • ניתן לשכפל את ה-VM לפי כל פרמטר שתרצו כדי לעמוד בעומסים. לשם כך תצטרכו להגדיר בקובץ YAML את ה-AccessModes לפי הצרכים שלכם.
  • KVM – מכיוון שה-VM שלכם ירוץ תחת KVM, כדאי להכיר את KVM. תרימו מכונת לינוקס, תפעילו Nested Virtualization ותריצו את Virt Manager (נקרא גם VMM). יש המון פונקציות והגדרות וכדאי להכיר אותם לפני כן, אחרת תקבלו הפתעות (במיוחד אם מכונת ה-VM שלכם משתמשת ב-UEFI. יש תמיכה ל-UEFI אבל תצטרכו להגדיר כמה דברים לשם כך).

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

אם אתם רוצים עוד הסברים על Kubevirt כולל הדגמה של לינוקס ו-Windows Server 2012, אתם מוזמנים לצפות בקליפ (הארוך – שעה) הבא.

לסיכום: אם אתם רוצים לעבור לקונטיינרים והדבר היחיד שמפריע זה מכונה אחת (או מספר מכונות) שבעייתי להמיר אותן ידנית לקבצי Docker Images ושירוצו כקונטיינרים טבעיים, Kubevirt יכול לסייע בכך. חברות כמו SAP, nVidia, Cloudflare כבר משתמשות ב-Kubevirt. חשוב לציין: Kubevirt עדיין לא מוגדר כגירסה סופית (מצד שני, גם Kubernetes לא מוגדר כך). אם אתם משתמשים ב-OpenShift מגירסה 3.10 ומעלה (גם בגירסת OKD – גירסת הקוד הפתוח) – קל מאוד לשלב את Kubevirt והחל מגירסה 4.2 – ה-Kubevirt יהיה חלק אינטגרלי (בגירסה הנ"ל תוכלו להתחבר ישירות ל-vCenter ולהמיר את ה-VM בכמה קליקים).
מיקרוסופט וגוגל כבר מזמן הבינו שאם רוצים למשוך את הלקוחות אליהם כדי שישתמשו בשרותי ה-Kubernetes שלהם, צריך לעזור ללקוחות בכך שיציעו המרה של מכונות VM להרצה בתוך קונטיינרים, וזה יהיה כנראה ה"גל" הבא.

כשצריך תשתית של עננים ציבוריים – מקומית

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

לפני כחודשיים כתבתי פוסט על Azure Stack (ועל "אחיו" – Azure Stack HCI), הפתרון של מיקרוסופט לחברות שדורשות ענן ציבורי בתשתית שנמצאת מקומית או ב-DC של אותן חברות. מאז אותו פוסט גם אמזון עדכנה את הפרטים לגבי המוצר המתחרה שלה: Outpost. לפי ה-FAQ העדכני והפוסט הזה שפורסם לפני מספר ימים מתאר אלו שרותים יהיו זמינים ב-Outpost. גם כאן, כמו עם Azure Stack, אתה לא יכול להשתמש בשרתים או סטורג' משלך, והשרות בעצם כולל השכרה/רכישה של ברזלים יחודיים של ספק הענן, וכמו בכל ההצעות – אתה חייב חיבור אינטרנט לאותה תשתית מכיוון שמי שמנהל את אותה תשתית ענן ציבורי שנמצאת מקומית ב-DC שלך – זה ספק הענן הציבורי בלבד.

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

גם גוגל החלה להציע פתרון משלה לאלו שרוצים תשתית ענן ציבורי אך מקומית ב-DC שלהם, אם כי הוא שונה מהמתחרים. אם אצל המתחרים השלב הראשון הוא רכישת/השכרת ברזלים, בגוגל פשוט ממליצים לך להשתמש בתשתית המקומית שלך או בתשתית הענן הציבורי שלהם או של אחרים ושם המוצר הוא Anthos. עם Anthos הלקוח מקבל את פלטפורמת הקונטיינרים של (Google Cloud (GKE לשימוש מקומי. זה לא בדיוק נשמע משהו מלהיב – אחרי הכל, לרוב החברות יש מאות ואלפי מכונות VM שהם לא רוצים/לא יכולים להמיר לקונטיינרים ולכן גוגל כוללים בחבילה גם את Anthos Migrate שמאפשר לך להעביר מכונות VM (בשלב זה מכונות מבוססות לינוקס בלבד) מ-VM ישירות לקונטיינר, כאשר המערכת של גוגל מנתחת את ה-VM, מקימה קונטיינרים, מזרימה אליהם את המידע ותוך רגעים ספורים אתה יכול להשתמש בקונטיינרים במקום במכונות ה-VM, גם כשהמכונות VM עדיין לא הועברו בשלמותם לפתרון של גוגל.

לגבי שאר ספקי הענן הציבורי:

  • ל-IBM יש Cloud Private שנותן לך בעצם Kubernetes עם שרותים נוספים של IBM שירוצו מקומית.
  • ל-Alibaba, Huawei, Baidu יש גם פתרונות מקומיים אבל אני בספק אם הלקוח הישראלי החשדן יסכים לשכור מהם שרותים שישבו מקומית.
  • Oracle מציעים את Oracle Cloud at customer – שכוללים את "רוב" השרותים שהם מציעים בענן (אחרי שנברתי בערימת מסמכים רוויי Buzzwords – קשה להבין מה הם בדיוק נותנים, מה עוד שהתיעוד שלהם לגבי ספקי ענן מתחרים לוקה בחסר ולכן לא מומלץ לסמוך על התיעוד שלהם).
  • VMware – נכון, VMWare היא אינה ספק ענן ציבורי, אבל עם מוצר כמו Tanzu אתה יכול להרים תשתית קונטיינרים/Kubernetes מקומית (PKS) ובעננים ציבוריים גדולים.

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

פרילאנסר – הממשלה רוצה אותך

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

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

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

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

  • קודם כל – Python ולא Paython.
  • עבודה עם Dot Net: אני ממליץ מאוד למינהל להתחיל בתכנון מעבר מ-Dot Net ל-Dot Net Core מהסיבה הפשוטה שקוד Dot Net Core יכול לרוץ גם על לינוקס, דבר שיעזור מאוד כשהקוד יצטרך לרוץ בענן הממשלתי. Dot Net Core מפותח ע"י מיקרוסופט ומיקרוסופט מספקת גם תיעוד כיצד לעבור מסביבה אחת לשניה.
  • פיתוח אפליקציות Mobile – אולי כדאי לחלק זאת לשתי סעיפים: iOS ו-Android. לא כל אחד שמפתח למערכת אחת, מומחה למערכת השניה.
  • סעיף "ארכיטקטורה" לא מובן לי. ב"ארכיקטורה" יש המון דברים הקשורים לתשתיות, אוטומציה, קונטיינרים, וירטואליזציה ועוד דברים רבים אחרים. האם המסמך יכול להכיל יותר פרטים?
  • הסבות בסיסי נתונים – על כך יש לי לאמר מספר דברים:
    • אני לא ממליץ ללכת על MySQL של אורקל אלא לעבור ל-MariaDB שכלול בתוך הפצת הלינוקס. למיטב ידיעתי, MariaDB מתפתח בקצב יותר מהיר וכולל תאימות לאחור ואין צורך לשלם עליו בנפרד.
    • ישנו פתרון RDBMS יותר רציני שנקרא PostgreSQL שגם נכלל בהפצות לינוקס (ונתמך ע"י רד-האט/SuSE בצורה רשמית) ויכול להיות שהוא יתאים יותר להסבה אליו מפתרונות DB אחרים.
    • הסבת נתונים מבסיסי נתונים כמו Oracle, MS-SQL, DB2, Adabas אל MySQL (או MariaDB) הם פרויקטים מסובכים וקשים. על מנת לעבור לדוגמא מ-MS-SQL ל-MySQL, יש מספר כלים ומתודות (כפי שניתן לראות כאן), אולם הקושי העיקרי הוא שינוי כל הקוד והלוגיקה באפליקציות שמשתמשות באותו DB. הרוב משתמשים ב-SQL כ"שפה" אבל לכל DB יש מימוש שונה. ב-DB אחרים כמו DB/2 ו-Adabas ההמרה תהיה הכי מורכבת.
    • אם אין בעיה של רשיונות, אפשר להתחיל להתעניין ב-SQL Server for Linux של מיקרוסופט (גירסת 2019 – זו הגירסה שיכולה לרוץ בקונטיינרים ובמערכות Kubernetes/Openshift).

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

  • איכות הקוד/מימוש הפרויקט: קבלת ממליצים ושיחה איתם לא תתן מידע שיכול להעיד על איכות הקוד של המתכנת או איכות ביצוע הפרויקט (מבחינה טכנית) ע"י המועמד. אם מישהו שוכר עצמאי לכתוב נניח אפליקציית שעון נוכחות, הדבר היחיד שמעניין את המזמין – הוא שהאפליקציה תעבוד ועדיף שיהיה גם תיעוד כלשהו לגבי תקלות. האם מזמין החברה יכול להעיד משהו על איכות הקוד של המפתח? לא. המקסימום שאפשר לקבל מידע מהממליץ, הם דברים "מסביב": האם המועמד ביצע את העבודה לשביעות רצון הלקוח, האם הוא עמד בלוח זמנים, האם הוא דאג "לסגור פינות", דברים כאלו, אבל שום דבר טכני שיכול להעיד על איכות הקוד, ולכן אני חושב שאולי כדאי להוסיף מבחן שהמועמד יצטרך לעמוד בו לכתוב קוד ושמישהו יבדוק את הקוד.
  • קוד הדוק ומאובטח: אנחנו נמצאים במדינה שמותקפת מבחינת סייבר מכל כיוון שתסתכל, ולא חשוב מה תשים "מקדימה" – אם הקוד גרוע מבחינת אבטחת מידע, יהיו דרכים לפרוץ למערכת. (לא צריך ללכת רחוק כדי להדגים – הנה מה שקרה עם מאגר נתוני האשראי רק לאחרונה), ולכן לעניות דעתי, אולי כדאי להוסיף מבחן או בדיקה של קוד מאובטח שיבדק ע"י מישהו שמבין ב-Code Auditing ושיתן ציון גבוה עבור קוד מאובטח.
  • Agile – זה שמישהו יודע לפתח זה טוב, אבל מה עם שימוש בכלים מודרניים? האם המפתח יודע להשתמש ב-GIT? האם הוא יודע לכתוב Pipeline ב-Jenkins לדוגמא? או Dockerfile (מאובטח) כדי להריץ את הקוד בקונטיינר? ומה שיותר חשוב – האם הוא יודע לכתוב Automated Tests בכדי לבדוק אוטומטית את הקוד שלו? גם לכך, לעניות דעתי, צריך לתת ציון.

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

עננים ציבוריים: להתחיל בקטן ולגדול

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

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

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

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

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

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

במקרים כאלו ה-Lightsail הוא פתרון מעולה. השימוש בו ממש קל: אתה יכול להרים לך מספר מכונות, אתה יכול להשתמש בשרותי ה-DB המנוהלים של אמזון גם ללא הכרה של ה-RDS המורכב, אתה יכול להשתמש ב-Load Balancer הפשוט שאמזון מציעה כדי לנתב את התעבורה, ואתה יכול להשתמש בשרותי ה-Snapshot כדי לשכפל מכונות תוך דקות ספורות, ויש דברים נוספים שלא עולים לך כמעט כלום: אתה יכול להשתמש בשרות ה-SMS לשם משלוח מיילים החוצה (בכמויות שסטארטאפים קטנים מתחילים – הם לא ישלמו כלום), אתה יכול להרים GIT פרטי (5 משתמשים ראשונים זה בחינם), אתה יכול גם להשתמש בשרות ה-DB המנוהל עם אפשרות Cluster שיעבוד כ-Active/Passive עם גיבוי אוטומטי כל 5 דקות, ויש לך מגוון שרותים שאתה יכול להשתמש עם ה-Lightsail מבלי להכאיב לארנק.

ברגע שהסטארטאפ רוצה לגדול, Lightsail מאפשר לך להעביר את התשתית שלך כמו שהיא ל-AWS המלא. צור Snapshot למכונות, ותוכל להקים אותם כ-Instances ב-EC2 ואותו דבר לגבי ה-DB – תוכל להעביר אותו בקלות ל-RDS ולהשתמש בשרותים מתקדמים כמו רפליקות וכו'.

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

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

קצת על גניבות קוד, קניין רוחני ועוד

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

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

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

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

חברות רבות נותנות לעובדיהם מחשבים ניידים כדי שיוכלו לעבוד מרחוק (בד"כ דרך VPN) על קוד או על תשתית של החברה (אני אתרכז יותר במפתחים). עובדים שעובדים מהבית בד"כ או שעובדים בצורה גמישה (משרד/בית) משתמשים במחשב הנייד כדי לקבל גישה לקוד (נניח דרך GIT), להוריד שינויים, לבצע שינויים קוד ולבצע Commit ו-Push. עד פה לאף אחד אין בעיה עם זה.

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

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

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

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

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

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

לגטימי? כן.

וכאן יש נקודות שכל סטארטאפ צריך לעשות:

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

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

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

כשאין נסיון מספק בתחום

בעבר, לאלו שעובדים כשכירים, בתחום ה-IT החיים היו יחסית פשוטים: בדרך כלל היו מחפשים אנשים עם נסיון עשיר ב-Windows, קצת נסיון בתקשורת, נסיון באפליקציות נלוות (אופיס, Exchange, Sharepoint וכו'), אם אפשר – נסיון כלשהו בלינוקס, ויש סיכוי סביר שהיית מתקבל לעבודה. ברוב המקומות, גם אם לא היה לך נסיון מספק ב-Windows אבל עברת איזה קורס והיית מכוון לאיזו משרת ג'וניור ב-IT, היו מוכנים לקבל אותה לאיזו משרה זוטרה.

כפרילאנסר – החיים מאוד דינמיים ומאוד תובעניים. ככל שאתה מכוון ליותר "גבוה" לפרויקטים והזדמנויות רווחיות – אתה צריך "להשיל" תחומים מסויימים בגלל שהשוק באותם תחומים מוצף בעצמאים שיהיו מוכנים לתת מחיר תחרותי מאוד. לדוגמא: תחזוקת מכונות Windows Desktop או תחזוקת שרתי Windows – יש מספיק בשוק שיציעו מחירים של 70-150 לשעה. אם אני אבקש "מאות" שקלים לשעה, ההצעה תידחה ולכן בדברים כאלו צריך לוותר ולכוון לדברים היותר רווחיים – קונטיינריזציה, עננים ציבוריים, כלי CI/CD, אוטומציה, אינטגרציית לינוקס, מערכות  משובצות, HPC, Scale Out, אחסונים גדולים (מעל פטה) ועוד.

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

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

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

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

וכך, כשכיר, בעת הראיון, אתה יכול לאמר את האמת: אין לי נסיון בנושא X מחברה קודמת, אבל יש לי ידע טוב בנושא X ואתה יכול לקרוא בעצמך את הפוסטים שכתבתי בבלוג שלי בכתובת XYZ. בשביל המראיין, הפוסטים האלו מראים את הידע שלך, ואת העובדה שאתה יכול לפתור בעיות. אותו דבר לגבי מפתח – פוסטים עם קישורים ל-Github עם קוד משלך עוזר הרבה יותר מ-1001 המלצות, גם אם מדובר בסקריפט BASH פשוט, באוטומציה פשוטה וכו'. מישהו יכול לראות, להתרשם, ואז להמשיך במסלול עד לחתימת חוזה עבודה איתך.

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

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

תכירו: vCompute Server של NVidia

במסגרת כנס VMWorld שנערך השבוע, חשפה NVidia את המוצר החדש שלה שהוא vCompute Server (נקרא לזה בקצרה VCS) שמתאים לאלו שצריכים להריץ עומסי AI, DL בסביבות וירטואליות.

עד היום, חברות שרצו להריץ למטרות Training ופיתוח עומסי AI בסביבה וירטואלית, היו צריכים לעשות זאת עם ה-vGPU ש-Nvidia מוכרת. בשיטה הזו מקצים חלק מכרטיס ה-GPU שיושב בשרת לכל VM (אגב, לידיעה: vSphere 6.7 U3 מאפשר לראשונה להצמיד מספר vGPU למכונת VM, לא רק vGPU יחיד).

לשיטה הזו יש כמה חסרונות רציניים:

  • ה-vGPU לא תוכנן מראש עם ה-CUDA לשימושי AI,DL. כן, הוא יכול להריץ זאת (גם מעבד גרפי נמוך מאוד כמו MX150 בלאפטופ יכול להריץ זאת), אך לא בצורה אופטימלית.
  • אם אתם משתמשים בקונטיינרים עם ה-Runtime Container של NVidia, זה לא היה מנצל את היכולות האמיתיות של הכרטיס (TCC, nVLink וכו') אלא היה מתייחס ל-vGPU בלבד.
  • אין תמיכת NVLink
  • אין אפשרות אגרגציה טבעית (מעבר למה שה-vGPU נותן).

הפתרון של NVidia הוא ה-VCS, מערכת חלופית שנותנת "vGPU" אבל למערכות AI,DL (כל עוד ה-VM לא מריץ שום דבר גרפי כי .. אין דרייבר גרפי).

מערכת ה-VCS פותרת את החסרונות של ה-vGPU ה"קלאסי" ונותנת את הפוקנציונאליות הבאה (אפשר לקרוא מעט יותר בהרחבה על כך בקובץ ה-PDF הזה):

  • אפשרות לחלק את ה-GPU לחלקים (Fraction) או לבצע אגרגציה של מספר v-GPU מכרטיסים שונים ובגדלים שונים.
  • מהירות עבודה יותר גבוהה (כי אין צורך לכרטיס לבצע רינדורי גרפיקה של מסכים וירטואליים/תלת מימד/וידאו וכו')
  • שימוש ב-NVLink בחיבור Peer to peer.
  • מיגרציה – מעתה אפשר לבצע vMotion (באשכולות לדוגמא) גם כשהמכונה רצה, לבצע suspend, resume.
  • תמיכה ב-Multi Tenant.
  • שימוש מ-NRC לקונטיינרים יהיה מהיר יותר, הואיל והמודול בלינוקס יודע להשתמש בכל היכולות של ה-GPU בשרת.

החסרונות:

  • אין דרייברים לגרפיקה (אז תשכחו מאובונטו גרפי – ואם אתם עדיין רוצים סביבה גרפית, תכירו את NoMachine)
  • אין דרייברים ל-Windows (כן, לכל גרסאות Windows)
  • אין יותר פרופילים קטנים, הן ברמת זכרון (המינימום הוא 4 ג'יגה, המקסימום הוא 48 ג'יגה) והן ברמת CPU (מינימום 4 ליבות, מקסימום 48 ליבות).
  • אין תמיכה ב-Quadro הישנים (יש תמיכה ב-Quadro RTX)

מבחינת רישוי: תצטרכו רישוי בתשלום שנתי, פר GPU.

פתרון ה-VCS בהחלט מתאים כמובן (ומומלץ) לשימוש עם Kubernetes, קונטיינרים וכו'.

ובעניין מעט שונה: נודע לי כי רוב החברות שרוכשות GPU בשרתים לצרכי AI – רוכשות RTX 2080TI ובכמויות נכבדות. כפי שציינתי בעבר, כרטיסים אלו אינם מתאימים לשרתים, הואיל והם צריכים כניסת אויר מצד שמאל ואילו כל הכרטיסי GPU לשרתים מצריכים איוורור מאחורי הכרטיס (בגלל זה הכרטיסים אטומים מצד שמאל). מהרגע שאתם מכניסים RTX 2080TI, אתם צריכים לקחת בחשבון שהכרטיס מהר מאוד יבצע שנמוך מהירות שעון הואיל ואין לו קירור מספק ואתם יכולים להגיע למהירות עיבוד של .. RTX 2070.

מעבר לכך, עם ה-VCS יש סוף סוף ניצול לחיבור ה-NVLink והעברת המידע ב-GPU בין הכרטיסים במהירות של 100 ג'יגהביט לשניה. ב-RTX 2080TI יש רק חיבור אחד כך שניתן לצוות מקסימום זוג כרטיסים. אם נכניס 8 כרטיסים כאלו לשרת וננסה להשתמש בכולם (הגדרת TCC), המערכת תצטרך לעבוד יותר לאט הואיל וה-DATA צריך לעבור הלוך ושוב בין ה-GPU (דרך המעבד וה-RAM בשרת) לדיסק וההיפך, ואילו עם כרטיסי Tesla וכרטיסים אחרים לשרתים (Quadro RTX) ה-DATA עובר בין כרטיסי ה-GPU דרך ה-NVLINK כך שהדברים רצים הרבה יותר, ועוד לא הזכרתי שמבחינה חוקית NVidia אוסרת על הפעלת כרטיסי RTX 2080TI (או כל RTX "ביתי") על שרתים והם יכולים מחר בבוקר בעדכון CUDA ודרייבר פשוט לבטל אפשרות שימוש בכרטיסים ביתיים בשרתים, כך שחשוב לקחת זאת בחשבון.

עוד נקודה ש-NVidia הכריזו היא הקמה של Repo חדש לקונטיינרים שמשתמש ביכולות CUDA ונקרא NGC. זה לא ממש חדש (ומשתמשים בו ב-DGX שלהם), אבל הפעם זה פתוח לקהל. לתשומת לב צה"ל, חברות בטחוניות וכו' שלא ממש מוכנים/יכולים לעבוד באופן ישיר מול האינטרנט – אין שום בעיה להוריד מה-REPO של NGC (ואחרים למען האמת) ולאכסן זאת דרך Registry משלכם. הנה לינק איך עושים זאת עם לינוקס.

לסיכום: אם אתם צריכים/משתמשים במערכת וירטואליזציה לצורך AI/DL או לשימוש עם קונטיינרים, הפתרון החדש של NVidia יכול בהחלט להתאים לכם. קחו בחשבון שאם אתם צריכים מקסימום מהירות, עדיף לרכוש את כרטיסי ה-Tesla או כרטיסי ה-Quadro (או כרטיסים עם האות V) עם חיבור NVLink כפול בכל GPU.

עדכונים בנושאי וירטואליזציה ו-VDI

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

אתחיל בנושא VDI.

תודות לחברת CRG שהשאילה לי כרטיס AMD S7150 לצרכי בדיקות VDI – התחלתי לבדוק את הנושא. לצערי הכרטיס הזה לא ממש עובד על מעבדי Xeon ישנים (סידרה V1-V2). הזמנתי לוחות אם של Supermicro יד שניה מסוחר ישראלי ו… גיליתי להפתעתי שהלוחות פגומים (פגומים במובן שכאילו מישהו העביר פטיש על תושבות המעבדים ועיקם את רוב הפינים!). מכיוון ששילמתי ב-Paypal, הצלחתי להחזיר את הלוחות ולקבל את הכסף בחזרה, כך שלא יכלתי להתקדם הרבה עם הכרטיס והחלטתי להחזיר אותו ל-CRG.

לא הרמתי ידיים, החלטתי לבצע בדיקות סימולציות משתמשי דסקטופ (כלי מצוין לכך: LoginVSI, יש גירסת התנסות בחינם) במובנים הבסיסיים לצרכי רואה חשבון ועורכי דין שמדי פעם גם צופים פה ושם בוידאו. התברר לי שכשמדובר בכמות קטנה (5-8 תחנות) של משתמשים, ואם משתמשים ב-RDP בלבד – לא יהיה צורך בכרטיס GPU לצרכי VDI. המעבדים בשרת מודרני יכולים לעמוד יפה בעומס. (אני ביצעתי את הניסויים על מעבד דסקטופ AMD Ryzen 7 2700X, כך שמעבדי Xeon יכולים לעשות זאת בקלות).

מכאן נעבור לברזלים: אני ממליץ על שרת בתצורת TOWER מהסיבה הפשוטה שלרבים אין מקום להכניס שרת 1U/2U רגילים מבלי לרכוש ארון תקשורת בעומק 80 ס"מ, מה גם שהוא מרעיש. שרת במארז Tower בדרך כלל הרבה יותר שקט והאיוורור בו הרבה יותר טוב ויעיל.

מבחינת אחסון, אני ממליץ להשתמש ב-Synology. אפשר כמובן להכניס דיסקים מכניים בשרת, אבל היתרון הגדול של Synology הוא שניתן לגבות גם מכונות ב-ESXI החופשי (כן, רוב התוכנות מאפשרות גיבוי רק אם יש לך את הסט שכולל vCenter וכו', התוכנה של Synology יודעת לעקוף זאת), כך שניתן להחליט אם להשתמש בדיסקים בשרת או ב-NAS (ולגבות לענן לדוגמא). עלות תוכנת הגיבוי כלולה ב-NAS עצמו, כך שאין צורך לשלם בנפרד, יש גיבויים מלאים, אינקרמנטליים, ואפשרות גם להריץ במקרה חרום VM מגובה מה-NAS עצמו אם VM ב-ESXI נדפק ואין זמן לשחזור מלא (את האופציה הזו מומלץ להשתמש אך ורק במקרה חרום. זה איטי).

מבחינת תקשורת: אני ממליץ  חיבור 10 ג'יגהביט בין השרת ל-Switch (לרוב המתגים יש Uplink של 10 ג'יגה בחיבור +SFP) – אם כל המשתמשים צופים בוידאו – קידוד ה-RDP + קידוד H.264 + תעבורה של הדסקטופ לוקחים לא מעט.

אסכם את הנושא כך: עם ESXI חינמי, עם מכונה בתצורת Tower שכוללת 2 מעבדים של 8 ליבות כל אחד, 128 ג'יגהבייט זכרון, דיסקים מקומיים, NAS של Synology ומתג נורמלי – אפשר לייצר "סביבת VDI". הפתרון, כמובן, לא VDI כמו Horizon או Terminal Services והוא גם לא מתיימר לכך, הוא בסך הכל נועד להעביר כמות קטנה של מכונות פיזיות ישנות ולהמירן ל-VM ולעבוד עליהן. אם מדובר על עשרות של מכונות פיזיות וכו' – אז כדאי בהחלט לחשוב על פתרון VDI מלא.

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

ומכאן – לוירטואליזציה (אצלי לפחות): עד היום עבדתי הן עם KVM והן עם oVirt/RHV (שמבוסס על KVM). ברמת המאקרו – הפתרון הזה הוא פתרון מעולה לוירטואליזציה, אבל ברמת המיקרו, יש כמה באגים וחוסרים קטנים שיכולים לשגע פילים: נסיון הוספה של Nodes שאינם מבוססים על מעבדי Intel מפיל את התהליך, כי התהליך לא יודע לזהות מעבדים אחרים ויש צורך להגדיר הכל ידנית ועוד כל מיני דברים קטנים. אפשר כמובן לדווח על באגים, אולם כל עוד אינך לקוח משלם – אולי תזכה ליחס ואולי לא. מכיוון שאני צריך להריץ על מספר מכונות כאשכולות, אני צריך פתרון רציני ולכן אני חוזר ל-vSphere, עם כל הצער שבכך.

עננים: במהלך השבועות הקרובים אתחיל להעלות קליפים נוספים הקשורים בתכנון מכונות על AWS, על שימוש ב-VPC (תתפלאו כמה חברות כלל לא מגדירות VPC ומשתמשות ב-Default), על Load Balacing ועוד.

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