הבאג הקריטי במעבדי אינטל

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

נכון להרגע, אין נתונים רשמיים עד לתחילת שבוע הבא ככל הנראה – אבל ממה שכן ידוע, מדובר על באג במעבדי אינטל מהעשור האחרון.

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

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

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

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

איזה מחיר? בביצועים. תלוי מה האפליקציות שאתם מריצים ולאיזה ציוד הם ניגשים – הביצועים ירדו בין 3 ל-30 אחוז אחרי התקנת הטלאי (הטלאי יהיה חובה בכל מערכות ההפעלה). במילים אחרות – אם אתם לדוגמא מריצים מערכת מורכבת נניח על 10 מכונות VM, אחרי התקנת הטלאי ועל מנת לקבל את אותם ביצועים – תצטרכו בין VM ל-3 VM נוספים. ישנם דברים שאינם מושפעים והם יותר קשורים למכונות דסקטופ או מחשבים ניידים כמו משחקים, קידוד וידאו ועוד מספר דברים. הפרטים יתבהרו יותר בשבוע הבא, אבל הנה דוגמאת גרף של מעבד דסקטופ חדש (משפחת CofeeLake, מעבד i7 8700K) בהשוואה למעבד i7 מלפני 2 דורות: ה-i7 6800K (תודה לאתר phoronix.com על הגרפים)

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

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

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

כשענק כמו גוגל מתחרה ב-Docker

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

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

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

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

אבל מה קורה שחברה די קטנה נתקלת בענק שיכול למחוץ אותה בקלות? אני מדבר על חברת Docker מול חברה שאולי שמעתם עליה .. גוגל.

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

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

מאז יצאו מספר תוכנות שעושות מה ש-Kubernetes עושה פחות או יותר – כמו DC/OS, Apache Mesos ועוד. במקביל יצאו מוצרים מסחריים (וחלקם חופשיים) ש"עטפו" את Kubernetes כך שאפשר למכור זאת לחברות יחד עם שרותי תמיכה מסביב לשעון, וגם Docker יצאה עם פתרון ה-Enterprise שלה.

העניין הוא ש-Kubernetes כבש את השוק. מדוע זה משנה? אם נחשוב על אנשי ה-Devops והמפתחים בחברה שנתקלים בתקלה, הסיכוי שהם ימצאו פתרון עם Kubernetes הוא הרבה יותר גבוה מאשר פתרונות אחרים שאינם מבוססים Kubernetes. נהיה יותר פרקטיים: חברתכם מחפשת 2-3 מפתחים שיעבדו עם קונטיינרים. אם תשאל לגבי הידע שלהם ב-Kubernetes, אתה תמצא שיש הרבה יותר אנשים עם הידע הנ"ל מאשר עם Apache Mesos, DC/OS או עם הפתרון המסחרי של Docker. מפתחים ואנשי מקצוע אחרים לומדים בעצמם דברים שהם פופולריים, ופחות דברים שלא נמצאים בשימוש רב.

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

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

פתרון GlusterFS – היכן הוא מתאים לכם?

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

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

נתחיל בהצהרה די פשוטה: למרות שטכנית ניתן לבנות את GlusterFS כפתרון שיכול לתת "פייט" רציני לכל פתרון אחסון Scale Up מסחרי, לא תמצאו אותי מחר אץ רץ לחברות תקשורת, בנקים וכו' וממליץ להם בחום לזרוק את פתרון האחסון שלהם לטובת GlusterFS, בדיוק כמו שפתרון VSAN של VMWare אינו פתרון להחליף סטורג' רציני עתיר משאבים. אלו 2 דברים שונים לחלוטין.

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

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

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

