המודלים הפיננסיים החדשים לשרתים

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

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

אם נלך לפי אחוזים ונבדוק כמה סטארט-אפים שקיבלו מעבדכם הנאמן שרות יעוץ – רכשו ציוד בסוף, נגיע למספר מפתיע: 90% לא רכשו בכלל חומרה (למעט לאפטופים, מתג כלשהו, VPN, תקשורת DATA) ומי שכן רכש, היה סטארט-אפ אחד שפיתח כלי סייבר שהתעקש על ציוד On prem. שימו לב: אני לא מדבר על מצב שלא רכשו דרכי, אלא לא רכשו כלל שרתים, סטורג’ וכו’.

מדוע הם לא רכשו? הסיבה נורא פשוטה: בזמן שהם הצליחו לגייס כספים, ה-VC פשוט לחצו (ובחלק מהמקרים התנו) שהסטארט-אפ לא ירכוש שרתים וסטורג’ אלא ישתמש בשרותי סע”צ, ובכל המקרים ה-VC היה מקשר בין ה-סע”צ לבין הסטארט-אפ, והסטארט-אפ היה מקבל כמה אלפי/עשרות אלפי דולר בקרדיטים למשך 12-18 חודשים. איך אני יודע על כך? כי אותן חברות בדיוק פנו שוב אל הח”מ וביקשו יעוץ לגבי סעצ”ים שונים, עם מי לעבוד, ואלו שרותים לשכור.

אם ישנה טעות אחת גדולה שעשו כל יצרני השרתים הפופולריים (Dell/HPE/Cisco/Lenovo) – הטעות תהיה ההתעלמות המוחלטת מהמעבר של לקוחות לשימוש ב-סע”צ. יצרני השרתים לא יכולים למכור שום ציוד לסע”צ כי סע”צ בונה ורוכש חלקים, כך שעלות ה-BOM לשרת אצל סע”צ היא מחצית ומטה ממה שיצרן שרתים מבקש. אז למי אפשר למכור? לעסקים קטנים עד גדולים, אולם אלו עוברים לענן ומקבלים משהו שהם לא מקבלים משום יצרן.

כפי שתיארתי לעיל, כל הסטארט-אפים שקיבלו מימון מ-VC קיבלו קרדיטים לשימוש אצל סע”צ. עם הקרדיטים הללו אותם סטארט-אפים יכולים להקים תשתית וירטואלית והכסף יכול להספיק בניהול נכון למשך 12-18 חודשים מבלי שהסטארט-אפ יצטרך להוציא סנט. לעומת זאת, כשסטארט-אפ צריך לרכוש ברזלים, הוא צריך לשלם Up Front (תשלום אחד או יותר, לא ממש משנה). מהרגע שסטארט-אפ משתמש בקרדיטים ומקים את התשתית ועוברת שנה – הסיכוי שאותו סטארט-אפ יזרוק את כל התשתית הוירטואלית ויעבור לתשתית On prem היא אפסית.

וכך מגיע מצב שחברה כמו Dell ראתה ברבעון האחרון איך המכירות שלה עלו בהשוואה לרבעון הקודם ב-2%, אולם בהשוואה לשנה הקודמת, נרשמה ירידה של 12%. המצב אינו מעודד אצל אף יצרן שרתים. ככל שעסקים וסטארט-אפים עוברים להשתמש בתשתית ובשרותים של סע”צ, הסיכוי שהם ירכשו שרתים/סטורג’/סוויצ’ים וכו’ יורד במהירות. המצב ב-Dell אינו יחודי, אותו דבר מתרחש גם ב-HPE (הנה קישור)גם ב-Cisco (קישור) וכן, גם ב-לנובו (קישור). הסיפור חוזר על עצמו באותן חברות: או ירידה במכירות, או שגרף המכירות “שטוח” עם אזהרות מההנהלות השונות שהמצב לא הולך להשתפר כרגע. שימו לב שהמספרים מתייחסים למכירות כוללות – כלומר גם ממכירות ישירות וגם מכירות ממפיצים, תיכף אתייחס לכך.

