כמה מילים על VMWare on AWS

(תודה לניצן וייסברג שהעיר את תשומת ליבי לגבי השרות החדש)

בכנס Re:Invent האחרון של אמזון, חברת VMWare הכריזה על שרות חדש בשיתוף אמזון שנקרא VMWare on AWS – שרות שנותן לך להרים SDDC (כלומר Software Defined Data Center). עם שרות זה, הלקוח מקבל מינימום 4 שרתים פיזיים שמותקנים עליהם ESXI יחד עם VSAN ו-NSX וכמובן כל השרותים של vSphere שמגיעים ברשיון Enterprise Plus. הלכתי לקרוא בכמה מקומות על השרות ולהלן התרשמותי:

מבחינת המכונות – אין מה לאמר, מפלצות אחת אחת. בכל מכונה תקבל 36 ליבות (מהמעבדים האחרונים – Xeon-SP של אינטל), 512 ג'יגהבייט זכרון, ו-8 דיסקים SSD NVME (כל אחד בגודל של 2 טרה, כאשר 2 מתוכם משמשים כ-Cache, כך שמבחינת Storage בחישוב כולל, יש לך בערך 20 טרהבייט, לפי הדף באתר של אמזון) והרשת היא ברוחב פס רציני של 25 ג'יגהביט. אין מה לאמר – הלוואי על כולנו!

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

איך נאמר בפרסומת: סבבה אגוזים!

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

הכל טוב ויפה, עד שמגיעים … למחיר, וכפי שאתם יכולים להסתכל על מפרט הברזלים לעיל – זול זה לא הולך להיות!

