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

מי שקורא את הבלוג הזה בקביעות, בוודאי קרא את ההתמרמרות שלי לגבי משרד האוצר, אגף החשכ"ל, מינהל הרכש (ובקיצור – חשכ"ל) – מדוע הם חוסמים את הפרילאנסרים ואת העסקים הקטנים שלא יכולים לעמוד בתנאי מכרז כמו ערבות בנקאית של 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 של אמזון.

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

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

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

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

לרובוט אין הפסקות סיגריה, אין כאבי גב, אין "עצבים" בגלל עובדים אחרים, אין עיצומים/שביתה, קל ללמד אותו דברים נוספים (זה לוקח בערך 2 דקות ואת זה ניתן לעשות בעת הטעינה שלו), והשאיפה היא ש-1-2 עובדים יוכלו לנהל צי של 50-100 רובוטים במקום גדול (רוב החברות בארץ שעובדות על רובוטים, עובדות על רובוטים שיתנהלו במרחבים ענקיים). גם מבחינת קופות ממוחשבות, הקופות שיש כיום בשרות עצמי מהוות (שוב, לא בארץ) מעין Stop Gap והשאיפה היא לעשות את הכל עוד בעגלה עם מחשב קטן וסורק, כשהתשלום ואריזה יבוצעו בעת החזרת העגלה, כך שסופר גדול בחו"ל מחזיק לדוגמא 30 קופאיות, הוא ירד ל-3-4.

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

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

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

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

אחד הדברים שבגללו אנשים רבים לא ניגשים ללמוד תחומי היי-טק הוא החשש עקב אי הכרת התחום מהעבר. איך אמר לי מישהו "חץ, לך יש יותר מ-20 שנה נסיון, לי יש אפס נסיון", והתשובה שלי אליו היא שברוב הדברים זה פשוט לא רלוונטי. יש דברים בסיסיים שצריך ללמוד, כמו מה-זה רשת תקשורת, מושגי מחשב בסיסיים וכו', עניין שיכול לקחת בין כמה שעות לכמה ימים, אבל אם יבוא מישהו כמו אותו בחור לעיל ללמוד לדוגמא Javascript ואני אבוא ללמוד Javascript, ההבדל בינינו יהיה מזערי – כי אני לא פיתחתי כלום בעבר ב-Javascript ולא למדתי את השפה. כשאני התחלתי לעבוד בתחום, מערכת הקבצים ברשתות היתה Novell Netware 2.11 ורשתות התקשורת היו מבוססות Token Ring. מבלי להיכנס להסברים על מה זה – נאמר שאף אחד כיום לא משתמש באף טכנולוגיה כזו.

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

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

אשמח אם תוכלו לשתף פוסט זה עם חברים שאתם חושבים שהיי-טק ופיתוח יכול להתאים להם.

יש לך גיבויים למכונות שלך בעננים?

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

כמו בענייני אבטחה, רבים נוטים לשכוח שספקי ענן לא נותנים אחריות לגבי השירותים שאתם משלמים עליהם. אם הלך לך ה-DATA – זו בעיה שלך, וזו לא דעה שלי. אם נסתכל בתנאי השרות של AWS, סעיף 4.11 קובע בפירוש את הדברים הבאים לגבי EC2 לדוגמא:

"As part of using Amazon EC2, you agree that your Amazon EC2 resources may be terminated or replaced due to failure, retirement or other AWS requirement(s). We have no liability whatsoever for any damages, liabilities, losses (including any corruption, deletion, or destruction or loss of data, applications or profits), or any other consequences resulting from the foregoing. "

במילים אחרות: מכונות יכולות להיתקע או להתקלקל וברגע שתפעיל את ה-Instance מחדש, הוא אוטומטית יופעל על מכונה תקינה, אך יחד עם זאת, הדיסק הוירטואלי שלך שרץ על EBS – זה משהו אחר. EBS יכול להתקלקל (אמזון מתחייבים על Five Niners, כלומר 99.999%) ואמזון תעשה את המאמצים לשחזר, אך אם הם לא יצליחו, הם לא יהיו אחראים ל-DATA שאיבדת.

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