ואז היצרנים החלו לעשות “חושבים” איך להתחרות ב-סעצ”ים והראשונה שהכריזה על שינוי היתה חברת HPE שהכריזה כי החל מ-2022 כל הברזלים (שרתים, סטורג’, רשתות וכו’), תוכנות ושרותים יהיו זמינים כ-Subscription. שלשום הכריזה חברת Dell על משהו דומה שנקרא Dell On Demand. אני מאמין שיצרנים מתחרים יכריזו בקרוב על שרותים מתחרים חופפים. המכנה המשותף לכולם: שרות שמתחרה באמזון ובמיקרוסופט.

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

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

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

כל יצרן יממש את הדברים האלו בצורה שהוא יחליט אולם לפי מה שידוע לי משיחות עם מהנדסים (כלל חשוב: אם אתה רוצה לדעת דברים אמיתיים על יצרן, דבר עם מהנדס שעובד בחברה, לא עם איש מכירות/הנהלה) – הדברים יבוצעו דרך ה-ILO עם License Manager או בחיבור ישיר מרחוק לשרת (תלוי בתקשורת, כמות שרתים וכו’) וב-Dell דרך iDRAC מעודכן. כך, אם אתה מנסה להתחמק מתשלום או שכרטיס האשראי/אמצעי תשלום לא פעיל, החברה יכולה לנתק (תקשורת) את השרת מרחוק, לחסום Boot/UEFI עם סיסמא וכו’ וכו’.

האם שיטות מכירה אלו יעבדו? אני לא בטוח מהסיבות הבאות:

  • כשאתה משלם על תשתית וירטואלית ל-סע”צ, התשלום שלך כולל חשמל,  קירור, תחזוקה וכו’. כאן אתה עדיין ממשיך לשלם על חשמל וקירור ועל אנשי סיסטם שכבר עובדים אצלך, כך שלא בטוח שזה שווה.
  • חברות גדולות כבר רגילות לעניין התשלום Up Front. לא בטוח שהם יאהבו את השיטות החדשות.
  • הנהלות רבות יתהו – אם כבר משלמים כל חודש, מדוע לא לקחת שרותים אצל סע”צ? (למעט מקרים שחייבים את התשתית On Prem עקב Latency וכו’)

ולבסוף – הנקודה הישראלית: תשאל יבואנים או מפיצים, וכולם כיום יאמרו לך ששרותים אלו לא יהיו זמינים בישראל. זה נכון? בשלב הנוכחי כאן, אבל בעתיד הקרוב לא בגלל סיבה פשוטה: היצרנים רוצים להרוויח מכל סוג מכירה שיש, כך שזה לא יהיה מוגבל לארה”ב (בשום מסמך, לא של HPE ולא של Dell שאני ראיתי – לא נכתב ששרותי ה-Subscription/On Demand לא כתוב, למיטב ידיעתי, שזה יהיה מוגבל לארה”ב). אני מאמין שיצרני השרתים יציגו חוזים חדשים שבהם המפיצים מקבלים עמלה מופחתת אם הלקוח לוקח On Demand, אבל המפיץ ממשיך לקבל כספים שנגבים מהלקוח – באופן שוטף חודשי, כך שיהיה מצב שגם בשביל מפיצים זה יהיה שווה לקדם שרותי Subscription/On Demand. בשלב זה, כפי שציינתי – זה לא זמין בארץ.

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

כשצריכים שרת קטן

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

כל יצרני השרתים מייצרים סוגים מסויימים של שרתים שנמכרים בכמויות גדולות, ואלו שרתי ה-1U וה-2U ה”רגילים”: מעבד יחיד או זוג של Xeon, זכרון, דיסקים וכו’. מחירי השרתים הללו (חדשים) בדרך כלל מתחילים בסביבות ה-3000$ לתצורה מינימלית.

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

חברת DELL הוציאה לאחרונה בדיוק שרת כזה. תכירו – זהו שרת R340.

