תגית: עננים

מעבר לענן – תכנונים, עדיפויות ומציאות

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

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

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

ניקח לדוגמא תשתית פשוטה: יש לנו 2 מכונות, אחת מריצה MySQL והשניה מריצה שרת Web NGINX ושרת שלישי שמריץ אפליקציות על Tomcat. התשתית הזו נגישה החוצה לציבור שמבצע אותנטיקציה עם שם משתמש/סיסמא והתשתית יושבת מאחורי Firewall (ואולי מערכות הגנה נוספות).

אם נסתכל על התשתית הזו בתצורה המקומית, סביר להניח שהמכונה שמריצה את ה-NGINX תהיה חשופה (מבחינת כתובת IP) לאינטרנט עם פורט 80 או 443 פתוח החוצה ב-Firewall עם כתובת IP אמיתית או שתהיה כתובת חיצונית ב-Firewall שתמופה אל כתובת IP פנימית. יהיו כאלו שיטמיעו את מכונת ה-NGINX ב-DMZ עם 2 רגליים – אחת ב-DMZ ואחת ב-LAN, כך שה-NGINX יוכל לדבר עם ה-Tomcat ברשת הפנימית (מכונת ה-Tomcat ומכונת ה-MySQL לא יהיו זמינות מבחוץ כלל).

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

  • אנחנו נצטרך להקים VPC שיכלול:
    • חלוקה ל-Subnets ששם ישבו מכונות בהתאם לקטגוריות שאנחנו בונים: Prod, testing, stage, devel וכו'. רובם לא יקבלו כלל כתובות IP אמיתיות.
    • Internet Gateway שיתן ל-Subnet שנבחר גישת אינטרנט החוצה
    • Elastic IP – שיהיה מחובר ספציפית למכונת ה-NGINX
    • NAT Gateway – שיאפשר למכונות הפנימיות לגשת לאינטרנט מבפנים החוצה (אך לא ההיפך)
    • Network ACL – שישמש כ-Stateless Firewall על מנת להחליט מי יכול לצאת ודרך איזה פורטים
    • Security Groups (שהולכים עם Network ACL) – שם נגדיר ספציפית מאלו כתובות ואלו פורטים יוכלו להיכנס לשרת(ים).
    • ויש עוד כמה צעדים, וחברות רבות גם יוסיפו כאן אולי Appliance Firewall מסחרי בנוסף למה שאמזון נותנת ועוד ועוד…

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

לאחר מכן אנחנו נקים מכונות ב-EC2. נצטרך לבחור Template של מכונה מהקטלוג, בחירת ה-VPC, וכמובן – גודל Storage מקומי למכונה. כאן הדברים שונים מהסטורג' שנמצא אצל חברות – ב-AWS תוכל לבחור בין General Purpose SSD לבין Provisioned IOPS SSD שהוא הרבה יותר מהיר והאפשרות השלישית היא דיסקים מגנטיים (מבלי אפשרות לבחור IOPS). ההבדל (חוץ מביצועים) בין ה-General ל-Provisioned מתבטא לא רק בביצועים אלא גם במחיר (ב-Provisioned הוא הרבה יותר גבוה) וראיתי מספר מקרים שבחרו ב-Provisioned והתפלאו מדוע המחיר טס בכמה מאות דולרים פר מכונה. לאחר הגדרות הסטורג' נצטרך לבחור תגים (Tags) אם נרצה, את ה-Security Groups (אם לא הגדרנו קודם), מפתח PEM להתחברות ולבסוף נאשר את הכל ו-AWS יקים לנו את המכונה. לאחר מספר דקות נוכל להתחבר אליה אם הגדרנו שהיא תקבל כתובת IP אמיתית דינמית או ללא כתובת IP דינמית דרך מכונת Bastian או דרך חיבור Direct שיש לנו אל ה-VPC. משם נגדיר פנימית את המכונה, נקים עוד כמה מכונות וכו' וכו'.

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

אחד הדברים שיותר ויותר חברות מעוניינות בו, הוא פתרון ה-Hybrid, וכאן הדברים קצת מסתבכים..

