כשצריך תשתית של עננים ציבוריים – מקומית

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

לפני כחודשיים כתבתי פוסט על Azure Stack (ועל "אחיו" – Azure Stack HCI), הפתרון של מיקרוסופט לחברות שדורשות ענן ציבורי בתשתית שנמצאת מקומית או ב-DC של אותן חברות. מאז אותו פוסט גם אמזון עדכנה את הפרטים לגבי המוצר המתחרה שלה: Outpost. לפי ה-FAQ העדכני והפוסט הזה שפורסם לפני מספר ימים מתאר אלו שרותים יהיו זמינים ב-Outpost. גם כאן, כמו עם Azure Stack, אתה לא יכול להשתמש בשרתים או סטורג' משלך, והשרות בעצם כולל השכרה/רכישה של ברזלים יחודיים של ספק הענן, וכמו בכל ההצעות – אתה חייב חיבור אינטרנט לאותה תשתית מכיוון שמי שמנהל את אותה תשתית ענן ציבורי שנמצאת מקומית ב-DC שלך – זה ספק הענן הציבורי בלבד.

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

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

לגבי שאר ספקי הענן הציבורי:

  • ל-IBM יש Cloud Private שנותן לך בעצם Kubernetes עם שרותים נוספים של IBM שירוצו מקומית.
  • ל-Alibaba, Huawei, Baidu יש גם פתרונות מקומיים אבל אני בספק אם הלקוח הישראלי החשדן יסכים לשכור מהם שרותים שישבו מקומית.
  • Oracle מציעים את Oracle Cloud at customer – שכוללים את "רוב" השרותים שהם מציעים בענן (אחרי שנברתי בערימת מסמכים רוויי Buzzwords – קשה להבין מה הם בדיוק נותנים, מה עוד שהתיעוד שלהם לגבי ספקי ענן מתחרים לוקה בחסר ולכן לא מומלץ לסמוך על התיעוד שלהם).
  • VMware – נכון, VMWare היא אינה ספק ענן ציבורי, אבל עם מוצר כמו Tanzu אתה יכול להרים תשתית קונטיינרים/Kubernetes מקומית (PKS) ובעננים ציבוריים גדולים.

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

עננים ציבוריים: להתחיל בקטן ולגדול

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

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

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

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

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

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

במקרים כאלו ה-Lightsail הוא פתרון מעולה. השימוש בו ממש קל: אתה יכול להרים לך מספר מכונות, אתה יכול להשתמש בשרותי ה-DB המנוהלים של אמזון גם ללא הכרה של ה-RDS המורכב, אתה יכול להשתמש ב-Load Balancer הפשוט שאמזון מציעה כדי לנתב את התעבורה, ואתה יכול להשתמש בשרותי ה-Snapshot כדי לשכפל מכונות תוך דקות ספורות, ויש דברים נוספים שלא עולים לך כמעט כלום: אתה יכול להשתמש בשרות ה-SMS לשם משלוח מיילים החוצה (בכמויות שסטארטאפים קטנים מתחילים – הם לא ישלמו כלום), אתה יכול להרים GIT פרטי (5 משתמשים ראשונים זה בחינם), אתה יכול גם להשתמש בשרות ה-DB המנוהל עם אפשרות Cluster שיעבוד כ-Active/Passive עם גיבוי אוטומטי כל 5 דקות, ויש לך מגוון שרותים שאתה יכול להשתמש עם ה-Lightsail מבלי להכאיב לארנק.

ברגע שהסטארטאפ רוצה לגדול, Lightsail מאפשר לך להעביר את התשתית שלך כמו שהיא ל-AWS המלא. צור Snapshot למכונות, ותוכל להקים אותם כ-Instances ב-EC2 ואותו דבר לגבי ה-DB – תוכל להעביר אותו בקלות ל-RDS ולהשתמש בשרותים מתקדמים כמו רפליקות וכו'.

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

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

הבדלים בין Snapshot לגיבוי

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

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

  • מימוש ראשון VMWare Snapshot
  • מימוש שני – AWS Snapshot

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