אז מה ניתן לעשות? להלן מספר אפשרויות:

  • כל ספק ציבורי מאפשר ליצור Snapshot לדיסקים שנמצאים ב-Instnace. השימוש ב-Snapshot יכול להיות הן לשחזור, והן להמרה ל-Image (אם אתם רוצים ליצור Image חדש ל-Instances חדשים). יצירת ה-Snapshot נעשית "מבחוץ" (בין אם דרך ממשק ה-Web, דרך ה-SDK/CLI, או דרך כלי אוטומציה שתבחרו) ואין צורך ב-Agent כלשהו. ההוראות לבצע זאת ב-AWS נמצאות כאן.
  • Immutable מול Mutable: רוב האנשים שמגיעים מעולם הוירטואליזציה שרצה On Prem ומתחילים להשתמש בעננים ציבוריים – עובדים בשיטה שנקראת Mutable: יש לנו VM, עליו רץ כמעט הכל: האפליקציה, שרת ה-Web, אולי גם שרת SQL וכו' וברוב המקרים ה-DATA נשמר מקומית. בשיטה הזו גם המתודה לשדרג לגרסאות חדשות ולשנות דברים היא די בעייתית (במקרים רבים אפליקציות מצריכות שינויי הגדרות בין גירסה לגירסה, לדוגמא), ואם לא מדובר ב-instance יחיד אלא כמה וכמה – זה נהיה יותר מורכב, והשדרוג לא תמיד מצליח.
    שיטת ה-Immutable היא שיטה הרבה יותר קלה לעבודה: אנחנו מכינים Image Master שאינו כולל DATA, אך כולל את כל ההגדרות שאנחנו צריכים, ובעת ה-Deploy של ה-Image אנחנו נריץ סקריפט שנמצא בתוך ה-Image שיבצע את השינויים וההגדרות האחרונים שאנחנו רוצים (אפשר לדוגמא לכתוב סקריפט קצר של 2-3 שורות שימשוך מ-GIT את הסקריפט שיבצע עדכון הגדרות, לא לעדכן/להתקין חבילות אחרת זה רק יאיט את הזמן עד שהמכונה תהיה זמינה – את זה תעדכנו ב-Master Image). ב-Instance החדש שום דבר לא נשמר מקומית: לוגים עוברים לשרתי עיבוד (Elastic וחבריו), SQL רץ במקום אחר (שרות מנוהל או ממכונה אחרת), קבצים שצריך להנגיש מגיעים מ-EFS או S3, כך שבשרת עצמו שום דבר מהותי לא יכתב, ואם צריך – נוכל למחוק מיידית את ה-Instance ללא נזקים. את ה-Image הזה נוכל לעשות Deploy בכל כמות שנרצה (לא לשכוח לחבר אותם ל-Load Balancer). בשיטה הזו אין צורך לגבות את המכונות, אבל כן כדאי לגבות את ה-DATA שנשמר במקומות אחרים מחוץ ל-Instance.
    למעוניינים, יש בלינק הזה קליפ שמסביר זאת בצורה יותר מוחשית.
  • קונטיינריזציה/אורקסטרציה: עם קונטיינרים, אין שמירה של הדברים, הואיל וכשקונטיינר מפסיק לעבוד, הוא "מת" ולכן עבודה עם קונטיינרים מחייבת עבודה מול אחסון חיצוני. חשוב: את ה-Volume של הקונטיינר (או PV/PVC במקרים של Kubernetes או OpenShift) למפות למקור חיצוני. Kubernetes/OpenShift יודעים לתמוך במגוון מקורות כמו NFS, וגם Docker יודע לדוגמא לתמוך ב-NFS (תמיכה ב-iSCSI ל-Docker – בדרך).

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

קצת על פוליגרף, גופים פיננסיים וגופי בטחון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ה"היצמדות" ל-CUDA והעתיד

