הבעיות של היום ומחר – עם פתרונות של אתמול ושלשום

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

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

לאחר קריאת החוברת או ההמלצות – אני מחזיר תשובה לפונה, בדרך כלל התשובה תהיה אחת משלושת האופציות הבאות:

  • ההמלצות טובות ונכונות (אם יהיו לי הערות או נקודות מסויימות – אציין אותן)
  • הרעיון העקרוני בהמלצות נכון, אבל מומלץ לשלב פלטפורמות X,Y וטכנולוגיות A,B.
  • אתם שילמתם על היעוץ הזה? ברצינות? אתם נמצאים בשנות ה-90 או ה-2000 או מה?

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

להלן שתי דוגמאות, מהחודשים האחרונים:

  • חברה מסויימת רצתה להריץ פלטפורמה מסויימת על לינוקס מספר רב של פעמים. המערכת אמורה להיות פתוחה לרשת וההפניות יועברו דרך Load Balancer (אני לא יכול לפרט עקב הסכמי סודיות). היעוץ שהם קיבלו: לרכוש 18 שרתים עם מפרט די "כבד", רכישה של Load Balancer חומרתי, סטורג' מפלצתי, לכל הברזלים רשיון VMWare Enterprise.
    ההצעה שלי (שהתקבלה): במקום 18 שרתים עם מפרט כבד, 2 שרתים עם מפרט נמוך, 4 שרתים עם מפרט כבד (יחסית, הרבה זכרון), מערכת OpenShift, ושרת נוסף קטן שיריץ ESXI כדי להריץ 2 מכונות VM שמריצות Windows. סטורג' – או בניה או לרכוש משהו קטן מכיוון שאין צורך ב-IOPS רציני או כמות אחסון גדולה. הפלטפורמה תרוץ כולה על קונטיינרים, ובהתבסס על הסטטיסטיקה שנמסרה לי, אני מתקשה להאמין שתהיה צריכת משאבים של יותר מ-40% בכל השרתים.
  • חברת מדיה מסויימת רצתה לאחסן תכנים רבים ולהערכתם הם יגדלו בכל שנה בסביבות ה-100-150 טרהבייט. הדרישה – אפשרות גדילה ללא SPOF (כלומר: Single Point of Failure) ומבלי לרדת בכמות רוחב הפס הפנימי, אדרבא – אם אפשר שתהיה גדולה יותר ויותר – הם ישמחו. כאן לא היתה חברה מסויימת שנתנה יעוץ, אלא החברה ביקשה מכל מפיצי הסטורג'ים הגדולים והמוכרים בארץ, ואני התבקשתי להמליץ על אחת מההצעות.
    הבעיה: אף הצעה לא כללה פתרון אחסון Scale Out. כל ההצעות היו פחות או יותר "תוסיף מדף" ובקשר לשרידות – קנה שתי ראשים. לפיכך המלצתי הפשוטה (שהתקבלה) היתה: זרקו את ההצעות ובקשו או פתרון Scale Out או לבנות פתרון Scale Out מבוסס קוד פתוח או תוכנה סגורה שמציעות יצרני שרתים וחברות אחרות, ורשת עם Backbone של 40 ג'יגהביט שיגדלו בהמשך לכיוון ה-100 ג'יגהביט.

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

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

שנת 2019 במעבדים – זו לא השנה של אינטל

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

נובמבר 2018 – חברת AMD מכריזה על מעבדי ROME, הדור השני של מעבדי EPYC לשרתים. החברה כינסה את הכתבים והבלוגרים הטכניים ליום עיון טכני, ובסופו של דבר לאחר שהדברים החלו להתפרסם, התברר משהו פשוט אחד: ב-AMD הפיקו מהר מאוד לקחים מהדור הראשון (Naples) והם שינו את הארכיטקטורה (מ-NUMA ל-UMA). החברה עברה בהצלחה מ-14 ננומטר ל-7 ננומטר, והחברה ממשיכה לעבוד בשיטת ה-Chiplets במקום שבב ענק אחד – השיטה שאינטל עובדת (יעברו עוד כמה חודשים עד שאינטל תכריז כי בשבבים עתידיים שלה בעוד שנתיים, גם הם יעברו כ-Chiplets). חברת AMD החליטה לשנות בדרך גם מספר דברים פנימיים מבחינת עיבוד נתונים וגם להגדיר את ה-Cache לגדלים בומבסטיים. בסופו של דבר, כשיצאו המעבדים לשוק ותוצאות המבחנים הראו מעבר לכל ספק שמעבדי EPYC דור שני עוקפים כמעט בכל מבחן את המעבדים של אינטל, כל ספקי הענן הציבורי מיהרו לרכוש וכל יצרני השרתים החלו לקחת את AMD ברצינות והחלו להוציא הן דגמים מעודכנים עם מעבדי EPYC החדשים והן להכריז על משפחות שרתים חדשים שישתמשו במעבדים הללו. מכיוון ששדרוג שרתים נעשה באיטיות ולוקח לשינוי להתרחש במשך שנים בתחום ה-Enterprise, אף אחד לא ציפה ש-AMD תחטוף לאינטל פלח שוק גדול, וגם AMD עצמה הכריזו שהשאיפה שלהם היא להגיע עד 2020 ל-10%, ולפי דיווחים שונים, הם בהחלט בדרך לכך.

