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

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

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

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

בדרך כלל ההסכם שלי מול חברות כאלו הוא פשוט:

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

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

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

עמדה: מחשבי מק ושימושיות בחברות

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

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

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

כשזה מגיע למחשבי דסקטופ, יש לאפל מחשב 2 מחשבים (ה-iMac ו-iMac Pro) שניתנים לשדרוג הן מבחינת זכרון, מעבד, ואחסון. במחשבים אלו האחסון שליף כך שבמקרה ומחשב צריך החלפה של לוח אם לדוגמא, אין שום בעיה להוציא את זוג ה-SSD הקנייני שבמחשב ולהחליף לוח אם, ומחשבים אלו לעניות דעתי מומלצים יותר לרכישה מאשר אחיהם הלאפטופים הואיל וניתן בכל זמן לשדרג אותם. לאפל יש גם את ה-Mac Mini אך למעט הזכרון לא ניתן לשדרג מאומה, כך שכמו אחיו הלאפטופים, אם ישנה בעיה באחסון, יש צורך בהחלפה של כל לוח האם כולל הבעיה של המידע שקיים במחשב. אפל בחורף תוציא את ה-Mac Pro שיהיה אחד המחשבים היחידים של אפל שבו ניתן יהיה לשדרג סוף סוף הכל, כולל הכנסת כרטיסי PCIe של חברות שונות.

אחת התהיות שעולות עקב "לחץ מלמטה" היא התהיה האם כדאי להחליף את שלל המחשבים הניידים בחברה למחשבי Macbook Air או Macbook Pro. מבחינת ניהול מרכזי, קיימים מספר כלים לנהל מחשבים אלו יחד עם מחשבי PC אחרים בצורה מרוכזת, ומבחינת מערכת הפעלה Mac OS היא מערכת הפעלה מעולה ויציבה (לא רק עבור גרפיקאים ואנשי מדיה אלא גם למפתחים), אולם חשוב לזכור כי הבעיה המרכזית היא שכל מחשב נייד ל-Enterprise שתעמיד למבחן מול כל מחשב נייד של אפל – המחשב הנייד שאינו מחברת אפל יוכל להיות משודרג הן מבחינת זכרון והן מבחינת אחסון, וזהו יתרון ענק כאשר מסתכלים לטווח של שנה שנתיים לאחר רכישה שבהן עולות דרישות של יותר זכרון ויותר שטח אחסון. אחרי הכל, אף אחד לא רוצה לגרור את עצמו עם מחשב נייד ועם SSD חיצוני לכל מקום כי נגמר המקום בדיסק SSD הפנימי..

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

על OpenShfit, הטמעה וציפיות בחברות

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

חלק לא קטן מהטענות ששמעתי הגיעו מצד גופים שחשבו ש-OpenShift זה כלי עם GUI מרשים ל-Kubernetes. הנחה זו היא די מוטעית. אם מחפשים GUI וכלי ניהול בשביל Kubernetes, אפשר להסתכל על מוצר בקוד פתוח שלא עולה כלום כמו Rancher. לעומת זאת, Openshift זה כלי שבא לתת לך הכל ללא צורך בהזדקקות לשרותים חיצוניים מהאינטרנט כמו Containers Registry וכו'.

על מנת להבין יותר את התפיסה של OpenShift, נדמיין סיטואציה אחרת לחלוטין: יש לנו 10 מפתחי JAVA ויש לנו שרת לינוקס גדול ורציני. למפתחים יש משתמש משלהם (נניח דרך אוטנתיקציית AD) על שרת הלינוקס ועל השרת מותקן באופן מרכזי ה-JDK וכלים אחרים שהמפתחים משתמשים, וכל מפתח יכול לבצע login ולבצע checkout מה-GIT המרכזי ולהריץ את האפליקציות JAVA שלו. אין צורך שיהיה לו ידע בניהול מערכת לינוקס, אבל מומלץ שיהיה לו ידע ממש בסיסי ב-BASH, ודברים פשוטים אחרים שאפשר ללמוד בשעה שעתיים – בשביל להריץ את מה שהוא כתב. מי שינהל את שרת הלינוקס מבחינת הגדרות, עדכונים וכו' – תהיה מחלקת ה-IT בחברה. לחובבי Windows אפשר לדמיין את הסיטואציה כשרת Windows שנותן שרותי RDP וכל משתמש נכנס עם המשתמש המאושר שלו והוא עושה מה שהוא צריך לעשות. הידע שהוא צריך – הוא שימוש בסיסי ב-Windows, לא יותר מזה.

