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

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

נקודות חשובות בשדרוג ל-CentOS 7.4

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

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

כמו תמיד, בגרסאות עדכון Minor ישנם שינויים רבים בהפצה, אך שינויים אלו עדיין שומרים על תאימות בינארית, תאימות קבצי הגדרות וכו'. יחד עם זאת, בחלק מהמקרים מעדיפים ברד-האט (ונגזר מזה גם ב-CentOS) לשדרג חבילות מסויימות לגרסאות Major מתקדמות יותר ובלבד שתשאר התאימות. הסיבה לכך היא שהפצת לינוקס (בניגוד לגירסת Windows) כוללת אלפי חבילות (וזאת לפני הפעלת מאגר תוכנות מומלץ כמו EPEL) ואין לרד-האט את המשאבים לעקוב אחרי כל החבילות וליישם Backporting של עדכוני אבטחה. ברד-האט בודקים אם ישנן פריצות ידועות ואם הפריצות נחסמו בגירסה יציבה מתקדמת יותר, גירסת העדכון הבאה תכלול את הגירסה המתקדמת יותר (מה שנקרא בשפה המקצועית "Rebase").

ב-רד-האט שחררו מסמך ארוך לגבי השינויים ברד-האט 7.4 (וכמובן כל הדברים נמצאים ב-CentOS 7.4) שנמצא כאן ומאוד מומלץ לקריאה לפני שדרוג שרתים. ישנם שינויים כמעט בכל תחום, Kernel עם עדכוני מודולים, תמיכה בדרייברים חדשים, חבילות בגירסאות חדשות (ה-Rebase שהזכרתי לעיל). בלינק לעיל תוכלו למצוא את ה-General Updates שמדבר בכלליות על השינויים ומתחתיו פירוט לגבי השינויים.