האירוניה הגדולה הקשורה לאינטל ולשוק זה – לאינטל יש מענה ל-ROME, והוא נקרא Xeon Platinum 9200, רק שיש מספר בעיות עם המענה הנ"ל:

  • אינטל בראש ובראשונה יעדה אותו אך ורק לשוק ה-HPC. ב-AMD מצהירים בפשטות שמי שרוצה ביצועים גבוהים וכמות ליבות גדולה, ישנם מספר דגמים עם 64 ליבות לרכישה.
  • מערכות השרתים שמריצות את ה-Xeon Platinum 9200 שונות לחלוטין ממערכות שרתים רגילות, הן בחשמל, הן במעבדים והן בתושבת (אין תושבת, המעבדים מולחמים ישירות על הלוח) – מה שלא מאפשר לשום יצרן שרתים לבנות ולמכור מכונות כאלו, זולת יצרנים שמייצרים לוחות אם Custom כמו Supermicro וכו'.
  • התמחור: במחיר של שרת עם מעבד יחיד, תוכל לרכוש שרת עם 2 מעבדי EPYC כשלכל אחד מהם 64 ליבות. עם הפרש מחירים כה גבוה, קשה מאוד לשכנע חברות לרכוש שרתים ועוד ישירות מאינטל (לאינטל אין נסיון רב במכירות שרתים ללקוח הסופי).

משוק השרתים נעבור לשוק ה-HEDT (כלומר: High End Desktop)

תחום ה-HEDT נוצר כתוצאה של תחרות בין אינטל ל-AMD. במקור, אינטל הוציאה סידרת מעבדים חדשה תחת משפחת Skylake, אלו מעבדים שיועדו לכל התחומים, מדסקטופ ועד שרתים. לדסקטופ אינטל הוציאה מספר מעבדים כאשר מקסימום הליבות פר מעבד הוא 4. AMD באותו זמן החלה להוציא פרטים על מעבדים חדשים, משהו שהחברה לא תכננה מראש והם תוצר פנימי של קבוצת מהנדסים שתכננו, הציגו להנהלה, בהנהלה אהבו את זה והחלו לייצר אותם. מהרגע שאינטל שמעה על זה, אינטל נכנסה לפאניקה והחלה לדרוש מיצרני לוחות האם לשנות את הלוחות שאמורים לצאת לשוק כדי לתמוך בכמויות יותר גדולה של PCIe, ולהוסיף תמיכה לסידרת מעבדים חדשה, ה-Skylake X, והכל כמובן היה תחת לחץ אטומי של אינטל לשנות הכל תוך .. 3 חודשים, והתוצאות גם ניכרו בהמשך כאשר לוחות שהחלו לצאת לשוק לא יכלו לתמוך מבחינת VRM וחום במעבדים החדשים. אז בזמן שאינטל הציגה רשימת מעבדים חדשה כשבראשה עומד ה-7980XE, חברת AMD הוציאו את ה-Threadripper עד 16 ליבות במחיר נמוך משמעותי מהמחירים שאינטל ביקשו. מאז החברות הוציאו דור שני למעבדי HEDT, ו-AMD הוציאה גם מעבדי Threadripper עם 32 ליבות.

בשבוע שעבר היתה לסוקרים ולבלוגרים הטכניים שמקבלים מעבדים לסקירה – "הפתעה" לא נעימה: אינטל החליטה להרים את ה-NDA כ-6 שעות לפני שהסוקרים יכלו להציג את מעבדי ה-Threadripper החדשים. ערוצי יוטיוב רציניים כמו Jaytwocents ו-Linus Tech tips די קטלו את אינטל על המהלך הנבזי הנ"ל (אינטל עם המהלך הזה רצתה להשיג סקירות שלא משוות את המעבדים החדשים ובמיוחד את ה-10980XE מול מעבדי ה-Threadripper) ובסופו של דבר רוב הסקירות שיצאו לשוק – די קטלו את המעבד החדש.

המעבד החדש, למרות שהוא מהיר בכ-400 מגהרץ בהשוואה לדור קודם (9980XE) קיבל חלק מתיקוני האבטחה, מה שגורם להאטת ביצועים מול ה-9980XE, כלומר מהירות השעון היא אכן יותר גבוהה, אך הביצועים יותר נמוכים. אינטל גם החליטה לחתוך במחצית את מחיר המעבד בהשוואה ל-9980XE כך שכולם ראו את התאוותנות של אינטל, ואז הגיעה ההשוואה מול מעבדי Threadripper החדשים של AMD (ה-3960X ו-3970X), וכאן – הפתעה: לא רק שה-Threadripper החדשים בועטים ב-10980XE כמעט בכל מבחן, ה-3950X, המעבד שמיועד בכלל לדסקטופ ויש לו "רק" 16 ליבות – גם הוא עוקף במבחנים רבים את ה-10980XE. בקיצור – אינטל נשארו עם עוגה על הפרצוף וההמלצה ברוב הסקירות היא שאם אין לך מערכת קודמת מבוססת X299, עדיף לבחור מהפתרונות של AMD.

שוק תחנות העבודה: הנה שוק שאינטל שולטת בו לחלוטין, והדבר היחיד החדש שהיה בו זה אינטל הוציאה לשוק זה את ה-Xeon W-3275. מעבד עם 28 ליבות במחיר של 4500$. רק לשם השוואה, ה-Threadripper 3970X עולה $2000 והוא "חוגג בסיבובים" ברוב מוחלט של המבחנים סביב המעבד הנ"ל של אינטל.