כפי שציינתי לעיל, יש פתרון כמו VMWare on AWS שמאפשר לך "להרחיב" את המערכת המקומית שלכם לענן אך ממשיך להשתמש במושגים ובטכנולוגיות של VMWare. אם ניקח לדוגמא את 3 המכונות מהדוגמא הקודמת, נוכל בקלות לבצע עבורם Migrate לתשתית ה-VMWare on AWS בענן וכל מה שנצטרך לשנות לפני המעבר זה החיבור ל-vSwitch/DVSwitch, לבחור לאן לאחסן את המכונות ועוד מספר פרמטרים – והמערכת תבצע את השאר בצורה עצמאית.

חברות רבות לעומת זאת מחפשות משהו יותר "מעונן" – הן מחפשות דברים כמו שרצים בענן, אך שירוצו מקומית עם אפשרות שימוש ב-Hybrid להעברת עומסים, מבלי להיות תלוים בפתרון של VMware (או שהם כלל לא משתמשים ב-VMware). מיקרוסופט לדוגמא מציעה את Azure Stack – מדובר בערימה של שרתים שמריצים תוכנות, סקריפטים ודברים נוספים על המכונות הללו והתשתית הזו יושבת ב-DC המקומי של הלקוח והוא מקבל גירסה מזערית של Azure מקומית עם אפשרות להתרחב ל-Azure הגלובאלי ובכך לעבוד או מקומית בלבד תוך שימוש בכלים הרגילים על Azure (מתאים לגופים בטחוניים לדוגמא) או שימוש כ-Hybrid כמקומי והעברה פנימה והחוצה לענן הציבורי. גם אמזון הכריזה על פתרון דומה שנקרא AWS Outposts וגוגל גם בונים פתרון כזה (אם כי עדיין לא ראיתי שום הכרזה קונקרטית על משהו מצד גוגל).

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

אלו שרוצים משהו פחות מחייב ויותר מדבר על פתרון Hybrid שמתייחס לקונטיינרים ומכונות VM יכול להשתמש כמובן ב-Open Stack והוידאו הבא מסביר בהרחבה איך ניתן לחבר OpenStack מקומי לעננים הציבוריים השונים.

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

על עננים ציבוריים ותקציבים

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

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

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

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

כאן קיים איזה ניתוק בחלק מהחברות בין ההנהלה הבכירה לצוותי IT/פיתוח, והניתוק נובע מהרגל לשימוש ב-On Prem. אסביר:

נניח ואני חברה בשם X ויש לי חדר שרתים נחמד עם 5 ארונות, ו-100 שרתים פיזיים, תקשורת, סטורג', מיזוג וכו'. השרתים מריצים כ-1500 מכונות VM. נניח ועכשיו יש צורך להוסיף עוד 500 מכונות VM ויש לי משאבים פנויים בשרתים ובסטורג', אז תוספת העלות לחברה תהיה יחסית זניחה (אני לא מדבר כרגע על רשיונות פר OS כמו ב-Windows): עלות החשמל תהיה קצת יותר גבוהה. אם אצטרך לרכוש ברזלים כדי להקים את אותן מכונות VM, אז העלות שלהם תהיה עלות חד פעמית ואני יכול להשתמש בציוד הזה במשך 3-5 שנים בלי בעיה, אך בשורה התחתונה – ההוצאות הכספיות לגבי תוספת אותן מכונות VM הן צפויות.

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

ההבדל בין On Prem לשימוש בענן בלא מעט מקרים גורם לכך שחברות, לאחר ישיבות תקציביות שנתיות – מתחילות להתעניין באחת מ-3 האפשרויות הבאות:

  • "לחזור הביתה" – לתשתיות On prem
  • להתחיל לשוחח עם נציגי ענן מתחרה על שרותים זהים כמו שמשתמשים עכשיו אך במחיר יותר נמוך
  • קיצוץ מאסיבי בשימוש שרותי הענן, ואם משתמשים ב-Hybrid (כלומר On Prem ועננים) – לקצץ את השימוש בענן לצרכים הכרחיים בלבד.

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

