כמה מילים על לימוד-מכונה ועל GPU ועננים

עדכונים לפוסט – בסופו.

בשנים האחרונות, תחום ה"לימוד מכונה"/"לימוד עמוק"/"AI" ושלל שמות נוספים (ותוסיפו לכך טונות של Hype) קיבלו תאוצה מאוד חזקה. כיום התחום "חם" מאוד ואלו שמכירים את התחום נחטפים, וחברות כמו אמזון וגוגל מציעות משכורות מאוד מפתות (כמה מפתות? 50K ומעלה לחודש, בשקלים כמובן, ויש גם מענק חתימת-חוזה, תלוי כמה אתה מכיר, וכמה אתה מנוסה). סטארט אפים לנושאים אלו צצים כמו פטריות לאחר הגשם וכמובן שחברות הענן הציבורי הזדרזו להוציא שרותים שמציעים תחומים אלו בקלות מופלאה – תכניס את ה-DATA, הנה API קל לשימוש ובהצלחה.

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

מכיוון שהתחומים הללו מכסים תחומים כמו אודיו, וידאו, צ'אט בוטים ודברים רבים נוספים, לא ניכנס לדברים במובנים הטכניים לעומק אלא נדבר על הדברים בכלליות. באופן עקרוני, לא חשוב איזה AI או Deep Learning או Machine Learning מדובר, הכללים די ידועים:

  • אתה בונה את התוכנה (או משתמש בשילוב של Tensorflow, Caffe2 ושאר ספריות) ו"מסביר" לתוכנה מה אתה בעצם רוצה לעשות.
  • אתה מכניס את הנתונים שאתה רוצה לעבד.
  • אתה מכוון שוב ושוב ושוב ו"מאמן" את האלגוריתמים שהתוכנה תכיר את הנתונים ותתן תוצאות שאתה רוצה שתתן – עד לתוצאות שאתה רוצה.

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

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

זה – במבט על מגבוה בערך מה שקורה.

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

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

חברות גדולות שעוסקות בתחומים הללו כבר למדו שבכל מה שקשור לאימון, עדיף לעשות זאת In house ולא לסמוך על עננים, ומכיוון שהן חברות גדולות, הן יכולות להרשות לעצמן לרכוש מכונה כמו ה-DGX-1 של nVidia. כמה עולה המכונה הזו? 130,000 דולר, סכום שאין להרבה סטראטאפים או חברות קטנות או בינוניות. בשרת זה ישנם 8 כרטיסי Tesla מבוססי Volta (הארכיטקטורה החדשה של nVidia) שכוללים ליבות יעודיות ל-Tensor והרבה ליבות שמיועדות ל-CUDA. בנוסף, הכרטיסים מחוברים ביניהם עם NVLink שנותן מהירות מדהימה של 200 ג'יגהבייט לשניה פר כרטיס. בקיצור – מפלצת יעודית ל-AI/DL/ML. (אפשר ללחוץ על התמונה על מנת לקבל את הפרטים).

לאחרונה חברת nVidia הבינה שאותם חברות קטנות ובינוניות מעוניינות גם בפתרון. הם לא מחפשים לקנות DGX-1 והם מעדיפות פתרון יותר זול אך חזק. כרטיסים גרפיים כמו GTX 1080TI או אפילו Titan Xp הם טובים, אך המהירות עדיין אינה מספיקה.

לכן nVidia הוציאה בימים האחרונים את הכרטיס מימין. תכירו – זה ה-Titan V, ה"אח הקטן" של Tesla V100. מדובר על כרטיס עם אותו GPU כמו אחיו הגדול, אך יש לו 12 ג'יגהבייט זכרון (ב-Tesla יש 16), אין אפשרות לשרשר אותו עם Titan V אחרים (ואין SLI) ויש עוד מס' הבדלים – טבלת השוואה ניתן לראות כאן. אגב, אם אתם רוכשים כרטיס כזה, שדרגו ל-CUDA 9.1 שידע לתמוך בכל הפונקציות של הכרטיס.