הגענו לשוק הדסקטופ, וכאן לאינטל השנה לא היה כמעט כלום מה לחדש. הם הוציאו מעבדים עם 8 ליבות שיכולים להגיע למהירות 5 ג'יגהרץ (כל הליבות), והם הוציאו גם כמה מעבדים ללא יחידת עיבוד גרפי פנימי (המבחנים הראו שחבל לרכוש אותם, לא מקבלים ביצועים יותר גבוהים). ב-AMD לעומת זאת "כיסו" עם שורת מעבדים את כל מה שאינטל מציעים, החל ממעבדים 2 ליבות ועד 16 ליבות – שרצים על לוחות אם חדשים וישנים (כל מה שצריך זה לעדכן BIOS) עם מחירים מאוד תחרותיים מול אינטל. המסקנה של רוב הסוקרים היתה פשוטה: אם אתה מחפש לרכוש/לבנות מערכת גיימינג שתתן לך את כל הפריימים עד האחרון שבהם, קח מעבד של אינטל ועדיף את ה-9900KS. אם יש לך צרכים מעורבים (כולל עריכת וידאו, אפקטים וכו'), תסתכל על ההצעות של AMD.

לסיכום: ל-AMD אין משאבים כמו שיש לאינטל, והשמועות על פלטפורמת Zen-2 (שכל המעבדים החדשים מתבססים עליה) החלו עוד באפריל 2018 ואני בטוח שאינטל ידעה הרבה יותר מהציבור, ובכל זאת, במהלך שנה וחצי, אינטל לא הוציאו שום מעבד תחרותי. אני פשוט המום מכך שחברה בשווי שוק של 254 מיליארד דולר לא מצליחה להוציא מעבדים תחרותיים בשעה שהמתחרה הקטנה שלה מצליחה לפתח ארכיקטורות חדשות (ה-Zen-3 שיצא בשנה הבאה היא הארכיטקטורה השלישית -AMD תוציא והיא מכוונת לנקודות החזקות של אינטל: Floating Point ו-IPC, ועוד כמה דברים). אני מאמין שאינטל תתעשת ותוציא ארכיטקטורות ומעבדים חדשים ויותר חזקים, אבל איך זה קורה ששנה וחצי אין שום התפתחות אצלם?

ה"פקקים" בדרך לביצוע פרויקטים

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

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

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

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

האידיליה הזו במקרים רבים נשברת על ידי צוותי הנהלה. לי כמובן אין שום דבר נגד צוותי ניהול, אך הבעיה המהותית שמתרחשת זה שדברים שמצריכים החלטה עוברים לדרג ניהולי, וחלק מאותם מנהלים מוסיף לעצמו עוד ועוד דברים וכתוצאה מכך – החלטות מתקבלות לאט (ידידנו האמריקאיים מומחים בכך, תאמינו לי. הם אלו שהמציאו את ה-Project Manager, Product Manager, Director ושלל תארים נוספים) וכך מתרחשים לדוגמא השהיות: נניח ואני צריך עוד שלוש שרתים כדי לבצע עבודה. שום איש IT לא יכול לאשר רכישות כאלו, אז זה צריך לטפס למנמ"ר, ל-CTO, ל-CFO ולמנכ"ל. מכיוון שלכל אחד מהם יש "בצלחת" דברים רבים שהוא צריך לעקוב/להחליט לגביהם, הזמן שיקח עד שיגיעו שרתים – נמדד בחודשים, ועד אז אותו חלק שאני צריך לבצע – מוקפא, מה שאומר שאותו פרויקט יתארך ויהיה צורך לשלם יותר לעובדים החיצוניים.

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

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

קצת על Scale Out עם פלטפורמות יעודיות

בשנים האחרונות אנחנו עדים ליותר ויותר פלטפורמות שעובדות בשיטות של Scale Out. הפלטפורמה הכי ידועה לדברים כאלו היא כמובן Kubernetes, אך כמובן שישנן פלטפורמות אחרות שקשורות יותר לעיבוד נתונים – Kafka או Cassandra לדוגמא, כל אחת מהן פלטפורמה לצרכים שונים, אבל מבחינת צרכי חומרה, הצרכים הם פחות או יותר זהים: מעבדים בינוניים (לא צריך כמות מפוצצת של ליבות, יספיקו 8-16), ולא צריך דיסקים (קשיחים או SSD) יקרים.

כלומר – אם אתה צריך להריץ פלטפורמה שעובדת ב-Scale Out מקומית בתשתית שלך, אל תנסה לחפש את היוקרתי עם כל מילות הבאז האחרונות, אלא ההיפך – מי הספק שיכול לתת לך את ההצעה הכי זולה שתעמוד במפרט שנקבע מראש, SLA שאתה צריך וכו'. ב-Scale Out אין את מושגי השרידות מעולם ה-Scale Up. אין Heart beat, אין Active/Passive, Active/Active וכו'. עם Scale Out בדרך כלל הפלטפורמה תהיה בנויה כך שאם שרת למטה/אינו זמין/אינו פעיל, המערכת תאזן את עצמה אוטומטית (למי שמשתמש ב-Kubernetes ורוצה לראות זאת – תורידו Node ותראו איך זה עובד).

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

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