השרת הזה הוא שרת 1U אך הוא שרת שהוא קטן פיזית, כך שהוא יכול להיכנס בקלות בארון עם עומק של 80 ס”מ. השרת עצמו בנוי עם לוח אם ש”הושאל” מתחנת עבודה: אין לו תושבת LGA-3647 אלא תושבת של מעבדי דסקטופ (LGA-1151). המעבדים שנתמכים בשרת כזה הם מעבדים כמו ה-Intel® Pentium G5500 ועד מעבדי Intel® Xeon® E-2126G – עד 6 ליבות ו-12 נימים. מבחינת זכרון – אפשר להכניס עד 64 ג’יגהבייט זכרון (בהמשך יצא עדכון שיאפשר להכניס מקלות DIMM של 32 ג’יגהבייט זכרון וכך ניתן יהיה להרחיב את המכונה לזכרון של 128 ג’יגהבייט). מבחינת אכסון ניתן להכניס או 4 דיסקים 3.5″ או 8 דיסקים 2.5″. השרת כולל ניהול (iDRAC), ניתן להחליף את חיבורי הרשת (יש 2) מ-1 ג’יגהביט ל-10 ג’יגהביט, ויש גם תמיכה לכרטיסי מיקרו SD וגם למקלוני אחסון M.2.

בקיצור – שרת סולידי בקצה התחתון.

נו, אז מה המחיר של מכונה כזו? ובכן, מכונה כזו עם מעבד Xeon E-2124 עם 4 ליבות, 8 ג’יגהבייט זכרון ודיסק 1 טרהבייט יעלו לך (בארה”ב) כ-1569$. אני מאמין שבארץ המחיר יהיה שונה ויותר גבוה, אבל אני לא מאמין שזה יגיע לכפול מכך. למי שרוצה לחסוך עוד במחיר, יש גם את דגם R240 עם אותה קונפיגורציה ב-1319$ (שוב, מחירי ארה”ב Online), אך הוא אינו מתאים לאלו שרוצים להתחיל עם מעבד שאינו Xeon.

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

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

כמה מילים על פתרון סטורג’ (קוד פתוח) משולב

לא מעט חברות מחזיקות ברעיון שפתרון אחסון (Storage) צריך להיות פתרון קנייני בצורת כמה חלקים (כולל “ראש”) ומדפים של דיסקים. בשנים האחרונות יותר ויותר חברות מאמצות גם את רעיון ה-Hyper Converge – ערימה של שרתים שנותנים אחד לשני (והחוצה) את כל השרותים ביחד – רשת, דיסק, מחשוב, ובמקרים של Open Stack – שרותים נוספים.

הבעיה בד”כ היא במחשבה או בתכנון מעבר. אם לדוגמא יש לכם פתרון וירטואליזציה של VMWare ותרצו ליישם את VSAN, ההשקעה תהיה גבוהה. על כל שרת ממוצע תצטרכו לשלם 5000$ וזה עוד לפני הדיסקים והתצורה היחודית שיש צורך ב-VSAN (על כל 2 דיסקים מכניים או SSD בינוניים, דיסק SSD מהיר או Mixed Intense או ביחד). במקרים אחרים יש פתרונות HyperConverged כמו Nutanix, Simplivity וכו’ שבסופו של דבר מחייבות אותך לרכוש כמעט הכל מחדש (אם כי כמובן אפשר במקרים מסויימים להשמיש שרתים שונים, תלוי מה ה”גיל” שלהם).

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