ברוב המקרים, הרצת yum update תשדרג מערכת מכל גירסה קודמת (7.0, 7.1 וכו') לגירסה האחרונה בלי הרבה בעיות, אולם ישנם מקרים בהם השדרוג יכשל או יותר חמור – המכונה/VM לא תצליח לעשות Boot או לא תצליח להפעיל תקשורת דרך כניסות התקשורת הרגילות/וירטואליות.

להלן כמה נקודות חשובות שכדאי לשים אליהן לב לפני שמשדרגים לגירסה 7.4:

  • אם אתם משתמשים ב-iptables וב-ip6tables (הראשון מיועד ל-IPV4 והשני ל-IPV6, הן מותקנות כברירת מחדל בהתקנה רגילה). אם אתם מפעילים את שתיהם, יכולות להיווצר בעיות של תקשורת. הבאג מתוקן ב-CentOS 7.4 בחבילה iptables-1.4.21-18.0.1.el7 אך הוא עדיין לא מתוקן ברד-האט 7.4. הפתרון המומלץ כרגע – להפעיל רק אחד מהם ולבטל את השני (בעזרת פקודת systemctl disable).
  • אם אתם משתמשים ב-Xen, מכונת VM של CentOS 7.4 עם דרייברים Paravirtualized – ה-VM לא יצליח לבצע BOOT וכרגע הפתרון הוא HVM (או PV-on-HVM). תיקון לכך יצא בקרוב.
  • במקרים מסויימים הרצת yum update תתקין חבילות i686 ולא X86-64. הבעיה מתרחשת עקב התקנת RDMA. אם אתם משתמשים ב-RDMA, מומלץ להריץ yum install rdma-core && yum update. אם אתם עדיין רואים בעיה, מומלץ להריץ yum install rdma-core ibacm. 
  • אם אתם רוצים להתקין VirtualBox על תחנת עבודה שתריץ כ-host את CentOS 7.4, תצטרכו להתקין את גירסת VirtualBox 5.1.28 מהאתר. גירסה 5.1.26 לא תעבוד.
  • משתמשים ב-VMware ורוצים להקים VM מבוסס CentOS 7.4? עקב שינויים שרד-האט ביצעו בקרנל, התקשורת הוירטואלית לא תעבוד. יש צורך בהתקנת Patch ל-VMware tools. לפרטים – כנסו ובצעו את ההוראות בקישור הזה.
  • חבילת ה-initramFS הרבה יותר גדולה מבעבר, ולכן אם מחיצת ה-boot/ שלכם קטנה מ-1 ג'יגהבייט, תצטרכו להרחיב אותה לפני השדרוג ל-7.4 לפחות לגודל 1 ג'יגהבייט (אני ממליץ להרחיב לגודל 5 ג'יגהבייט אם הנכם מתקינים מספר גרסאות קרנל).
  • יכול להיות ששרות SAMBA יפול עם השגיאה symbol krb5_get_init_creds_opt_set_pac_request, not defined. במקרים כאלו יש להתקין את חבילת  krb5-libs-1.15.1-8.el7 ולהפעיל את שרות SAMBA מחדש.
  • ועוד בעניין SAMBA – אם אתם עובדים עם אותנטיקציית SSSD ומאפשרים SHARE, זה לא יעבוד. כרגע האפשרות היחידה היא לשנמך לגירסה שקיימת בסנטוס 7.3. כרגע רד-האט עובדים על הבאג הזה.
  • נדיר, אבל ראיתי מקרים שזה קורה: אתם מפעילים את ה-CentOS ואין תקשורת עד שאתם מבצעים Login או שהתקשורת לא מופעלת בזמן Boot. במקרים כאלו, עקבו אחר ההוראות כאן.
  • החל מגירסה 7.4, מינימום זכרון שנדרש עבור המערכת הוא 1 ג'יגהבייט. במקרים שאתם רוצים להריץ את ה-ISO כ-LIVE, יש צורך בלפחות 1.5 ג'יגהבייט זכרון.
  • עוד בענייני VMWare: אם אתם מגדירים ידנית VM לשימוש עם CentOS 7.4, אל תנסו לבחור דרייברים SCSI אלא אך ורק את ה-Paravirtualized. דרייברים ל-SCSI ש-VMWare השתמשו כבר לא קיימים בקרנל הזה.
  • אוהבים את פקודת ifconfig ו-netstat? תתכוננו לשכוח מהם. הם מסומנים כ-Deprecated והם אינם מותקנים כברירת מחדל עם CentOS 7.4, ולכן אם הרשת שלך לא עלתה, השתמשו בפקודת nmcli כדי להפעיל את כרטיס הרשת ואז תוכלו להתקין את החבילה (ותתכוננו לשנות סקריפטים שמשתמשים בפקודות הנ"ל).
  • בסנטוס 7.4 מותקנת גירסה חדשה של sudo שמשתמשת ב-var/db/sudo/lectured/ ולפיכך ההתראה הראשונה שמשתמשים ב-sudo (עם האזהרות וכו') תופיע מחדש לכל המשתמשים ב-sudo לאחר שדרוג לסנטוס 7.4.
  • אם אתם משתמשים ב-CentOS 7.4 עם GNOME, יכול להיות שמנהל הקבצים (Nautilus) יראה את האייקונים מאוד גדולים. הפתרון הוא להריץ את הפקודה: gsettings set org.gnome.nautilus.icon-view default-zoom-level 'small' ולבצע lougout ולאחר מכן login.
  • אם אתם משתמשים ב-CentOS 7.3 (או גרסאות 7 קודמות) ואתם מריצים על זה OpenLDAP ואתם מתכוונים לשדרג, יש לבצע את ההוראות בלינקים כאן וכאן או שתהיה לכם בעיה רצינית עם ה-OpenLDAP. בכל מקרה אם מדובר ב-VM, בצעו snapshot לפני כן.

בכל מקרה, תמיד מומלץ להסתכל בדף ה-Errata של רד-האט ולוודא שאין עדכונים שלא התקנתם או שלא שמתם לב אליהם.

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

החלוקה

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

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

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

Solaris / SPARC – הסוף

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

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

בהתחלה זה עבד לא רע. בכל זאת, ל-Sun היו שרתים כלל לא רעים, פתרונות סטורג' מבוססי ZFS, פתרונות משולבים כמו Exadata ועוד מוצרים שחברות גדולות רכשו, אך הבעיה הגדולה ביותר היתה – סטגנציה. מערכת ההפעלה Solaris לא קיבלה עדכונים רציניים, מערכת ה-ZFS גם לא קיבלה תכונות חדשות ורציניות מאז סולאריס 10, וגם מעבדי ה-SPARC החדשים לא ממש היוו איום רציני לאינטל (שבסופו של דבר כבשה את שוק השרתים בכל מובן). אינטל פתחה מרכזי לינוקס בתוך החוברה ובסבלנות ועבודה עם יצרני הפצות לינוקס כמו רד-האט ו-SuSE כדי לשפר עוד ועוד את ליבת הלינוקס (ואת המעבדים עצמם) על מנת לתת תוצאות לא-פחות-טובות מהשילוב של סולאריס ו-SPARC וכיום מבחינה טכנית, אין שום הצדקה טכנולוגית להטמיע Solaris. אם אתה מחפש פתרון מבוסס יוניקס, פשוט תתקין לינוקס ותגמור עם זה, שלא לדבר על כך שדברים שנכנסו חזק לטרנד כמו Machine Learning או IOT – אתה צריך לינוקס וסולאריס לא יתן לך פתרון (בהצלחה להפעיל כרטיסי Tesla עם סולאריס. מנסיון – זה לא כיף, גם כשיש דרייברים של nVidia).

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

אורקל מנסה גם ללכת בשיטת ה-Me too. פתרון הוירטואליזציה שלהם? העתק של Xen. פתרון הלינוקס שלהם? העתקה ישירה מ-RHEL (של רד-האט) ואפילו הכלים המיוחדים שאורקל העבירו מסולאריס – כיום ב-2017 יש להם חלופות שהן בקוד פתוח לגמרי וכמובן רצות על כל הפצת לינוקס. גם בתחום הענן אורקל התעוררה מאוחר מדי ואם תסתכלו מבחינת דוחות Market Share, תוכלו לראות שאורקל נמצאת בד"כ בגרפים בתוך קטגוריית ה-Others. איך אורקל ישיגו לקוחות לענן שלהם? בכך שהם יעשו כל מאמץ לדחוף את הלקוחות שלהם שמשתמשים ב-Middleware וב-DB של אורקל – לענן תוך מתן הנחות (אני מנחש: זמניות) ולמי שמתעקש לעבוד On Premise – חכו לחשבוניות החידוש רשיון.

האם אורקל מחר הולכת "למות"? אני בספק, אבל מצד שני בינתיים לא רואים שום מנועי צמיחה רציניים שם. אם מחר חברתכם תחליט לעבור לענן, סביר להניח שהיא תבחר באמזון או מיקרוסופט ואולי גם יחשבו על פתרון הענן של גוגל, אבל אני מאוד בספק אם חברות יעברו לענן הציבורי של אורקל. גם בתחום ה-On Premise מחכה לאורקל תחרות לא קלה עם ההצעה החדשה של מיקרוסופט לחברות שמתעקשות להריץ את ה-DB שלהם באורקל תחת לינוקס: מיקרוסופט מוכנה לתת רשיון מלא ל-SQL Server החדש שרץ תחת לינוקס בחינם לכל לקוח שעובר מאורקל (ואגב, ה-SQL של מיקרוסופט יכול לרוץ גם כקונטיינר Docker בלינוקס) כך שכשחברות יצטרכו לחדש רשיון, יהיה להן קשה מאוד לסרב להצעה של מיקרוסופט, במיוחד שהן לא צריכות לשנות מערכת הפעלה..

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

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

קצת על רד-האט, BTRFS, פוליטיקה ומוכנות ל-Enterprise

אם נסתכל כיום על תשתיות של כל Enterprise או כל חברה גדולה, נראה שכיום רוב מכונות הלינוקס וה-Windows רצות כרגע על VM, בין אם זה רץ על ESXI, על Hyper-V, על OpenStack או בעננים ציבוריים או פרטיים. גם לינוקס וגם Windows רצים בלי בעיה כ-VM ולכל מערכת הפעלה יש תמיכה טובה בקישוריות בין ה-VM ל-Hypervisor שמריץ אותו.

הבעיות מתחילות כשצריכים להריץ הפצות לינוקס כמו רד-האט או סנטוס על "ברזל" פיזי או Appliance פיזי. אין שום בעיה להתקין לינוקס וברוב המקרים גם לא נצטרך דרייברים, וה-File system יעבוד כמו שצריך, אולם יש דברים בלינוקס שהם אינם קלים או מובנים למשתמשים רבים שאינם אנשי לינוקס ותיקים. יצירת RAID מבוסס תוכנה (Software RAID או Fake RAID) הם לא בדיוק דבר הכי קליל, במיוחד אם רוצים לשלב Volume Management בתוך אותו RAID תוכנה (אם כי כמובן יש אתרים שמסבירים כיצד לעשות זאת). את המשוכה הזו ניתן לדלג עליה די בקלות אולם אם אנחנו רוצים לבצע Snapshots או להוסיף SSD כ-Cache לאותו RAID, זה כבר נהיה יותר מורכב. רוצה גם לבצע Compression ו-DeDup בזמן אמת? כאן כבר תצטרך איש לינוקס טוב וזה לא תמיד אפשרי, תלוי במה קיים ובאפשרות לשנות דברים.

האם ניתן לעשות את הדברים בלינוקס? התשובה היא שבהחלט כן. אני כותב את הפוסט הזה בביתי ואחד משרתי ה-NAS שלי עושה בדיוק את הדברים הללו: ה-RAID הוא תוכנה, המערכת מייצאת iSCSI, CIFS, NFS החוצה למערכות אחרות (כל עריכת הוידאו שלי שאתם רואים בערוץ הוידאו של העסק מבוצעת על CIFS/SAMBA, לא על דיסק מקומי), יש DeDuplication  ויש דחיסה והכל רץ על "מפלצת" עם … מעבד i5 ועם 16 ג'יגהבייט זכרון, 5 דיסקים מכניים ו-2 דיסקים SSD ישנים שישבו אצלי במגירות. המערכת עצמה רצה על ZFS עם הפצת CentOS 7 ועם כל העומס שאני זורק עליה (ויש עומס) – היא עושה את עבודתה יציב כבר 4 שנים בלי תקלה אחת הקשורה ל-ZFS.

אז אם יש את זה, מדוע אינך רואה בהפצת לינוקס מבוססת רד-האט או סוזה אפשרות להקים מכונה עם ZFS? הרי ל-ZFS יש כבר ותק של בערך 12 שנה ב-Sun עם סולאריס (המערכת פותחה שם במשך 5 שנים לפני שהיא שולבה בסולאריס).

הסיבה הרשמית היא "בעיה ברשיון", הסיבה המציאותית יותר היא … פוליטית.

הרשיון ש-ZFS שוחרר כקוד פתוח הוא רשיון CDDL, רשיון המאפשר שילוב הקוד במסגרת פרויקטים בקוד פתוח אך אינו מאפשר שילוב עם קוד מבוסס GPL כמו קוד הליבה (Kernel) של לינוקס, כך שאנחנו לא נראה אף פעם את קוד ה-ZFS משולב בתוך קוד הליבה של לינוקס. יחד עם זאת, ישנם מספיק דרכים עוקפות (וחוקיות) לשלב את ZFS בהפצת הלינוקס עוד בשלב ההתקנה, בדיוק כמו שאובונטו עושים (החבילות אינן כלולות ב-ISO, הן פשוט ניתנות להורדה ויש הוראות כיצד להכין מערכת כזו שכולה תהיה ZFS.

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

ב-2008 החלה לקום מערכת ניהול קבצים ודיסקים חדשה בשם BTRFS. בעקרון, BTRFS אמור להיות התשובה ל-ZFS רק בקוד GPL והוא משולב בתוך הליבת לינוקס. אנחנו ב-2017 וכיום כל הפצת לינוקס תומכת ב-BTRFS אולם הבעיה הגדולה ביותר של BTRFS היא ביציבות. ה-BTRFS יציב מבחינת file-system אך יש לא מעט בעיות במימוש ה-RAID שלו ובחלקים אחרים. בזמנו הקוד נבנה תחת קורת הגג של אורקל, אולם מאז שאורקל החליטה לברוח מקוד פתוח כאילו מדובר במחלה מדבקת – התפזרו המפתחים לכל עבר ואין עבודה יציבה על BTRFS, מה שגרם לרד-האט להודיע שהיא "יורדת" מ-BTRFS בגירסאות הבאות של הפצת הלינוקס שלה (בינתיים שאר ההפצות ממשיכות לתמוך ב-BTRFS, וזו מערכת עיקרית בהפצות כמו SuSE).

נשמע כמו צעד די דרסטי – לא? אכן, רק שבימים האחרונים הסתבר מדוע רד-האט עשתה זאת. רד-האט רכשה חברה קטנה בשם Permabit ש.. מציעה בדיוק את השרותים שה-Enterprise צריך: דחיסה, Dedupe, thin provisioning וכו'. האם רד-האט תציע זאת בחינם לקהל הרחב? כן, אבל יקח זמן. במילים אחרות, במקום לחכות ש-BTRFS יבשיל, רד-האט העדיפה לקנות חברה וטכנולוגיה. במקביל הודיעה רד-האט שהם החלו פרויקט חדש שנקרא Stratis שיאפשר לבצע חלק מהדברים בצורה קלה ופשוטה. אל תחזיקו את נשימתכם, לפרויקט יקח כמה שנים עד שיהיו פירות וניתן יהיה להשתמש בו בצורה בטוחה.

לסיכום: כיום ב-8 מתוך 10 מקרים, כשמקימים מכונת לינוקס, מקימים אותה כ-VM. לא צריך RAID ב-VM (אבל כן צריך LVM אם תרצו להגדיל דיסק או להוסיף דיסק ל-VM) ו-snapshots ניתן לעשות ברמת VM – ועדיין, עקב כל מיני החלטות שאני קורא להן "פוליטיות" הפצות רשמיות עדיין לא כוללות (גם בגרסאות המסחריות) דברים ש-Enterprise צריכים כשמקימים מערכת עם דיסקים מקומיים. הרכישה ש-רד האט ביצעה מסייעת במשהו, אבל אם רד-האט היתה עושה צעדים לפני מס' שנים כדי לסגור עיסקה עם אורקל, אז היינו כיום עם מערכת כמו ZFS שנותנת את הדברים שאותם לקוחות חשובים צריכים, במיוחד במקומות שמעוניינים להרים Software defined storage בשיטה של Scale Up.

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

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

על דחיית פרוייקטים והמחיר הכרוך בכך

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

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

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

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

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

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

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

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

לכן, במידה ובוחרים כל דבר שקשור לתשתיות, פלטפורמה, או כלי עבודה שונים, בין אם הם מבוססי קוד פתוח או סגור (ההמלצה שלי תמיד היא לעבוד עם כלי שמבוסס קוד פתוח) – היא לראות האם ב-Road Map של החברה יש שדרוגים ומעבר לטכנולוגיות ומתודות עדכניות. חברה כמו VMWare לדוגמא "פספסה מעט את הרכבת" בכל הקשור לקונטיינרים ו-OpenStack, אבל גירסה 7 שתצא בהמשך תתן יכולות להרצת קונטיינרים ותמשיך לשפר את ה-VMware Integrated OpenStack שלהם. גם חברה כמו Red Hat שהבינה שקונטיינרים הולכים להיות ה"בון טון" זרקה בגירסה 3 את כל הטכנולגיה של ה-Cartridges שלהם לטובת קונטיינרים וכיום הם מפתחים לגירסה הקרובה עבודה מלאה מול שרתי Windows Server 2016 ועושה את החיים הרבה יותר קלים לשימוש בפונקציות מסויימות ע"י אימוץ kompose.io לדוגמא. לעומת זאת, חברה מסויימת מאוד גדולה וידועה (שלא אציין את שמה אך כל איש IT מכיר אותה) מציגה את עצמה כחברה עם שרותי ענן "מתקדמים" וכל מה שמקבלים כשנרשמים – הם תשתיות כאילו אנחנו נמצאים בשנת 2010 (ולסקרנים מביניכם – לא, אינני מדבר על מיקרוסופט..)

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

מעבר לעננים – מבחינה כספית (מאמר עדכון)

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

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

כלומר המצב הקלאסי של היום מבחינת תשתית IT אינו מתאים כל כך למעבר לענן. אם אתם כמובן רק רוצים להעביר כמה מכונות VM בשביל אתרים שיווקיים ועוד כמה דברים שיכולים להיות "בחוץ" – אז אני ממליץ לכם לבחור ב-Digital Ocean (הנה קופון של 10$ מתנה להתחלה מבלי להתחייב). עם המכונות ב-Digital Ocean אינכם משלמים עבור תעבורה מעבר לשימוש רגיל (כל מכונה מגיעה עם כמות תעבורה חודשית מכובדת לכל הדעות), אתם יכולים להוסיף דיסק קשיח בגדלים שאתם רוצים, והמכונות די מהירות ויציבות ומה שהכי חשוב – המחיר ידוע לכם מראש, כך שסביר להניח שתוכלו להעביר חלק מהתשתית לשם ללא הפתעות כספיות.

לגבי שאר המכונות, אם רוצים להעביר לענן, הדבר הראשון עוד לפני שבכלל בוחרים ספק אינטרנט, הוא למדוד כמה משאבים האפליקציות באמת צריכות. נניח ויש לכם אפליקציית JAVA או דוט נט והגדרתם VM עם 2 ליבות ו-16 ג'יגהבייט זכרון. השתמשו בכלים הסטטיסטיים של הוירטואליזציה כדי "לחפור" בהיסטריה של אותו VM האם באמת יש שימוש ב-2 ליבות וב-16 ג'יגהבייט זכרון או שאולי מכונה זו לדוגמא יכולה להסתפק בליבה אחת ו-8 ג'יגהבייט זכרון.

דוגמא נוספת: אפליקציות כמו שרתי Web שפותחים עשרות או מאות תתי-תהליכים בהתאם לכמות החיבורים. נניח שבניתם שרת Web גדול שיקבל כמות גדולה של משתמשים כדי להפעיל אפליקציית Web שהם צריכים ויצרתם לכך 2 מכונות עם 8 ליבות וירטואליות ו-32 ג'יגהבייט זכרון בכל אחת מהמכונות. האם פתרון של 4 מכונות קטנות יותר (2 ליבות ו-8 ג'יגה זכרון) כשמאחוריהן עומד Load Balancer יהיה יעיל יותר? מבחינת עבודה בתשתית ענן, 4 מכונות קטנות עולות פחות מ-2 מכונות גדולות. באמזון לדוגמא, 4 מכונות בגודל כפי שתיארתי לעיל יעלו לכם $319 ואילו 2 מכונות גדולות כפי שתיארתי לעיל יעלו לכם $631, כלומר כמעט כפול (לא כולל דיסק, Snapshots, תעבורה וכו'). גם אם נגדיל ל-6 מכונות קטנות, עדיין המחיר יצא יותר זול מ-2 מכונות גדולות.

עוד נקודה קריטית לפני מעבר לענן היא הצורך לשנות את צורת העבודה כך שבעצם האפליקציה שתרוץ תהיה החשובה והשרת והתשתית יהיו פחות חשובים. כך לדוגמא אם יש לנו אפליקציה שצריכה לקבל כמות משתנה של משתמשים שהכמות קטנה בזמנים מסויימים ומאוד גדולה בזמנים אחרים – במקרים כאלו כדאי לחשוב על העברת האפליקציה לקונטיינרים ושימוש בתשתית קונטיינריזציה בענן (ECS באמזון, GKE בגוגל או OpenShift אם אתם רוצים להריץ משלכם משהו שיותר מתאים ל-Enterprise). בעזרת תשתית זו ניתן להוסיף אוטומטית קונטיינרים משוכפלים ומכונות נוספות (שיארחו את הקונטיינרים) וכמות הקונטיינרים והמכונות תרד אוטומטית בהתאם לכמות המשתמשים באותו זמן (כמובן שניתן להגביל את כמות המכונות שיתווספו, אם לדוגמא משהו קורה שיוצר תעבורה מזוייפת, עקב תקלות וכו'). לאלו שלא רוצים קונטיינרים או לא יכולים (קוד שרץ על Windows בלבד שלא בנוי לעבוד על קונטיינר או שהחברה לא רוצה לעבור ל-Windows Server 2016) – אפשר להקים מכונות (Instances) שישוכפלו דרך מתודת AutoScale לפי כמות המשתמשים שמתחברים או לפי כמות המשאבים שנצרכים – כך שקונטיינרים או מכונות (בהתאם לסיטואציה) הן תמיד זהות וה-Data האמיתי מגיע מבחוץ (NFS או אחסון שיתופי אחר לדוגמא).

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

ומה לגבי סטורג'? בניגוד לסטורג' שיש אצלכם בחברה, אצל ספקי ענן אין "סטורג'" באותו מובן. ישנו File או Block Storage שאתם קונים למכונות לפי גודל שאתם רוצים, לפי IOPS שאתם מבקשים (בזהירות – בחירה לא נכונה של סוג אחסון תפציץ לכם את החשבון באלפי או עשרות אלפי דולרים!). אם יש לכם אלפי קבצים סטטיים, אפשר להשתמש ב-S3 (יש כזה לא רק לאמזון, אלא גם למיקרוסופט ולגוגל) לאחסן שם את הקבצים וכמובן אפשר לשמור לשם גיבויים, (אם כי S3 אינו File Storage רגיל עם הרשאות שיש ל-NTFS/CIFS, חשוב לזכור). ככלל, בענן מומלץ יותר לבנות לקבוצות שרתים "מיני סטורג'" משותף בינם מאשר לנסות לעשות זאת על Block Storage ענקי – זה גם יצא זול בהרבה.

נקודה נוספת שמתאימה לחברות גדולות שיש בהן תשתית ענן פרטי והן רוצות לשלב חלק מהתשתית בענן ציבורי והתקציב שלהן בנוי כך שמחלקת המחשוב מחייבת מחלקות אחרות – כדאי יהיה לכלול בתקציב מערכת CMP (או Cloud Management Platform). הסיבה לכך היא פשוטה: כשמתחילים להשתמש ב-AutoScale לגדילה דינמית, יהיה קשה לחשב כמות משאבים פר שרת, הואיל וברגע אחד לאפליקציה של מחלקה מסויימת יש 2 שרתים ולאחר שעתיים יש 20 שרתים. מערכת CMP טובה (המלצתי כאן בעבר על CloudForms) תדע לא רק לחשב את הדברים אוטומטית, אלא גם ניתן יהיה לבנות דרכה את כל תהליך הבקשה, אישורים ובניית המכונה ללא צורך בלימוד שפה סגורה או כלים סגורים (שלא בטוח אם מחר זה יהיה קיים.. תראו מה קרה ל-vCloud Air לדוגמא).

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

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

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

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

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

שבוע טוב 🙂