אחת השגיאות שאפשר לראות בפורומים שונים, זה שאנשים שעובדים עם פתרונות Scale Out מחפשים איך לאחסן את כמות הנתונים שהולכת וגודלת והם עדיין לא מכירים/מבינים את עניין ההוספה המתמדת של ברזלים ודיסקים מקומיים – והם תמיד יקבלו את הצעות הפתרונות שמתאימים ל-Scale Up: לתכנן את הגדילה למשך שנה וכו' וכו' ואז לבחור סטורג'. זו טעות, כי בעולם המדידות/דגימות ושימוש בפלטפורמות Scale Out אתה מחפש לקבל כמה שיותר מידע, לא כמה שפחות, ויכול להיות שהחודש הקרוב אתה תוסיף עוד 4 טרה מידע לחודש אבל בעוד 3 חודשים זה יקפוץ ל-15 טרה לחודש. בגדלים כאלו, שום פתרון סטורג' קנייני אינו מתאים, אלא אם רוצים "לשרוף" את תקציב החברה, ולכן יש צורך ללכת לפי הפתרון של הפלטפורמה, לא לפי שם/דגם של סטורג'.

ולכן:

  • אם הולכים להשתמש בפלטפורמה שהיא בראש ובראשונה Scale Out לצרכי עיבוד נתונים/קליטת נתונים – נצטרך דיסקים ושרת מהקצה הנמוך-בינוני, מבלי להשקיע יותר מדי כספים פר ברזל (קחו דיסקים בסיסיים, בפוסט קרוב אסביר לגבי הגדרות אחסון מקומי למערכות כמו Kafka ו-Cassandra), (אגב, אם אתם רוצים להריץ Kafka בענן, אמזון לדוגמא שמחה להציע לכם את MSK).
  • אם אנחנו רוצים לשמור כמות גדולה מאוד של מידע לאחר עיבוד או ארכיבאי כשהכמות גודלת כל הזמן, או שאנחנו צריכים Object Storage – פתרון אחסון Scale Out (כמו Gluster) יתאים יותר לשימושים הללו מכיוון שעלות הגדילה היא זולה, והביצועים גודלים ככל שמוסיפים ברזלים לאותו אחסון.

לסיכום: בעולם ה-Enterprise, הסטורג' הקנייני היה ה-דבר הכי חשוב וקריטי. אין סטורג', שום דבר לא פועל. מאז הגיעו ספקי הענן הציבורי הגדולים שהכריזו שאצלם אין ולא יהיה שום סטורג' מרכזי, ובמקביל התפתחו יותר ויותר פלטפורמות שמחזירות את השימוש בדיסקים מקומיים ומאפשרות לבנות אחסון מדיסקים זולים וממשאבים צנועים, וזהו בדיוק החלק שבמחלקות ה-IT או ה-CIO/CTO צריכים להבין: אל תנסו לכפות פתרון Scale Up על פתרון Scale Out.

המעבר ממונוליטי ל-Microservices