מחיר הכרטיס (לא כולל מסים ומכס) – 3000$. יקר בהרבה מכל כרטיס אחר שמיועד ללקוחות פרטיים, אבל עדיין זול בהרבה בהשוואה ל-Tesla V100 (שאותו בין כה לא תוכלו להכניס לרוב השרתים). עם כרטיס כזה, אני יכול להבטיח לכם שהביצועים שלו יהיו גבוהים בהרבה מכל Instance עם GPU שתרימו בענן. (ניתן כמובן להרים מס' מכונות VM בשרתים מקומיים ולכל מכונה להצמיד GPU כזה בשיטת GPU Passthrough, כדאי לשאול את יצרן השרת לגבי התמיכה ב-Passthrough ולגבי IOMMU).

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

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

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

עדכון 17/12/17: קיבלתי פניה לגבי מידע שגוי שאני מפרסם בפוסט זה ולכן אני רואה צורך להבהיר: אינני אומר ששום ענן ציבורי לא נותן תשתית מואצת GPU (במקרה של אמזון ומיקרוסופט – Tesla ובמקרה של גוגל – TPU). כולם נותנים שרות SAAS כזה או אחר ל-ML/DL מואצים, אבל זהו שרות SAAS. למי שמחפש פתרון VM או קונטיינרים נטו שבהם הוא יכול להשתמש בפשטות ב-tensorflow-gpu עם PIP ועם הקוד שלו – זה כרגע למיטב ידיעתי והבנתי – לא קיים.

כשצריכים לבחור Storage לסטודיו

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

אותה חברה החליטה לעבור ל-NAS אחר ובאותה הזדמנות לעבור לחיבור 10 ג'יגהביט לכל מכונות הדסקטופ.

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

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

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

הדבר הראשון שצריך לקחת בחשבון הוא בעצם את החומר שאנחנו הולכים לערוך וליתר דיוק – בכמה מגהביט מוקלט הוידאו. יש הבדל עצום בין וידאו שמוקלט ממכשיר טלפון סיני, מאייפון או גלקסי – לבין מצלמות DSLR מקצועיות, מצלמות וידאו מקצועיות (כמו Sony) ומצלמות RED בדחיסה נמוכה. המצלמות הפשוטות בטלפון מקליטות ב-10-20 מגהביט ואילו RED יכולות להגיע בערך ל-300 מגהבייט לשניה ואני מאמין שיש מצלמות שמקליטות במגהביט יותר גבוה.

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

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

ובנוגע לרשת שהחבר'ה ב-FStoppers הקימו, לו היו החברים קוראים את הסטנדרט בגירסה הקצרה, הם היו מוצאים שהכבלים שהם רכשו, ולא חשוב מאיזה פירמה – לא יתנו תמיד 10 ג'יגהביט הואיל ו-CAT7 מספק 10 ג'יגהביט עד אורך 100 מטר, לא 200. בשביל 200 מטר יש צורך להשקיע בכבלים CAT 7A או ברכישת כבלים מוקשחים (כאלו שמכניסים בקירות).

הצורך באיש DBA

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

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

לא חשוב מהו שרות ה-SQL המותקן בשרת, בד"כ הם עושים את העבודה Out of the box בצורה טובה יחסית, אבל במקרים רבים לקוחות מתלוננים על כך שהעבודה שהוא מבצע היא איטית, החשש שהטבלאות גדולות מדי, ומדוע דבר שרץ מקומית על המכונה של המפתח לוקח 0.1 שניות – על השרת לוקח 4 שניות לדוגמא..

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

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

אישית אני מודע לכך שלכל שרת SQL יש הגדרות של Cache שעוזרות בהאצת עיבוד השאילתות וקריאה/עדכון/מחיקת נתונים מה-SQL, אבל בד"כ ממה שראיתי – אם כבר בהתחלה רצים לשנות את גודל ה-Cache, אותן בעיות יצוצו שוב בהמשך, כי הבעיה היא לא ב-Cache והגודל, אלא בצורת השאילתות.

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

בהזדמנות זו – אם ישנם אנשי DBA פרילאנסרים – אשמח אם תשלחו לי מייל ([email protected]) עם הפרטים שלכם כך שאם פונים אליי ומבקשים שרות זה – אפנה אותם אליכם.

תמיכת מוצר מול הסכם בנק שעות

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

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

רמות 1-3 (ושאר רמות) הן דרך מצוינת "לחלוב" מעסקים כספים. ככל שהרמה עולה, אתה משלם יותר. בעולם הלינוקס לדוגמא, רמות לא קיימות. כשאתה קונה לדוגמא SLES או RHEL, אז אתה מקבל תמיכה על גירסת הלינוקס שרכשת (בהמשך אכנס ליתרונות ולחסרונות). אם התמיכה בחבילה שרכשת אינה מספקת לסיטואציה שלך, אז אתה יכול לרכוש שרותי Incident או Consulting (כל חברה והמושגים שלה) שבה אתה תשלם כמה מאות דולרים לשעה, ויצרן ההפצה יקדיש לך מישהו שישב על המערכת שלה למצוא מה התקלה ואיך לפתור אותה. היכן יש רמות בעולם הלינוקס? ברמת הדחיפות. אם ניקח לדוגמא את רמות התמיכה של Red Hat, נוכל לראות שיש רמות ב-SLA. רוצה שרות טלפוני? שלם 800$ פר עותק הפצה. רוצה שרות מהיר? המחיר קופץ ל-1500$ פר עותק (שוב, המחירים אינם כוללים מצבים שבהם מהנדס מוצמד לעסק שלך לפתור את הבעיה, שם התשלום ליצרן ההפצה הוא בנפרד ממה ששילמת על ההפצה).

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

כשזה מגיע לעסקים וחברות שמריצים עשרות/מאות/אלפי מכונות לינוקס לעומת זאת, אין יתרון ברכישת מנוי שנתי לתמיכה של יצרן ההפצה. בעסקים וחברות, ברוב המקרים התוכנות שמריצים על הלינוקס – הן יותר חדשות ממה שמגיעים עם ההפצה. לדוגמא, גירסת PHP שמגיעה בהפצת RHEL 7.4 היא גירסה 5.4.16 כאשר הגירסה היציבה היום לפי אתר PHP היא 7.1.10. אם תתקין את 7.1.10 על ה-RHEL ויהיו לך בעיות שה-PHP לא מצליח לרוץ, רד-האט לא תתן לך שרות הואיל והם נותנים אך ורק שרות לחבילות שהגיעו עם ההפצה עצמה, לא מ-REPO נוספים. דוגמא נוספת: רוצה להשתמש ב-NodeJS? הגירסה שקיימת היום ב-EPEL REPO היא אכן גירסת ה-LTS האחרונה, אבל שוב – מכיוון שזה REPO חיצוני, אין תמיכה רשמית מצד רד-האט.

לכן אני ממליץ לחברות לחשוב על כמה נקודות:

  • אם יש בחברתכם IT שנותן תמיכת לינוקס, ואתם חושבים במהלך השנה להכניס טכנולוגיה/פלטפורמה חדשה – קחו יעוץ חיצוני (גם אם זה לשעות בודדות) שמכיר את הטכנולוגיה החדשה. חבל שתשרפו עשרות שעות על תקלות שהיועץ החיצוני כבר מכיר.
  • אם בחברתכם יש חובה להשתמש בהפצה מקורית (RHEL או SLES) ואתם רוצים עדכונים, אז מומלץ לחשוב על רשיונות SuSE Linux Enterprise עם Expanded Support – זה יתן לכם עדכונים גם ל-RHEL וגם ל-SUSE וזה גם יותר זול מ-RHEL מבחינת רישוי שנתי.
  • כיום כמעט בכל פרויקט לינוקס, החבילות מגיעות מבחוץ (Github או REPO חיצוניים) אינן נתמכות ע"י יצרן ההפצה ולכן אם אין לכם צוות לינוקס בחברה שיכול לבצע אינטגרציה במסגרת הזמן שאתם רוצים – קחו יעוץ חיצוני (כדאי לסכם שיכתבו עבורכם תיעוד).
  • אם אתם משתמשים (או חושבים לעבור) לאובונטו, עדיף לרכוש בנק שעות חודשי ליעוץ מומחה.

החלוקה

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

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

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

התשובה: אני מעריך בין 1 ל-2. להלן הסיבות מדוע המספר נמוך:

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

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

  • "לא בטוח שרלוונטי" – במקרים אלו הסיכויים לקבלת שכרך ובזמן אינם כה גבוהים. דוגמאות:
    • אתה מבקש מחיר של 200 ש"ח + מע"מ לשעה, הם מוכנים לשלם לך .. 50 ש"ח לשעה או שהם מוכנים לשלם לך באחוזים וירטואליים תמורת "שותפות", ושאר ירקות.
    • הצעות מפוקפקות – הם מוכנים לשלם לך פחות או יותר את מה שאתה מבקש אבל הכסף לך יגיע לחשבונך מחו"ל וינכו משכרך כמה עשרות דולרים על כך, או שתנאי התשלום אינם ברורים.
    • תשלום שכר בסימן שאלה – הסטארט-אפ ישמח לשלם לך… ברגע שימצאו משקיע/אנג'ל. עד אז תקבל חלק קטן מהשכר שביקשת.

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

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

אז מה ניתן לעשות בנידון? איך ניתן להשיג עוד עבודות? להלן מספר נקודות חשובות:

  • פרסם עבודות שאינן מתאימות לך. אתה מומחה בפייתון ומישהו מחפש מתכנת ++C? קח את פרטיו ופרסם את פרטי ההצעה (אתה יכול לפרסם כאן וכאן).
  • עדיין לא הומצאה מכונה לקריאת מחשבות ואיש אינו יודע אם אתה במצב של 0 עבודות או שאתה מחפש עבודות, מחפש עבודה קבועה לחצי משרה, מחפש משרה מלאה לטווח ארוך וכו'. אל תתבייש, תפרסם זאת! (הח"מ מחפש לחצי משרה 🙂 ), זו הדרך הכי מהירה שחברים ישתפו זאת וסיכוייך לקבל משרה כך אינם נמוכים.
  • פרסם תכנים משלך על התחומים שאתה נותן בהם שרות(ים) ומדי פעם תבצע קצת SEO כך שגוגל יעלה את דירוג הבלוג/אתר שלך.. להלן דוגמא על קונטיינרים:

  • הדגם את יכולותיך. קל לדבר ולכתוב על דברים אבל אם יש משהו שמושך אנשים להתעניין בשרותיך – הם הדגמות של הדברים. התקנה של דברים מאפס, הגדרות שונות, הסברים איך מפעילים דברים וכו'. כל מה שאתה צריך זה חשבון בגוגל, מיקרופון ותוסף Nimbus לכרום (ניתן להתקנה מכאן). להלן דוגמא:
  • כרטיסי ביקור – נפגשת עם מישהו? אתה ב-Meetup ומשוחח עם אנשים? חלק כרטיסים, אולי יחזרו אליך. אל תשאיר אנשים עם תהיה "הבחור שפגשתי רציני, חבל שאין לי את הפרטים שלו".
  • הסעיף הבא נתון למחלוקת ביני לבין חבריי אך אני עדיין עומד על שלי: אם אתה טוב בתחומך, שקף זאת במחיר שאתה גובה. הנה כמה דוגמאות למחירים שמהם לא כדאי לרדת (תחום סיסטם/Devops/אינטגרציה/יעוץ). תזכרו שכעצמאים המדינה עושקת אותנו בכל מצב:
    • עבודה חד פעמית חרום לתיקון תקלה (מעכשיו לעכשיו) – לא פחות מ-300 שקל
    • חצי משרה קבועה – לא פחות מ-150 שקל
    • משרה מלאה קבועה (תשלום כנגד חשבונית, לא תלוש משכורת) – לא פחות מ-120 לשעה
    • יעוץ מומחה – פר שעות (בד"כ לוקחים מינימום שעה או שעתיים) – לא פחות מ-200 לשעה
  • "לחפור" קצת. הגעת ללקוח שרוצה ממך עבודה X. בדוק אם יש עוד דברים שאתה יכול לעשות עבורו ובכך להרחיב את העבודה או כמות שעות העבודה.
  • חשוב: דרוש מקדמה כאשר מדובר בעבודה גדולה. שיטות תשלום של ש+60 או ש+30 הן נחמדות אבל אם אין לך כרגע עבודות שאתה עושה בנוסף, אתה יכול להיתקע למצוקת מזומנים. אין כללים לסכום אולם אני לדוגמא נוהג לבקש בין שליש למחצית הסכום כמקדמה (בהתאם לכמות השעות או מחיר הפרויקט) וחשוב לוודא שהמקדמה תשולם לפני שאתה מתחיל לעבוד.

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

התהליך המומלץ בעת ביצוע פרויקט ע"י יועץ

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

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

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

לעניות דעתי, דברים צריכים להתבצע בדיוק ההיפך.

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

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

משם עוברים לשאר החלקים – אחסון (Storage), רשת (Network) ומחשוב (Compute). היכן מומלץ לחשוב על פתרון NFS והיכן מומלץ על פתרון בלוק כמו iSCSI? האם ללקוח יש תשתית תקשורת מתקדמת (10/25/50 ג'יגהביט) או שצריך לעבוד ב-Teaming? האם חיבור הסטורג' "יחנק" עקב עבודה מאומצת של הפתרון שהלקוח רוצה שירימו לו? האם הלקוח צריך לעבוד ב-HA או DR או שאם נופל הפתרון ויש השבתה זמנית זה לא יהיה קריטי בשבילו? ועוד לא דיברנו על שילוב אוטומציה, Workflow ועוד דברים אחרים.

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

עדכונים לגבי ESXI

זמן רב לא כתבתי על VMWare ESXI והגיע הזמן אולי לפרסם כמה דברים שחלק מהקוראים יודעים וחלק לא וגם לתת לכם זמן לחשוב לגבי גירסה עתידית של ESXI והאם כדאי יהיה לעבור אליה.

נתחיל בהווה: אם יש לכם גרסאות 4, 5, 5.1, 5.5 אז אולי הגיע הזמן יהיה לחשוב על שדרוג. לפי המסמך הזה של VMWare, גרסאות 4, 5.0, 5.1 כבר סיימו את חייהם מבחינת תמיכה ואם אתם מריצים גירסה 5.5 – היא תסיים את חייה ב-19/9/2018 כך שכדאי בתכנון התקציבי להכניס הוצאת שדרוג.

אם אתם משתמשים בגירסה 6.0 של ESXI אז מאוד מומלץ לשדרג לגירסה 6.5U1. השינויים בין 6.0 ל-6.5 הם רבים וכוללים שינויים ועדכונים ל-vSAN, עדכוני דרייברים רבים, מעבר ל-VSCA (ב-VMware ממש רוצים שתעבור ל-VCSA והם נותנים "הטבות" ב-VCSA כמו כלי מיגרציה, High Availability "טבעי", וגיבוי ושחזור "טבעיים" (של ה-Appliance, לגיבוי מכונות VM תמשיכו להשתמש ב-Veeam). ההתקנה של VCSA הרבה יותר קלה ואתם יכולים לקרוא על מגוון התכונות החדשות במסמך הארוך והרשמי כאן או בגירסה המקוצרת כאן. השדרוג מ-6.0 ל-6.5U1 עולה לכם … 0 שקלים מבחינת רישוי.

אם יש לכם גירסה 6.5, מאוד מומלץ לשדרג ל-6.5U1 בגלל כמה סיבות, להלן חלק מהן:

  • גירסת VSAN שודרגה ל-6.6 (והיא מצריכה ESXI 6.5 כולל VCSA 6.5 או אם אתם עדיין בגירסת Windows – אז vCenter Server 6.5 – מומלץ בחום לעבור ל-VCSA, הוא יעביר לכם את הנתונים אוטומטית) ואם אתם עובדים All Flash תקבלו הפתעה נחמדה – שיפור של 50% בביצועים. בנוסף תכנון גדילה עובר עתה תהליך Pre-check כך שהדברים יהיו יותר בטוחים ולא יפלו עקב חישוב שגוי מצד מנהל המערכת. בנוסף מקבלים את vRealize Operation Management, תהליך ה-Deploy יותר קל, תהליך בדיקת התקינות שופר מאוד, אין יותר צורך ב-Multicast (אני יכול לדמיין אנחת רווחה מאנשי התקשורת), שיפורים ב-Cross Site Protection (לאלו שמשתמשים בזה, לא מכיר כאלו) ועוד. אפשר לקרוא מה חדש כאן.
  • אם אתם חושבים לרכוש ברזלים חדשים כמו שרתים מבוססי מעבדי EPYC (שאפו!) או שרתים מבוססי דור 5 של Xeon – תצטרכו את ה-Update 1 של גירסה 6.5, אחרת תקבלו מסך סגול והמון עצבים. לאלו שרוצים להריץ בביתם כ-LAB את גירסה 6.5 על מעבדי Ryzen או Threadripper או Skylake-X – גם אתם תצטרכו את גירסת 6.5U1. (לא מומלץ לנסות על Kabylake-X – ניסיתי, זה נופל לאחר זמן מה מבחינת ביצועים ו-VMware אפילו לא מוכנים להתייחס לכך).
  • עדכוני דרייברים – ישנם עדכונים לכל כרטיסי הרשתות, החל מכרטיסים בסיסיים כמו כרטיסים מבוססי אינטל של 1 ג'יגהביט ועד לכרטיסים של 40/50 ג'יגהביט (למיטב ידיעתי כרטיסים של 100 ג'יגה תצטרכו דרייבר יצרן עדיין).
  • ה-vCenter יכול להיות ב-High Availability באופן טבעי ללא צורך בקפיצת ראש לבריכה בעומק חצי מטר. מגדירים Active, Passive ו-Witness ויאללה – יש HA. פונקציה זו אינה קיימת בגירסת Windows. כמו שאמרתי – VMWare מאוד רוצים שתעופו מגירסת ה-Windows לטובת גירסת ה-Appliance.
  • שדרוג מכונות ESXI הרבה יותר קל וברוב המקרים אוטומטי לגירסה אחרונה עם VCSA. שימו לב: קודם משדרגים Appliance ורק אז את ה-Hosts.
  • גם VUM עבר שדרוגים בכל הקשור לעדכונים ומעתה הוא יכול גם לשדרג אוטומטית (אם תרצו) מכונות VM לגירסה אחרונה (או גירסה שתקבעו) של תאימות VM.
  • בכל הקשור ל-Auto Deploy, מי שמנהל את ה-vSphere בחברה אולי ישמח לדעת שהוא פחות יצטרך להשתמש ב-PowerCLI ועכשיו יש ניהול גרפי מלא של הדברים וגם בניית Image חדש של ESXI Boot תוך כדי הוספה והעפה של דרייברים.
  • ויש עוד ערימות של תכונות חדשות…

אחד הדברים החשובים לגבי תשתית vSphere מהגירסאות הקיימות לגירסה 7 העתידית – זה שגירסה 7 העתידית תהיה שונה מאוד ממה שהיה עד כה. זה לא סוד ש-VMWare עובדים לאט (רק בגירסה 6.5 הם התחילו לתמוך ב-VMWare tools חתומים והתקנה של מערכות הפעלה עם Secure Boot), אבל בגירסה 7 הם רוצים לסגור פערים. העולם עובר לקונטיינרים וכרגע ל-VMware אין תשובה ב-vSphere באופן רשמי, כנ"ל לגבי פתרון תחרותי ל-OpenStack או Azure Stack של מיקרוסופט (אם כי יש להם כלי להקים OpenStack בתוך vSphere – ראו למטה), כך שגירסה 7 תהיה שונה לחלוטין מכל הגרסאות הקודמות. אי אפשר למסור עליה פרטים (אין לי הסכם NDA עם VMware אבל מצד שני אין לי חשק מחר לקום בבוקר ולקבל טלפון וצעקות מאנשים שם) אך מה שכן אפשר לאמר – שהיא בהחלט תקל על חברות גדולות שרוצות לעבור להשתמש בקונטיינרים (ויש לה כבר פרויקטים בקוד פתוח בנושא, אפשר לראות אותם כאן – ויש המון). משהו אחד שאני יכול להמר (אין לי בסיס משמועות לכך) זה ש-VMWare גם תבצע אינטגרציה של VMWare Integrated Openstack לתוך vSphere בעזרת מוצרים משלימים שיש כבר ל-VMware ובעזרת חלקים בקוד פתוח (שהיא תשחרר שינויים תחת אותם רשיונות). אגב, למי שלא מכיר את התוכנה – מוזמן לעקוב אחר המצגת הנחמדה כאן.

לסיכום: ישנם לא מעט חברות גדולות שרוצות להישאר רק על VM, לא ענן מבוסס OpenStack, לא קונטיינרים (אולי בעתיד) וחברות רבות הן גם מאוד שמרניות, לכן אני חושב שנראה כאן מעין "קו" וירטואלי בין מוצרים והטמעות שחברות יבחרו. עד גירסה 6.5U1 ה-vSphere סובב כולו סביב VM והתשתיות לספק את הדרישות ל-VM (רשתות, סטורג' וכו'). מגירסה 7 המוצר יהיה הרבה יותר גדול ומורכב בהרבה מהיום ולא בטוח שחברות ירצו לקפוץ אליו  ויש מצב שיותר ויותר חברות יחליטו להישאר עם 6.5U1 ואת השאר להעביר לעננים ציבוריים במקום לשדרג לגירסה 7 (ודרך אגב, אני מאמין שגירסה מוקדמת שלה אנו נראה ב-VMWorld שתתרחש עוד 18 יום ולאחר מכן ב-VMWare Europe. אגב, בכנס הזה נראה את התשובה של VMWare לאינטגרציה עם עננים ציבוריים, לא רק של אמזון).

הולך להיות מעניין…

כמה מילים על תחנות עבודה לטיפול בוידאו

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

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

כשזה מגיע לבתי סטודיו שרוצים לשדרג כמות של מכונות ומבחינתם לשלם עוד $1000 זה לא ממש ביג דיל, אז ההמלצה שלי היא פשוטה: קנו מחשב מותג של יצרן מוכר, כלומר תחנות של Dell, HP או Lenovo. המכונות האלו בנויות כמו טנק, ניתן לשדרג שם (ללא שבירת אחריות) זכרונות, דיסקים וכרטיס גרפי, וכשאותו סטודיו רוכש את התחנות, הוא יכול להרחיב את האחריות ל-3 שנים ולכלול טכנאי עד העסק כך שאם יש תקלה, טכנאי מגיע ומחליף את החלק במקום ללא צורך בהמתנה שמחשב יגיע למעבדה, יטופל ויוחזר. החסרון היחיד שיש עם תחנות כאלו הוא שהסטודיו לא יכול לקבל תמיכה על התוכנות וידאו/אפקטים/תמונות שיותקנו על התחנה ובשביל זה כל סטודיו בד"כ חותם על חוזה שרות עם עצמאי שנותן להם את השרות או שהם שוכרים מישהו כשכיר שיתן תמיכה.

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

האם באמת שווה לרכוש מאותם עסקים מקומיים את אותם מחשבים? האם באמת שווה להשקיע יותר?

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

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

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

לוח אם

לוח האם הוא החלק העיקרי בו הכל יושב ודרך לוח האם הכל מתחבר יחדיו. ישנם לוחות אם מעשרות יצרנים וחשוב להבדיל ביניהם. לכל מעבד יש צורך בלוח אם מסוים (ומחיר שונה). 2 נקודות חשובות לגבי לוח אם:

  • כדאי מאוד שזה יהיה מיצרן מוכר ואמין. יצרנים כאלו הינם: ASUS, MSI, ASrock, Gigabyte. לוח שאינו מהיצרנים הללו עלול להתקלקל בעבודה מאומצת והשבתה לאורך זמן.
  • אם המחשב הזה הולך לשרת אתכם למשך 3 שנים, מומלץ להשקיע מעט יותר בלוח האם ולבקש לוח עם לפחות 2 תושבות לכרטיס גרפי. בלוחות כאלו ניתן להרחיב יותר זכרון ואפשר להכניס יותר כרטיסים גרפיים (כיום זה לא כל כך אקטואלי אבל אני מניח שבשנה שנתיים הקרובות יותר תוכנות של אדובי יתמכו בכך ועם 2 כרטיסים גרפיים הביצועיים יהיו כמעט כפולים).

מעבד

המעבד הוא ה"לב" של המערכת והוא מבצע עבודות רבות. הוא זה שמריץ את ה-WIndows, הוא זה שמנהל את כל העבודה במחשב והוא זה שמפנה נתונים לציודים השונים ולכן חשוב מאוד לבחור במעבד טוב. מעבדים כמו i3, i5 אינם שווים הסתכלות כשזה מדובר בתחנה לעריכת מדיה.

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

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

המתמודדים העיקריים כיום:

  • אינטל i7-7700K – מכיל 4 ליבות ו-8 נימים.
  • AMD Ryzen 7 1700 – מכיל 8 ליבות ו-16 נימים (ועולה פחות מה-i7-7700K של אינטל)
  • אינטל  i7-7800X – מכיל 6 ליבות ו-12 נימים – ה"תשובה" של אינטל ל-Ryzen 7 1700 של AMD, רק שהמחיר יותר גבוה מההצעה של AMD והביצועים (בעריכת מדיה) – יותר נמוכים. עלות הלוח אם של ה-i7-7800X מוסיפה לא מעט למחיר.

זכרון

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

כרטיס גרפי (GPU)

הכרטיס הגרפי הוא שבסופו של דבר מתרגם את רוב העבודה שלכם למשהו ויזואלי, לפורמט וידאו שאתם רוצים, ובשביל זה צריכים כרטיס GPU טוב ולא מה שמוכרים לכם במחשב רגיל לשימוש עם אופיס וגלישה באינטרנט. 2 היצרנים המובילים הם AMD ו-nVidia.

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

  • כרטיסים מבוססי nVidia GTX 1050 ו-1060 לא מומלצים (יש בהם 2 או 3 ג'יגהבייט זכרון. יש כרטיס GTX 1060 עם 6 ג'יגהבייט זכרון אולם מבחינת משאבי עיבוד גרפי – המשאבים נמוכים). לפיכך ההמלצה שלי על ה"אמצע" – GTX 1070.
  • כרטיסי Radeon – דגמי RX480, RX580 מומלצים. RX560 מומלץ למי שאין לו עבודות גדולות.
  • כרטיסים מבוססי nVidia GTX 1080 או nVidia 1080TI – כרטיסים יקרים ולא ממש שווים את ההשקעה (אלא אם אתה אוהב להשתולל מבחינה פיננסית) מכיוון שהביצועים בין 1070 ל-1080 לא כזה גדול.

דיסק קשיח

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

  • דיסק SSD (זה הדיסק ה"קשיח" האלקטרוני הקטן, לא המכני הגדול) ובו תותקן מערכת ההפעלה והאפליקציות. הגודל המומלץ ל-SSD: כ-512 ג'יגהבייט זכרון (למי שחושב ש-256 ג'יגה יספיק – קחו בחשבון ש-Windows מוריד עדכונים גדולים וכנ"ל תוכנות של אדובי וכו'. בנוסף, בגלל מהירות ה-SSD מומלץ להגדיר את ה-Scratch Disk ויצירת קבצים אחרים בתוכנות כמו פוטושופ/פרמייר/אפטר-אפקטס – לאכן אותם על ה-SSD, כך תרוויחו מהירות ובגלל זה ההמלצה היא של 512GB.
  • דיסק קשיח מכני – יש את חברת Western Digital (או WD בקיצור) והדיסקים מסידרת BLUE או Black יתאימו לכם בהתאם לגודל של הדיסק שתרצו. מה שלא מומלץ זה סידרת RED, GREEN שהם דיסקים איטיים יותר ומתאימים להקלטות וידאו ממצלמות במעגל סגור. ישנם גם דיסקים של Seagate. הדבר הכי חשוב הוא מהירות סיבוב הדיסק (RPM – ככל שהמהירות יותר גבוהה, הוא יכול לכתוב ולקרוא נתונים יותר מהר) – כך שמומלץ שהדיסק יסתובב ב-7200 RPM וכדאי לבדוק שיש לדיסק אחריות ל-3 שנים. הדיסקים הללו די זולים (רכשתי לפני חודש דיסק של Seagate עם 4 טרהבייט זכרון – ב-625 שקל) ולכן מומלץ לרכוש אפילו 2.
  • דיסקים SSD מומלצים (שוב, ממליץ על 512 ג'יגהבייט):
    • Samsung EVO 850
    • Crucial MX300 או MX500
    • Toshiba OCZ VX500 (הוא קצת יקר אבל נותן ביצועים רציניים)

אם הזכרתי דיסקים – אם אין לכם מחשב נוסף (או שאתם רוצים לאכסן את התוכן בנפרד) מומלץ לקנות דיסק קשיח בגודל לדוגמא של 6 טרהבייט לאחסן פרוייקטים שגמרתם (לא בשביל לעבוד עליהם מחדש!). דיסק של WD מהסידרה הסגולה (Purple) בגודל 6 טרהבייט יעלה לכם 999 שקל ב-KSP ו-Ivory ועליו אפשר לשמור מה שסיימתם. הדיסק אינו מהיר ולכן לא מומלץ לערוך עליו תכנים אלא רק לשמור דברים גמורים או דברים לפני עריכה שלכם.

מחשבים ניידים

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

  • משקל – הם כבדים.
  • כח סוללה מאוד חלש. תתכוננו לשעה-שעתיים עבודה גג עם סוללה.

היתרונות (חוץ משיש לך את התחנה שלך ניידת):

  • אפשר להרחיב זכרון – עד 32 ג'יגהבייט
  • אפשר להרכיב דיסק קשיח או SSD נוסף (בחלק מהמקרים גם 2)
  • אפשר לחבר 2 מסכים חיצוניים בחלק גדול מהדגמים.
  • הוא הרבה יותר חזק מכל מק-בוק או מק-בוק פרו 🙂

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

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

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

קונטיינרים, OpenStack ושינוי מערכות

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

אז החלטתי לכתוב פוסט שינסה לתת כמה טיפים לגבי נושאים אלו.

נתחיל ב-OpenStack: למרות שזו פלטפורמה מעולה לוירטואליזציה ומערכת ליצירת שרותי PAAS/SAAS/IAAS, כדאי לקחת בחשבון את העלויות שלה. כן, ישנה גירסה חופשית אך גירסה זו משתנה מדי כמה חודשים ואין שום בטחון שגירסה שתצא עוד חצי שנה תהא תואמת לגירסה הנוכחית ולכן מומלץ לחברות שרוצות OpenStack לרכוש את הגירסה שהפצות הלינוקס ומספר חברות אחרות מציעות (לא את הגירסה שכל מיני חברות מציעות של HP כ-Helion כי זו גירסה די מתה). המחיר אינו זול (מ-20K$ ומעלה) אולם אתם כחברה יכולים להיות שקטים שהמערכת שלכם תיתמך לשנים הקרובות (בין 3 ל-5, תלוי איזו גירסה קניתם ומתי) ותקבל עדכוני אבטחה ותיקוני באגים קריטיים.

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

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

יחד עם זאת, מעבר לקונטיינרים מחייב הבנה כי קונטיינרים אינם מכונות וירטואליות והדברים עובדים בצורה שונה לחלוטין בכל הרמות, החל מהקמה, הרצה, עדכוני קונטיינרים, כתיבה/קריאה ל-Shared storage חיצוני ועוד ועוד.

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

כך לדוגמא, אם יש לכם אפליקציית JAVA שרצה על JBoss, תצטרכו קודם לחפש לכם פתרון אחר במקום JBoss (כמו Wildfly, tomcat וכו'), להעביר את הקוד של האפליקציה ל-GIT ואז להשתמש בכלים כמו S2I או מערכות כמו Jenkins כדי להקים את ה-Images שכוללים את האפליקציית Server להרצת ה-JAVA וכשהיא תרוץ, היא תפעיל את האפליקציה שלכם שכתבתם ב-JAVA (או להשתמש ב-OpenShift שיעשה לכם את רוב העבודה 🙂 )

למרות ש-OpenStack יכול להריץ קונטיינרים, מומלץ יהיה להשתמש במערכת Scheduling כמו OpenShift, Kubernetes, Docker Swarm, Rancher ואחרות כדי להריץ את הקונטיינרים, כלומר אם משתמשים ב-OpenStack, עדיף להרים מכונות VM שישמשו כ-Nodes כדי להריץ את הדברים הללו.

כשזה מגיע ל-Storage, אינני ממליץ לזרוק את ה-Storage מהחלון, אולם כדאי לחשוב על חלוקה מעט שונה של ה-Storage לצרכים השונים. OpenStack יכול להסתדר עם iSCSI ו-NFS, אולם קונטיינרים צריכים NFS בלבד. אם אתם משתמשים ב-Object Storage על מנת לאחסן קבצים סטטיים או תמונות לדוגמא, יכול להיות שיהיה עדיף להקים "מיני סטורג'" שמורכב משרת עם דיסקים + JBOD (במקרה הצורך) הואיל ו-Object Storage אינו מצריך מהירות גבוהה.

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

גילוי נאות
שרותים אלו ניתנים ע"י חץ ביז

קוד פתוח מול קוד סגור ו"נעילת" לקוחות

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

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

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

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

הנה דוגמא: לא מעט חברות שנכנסות יותר ויותר בשימוש עננים ציבוריים "מגלים" כשהם משתמשים בלינוקס ומערכות CI/CD את האוטומציה, ותתפלאו – חברות רבות לדוגמא עד היום לא הכניסו שום אוטומציה. יש פלטפורמות אוטומציה רבות ללינוקס כמו Chef, Puppet, SALT ובוודאי עוד כמה – אולם אני ממליץ ספציפית על Ansible מכמה סיבות:

  • הקוד של "המנוע" – פתוח לחלוטין וכתוב ב-Python.
  • אין צורך ב-"שרת" Ansible. כל הפעילות היא Serverless לחלוטין.
  • הכתיבה של ה"תסריטים" (או Playbooks איך שזה נקרא ב-Ansible) היא פשוטה ולוגית. המשתמש יכול תוך שעה שעתיים אחרי שהוא קרא את התיעוד לכתוב דברים בסיסיים שיכולים לרוץ על המכונה שלו ומכונות אחרות, כך שעקומת הלימוד – היא די קטנה.
  • יש לכם שרתי Windows? אולי הגיע הזמן גם ששם תהיה אוטומציה? אז ל-Ansible יש גם מודולים ל-Windows, בין אם מדובר להתקין קבצי MSI, להגדיר IIS, להעתיק קבצים, פעולות דוט NET, ניהול משתמשים וקבוצות ודברים נוספים. העלות לחברה? יקרה מאוד .. אפס שקלים.
  • מחפשים ממשק Web? אתם יכולים לרכוש את Ansible Tower (וביחד עם זאת לקבל תמיכה רשמית מ-רד-האט) או שאתם יכולים להשתמש בממשק וובי אחר (ויותר בסיסי) בקוד פתוח שנקרא Ansible Semaphore.
  • חושבים לעבור לאוטומציה אחרת מסיבה כלשהי? לרוב המתחרים יש כלים אוטומטיים להעביר את ה-Playbooks שכתבתם אל המערכת החדשה (אם כי עדיין לא נתקלתי בחברה שעברה מ-Ansible למערכת אחרת).

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

אותו הדבר גם בכלים לניהול סביבת חיים (Life Cycle) של קונטיינרים וסביבות המורכבות מעננים פרטיים וציבוריים. ניקח לדוגמא את קטגוריית ה-CMP (כלומר Cloud Management Platform). בתחום זה יש מתחרים רבים, החל מ-VMWare עם ה-vRealize לגרסאותיו, RightScale, ועוד. האם פלטפורמות אלו מבצעות את מה שהן מבטיחות? בהחלט! אולם אם תפסיק לשלם את התשלום החודשי או השנתי, תיתקלו באחת מהסיטואציות הבאות:

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

לעומת זאת, במוצר כמו CloudForms שנותן לך לבצע CMP (כולל כמובן עמידה ברגולציות וכו'), אם לא בא לך לשלם יותר, אתה יכול לייצא ולייבא את ההגדרות, הקבצים והתכנים לגירסת הקוד הפתוח (ManageIQ) בדיוק כמו שאתה יכול לעבור מ-RHEL ל-CentOS מבלי לאבד פונקציונאליות או תאימות. כשזה מגיע לקונטיינרים, אתה יכול לעבור מגירסת OpenShift מסחרית ל-OpenShift Origin שמבוססת על Kubernetes כך שבעצם למעט שרותי תמיכה (שאותם תוכל לקבל מצד ג' בין כה), אינך מפסיד דבר. להיפך: אתה שומר על כל העבודה שהצוות ביצע ואפשר לאחר המרה לגירסת קוד פתוח – להמשיך לעבוד כרגיל.

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

שבוע טוב 🙂