כפרילאנסר, אני מציע שרות שלא מעט חברות ועסקים זקוקים לו בהתחלה – והוא קשור ל-CUDA, הדרייבר של nVidia, והשבב הגרפי הפנימי שנמצאים במעבדים של אינטל (בתחנות עבודה). הצירוף של ה-GPU המובנה במעבד של אינטל וה-GPU של Nvidia לא תמיד יודעים "לעבוד" יחד, במיוחד בכל מה שקשור ל-OpenGL ו-Xorg וצריך לדעת איך "לפשר" ביניהם. מעבר לכך, ה-CUDA של Nvidia יכול לעבוד רק מגרסאות מסויימות בכרטיסי ה-GPU החדשים של NVidia כמו Tesla מסידרה T. כתוצאה מכך אני עוקב בזמני הפנוי אחרי גרסאות CUDA, דרייברים הן של אינטל והן של Nvidia.

מבחינת השוק כיום – בין אם מדובר בסטארטאפים, עצמאים וחברות שעובדים בתחומים הקשורים ל-AI, Deep learning וכו', כרטיסי ה-GPU המועדפים בצורה חד משמעית הם הכרטיסים של NVidia וכמובן הכל הולך לפי התקציב: למי שאין תקציב, רוכש כרטיסי RTX (כרטיסי ה-GTX כבר "מתו"), ולמי שיש תקציב – רוכש כרטיסי Tesla או Quadro. כשזה מגיע לשרתים, ההמלצה החד משמעית היא כרטיסי Tesla הואיל והאיוורור שיש בשרתים אינו מתאים לכרטיסי RTX (זה יעבוד, אבל הכרטיס יוריד עצמאית את מהירות העיבוד בצורה דרסטית בהתאם לטמפרטורות בכרטיס).

כתוצאה מכך, כל פלטפורמות הפיתוח (TensorFlow, Caffe וכו' וכו') תומכות בצורה מלאה ב-CUDA, כמו שהן תומכות בכרטיסי GPU אחרים (אם אין לך GPU של NVidia, אין שום בעיה לעבוד עם כרטיס GPU אחר, או עם ה-GPU המובנה או עם המעבד עצמו – הביצועים יהיו בהתאם). אם ביצועי GPU יחיד של NVidia אינם מספקים אותך (ורכשת כרטיס RTX 2080 ומעלה), תוכל להוסיף GPU נוסף (ויותר) ולחבר ביניהם עם מחבר NVLink שנמצא בחלק העליון של הכרטיס. פלטפורמת CUDA יודעת לזהות מיידית את הכרטיס ולחלק את העבודה ביניהם, תוך כדי שהיא נותנת "ציון" לכל GPU ובהתאם לכך היא מחלקת את העומסים.

כשזה מגיע לעננים ציבוריים, התמונה משתנה במעט. אם אתם משתמשים בעננים של אמזון או מיקרוסופט, אתם יכולים לשכור Instance הכולל GPU של Nvidia (מיקרוסופט מאפשרת כיום גם לשכור GPU של AMD, תיכף אתייחס לכך) ואילו גוגל מציעה ללקוחותיה לשכור Instance עם GPU של NVidia או עם פתרון משלהם שנקרא TPU (שנותן ביצועים שאינם נמוכים ממה ש-NVidia יכולה להציע גם עם הכרטיס הכי חזק שלה).

