קונים/מטמיעים שרתים? כדאי שתקראו

ברוב החברות, עד שהם רוכשים שרתים אפשר לפתוח בקבוק שמפניה. רוב החברות רוכשות שרתים אחת לכמה שנים ועם כניסת טכנולוגיות הוירטואליזציה השונות, כמות השרתים הנרכשת – קטנה. אחרי הכל, הרבה יותר קל וזול לדחוף עוד כמה עשרות ג'יגהבייט זכרון לשרת ואולי להוסיף/לשדרג מעבדים מאשר לרכוש ברזל חדש (האמת שיש לי בנושא ויכוח עם כמה אנשי IT. אחרי הכל, שרתים בסיסיים שכוללים 2 מעבדים 4 או 8 ליבות ו-16 ג'יגה זכרון + 2 דיסקים SATA – לעיתים יותר זולים משדרוג שרת קיים, תלוי בגודל השדרוג) – בתחום הזה כל חברה מחליטה לעצמה איך ולאן מתקדמים.

תחום השרתים עצמו די מתפתח. היו לנו שרתי Blade (זוכרים?) וכיום יש מחברות כמו SuperMicro שרתים שהם Twin שהם 2 או 4 שרתים במארז 2U או 4U (בהתאמה) וחברות אחרות גם העתיקו את הטכנולוגיה. היום גם ניתן להכניס דיסקים SSD PCI שעברו דיאטה רצחנית והם בעובי 7 מ"מ וניתן להכניס בין 10-15 דיסקים כאלו במארז 1U (תלוי ביצרן). מבחינה פנימית – כל יצרן בנה לעצמו פתרונות (שחלקם הגדול די קנייני) על מנת לבדל את מוצריו מהמתחרים. חלק מהפתרונות לדעתי תמוהים, חלק מעניינים – אבל ברוב המקרים הטכנולוגיה סגורה. קחו לדוגמא את HP – תכניסו דיסקים שאינם של HP (שבעצמם כלל לא מייצרים דיסקים) ותקבלו הודעה מעצבנת שהדיסקים אמנם יעבדו אבל אם תהיה תקלה – לא תקבלו LED אדום על אותו דיסק. בשבילי כאחד שעוקב כמעט מדי יום לגבי טכנולוגיות חדשות כמעט בכל סוג חומרה – זה מעצבן, כי תמיד יש פתרונות חדשים במחירים מעניינים. בשביל חברות – זה כלל אינו ISSUE, הם פשוט יקנו את הדיסקים מיצרן השרת וישלמו עוד כמה אלפי דולרים. בגלל זה אני מעדיף שרתים "לבנים" מיצרנים כמו TYAN, SuperMicro, ASRockRack, Gigabyte ו-ASUS (האחרונים יותר מייצרים לוחות אם מאשר שרתים מוכנים ללקוח).

ישנה נקודה חשובה שלצערי אינה ידועה רבות כשרוכשים שרתים חדשים: לא מומלץ להכניס אותם ל-DMZ שלכם. מדוע? אסביר.

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

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

כדי לראות את הבעיה בזמן אמת, אתם מוזמנים לבצע את התרגיל הבא מול חוות השרתים שלכם: בחרו לכם מספר שרתים מיצרנים שונים, בדקו גירסאות BIOS/UEFI והשוו את מספר הגירסה למספר הגירסה שמופיעה באתר היצרן. מהיכרות שלי: בסביבות ה-50-70% מהמקרים, השרת אינו מעודכן לקושחות ול-UEFI/BIOS האחרונים (הסיבה שאני שומע הכי הרבה: "זה רץ, אז למה לנסות להתקין דברים חדשים?". התשובה שלי: אבטחה).

ישנם לעיתים חורי אבטחה ממש גדולים. קחו לדוגמא את ה-Management Engine של אינטל שנמצא בכל שרת ובכל תחנת עבודה (שכוללים את הדרייברים של אינטל). משנת 2010 ישנו חור אבטחה רציני שתוקף יכול להגיע אל ה-Management Engine (שנמצא כחומרה בתוך המכונה), להשתלט עליו ולעקוב אחרי מה שקורה במכונה במקרה הקל או להזיק לדברים שרצים במכונה במקרה היותר גרוע. שום פירמוט או החלפת דיסקים לא יעזרו. תצטרכו להשתלט על ה-Management Engine מחדש על מנת לפתור את הבעיה. לאינטל לקח 7 שנים עד שבחודש מאי הם שחררו עדכון. החור קיים ב- Intel's Active Management Technology (AMT), Standard Manageability (ISM) ,Small Business Technology (SBT) מגירסאות 6 עד 11.6. האם עדכנתם אצלכם את השרתים לחסום את הפירצה הזו? (אפשר לקרוא עוד על כך כאן)

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

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

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

