מעכשיו – יש גם מכירות

במחירים כאלו – אין לנו כל כוונה לרכוש את המוצר!

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

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

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

עברו 48 שעות ואותו מנמ"ר מרים אליי טלפון. ה-PoC שהוא חשב עליו? מבוטל. מדוע? הצעות המחיר שהוא קיבל היו לדבריו "מבהילות" והוא לא מוכן לשלם מחירים כאלו. מכיוון שאני מכיר מחירים, ביקשתי שישלח לי את ההצעות במייל, אולי יש כאן אי הבנה של איזה איש מכירות או משהו. קיבלתי את ההצעות ומכיוון שאני מכיר את המחירים של יצרן התוכנה – חשכו עיניי. קודם כל שהיו חסרים חלקים שגם עולים בתשלום אבל גם כך – הצעות המחיר היו בין 180 ל-250 אחוז מהמחיר שהיצרן מבקש וההצעות לא כללו מחירים נוספים הכוללים התקנה/אינטגרציה וכו'. פשוט קובץ ISO ומספרים סריאליים פר שרת.

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

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

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

אז החל מהיום, אם אתם מחפשים מוצרים ופתרונות של רד-האט או SuSE, "חץ ביז" הוא פרטנר רשמי של 2 החברות ואתם מוזמנים ליצור קשר

 

תכירו את Open Shift

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

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