עכשיו נעקוב אחר התהליך הנ"ל מקרוב. ברגע שיצרנו את ה-Snapshot לאותו VM, הוא מתחיל בגודל 0 בתים (או משהו קרוב לכך, יכול להיות שה-snapshot יכלול בתים ספורים בהתחלה). ברגע שערכנו את אותו קובץ טקסט ושמרנו אותו, הוא אינו שומר את השינוי לדיסק הקשיח הוירטואלי, אלא שומר אותו לתוך ה-snapshot. אם נבדוק, נוכל לראות שגודל ה-snapshot גדל בכמות הבתים שהוספנו לאותו קובץ טקסט (את הדברים הרבה יותר קל לראות "מבפנים" אם משתמשים במערכת ZFS, שהיווה "השראה" ל-VMWare כיצד ליצור snapshots). אם לאחר שיצרנו קובץ Snapshot, עבר זמן ויצרנו קובץ snapshot חדש, כל השינויים שניצור מעתה ישמרו ב-Snapshot החדש, וה-snapshot הקודם יעבור למצב read only.

המימוש השני של snapshot לשם הדוגמא יהיה AWS EBS Snapshot: הקמנו Instance (כלומר VM) עם מערכת ההפעלה שבחרנו, ולאחר מכן ביצענו מספר שינויים בהגדרות, הוספנו אפליקציות ועוד, וכעת אנחנו יוצרים Snapshot ב-AWS. ה-Snapshot הראשון שניצור ישמור את השינויים מהקמת ה-VM עד לרגע זה. אם ניצור Snapshot נוסף, הוא ישמור את השינויים שנוצרו מאז ה-Snapshot הראשון, כלומר כל שינוי שביצענו אחר ה-Snapshot הראשון ישמר בדיסק EBS ולא ב-snapshot ורק אם ניצור snapshot נוסף, השינויים יועתקו אליו.

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

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

במקרים כמו VMWare התשובה היא "לא ממש" הואיל ויצירת Snapshot הוא דבר שצריך לבצע "ידנית". המערכת לא תיצור עבורך snapshot אוטומטית (למרות שלמערכת יש בהחלט דבר שנקרא Changed Block Tracking שמופעל אוטומטית ובכך המערכת יודעת לזהות כל שינוי שבוצע בדיסק, ואין זה משנה איזו מערכת הפעלה מדובר, כי אותה מערכת עובדת בבלוקים, לא ב-File system) ולכן גיבוי של המערכת ע"י תוכנת גיבוי (Veeam, Arcserve ושאר תוכנות) היא דבר חשוב ואף הכרחי.

בעננים ציבוריים כמו AWS לעומת זאת, יש צורך לעבוד בשיטה שונה (שלצערי יש לא מעט שמתחילים לעבוד עם AWS ולא מפנימים זאת): ב-AWS כדאי לבנות את מכונות ה-VM כ"שלדים" (templates) ולשמור את הקבצים המשתנים ב-EFS או ב-S3. כך, בונים VM, מגדירים את הדברים הקבועים, מוסיפים סקריפט שידע להעתיק את הקבצים הנחוצים מ-S3 או EFS, יוצרים snapshot ולאחר מכן ממירים את זה ל-Image בפורמט AMI סגור. נדפק ה-VM? פשוט מקימים חדש מה-AMI כשאחד הפרמטרים הוא בעצם הרצה של הסקריפט שיצרנו כך שלאחר הקמת ה-VM/Instance – הוא יעתיק את הקבצים וידווח לנו מה כתובת ה-IP הפנימית של ה-VM החדש.