השוני הכי גדול בין Kubernetes ל-OpenShift מבחינת כל מה שקשור לקונטיינרים – היא הגישה. ב-Kubernetes אם אני רוצה לבצע Deploy, לבצע Scale, רפליקציה, כתיבת שרותים ודברים רבים אחרים – אני צריך לכתוב קבצי YAML (או JSON) שאותם אני צריך להזין ל-Kubernetes ואני צריך גם לבדוק לוגים כדי לראות שכל רץ תקין, ולכן בחברות שמשתמשות ב-Kubernetes רוב העבודה הזו נופלת על איש ה-Devops. לעומת זאת, עם OpenShfit, הדברים בנויים יותר בכיוון שרת הלינוקס וה-JAVA. עם OpenShift אני מגדיר משתמשים (ומחבר את OpenShift ל-AD על מנת לשמור על סינכרון שם משתמש/סיסמא/הרשאות) ואותו מפתח יכול להריץ דברים ישירות דרך ה-CLI או ה-GUI ויש לו כלים מוכנים כדי שהוא לא יצטרך לשכתב קבצי YAML כדי לבנות קונטיינרים עם הקוד שלו בתוך ה-OpenShift. אם הוא רוצה לבצע לדוגמא Scale או Deploy, הוא פשוט יכול ללחוץ כמה קליקים ולהשתמש ב-Template מוכן, לתת שורת כתובת של ה-GIT שלו, ותוך דקות ספורות ה-POD עם הקונטייר/ים שלו ירוצו, הוא יכול לראות מתוך ה-GUI את הלוגים ואף לקבל גישת טרמינל מוגבלת לתוך הקונטיינר כדי לבדוק אם הכל תקין וכו' וכו' ואם הוא רוצה לשמר את מה שהוא עשה בתור קובץ YAML/JSON, המערכת תשמח ליצור עבורו את הקובץ הנ"ל.

לכן, מבחינת חברה, OpenShift עושה את החיים יותר קלים מבחינת הטמעה ושימוש בקונטיינרים, ניהול תשתית המכונות המריצות את OpenShift ואת הקונטיינרים עצמם, כלומר הצורך במישהו יעודי רק כדי להריץ דברים בקונטיינרים פוחת ואפשר להוציא זאת לשרות חיצוני או ללמד את צוות היוניקס/לינוקס את הדברים הדרושים, ובנוסף קל לראות אם ישנן בעיות בתשתית ה-OpenShift (מערכת Heapster נותנת גרפים עשירים פר Node, פר POD וכו' וכו', וגם ניתן לחבר את OpenShift ל-ELK, גרפאנה ושאר החברים). בנוסף, מכיוון ש-OpenShift מבוססת על Kubernetes, ניתן ליישם את מה שרץ על OpenShift על מערכת Kubernetes במקרים לדוגמא בהם הוחלט ש-OpenShift ירוץ בפיתוח ו-Kubernetes או פתרון תואם רץ בפרודקשן (אם כי זה קצת יותר מורכב).

ונקודה אחרונה לגבי מחיר: אני מכיר כמה מנהלי IT ששמעו את המחירים של רד-האט ולסתותיהם נשמטו. נכון, מחירים פר Node אינם בדיוק זולים, אולם המחיר יורד לחמישית אם מריצים את ה-Node כמכונת VM ומעוניינים להריץ את הגירסה המסחרית. חוץ מזה שאישית – אני ממש לא ממליץ להריץ את OpenShift על "הברזל" אלא אם יש שם למחלקת ה-IT ידע ממש עמוק ורציני בלינוקס, אחרת אפשר להפיל Node (ולא חשוב אם זה Node לעבודה או Master) די בקלות. בכל זאת, לא מדובר על הפעלת Cluster קונבנציונאלי עם HeartBeat, PaceMaker וכו'.

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