אם נסתכל בתשתית ה-Corporate במחלקות הפיתוח לדוגמא, נמצא במקרים שרת SCM כמו GIT (או SVN, מרקיוריאל ואפילו רחמנא ליצלן .. CVS וכו'), אלו שהחלו להיכנס לעולם ה-CI/CD הקימו בוודאי שרת Jenkins ואולי כמה Slaves, אם החברה מפתחת ב-JAVA אז יש בוודאי איזה שרת Nexus, בנוסף ישנם מספר שרתים שמריצים אפליקציות Web, שרת Apache או NGINX (או IIS). הכל רץ טוב ויפה (כשזה רץ…), אבל כשצריך להגדיל את התשתית, מישהו יצטרך לחפש כדורים נגד כאבי ראש עם כל הבירוקרטיה שיש ב-Corporate.

עם Open Shift הדברים שונים. Open Shift (שאגב, היא מערכת PAAS לכל דבר ועניין!) משתמשת בקונטיינרים כדי להריץ את מה שאתה צריך כשכל דבר רץ בקונטיינר נפרד. יש לך אפליקציה ב-PHP שצריכה לכתוב ל-MySQL? כמה קליקים ויש לך 2 קונטיינרים, תוסיף Route ושתיהם מדברים אחד עם השני, שתיהם לא צריכים לשם טסטים לדוגמא להיות עם יותר מ-1 ג'יגה זכרון (סה"כ ל-2 הקונטיינרים) ושתיהם יחד לא יצטרכו יותר מליבה אחת של המעבד בשרת וזה ירוץ מעולה תחת POD יחיד (POD זו ההגדרה של מספר קונטיינרים שרצים בקבוצה). רוצים לגדול עם האפליקציית PHP? שתי קליקים עם העכבר בממשק ה-WEB ותוך שניות ספורות יש עוד קונטיינרים שמוכנים לקבל גולשים, ולא – אתה לא צריך לשבור את הראש על Routing, על Load Balancing וכו' – בתוך Open Shift יש את Kubernetes שעושה את העבודה לבד ברקע. כך גם אם קונטיינר מסוים יפול, המערכת תרים מיידית קונטיינר נוסף תוך שניות ספורות (במקום לחכות כמה דקות עד שיקום VM עם כל התהליכים שהוא צריך לאתחל) והמערכת יכולה להמשיך לתת שרות.

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

אז איך בעצם זה עובד? הנה תהליך עבודה פשוט לדוגמא:

מפתח כותב קוד ובודק אותו מקומית. לאחר שהוא מרוצה מהקוד, הוא "דוחף" אותו ל-SCM של החברה ואז מערכת ה-CI/CD נכנסת לפעולה (אם זה פרויקט קיים), מקמפלת את הקוד, מריצה בדיקות או מה שמוגדר ב-Pipeline ולסיום היא פונה ל-Open Shift. ה-Open Shift לוקח את הקבצים הבינאריים (Artifacts לדוגמא) ובונה מהם יחד עם הדברים שצריך (סביבת ריצה וכו') קונטיינר והמערכת מפעילה את הקונטיינר. המפתח יכול לקבל הודעה במייל שהכל מוכן וכשהוא נכנס לפורטל של Open Shift, יש URL שלחיצה עליו תעביר את המפתח לאתר שהקונטיינר מריץ. עכשיו המפתח יכול להוסיף תכונות, לתקן וכו' – והכל חוזר מחדש. מפתחים בד"כ לא עובדים לבד – והמערכת תומכת בקבוצות כך שמפתחים יכולים לעבוד יחדיו על אותו פרויקט.

צריך להריץ Deployment בשיטות כמו Blue-Green או AB? שתי השיטות נתמכות.

אחרי שהקוד מוכן, נרצה להריץ אותו בפרודקשן. מה אז?

כאן מגיע יתרון גדול של Open Shift. לא משנה איזו תשתית וירטואליזציה יש לך, תהיה הפופולרית ביותר או אזוטרית ביותר, בין אם זה מקומית או בענן פרטי או ציבורי – Open Shift תרוץ. כל מה שאתה צריך זה מספר מכונות VM (או ברזלים פיזיים) ו-Subnet כתובות פרטי וציבורי. מה שנשאר לך לעשות זה להקים Open Shift במכונה אחת (או כאשכול), "לשדך" את שאר מכונות ה-VM שיריצו מערכת Atomic Host (זו גירסת לינוקס מאוד מצומצמת שנועדה להריץ קונטיינרים) ומשם לקמפל את הגירסה היציבה ולהריץ אותה עם רפליקציה. מערכת ה-Kubernetes הפנימית תדע להפיץ את הקונטיינרים בין מכונות ה-VM (וכן, יש גם Auto Scaling ו-HA) ואם אתם מריצים את זה בענן, שרות ה-Load Balancer ידע להעביר את התעבורה ל-IP חיצוני (לא צריך ציוד יעודי יותר בתוך החברה שיעשה LB). קונטיינר נופל? VM נופל? המערכת תדע להתאושש לבד.

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

עד כה כל הטכנולוגיה שדיברתי עליה מדברת על הרצת דברים שכתובים ללינוקס, אבל מה עם אלו שכותבים ב-DotNet? ובכן, מאז שמיקרוסופט ורד-האט חתמו על הסכמי שת"פ, האהבה פורחת ביניהם וכיום ניתן לקחת אפליקציות שכתובות ב- #C עם DotNet ולבנות אותן על לינוקס ולהרים קונטיינר כזה. בשלב זה טכנולוגיות הקונטיינרים של מיקרוסופט עדיין לא עובדת ישירות טוב עם Open Shift אבל אפשר לבנות להריץ אפליקציות כפי שציינתי. אגב, ניתן לשלוט על Open Shift בעזרת ה-CLI גם מתוך Windows (כל מה שצריך זה להתקין Ruby, Git ולהריץ מספר קטן של פקודות).

להלן הדגמה של ASP שרץ עם Open Shift:

הוידאו הבא ידגים איך מקימים מערכת CI/CD מלאה יחד עם Open Shift:

ומה לגבי הטמעת מערכת כזו בחברה?

גם כאן, כמו ב-CloudForms/ManageIQ ישנם מספר גרסאות:

  • יש גירסה שרצה על הענן של רד-האט ומשלמים Pay As you Go, בין אם ב-VM או בברזלים נפרדים.
  • יש גירסת קוד פתוח (גירסה שמהנדסי רד-האט מפתחים, יכולים לצוץ באגים!) שנקראת Open Shift Origin.
  • וישנה גירסת ה-Open Shift Enterprise בתשלום עם תמיכה לשנה או 3 שנים במסלולים שונים.

מבחינת הטמעה וקאסטומיזציה – זה מאוד תלוי בחברה ובדרישות. הקוד של Open Shift כתוב ב-GO.

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

לסיכום: קונטיינרים יכולים לחסוך הקמת VM מרובים ותחזוקתם. מערכת Open Shift יכולה להקל בצורה רצינית על כל תהליך הקמת סביבות הרצת טסטים, פרודקשן, ועוד. בכל מה שקשור למעבר לענן, Open Shift מקלה על בחירת ספקי ענן ובמקביל מגדילה את המבחר ספקים (כך לדוגמא אפשר להשתמש בספק כמו Digital Ocean עם מכונות במחירים זולים בהרבה מספקי ענן ציבורי ובמקרים רבים החבילה תכלול מספיק תעבורה כך שלא תצטרכו לשלם על כך בנוסף!)

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

כמה מילים על פרסום בעיתון

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

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

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

pconתחקיר מס' 1271 שיוצא היום למנויי PCON ("הוירטואליזציה פורצת ומתפשטת"), מכיל את הטקסט שבתמונה משמאל.

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

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

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

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

מדוע? הסיבה מחולקת למספר נקודות:

  1. אף ספק ענן ציבורי עוד לא הקים "אזור" (Region) בישראל (ולמען האמת לא נראה לי שזה גם יקרה בקרוב – אנחנו פשוט קטנים מדי בשבילם) מה שאומר שהמיקום הכי קרוב גיאוגרפית לשרתים יהיה בבריטניה או באירופה (אמסטרדם, פרנקפורט) ובהתחשב ב-Latency הנודע לשמצה של הקווים מישראל לחו"ל, מדובר על תוספת LAG המוערכת בין 70-140 מילישניות. ספרו את זה למנמ"ר של Corporate ממוצע ותראו איך הוא מיד מבטל אפילו מחשבות על מעבר לענן ציבורי כזה.
  2. מחיר מטורף: אם ניקח Corporate ממוצע שיש בו כמה מאות VM וננסה איכשהו להעביר אותם כמו שהם לענן ציבורי, החשבונית הראשונה שתתקבל תגרום לצעקות היסטריות בחברה, ואת זה אני יכול להבטיח. שום ענן ציבורי אינו בנוי כעוד חברת Hosting שמוכרת לרוב שרתי VPS או משכירה שרתים. בשרותי ענן העניין הוא להשתמש בשרותים שאותו ספק ענן מציע – בין אם זה DNS, SQL, או עוד כמה מאות שרותים נוספים, וה-VM (או ה-Compute) הוא עוד אחד מהשירותים וכשמשתמשים בשרותים שהספק מציע, ואז אתה מגלה שבמקרים רבים אתה צריך VM יותר קטן או שאתה יכול לפזר בין כמה שרותי VM קטנים או שאתה יכול לוותר על חלק מה-VM, כך שבמציאות אי אפשר סתם כך להעביר כמה מאות VM ולמכור את השרתים הפיזיים שיש בחברה מבלי לשלם מחיר מאוד גבוה.
  3. פחדים ורגולציות: קשה מאוד לחברות לקבל שכל ה-DATA הקריטי (ובמקרים רבים כולל סודות מסחריים ותכנים שלא אמורים לצאת החוצה כמו מיילים, פרזנטציות, קוד וכו') יושב באיזה ענן ציבורי מעבר לים, כך שהם חוששים. בנוסף, מוסדות שונים אינם יכולים להוציא DATA מחוץ לישראל עקב הסכמים ואיסורים שונים, כך שמבחינתם כל עניין המעבר הוא No Go.

ישנה שמרנות ב-Corporate לאמץ טכנולוגיות שאינן בדיוק Mainstream. כך לדוגמא כמות החברות שאימצו את OpenStack בארץ אינה גדולה למרות שזו פלטפורמה שיכולה להיות "מתחרה" או משלימה עם פלטפורמת הוירטואליזציה שיש ב-Corporate. ל-OpenStack אין בעיה להציע שרות Compute לדוגמא משלו (KVM, XEN) אבל אין לו בעיה לעבוד עם VMWare או Hyper-V שנמצאים בחברה, הכל תלוי בתכנון ובמימוש שיעשה. אותו דבר בכל מה שקשור לרשתות התקשורת בחברה (עניין סופר רגיש ב-Corporate) – אפשר לשלב עם תשתית התקשורת ואפשר גם להתחיל לחשוב לעבור ל-NFV עם OpenStack.  (ואם חברה צריכה הפניות או יעוץ בנושא – אפשר ליצור קשר. יש לא מעט גורמים שנותנים שרותי יעוץ, הטמעה, תכנון וכו').

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

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

עבודה כ-Devops

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

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

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

שני הדברים שהכי קובעים בקבלת מועמד לעבודה הם ידע ונסיון. כשאדם לומד מ-ספר או קורס, יהיה עדיין חסר לו בין 50-90% מהידע שחברה צריכה. כך לדוגמא מבחינת Troubleshooting – רוב הקורסים בקושי נוגעים בנושא (וברוב עבודות הסיסטם הזמן שנשרף הוא על תקלות, בין אם זה AD שעושה צרות, SQL שעובד לאט, תקשורת איטית, תקלות ב-1001 שרותים ואפליקציות וכו' – ובלינוקס זה יכול להיות תקלות של ביצועי שרותים, שרת שלא עולה, הרשאות לא נכונות, Segfault של אפליקציות ועוד המון המון סוגי תקלות). בקורסים אולי מלמדים אותך איך להקים מערכות ושירותים – אבל בקושי נוגעים ב-Troubleshooting, ולכן חשוב לבדוק כמה שנות נסיון אמיתיות יש למועמד.

בתחום הסיסטם תמיד כדאי שיהיה לך נסיון בשפת סקריפטים כלשהי. בעולם המיקרוסופט כדאי מאוד שיהיה לך נסיון ב-Powershell וגם ב-Batch. בלינוקס – כדאי מאוד שיהיה לך נסיון לפחות ב-BASH ועדיף גם נסיון ב-Python או PHP, כלומר ידע ונסיון בשפת סקריפטים – חובה. ידע בשפת תכנות אחרות – זה פלוס.

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

כמה רחבה? בניגוד לאיש סיסטם, איש Devops הוא בעצם ה"מכתיב" בכל התחומים שקשורים החל משרתים ועד לפיתוח. כך לדוגמא אם איש סיסטם הכיר Puppet לאוטומציה, איש Devops טוב יצטרך להכיר גם Chef וגם Ansible. הוא לא חייב להכיר אותם עד רמת הבורג, אבל צריך שיהיה לו ידע בהרמה לדוגמא של 2 שרתים, "חיבור" למערכת אוטומציה והתקנת שרות כלשהו, לדוגמא. עניין אחר הוא בשינוי מתודת פיתוח אפליקציות של החברה (במיוחד של חברות שנותנות שרותי SaaS לדוגמא) – בעבר חברות היו מפתחות גירסה 1 ואחר כך היו מתחילים לעבוד על גירסה 1.1 או 2. כיום חברות רבות עוברות לשיטה שבה הפיתוח הוא מתמשך ו"נזרק" מיד לפרודקשן לאחר שהוא מתקמפל ועובר סט בדיקות אוטומטי (מה שנקרא CI או Continuous Integration) ובשביל זה קיימים כלים כמו Jenkins. מי שצריך להרים מערכת CI, לכתוב לה סקריפטים, לכתוב בדיקות וכו' – הוא איש ה-Devops.

עדכון: להלן כמה דברים שאנשי Devops כותבים לגבי הנושא:

יבגני זיסלס כותב: "בוא נתחיל מזה שדבאופס, כפי שהגו האנשים שהכניסו לנו את המושג, זה בכלל לא קשור לכלי כזה או אחר. וזה גם לא ״בן אדם״, ז״א אין דבר כזה ״מהנדס דבאופס״ או ״צוות דבאופס״. אבל כמו כשציינתי, ככה מסתכלים על זה האנשים שהגו את המושג. היום יש גם את כל החברות והציידי ראשים והמחפשי עבודה שכמובן רואים את זה אחרת לגמרי, אבל אני קופץ קדימה מדי.
דבאופס לפי ההגדרה הראשונית, זה עניין של תרבות חברה. וכל הכנסים והפרסומים שמבטיחים שדבאופס יתן כל מני אחוזים ענקיים בשיפור העסק, כל זה מסתמך על השוואה של חברות שיש בהן תרבות דבאופס, לבין אלו שאין. אני מזמין אותך לקרוא את סקר ה-״דבאופס״ שחברת פאפטלאבס הכינו ב-2015 ו-2014, וכאשר אתה קורא את התוצאות שים לב שמדובר בתרבות, לא כלים.
אבל בוא נחזור אל מחפש העבודה הממוצע שחושב לעשות תיקון קריירה ולקרוא לעצמו ״דבאופס״. תתחיל בזה שכנראה הוא, והחברה שרוצה לגייס אותו, לא יועץ או פרילנסר. לכן לא באמת יש סיבה למישהו שעובד בחברה שעושה שימוש בשף, שיהיה לו ידע בסיסי בדברים אחרים. וכמובן גם חברה שמחפשת אנשים עם ידע בשף, לא צריכה את אלה שלא מכירים אותו.
עניין הנסיון הוא באמת משחק תפקיד די גדול אצל מישהו כזה שקורא לעצמו ״דבאופס״, אחרי הכל הכלים שאותו אדם טוען לדעת לא טריוויאליים, ולרוב לא היו בשימוש בעבר בשום מקצוע אחר (לא סיסטם ולא מתכנת ולא הלפדסק ולא בדיקות). אז יש כלי חדש, צריך תווית חדשה, ולמזלנו בדיוק הגיע ה״דבאופס״ הזה, אז למה לא. אבל נסיון בשימוש בכלי הוא שום דבר ליד נסיון בהבנה של מערכות, ויותר חשוב, בהבנה של מערכות של אנשים.
אתה בטח מכיר ארגונים שבהם הפוליטיקה שולטת, אז דמיין בן אדם בארגון כזה שיודע להשיג דברים שהוא רוצה שיקרו כאילו אין שום פוליטיקה … זה מיומנות, גם כאן יש אנשים עם נסיון בזה וכאלה בלי נסיון, וגם זה דוגמא לכלי, לא פחות חשוב משף או ג'נקינס.
קיצור, העליתי כמה נקודות, אבל המאמר בא לחזק בדיוק את הדברים שאנשים בעולם ה״דבאופס״ מנסים להעלים." (יבגני גם ממליץ לקרוא את ה-Agile Manifesto וגם את הקישור הבא)

עמוס שפירא כותב: "…בכלל מזה "איש DevOps"? הרי DevOps זה צורת מבט על כל תהליך הפיתוח (Dev) והרצת שרתים (Ops) כשלבים מאד קשורים אחד לשני, לעומת המודלים הקודמים שבהם אנשי הפיתוח לא יודעים כלום ולא מעניין אותם איך הקוד שלהם רץ בשטח והתפקיד שלהם נגמר כשהם " זורקים את הקוד מעבר לגדר" ("chuck over the fence").
מבחינת אנשי סיסטם (ואני לא בטוח כמה זה קשור ספציפית ל-Devops), איש סיסטם עדכני צריך להבין את החלק שלו בכל התהליך מהגדרת המוצר וכתיבת התוכנה (ששם הוא יכול לתרום בהסבר מראש מה הוא צריך כדי לעשות את החלק שלו) וכן לממש "infrastructure as code", אוטומציה של תהליכים, תמיכה בשרשרת הבניה והבדיקות של התוכנה וכו'." (למעוניינים, ישנו שרשור של אנשי Devops המתייחסים לפוסט זה ואנשי Devops מסבירים מה הוא המקצוע)

איש ה-Devops ברמת המאקרו צריך להכיר המון טכנולוגיות חדשות ועדיף שיהיה לו מבחינת שפות ידע ב-Python, JAVA ואם אפשר – גם RUBY (ולאחרונה מה שנהיה פופולרי – שפת Go של גוגל), אך כאן זה לא נעצר – איש Devops חייב להמשיך להכיר טכנולוגיות חדשות בזמן  העבודה או מחוץ לעבודה. מכיר קונטיינרים? אם לא – תכיר. אתה צריך להרים מכונות VM בצורה אוטומטית? תכיר את Vagrant והרשימה ארוכה ומתארכת כמעט כל יום או כל שבוע. כך לדוגמא בעבר אם היה לך נסיון ב-RDBMS כלשהו (החל מ-MySQL או SQL server של מיקרוסופט או Oracle DB) – כיום חברות רבות מחפשות ידע בשרותי DB שמבוססים NoSQL (כמו MongoDB ואחרים).

ואחד הנושאים הכי חשובים שאיש Devops צריך להכיר ברמה מעולה – הם העננים הציבוריים. פחות ESXI/Xen ויותר אמזון AWS, מיקרוסופט Azure, או גוגל Cloud Computing. כל אחד מהעננים הציבוריים מציע עשרות (ובמקרה של אמזון מאות) שרותים שונים ורוב מוחלט של חברות שמציעים שרותים באינטרנט – מארחות בענן ואותם שרותים שמציעים העננים הציבוריים נגישים דרך API או SDK (ומי ש"בונה" על ממשק GUI של ספק הענן – שיקח בחשבון שבמקרים רבים ה-GUI מספק פונקציונאליות פחותה מה-API) ובשביל להשתמש ב-API או SDK – יש צורך בידע בשפות כמו Python או JAVA ובמקרים מסויימים Javascript וידע ב-JSON לדוגמא.

לסיכום: המקצוע של איש Devops שונה מתפקיד של איש System. הוא כולל את התפקיד של איש סיסטם ולוקח אותו כמה צעדים (די הרבה, למען האמת) קדימה. איש Devops להישאר במצב של לימוד X והלימודים הבאים שלו יהיו שנה הבאה אם בכלל. הוא חייב להשקיע המון בלימודים של דברים חדשים. אלו שהתרגלו לעולם של מיקרוסופט יצטרכו לבצע לעצמם הסבה ללינוקס (מה לעשות, אמזון שולטת בשוק הענן הציבורי), הכרת VI (או emacs, לא nano), הכרת רשת על לינוקס, שרותים, סקריפטים ועוד ועוד.

ולאלו שמתעניינים במיוחד בשורה התחתונה של "כמה מקבלים" – באופן עקרוני, איש Devops מקבל יותר מאיש סיסטם, אבל שוב – תלוי כמה נסיון יש. אפשר להגיע ל-30K+ אם יש לך נסיון עשיר ב-Devops, Linux ונסיון טוב עם שרותי ענן של אמזון לדוגמא.

(גילוי נאות: כותב שרות אלו מציע שרותי Devops כפרילאנסר)

הבעיה עם MySQL והפתרון של אמזון

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

יחסית, MySQL יודע להסתדר די טוב עם כל חומרה שתזרקו לו, החל מ-512 מגהבייט של זכרון ודיסק SATA מכני פשוט ועד מעבדי Xeon E7 עם ליבות מרובים, מאות ג'יגהבייטים של זכרון ודיסקים SSD מבוססים NVMe. תצטרכו כמובן להגדיר דברים מסויימים בקובץ my.cnf, אבל בד"כ איש סיסטם טוב ידע להסתדר עם זה.

הבעיות מתחילות כשאנחנו צריכים להתרחב מבחינת כמות שרתים מעבר לשרת יחיד. מכאן אנחנו עוברים לשיטות כמו Master/Slave, אנחנו יכולים להשתמש ב-Sharding ויש עוד כמה שיטות. לכשזה עובד – הדברים עובדים בצורה טובה… עד שקורה Crash, צריך להשתמש ב-mysqlbinlog והסיפור לוקח זמן. בעיות אחרות יכולות לקרות אם הסינכרון נופל היכן שהוא. שורת הקללות שאיש הסיסטם (או ה-DBA) יפלוט – תהיה ארוכה.

חברות שונות כשגודלות מחליטות מסיבות שונות לעבור לפתרונות מבוססים NoSQL, בין אם זה DynamoDB, או MongoDB ופתרונות אחרים ששם עניין ה-Scalability נבנה בצורה אחרת והוא יכול להתפרס על פני מאות Nodes ויותר ב-Data Centers שונים בעולם. אם תסתכלו כאן לדוגמא, תראו שחברות גדולות מאוד ומפורסמות משתמשות ב-MongoDB והן מרוצות, מאוד.

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

באמזון, חברת הענן הציבורי הגדול בעולם, החליטו בהתחלה להציע את שרות ה-RDS ואחת האופציות העיקריות שם היא MySQL מנוהל. אתה מגדיר בהתחלה אם אתה מעוניין ב-Instance יחיד קטן או שאתה מעוניין בשימוש מספר Availability Zones (כך שתהיה רפליקציה של ה-DATA באזורים שונים ב-Data Center), אתה מחליט על גודל מכונה, כמות אחסון וכמות IOPS (חישוב שאני אישית שונא) ואתה מקבל Instance של MySQL שאמזון מנהלים עבורך. מבחינת חברות שכבר שמות את האפליקציה שלהן בענן – זה פתרון טוב יותר מאשר סתם לשכור מספר Instances ולהתחיל לעשות את כל עבודת ה-MySQL ידנית, אבל עדיין, מבחינת השוואת ביצועים – Instance שאתה תרים על מכונה חזקה מאוד – יהיה יותר מהיר מ-RDS (אם כי כמובן אתה תפסיד הרבה מהפונקציונאליות של RDS ואתה תצטרך לבצע הרבה דברים ש-RDS מבצע לבד).

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

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

לכן באמזון בנו מוצר חדש שנקרא Aurora שבא בעצם לתת פתרונות לכמה דברים:

  • הוא בנוי מהרגע הראשון ל-High Availability. צריך Instance יחיד לבלוג שלך או שה-? חזור ל-RDS עם MySQL.
  • אין יותר הגדרות של Storage וה-Storage הוא אינו חלק מהמכונה. מעתה ה-Storage מנוהל ע"י אמזון והוא גודל דינמית לפי הצרכים של ה-DB שלך עד לגודל מפלצתי של 64TB!
  • היא מהיר הרבה יותר מ-MySQL – פי 3-5.
  • אתה יכול לבצע מיליוני טרנזאקציות בדקה מ-Instance ואם אתה צריך עוד רפליקות, אתה יכול להוסיף עד 15 רפליקות.
  • ה-DB נופל ברפליקה מסויימת? שכח מזה, Aurora מטפל ומנטר לבד הכל.
  • ה-DATA שלך שמור בלא פחות מ-3 עותקים ב-AZ, כך שאם יש לך Crash, השחזור הוא מיידי.
  • יש לך Snapshots ואתה יכול לבחור Snapshot ולהשתמש בה כ-DB עיקרי מיידית.
  • אין לך צורך לנהל כמעט שום דבר, גם עדכוני תוכנה מבוצעים מיידית בזמן שתגדיר במערכת
  • מכונות גדולות – אתה יכול להרים מכונה עם עד 244 ג'יגהבייט זכרון ו-32 ליבות.
  • אפשר תוך מספר קליקים לעבור מ-RDS עם MySQL ל-Aurora

ומה שהכי חשוב: Aurora תואם MySQL 5.6 בתצורת On the wire, כלומר האפליקציה שלך לכשתתחבר אל ה-Instance, תחשוב שמדובר ב-MySQL לכל דבר ועניין.

לכן, הפתרון עם Aurora נותן מעלה טוב מאוד לכל אותן חברות שרוצות להמשיך עם MySQL אבל רוצות לתת פתרון שיכול לעמוד בקצבים גבוהים ובגידול מאסיבי בתוך זמן קצר מאוד (פיקים לדוגמא) וכל זאת מבלי לשבור את הראש על קלאסטרים, Sharding, Master/Slave ועוד הגדרות רבות.

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

יש גם חסרונות:

  • אם גודל ה-Datasize שלך הוא די קטן (כמה אלפים) – Instance שתרים משלך עם 3000 IOPS ירוץ יותר מהר מ-Aurora (אם תשתמש ב-DB חלופי ותואם כמו Percona)
  • ה-Aurora עדיין לא מהיר ברוב המקרים בהשוואה ל-Percona גם ב-Datasize גדול (אתם מוזמנים לקרוא את המאמר שלהם כאן).
  • אם יש לך איש סיסטם בחברה, הוא יכול לבנות פתרון יותר טוב מ-Aurora  בין אם בשימוש Percona או גם MariaDB, עם אחסון בעל IOPS גבוה ובניית שרידות שמורכבת מ-AZ, כך שבשביל חברות כאלו – Aurora לא יתן הרבה.

הדבר היחיד שחסר בזה – איזה Free Tier לשחק איתו 🙂

סוגי מחשוב ענן

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

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

חברות ענן נוספות מוכרות שרות מסוים וזה בעצם המוצר שלהן, הן לא מנסות למכור לך 1001 שרותים אלא אך ורק שרותים במסגרת קטגוריה מסויימת. כך לדוגמא חברת Deserve-IT מציעה שרות DR בתצורה מעניינת: לא חשוב מה ה-Hypervisor שאתם מריצים ב-Corporate שלכם, בין אם זה vSphere או Hyper-V – השרות שלהם יוכל לסייע לך להפעיל במקרה חרום את המכונות שלך מחוץ לתשתית המקומית שלך. (נכון לזמן כתיבת שורות אלו, הם תומכים ב-ESX ו-Hyper-V ובקרוב תהיה תמיכה מול OpenStack).

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

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

עננים: מעבר לענן ושרידות מאוד גבוהה

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

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

מכאן נעבור לחברות שרוצות להעביר את התשתית שלהן לענן: חברות הענן אינן מנסות למכור לכם VM גדולים בזול. הן תמיד תהיינה יותר יקרות מכל ספק אחר שאינו ענן. מה שכן הן מנסות – זה למכור לכם את השירותים שהן מציעות במקום שתרים אותם על השרתים שלך אצל אותו ענן. לדוגמא: צריך SQL כלשהו? (לא חשוב אם זה MySQL או מיקרוסופט SQL או DB של אורקל) כמובן! אז במקום שתרים אחד כזה, אמזון מציעה לך שרות RDS (כן, גם ל-SQL Server וגם לאורקל), וישנם המון סוגי שרותים אחרים שהיתרון שלהם הוא מחיר (יחסית) זול, ושאתה לא צריך לתחזק כלום (ובין כה הם עושים שרות תחזוקה הרבה יותר מקצועי ממה שרבים עושים). אתה תשלם רק על הדברים שתגדיר ותשתמש, אין תשלום מינימום ואין תשלום מראש.

לכן, עם שרותים אלו, כמות ה-VM שתצטרך תצטמצם משמעותית. יכול להיות כמובן שתצטרך VM חזק בשביל שרת אפליקציות שלך, אבל לא תצטרך שרת בכלל עבור DB. יש לך מספר משתמשים גדול? אתה לא צריך קופסאות Load Balancing, אתה פשוט משתמש בשרותים של אותו ספק ענן לביצוע איזון עומסים. מתעקש על חומת אש מה-Brand האהוב עליך? יש לך VM מוכן יחד איתו, בחר, תקים ותשתמש, תשלם פר שעה עליו, ומה שהכי חשוב – אין יותר צורך בתחזוקת חומרה, סוויצ'ים, וכו'. הכל כבר מטופל ולבחירתך מגוון מסלולי תמיכה, כך שגם אם יש תקלות ביום כיפור – יש מי שיענה לך.

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

  • איזו מערכת הפעלה רצה על ה-VM אצלך שאתה רוצה להעביר? כל ספקי הענן הגדולים טוענים כי הם תומכים בכל מערכות ההפעלה. זה נכון בצורה חלקית. רשמית מה שהם מצהירים הוא נכון אולם בתכל'ס אם רוב ה-VM שלך מבוססים לינוקס, אין לך מה לעשות בענן של מיקרוסופט. לך לגוגל או אמזון. אישית, צמחו לי מספיק שערות לבנות מהתמיכת לינוקס של מיקרוסופט.
  • מי נותן לך קרדיט ראשוני (וכמה)? ספקי ענן שונים נותנים קרדיט ראשוני שנע בין כמה מאות דולדרים לכמה אלפי (או עשרות אלפי) דולרים. כמה ספק הענן מוכן לתת לך כדי להתחיל לעבור?
  • ניהול, תחזוקה, הגירה, הגדרות וכו' של השרותים וה-VM אצל ספקי ענן לא מבוצעים בד"כ דרך ממשק GUI אלא דרך כתיבת סקריפטים או אפליקציות תוך שימוש ב-API של ספק הענן. האם הספק תומך בשפות שאנשי ה-IT שלך מכירים או שהם רק יודעים PowerShell והספק מצריך ידע ב-Python/PERL? נכון, ספקי הענן ברוב המקרים נותנים תמיכה גם וגם, אולם ישנם לא מעט עניינים של פתרונות תקלות המצריכות שימוש בשפות ש"חביבים" אצל ספק הענן.
  • מעבר לענן מצריך שינויים מאסיביים בכל תכנון התשתית כולל דברים כמו Storage, Networking ועוד. פה יש לך NetApp/EMC שעליו אתם זורקים הכל, בענן אם תנסה לבצע את אותו טריק, תקבל חשבונית חודשית מבהילה! יש צורך בהפרדה של תכנים סטטיים ודינמיים, אפליקציות ו-VM שצריכים IOPS גבוה וכאלו שיכולים להסתדר עם כל דבר שתזרוק עליהם – לכן חובה לקחת בחישוב השכרת יעוץ/פרילאנסרים שיסייעו לך בתכנון המעבר ולאחר מכן ביישומו.
  • האם לספק הענן יש נציגות טכנית מקומית שנציגיה יכולים להגיע למשרדכם? טלפון/מייל זה טוב, אבל לפעמים פגישה פרונטלית יכולה לסגור קצוות רבים בפגישה אחת.

מכאן נעבור לשרידות: אצל ספק ענן אתה יכול לקבל שרידות גבוהה יותר ממה שאתה מקבל אצל ספק VM/VPS כלשהו. אפשר להשתמש בשרותים שונים כדי להרים VM מוכנים במקרה ויש עומסים פתאומיים (ולשרשר אותם מיידית ל-Load Balancer), והשרתים מתוחזקים בצורה כזו שגם אם VM נופל, הוא מיד קם על מכונה אחרת מיידית ללא צורך בהתערבות ידנית. ככלל, כל ספקי הענן נותנים לך תיעוד איך להקים את האפליקציה שלך/שרות שלך כ-Fault Tolerance.

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

לשם כך מומלץ לחשוב על אחד מהפתרונות הבאים:

  • כל ספק ענן מכובד (במיוחד השלישיה) מציע את השרותים במספר אזורים שונים בעולם. מה שאתם יכולים לעשות הוא להקים את התשתית שלכם בתצורה המינימלית בעוד אזור (Region) עם סינכרון דו כיווני (או רב כיווני, בהתאם לתשתית שלכם) בין האזורים וכל מה שצריך הוא מכונת VM קטנה מאוד שתדגום את האזורים כל הזמן. היה ואזור עיקרי לא מגיב, ה-VM הקטן ישנה את ה-DNS ושאר פרמטרים כדי שלקוחותיכם יקבלו שרות מהאזור המשני שהקמתם. (האזורים מופרדים מבחינת מערכות כך שנפילה באזור 1 אינה משפיעה על אזור 2)
  • ישנן מספר ספריות שונות (כולן בקוד פתוח) המאפשרות לך לעבוד דרכן ולהקים את השרותים שלך אצל יותר מספק ענן יחיד, כך שתוכל לקבל שרידות יוצאת מן הכלל. החסרונות בשיטה זו:
    • אתה צריך לשלם על התעבורת סנכרון בין ספקי הענן
    • ספריות אלו לא תמיד מעודכנות ולעומת זאת ספקי הענן משנים API במקרים רבים כך שהספריה לא כל כך תעזור.
    • יש הרבה יותר עבודה לעשות בהקמה/הגדרות וגם תחזוקה.

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

חג שמח 🙂

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

האם VSAN יכול לשמש כתחליף ל-Storage יעודי?

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

השאלה פשוטה: האם VSAN יכול להחליף פתרון Storage יעודי?

אסביר: במקרים רבים לחברות יש Storage יעודי שנקנה לפני מס' שנים ועלות חידוש חוזה תמיכה/תחזוקה גורמת להרהורים לגבי פתרון חלופי. יש מקרים שה-Storage מגיע ל-End Of Life ויש גם מקרים שמוצאים שמי שהחליט לרכוש Storage החליט להקשיב יותר לנציג השיווק מאשר לבדוק מספרים טכנית לגבי מה ה-Storage יכול להנפיק והתוצאות כרגע לא מספקות.

אם תקשיבו לתשובה מנציגי המכירות של VMWare (או ריסלרים שלהם) אז במקרים רבים התשובה תהיה ש"כן", בוודאי ש-VSAN יכול להחליף קופסת Storage.

החלק שהם לא כל כך ישימו עליו דגש – זה המחיר שצריך לשלם כדי להגיע לביצועים של Storage רציני מודרני מהשנתיים האחרונות. אם לדוגמא יש לך 10 ברזלים ואתה מחפש מקסימום IOPS, תצטרך למלא כל תושבת PCI וכל כניסת SAS ב-SSD מבוססי PCIe או SAS (מה-12 ג'יגהביט) מהקצה העליון כלומר שכל SSD כזה עולה לך כמה אלפי דולרים טובים. כך תקבל באמת מקסימום Performance ומיליוני IOPS אבל אתה כבר מדבר על עשרות אלפי דולרים ומעלה, ובמקרים כאלו, לעיתים הכדאיות הכלכלית נוטה לכיוון הארכת חוזה על ה-Storage הקיים ושדרוגו. אחרי הכל, קל יותר לדחוף מגש SSD, לשדרג/להוסיף SP (כל זה אם האפשרויות קיימות) מאשר להתחיל מאפס.

גם במקרים בהם ה-CEO וה-CTO מחייכים ומוכנים לממן VSAN עם כל הציוד שתיארתי בלינק ועם מילוי כל חור ב-SSD מהקצה הגבוה – ישנה בעיה מהותית אחת.

כפי שאנו יודעים, ב-Corporate טיפוסי במקרים רבים הוירטואליזציה אינה אחידה. פה הכניסו Hyper-V שנשאר כ"ירושה" מה-CTO הקודם שהחליט לעבור לפתרונות מבוססי מיקרוסופט בלבד, שם החבר'ה שמפתחים בלינוקס הכניסו Docker, ובל נשכח כל מיני שרתי ESXi ישנים שקיימים פה ושם כי מישהו הנחית הוראה מגבוה לא לשדרג כי אין יותר דרייברים חדשים לכרטיסים שבתוך ה-ESXi והמערכת עובדת ו"נא לא לנגוע" (כן, ראיתי גם מקרים כאלו). במקרים של Storage רגיל – אין בעיה, לכאן אתה מוציא SMB, לכאן אתה מוציא NFS ולשם אתה מכין כמה LUNs ומייצא כ-iSCSI ונגמרה הבעיה.

אבל VSAN לא יודע לעבוד כך. VSAN מכין Datastore ענק שהוא מיועד עבור ה-VM שרצים ב-hosts שמשתתפים ב-VSAN. יש לך ערימת שרתי ESXi שלא משתתפים ב-VSAN או שהם עם וירטואליזציה אחרת? הפתרון היחיד שיש לך הוא הקמה של VM באשכול השרתים שמשתתפים ב-VSAN ומשם לייצא החוצה CIFS/NFS/iSCSI. כמה זה מהיר וטוב? זה מאוד תלוי מה רץ על ה-VM שמייצא את השרותים הללו החוצה, אבל בכל מקרה אני מהמר שמול Storage מודרני מול VM כזה, ה-Storage המודרני ינצח עם יד קשורה מאחור מכיוון שיש לו הרבה יותר פונקציונאליות ממה ש-VSAN בתוספת ה-VM שמייצא – נותנים. בל נשכח של-VM עם VSAN אין גישה ישירות לבקר או לדיסקים, את זה יש רק ל-VSAN כך שאין לך דברים כמו dedup, tiering וכו'.

היתרון הגדול של VSAN הוא רק כשאתה מריץ ESXi וכל השרתים משתתפים ב-VSAN (אגב, לא חובה "לפוצץ" את כל הברזלים ב-VSAN, אפשר למלא את רובם ולחבר עוד כמה ללא SSD/דיסקים מכניים ואותם שרתים ישמשו כ-Compute Only). אז באותם מקרים אפשר לקבל שרידות מעולה ואין מקרים של "Storage נופל וכל ה-VMs למטה". גם אם שרת פיזי יקרוס אז המכונות VM שרצו עליו יעשו reboot בשרתי ESXi האחרים ואפשר גם להגדיר ש-2-3 שרתים נופלים, אז ה-VM החשוב יעלה במכונה תקינה (מה שנקרא FTT ולזה כמובן יש מחיר מבחינת כמות נמוכה יותר של Free space בדיסקים).

כל מה שתיארתי לעיל מדבר על גירסת VSAN הנוכחית (6.0). ב-VMWare החליטו שעם כל הכבוד לחברה האחות (EMC) – הם יתחרו בשוק ה-Software Defined Storage ואין לי ספק שהם יוסיפו הרבה מאוד פונקציונאליות ל-VSAN כדי לפתור גם את הבעיות שתיארתי לעיל, כך שכדאי לעקוב. כנס VMWorld יתחיל ביום שלישי כך שסביר להניח שביום שני והלאה יצאו הכרזות מצד VMWare ושותפים לגבי גרסאות חדשות למוצרים. אני אפרסם את ההודעות החשובות בפורום VMWare בפייסבוק ואתם מוזמנים להצטרף.

גילוי נאות: הח"מ מספק שרותי הטמעה גם ל-VSAN 🙂

פתרונות קוד פתוח כתחליף ל-Hypervisor מסחרי

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

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

האם קוד פתוח יכול לתת פתרון הולם כתחליף לדברים כמו ESXI?

ישנן לא מעט חברות שחושבות על פתרון כמו Open Stack כתחליף ל-ESXI. הרעיון עצמו על פניו נשמע הגיוני, אחרי הכל Open Stack מאפשר לך גם Network, גם Compute וגם Storage, אבל כשבודקים בפונקציות ההכרחיות שצריכים מה ESXI נותן ומה Open Stack נותן, התוצאות לעיתים מעודדות ולעיתים לא.

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

בנוסף – Open Stack עדיין מתאים לחברות ממש גדולות והוא לא ממש מתאים לחברה שיש לה מספר קטן של שרתים פיזיים.

פתרון אחר הוא Xen שמוכרות חברות שונות כמו Citrix או Oracle או להריץ את הגירסה הפתוחה ב-Xen Project ולחבר לזה את ה-Client של Citrix דרך Windows או להשתמש בכלים אחרים. אם יש לך כמות VM קטנה יחסית, הפתרון הזה יכול לעבוד לא רע בכלל. הפתרון של Citrix דווקא נותן "פייט" לא רע לפתרון של ESXi אבל אם אתה צריך תמיכה – תצטרך לרכוש את המוצר המסחרי.

עוד פתרון שחלק חושבים שיכול לסייע להם (אך הוא לא) הוא KVM. בעקרון KVM הוא בעצם "מנוע" וירטואליזציה, הוא זה שבסופו של דבר גורם ל-VM לפעול. הוא לא יודע ליצור דיסק ל-VM, הוא לא יודע להגדיר שום דבר ל-VM, אתם צריכים להזין לו את כל הדברים ידנית (או דרך סקריפט) ולכן KVM בד"כ לא מומלץ לשימוש "ידני", אלא מומלץ לשימוש בשילוב כלים, לדוגמא virsh שנותן command line לנהל את כל ה-VM או libvirt שזו ספריה שתומכת ב-binding בשפות רבות כך שניתן בשפה החביבה עליך להרים מכונות מבוססות KVM, לכבות, לעשות מיגרציה, ופעולות רבות אחרות.

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

פה נכנס כלי שרד-האט מפתחת שנקרא oVirt. הכלי הזה יודע לנהל יפה שרתים שמריצים את Ovirt Node (שזו גירסת לינוקס מאוד מקוצצת שמותקנת "על הברזל") ומאפשרת פונקציות רבות שקיימות במערכות vSphere. למי שרוצה, יש גם גירסת LIVE שלא מצריכה התקנה, רק להוריד ISO, לעשות Boot ולשחק עם זה (רק כדאי שיהיה מחשב נוסף שישמש כ-Node). גם כאן, אם אתם צריכים תמיכה, תצטרכו את זה מ-רד-האט בתשלום לפי תושבת, או דרך ה-Mailing list / IRC אם אתם בוחרים באופציית החינם. שימו לב ש-oVirt הוא כלי שמצריך השקעה בלימוד.

עוד אופציה שיש בקוד פתוח היא מערכת שנקראת  ProxMox, ודרכה אתה יכול להרים VM, ולבצע ניהול ודברים נוספים. היתרון של Proxmox על פני פתרונות אחרים הוא קלות השימוש בכלי. הוא לא מציע פונקציות רבות כמו oVirt אולם אם יש לכם מספר שרתים קטן והרשת הולכת להיות די פשוטה, Proxmox יכול להוות פתרון לא רע.

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

ולבסוף – הנה קישור שאני מציע לכולם לראות – טבלה המשווה בין הוירטואליזציות השונות.

תחום האחסון בעוד 5 שנים

אני רוצה שנחזור אחורה בזמן (לותיקים מאיתנו) בערך 20 שנה אחורה, לתחילת שנות ה-90. אם היית צריך שרת "עצבני" – היו לך מספר פתרונות, כולם קנייניים – בין אם זה HP-UX, או IBM AIX, או כמובן Solaris של Sun. אם רצית להריץ UNIX טוב על מערכת מבוססת X86, הפתרון המסחרי שהיה לך הוא של SCO ואם חיפשת לחסוך בכך שתלך ל-X86, היית מוצא מהר מאוד שטעות בידך – SCO דרשה בזמנו סכום של בערך $4500 דולר עבור רשיון ל.. TCP/IP, וזה פר שרת. היית יכול כמובן לנסות את גרסאות ה-BSD או את המערכת הצעירה שנקראת Linux, אבל אם היית מראה את זה ב-Corporate, היית מסתכן בצרות. אם היית שואל חברות אחרות על Linux, הן היו אומרות לך שזו מערכת "נחמדה" אבל לא יציבה ולא חזקה ולא תומכת בהרבה דברים וכדאי שתשכח ממנה ותתרכז בפתרון הקנייני שישאר איתך "לשנים רבות" ורק ישתפר.

נחזור חזרה ל-2015, וכיום אם אתה מרים מערכת שאינה Windows, סביר מאוד להניח שהיא תהיה Linux. איפה SCO? נעלמה. איפה AIX או HP-UX? נמצאים במקומות בודדים מסויימים, ושאר מערכות ה-UNIX המסחריות למיניהן מתו. נשארו הגרסאות בקוד פתוח כמו BSD לסוגיו וכמובן הפצות הלינוקס. כיום ב-Corporate (לפחות הבינלאומי, הרבה פחות בישראל) אינו נראה כדבר נורא וחברות למדו לאמץ את מערכת ההפעלה, במיוחד שחברה כמו Red Hat נותנת להם שקט לעשור שנים פר גירסה, והיצרנים מקבלים את ה"הכשר" של Red Hat שה-Corporate מאוד רוצה לראות. יש גם תמיכה 24/7 וגם הגנה נגד תביעות של פטנטים. כיום אם תרצה להכניס Solaris במקום Linux, זה יהיה לך הרבה יותר קשה, כמו שלפני 2 עשורים מאוד היה קשה להכניס Linux.

גם תחום הוירטואליזציה עבר פחות או יותר את אותו מסלול אם כי בפחות זמן. ל-IBM היו פתרונות "וירטואליזציה" עוד משנות ה-70 (DISCO) ולחברות אחרות היו גם פתרונות של "וירטואליזציה" (אתם יכולים לראות רשימה מלאה, אם כי לא עדכנית – המסמך נכתב ב-2004 כאן) כך שחברות שהריצו מערכות MainFrame יכלו להריץ עוד עותקים של אותה מערכת הפעלה כתהליך (Process) עצמאי (פחות או יותר) וב-2004 חברת Sun הציגה את Solaris Container, שנתן פחות או יותר את מה ש-IBM נתנו 30 שנים לפני כן. בערך באותו זמן החלה חברה צעירה בשם VMWare להציע פתרון וירטואליזציה מעניין – בהתחלה בדסקטופ ואחר כך לאט לאט בשרתים – את ה-ESX (שנהפך במשך הזמן למשפחה ענקית [ולפעמים ענקית מדי] של מוצרים).

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

אז עברנו בשנים האחרונות מ-UNIX ל-Linux, ומשרתים פיזיים שמריצים מערכת הפעלה יחידה לשרתים שמריצים מערכת וירטואליזציה ועליהם רצים עשרות או מאות שרתים וירטואליים.

אנחנו נמצאים עכשיו בתקופת מעבר מעט שונה שאני מאמין שתחל להיות מיושמת בשנה שנתיים הקרובות וביתר שאר ב-4-5 שנים הקרובות, והיא – מעבר ל-Storage שאינו "ארון".

אם נסתכל היום על Storage ממוצע, נמצא שהוא מורכב מהרבה "מדפים" (Shelves), אולי מתג לסיב אופטי, (Storage Processor(s (שעושים בעצם את כל העבודה) ואולי עוד כמה מודולים, בהתאם ליצרן ה-Storage, דגם וכו'.

נסו לדמיין את ה-Storage שיש לכם ב-Corporate. ה"מפלצת" הזו, עתירת הטרהבייטים שנותנת שרותי קבצים, NFS, iSCSI ואולי עוד שרותים – היא היא ה"לב" של ה-Data Center והיא מאחסנת את המידע החשוב שלכם. את הדבר הזה אתם צריכים שיהיה הכי יציב שיש. אם זה נופל – שרותים רבים לא יהיה זמינים למשתמשים שלכם. אם יפול לכם מתג (Switch) בחברה, תוכלו להתגבר בכך שתנתבו חלק מהכניסות למתגים אחרים. אם שרת פיזי יפסיק לפעול, אתם תבצעו העברה/הפעלה של המכונות הוירטואליות במכונה פיזית אחרת, אבל אם כל השרתים מקבלים שרותי Storage מאותה קופסא ענקית והיא מושבתת – אף VM לא יעלה.

הותיקים מבינינו יקבלו אולי תחושת Deja-Vu קלה – ככה בדיוק מכרו ל-Corporate שרתים של Sun וחברות גדולות אחרות לפני 20 שנה. מפלצת גדולה, חייבת להיות יציבה ואם היא מפסיקה לתת שרותים – הצרות יגיעו (כולל כמה מאות טלפונים  ו-SMS בהולים).

כיום – שרתי ה-Solaris הגדולים של SUN נזרקו מרוב החברות ואותם שרתים הוחלפו במכונות Linux שמאוחר יותר עברו P2V להיות VM, וכיום יש לנו מספיק פתרונות טכנולוגיים לתת שרידות ל-VM כדי שגם אם יפול מתג, או Storage או שרת פיזי – ה-VM ימשיך לעבוד. אחרי הכל, להכין FT או HA ב-ESXI זה לא בדיוק מסובך כמו להטיס חלליות…

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

האם אתם יודעים על איזה שרת אתם רצים? (מבחינת Brand), האם אתם יודעים איזה דיסקים יש בפנים? האם יש דיסקים בשרת הפיזי או שזה מחובר לארון שמריץ שרותים שנותן שרותי דיסק ב-LAN עם דברים כמו LUN/iSCSI? התשובה לכל השאלות האלו היא פשוטה והיא: לא, אתם לא יודעים. אם תתהו מה יש מאחורי הקלעים, אמזון יאמרו לכם שהם עושים כל מיני דברים סודיים שלא אמורים לשנות לכם כלום – מבחינתם, הם צריכים לתת לך VM עם תכונות X,Y,Z שרצית וזהו. לא אמזון, לא גוגל ולא מיקרוסופט – אף אחד מהם לא מפרט לעומק מה ה"נוסחה" שהם בונים את התשתית שנותנת את ה-VM שאנחנו מקבלים בסוף. יש לנו רמזים על חלקים מסויימים (אמזון משתמשת ב-Xen, גוגל ב-KVM ומיקרוסופט ב-Hyper-V), אבל לא על הדיסקים, לא על הרשת, ולא על רפליקציות וכו'.

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

נחזור ל-Data Center שיש ב-Corporate ונדמיין לעצמנו שאנחנו לוקחים מברג ומחליטים לפתוח את אותו פתרון Storage קנייני גדול (טיפ: לא לנסות בחברה, מתכון בטוח לפיטורים מהירים) ולראות מהו אותו "קסם" שהם עושים בפנים. מבלי להיכנס ליותר מדי פרטים טכניים, אנחנו נמצא שישנה מערכת הפעלה קניינית של היצרן, מעבדים, זכרונות ועוד כמה חלקים, כך שה-Storage עצמו בנוי בצורה שלא ממש רחוקה משרת ממוצע שיש לנו (כמובן שאין שם מעבדי X86). אם נסתכל ונכיר קצת יותר את ה-Storage Processor ונשווה אותו למעבדים גנריים אחרים, אולי נופתע מכך שהמעבד עצמו הוא חלש בהשוואה לאחרים. כמה חלש? מעבד Xeon ישן מאוד שיש לך בשרת ישן – הרבה יותר חזק מה-SP עצמו ומסוגל לעשות את אותם פעולות מבלי להתאמץ ממש (כן, גם אם ניתן לו לעשות את החישובים של דחיסה, RAID וכו' במקביל).

זו בדיוק הנקודה שספקי הענן הפופולריים הבינו מזמן. אתה ממש לא צריך את הפתרון הקנייני המפלצתי כדי לבנות משהו שיתן שרותי בלוק/קבצים בצורה מהירה מאוד ובדרך גם לנהל מאות דיסקים, וכן – אתה יכול גם לקנות דיסקים איטיים (ואפילו SATA – וכן, אמזון קונים SATA בערימות) וגם SSD מהירים מאוד ובעזרת הפתרון שהם בונים, הם משלבים את הדיסקים כך שאחד לא "יחנוק" את השני. כך לדוגמא אם אתה עושה רפליקציה כל כמה שעות בין 2 ארונות, אפשר להכניס בארון שמקבל את הרפליקציה מספר דיסקים SSD גדולים שמשמשים רק כ-Cache ל-Write ולאחר שהם מקבלים את ה-DATA יש תהליך איטי של כתיבה מה-SSD לדיסקים SATA (לא יכול לאמר מי ספק הענן שעושה זאת, אבל אחד מהם בהחלט עושה זאת כך).

כאן מגיע דבר שנקרא במקומות רבים SDS ר"ת של Software Defined Storage. ב-SDS אתה הוא מי שבעצם מתכנן ובונה את ה-Storage ואתה יכול להקים עליו איזו תוכנה שתרצה כדי לנהל את ה-Storage וכאן יש לך מגוון של תוכנות, החל מקוד פתוח ועד פתרונות סמי-קוד-פתוח כמו של EMC ScaleIO  ופתרונות קוד סגור אחרים. גם מבחינת גדילה אתה יכול להתחיל במסלול של Scale UP ולחבר JBOD או יותר ועד למצב של Scale Out עם 3 שרתים ומעלה (ומומלץ רשת של 10 ג'יגה בין אותם שרתי Storage). אפשרות נוספת שיש לך היא בעצם להשתמש במשהו שכבר קיים אצלך, כך לדוגמא אם כל השרתים הפיזיים שלך מריצים ESXI, אתה יכול להשתמש ב-VSAN ולהכניס דיסקים מגנטיים ו-SSD לכל אחד מהשרתים ולבנות בעצם Storage מתוך אותם משאבים (בין כה VSAN לעולם לא עובר את קו ה-10% שימוש במשאבי מעבד/זכרון כך שהוא לא יחנוק לך את השרתים).

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

האם ב-Corporate יעברו לפתרון כזה? כשחשבתי על כך בעבר, תשובתי היתה "לא", אולם כיום כשחברות מוצאות את עצמן צריכות לשלם על הארכת חוזה תמיכה סכומים רציניים מאוד, ומאות אחוזים נוספים על דיסקים, נראה לי שחברות יהיו מוכנות יותר לשמוע על הרעיון. לא לעבור אליו מחר, אבל עצם הרעיון נשמע להם "מעניין". אני מאמין שבמהלך ה-5 השנים הקרובות נראה יותר ויותר חברות עוברות ל-SBS. אם מסתכלים על הדוחות הפיננסיים של חברות יצרני Storage כבר כיום רואים חברות כמו EMC שלא מראות ממש צמיחה והם מתכננים קיצוץ כ"א, וכנ"ל ב-NetApp כך שנראה שחברות פחות ופחות רוצות לקנות את הקופסאות הענקיות הללו.