ב-ZFS הדברים שונים. מכיוון ש-Snapshot ב-ZFS אינו תופס מקום בדיסק (0 בתים), ישנה שיטה פשוטה ליצור אוטומטית snapshots כל זמן שתרצה. אני לדוגמא עובד עם ZFS שיוצר snapshots כל שעה, כל יום, כל שבוע, כל חודש, כל שנה – ומגדיר את המערכת שתשמור לי 50 snapshots אחורה. מבחינת שרידות, ZFS תומך במערך RAID (שנקרא RAIDZ) עד רמה שלישית (כלומר: המערכת יכולה לתפקד עד למצב שבו יש שלושה דיסקים תקולים) עם תמיכה מלאה ב-Hot Spare. מעבר לכך, מערכת ZFS נותנת גם "להשתולל" עם מערכי RAIDZ כך שניתן להקים שתי מערכות RAIDZ3 ולצוות אותן יחד כ-RAIDZ1. בזבוז מטורף של דיסקים? בהחלט, אבל למי שיש תקציב – בכיף. מה עם גיבוי לטייפ? יש כאלו שמגבים אחת לזמן מה לטייפ ויש כאלו שפשוט מעדיפים להשתמש בתשתית ה-ZFS ופקודות ה-send/receive המובנות על מנת לגבות את ה-ZFS למערכת מרוחקת. (אפשר כך לבנות אחסון DR בזול. אגב, מקומות רבים בחו"ל משתמשים בשיטה הזו).

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

שינויים בעולם ה-IT בחברות

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

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

יחד עם זאת, יצא לי בכמה פעמים לשוחח עם מספר מנמר"ים, CTO ומנהלי מחלקות IT. השיחה בד"כ נסובה על דברים שהם מחפשים במועמד הבא לאייש משרה בתחום ה-IT, ושמתי לב לכמה דברים מעניינים שאני רוצה לשתף עמכם:

  • הדרישות גדלו: אם פעם היו מחפשים אצל המועמד ידע ב-Windows, ידע התחלתי-בינוני בלינוקס, ידע ב-VMWare ואולי קצת ידע ב-Networking, הפעם רוצים שהמועמד יהיה בעל נסיון בתחומים שהם אינם IT כל כך: תדע Jenkins, GitLab, Code bucket – ולא מדובר על ידע של התקנת הכלי (כמה זמן לוקח להתקין Jenkins? דקות ספורות, לא כולל plugins שאינם רשמיים וכו') – אלא גם כתיבת Pipelines, ידע בניהול גרסאות ב-GIT, ידע ב-Docker, ידע ב-Kubernetes, ידע בהגדרות עננים ציבוריים (AWS, Azure ולפעמים גם GCP). לא שמעתי על הרבה שרוצים ידע ב-Terraform אבל אני מניח שאת זה הם משאירים לאיש DEVOPS (כן, Devops זה מתודות, אבל לך תתקן אנשים).
  • משכורות – אתה הולך לרכוש דירה? הולך להרחיב את המשפחה? הולכת להיות לך הוצאה גדולה? כדאי שתעזוב את תחום ה-IT לטובת תחומים אחרים יותר רווחיים. המספרים ששמעתי נעים בין 13-20K ברוטו. טוב לצעירים, פחות טוב לנשואים, אבות לילדים וכו' וכו'.
  • Kubernetes, Helm, Terraform, Ansible, AWS, Azure – ורצוי גם ידע ב-Python, אלו הדרישות שדורשים מאנשי Devops, חוץ מידע בכלי CI/CD. שימו לב: בסטארטאפים מצפים מכם שתלמדו הרבה יותר ממה שציינתי – ומהר. כלי נוסף שחברות עדיין לא ממש גילו ויש מצב שירצו להריץ אותו – נקרא KOPS. ממליץ לכם להכיר אותו.
  • שכר לאנשי Devops: משום מה במקומות רבים חושבים שהשכר של איש Devops אמור להיות שכר כמו של איש IT. עצתי לכם: תדעו למכור את עצמכם ולהתמקח. עם כל הכבוד לתחום ה-IT, איש Devops צריך לדעת הרבה יותר וללמוד מהר דברים חדשים, התחום מתקדם במהירות מטורפת!
  • אל "תינעלו" על ענן ציבורי מסוים! ידוע לי שבחברות גדולות רבות פשוט "מתים" על Azure, אבל בשוק יש המון חברות (ובמיוחד סטארטאפים) שמשתמשים ב-AWS ו-GCP ועדיף לכם להכיר את כולם. כל ספקי הענן הציבורי מציעים כמות קרדיטים חינמית בתור התחלה אבל זה לא תמיד מספיק (תזכרו: הקרדיטים הראשוניים הם לזמן קצוב בלבד של חצי שנה או שנה). לכן אני ממליץ: תתנחמדו לאנשי מכירות של ספקי הענן הציבורי ותבקשו בנימוס קרדיטים. טיפ קטן: אני ממליץ ללמוד את הנושאים דרך Linux Academy (למרות השם שלהם, הם מלמדים גם על דברים שאינם לינוקס) ולהשתמש ב-Lab שלהם, אתם תקבלו מספר מכונות וירטואליות חינמיות שפועלות במשך זמן קצוב.
  • קראו בין השורות לגבי משרות. בלא מעט מקרים באתרים כמו Alljobs ניתן לקרוא את המפרט של נושאים שהחברה רוצה שהמועמד ידע ויכיר, אבל לפעמים אפשר לראות שהחברה בעצם מחפשת איש Devops שיהיה גם איש IT ואם אפשר – שיכין קפה לפעמים. ממשרות כאלו אין הרבה לאן להתקדם, חפשו דברים שמתאימים לכם, לא להיות כלבויניקים.
  • הנה משהו מעניין ששמעתי ולא מאדם אחד: אין לכם נסיון (חוץ ממה שהתנסיתם בבית)? אל תבקשו לעבוד בחינם. אתם יכולים לדבר על משכורת התחלתית כלשהי שתעלה לאחר תקופה מסויימת/דיון שכר וכו' – והכי חשוב, להיות כן: אם אין לך נסיון מספק, תאמר זאת ותאמר שאתה מוכן בשביל זה להסתפק במשכורת כלשהי (עדיף לא לציין מספר). תנסו לתחמן, יש סיכוי גדול שיתפסו זאת ולא יזמנו אתכם להמשך תהליך.

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

המעבר לענן ציבורי – התהליכים המקדימים

דמיינו לעצמכם סיטואציה פשוטה: יש לכם 20 שרתים בחברה (פיזיים) שמערכת vSphere רצה עליהם. הכל מתקתק ועובד טוב עד שיום אחד האחראי על ה-vSphere בחברה מפוטר עקב סיבה כלשהי. האם יהיה קשה למצוא עובד חלופי לאותה משרה? לא ממש, השאלה למה אתה מצפה: אם לדוגמא העובד שפוטר היה כותב סקריפטים ב-Powershell או ב-PERL לאוטומציה של ה-vSphere ורוב העבודה היתה נעשית באוטומציה כלשהי ללא שימוש ב-GUI – אז כן, אתה תתקשה למצוא מחליף (וגם אם תמצא, תצטרך לשלם לו הרבה יותר ממה שחשבת). אם לעומת זאת אתה מחפש מישהו שינהל רק ברמת הממשק Web, תמצא לא מעט כאלו בקלות ותוכל לשלם להם משכורת יותר נמוכה אפילו (תלוי בכישורי המו"מ שלך והבטחון העצמי של המועמד). מצד שני, אם יש לך תקלות שמתאפיינות במסך סגול וגוגל לא ממש עוזר – תתכונן לשלם והרבה, בין אם זה ל-VMware או למישהו מומחה.

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

מה בעצם העבודה שהרוב יציעו ויעשו? הם יעשו מה שאני קורא "Copy Paste". נניח שיש 10 מכונות VM, הם פשוט יעלו אותן לענן כ-Instances, יקצו להן כתובות IP חיצוניות פר Instance (תתפלאו כמה חוסר מקצועיות יש בנושא), יגדירו Security Group שנושאת מטוסים יכולה לעבור דרכו, חס ושלום VPC חדש ונורמלי, או ניתובים קצת יותר מוקשחים. אם הלקוח מתעקש על Firewall, אז יתקינו איזה משהו שקיים ב-Market עם חוקים מאוד "רפים". אני לא מנסה "ללכלך", אני בדרך כלל מי שמגיע אחרי כן לבדוק מדוע הדברים לא עובדים טוב וזה מה שאני מוצא. אני כמובן שלא אומר שכולם כך, יש דווקא לא מעט אנשים מקצועיים בתחום.

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

בהעברת התשתית לענן יש לנו 3 מטרות חשובות:

  • הורדת המחיר פר מכונה
  • קבלת ביצועים יותר גבוהים
  • הגנה יותר נאותה.

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

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

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

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

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

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

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

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

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

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

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

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