כאן מתחיל העניין שנקרא תחרות, ואת התחרות מייצג פתרון שנקרא OpenCL. פתרון OpenCL זקוק למימוש בדרייבר עצמו וכל יצרן (כולל NVidia) כותב זאת ומציע זאת ללקוחותיו. היתרון המוחץ של OpenCL על CUDA, הוא בכך שהוא מזכיר את OpenGL ו-DirectX – אתה יכול להשתמש באיזה GPU שתרצה, ובהתאם למימוש בדרייבר – התוצאות יהיו בהתאם. גם ה-TPU של גוגל וגם הפתרון GPU של AMD משתמשים ב-OpenCL במימושים שונים על מנת לאפשר למפתחים ולפלטפורמות את תמיכת ה-OpenCL שהן דורשות. (למעוניינים, להלן לינק המשווה בין OpenCL לבין CUDA. מי שמחפש את הגירסה המקוצרת: CUDA = פתרון סגור, OpenCL = פתרון פתוח לחלוטין שנתמך בכל GPU)

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

  • אינטל הכריזה לאחרונה על שני פתרונות ל-AI (גאווה ישראלית: הם פותחו כאן בארץ). הפתרונות הללו לא רק תומכים ב-OpenCL אלא במגוון פלטפורמות וכמיטב המסורת של אינטל בקטע הזה, הכל בקוד פתוח. זהו הכרטיס הראשון ל-AI ו-DL שמשתמש ב-PCIe 4 X16. הקטע האירוני: בשביל להשתמש בכל רוחב הפס, תצטרך כיום .. מעבד ולוח של AMD..
  • עוד פתרון חומרה כחול לבן הוא של חברת Habana שמציעים את GOYA ככרטיס למחשב ושרת, ואת GAUDI כפתרון כחלק ממערכת מלאה (כרטיס יעודי). גם כאן, יש תמיכה מלאה ל-OpenCL ומגוון פלטפורמות AI ו-DL.
  • עוד פתרון מגיע מסין מחברה מאוד ידועה – Huawei, אם כי בניגוד לשאר, החברה הציגה מעבד בלבד (כלומר לא פתרון קצר) בשם Ascend 910 שהחברה טוענת שהוא מעבד ה-AI הכי מהיר בעולם.
  • ל-AMD יש כרגע את כרטיסי ה-GPU מסידרת Instinct ל-AI ו-DL. החברה מתעתדת בחודשים הקרובים להכריז על הדור הבא.
  • אינטל (כן, שוב) – מתעתדת בשנה הקרובה להוציא משפחת כרטיסי GPU חדשים שתתחרה הן ב-GPU הרגילים של NVidia ו-AMD והן GPU למטרות AI ו-DL – הם יהיו תחת משפחה בשם "Xe".

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

דבר שחשוב לדעת: שוק פתרונות החומרה ל-DL, AI מתחיל להשתנות ולפצל דברים ל-2: יש את פתרונות ה-Training (כלומר – הדברים שרצים אצלכם בחברה – אתם "מזינים" אלפי תמונות/וידאו וכו' ומאמנים את המערכת) ויש את החלק של Inference שצריך להתמודד עם העולם האמיתי, והחלק של ה-Inference אמור לכלול פתרון יעודי (כרטיס מיוחד או חלק מלוח אם) שישולב בפתרון החומרה שיותקן אצל הלקוח.

עוד נקודה חשובה: ישנם כל מיני אנשים שממליצים לבצע את ה-Inference על מעבדים. אם אתם רוצים לעשות זאת על מעבדים, קחו את המעבדי EPYC החדשים של AMD – גם תחסכו 40-70% במחיר (תלוי בכמות הליבות) ותוכלו לבחור מעבד עם עד 64 ליבות או 2 מעבדים עם 128 ליבות (שימו לב: אתם צריכים את הסידרה החדשה 7XX2, לא את הישנה 7XX1).

לסיכום: כמו תמיד, אינני ממליץ לשים את כל הביצים בסל אחד. כן, הפתרון של NVidia הוא פתרון מעולה אך הוא פתרון סגור שרץ רק על הכרטיסים של Nvidia. אם אתם מפתחים פלטפורמה או קוד בפלטפורמה או אפליקציה משלכם, תבדקו אם היא עובדת עם OpenCL. אחרי הכל – אינכם יודעים מה הלקוח שלכם ירצה להריץ וחבל למצוא את עצמכם בדקה ה-90 מציעים פתרון שלא יכול לרוץ בתשתית של הלקוח. השוק ישתנה ב-2020 ועוד יותר ב-2021 (לכל החברות "נפתחו העיניים" וכולם רוצים את הרווחים המאוד נאים ממכירות כרטיסים ופתרונות כאלו).