סיטואציה ראשונה
כאחד שנותן שרותי תמיכה ל-vSphere לגרסאותיו השונות, יש לי מילים חמות לאמר על VSAN. זהו פתרון אמין מאוד עם שרידות גבוהה מאוד ללא צורך בסטורג'. עם VSAN אפשר להגדיר פונקציות שונות כמו פונקציית שרידות מאוד גבוהה כך שמתוך קבוצה של 3 שרתים פיזיים, 2 נכבים, אפשר להגדיר ש-VM קריטי עדיין ישרוד.
הבעיה המרכזית עם VSAN אינה טכנית, אלא בעיה כספית. במחיר של $2500 לרשיון פר מעבד, על קבוצה של 3 שרתים פיזיים, אנחנו מדברים על 15,000$ וזה לא כולל את הרשיון היעודי של vSphere ולא כולל תמיכה של 3 שנים (שזה עוד 15,000$) ועוד לא הגענו בכלל למחירי הדיסקים – במיוחד שעם VSAN חובה ללכת בתצורת קבוצות של 2+1 (כלומר 2 דיסקים מכניים ו-1 SSD אם כי אפשר ללכת בתצורה היותר יקרה של 3 SSD ונוסיף לכך שאתה צריך שרתים מהדור האחרון או לפניו כדי להריץ את כל הדברים. מחיר כזה, לדעתי, אינו מוצדק עבור Dev, stage, testing, POC וכו'. במחיר כזה חברות כבר יחשבו על קניית אחסון יעודי.

במקום זה, אנחנו יכולים לקחת 3 מכונות שדווקא אינן חדשות (כל עוד בקר הדיסקים שלהם תומך ב-6 ג'יגהביט SATA/SAS, אם זה תומך רק ב-SATA 2.0, אז אפשר להכניס כרטיס בקר צד ג') כמו דור 7 של HP, דור 11 של DELL, דור 3 של LENOVO, ולמלא אותן בדיסקים. ניקח דוגמא: 10 דיסקים SATA של WD RED PRO (מחיר של 319$ באמזון פר דיסק, המחיר קצת יותר יקר אצל המפיץ בארץ) או WD GOLD Enterprise בגודל 10 טרה שעולה $361 פר דיסק, או Seagate מסידרת EXOS ל-Enterprise בגודל 10 טרהבייט שגם עולה $360. סה"כ עד כה – בערך $3600 (פר שרת). נוסיף עוד 2 דיסקים SSD – אם מחפשים זול וטוב, אז 2 דיסקים מה-850 PRO של סמסונג יוכלים לעבוד טוב (סה"כ 418$)ואם המכונה היא 2U, אז 2 כרטיסי SSD PCIE מסוג אינטל 900P 280GB AIC בתצורת PCIE (סה"כ 780$) יכולים לתת Cache די רציני למכונה.

ניקח את הבקר (ואת כרטיסי ה-PCIE) ונצמיד את כולם למכונת VM, נצמיד לה 32 ג'יגהבייט זכרון ו-4 ליבות, ועליה נרים GlusterFS (אם אתם מעוניינים בדחיסה, Dedup ושאר תפנוקים – יש צורך להקים עליה ZFS ועל זה GlusterFS), נחבר את המכונות ברשת פרטית וברשת "ציבורית") (כלומר 2 כרטיסי רשת וירטואלית פר VM של GlusterFS) והרי לנו תחליף ל-VSAN שיכול לתת לנו iSCSI, CIFS, NFS, אחסון אובייקטים (Object Storage) ועוד ועוד. בשביל ביצועים ושרידות נצטרך עוד מכונה כזו (עדיף עוד 2) – ויש לנו אחסון עם שרידות חזקה וביצועים גבוהים, ובו זמנית אפשר להריץ על השרתים עוד מכונות VM, ואת כל זה נעשה דרך ה-vSphere, כך שמבחינת עלות – שילמנו רק על החומרה ולא הפכנו את השרתים היעודיים לסטורג' בלבד (כך שלא נצטרך לבזבז שרתים). מבחינת גיבוי – זה VM ואפשר לגבות בכל תוכנה שמשתמשים בחברה (רק שחשוב לזכור לא לגבות את כל ה-VM שמריצים GlusterFS אלא רק אחד, חבל לשמור את הנתונים באותו גיבוי 3 פעמים).

סיטואציה שניה – אפליקציות
קונטיינרים הם ה"שוס" בשנתיים האחרונות ורבים מעבירים חלק מהמערכות לרוץ בקונטיינרים, שזה מעולה, אבל בחלק מהמקרים עדיין מעדיפים להריץ אפליקציות מסויימות בהכפלה וכו', לדוגמא MySQL על 2-3 מכונות VM, שרתי Front ו-Back על מספר מכונות VM ועוד. בכל המקרים הללו, באותם שרתים ניתן להקים GlusterFS כ-VM כמו שתיארתי לעיל (עם פחות דיסקים, רק חשוב שיהיה לפחות SSD אחד שישמש כ-Cache) ואז ה-DATA של האפליקציה (לדוגמא עם MySQL התיקיה var/lib/mysql/) תשב ב-GlusterFS (איך עושים? עוקבים אחרי ההוראות כאן), ה-WWW של שרת ה-Web ישב ב-GlusterFS וכו' וכו'. יהיו מספר שינויים קטנים שצריך לבצע (אולי להשתמש ב-HAProxy), וכך נוכל לקבל שרידות רצינית ומהירות משופרת בהרבה מכיוון שכל שרת אפליקציות יכול לקבל נתונים משרת GlusterFS קרוב וסינכרון הנתונים הוא מיידי – מבלי להשקיע כספים רבים.

סיטואציה שלישית – קונטיינרים/Kubernetes/Openshift
קונטיינרים רצים בד"כ על שרתי VM וקבצי ה-YAML, קבצי קונפיגורציות יושבים על דיסקים מקומיים אך ניתן להגדיר את ה-VM שירוצו על דיסקים וירטואליים שה-vSphere יקבל מ-GlusterFS דרך NFS או iSCSI. בנוסף, ניתן להגדיר Volumes עבור ה-Pods שישתמשו ב-GlusterFS (גם Kubernetes וגם אפליקציות שמריצות את Kubernetes כמנוע כמו Rancher, OpenShift וכו' תומכים ב-GlusterFS החל מ-Kubernetes 1.5). ואנחנו יכולים להשתמש לדוגמא ב-Volume מסויים במספר Pods במקביל, ועם GlusterFS ניתן לוותר על הרצת קבצי YAML/JSON ליצור את ה-Volumes ולגשת ישר ל-Volume Claim, המערכת תיצור את ה-Volume אוטומטית.

סיטואציה רביעית – בענן
מכיוון של-GlusterFS לא אכפת מה נמצא מתחתיו (דיסק מסכן, EBS וכו'), אפשר להקים את GlusterFS גם בענן. כל מה שאנחנו נצטרך הם מספר Instances (מומלץ 3 ומעלה לפרודקשן, 2 לטסטים) ולאותם Instances (שישמשו כ-Nodes) נחבר 2-3 אחסוני EBS ונתקין את GlusterFS ומשם אנחנו יכולים להשתמש ב-GlusterFS כפתרון אחסון לצרכים שלנו.

סיטואציה חמישית – קרוב רחוק
הקמה של GlusterFS זה דבר טוב ועוזר, אולם לפעמים אנחנו צריכים את הנתונים בחוץ, בחוות שרתים אחרת בארץ או בחו"ל. לשם כך, החל מ-GlusterFS 3.8 ומעלה ניתן להריץ Geo Replication לסנכרן בין מספר Volumes (בשיטת Master/Slave), ואפשר גם לספק צרכים "מופרעים" כאלו:

סיטואציה 6 – פתרון אחסון ל-VDI
הקמת VDI למאות עובדים זה פרויקט מורכב עם עלויות אסטרונומיות. (בימים אלו אני מנסה בבית להקים פתרון VDI עם דגש על מחירים נמוכים, ברגע שאצליח, אפרסם פוסט על כך). יש צורך לשלם למיקרוסופט, ל-VMWare וכמובן כל נציג מכירות יאמר לך – All Flash Array, כך שאם תרצה פתרון VDI טוב, תחשוב על כך סכום של 7 ספרות.

האם GlusterFS יכול לחסוך כאן במחיר? התשובה היא בהחלט. נתחיל בגירסה הזולה: זוכרים שהמלצתי על השרתים הישנים להרצת GlusterFS? אנחנו נשתמש בכאלו בגודל 2U עם פאנל קידמי של כונני 2.5 אינטש כך שאפשר יהיה להכניס בין 16 ל-24 דיסקים 2.5". לתוכם נכניס דיסקים 850 PRO של סמסונג בגודל שתבחרו, יש עד 2 טרהבייט (יש לוודא שהבקר דיסקים תומך במצב JBOD ושהוא תומך ב-SATA-3, אם לא – יש צורך בבקר אחר) ונכניס את הדיסקים הנ"ל למגירות ונצטרך לרכוש או אינטל 900P בגודל 480 ג'יגה או 2 כרטיסי אינטל 900P בגודל 280 ג'יגה, הכל לפי התקציב (עם 2 כרטיסים השרידות הרבה יותר גבוהה). על כל שרת כזה נקים ZFS עם Hot Spare ל-2 דיסקים SSD. כל ה-RAID יוגדר דרך ה-ZFS (כלומר RAIDZ לפי תצורה שמחליטים) ועל זה נקים את GlusterFS. את החיבור בין השרתים נחבר ב-10 ג'יגהביט (נחושת, SFF, FC – החלטה שלכם) ואת הזכרון נמלא ב-ECC 3 8500R (שהוא פחות מהיר אבל המהירות אינה ממש חשובה כשהשרת משמש Node ל-Gluster, הזכרון משמש בראש וראשונה כ-Cache ב-ZFS) עד המקסימום. המחיר לא כזה יקר: 2000 שקל (תלוי מהיכן אתם קונים) ל-192 ג'יגהבייט זכרון. נצטרך 3 מכונות. שימו לב: בשרת כזה נרוץ "על הברזל" ללא וירטואליזציה כלל ונוכל לגבות אותו כמו כל תחנת לינוקס (אם כי צריך לגבות רק אחד מהם, לא את שלושתם).

אם יש לכם כמה וכמה שרתים ישנים, אפשר לפצל את כמות הדיסקים לפי כמות השרתים הישנים שלכם (לדוגמא – 6 דיסקים בשרת 1U) ובכך לקבל ביצועים יותר גבוהים הואיל ולא מדובר בסיטואציית Active/Passive אלא עבודת קריאה/כתיבה מקבילית לכל המכונות.

אם מצד שני יש תקציב – אפשר לרכוש 3 שרתים כשהפאנל הקדמי שלהם הוא NVME ונרכוש דיסקים NVME U.2 – גם סמסונג וגם אינטל מוכרים דיסקים מעולים, והעלות משתנה לפי גודל הדיסק והפירמה שקונים ממנה. מבחינת רשת, תצטרכו לחשוב איך לחבר את הכל מכיוון שברוטו, תעבורת הקריאה מגיעה בין 40-60 ג'יגהבייט לשניה. אפשרי לצמד מס' כרטיסי רשת 10 ג'יגהביט או לרכוש כרטיסים ו-Switch של 40 ג'יגהביט (מלאנוקס, אינטל וכו' ישמחו למכור לכם). עם ההצעה הזו, המחיר שתצטרכו לשלם בהשוואה לפתרון אחסון מבוסס AFA (כלומר All Flash Array) יהיה נמוך יותר ב-50-70% מפתרון קופסא, וגם יש לכם שרידות יותר גבוהה.

בכל שאר הפרמטרים (וירטואליזציה, רשיונות וכו') – הכל נשאר אותו דבר.

ומה עם תמיכה? רד האט מוכרת את פתרון ה-GlusterFS כמוצר (Red Hat Gluster Storage) עם תמיכה מסביב לשעון.

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

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

אחד מול השני: Ceph מול GlusterFS

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

2 הפתרונות שבגינן יש בלבול רב הם GlusterFS מול Ceph. למרות ש-2 הפתרונות הם פתרונות Scale Up, יש שוני גדול ביניהם שכדאי להכיר לפני שחושבים לאמץ פתרון זה או אחר.

נתחיל ב-Ceph. מערכת Ceph היא מערכת "חייתית" שהמטרה שלה אחת היא: לתת ביצועים מקסימליים לחברות שמוכנות להשקיע בתשתית. באופן עקרוני, מערכת Ceph שולטת במכונות האחסון בדברים מ-א' ועד ת' – הן שולטות על הדיסקים, המערכת שולטת לאן כל דבר יכתב ואיך יכתב ומהיכן צריך לשחזר ואיך לשחזר במקרה שקם צורך להתקין מכונה אחרת במקום אחת שהלכה, ובגלל זה חישוב האחסון הוא מעט שונה: על כל ג'יגהבייט שתרצה לאחסן, תצטרך בדיסקים מקום של 3 ג'יגהבייט לערך (יותר בכיוון 2.4) ומכונה אחת אינה מספיקה, יש צורך ב-3 מכונות (כאשר כל מכונה היא בעצם שרת 2 או 3U מלאה בדיסקים מכניים וחלק SSD) עם הרבה זכרון, רוחב פס של 40 ג'יגהביט (המינימום הוא 10 ג'יגהביט) ועם מעבדים חזקים, כך שכל דרישה להגדיל כמות אחסון או מענה מבחינת מהירות ורשת ללקוחות – מצריך הוספה של מכונות (במדריך ההטמעה של SuSE לדוגמא יש "רשימת קניות" מה הדרישות חומרה פר Node).

מי שיציץ בלינק יחשוב בוודאי שזה נשמע מוגזם מבחינת דרישות חומרה, וכאן בדיוק העניין: זהו פתרון שאינו מתאים לחברות קטנות ובינוניות. זה פתרון שיכול להתאים לבנקים, קופות חולים, חברות ביטוח, חברות פיננסיות גדולות שיש להן המון DATA ואותם נתונים אמורים להיות זמינים בכל דקה, 24/7/365 ועם Latency מאוד נמוך. האם הן כבר אצות רצות להטמיע? התשובה היא "עדיין לא". מנמר"ים, מנהלי IT ו-CTO רבים צריכים בשביל זה "להחליף דיסקט", וכשאני שומע מהם שהם מחפשים פתרון שיהיה Active/Active או Active/Passive אז אני מבין שהם עדיין לא ממש "נכנסו לראש" של Scale Out.

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

עם GlusterFS המצב שונה לחלוטין. נתחיל בכך שאם ב-Ceph כל השרת 2U/3U מיועד לשימוש הסטורג', ב-GlusterFS המצב הפוך. אם לדוגמא אתם מריצים vSphere/ESXi, אז אתם בוודאי מכירים את העניין שאפשר לעשות boot ל-ESXi מ-Disk on key או PXE ואין צורך בדיסק קשיח מקומי להתקנת ה-OS, אז אפשר על אותה מכונה להקים ESXI, להקים VM עם נניח 16 ג'יגהבייט זכרון, ולמפות אל ה-VM את כרטיס ה-RAID עם הדיסקים. ונצטרך להגדיר גם 2 חיבורי רשת פיזיים (האחד לקבל שרותים מה-Gluster והשני לחבר את כל המכונות שישתתפו ב-GlusterFS). לא צריך שרת חדש נוצץ מהניילונים, גם שרת R610/R710 דור 11 של DELL, שרתי HP G7, שרתי X3550/3650 M2 של לנובו/IBM יתאימו למטה (כל עוד הבקר תומך ב-SATA במהירות 6 ג'יגהביט), אפשר למלא דיסקים פשוטים (WD RED PRO ואחרים שנותנים מהירות 7200 RPM) ואולי 1-2 דיסקים SSD בחיבור SATA. שאר משאבי המערכת ישומשו טובת הרצת אפליקציות אחרות, מכונות וירטואליות, קונטיינרים (בפוסט קרוב אדגים איך Gluster FS יכול לעזור ל-Kubernetes בכך שתצטרך מעתה לבקש רק Volume Claim מבלי ליצור Volume, המערכת תיצור אוטומטית וניתן לגשת לאותו Volume ממספר קונטיינרים במקביל) וכו'.

גם כאן, כמות המכונות המשתתפות ביצירת Volume יכולה להיות מינימום 2 אך עדיף ברוב המקרים להתחיל עם 3, רק שכאן אם אתם רוצים להישאר עם 3 ולהוסיף דיסקים לדוגמא, חברו JBOD עם הדיסקים, צרו מהדיסקים דבר שנקרא Brick, והוסיפו אותו ל-Volume קיים. זה יספיק. מבחינת File system, ל-Gluster FS זה כלל לא משנה. תקים ZFS על הדיסקים ועל זה תריץ GlusterFS? אין בעיה. תרצה לפרמט עם בקר ה-RAID שלך את כל הדיסקים לאיזה RAID מסוים ועל זה להריץ GlusteFS? אין שום בעיה. גם כמות הדיסקים אינה ממש משנה, ואפשר אפילו להתחיל בדיסק יחיד (לא כל כך מומלץ אלא אם זה דיסק וירטואלי).

עכשיו החלק היותר מעניין: החלק הכי קריטי בבחירת מערכת זה החלק של השרותים. איזה שרותים אפשר לקבל עם הפתרון? גם עם Ceph וגם עם Gluster FS, אתה יכול לקבל את אותם פתרונות. רוצה iSCSI MP? יש. NFS כולל גירסה 4.1 או PNFS? יש. רוצה Object Store? יש. שרידות במקרה ששרת פיזי נופל? יש. מחפש Deduplication? ב-Gluster FS ניתן לקבל זאת כשמפרמטים את הדיסקים עם מערכת ZFS ובדרך גם ניתן לקבל דחיסה. (ב-Ceph כרגע אין את זה). מה עם Caching ו-Erasure Coding? יש ב-Ceph ויש גם ב-Gluster FS, וכן, לשתיהם יש גם ממשק WEB.

מה עם שרות ותמיכה? לגבי Ceph – גם SuSE ישראל וגם רד-האט ישראל (דרך הנציגים שלהם בארץ) מוכרים חבילה מסחרית ותמיכה מסביב לשעון של Ceph (ב-Suse זה נקרא SuSE enterprise storage 5, ב-רד-האט זה נקרא Red Hat Ceph Storage) עם תמיכה מסביב לשעון. כשזה מגיע ל-Gluster, רד-האט מוכרת את Red Hat Gluster Storage. אני ממליץ לשים לב לנקודה עקרונית: לא מומלץ להתקין את התוכנות אם אתם לא קונים ואין לכם מישהו שיתמוך לכם בתוכנה. נכון, Gluster FS לוקח חצי שעה להקים, אבל כשהתקלות מתחילות, אם אין ידע, זה כאב ראש (במיוחד ב-Ceph).

לסיכום: למי שמחפש פתרון סטורג' Scale Out, אלו 2 פתרונות טובים עם "גב" מאחוריהם. הפתרון של Gluster הוא טוב והוא יכול לתמוך גם בפטהבייט בלי שום בעיה והוא יכול להתאים לכל גוף שמחפש לעצמו פתרון אחסון חזק עם שרידות מעולה. הפתרון של Ceph לעומת זאת הוא פתרון "מפלצת" שנועד בראש ובראשונה לשרת אלפי, עשרות אלפי ומאות אלפי לקוחות בו זמנית ובנוסף, 2 הפתרונות נותנים לכם חופש מוחלט בבחירת הציודים שישמשו לאותו פתרון סטורג', כך שאין צורך יותר לשלם אלפי שקלים נוספים פר דיסק בגלל .. מדבקה (וכן, אני עומד מאחורי ההצהרה הזו). פתרון Active/Passive או Active/Active זה אחלה, אבל פתרון עם 3 מכונות נותן שרידות הרבה יותר טובה וגם נהנים ממהירות הביצועים.

כמה מילים על לימוד-מכונה ועל GPU ועננים

עדכונים לפוסט – בסופו.

בשנים האחרונות, תחום ה"לימוד מכונה"/"לימוד עמוק"/"AI" ושלל שמות נוספים (ותוסיפו לכך טונות של Hype) קיבלו תאוצה מאוד חזקה. כיום התחום "חם" מאוד ואלו שמכירים את התחום נחטפים, וחברות כמו אמזון וגוגל מציעות משכורות מאוד מפתות (כמה מפתות? 50K ומעלה לחודש, בשקלים כמובן, ויש גם מענק חתימת-חוזה, תלוי כמה אתה מכיר, וכמה אתה מנוסה). סטארט אפים לנושאים אלו צצים כמו פטריות לאחר הגשם וכמובן שחברות הענן הציבורי הזדרזו להוציא שרותים שמציעים תחומים אלו בקלות מופלאה – תכניס את ה-DATA, הנה API קל לשימוש ובהצלחה.

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

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

  • אתה בונה את התוכנה (או משתמש בשילוב של Tensorflow, Caffe2 ושאר ספריות) ו"מסביר" לתוכנה מה אתה בעצם רוצה לעשות.
  • אתה מכניס את הנתונים שאתה רוצה לעבד.
  • אתה מכוון שוב ושוב ושוב ו"מאמן" את האלגוריתמים שהתוכנה תכיר את הנתונים ותתן תוצאות שאתה רוצה שתתן – עד לתוצאות שאתה רוצה.

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

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

זה – במבט על מגבוה בערך מה שקורה.

הבעיה מתחילה כשמקימים את החלק הראשון בענן. כיום, ברוב המקרים מומלץ לעשות את הדברים על GPU הואיל והוא מכיל אמנם "ליבות טיפשות" שמסוגלות לעשות רק דברים פשוטים, אבל יש אלפי ליבות פר GPU ולכן העיבוד יהיה הרבה יותר זריז מאשר לבצע אותו על CPU. הבעיה מתחילה בכך שאינך מקבל מקבל GPU יעודי עבור המכונה/מכונות שלך אלא רק חלק ממנו. כמה? אף ספק לא אומר, אבל אני יכול להמר על 1/8 או יותר נמוך (1/16, תלוי כמה GPU יש במכונה, תלוי כמה VM רצים עליה ושאר פרמטרים).

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

חברות גדולות שעוסקות בתחומים הללו כבר למדו שבכל מה שקשור לאימון, עדיף לעשות זאת In house ולא לסמוך על עננים, ומכיוון שהן חברות גדולות, הן יכולות להרשות לעצמן לרכוש מכונה כמו ה-DGX-1 של nVidia. כמה עולה המכונה הזו? 130,000 דולר, סכום שאין להרבה סטראטאפים או חברות קטנות או בינוניות. בשרת זה ישנם 8 כרטיסי Tesla מבוססי Volta (הארכיטקטורה החדשה של nVidia) שכוללים ליבות יעודיות ל-Tensor והרבה ליבות שמיועדות ל-CUDA. בנוסף, הכרטיסים מחוברים ביניהם עם NVLink שנותן מהירות מדהימה של 200 ג'יגהבייט לשניה פר כרטיס. בקיצור – מפלצת יעודית ל-AI/DL/ML. (אפשר ללחוץ על התמונה על מנת לקבל את הפרטים).

לאחרונה חברת nVidia הבינה שאותם חברות קטנות ובינוניות מעוניינות גם בפתרון. הם לא מחפשים לקנות DGX-1 והם מעדיפות פתרון יותר זול אך חזק. כרטיסים גרפיים כמו GTX 1080TI או אפילו Titan Xp הם טובים, אך המהירות עדיין אינה מספיקה.

לכן nVidia הוציאה בימים האחרונים את הכרטיס מימין. תכירו – זה ה-Titan V, ה"אח הקטן" של Tesla V100. מדובר על כרטיס עם אותו GPU כמו אחיו הגדול, אך יש לו 12 ג'יגהבייט זכרון (ב-Tesla יש 16), אין אפשרות לשרשר אותו עם Titan V אחרים (ואין SLI) ויש עוד מס' הבדלים – טבלת השוואה ניתן לראות כאן. אגב, אם אתם רוכשים כרטיס כזה, שדרגו ל-CUDA 9.1 שידע לתמוך בכל הפונקציות של הכרטיס.

מחיר הכרטיס (לא כולל מסים ומכס) – 3000$. יקר בהרבה מכל כרטיס אחר שמיועד ללקוחות פרטיים, אבל עדיין זול בהרבה בהשוואה ל-Tesla V100 (שאותו בין כה לא תוכלו להכניס לרוב השרתים). עם כרטיס כזה, אני יכול להבטיח לכם שהביצועים שלו יהיו גבוהים בהרבה מכל Instance עם GPU שתרימו בענן. (ניתן כמובן להרים מס' מכונות VM בשרתים מקומיים ולכל מכונה להצמיד GPU כזה בשיטת GPU Passthrough, כדאי לשאול את יצרן השרת לגבי התמיכה ב-Passthrough ולגבי IOMMU).

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

השלב השני לעומת זאת, עדיף לבצע אותו בענן, מכיוון שהתהליך ה-Evaluation של המידע שנכנס מהלקוח הוא הרבה יותר קצר ולכן גם חלק מ-GPU יכול להספיק לכך, מה עוד שבענן הרבה יותר קל לעשות Scale Out ולשרת בכך יותר ויותר לקוחות.

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

עדכון 17/12/17: קיבלתי פניה לגבי מידע שגוי שאני מפרסם בפוסט זה ולכן אני רואה צורך להבהיר: אינני אומר ששום ענן ציבורי לא נותן תשתית מואצת GPU (במקרה של אמזון ומיקרוסופט – Tesla ובמקרה של גוגל – TPU). כולם נותנים שרות SAAS כזה או אחר ל-ML/DL מואצים, אבל זהו שרות SAAS. למי שמחפש פתרון VM או קונטיינרים נטו שבהם הוא יכול להשתמש בפשטות ב-tensorflow-gpu עם PIP ועם הקוד שלו – זה כרגע למיטב ידיעתי והבנתי – לא קיים.

תכירו את Kubevirt

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

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

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

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

אחת הבעיות שנוצרות מהכנסת קונטיינרים ומערכת ניהול/אורקסטרציה (כמו Kubernetes, OpenShift, Docker-swarm ואחרים) היא שמעתה צריך לנהל 2 מערכות שונות. האחת לניהול השרתים הוירטואליים שלכם (Hyper-V, vSphere) ואחד לניהול הקונטיינרים שלכם ולמרות שברמה העקרונית שתיהן מרימות דברים שהם מופרדים (קונטיינרים, VM), יש תהום של הבדלים ביניהם:

  • ב-Kubernetes הרשת מנוהלת בצורה אחרת לגמרי
  • כל עניין ה-Clustering הוא משהו שונה וחדש שלא קיים בשום פתרון וירטואליזציה
  • דיסקים בכלל מוגדרים בצורה שונה ואין אפשרות לנהל את ה"דיסקים" בפתרון כמו Kubernetes (להגדיל, להקטין דברים שקיימים)
  • שיטת העבודה עם Kubernetes (ו-OpenShift) היא בכלל שיטה "הצהרתית" (כלומר אתה מצהיר מה אתה רוצה שיקרה, המערכת עובדת על לקיים את רצונך. Genie כזו 🙂 ).

יחד עם זאת, לא היה נחמד יותר להשתמש ב-Kubernetes (או OpenShift או CAAS של SuSE)?

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

תכירו את Kubevirt.

הרעיון של Kubevirt הוא די פשוט: בתוך Kubernetes יש דבר שנקרא CRI (ר"ת Container Runtime Interface). פרויקט oVirt מרחיב את ה-CRI ואת Kubernetes עצמו כך שיוכל להפעיל גם מכונות וירטואליות כאילו מדובר בהפעלת קונטיינרים. בד"כ ע"מ ליצור POD עם קונטיינר, אנחנו יוצרים קובץ בפורמט YAML (או JSON, בהתאם להעדפות), וכאן הדברים יהיו דומים. הנה דוגמא לקובץ YAML כזה.

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

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

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

על נקודות חשובות בעת מעבר לענן

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

בפוסט זה אני אעלה מספר נקודות ואתייחסן אליהן.

שרותי SAAS כחלק ממעבר לענן
SAAS (כלומר Software As A service) זה דבר מעולה, בתנאים ובדברים מסוימים. צריך לשלוח עשרות אלפי מיילים? יש כמה ספקי SAAS וסביר להניח שספק הענן שתבחר (טוב, למעט Azure לפחות ממה שידוע לי) שישמחו להציע לך שרות כזה. אם תיקח עצמאי שיקים לך דבר כזה, זה יעלה לך לא מעט, ובנוסף יש צורך לתחזק זאת ברמה שבועית או פחות (RBL, Black List ושאר צרות שמגיעים עם זה), כלומר במקרה כמו המקרה הנ"ל – השימוש ב-SAAS הרבה יותר זול מבחינת עלות ראשונית (ואולי גם בהמשך, תלוי בכל מיני פרמטרים) והוא שרות מוצדק.

לעומת זאת, אם לדוגמא אתה צריך שרות כמו MySQL או PostgreSQL בתצורה כמו Master ו-2 Slaves שיהיו מותקנים באזורים זמינים (Availability Zones במושגים של AWS), יהיה לכם יותר זול להקים זאת בעצמכם עם MariaDB (ו-Galera) לדוגמא, מכיוון שאתה יכול לבחור איזה גודל מכונה שתרצה (ולא רק מה שיש מבחינת SAAS), וגם התחזוקה עצמה אינה מסובכת. הבעיות הנפוצות ביותר שקיימות עם SQL (ולא חשוב איזה SQL) הם בד"כ השאילתות שנכתבות ע"י צוות הפיתוח וחוסר אופטימיזציה, וכאן שרותי SAAS לא יעזרו הרבה כי בסופו של יום – יותר קל וזול לתקן שאילתות מאשר להוסיף 20 שרתי רפליקציה ל-SQL.

מה שמוביל לנקודה הבאה..

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

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

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

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

מה שמוביל לנקודה הבאה..

סקריפטים, קוד ואוטומציה
כשיש לנו תשתית פנימית שנמצאת בחדר השרתים, סביר להניח שצוות ה-IT יכתוב במהלך הזמן עשרות או מאות סקריפטים (ב-PowerShell, Bash, Python, Ruby וכו') על מנת להריץ דברים מסויימים כמו תהליכים מתוזמנים (Cron), ניקוי ומחיקת קבצים ועוד עשרות דברים שונים.

בענן הציבורי לעומת זאת, לרשותכם עשרות או מאות שרותי SAAS שונים וכל אחד מהם צריך הגדרות שונות על מנת שיפעל ויבצע מה שהשרות צריך לבצע, ובמקרים רבים הדבר שנעשה ע"י הצוות הוא כתיבת סקריפטים שיעשו את הדברים או שמכניסים את הקוד לאפליקציה שכותבים שרצה לדוגמא ב-Back end, וכאן בד"כ ישנם 2 בעיות:

  • במקרים רבים לאבטחת המידע לא ניתנת החשיבות המספיקה ובמקרים רבים הסקריפטים מכילים מפתחות של החברה, מה שעלול להוביל למצב שאם סקריפט דולף (או חמור מכך – המפתחות דלפו) – מישהו ישתמש במפתחות ליצור מכונות או שרותים שהחברה תשלם עליהם (וזה קרה בעבר לגוף גדול). בנוסף, שרותי SAAS שונים מצריכים הגדרות נוספות לשם אבטחת מידע, מה שלא תמיד מקבל מספיק יחס מבחינת הכותבים, מה שיוצר מצבים לא נעימים.
  • אחד הדברים הכי חשובים להכניס ולהטמיע בחברה הם כלי אוטומציה או כלים לעבוד עם הענן, כלים שהם ידועים במקום להמציא את הגלגל. כך לדוגמא, עבודה עם Terraform או כלי אוטומציה כמו Ansible, Puppet, Chef הם דרכים הרבה יותר טובות כדי לבצע מה שצריך, מכיוון שכלים אלו כוללים כבר תמיכה ב-API החדש של ספק הענן (בד"כ יש צורך בעדכון גירסת הכלי ושינויים קטנים בקוד שנכתב תוך שימוש בכלי על מנת לקבל את הפונקציונאליות החדשה), וכלים כאלו נותנים גם תמיכה יותר טובה בהצפנת מפתחות, קבלת פלט מסודר בהרצת הדברים ועוד. אלו דברים שהרבה יותר קשה לתחזק בקוד ללא אוטומציה שנכתב כולו בחברה.

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

מה שמוביל לנקודה הבאה…

אימוץ טכנולוגיות חדשות
הנה אחד הדברים שאני שומע: "אנחנו מעוניינים שתקים לנו את הדברים בקונטיינרים, אנחנו רוצים גם לעבוד ב-CI/CD עם Jenkins ושהכל יהיה עם Auto Scaling".

לי אישית, אין לי שום בעיה לתת את השרות הזה, בין אם בעבודה עם ECS, עם Kubernetes, עם Swarm או Kubernetes ואין לי גם בעיה לעבוד עם Jenkins. זו לא הבעיה. הבעיה בד"כ היא מה קורה עם הצוות שלך. כל הכלים שציינתי לעיל מורכבים מאוד (ועוד לא דיברנו על שרותי ה-SAAS השונים שספק הענן מציע והחברה רוצה להשתמש בהם).

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

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

הצורך באיש DBA

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

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

לא חשוב מהו שרות ה-SQL המותקן בשרת, בד"כ הם עושים את העבודה Out of the box בצורה טובה יחסית, אבל במקרים רבים לקוחות מתלוננים על כך שהעבודה שהוא מבצע היא איטית, החשש שהטבלאות גדולות מדי, ומדוע דבר שרץ מקומית על המכונה של המפתח לוקח 0.1 שניות – על השרת לוקח 4 שניות לדוגמא..

כאן הבעיה מתחילה בחלק שלא קשור לסיסטם, אלא בחלק שקשור למפתחי האפליקציות. ישנם לא מעט מקרים שראיתי שבהם שאילתות נכתבות בצורה שתגרום לשרת SQL "להזיע" עם שאילתות באורך 6-10 שורות ובסופו של דבר לא קיימת אופטימיזציה של השאילתות, כך שהשרת SQL עצמו הוא בסדר גמור, אבל מה שהמפתח שולח – "חונק" את השרת, תכפילו את בקשת השאילתות פי 100 או 1000 (פר גולש) – וקיבלתם מערכת שיכולה להיתקע גם אם יש בשרת 32 ליבות!

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

אישית אני מודע לכך שלכל שרת SQL יש הגדרות של Cache שעוזרות בהאצת עיבוד השאילתות וקריאה/עדכון/מחיקת נתונים מה-SQL, אבל בד"כ ממה שראיתי – אם כבר בהתחלה רצים לשנות את גודל ה-Cache, אותן בעיות יצוצו שוב בהמשך, כי הבעיה היא לא ב-Cache והגודל, אלא בצורת השאילתות.

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

בהזדמנות זו – אם ישנם אנשי DBA פרילאנסרים – אשמח אם תשלחו לי מייל ([email protected]) עם הפרטים שלכם כך שאם פונים אליי ומבקשים שרות זה – אפנה אותם אליכם.

על OpenShfit, הטמעה וציפיות בחברות

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

חלק לא קטן מהטענות ששמעתי הגיעו מצד גופים שחשבו ש-OpenShift זה כלי עם GUI מרשים ל-Kubernetes. הנחה זו היא די מוטעית. אם מחפשים GUI וכלי ניהול בשביל Kubernetes, אפשר להסתכל על מוצר בקוד פתוח שלא עולה כלום כמו Rancher. לעומת זאת, Openshift זה כלי שבא לתת לך הכל ללא צורך בהזדקקות לשרותים חיצוניים מהאינטרנט כמו Containers Registry וכו'.

על מנת להבין יותר את התפיסה של OpenShift, נדמיין סיטואציה אחרת לחלוטין: יש לנו 10 מפתחי JAVA ויש לנו שרת לינוקס גדול ורציני. למפתחים יש משתמש משלהם (נניח דרך אוטנתיקציית AD) על שרת הלינוקס ועל השרת מותקן באופן מרכזי ה-JDK וכלים אחרים שהמפתחים משתמשים, וכל מפתח יכול לבצע login ולבצע checkout מה-GIT המרכזי ולהריץ את האפליקציות JAVA שלו. אין צורך שיהיה לו ידע בניהול מערכת לינוקס, אבל מומלץ שיהיה לו ידע ממש בסיסי ב-BASH, ודברים פשוטים אחרים שאפשר ללמוד בשעה שעתיים – בשביל להריץ את מה שהוא כתב. מי שינהל את שרת הלינוקס מבחינת הגדרות, עדכונים וכו' – תהיה מחלקת ה-IT בחברה. לחובבי Windows אפשר לדמיין את הסיטואציה כשרת Windows שנותן שרותי RDP וכל משתמש נכנס עם המשתמש המאושר שלו והוא עושה מה שהוא צריך לעשות. הידע שהוא צריך – הוא שימוש בסיסי ב-Windows, לא יותר מזה.

השוני הכי גדול בין Kubernetes ל-OpenShift מבחינת כל מה שקשור לקונטיינרים – היא הגישה. ב-Kubernetes אם אני רוצה לבצע Deploy, לבצע Scale, רפליקציה, כתיבת שרותים ודברים רבים אחרים – אני צריך לכתוב קבצי YAML (או JSON) שאותם אני צריך להזין ל-Kubernetes ואני צריך גם לבדוק לוגים כדי לראות שכל רץ תקין, ולכן בחברות שמשתמשות ב-Kubernetes רוב העבודה הזו נופלת על איש ה-Devops. לעומת זאת, עם OpenShfit, הדברים בנויים יותר בכיוון שרת הלינוקס וה-JAVA. עם OpenShift אני מגדיר משתמשים (ומחבר את OpenShift ל-AD על מנת לשמור על סינכרון שם משתמש/סיסמא/הרשאות) ואותו מפתח יכול להריץ דברים ישירות דרך ה-CLI או ה-GUI ויש לו כלים מוכנים כדי שהוא לא יצטרך לשכתב קבצי YAML כדי לבנות קונטיינרים עם הקוד שלו בתוך ה-OpenShift. אם הוא רוצה לבצע לדוגמא Scale או Deploy, הוא פשוט יכול ללחוץ כמה קליקים ולהשתמש ב-Template מוכן, לתת שורת כתובת של ה-GIT שלו, ותוך דקות ספורות ה-POD עם הקונטייר/ים שלו ירוצו, הוא יכול לראות מתוך ה-GUI את הלוגים ואף לקבל גישת טרמינל מוגבלת לתוך הקונטיינר כדי לבדוק אם הכל תקין וכו' וכו' ואם הוא רוצה לשמר את מה שהוא עשה בתור קובץ YAML/JSON, המערכת תשמח ליצור עבורו את הקובץ הנ"ל.

לכן, מבחינת חברה, OpenShift עושה את החיים יותר קלים מבחינת הטמעה ושימוש בקונטיינרים, ניהול תשתית המכונות המריצות את OpenShift ואת הקונטיינרים עצמם, כלומר הצורך במישהו יעודי רק כדי להריץ דברים בקונטיינרים פוחת ואפשר להוציא זאת לשרות חיצוני או ללמד את צוות היוניקס/לינוקס את הדברים הדרושים, ובנוסף קל לראות אם ישנן בעיות בתשתית ה-OpenShift (מערכת Heapster נותנת גרפים עשירים פר Node, פר POD וכו' וכו', וגם ניתן לחבר את OpenShift ל-ELK, גרפאנה ושאר החברים). בנוסף, מכיוון ש-OpenShift מבוססת על Kubernetes, ניתן ליישם את מה שרץ על OpenShift על מערכת Kubernetes במקרים לדוגמא בהם הוחלט ש-OpenShift ירוץ בפיתוח ו-Kubernetes או פתרון תואם רץ בפרודקשן (אם כי זה קצת יותר מורכב).

ונקודה אחרונה לגבי מחיר: אני מכיר כמה מנהלי IT ששמעו את המחירים של רד-האט ולסתותיהם נשמטו. נכון, מחירים פר Node אינם בדיוק זולים, אולם המחיר יורד לחמישית אם מריצים את ה-Node כמכונת VM ומעוניינים להריץ את הגירסה המסחרית. חוץ מזה שאישית – אני ממש לא ממליץ להריץ את OpenShift על "הברזל" אלא אם יש שם למחלקת ה-IT ידע ממש עמוק ורציני בלינוקס, אחרת אפשר להפיל Node (ולא חשוב אם זה Node לעבודה או Master) די בקלות. בכל זאת, לא מדובר על הפעלת Cluster קונבנציונאלי עם HeartBeat, PaceMaker וכו'.

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

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

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

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

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

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

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

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

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

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

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

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