גם במקרים של פתרון קוד סגור או קוד פתוח, נצטרך דבר ראשון להעיף מבט על השרתים שיש לנו. רוב השרתים שמריצים פתרון וירטואליזציה כלשהי, אנחנו נראה שרוב התושבות בשרתים – פנויים (וכמובן שיצרני השרתים מנצלים זאת על מנת לתת פתרון Backplane חלקי, כך שגם אם תרצה למלא 24 דיסקים 2.5″ בשרת, לא תוכל אלא אם תרכוש עוד 2 backplanes עם החיבורים. בד”כ ה-backplane שאתה מקבל בשרת יכול לחבר מקסימום 8 דיסקים), כלומר שמבחינת השקעה בברזלים אם נרצה פתרון סטורג’ מבוזר, נצטרך לרכוש פתרונות backplane לשרתים, וכמובן דיסקים מכניים, SSD (מסוגים שונים – read intense או mixed Intese – תלוי בתקציב ובמה שאתם רוצים לעשות). נקודה נוספת שנצטרך לקחת בחשבון זו הרחבת זכרון. אין צורך “להשתולל”, בד”כ לפתרון SDS נצטרך 16 או 32 ג’יגהבייט זכרון. הנקודה האחרונה שיכולה להיות קצת יקרה היא רשת – אנחנו נצטרך בכל מכונה חיבור של 10 ג’יגהביט לתקשורת פנימית בין ה-VM שמריצים את פתרון ה-SDS.

את פתרון ה-SDS נריץ כ-VM בתוך כל מכונה, אולם אנחנו צריכים קודם כל להחליט איפה בעצם לאכסן את הנתונים, באלו דיסקים. דיסקים בגודל 2.5″ לדוגמא יהיו קצת בעייתיים כי כמות ה-DATA שאפשר לאכסן בהם היא לא גדולה אך המחיר הוא די גבוה. אם לדוגמא נדמיין שאנחנו מכניסים 20 דיסקים של 1 טרה בגודל 2.5″, ועוד 2 דיסקים SSD שישמשו כ-Cache, אז נקבל “ברוטו” 20 ג’יגהבייט. אולם אם נחליף את הפאנל הקדמי (כולל הלוח המוצמד) לגירסת LFF (כלומר Large Form Factor), אז נוכל להכניס 12 דיסקים של 4 טרהבייט, אז נקבל “ברוטו” 48 טרהבייט ומחירי הדיסקים הללו יהיו יותר זולים מ-20 דיסקים של 2.5″ (בד”כ נוכל להכניס 2 דיסקים SSD ל-Cache מאחורי השרת). מבחינת הוירטואליזיציה, אין לנו צורך להתקין אותה (בגירסת vSphere) על הדיסקים המקומיים, 2 כרטיסוני מיקרו SD יוכלו לעשות את העבודה. (בין כה כמות הכתיבה אליהן מאוד קטנה ואם כרטיס נופל, כרטיס שני “לוקח פיקוד”) כך שאנחנו יכולים בסופו של דבר להצמיד את כרטיס ה-RAID ל-VM עצמו ולקבל מקסימום ביצועים.

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

כעת, כל מה שנותן לעשות זה לחבר את הדברים. בכל מכונה נקים VM עם הפצת לינוקס כלשהי (GlusterFS קיים לכל הפצת לינוקס שתרצו), להגדיר אם אנחנו מעוניינים בשכפול והפצת קבצים (אפשר לראות את האפשרויות כאן, פוסט מורחב על הנושא יהיה בקרוב) ומאותו פתרון SDS נוכל להגדיר שיתופים איך שנרצה: CIFS, NFS, iSCSI ועוד. כך נוכל להנות גם מפתרון SDS יציב, שיכול לעמוד במצב ששרת או 2 נופלים (תלוי איך הוגדר GlusterFS, בד”כ הגדרות ברירת מחדל יתנו HA כך שאם מכונה נופלת, השניה לוקחת פיקוד), גם נוכל להרחיב את הפתרון בהמשך (הוספת דיסקים, JBOD, מכונות נוספות) והכי חשוב – נוכל להנות מפתרון שנותן גם ביצועים מהירים וגם התחזוקה עצמה תהיה די מינימלית.

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

ההבדל בין קוד פתוח למוצר מסחרי מבוסס קוד פתוח