מי שהסתכל בלינק יכל לראות שישנן תשובות שונות. אני אפרסם כאן את התשובות שלי:

  • בנוגע למעבר ל-On Prem ("חזרה הביתה") – אם מדובר על מכונות VM, אז זה אפשרי כמובן, אם כי סביר להניח שתקבלו אולי ירידה כלשהי בביצועים הואיל וספקי הענן בד"כ משתמשים במעבדים מהדור האחרון או זה שלפניו, בהשוואה ל-2-3 דורות אחורה שחברות משתמשות. בנוסף, תלוי בסיטואציה, יכול להיות שתצטרכו לרכוש ציוד נוסף כדי לארח את המכונות שמוחזרות מהענן.
    לעומת זאת – אם אתם משתמשים בשרותים שספקית הענן מציעה (RDS, S3, ELB ועוד שרותים רבים) – חלק מהם ניתן להקים מקומית בקלות (אם כי לא באותה שרידות – לדוגמא במקרה של S3) וחלקם מצריך משאבים ניכרים בכדי להקים משהו זהה רק ב-Scale קטן בהרבה (כמו Aurora), כך שבכל מקרה מדובר על הקצאת משאבים ניכרים שהולכים וגודלים ככל שהעברתם/הקמתם תשתיות וירטואליות בענן או שאתם משתמשים בשרותים המוצעים ע"י ספק הענן.
  • מעבר לענן מתחרה: "על הנייר" זה נשמע קל – מביאים את נציגי המתחרים, מבקשים מחיר נמוך וקרדיטים ואפשר לסגור חוזה. הבעיה בדרך כלל היא במימוש: אם אתם בנק ואתם משלמים מאות אלפי דולרים ומעלה פר חודש לספק הענן הנוכחי, אז ספק הענן המתחרה יקח על עצמו את כל ההקמה והעברת המכונות והנתונים אליו. אם אתם יותר קטנים – הספק המתחרה ישמח לתת לכם שרותי יעוץ (תרגום: אתם עושים את העבודה השחורה, הספק רק מייעץ תיאורתית ושולח לכם לינקים לתיעוד).
    משהו שחשוב לזכור: אין הבדלים רציניים במחירים בין ספקי הענן. הוא יכול נניח לתת לכם מחיר יותר זול על הקמת VM, אבל הוא יקח יותר על ה"דיסק" הוירטואלי, על רשתות תקשורת וירטואליות או על דברים אחרים, כך שלדעתי הסיבות היחידות לעזוב ספק ענן זה שרות גרוע, בעיות Downtime או שאין שרותים שאתם צריכים.
  • קיצוץ בשימוש שירותי הענן: אני יכול להבין בהחלט את אלו שרוצים את האופציה הזו, אבל חשוב לזכור (וזה רלוונטי אצל רוב ספקי הענן!) – אפשר להוציא לדוגמא 1000$ לחודש על פרויקט שרץ על הענן ואפשר במקרים רבים לעשות את זה אצל אותו ספק ענן ב-500$. הכל תלוי בידע של אותו אדם לגבי השרותים המוצעים על ידי אותו ספק ענן.
    סתם דוגמא מציאותית: התשתית שמציגה את הבלוג הזה (ובלוגים אחרים שלי ועוד כמה אפליקציות וניסויים שאני מריץ) לפני כשנה עלתה בסביבות ה-85$ לחודש. כיום אני משלם בחודש 26$. איך? צריך לדעת לבחור את השרותים, לראות מה השרותים החדשים שמוצעים, היכן ספק הענן הוריד מחירים, איך ניתן לבזר את הדברים, היכן כדאי לשלם מראש על משאבים מסויימים לתקופה ארוכה ולחסוך הרבה כסף, היכן ניתן להשתמש במשאבים זמניים כדי להריץ דברים שלא לוקחים זמן רב וזולים בהרבה ועוד ועוד. יש מספר חברות (כולל הח"מ) שמציעים שרות כזה, כך שלפני שמניפים את הגרזן – כדאי להתייעץ.

לסיכום: בלא מעט חברות שיש להם תשתיות בענן ציבורי מגיעים לפעמים סיטואציות שההנהלה דורשת חיתוך רציני בתקציב התשלומים לספק הענן. לא צריך להיכנס לפאניקה, תמיד אפשר למצוא פתרונות איך לקבל ביצועים נאותים תוך ביצוע שינויים שחוסכים מחיר ללא צורך ירידה לשימוש במשאבים בלתי מספקים (תמיד אזכור את אותו עסק שפנה אליי אחרי שקיבל חשבונית היסטרית על שרת SQL שהריץ באמזון ושבקושי נותן שרותים למישהו, אבל האינטגרטור הקודם החליט שזה רעיון מעולה להגדיר שה-SQL ירוץ על m5.4xlarge [כלומר 16 ליבות, 64 ג'יגהבייט זכרון!]).

תודה למשתתפי פורום Operation Israel על תשובותיהם.

קונטיינרים – הפתרונות שקיימים ומה כדאי לבדוק

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

(הערה: מכיוון שמערכות כמו OpenShift, IBM Private Cloud, CAAS, Rancher ועוד מבוססים על Kubernetes ועל זה הם הוסיפו דברים אחרים, אתייחס בפוסט זה ל-Kubernetes או בשמו המקוצר הידוע – K8S).

אחד הדברים הראשונים שמנמר"ים ואנשי IT רבים עדיין לא מבינים, זה את הבסיס, שקונטיינרים אינם מכונות וירטואליות. קונטיינר שקם משתמש ב-Images והוא לא מיועד לאחסן נתונים באופן פרמננטי כמו במכונה וירטואלית, לשם אחסון נתונים יש Volumes שעליהם אתייחס בפוסט זה בהמשך. בקונטיינר אין מערכת הפעלה מלאה, אלא מה שהותקן בעת הקמת ה-Image וברוב מוחלט של המקרים מדובר במשהו מזערי שאמור לספק את דרישות האפליקציה שתרוץ בקונטיינר. בנוסף, קונטיינר מאובטח לא אמור להריץ שרותים כמשתמש root אלא כמשתמש רגיל (ללא הרשאות root/sudo) ולבסוף – קונטיינרים לא אמורים להריץ מספר אפליקציות, אלא אפליקציה אחת בכל קונטיינר/POD ו"לדבר" עם POD/קונטיינרים נוספים שמריצים אפליקציות אחרות, בשביל זה יש לנו TCP/IP ובשביל זה יש שרות DNS פנימי שרץ על K8S שיודע לתקשר בין החלקים והשרותים השונים.

הדבר השני שחשוב להבין בקונטיינרים, זה שזו מערכת מאוד דינמית. לא מומלץ לנסות לקבוע למערכת על איזה שרת לרוץ, מערכת K8S יודעת לבד באיזה שרת להקים את הקונטיינרים, היא יודעת למדוד עומסים וכשצריך – היא תקים את הקונטיינר בשרת אחר אם השרת שכרגע הקונטיינר רץ – עמוס או תקול. אין Live Migration של קונטיינרים, יש להרוג את הקונטיינר ולהריץ אותו מחדש במקום אחר, ובגלל זה כל מידע שצריך להישמר – צריך להיות מאוחסן ב-Volume, אחרת המידע ימחק.

הרעיון של Volume הוא שונה מכל מה שאנחנו מכירים וקשור לאחסון. במערכות וירטואליזציה לדוגמא, אנחנו מגדירים "אחסון" (כמו Datastore ב-VMWare) שיש לו Backing שיכול להיות iSCSI, NFS ובמקרה של Hyper-V זה יכול להיות CIFS. בפתרון הסטורג' שלנו אנחנו מקימים LUN או מחיצה כלשהו שייוצאו כ-NFS/CIFS לפתרון הוירטואליזציה (לא ניכנס עכשיו לכל עניין שרידות, Multipath ושאר ירקות) ועל המקום הזה פתרון הוירטואליזציה שלנו יוצר/משתמש בדיסקים וירטואליים כדי להריץ את מערכת ההפעלה ולאחסן את המידע שלנו.

ב-Volumes לעומת זאת, הדברים שונים לחלוטין. אנחנו עדיין צריכים את ה-Backing (רק שיש הרבה יותר אופציות מאשר iSCSI, NFS – יש 26 אופציות, ו-OpenShift מוסיף עוד כמה) מהסטורג' כדי לאחסן את ה-Volumes, אבל כשאנחנו באים ליצור/להשתמש ב-Volume, אנחנו צריכים קודם כל להגדיר Persistence Volume, להגדיר מה הגודל של אותו Persistence Volume, מה יקרה ל-DATA באותו Volume אחרי שהקונטיינר מת, ומה ההרשאות שיהיה לאותו Persistence Volume מבחינת קריאה/כתיבה. בהגדרות הקונטיינר עצמו אנחנו נשתמש ב-Persistence Volume Claim (או PVC בקיצור) כדי להתחבר לאותו Persistence Volume (או PV בקיצור) ולהגדיר גם Path להיכן להתחבר. ה-PV בדרך כלל מוגדר ברמה של מגהבייט או ג'יגהבייט.

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

לכן, אם אנחנו רוצים להקים פלטפורמת K8S, אנחנו קודם כל צריכים להחליט, האם אנחנו מקימים את זה "על הברזל" או על מכונות וירטואליות? אם על מכונות וירטואליות והפתרון מבוסס vSphere, אז אנחנו יכולים להסתכל על VMware Kubernetes Engine™ VKE לדוגמא (ואפשר במקביל להציץ גם ב-PKS של VMWare/Pivotal). חובבי מיקרוסופט? בחודש הבא יוצא Windows Server 2019 שכולל את Kubernetes בתוכו. אם לעומת זאת אנחנו מעדיפים פתרונות כמו OpenShift, CAAS ואחרים, נצטרך להקים מכונות לינוקס ועליהן להריץ את אותם פתרונות. לא אכנס כאן ליתרונות וחסרונות של פתרונות "טבעיים" מול הקמת פתרונות על מכונות וירטואליות – אבל אחת הנקודות שחשוב לזכור, זה שפתרונות שמקימים על מכונות וירטואליות – זה שקל להזיז את הפתרון לעננים או למקומות אחרים במקום להיות "נעול" על פתרון שיצרני ה-OS ווירטואליזציה מציעים. חוץ מזה קיים גם עניין המחיר.

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

  • תקשורת 10 ג'יגהביט. שוב, אין בקונטיינרים Live Migration שמשתנה בו כמה קבצי קונפיגורציה וה-VM "קופץ" למכונה אחרת, יש הקמה מחדש של קונטיינרים ולמרות שה-Image נמצא בסטורג', בחלק מהמקרים הוא מועתק לדיסקים מקומיים ולכן פתרון תקשורת 1 ג'יגה יאיט הכל.
  • סטורג' עם שרידות – יש לא מעט חברות שבטוחות שזה שהדיסקים מחוברים בבקר RAID כפול יש אחלה שרידות. לדעתי – עדיף שרידות שאם "ראש" נופל, "ראש" אחר לוקח מיידית פיקוד, אבל שוב – הכל תלוי בתקציב וכמה הפלפורמה תהיה פרודקשן.
  • דיסקים מקומיים – מאוד חשוב. ה-Images ימצאו בדרך כלל ב-Container Registry, אבל הם יועתקו לדיסקים מקומיים ברוב המקרים ועם הדיסקים מקומיים איטיים, זמן הקמת הקונטיינר יתארך (ותהיו בטוחים שיהיו ערימות קונטיינרים, חוץ מהקונטיינרים שלכם, תלוי בפלטפורמה). דיסקים מכניים זה פתרון לא רע אבל אם רוצים ביצועים – תחשבו על SSD Mixed Intense.
  • אם המערכת הולכת להיות חשופה החוצה לאינטרנט (הכוונה השרותים כמו WEB חשופים לאינטרנט) – אז אבטחה רצינית היא חשובה: לא להקים Images כ-root, תקשורת ו-Namespace מופרדים ועוד דברים חשובים שמצריכים הכרה עמוקה עם פלטפורמת הקונטיינרים. תזכרו: קונטיינר שרץ כ-root וחשוף לרשת – יכול לתת לפורץ הרבה יותר ממה שאתם חושבים.

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

חישובים על מעברים לעננים ציבוריים מול ענן פנימי

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

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

אם נתייחס למצב בישראל, אז הדבר הכי אירוני שקורה פה בארץ, הוא עניין מחירי שרתי המותג (HP, Dell, Lenovo, Cisco, Fujitsu): המחירים כאן די "דוחפים" את הלקוחות לעבור לשרותי ענן עקב מחירם היקר (מאוד).

הבה נסתכל מהצד השני, אצל ספקי ענן, ולא חשוב אם מדובר בספק קטן יחסית (Linode, Digital Ocean) או על הגדולים (אמזון, גוגל, מיקרוסופט): אצל כל אותם ספקים יש התחמקות רצינית מכל ציוד מותג. אצל הגדולים לא תמצאו שום ציוד מותג של שרתים, לא תמצאו חומרה של Enterprise ממותג (למעט מעבדים), לא תמצאו מתגים של מותגים, אין שום NetApp או EMC שמשמש כ-Storage ל-VM, ועוד. אצל היותר קטנים יכול להיות שתמצאו שרתי מותג – אך הם נרכשים בתצורה הכי בסיסית וכל הציוד הפנימי הוא צד ג' – ללא גרסאות Enterprise. הגדולים בונים לעצמם את הכל ושרתים מיוחדים נרכשים משמות שאף אחד לא מכיר כמו Wywinn הסינית שמייצרת את הדגמים לפי שרטוטי לוחות שספקי הענן מעבירים). בקיצור: המטרה של כל אותם ספקי ענן היא להוציא כמה שפחות כספים על הציוד, ובגלל זה פרויקטים כמו OCP מאוד פופולריים אצל ספקי הענן וכולם משתתפים ותורמים שרטוטים, תכנונים וכו'.

במילים אחרות: כשחברה עוברת לענן, המכונות הוירטואליות לדוגמא שהם יקימו – יוקמו על ציודים שספק אם בחברות ירצו לרכוש אותם מקומית. זה שאתם עוברים לענן לא אומר שלא יהיו לכם מכונות VM תקועות ושאר תקלות. אתם פשוט תצטרכו לבצע Restart והתשתית ענן תקים את ה-VM במכונה אחרת, ומכיוון שתשתית ה-Storage שם שונה לחלוטין מכל NetApp או EMC שאתם מכירים, לא יהיה צורך בביצוע Migrate (ואגב, הדיסקים באותו פתרון Storage – המכניים הם SATA "ביתי" וה-SSD ברובם גם "ביתיים" למעט חלק קטן עבור Write Cache שהם OEM מיצרנים ידועים כמו Samsung).

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

אז איך אפשר לקבל מחיר נמוך, יחד עם עמידה בכל מה ש-Enterprise דורש?

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

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

להלן מספר נקודות כלליות שיש לתת עליהן את הדעת:

  • וירטואליזציה – 2 הדברים החשובים כשמקימים ענן פרטי זה יציבות ומחיר נמוך (כשאני מדבר על מחיר נמוך, אני מדבר על מחיר תלת ספרתי בדולרים פר ברזל בגירסה המסחרית, או גירסת קוד פתוח עם חוזה תמיכה מבחוץ). מי שמעוניין ב-OpenStack, כדאי שיצור קשר עם SuSE ישראל (המחיר זול בעשרות אחוזים מהמחיר של Red Hat). מי שמעוניין בפתרון שהוא וירטואליזציה נטו, כדאי שיסתכל על RHV של Red Hat.
  • שרתים – אתם יכולים להשתמש בשרתים קיימים או לרכוש שרתים מתור קודם (ברוב המקרים, ההבדל בביצועים בין הדור הקודם לנוכחי לא כזה גדול). אני ממליץ גם להסתכל על השרתים של SuperMicro ושל חברת Tyan. ספציפית ל-SuperMicro יש מבחר הרבה יותר גדול של שרתים לצרכים שונים ופתרונות חדשניים שעדיין לא קיימים אצל HP או DELL לדוגמא, ובמחיר שהוא זול בהרבה בהשוואה לחמשת היצרנים שציינתי לעיל. אגב, הנה משהו מעניין שכתבה חברת Barrons על Supermicro. שרתים שאני לא ממליץ – הם דווקא של HP ובסעיף הבא אסביר מדוע.
  • דיסקים – עולם הדיסקים משתנה כל הזמן. דיסק SATA טיפוסי שבעבר היה נותן מהירות קריאה של 110-150 מגהבייט לשניה נותן כיום 250 מגהבייט לשניה ובקרוב יצאו דיסקים מכניים שנותנים מהירות שמגיעה ל-420 מגהבייט בשניה ובחיבור NVME (כן, SAS/SAS-HD מגיע לסוף דרכו). המבחר די גדול וכפי שהוכיחה חברת BackBlaze בדו"ח אחרי דו"ח (הם מנפיקים דו"ח פר רבעון והם קונים אלפי דיסקים) – דיסקים ל-Enterprise לא נותנים מאומה הן מבחינת ביצועים והן מבחינת שרידות. גם מבחינת מחיר, בממוצע אתה יכול לרכוש 3 דיסקים במחיר שקונים לדוגמא דיסק קשיח מ-HP, כך שאתה יכול להגדיר 2 דיסקים ב-RAID-1 ועוד דיסק כ-Hot Spare, ואתה מסודר לתקופה ארוכה – פר שרת. אני לא ממליץ על שרתי HP מבחינת דיסקים מכיוון ש-HP נועלים אותך על דיסקים שלהם בלבד (שעולים פי 3 בלי הצדקה, במיוחד כשרוכשים פתרון כולל SLA ואז עניין כל החלפת הדיסקים הוא על מי שנותן לכם שרות).
  • דיסקים SSD – עולם ה-SSD מתעדכן כמעט כל חצי שנה במהירות ויש המון יצרנים וסוגי SSD שונים. המצב מול SSD ל-Enterprise הגיע למצב כזה מגוחך כשראיתי אצל לקוח דיסק SSD שעלה המון והביצועים שאותו SSD נותן הם פחות ממחצית מדיסק SSD שיושב לי פה במחשב הדסקטופ שלי, ואני שילמתי רבע מחיר ממה שהוא שילם. לכן, חשוב לבחור יצרן שרתים שמאפשר הכנסה של כל דיסק צד ג' ובכך להנות מהתחרות בשוק.
  • מעבדים – המלצתי בעבר על EPYC ואני עדיין ממשיך להמליץ על מעבדים אלו מהסיבה הפשוטה שמקבלים יותר ביצועים וליבות ומשלמים פחות. החשבון פשוט.
  • תקשורת – זמן רב שהמחירים לא זזו בצורה רצינית בתחום התקשורת אולם כיום יש ירידה במחירים ולכן מומלץ לצייד כל מכונה בכרטיס עם זוג כניסות בחיבור +SFP כתקשורת עיקרית ומתגים עם חיבורים של 10 ג'יגה ו-Up/DownLink של 40 או 50 ג'יגה. אגב, יש בהחלט גם מתגים שתומכים ב-RJ45 וחיבור 10 ג'יגה על CAT6 (למרחקים קצרים) או DAC (גם למרחקים קצרים) או סיבים אופטיים (למרחקים יותר ארוכים).
  • סטורג' – אף אחד מספקי העננים, גדולים כקטנים, לא משתמש בסטורג'. כיום הבון טון הוא שימוש בדיסקים מקומיים עם פתרון Scale Out לסטורג' בין כל המכונות הפיזיות. הפתרונות הפופולריים כיום הם CEPH ו-GlusterFS.

פתרון מבוסס על הדברים שציינתי יתן לכם:

  • אפשרות קלה לשדרוג והוספת מכונות
  • פתרון ענן ל-3-5 שנים כולל תמיכה שוטפת
  • הרצת מכונות וירטואליות, קונטיינרים ועוד.

לסיכום: אפשר להקים תשתית שיכולה בחישוב ROI/TCO להיות יותר נמוכה ממחירים של ענן ציבורי – אם "משתחררים" מהראש של ציוד Enterprise ממותג מהיצרנים שציינתי בתחילת הפוסט. הציוד שתיארתי יכול לעמוד בדרישות פרודקשן חמורות והוא כבר עומד – אצל ספקי עננים קטנים לדוגמא (אגב, כשאני מדבר על "קטנים" אני מדבר על ספק עם מינימום 5 DC ואלפי שרתים פיזיים). כל עוד הדרישות שלכם מסתכמות במכונות וירטואליות וקונטיינרים – זה עובד. יש כמובן דברים שעננים מקומיים לא כל כך נותנים כמו כל עניין ה-Serverless או API ענק כמו של אמזון ל-1001 שרותים שונים, ואם רוצים להשתמש באותם API, אין מנוס מאשר לחתום מול ספק ענן ציבורי.

על עסקים קטנים ומעבר לעננים. כדאי?

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

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

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

אתן דוגמא: אתם קוראים את הבלוג הזה, שהוא חלק ממספר בלוגים שעבדכם הנאמן כותב. כל הבלוגים רוצים בשרת וירטואלי עצמאי שהיה נמצא בחברת Digital Ocean ועתה הוא נמצא באמזון תחת Amazon Lightsail. האתר עצמו, וה-Database שלו ושרת ה-Web – כולם מותקנים על שרת וירטואלי יחיד שעולה לי בחודש 40$. זה מה שאני משלם בכל חודש, בין אם נכנסו 3 גולשים או 2000 גולשים ביום, מכיוון שכמות ה-DATA היוצאת מהשרת אינה עוברת את כמות ה-DATA המוקצית עבורי בחבילה. יש חבילות כמובן יקרות יותר ויש זולות יותר, בהתאם לצרכי הלקוח והחברות המציעות שרותים אלו ושאני יכול להמליץ עליהן (כולל Amazon Lightsail שהזכרתי לעיל) הן Digital Ocean ו-Linode ויש כמובן חברות נוספות בהתאם להמלצות שאתם יכולים לקבל מאחרים אולם אלו ההצעות הפופולריות ורציניות.

כמובן שגם ספקי הענן הציבורי מציעים מוצרים כמו קונטיינרים, מכונות וירטואליות וכו', אולם שם התעריפים שונים מההצעות לעיל. לדוגמא: אם באמזון ניקח מכונה ב-EC2 (לא בחבילת ה-Lightsail) כמו המכונה שיש לי, המחיר יהיה $43.63 עד לתעבורה של 100 ג'יגהבייט, אולם אם מחר אפרסם פוסט שיהפך לויראלי, אני אגיע בקלות גם לתשלום של 50-100$ לחודש. אם נבנה ב-Google Cloud את אותו מפרט של מכונה (מכונה מבוססת לינוקס, 2 ליבות, 4 ג'יגהביייט זכרון, 40 ג'יגה דיסק SSD ו-100 ג'יגהבייט תעבורה החוצה) נגיע ל-$61.22. ב-Azure אותה חבילה תעלה לנו $48.42. כך יוצא שהלקוח משלם יותר על פחות. (אגב, ב-Azure תצטרכו לשלם יותר כי הדיסק מוגדר "זמני", ודיסק מבוסס רשת עולה יותר). הערה: המחירים יכולים להיות אצל חלק מהספקים זולים יותר – אם אתם משלמים מראש שנה או שנתיים.

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

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

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

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