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

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

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

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

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

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

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

הנה דוגמא: לא מעט חברות שנכנסות יותר ויותר בשימוש עננים ציבוריים "מגלים" כשהם משתמשים בלינוקס ומערכות CI/CD את האוטומציה, ותתפלאו – חברות רבות לדוגמא עד היום לא הכניסו שום אוטומציה. יש פלטפורמות אוטומציה רבות ללינוקס כמו Chef, Puppet, SALT ובוודאי עוד כמה – אולם אני ממליץ ספציפית על Ansible מכמה סיבות:

  • הקוד של "המנוע" – פתוח לחלוטין וכתוב ב-Python.
  • אין צורך ב-"שרת" Ansible. כל הפעילות היא Serverless לחלוטין.
  • הכתיבה של ה"תסריטים" (או Playbooks איך שזה נקרא ב-Ansible) היא פשוטה ולוגית. המשתמש יכול תוך שעה שעתיים אחרי שהוא קרא את התיעוד לכתוב דברים בסיסיים שיכולים לרוץ על המכונה שלו ומכונות אחרות, כך שעקומת הלימוד – היא די קטנה.
  • יש לכם שרתי Windows? אולי הגיע הזמן גם ששם תהיה אוטומציה? אז ל-Ansible יש גם מודולים ל-Windows, בין אם מדובר להתקין קבצי MSI, להגדיר IIS, להעתיק קבצים, פעולות דוט NET, ניהול משתמשים וקבוצות ודברים נוספים. העלות לחברה? יקרה מאוד .. אפס שקלים.
  • מחפשים ממשק Web? אתם יכולים לרכוש את Ansible Tower (וביחד עם זאת לקבל תמיכה רשמית מ-רד-האט) או שאתם יכולים להשתמש בממשק וובי אחר (ויותר בסיסי) בקוד פתוח שנקרא Ansible Semaphore.
  • חושבים לעבור לאוטומציה אחרת מסיבה כלשהי? לרוב המתחרים יש כלים אוטומטיים להעביר את ה-Playbooks שכתבתם אל המערכת החדשה (אם כי עדיין לא נתקלתי בחברה שעברה מ-Ansible למערכת אחרת).

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

אותו הדבר גם בכלים לניהול סביבת חיים (Life Cycle) של קונטיינרים וסביבות המורכבות מעננים פרטיים וציבוריים. ניקח לדוגמא את קטגוריית ה-CMP (כלומר Cloud Management Platform). בתחום זה יש מתחרים רבים, החל מ-VMWare עם ה-vRealize לגרסאותיו, RightScale, ועוד. האם פלטפורמות אלו מבצעות את מה שהן מבטיחות? בהחלט! אולם אם תפסיק לשלם את התשלום החודשי או השנתי, תיתקלו באחת מהסיטואציות הבאות:

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

לעומת זאת, במוצר כמו CloudForms שנותן לך לבצע CMP (כולל כמובן עמידה ברגולציות וכו'), אם לא בא לך לשלם יותר, אתה יכול לייצא ולייבא את ההגדרות, הקבצים והתכנים לגירסת הקוד הפתוח (ManageIQ) בדיוק כמו שאתה יכול לעבור מ-RHEL ל-CentOS מבלי לאבד פונקציונאליות או תאימות. כשזה מגיע לקונטיינרים, אתה יכול לעבור מגירסת OpenShift מסחרית ל-OpenShift Origin שמבוססת על Kubernetes כך שבעצם למעט שרותי תמיכה (שאותם תוכל לקבל מצד ג' בין כה), אינך מפסיד דבר. להיפך: אתה שומר על כל העבודה שהצוות ביצע ואפשר לאחר המרה לגירסת קוד פתוח – להמשיך לעבוד כרגיל.

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

שבוע טוב 🙂