החלוקה

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

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

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

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

משפחת ה-Xeon W החדשה של אינטל. שווה לרכוש?

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

בשבוע שעבר אינטל הכריזה על משפחת מעבדים חדשה, ה-Xeon W שמיועדת (כפי שהאות W רומזת) לתחנות עבודה. מבחינת דירוג, מעבדים אלו לתחנות עבודה יושבים באמצע, כאשר ברמה הראשונית יש את ה-Xeon E3 (כלומר תקבל משהו שהוא טיפ טיפה יותר מ-i7 לדסקטופ, אבל עם מגבלות של 32 ג'יגהבייט זכרון), לאחר מכן מגיעים דגמי Xeon W ואם אתה צריך יותר מכך, אתה מוזמן לעבוד למשפחת ה-Xeon החדשים תחת שם הקוד Purley. אם נשווה זאת לדגמים קודמים, הרמה ההתחלתית היתה גם אז Xeon E3, אם אתה צריך יותר אז היית רוכש Xeon E5 V4 מסידרה 16XX ואם אתה צריך מערכת עם זוג מעבדים, היית רוכש מערכת עם מעבד (או 2 מעבדים) מסידרה 26XX. בתכל'ס – אף אחד מיצרני תחנות המותג לא היה מוכר מערכות עם 16XX אלא מערכות עם מעבדים 26XX כאשר היית יכול לרכוש מעבד יחיד ולהרחיב יותר מאוחר ל-2 מעבדים מאותה משפחה. אם לעומת זאת היית בונה מערכת, היית יכול לקנות לוח אם לתחנת עבודה ולהרכיב בו מעבד Xeon E5 V4 16XX ואם היית רוצה ביצועים נוספים, היית יכול להחליף אותו למעבד E5 26XX. טריק נוסף נחמד שהיה הוא האפשרות להחליף מעבד Xeon E5 דור 3 (כלומר V3) לדור 4 מבלי להחליף חומרה נוספת, רק עם עדכון BIOS והחלפת מעבד+קירור.

מאז שאינטל הוציאה את דור 4 ואת מעבדי ה-Kaby Lake לדסקטופ, חלו כמה שינויים גדולים בתחומי המעבדים. AMD יצאה עם משפחת ה-Ryzen והראתה שאפשר למכור לציבור מעבדים מכובדים עם יותר ליבות בפחות מהמחיר שאינטל מבקשת על Kaby Lake ולשם שינוי – גם לתת ביצועים מכובדים. בחודש שעבר AMD גם שחררה את משפחת ה-Threadripper שלה שנותנת ללקוחות ה-Prosumer מעבדים עם עד 16 ליבות ו-32 נימים, עם תמיכה של עד 1 טרהבייט זכרון ECC, עם 64 נתיבי PCIE ובלי שום נעילת מעבדים (מבחינת Overclocking) במחירים נמוכים בהרבה ממה שאינטל מציעה.

אינטל בתגובה הוציאה את מעבדי ה-Skylake-X עם Chipset חדש (ה-X299 – כך שאתה חייב להחליף לוח אם) ובמשפחת מעבדי ה-Skylake-X ישנם מעבדים שבקצה הנמוך הם עם 4 ליבות (ללא תצוגה ושמיד מבטלים לך חצי מפונקציונאליות לוח האם) ועם מעבדים די ראויים בסידרת ה-78XX כאשר בקצה העליון יש מעבד כמו 7890XE עם 18 ליבות, 36 נימים, 44 נתיבי PCI ואפילו RAID לדיסקים מבוססי NVME! כמובן שאינטל גובה על המחיר למעבדים אלו מחיר מפולפל. על ה-7890XE היא גובה 2000$ (זה כמובן לא כולל לוח אם די יקר). הפתרון המתחרה של AMD עולה 1000$ (עם פחות 2 ליבות אבל עם יותר פונקציונאליות) – אבל אינטל לא ממש מתעניינת בתחרות ואלו המחירים.

וכרגיל, כשזה מגיע לאינטל, עצם העובדה שהיא מוכנה למכור מעבדים עם יותר ליבות במחיר יותר גבוה – לא אומר שהיא תפתח פונקציונאליות שהיא מייעדת ל-Enterprise – למשתמשי ה-Prosumer! חס ושלום! רוצה זכרון? יופי, נגביל אותך ל-128 ג'יגהבייט. זכרון ECC? לא ולא! אז מה אם אתה תשלם מחיר יקר בהשוואה לפתרונות של AMD?

מה שמביא אותנו למעבדי ה-Xeon W החדשים. המעבדים האלו .. הם בעצם ה-Skylake-X רק שאינטל הפעילה כמה ביטים בתוך המעבד והגבילה את התאימות שלהם. זה שקנית לוח אם עם X299 Chipset לא אומר שתוכל לרכוש Xeon W ולהכניס אותם (למרות שהם בדיוק עם אותם כמות פינים – 2066). בשביל זה אינטל הוציאה Chipset חדש, ה-C422 וכמובן אותו Chipset מקבל רק Xeon W ואתה לא יכול לתחמן בהכנסת מעבד Skylake-X. גם מחירי ה-Xeon W קיבלו "שדרוג" ואתה תשלם בין 400-1000$ יותר על אפס תוספת בביצועים, אבל תוכל להכניס זכרון ECC (בלבד!) עד 512 ג'יגהבייט, ותקבל את שאר הבבל"ט של ה-RAS ושאר ירקות שאינטל דוחפת ללקוחות Enterprise.

עד לשנה האחרונה, לחברות שרצו תחנות עבודה או ביצועים של תחנות עבודה, לא היו הרבה ברירות. או Xeon עם המחירים הגבוהים או מעבדים כמו 6950X שהיה יותר מיועד ל-Enthusiasts עם תג מחיר מאוד גבוה. כיום לעומת זאת – המצב שונה לחלוטין. תחנות קצה רגילות (דסקטופ) לחברות – אפשר לרכוש עבורן Ryzen Pro (שכולל את הפונקציות ל-Enterprise) או Ryzen רגיל ולתחנות דסקטופ רגילות עבור הפקידות ניתן לרכוש מעבדים כמו Ryzen 3 (מגיע עם 4 ליבות ויותר זול מ-i3 שמגיע רק עם 2). לקצה הגבוה של תחנות עבודה אפשר לרכוש תחנות עם Skylake-X או AMD Threadripper (בהתחלת השנה כל יצרני המותג יאפשרו רכישה כזו), ואם מתעקשים על פונקציונאליות של Enterprise אז ניתן לרכוש את ה-Xeon W או לחלופין תחנה עם מעבד כמו EPYC 7401P שעולה $1050 אבל מגיע עם 24 ליבות, 48 נימים, 124 נתיבי PCIE ותמיכת זכרון ECC עד 2 טרהבייט ובעודף שנשאר במקום רכישת Xeon W אפשר לרכוש מספר SSD או כרטיס/ים GPU טוב/ים.

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

נקודות שיצרני Storage לא רוצים שתדעו

כפרילאנסר שמוכר שרות הטמעה/התקנה של SDS (כלומר Software Defined Storage) אני משתדל בדרך כלל להיות מעודכן גם ב"רכילות" של מה קורה אצל אלו שמוכרים פתרונות כ"קופסאות סגורות", מה-NetApp ו-Dell/EMC ועד ליצרני פתרונות AFA (כלומר All Flash Array) למיניהם. תמיד נחמד לדעת על כל מיני פתרונות שיצרני ה-AFA מכניסים או הולכים להכניס בשעה שהגדולים .. המהנדסים שלהם מדברים על פתרונות כאלו בארוחת צהרים, ההנהלה לא הכניסה את זה ל-Road Map עדיין.

כשזה מגיע ל-SDS, החיים קלים ופשוטים: הלקוח רוכש שרת, עם כל הציוד הנדרש, דיסקים וכו', הוא נניח שוכר את שרותיי, אני מציע לו מספר פתרונות, בין בקוד פתוח או סגור (כולם מבוססי לינוקס למעט Windows – ב-Windows יש לו כיום את Storage Spaces [שהוא אגב, אינטרגלי ב-Windows Server 2016] והוא ממש לא צריך אותי לשם כך), הלקוח בוחר, מרימים גירסה, אני מגדיר את כל מה שהלקוח מבקש, מריצים סידרת טסטים ואם הוא מרוצה – מכניסים לפרודקשן. במקרה ויש לו בעיות עם המערכת הוא פונה אליי ואני מטפל בבעיה אם מדובר בתוכנה או מבקש ממנו לפנות למי שהוא קנה ממנו את הברזל כדי להחליף דיסק/זכרון/לוח/כרטיס-רשת וכו'. פשוט וקל.

אבל כשזה מגיע לסטורג' סגור, אני ממליץ לעבוד בשיטה שאני קורא לה "הבן של מי אתה?"

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

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

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

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

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

  • אם אתם חושבים לרכוש סטורג' – ראשית מומלץ לבדוק לגבי המוצר שאתם רוצים לרכוש – האם הוא מוצר שיוצר בעבר ע"י חברה אחרת שנרכשה ע"י אותה חברה גדולה שאתה רוצה לרכוש ממנה. אם כן – עדיף לחפש מוצר אחר.
  • אם כבר רכשתם מוצר מחברה קטנה שנרכשה ע"י החברה הגדולה, תפנו זמן לצוות הטכני ותתנו להם הוראה להתחיל להתעמק ב"בפנוכו" של הסטורג', לא ברמת GUI אלא ברמת CLI. לא צריך לנסות דברים שיזיקו, אבל כדאי שיכירו את הפקודות, קבצי הקונפיגורציה ומי עושה מה.
    • עוד משהו שאתם יכולים לעשות – זה להיעזר בחברים ולרכוש בנק שעות תמיכה מאינטגרטור שמכיר את הסטורג' הזה. אישית אינני נותן שרותים לסטורג' סגורים, אבל מהיכרות עם חברים שנתנו תמיכה לכל מיני חברות ועסקים שיש להם סטורג'ים כאלו – ההשקעה בבנק שעות כזה הצילה חברות לא פעם ולא פעמיים בהשוואה ל"טקס מעבר-בגהינום" של התמיכה בחברה הגדולה. קנו לכם כמה עשרות שעות שיהיה לכם שקט במקרה של תקלות (יהיה לכם עדיין את היתרון שבמקרה ויש תקלת חומרה – החברה הגדולה תשלח נציג שיבוא ויחליף את הציוד התקול).
  • העולם עובר ל-Software Defined Everything, מסטורג' לרשת ודברים נוספים, ולכן מומלץ לשקול בחיוב לקחת פתרון Software Defined Storage. אל תאמינו לי, תשאלו את VMWare, Microsoft, Red Hat, Amazon וחברות מפורסמות אחרות. עם SDS אין לך שום "מסע גהינום" של תמיכה, יועץ/אינטגרטור נותן לך תמיכה ואם אינך מרוצה אפשר להחליף אותו ביועץ/אינטגרטור או חברה שנותנת את אותם שרותים ואם יש תקלת חומרה – החברה שמכרה לך את הברזל תחליף לך את הציוד, כך שזמן ההשבתה מתקצר משמעותית, יש למי לפנות וניתן לקבל בזמן קצר פתרונות.

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

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

שבוע טוב 🙂

על קונטיינרים ו-Appliance

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

אם יש משהו שאני יכול לאמר על Appliances זה שהחיים איתם מבחינת הכנה – אינם קלים. תמיד אפשר כמובן לכתוב איזה updater לדוגמא שיתחבר לכל מיני מאגרי חבילות (REPO) ויוריד את חבילות מערכת ההפעלה ועדכוני התוכנה וחתימות (אם צריך, נניח), אבל מה אתה עושה אם לקוח לא מוכן לחבר את ה-Appliance עקב הוראות בטחוניות באותה חברה/מוסד/ארגון? אתה צריך ליצור מעין "Delta" של החבילות סיסטם + עדכונים ולשלוח לו את זה כדי שהוא יוריד לדיסק און קי, "ילבין" ויתקין את זה.

נחשוב על סיטואציה שמתרחשת אצל כל חברה שמייצרת Appliance (בין כ-VM ובין כקופסא פיזית) – החברה החליטה שבמסגרת הגירסה הבאה של התוכנה, היא מחליפה בדרך גם את הפצת הלינוקס שלה, ולא חשוב אם מדובר בשדרוג לגירסה אחרת מאותה הפצה או במעבר מ-Ubuntu ל-CentOS. המימוש לתהליך הזה די מורכב הואיל ומדובר על דריסה של מערכת קיימת ואם זה נשבר באמצע, ללקוח יהיה Appliance במצב לא שמיש (נקרא גם Brick). מעבר לכך זה גם מאוד תלוי אם המערכת הוקמה עם Volume Management (תתפלאו כמה Appliances אין להם את זה) ושההגדרות והנתונים יושבים על Logical Volume אחד, ה-DB יושב על Logical Volume אחר וכו' וכו'. בלי זה – כתיבת השדרוג הולכת להיות מורכבת ומסובכת (מנסיון…)

וכאן בדיוק קונטיינרים יכולים מאוד לעזור בשילוב LVM (ר"צ של Logical Volume Manager). את ה-Appliance אפשר לבנות בתצורה הבאה לדוגמא (בניכוי כל הדברים הקשורים ל-Volume Groups וכו'):

  • מחיצת boot/ בגודל 1 ג'יגהבייט (זה הסטנדרט המומלץ בסנטוס 7, אגב) ללא LVM
  • LV לוגי שמכיל את ה-OS עצמו בלבד.
  • LV שמכיל את ספריות ה-DB וקבצי קונפיגורציה
  • LV שמכיל קונטיינרים
  • LV לגיבויים
  • LV שמיועד לקבצים זמניים, Cache וכו'
  • LV ספייר (ריק, לשימושים שונים במהלך חיי ה-Appliances כמו פריסת Plugins זמניים, קבצי התקנה זמניים ועוד ועוד)

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

מבחינת קונטיינרים, יהיו במערכת מינימום 2 קונטיינרים (או 3, תלוי בחברה, מה המוצר, מורכבות ועוד):

  • בקונטיינר הראשון תרוץ אפליקציית Web שמטרתה העיקרית היא ניהול ה-appliance עצמו ברמת סיסטם: עדכוני תוכנה, יצירת גיבוי ושחזור, הרצת בדיקות תקשורת, התחברות ל-AD (אם צריך) ו/או למערכות אחרות. לאותו קונטיינר אנחנו נמפה הן את ה-DB והן את תיקיית קבצי הקונפיגורציה כך ששינויים ישמרו, גם אם לקונטיינר יקרה נזק/יפול/ימחק. לקונטיינר הזה המשתמש יגש דרך כתובת ה-IP של ה-appliance אך דרך פורט אחר שאינו 80/443 ומומלץ שיהיו לו יוזרים שונים מהיוזרים שמשתמשים ב-appliance עצמו.
  • בקונטיינר השני תרוץ האפליקציה העיקרית שלנו וגם בקונטיינר זה אנו נמפה את התיקיות קונפיגורציה ואת תיקיית ה-DB. לכאן המשתמש יגיע דרך HTTP או דרך HTTPS לפי העדפותיכם כמובן (אגב, טיפ קטן לחברות שבונות appliances – תנו דרך קלה להכניס תעודות SSL).
  • אופציונאלי: קונטיינר שלישי יריץ את ה-DB וגם אליו נמפה את תיקיית ה-DB. הסיבה שאני ממליץ להפריד את ה-DB לקונטיינר אחר היא שבמקרים רבים ללקוח יש הרבה פעילות וה-Appliance מגיב באיטיות כשהוא בעומס, ולכן כדאי לחשוב על מתן אפשרות הקמת Appliance רק עם ה-DB.

היתרונות בעבודה בדרך זו:

  • יצרן ה-Appliance יכול להשתמש בכל גירסה באיזו הפצת לינוקס שירצה, מבחינת המערכת – זה בסך הכל Image שקונטיינר מריץ. האפליקציה בקונטיינר מתממשקת לתיקיה של ההגדרות וה-DB ויכולה לזהות אם ההגדרות ישנות (או הנתונים ב-DB ישנים) ולשדרגם בהתאם.
  • כשיש עדכון חרום או עדכון רגיל שאיננו החלפת גירסת Major, העדכון שירד יהיה די קטן והוא ירד בצורה מאובטחת מ-repository של היצרן דרך התשתית של docker, המערכת תעדכן את קבצי ה-image, תבנה קונטיינר חדש ותחליף את הקיים בצורה שקופה.
  • כשיש שדרוג לגירסת Major חדשה, קונטיינר אחר נותן חוויית שימוש הרבה יותר אינפורמטיבית ללקוח, הוא יכול לראות מה קורה מבחינת אחוזי הורדה, מה המערכת עושה.
  • עדכוני מערכת ההפעלה הראשית (שאינה נמצאת בקונטיינר) הם בטוחים וגם אם יש תקלה, המקסימום שיהיה צורך זה לעדכן את ה-OS המינימלי. זה לא נוגע בקונטיינרי (ההגדרות יושבות ב-LV אחר).
  • אם הלקוח גודל מחר וצריך DB עם רפליקציות וכו' – השינויים שיש צורך לבצע הם מינוריים.
  • הזמן שלוקח מגילוי תקלה בתוכנה ועד שחרור ללקוחות (לאחר בדיקה) – מתקצר משמעותית. מהרגע שהחברה שחררה עדכון, הלקוח יכול להיכנס לקונטיינר הניהול, ללחוץ על Update מבלי להוריד קבצים.
  • זמן הירידה והעליה של ה-Appliance לאחר שדרוג מתקצר משמעותית.
  • אפשר לפתוח לטובת הלקוחות ערוצים נוספים כמו testing, beta, stable והלקוח יוכל לבחור לעבור, מדובר בסופו של דבר רק בהחלפת קונטיינר (חשוב לזכור: האפליקציה של הלקוח תצטרך להתמודד עם קבצי הקונפיגורציה וה-DB מבחינת שינוי ושדרוגם)
  • הלקוח יוכל לבצע (או שהמערכת תבצע עבורה) גיבוי של הקונפיגורציה וה-DB במהירות (מדובר ב-LV snapshot שהוא חלק בסיסי בלינוקס) ו-rollback במקרה הצורך.

במקרים כמו עבודה של Offline עקב דרישות של ארגונים בטחוניים או אגף אבטחת המידע של החברה, יהיה צורך בשינויים- אבל את זה אני משאיר מחוץ למאמר זה 🙂

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

קונטיינרים: ה"קרב" בין OpenShift ל-Docker DataCenter

בפוסט הקודם שכתבתי כאן על קונטיינרים וחברות מסחריות, ניסיתי להסביר מעט על קונטיינרים ועל המוצרים שנמכרים בארץ כאשר התרכזתי ב-2 מוצרים: ה-Docker DataCenter ומולו ה-OpenShift (גירסה מסחרית או גירסת Origin שהינה קוד פתוח) – עבור שוק ה-Enterprise. בפוסט זה אשווה קצת יותר (בצורה כללית) בין המוצרים ואנסה להסביר היכן כדאי להוציא הזמנת רכישה והיכן כדאי "לדלג".

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

בימים האחרונים השתמשתי בגירסת ה-Trial ל-Docker DataCenter (ובקיצור: DDC), למדתי אותה, הקמתי אותה אצלי ב-LAB הקטן שלי. השתמשתי ב-Swarm שבתוכו (שזה בעצם ה-Scheduler ועוד) ובשאר הכלים שגירסת ה-Enterprise כוללת. הייתי צריך להקים כ-5 מכונות וירטואליות (Nodes) כדי שהדברים יעבדו, עוד לפני שיכלתי להקים קונטיינר אחד. בסופו של דבר, המערכת עבדה בצורה טובה, יחסית. (אם כי נתקלתי באיזה באג או 2 שמצאתי להם "עיקוף").

מבחינת מחיר: DDC אינו זול. מחיר גירסת ה-Enterprise פר Node הוא 1500$ לשנה (כפי שניתן לראות כאן, גללו לאמצע הדף). על מנת להרים מערכת Enterprise, תצטרכו לרכוש לפחות 5 רשיונות: manager, registry, cache – אלו הם חלקים שרצים כ-VM נפרדים ב-DDC, עוד Node ל-Worker (שעליו בתכל'ס רצים הקונטיינרים) ותצטרכו מינימום עוד אחד אם אתם רוצים שרידות ועמידה בעומסים. (אפשר כמובן להריץ את החלקים השונים כקונטיינרים, אבל Docker ממליצים להרים את החלקי ניהול כמכונות VM נפרדות), כלומר אנחנו מתחילים במחיר של 7500$ לשנה. כל Node נוסף – עוד $1500.

הבעיות עם DDC פחות קשורות לבאגים או תכונות, אלא בעיה כללית שיש לחברת Docker בכל מה שקשור ל-Enterprise. הבעיה הראשית שלהם מאוד מזכירה את ההתנהגות של חברת רד-האט בצעירותה: רד-האט היתה משחררת גירסת לינוקס חדשה כל שנה ושוברת את התאימות הבינארית בין גירסה לגירסה. גירסה 5 לא תאמה לגירסה 4, גירסה 6 לא תאמה ל-5, גירסה 7 היתה עולם אחר לגמרי שלא תאם לגרסאות קודמות מבחינה בינארית. כלי ניהול הגיעו ונעלמו כלעומת שבאו, ויצרני תוכנה וחומרה התעצבנו מכל המהלכים הללו והן הביעו את דעתן בשיחות מול רד-האט ובעיתונות הטכנולוגית. לקח לרד-האט במשך שנתיים להבין שהדרך הזו אינה מקובלת לא על יצרני תוכנה וחומרה, ולא על Enterprise וכך נולדה משפחת ה-RHEL (כאשר כל הפיתוחים ושבירת התאימות עברו לגירסת Fedora), וכיום RHEL ניתנת עם תמיכה ועדכונים ל-10 שנים. ב-Docker לעומת זאת, שבירת התאימות היא עניין שבשגרה לגבי מוצרי הקוד פתוח, ומה לגבי הגירסה המסחרית שחברות משלמות? אה, לזה הם מוכנים לתת עדכונים ותיקונים למשך .. שנה אחת. מי בדיוק ה-Enterprise שמוכן לקנות מוצר שיהיה לו תמיכה ותיקונים לשנה אחת בלבד ובשנה אחר כך ב-DDC תישבר התאימות? שאלה מעולה!

ב-רד האט, למודי הנסיון, הדברים שונים לחלוטין.

ברד-האט יודעים שחברות לא ששות כל כך מהר לשלם עבור מוצרים שמיועדים לסביבות פיתוח, טסטים, QA, סביבות אוטומציה וכל דבר שאינו פרודקשן, ולכן רד האט אומרת: קחו את מוצר ה-OpenShift Container Platform (ובקיצור: OSCP) בחינם או את גירסת OpenShift Origin היציבה (נכון להרגע זו גירסה 1.4, כל עוד אתה מארח את הכל על התשתית שלך או תשתית הענן שלך), רק תזכור – זה לא מקבל תמיכה! כלומר את OSCP אפשר להרים על הלאפטופ (מספיק מכונת VM אחת או על הפצת הלינוקס במכונה ללא VM) או בשרתים הפנימיים לפיתוח וכו'. מעוניין בגירסה מסחרית עם תמיכה? הנה המחירון של Grey Matter. כפי שאתם יכולים לראות, על כל Node המחיר הוא 2724 ליש"ט ואם ה-Node הוא שרת פיזי, המחיר הוא 6810 ליש"ט (זה לפני מו"מ כמובן) עם תמיכה לשנה, ויש גם מחיר ל-3 שנים תמיכה, סטנדרט או פרימיום.

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

בסופו של יום, 2 המוצרים מציעים טכנולוגיות שונות. האחת (DDC) משתמשת ב-Swarm כדי לנהל את ה-Scheduling, Load Balancing, FT וכו' ואילו השניה משתמשת ב-Kubernetes. רוצה לדעת מי יותר פופולרי? תשאל את המפתחים ואנשי ה-Devops בחברתכם מי מכיר מה, אתה תקבל תשובה מהר מאוד מדוע Kubernetes כה פופולרית (כי היא קלה להתקנה וניהול בהשוואה ל-Swarm). ה-OpenShift של רד-האט תומך בגדילה של עד 1000 Nodes, ועד 120,000 pods. במילים אחרות, עם מערכת OpenShift אחת אתה יכול תיאורתית לארח את האתרים ואפליקציות בגדלים ענקיים!

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

על תשתית קונטיינרים לחברות מסחריות

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

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

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

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

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

עתה נחלק ל-2 את החברות בארץ: יש כאלו שקוד פתוח זה "בעורקים" שלהם – יש להם צוותים שמכירים לינוקס מאוד לעומק, נסיון עשיר ב-Python ו-Go והם יכולים לקמפל לינוקס קרנל בין פיהוק למשנהו ואם יש בעיה בתוכנת קוד פתוח – מישהו בצוות יכול לחטט ולתקן. לאותן חברות שמחפשות פתרון קונטיינרים מקיף אני פשוט ממליץ ללכת על OpenShift Origin על תשתית וירטואליזציה ולהתחיל להשתמש. כל מה שאתם צריכים בשביל להריץ קונטיינרים, להקים, לבנות, Load balancing, HA וכו' וכו' – הכל כבר שם. תורידו מה-GIT ותתקינו ואין לכם צורך לשלם על כלום.

ב-95% מהמקרים האחרים – חברות בד"כ יעדיפו מוצר מסחרי עם תמיכה מלאה של היצרן, עדכונים מהיצרן וכו' וכאן בישראל נמכרים 2 מוצרים: Docker Datacenter שנמכר ע"י מטריקס ו-OpenShift שנמכר ע"י העסק שלי (אם כי, לשם הגילוי נאות וה"פרסומת", העסק שלי אינו היחיד שמוכר אותו, רק שכאן תקבלו משהו .. טיפה יותר מקצועי. הדגמות וידאו על Open Shift, אגב, בקרוב יופיעו בערוץ יוטיוב של חץ ביז).

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

  • אם אתם חושבים להקים מכמות של כמה מכונות בודדות (VM או פיזי) ועד כמה עשרות כאלו (הם נקראים Nodes) – אז מבחינת תמחור, ה-Docker Datacenter זול בהרבה מהפתרון עם OpenShift. בנוסף, אם מערכת ההפעלה העיקרית שלכם היא Windows והקונטיינרים שלכם יריצו קוד שרץ על מערכות מיקרוסופט – Docker Datacenter הוא הפתרון היחידי כרגע המתאים לפלטפורמות מיקרוסופט.
  • אם לעומת זאת אתם מתכננים על מאות Nodes ומעלה – הפתרון של OpenShift שווה יותר (וזול יותר)
  • אם אתם מעוניינים להקים תשתית חדשה לגמרי שתהיה נפרדת מתשתית הוירטואליזציה הנוכחית שלכם ושאותה תשתית חדשה תריץ קונטיינרים – אז אני ממליץ לרכוש את ה-OpenStack החדש (שם קוד: Magnum) שדואגת גם לתשתית כולה (Compute, Network, Storage, Authentication, Images וכו') וגם להרצת קונטיינרים, בניה, LB, HA וכו'. גם רד-האט וגם SuSE ישראל מוכרים את OpenStack Magnum. אינני יכול לפרסם מחירים של אף מוצר אבל מה שאני כן יכול לרמוז – זה שכדאי להתעניין אצל 2 הספקים במחירים. התחרות רצחנית!

כדאי לזכור משהו חשוב: אין מעבר קל בין Docker Datacenter ל-OpenShift. שתיהן אמנם משתמשות ב-Dockerfile כדי להרים קונטיינרים מבוססי Docker, אולם כל המערכות "מסביב" הינן שונות לחלוטין. ב-Docker Datacenter משתמשים ב-Docker Swarm ואילו ב-OpenShift משתמשים ב-Kubernetes. אפשר לייצא ולייבא קונטיינרים דרך סקריפטים אבל מנסיון – זה לא כיף גדול וזה די מורכב.

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

מכירות – לא עדיף לרכוש ישירות מיצרן התוכנה?

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

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

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

בניגוד למיקרוסופט, ליצרני הפצות לינוקס אין פתרון לכל דבר. כשזה מגיע לפתרונות ניהול תשתיות, הפתרונות של רד האט יותר טובים, אבל כשזה מגיע ל-OpenStack או לפתרון אחסון Scale Out או פתרון עדכונים לשרתי Windows ולינוקס – הפתרונות של SuSE יותר טובים וכשזה מגיע לפתרון אחסון Scale Up הפתרונות של אף אחת מהיצרניות לינוקס אינו מספק ברמה טובה (במקרים כאלו עדיף לבנות אחד מקוד מקור ולמכור ללקוח תמיכה).  יותר מכך – פתרונות רבים כוללים תוכנות שונות שאין להן קשר לאף  אחת מהיצרניות. אם לדוגמא תרצה לנטר מאות ואלפי מכונות וירטואליות או קונטיינרים – פתרון של ZABBIX יעשה את הדברים באופן אוטומטי ואם רוצים גרפים יפים מאוד – אפשר לשלב בקלות את Grafana לדוגמא. מישהו מיצרני הפצות הלינוקס משווק זאת? לא. אפשר לבקש לשלב את הפתרונות מיצרן ההפצה, אך במקרים כאלו תתכונן לשלם הרבה "אקסטרא" מכיוון שמערכות התמיכה של יצרני ההפצה לא תומכות ב-Zabbix או Grafana (ותוכנות רבות אחרות) וזהו חסרון גדול של רכישה ישירות מיצרן הפצת הלינוקס.

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