המחיר מתחיל ב-8.3681 דולר לשעה פר ברזל ומכיוון שצריך מינימום 4 ברזלים (אי אפשר פחות), אז אנחנו מדברים על 33.47 דולר לשעה. נכפיל ב-720 שעות לחודש ונגיע ל-24,100 דולר לחודש, או 289,201 דולר לשנה. המחיר כמובן לא נגמר פה, על כך יש להוסיף מחיר תעבורה מהתשתית של אמזון החוצה (רוצים להתחבר ב-Remote? להוריד VM לארץ? להוריד DATA לארץ? סינכרוניזציה או רפליקציה בין VMים משם לכאן? אז תוסיפו בבקשה, 5 סנט פר ג'יגהבייט) וכרגע אם אתם רוצים Latency נמוך, אתם יכולים לשכוח מזה – בשלב זה השרות זמין בצפון אמריקה בלבד (אלא אם יש לכם קו יעודי לארה"ב, שזה סיפור אחר כמובן).

רוצים הנחה? בשמחה! תתחייבו לשנה מראש, ותשלמו פר הוסט סכום של 51,987 דולר, נכפיל ב-4 וכך נרד למחיר "מציאה" של 208,000 דולר לערך או 437,464 דולר בהתחייבות ל-3 שנים. אין שוטף+30 או 60, זה תשלום מיידי ואין אפשרות לצאת מהמחויבות באמצע התקופה.

אבל בואו נעזוב את המחיר. יש לא מעט חברות גדולות מאוד ששרפו מיליוני דולרים באגפי המחשוב בצעדים תמוהים (אל תאמינו לי, תראו מה קרה עם 600 מיליון שקל וביטוח לאומי) שבשבילם Money is not a object ואין להם בעיה להוציא מאות אלפי דולרים בשנה – האם להם זה שווה?

מבחינה טכנית גרידא, התשובה היא לא רבתי, מהסיבות הבאות:

  • השרידות היא אשלייתית. באמזון לדוגמא, אם תשתמש בשרות Aurura להקים שרות MySQL, אתה מגדיר שם Availability Zone, כלומר השרות שיוקם עבורך מבוזר על פני שרתים שנמצאים ב-Zones שונים שנמצאים באותו Region, כך שאם Zone נופל (הנה דוגמא) אז Zone אחר תופס פיקוד ואתה אפילו לא מרגיש נפילה. עם השרות החדש הזה – כל השרתים שלך נמצאים באותו Zone, ואם ה-Zone נופל, הכל נופל בתשתית המרוחקת. מעבר לכך, לא ניתן לפרוס את ה-Hosts על פני Regions שונים של אמזון (אם כי ניתן להקים SDDC שונים ב-Regions שונים, אך כרגע רק בצפון אמריקה).
  • גדילה של Storage היא בעייתית בהשוואה למחיר. זה שתוסיף עוד Host לא תקבל עוד 20 טרה אחסון, אלא סביר להניח שתקבל בערך 5 טרהבייט נטו (הסיבה לכך שעם VSAN, ה-DATA של מכונות ה-VM או DATA שאתה מייצא כ-iSCSI החוצה – מתרפלק בין המכונות כולן, כך שאם מכונה אחת נופלת, ה-Cluster ממשיך לעבוד כי ה-DATA נמצא. אפשר לעשות את החישובים כאן). הדבר המוזר בכל השרות הזה הוא שלא ניתן לחבר EBS מסוג io1 (או כל סוג EBS) כ-Datastore לתשתית.
  • חייבים 4 מכונות, למרות ש-VSAN יכול לעבוד גם בתצורות של 2 ו-3 מכונות פיזיות.

אבל שוב, אם יש לחברה את התקציבים, יש גם יתרונות:

  • הקמה של SDDC מלא עם מכונות מאוד חזקות בשעות ספורות במקום לבזבז מס' חודשים על בדיקת הצעות מחיר, ישיבות תקציב, הזמנות, הגעת ציוד, הגדרות והכנה לעבודה.
  • גדילה של התשתית הרחוקה תוך דקות ספורות. צריך עוד 2 ברזלים? זה יקח מס' דקות והברזלים יהיו מחוברים לתשתית ה-SDDC שלך. Host נפל? לא נורא, תוך דקות תקום מכונה אחרת ואתה יכול לגדול ל-עד 32 מכונות פיזיות (כרגע).
  • עבודה שקופה – מנהלי תשתית ה-vSphere שלך יכולים להקים מכונות פה או שם (או פה ושם) בצורה מהירה, מבלי להכיר לעומק איך לעבוד עם AWS (למעט החלק הראשוני של הקמת ה-SDDC).
  • גיבויים – הקץ ל"אין מקום לגבות". עובדים עם Veeam? מעכשיו תוכלו להשתמש באמולציית ה-VTL שלו ולגבות ל-S3 של אמזון. גם זול, גם שרידות סופר גבוהה, וזה תמיד זמין. (כעקרון אפשר לעבוד עם כל תוכנת גיבוי שיודעת לעבוד עם S3).
  • אחריות ושרות – אתה מקבל ניהול תשתית ומענה לכל בעיה ישירות מ-VMWare.
  • תשלום פר שימוש – אפשר לנסות את זה לכמה שעות או כמה ימים מבלי להתחייב על כלום ולשלם רק על השעות שניצלת.

לסיכום: אם בחברה שלכם יש תקציבים כמו מים זורמים, ואתם משתמשים בתשתית vSphere, אז בהחלט כדאי להסתכל בהצעה החדשה של אמזון/VMware. אם לעומת זאת כל שרת נרכש אצלכם בדם-ויזע, אז עדיף לוותר על השרות ומבחינה כספית – יהיה יותר זול לרכוש שרתים חזקים + רשיונות ולהכניס אותם ל-Data Center שלכם או באחת החוות של ספקי האינטרנט.

על תשתיות IT והקמת פרויקטים מבוססי לינוקס ב-Enterprise

נניח שאתם שוכרים את שרותי להקמת שרת אפליקציה לינוקסי כלשהו. לא חשוב מהי האפליקציה. סביר להניח שאקבל מכונת VM כלשהי עם הפצת לינוקס שאתם עובדים עליה. ברוב המקרים, סביר להניח שאני אצטרך חיבור אינטרנט כדי להוריד חבילות נוספות מעבר למה שקיים ב-ISO image של הפצת הלינוקס שבחרתם. לפעמים זה חבילה או 2 ולפעמים – מאות חבילות. לבקש שיורידו לי חבילה X זה לא פתרון כי לכל חבילה יש חבילות שכנות שנקראות "תלויות" (Dependencies), כך שלשם ביצוע המשימה, אני צריך את החיבור לאינטרנט, ולפעמים גם ביטול זמני של DLM ודברים כאלו שלא מאפשרים לחבילות בלינוקס לרדת.

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

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

בלינוקס, ולא חשוב איזו הפצת לינוקס, עניין החבילות שונה לחלוטין מ-Windows (אם כי ב-Windows השינויים בחבילות גם נכנסים לאט, כמו חבילות שמתקינים עם Powershell). מאגרי חבילות לדוגמא במקרים רבים לא יורדים מאיזה שרת ספציפי מסוים בחו"ל. במקרים רבים, פקודת ההורדה (yum ב-CentOS או Red Hat לדוגמא) דוגמת מהירת גישה ממספר שרתים שונים באינטרנט וגם במהלך ההורדה, אם לדוגמא חבילה מסויימת לא קיימת בשרת מסוים, ההתקנה אוטומטית "קופצת" לשרת אחר (בכתובת שונה) ומורידה את החבילות משם. אם תרצו לאחר יותר מיומיים שוב להוריד חבילות, מערכת ההתקנה שוב תדגום מהירות של מספר שרתים ויכול להיות שתבחר שרת mirror אחר כדי להוריד, כך שפתיחה ב-Firewall לכתובת URL אחת לא תסייע, מה עוד שבמקרים רבים כתובת ה-URL משתנה עם redirect ואז שוב ה-Firewall חוסם.

אז כן, הפצות לינוקס ו-Firewall בכל הקשור להתקנת חבילות – הם לא החברים הכי טובים.

מה ניתן לעשות?

ההמלצה שלי לחברות גדולות זה להקים שרת (אפשר גם שרת ישן וגם דסקטופ עם מעבד i3 יספיק עם 4 ג'יגהבייט זכרון, כל עוד מדובר על עשרות מכונות VM שיקבלו את החבילות) עם 2-3 דיסקים גדולים (SATA פשוטים של 4-8 טרהבייט, לא צריך Enterprise) ב-RAID 1 ועם 2 חיבורי רשת, רגל אחת תהיה מחוברת החוצה ורגל אחת פנימה. השרת שנקים יהיה בעצם שרת Mirror פנימי לחברה עצמה, ובשרת נריץ מספר סקריפטים שיתחברו אחת ליום לכל מיני מאגרי חבילות ויקבלו את כל החבילות של אותה הפצת לינוקס לגרסאותיה השונות. השרת מתעדכן מדי יום (לעיתים פעמיים ביום) בחבילות וכל החבילות של ההפצות יורדות ומסונכרנות עם שרת Mirror אחר או שרת Master.

אחרי שהקמנו את השרת הזה, נגדיר את השרתים הפנימיים שלנו לקבל עדכונים רק משרת ה-Mirror הפנימי שלנו (כמובן, אם יש בחברה אלפי שרתי לינוקס, PC פשוט לא יספיק ויכול להיות שיהיה צורך להקים זאת על מספר מכונות VM כאשר כל המכונות מקבלות את הקבצים משיתוף NFS ויהיה Load Balancer שיפנה את הדרישות למכונות השונות). כל החבילות חתומות כך שזה יכול לשמח את מחלקת אבטחת המידע.

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

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

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

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