לפני מספר חודשים פרסמתי בכמה מקומות סקירה מקוצרת על פרויקט של Red Hat שנקרא oVirt. הפרויקט הזה הוא בעצם ה”תשובה” של Red Hat לכל אלו שמחפשים מוצר וירטואליזציה כ-Hyper Converge. המערכת כוללת בפנים פתרון סטורג’, רשת וכמובן Compute ויש בה עוד חלקים שלמוצרים מתחרים יש תשובות חלקיות.

כעבור מספר ימים פנה אליי אחד מקוראי הבלוג, הוא בכיר באחד ממוסדות הבריאות הגדולים בארץ והוא ביקש אם לא אכפת לי לתת להם הדגמה מרחוק של מערכת oVirt עובדת, לא סתם Demo. מכיוון שהרמתי אצלי בבית ב-LAB פתרון כזה עם מכונות VM שאני משתמש בהם – הדגמתי לו ולחבריו את המערכת. בסוף ההדגמה הוא אמר לי משהו פשוט: “חץ, זה מעולה שאתה מכיר את המערכת, אבל אני לא יכול להקים כאן מערכות כזו כתחליף כשרק חץ בן חמו יכול לתמוך לי בה.”

המשפט שהוא אמר די מסכם את הטעויות ש”מושרשות” אצל חלקי ממנהלי ה-IT/מנמרי”ם בארץ, וכשאני אומר “טעויות”, אני מתכוון ליותר מאחת.

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

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

הנקודה השניה החשובה היא כמאמר הפתגם “יותר משהעגל רוצה לינוק, הפרה רוצה להניק”. כל יצרני השרתים מוכרים את המוצרים המסחריים מבוססי הקוד הפתוח כולל תמיכה מלאה 24/7, כלומר אם מחר תרצה לרכוש שרתים מ-HPE או DELL או LENOVO ותרצה לרכוש פתרון אחסון SDS, פתרון קונטיינרים כמו OpenShift המסחרי, פתרון סטורג’ Scale Out כמו Ceph או Gluster או מוצר ענק כמו SAP HANA – הם ימכרו ויתמכו בך כולל SLA מלא ואז אינך תלוי באם חץ בן חמו זמין או אם יש מישהו אחר שיתן לך תמיכה. אתה מקבל תמיכה מלאה בדיוק כמו שאתה מקבל תמיכה לברזלים שלך. ליצרן יש תמיכת “גב אל גב” עם יצרן התוכנה. דוגמא פשוטה לחובבי מיקרוסופט ו-Azure – אם יש לך הפצת לינוקס מותקנת על VM ב-Azure ויש לך בעיה, אתה פונה לתמיכת Azure והם מנסים לפתור. לא מצליחים? יש להם קו ישיר ליצרן ההפצה שיעזור להם ולך לפתור את הבעיה.

לסיכום: כמו שאתה קונה מתגי תקשורת של Cisco, כמו שאתה קונה מערכת מורכבת כמו JIRA, כך גם עם מוצרים מסחריים מבוססי קוד פתוח. החברה שמוכרת לך את זה, בין אם יצרן התוכנה או יצרן הברזלים – אתה מקבל שרות מלא הכולל התקנה, הטמעה, תמיכה וכו’ לפי SLA שנקבע בין הצדדים. זה ש-HP מעדיפים למכור סטורג’ 3PAR שלהם או DELL מוכרים סטורג’ כמו UNITY, לא אומר שזה הדבר היחיד שהם מוכרים. יש להם עוד מוצרים, אתה פשוט צריך לבקש את זה במסגרת ההזמנה ואין שום הבדל בתמיכה/התקנה/הטמעה בין אם קנית לדוגמא סטורג’ קנייני או פתרון סטורג’ SDS, בין אם קנית פתרון מבוסס קוד פתוח או פתרון סגור לחלוטין. יש כמובן את הפרויקטים בקוד פתוח שהם אינם מוצר מסחרי ואתה חוסך את הקניה איתם, אבל שם המסלול הוא שונה והוא יותר קשור בחברות ועצמאים פה בארץ שיכולים לתת לך שרות על כך, ולכן כדאי להבדיל בין הדברים.

Exit mobile version