כל מי שנמצא ברמה ניהולית של IT (מנמ"ר/CTO/CIO וכו') בוודאי מכיר את הדבר הבא: חברה מעוניינת לפתח מוצר גדול, "הדבר הבא" בתחום שלהם. מתקיימות מספר ישיבות עם גורמים שונים בחברה ותוך כדי כותבים מפרט ארוך מה הולך להיות בתוך המוצר, במה הולכים לתמוך בתוך המוצר וכו' וכו'.

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

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

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

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

פרויקט גדול מורכב מחלקים רבים שצריך לכתוב. בשיטה המונוליטית כל החלקים משתלבים אחד עם השני (Linking) כך שאי אפשר לשלב קוד בחופשיות של מפתחים שונים. צריך לבדוק כל חלק שמבצעים לו Commit שהוא לא שובר חלקים אחרים במוצר. בשיטת ה-Microservices (אני אקרא לזה מ"ש במשך פוסט זה) עושים דברים בשיטה הפוכה: כל חלק שצריך לכתוב, יכתב באופן עצמאי לחלוטין, הוא יכול להיות כתוב בשפה אחרות או עם פלטפורמה/Framework שונה מחלקים אחרים – כל עוד לאותו חלק יהיה ממשק RESTful API שאליו נוכל לשלוח פרמטרים (דרך YAML, JSON וכו') ונוכל לקבל נתונים בחזרה מאותו חלק בפורמט שנרצה.

וכך, בשיטה זו הצוותים השונים עובדים בצורה עצמאית לחלוטין והדבר היחיד שהם צריכים לשמור, זה פורמט API שמוסכם בין כל הצוותים ומתועד. זו בדיוק ההזדמנות גם להשתמש בטכנולוגיות חדשות, או לקחת מפתחים מבחוץ שיודעים לבנות לדוגמא UI בכלים מודרניים, אפשר להשתמש בכלי CI/CD לבדוק ולקמפל כל חלק באופן עצמאי, לכתוב טסטים ולבצע Stress testing לכל חלק.

לאחר שהחלקים השונים נכתבו (או במהלכם) – אנחנו נשתמש במערכת אורקסטרציה לקונטיינרים (כמו Kubernetes/OpenShift) בכדי להריץ כל חלק בקונטיינר/POD והתקשורת בין החלקים תהיה דרך HTTP/HTTPS ודרך פרוטוקולים אלו נשתמש ב-API כך שכל חלק יוכל לדבר עם חלקים אחרים.

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

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

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

להלן מצגת (קצת ישנה) על הנושא (ותודה ליבגני זיסליס על הלינק):

כשצריך הגנות על מכונות וירטואליות

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

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

אינטל בזמנו פיתחה את ה-SGX, שזו מערכת שמאפשרת לנו ליצור איזור מאובטח שעליו ירוץ קוד בצורה מוצפנת כך שגם מנהל Hypervisor עם תוכנות זדוניות לא יוכל לסרוק את אותו זכרון ולמצוא מה רץ. ה-SGX עצמו כבר נפרץ (אינטל הוציאה תיקון), אבל בכל מקרה הפתרון עצמו היה בעייתי עוד מלכתחילה: האפליקציה המוצפנת היתה צריכה להיות מאוד קטנה (עד 64 מגהבייט זכרון), והביצועים (במיוחד ה-Floating Point) היו, איך נאמר בעדינות … לא משהו להתגאות בו. ב-VMWare לא רצו לנגוע בזה גם עם מקל ארוך.

ואז הגיעה חברת AMD ובשנת 2017 היא פירסמה על תוספות חדשות שיהיו זמינים במעבדים שלה לשרתים (EPYC) ובמעבדים לצרכים מקצועיים (Ryzen Pro): התוספות הן SEV ו-SME (והתוספת החדשה: SEV-ES – להצפין גם רגיסטרים במעבד שמשומשים ע"י אותו VM מוצפן). ה-SEV איפשר להצפין את מכונת ה-VM עם מפתח יחודי שמגיע מתוך מעבד ARM שנמצא במעבד EPYC (כן, מעבד בתוך מעבד) ו-SME שמצפין את הזכרון של ה-VM.

היתרונות של SEV ו-SME הם בכך ש:

  1. אין צורך לעשות שינויים מהותיים ב-VM (רק להחליף Kernel לאחד שתומך ב-SME/SEV)
  2. ההצפנה היא ברמת חומרה, כך שה"קנס" ברמת ביצועים הוא מאוד מינימלי
  3. המפתחות הם יחודיים ולכל VM יש מפתח משלו שמונפק ע"י המעבד. ניתן להנפיק עד 105 מפתחות (כל VM מקבל מפתח אחד, כך שאפשר להריץ עד 105 מכונות VM מוצפנות בשרת עם מעבד EPYC יחיד או 210 בשרת עם שני מעבדי EPYC).

החסרונות:

  1. אי אפשר להצפין מכונות Windows, לפחות עד שמיקרוסופט לא תוסיף את תמיכת ההצפנה ל-OS עצמו.
  2. VMware בשלב זה אינה תומכת בפונקציות אלו מ-AMD או אינטל (תיכף ארחיב על הפתרון של אינטל) – זה יתווסף בגירסה 6.8 או 7.0 ולכן אם אתם צריכים זאת עכשיו, תצטרכו לעבור ל-KVM או על אחת הפלטפורמות שמבוססות על KVM (בכל מקרה יש צורך לבצע את ההחלפת Kernel).

באינטל ראו את הפתרון של AMD והחליטו שגם הם יוציאו משהו דומה: תכירו את TME (כלומר Total Memory Encryption) ואת MKTME (כלומר: Multi Key Total Memory Encryption). אפשר לקרוא על הפתרון הזה בקצרה כאן, אך אני יאמר מראש: אל תבנו על הפתרון הזה, הוא לא זמין באף מעבד נוכחי.

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

  • כן, הפתרון רץ אך על מנת להשתמש בו, יש צורך בידע טוב בלינוקס. אם צריכים את הפתרון ל"מחר בבוקר" – תצטרכו לבצע שינויים הן ברמת ה-HyperVisor והן ברמת ה-VM.
  • הפתרון אינו מבטיח הגנות נגד דברים אחרים כמו Side Memory Attack, DDoS.
  • הפתרון הוא יחסית צעיר (ב-AMD פיתחו אותו בכלל עבור הגנת הקונסולות של סוני ומיקרוסופט ואז החליטו שזה רעיון מעולה להעביר אותו למעבדים לשרתים) ולפיכך מתגלים בו באגים (ו-AMD משחררת קושחות לתיקון).
  • כיום הפתרון של AMD נמצא בשימוש בשרתים החדשים (דור 10) של HPE שמבוססים על מעבדי EPYC (כלומר DL325 ו-DL385) בשילוב ה-Root of Trust של HPE והחברה (HPE) טוענת שזה הפתרון הכי מאובטח שיש להם להציע לשוק.
  • זה לא לפרודקשן אם ה-VM שלכם צריך לרוץ בחוץ או ה-Hypervisor שלכם מחובר לאינטרנט (יש לא מעט כאלו).

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

לסיכום: השיטה ש-AMD מציגה על מנת להגן על מכונות VM נגד האזנה למכונות VM היא שיטה טובה מאוד (ובגלל זה אינטל גם מעתיקים אותה), אך זהו פתרון חדש, וככזה הוא יכול להתאים למאמצים מוקדמים (Early Adopters) עם ידע בלינוקס. אני מאמין שבעוד שנה, הפתרון יתבגר יותר ובמקביל נראה הצעות מספקי ענן ציבורי לשכור Instances שיתמכו ב-SEV/SME, כך שה-Instances שלכם יהיו מוצפנים מספיק טוב בכדי לא לאפשר (באופן עקרוני) לגורמים זרים שיש להם גישה לברזל – לחטט בזכרון של ה-VM שלכם.

הפתרון למעבר מ-VM לקונטיינר: Kubevirt

(הערה: לפני כשנתיים כתבתי את הפוסט הזה על Kubevirt. מאז דברים רבים השתנו ופוסט זה הוא פוסט עדכון לכלי).

כל מי שהתחיל ומשתמש בקונטיינרים, Kubernetes וכו' – מבין בוודאי שקונטיינרים אינם מכונות וירטואליות. בניגוד ל-VM, קונטיינר מקבל שרותי OS ממערכת ההפעלה המותקנת על ה-VM (או על הברזל) שמריץ את הקונטיינר, ולפיכך קונטיינרים ברוב המקרים הם דברים די קטנים בהשוואה למערכת הפעלה מלאה שמותקנת ב-VM, גם כשהיא מותקנת כ-Minimal.

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

ישנם גם מקרים שאי אפשר להמיר מכונת VM לקונטיינרים חדשים. מקרים כמו:

  • האפליקציה רצה ומבוססת על Windows
  • האפליקציה רצה על גירסת לינוקס מאוד ישנה
  • האפליקציה רצה על מערכת הפעלה שאינה מבוססת לינוקס
  • ה-VM נבנה ע"י מומחה חיצוני ולאף אחד אין מושג ירוק איך הדברים מוגדרים ב-VM (לדוגמא: Cobol ישן)

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

וכאן נכנסת לתמונה אפליקציית Kubevirt.

אפליקציית Kubevirt מרחיבה בעצם את Kubernetes/OpenShift ומוסיפה למערכת תמיכה בקונטיינרים מסוג נוסף: קונטיינר שמריץ VM. כך בעצם אפשר לקחת VM מהדוגמאות לעיל ו"להכניס" אותו לתוך קונטיינר, כך שנוכל להריץ אותו כמו שאנחנו מפעילים קונטיינרים נוספים, ובכך נוכל להשתמש באפליקציה שרצה ב-VM, נוכל לשכפל את הקונטיינר לפי פרמטרים שנרצה, נוכל לשדרג את הקונטיינר ועוד ועוד.

מאחורי הקלעים, מה ש-Kubevirt עושה, הוא להשתמש ב-KVM (הוירטואליזציה המצויה בכל לינוקס) ובספריית Libvirt וספריות נוספות בכדי ליצור POD ובתוך ה-POD להריץ VM. את אותו VM אנחנו נגדיר בעזרת קבצי YAML, כמו שמגדירים כל דבר ב-Kubernetes, וכך נוכל להגדיר כמות זכרון, היכן הדיסק הוירטואלי יושב, האם ה-VM יהיה בעצם Immutable (כלומר שכל שינוי ל-VM ימחק ברגע שה-VM "כובה"), ועוד פונקציות נוספות. הגישה ל-VM תוכל להתבצע בכלים הרגילים (SSH, RDP) או VNC וחיבור סריאלי וירטואלי (במקרה שמדובר בלינוקס או כל מערכת תואמת UNIX אחרת).

מכיוון שב-Kubernetes אפשר להשתמש בכל מיני "דרייברים" (Storage Classes, Volumes), נצטרך להמיר בשלב ראשון את הדיסקים הוירטואליים של ה-VM מהפורמט הנוכחי (VMDK ב-vSphere) לפורמט ש-KVM ו-libvirt יכולים להבין ולהשתמש. סוג הדיסק שאנחנו נצטרך יהיה RAW וכלי ההמרה (שצריך לרוץ תחת לינוקס) הוא virt-v2v (זה קצת יותר מורכב ממה שהקישור מראה). מהרגע שביצענו זאת, אנחנו "מנתקים" בעצם את ה-VM מהוירטואליזציה הנוכחית (נניח vSphere), אבל ה-VM עדיין נשאר ב-vSphere. ברגע שיש לנו את הקובץ בפורמט RAW, נוכל להשתמש בכלי כמו CDI כדי לבצע Import של ה-Image לתוך Volume שנגדיר. אחרי שהצלחנו (שוב, לא דבר כל כך קל, אלא אם אתם משתמשים ב-Openshift דרך ה-WEB UI), אנחנו נגדיר POD עם ה-VM ושם אנחנו נבחר דברים כמו כמות זכרון, מערכת הפעלה, וכו'. בזמן ההגדרות נוכל להוסיף דיסקים וירטואליים חדשים ל-VM ועוד. לאחר שהתהליך מסתיים ונפעיל את ה-VM, תופיע כתובת IP שדרכה נוכל להתחבר אל ה-VM.

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

  • Kubevirt עובד על כל גירסת Kubernetes מ-1.10 ומעלה, ו-OpenShift 3.11 ומעלה.
  • בשביל לקבל ביצועים טובים עם ה-VM, יש צורך בתמיכת Nested Virtualization (אם ה-Kubernetes שלכם רץ כמכונה וירטואלית).
  • עננים ציבוריים: אם אתם רוצים להריץ Kubevirt על ענן ציבורי, תצטרכו לבחור Instances שכוללים תמיכת Nested Virtualization. גם לאז'ור וגם לגוגל יש מכונות כאלו, ב-AWS אין ולפיכך ב-AWS מכונות VM כאלו ירוצו יותר לאט מאחר ומדובר באמולציית X86-64 בתוכנה.
  • דיסקים וירטואליים: מכיוון שאין Thin Provisioning בשיטה כזו, הווליומים יהיו גדולים (כמה שהגדרתם ב-VM בהתחלה תחת vSphere), לכן אם הגדרתם את ה-VM עם דיסק של 100 ג'יגה אבל השתמשתם רק ב-15 ג'יגה, הקטינו את הדיסק (הוראות נמצאות כאן אם מדובר ב-vSphere).
    נקודה נוספת חשובה לגבי דיסקים וירטואליים: אפשר לצרף אותם ישירות ל-Image של הקונטיינר אך הדבר אינו מומלץ (אלא אם אתם רוצים להפיץ את ה-Image החוצה).
  • קישוריות ל-VM ותקשורת: במקור כברירת מחדל יש ל-VM חיבור רשת יחיד. יחד עם זאת ניתן להשתמש ב-Multus או Genie כדי להוסיף דברים רבים הקשורים לרשת: VLAN, Bridges, אפילו PXE Boot – תשתוללו חופשי.
  • ניתן לשכפל את ה-VM לפי כל פרמטר שתרצו כדי לעמוד בעומסים. לשם כך תצטרכו להגדיר בקובץ YAML את ה-AccessModes לפי הצרכים שלכם.
  • KVM – מכיוון שה-VM שלכם ירוץ תחת KVM, כדאי להכיר את KVM. תרימו מכונת לינוקס, תפעילו Nested Virtualization ותריצו את Virt Manager (נקרא גם VMM). יש המון פונקציות והגדרות וכדאי להכיר אותם לפני כן, אחרת תקבלו הפתעות (במיוחד אם מכונת ה-VM שלכם משתמשת ב-UEFI. יש תמיכה ל-UEFI אבל תצטרכו להגדיר כמה דברים לשם כך).

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

אם אתם רוצים עוד הסברים על Kubevirt כולל הדגמה של לינוקס ו-Windows Server 2012, אתם מוזמנים לצפות בקליפ (הארוך – שעה) הבא.

לסיכום: אם אתם רוצים לעבור לקונטיינרים והדבר היחיד שמפריע זה מכונה אחת (או מספר מכונות) שבעייתי להמיר אותן ידנית לקבצי Docker Images ושירוצו כקונטיינרים טבעיים, Kubevirt יכול לסייע בכך. חברות כמו SAP, nVidia, Cloudflare כבר משתמשות ב-Kubevirt. חשוב לציין: Kubevirt עדיין לא מוגדר כגירסה סופית (מצד שני, גם Kubernetes לא מוגדר כך). אם אתם משתמשים ב-OpenShift מגירסה 3.10 ומעלה (גם בגירסת OKD – גירסת הקוד הפתוח) – קל מאוד לשלב את Kubevirt והחל מגירסה 4.2 – ה-Kubevirt יהיה חלק אינטגרלי (בגירסה הנ"ל תוכלו להתחבר ישירות ל-vCenter ולהמיר את ה-VM בכמה קליקים).
מיקרוסופט וגוגל כבר מזמן הבינו שאם רוצים למשוך את הלקוחות אליהם כדי שישתמשו בשרותי ה-Kubernetes שלהם, צריך לעזור ללקוחות בכך שיציעו המרה של מכונות VM להרצה בתוך קונטיינרים, וזה יהיה כנראה ה"גל" הבא.

על מדיה דיגיטלית, ענן ציבורי וגדילה דינמית

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

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

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

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

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

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

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

על בניית אתרים ואחסונם – דברים שחשוב לדעת

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

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

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

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

לכן, אם מקימים לך אתר, כדאי לחשוב/לבצע את הדברים הבאים:

  • אם אין לך שרת וירטואלי, תשכור אחד, לא צריך בישראל ולא צריך לשלם הרבה. אמזון Lightsail מציעים מכונות החל במחיר של 3.5$ (אני ממליץ לקחת את החבילה של ה-20$ אם זה לא אתר נשכח שנכנסים אליו 2 גולשים בשבוע), ואם אתם לא מעוניינים בהצעות של אמזון, יש גם את Digital Ocean (המחירים די זהים)
  • קחו איש לינוקס מקצועי שיבצע את הדברים הבאים:
    • יקים את המכונה, יעדכן ויגדיר אותה בהתאם לצרכים
    • שיקבל את האתר ב-ZIP מבוני האתר (חברות רבות שבונים אתרים מבקשים גישת FTP. לא לפתוח את זה, שילמדו לעבוד עם GIT!), כולל DB DUMP אם צריך.
    • שיגדיר את כל הדברים הנחוצים כולל הרשאות קבצים, גישה לשרת, מפתחות, SSL וכו'
    • אם האתר הוא מסחרי, אנליטיקות וכו' – בקשו מאיש הלינוקס להריץ בדיקת עומסים. אם השרת לא מצליח לעמוד בעומס נורמלי שאתם צריכים, פנו לחברה שבנתה אותו, בדרך כלל מדובר בקוד SQL גרוע, או במקרים רבים – חוסר אופטימיזציה של קוד, אי שימוש ב-Cache וכו'.
    • במידה ומדובר באתר גדול עם אלפי גולשים, דאגו ליידע מראש הן את איש הלינוקס והן את בוני האתרים. יתכן שיתווספו דרישות לבניית האתר מאיש הלינוקס.
    • בכל ויכוח מקצועי לגבי מכונת הלינוקס – דעתו של איש הלינוקס קובעת, לא הדעה של חברת בוני האתרים (אין לי מספיק שערות בראש מכמות הויכוחים שעברתי בנושא הזה, שחברת בוני האתרים מילאה את ראשו של הלקוח בשטויות!)
  • במסגרת ההסכמים שלכם עם איש הלינוקס וחברת בניית האתרים, דאגו ש:
    • בתמחור לאיש הלינוקס תהיה חובת עדכון השרת אחת לחודש במשך שנה
    • חברת בוני האתרים יחויבו לעדכן את הקוד שלהם לגבי באגים וגרסאות תיקון של השפה בה הם מפתחים (NodeJS, PHP, Python וכו') – למשך שנה
  • כשאתם רוכשים את החבילה, בקשו מאיש הלינוקס גיבוי אוטומטי של השרת בהתאם לצורך (אחת ליום, אחת לשבוע וכו') כך שיאפשר שיחזור נתונים מיידי במקרה של תקלה/פריצה.
  • אם יש לכם את הכסף – העבירו את הקוד של חברת בניית האתר למישהו שיודע לבצע Code Auditing לקוד.
  • והכי חשוב: לא לתת גישת sudo/root לחברת בוני האתרים בשרת, בשום מקרה!

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

אורקל מקימה region בישראל ומי צריך את זה?

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

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

אתחיל ברשותכם בחלק של "מי צריך את זה?"

ספקי אינטרנט בישראל מוכרים מספר שרותים: קווי תקשורת, Colo (אחסון שרתים), עוד כמה שרותים, ושרות VPS מנוהל או לא מנוהל. בכל מה שקשור ל-Region לא תהיה ממש פגיעה במחלקת מכירת קווי תקשורת, אך יכולה להיות פגיעה בכל מה שקשור ל-Colo (במקום להשקיע ברכישת ברזל חדש, יכול להיות שההצעות מספקי ענן ציבורי עם Region מקומי יהיו קוסמות יותר). מה שבהחלט יפגע לדעתי – זה בכל מה שקשור ל-VPS. אין מה לעשות, ספקי הענן הציבורי מורידים מחירים מפעם לפעם, מה שלא קרה בארץ אפילו פעם אחת! תארו לכם שמישהו צריך להריץ אפליקציה על שרת VM ועד היום הוא שילם נניח 200 שקל על אותו VM ועתה ספקי הענן הציבורי עם Region מקומי מציעים לו את החבילה ב-100 שקל. כמה חברות לא ינטשו את הספקים הקודמים? לא הרבה. רובם ישמחו לעבור לענן הציבורי. אותו דבר גם לגבי חברות שרוצות DR מחוץ ל-DC המקומי שלהם. אם ההצעה החדשה אומרת שאתה לא צריך לרכוש כלום אלא לשלם מחיר נמוך (יחסית) בכדי לשכפל את המערכת שלך למערכת Instances בענן, אני מאמין שהרבה חברות יעברו, במיוחד שאין יותר בעיה של Latency גבוה.

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

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

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

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

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

  • חושבים לארח את הברזלים בארץ אצל Colo זה או אחר? לא בטוח שזה יעבוד. למיטב ידיעתי, אף ספק בישראל לא בנוי לקבל או להתמודד עם ציודים בסטנדרט OCP. תביא שרת שמקבל הזנה של 48V-DC ותהיה לך בעיה לחבר את זה.אפשר כמובן להרים פאנל חשמל עם ממיר וכו', אבל כדאי לקחת זאת בחשבון. ככלל, אני בספק אם יש כאן ספק COLO שיכול לעמוד בסטנדרטים של Data Center של גוגל, אמזון או מיקרוסופט.
  • הטבות: אם תקים DC בצפון או בדרום, אתה יכול לקבל הנחות מפליגות בארנונה ומסים באותם אזורים. זה לא קשור ל"טובות" כלשהן, זה משהו שקיים מזמן – הממשלה (והרשויות המקומיות) מעניקות הנחות לחברות שמקימות תשתיות וחברות באזורים אלו ואז יכול להיות שבחישוב OPEX, יהיה זול יותר לך להקים חוות משלך.
  • קווי תקשורת: כמה שפחות לסמוך על ספקים מקומיים כולל ספקי תשתית. צריך קווי תקשורת לארה"ב ואירופה? צור קשר עם תמר'ס, מד-וואן, או בזק בינלאומי ותוודא שאתה לא מקבל משהו משותף, ואם אפשר – קח חיבור כפול על כפול. בכל הקשור לקווי הולכה עד ל-DC, קח בחשבון שגם כשיש SLA, השרות לא תמיד משהו, צפה לנפילות תקשורת פתאומיות.
  • אנרגיה חלופית: בישראל יש חברת חשמל אחת גדולה וכמה קטנות שפועלות עם גז. אם אתם בצפון, אתם יכולים לשוחח עם Energix Group לגבי חשמל מטחנות רוח וחברות אחרות מספקות אנרגיה סולארית – הכל תלוי במיקום ה-DC.
  • פוליטיקה: מבחינה פוליטית, השלום בין ישראל לירדן הוא "קר", השלום עם מצרים הוא "פושר", ושלום בין ישראל לרש"פ נע ונד, תלוי באיזה יום (פוליטית אנחנו "ברוגז", מבחינת ביזנס לעומת זאת, לא מעט חברות ישראליות שוכרות עובדים פלסטינים). יחד עם זאת, יכול להיות שמקומות אלו כן ירצו להתחבר ל-Region מקומי, כל עוד ה-Latency הוא נמוך. אולי כדאי לחשוב על כך.
  • פרויקט נימבוס: סביר להניח שכל ספק ענן ציבורי ירצה להתחרות במכרז זה ואולי לזכות. יחד עם זאת, לפני שמתחילים לתכנן את ה-Region הישראלי, מומלץ לחכות למסמכי המכרז עם פירוט השרותים שתצטרכו לספק (הימור שלי: משהו בגודל Outpost ממש לא יספיק) – יכול להיות שתצטרכו להקים משהו הרבה יותר רציני ממה שתוכנן מלכתחילה ואולי שת"פ עם COLO לא יהיה כל כך רלוונטי.

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