על חוות שרתים מעל ומתחת לאדמה

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

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

התשובה עצמה – קצת מורכבת, וברשותכם – אפרט.

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

מה שתמיד מומלץ ללקוחות לעשות, זה לעבוד עם הכלים והפלטפורמות של ספקי הענן הציבורי הגדולים בכל הקשור לשרידות, ולהזניח את שיטות ה-DR הקלאסיות. שלושת ספקי הענן הגדולים, לדוגמא, מאפשרים להקים תשתית וירטואלית של שרותים ומכונות VM שפועלות במקביל במספר Availability zones (או Regions), כך שאם AZ או Region (תלוי בטרמינולוגיה של ספק הענן הציבורי) נופל או נפגע, התשתית הוירטואלית של הלקוח תמשיך לפעול מה-AZ או ה-Region האחר שנמצא גיאוגרפית במיקום שונה. לאלו שמוכנים להשקיע עוד, ניתן אפילו לבנות זאת בצורה של שימוש ב-3 Regions (או Region נוסף מחוץ לישראל ו-2 Availability zones), כך שלא חשוב מה יקרה בישראל, המערכת של הלקוח עדיין תמשיך לעבוד. אפשרות נוספת (ותמיד מומלצת) היא שימוש ב-Multi Cloud תוך שימוש בשרותים של ספקי ענן ציבורי שונים והקמה של התשתית אצל ספקי ענן ציבורי שונים, כך שאם קורה מקרה נדיר בה כל התשתית של ספק ענן ציבורי כלשהו נופלת – המערכת של הלקוח תפעל אוטומטית מהתשתית של ספק ענן ציבורי אחר.

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

פוסט תגובה ל-"לא להינעל" (המאמר של ליאור קיסוס)

קראתי את מאמרו של ידידי היקר ליאור קיסוס באתר PC, וחשבתי להגיב לגבי הדברים.

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

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

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

את הריצה המטורפת לשימוש ב-SAAS אני רואה מכל עבר, ואני חוזר ומציין תחת כל עץ רענן כי ברוב מוחלט של המקרים, שרותי ה-SAAS הם מיותרים לחלוטין אם לא מדובר בפרודקשן שחייב להיות זמין 24/7. אדרבא, ככל שמשתמשים בכמה שיותר שרותי SAAS, האפשרות למעבר לספק ענן מתחרה הופך להיות יותר ויותר קשה, במיוחד כשרוב מוחלט של ספקי הענן הציבורי כיום כלל לא מציעים שום Migration Path נורמלי מענן אחד לשני, ואף אחד כמובן לא מוכן לממן את השינויים בסקריפטים ובמקומות אחרים שצריכים לשנות כדי לעבור ענן.

יש נקודה מסויימת שאינני מסכים עם ליאור, והיא קשורה למחיר: מחירי הענן לא עולים ועולים, ואני אומר זאת באחריות: אני משתמש בשרותי ענן של אמזון כבר 6 שנים לצרכיי האישיים, וכיועץ אני מתעדכן תדיר במחירים של הספקים השונים מבחינת מחירי תשתיות ושרותים. כמעט בכל מצב, תמיד אפשר למצוא דרכים לחסוך כספים בענן, אם מוכנים קצת, טיפה, להתאמץ: במקום להשתמש ב-RDS, תפסיקו להתעצל ותקימו בעצמכם תשתית SQL (לדוגמא). במקום להשתמש ב-CDN הסופר יקר של ספק הענן, תשתמש ב-CDN של מתחרים שאינם נופלים בביצועים ובאיכות ממה שספק הענן שלכם מציע, יש "שכבות" שונות לאחסון Object Storage כמעט אצל כל ספק ענן וניתן בעזרת סקריפט פשוט להעביר קבצים (אם לא רוצים לשלם על Tiering חכם), וזה – על קצה המזלג, כך שבעזרת תכנון נכון וניטור מתמשך, לא צריך להגיע למצב של "שריפת" תקציבים אצל ספק הענן הציבורי.

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

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

הקמת HPC – מקומית או בענן? נקודות למחשבה

חדש! אין לכם כח לקרוא? אתם יכולים ללחוץ על הקישור כאן או להסתכל בסוף הפוסט על וידאו קצרצר המסכם את הפוסט.

עולם ה-HPC הוא עולם שמתקדם בקצב איטי. עד לפני שנים מעטות, השינויים המהותיים היו יותר קשורים ל-Job management פופולרי (slurm ש"כבש" פופולריות במקום ה-Sun Grid Engine לדוגמא, שהפך לאחר מכן ל-Son of Grid Engine) וברוב המקרים כשהיה מדובר על מערכות גדולות (עשרות, מאות שרתים ומעלה) חברות כמו Dell ו-HPE החליפו שרתים של Sun (לאלו שהיתה להם מערכת HPC ישנה יותר).

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

  • מבחינת מערכת File system מרכזית – ל-Lustre עדיין יש מקום ורלוונטיות (גירסה חדשה שוחררה רק בחודש שעבר), אך במקביל, מערכות כמו Gluster ו-CEPH תפסו מקום נכבד כ-Scale Out Storage
  • יותר ויותר חברות עוברות לשימוש מאסיבי יותר בכרטיסי GPU יעודיים (V100, A100 של NVIDIA, וכרטיסים אחרים לעיבוד AI/ML/DL מחברות כמו AMD ואיננטל יכנסו בקרוב לשוק בצורה יותר רצינית).
  • חיבוריות/רשת תקשורת פנימית עוברת שדרוג רציני. במקרים רבים, חברות היו משתמשות בחיבור סיב במהירות של 10 ג'יגהביט, כיום בד"כ ההמלצה היא 50 ג'יגהביט ומעלה.

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

כיום חברות כמו NVidia מציעות שרתי DGX במחיר שווה: במחיר של 200-220K אתה מקבל שרת עם 2 טרהבייט זכרון, 8 מודולי GPU מסוג A100 (עם 80 ג'יגהבייט זכרון פר מודול), אחסון מקומי בגודל 36 טרהבייט, 128 ליבות (2 מעבדי AMD EPYC עם 64 ליבות), קישוריות רציפה בין מודולי ה-GPU (זה ה-NVSwitch) ומספר חיבורים במהירות 200 ג'יגהביט. עם קופסאות כאלו, בדרך כלל תצטרך לרכוש מתג (או מתגים, תלוי בקופסא) ותצטרך לדאוג לפתרון אחסון Scale Out (אם מדובר ברכישה של 10+ שרתים) וגם פתרון אחסון יותר איטי – והרי לך פתרון HPC בסיסי ברמה העקרונית (כמובן שברזלים זה נחמד, אבל יש המון עבודה להתקין דברים, להגדיר, אוטומציה, Job Management ועוד ועוד)

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

לרכוש ולבנות "משלנו" או ללכת עם פתרון ענן של ParallelCluster של AWS (או פתרון של Azure או GCP)?

על מנת לענות על שאלה זו, נצטרך בשלב הראשון לחלק בעצם את פתרון ה-HPC ל-2 חלקים:

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

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

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

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

  • זמינות לעבודה מיידית: בין אם אתה צריך 1000 או 10000 ליבות, בין אם אתה צריך 2 או 300 כרטיסי GPU החדשים ביותר – הם זמינים עבורך תוך דקות ספורות. אין צורך להמתין שהמערכת תתפנה, או להבין שאין ב-HPC המקומי את הציוד שאתם כלקוח צריכים.
  • התשלום הוא רק עבור שימוש: הפעלתם דרישה של 1000 ליבות לעבודה שלקחה שעתיים ו-14 דקות? על כך בדיוק תשלמו (פלוס האחסון, תעבורת אינטרנט וכו'). בסיום ה-JOB בדרך כלל (בהתאם להגדרות) המערכת "תהרוג" את כל ה-Nodes המשתתפים בעבודה (לאחר שהחומר הרלוונטי הועבר לאחסון), מה שמאפשר ביצוע עבודות רבות עם תקציב קטן יחסית, גם לסטארט-אפים.
  • מבחר ענק של ציוד: צריכים מכונות חזקות מאוד? חלשות (עם תשלום נמוך)? עם 2 כרטיסי GPU? ללא כרטיסי GPU? עם מהירות תקשורת של מאות ג'יגהביט? עם אחסון במהירות 7 ספרות IOPS? ברוב פתרונות ה-HPC, האפשרויות מצומצמות מאוד, ובענן – כל מה שצריך זה לבחור ולשנות שורה אחת בקובץ קונפיגורציה.
  • תאימות: רגילים לעבוד עם SGE, עם Slurm, עם Torque? רוב הסיכויים שפתרון ה-HPC בענן כבר תומך ב-Job Management שאתם רגילים אליו, ולכן מעבר לשימוש HPC בענן יהא יחסית קל.

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

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

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

ישנן סיטואציות בהן ההחלטה היא יותר קלה לכאן או לכאן:

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

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

למעוניינים – גירסת וידאו קצרה המסכמת את הפוסט:

האם מומלץ להעביר מערכת שלמה לענן מ-On Prem?

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

למי שלא מכיר, אחד המושגים הכי שגורים בפני כל מי שמתעסק בתחום עננים ציבורים הוא המושג "Lift & Shift", כלומר המושג מתאר מצב בו הלקוח מעביר את כל או רוב התשתית שלו מה-DC שלו אל ספק הענן בתצורה כמה שיותר זהה. לדוגמא: אם יש ללקוח 100 מכונות וירטואליות שמריצות את כל האפליקציות, הפלטפורמות ושאר דברים ב-On Prem, ב-Lift&shift מעבירים הכל "כמו שזה" (או כמעט) אל ספק הענן הציבורי שהחברה חתמה מולה, כך שבסופה של ההעברה, יש 100 (או קצת פחות) מכונות וירטואליות רצות בענן.

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

להלן הסיבה מדוע אני לא ממליץ על המהלך:

ללקוח יש 100 מכונות וירטואליות והוא מעביר אותם בתהליך lift & shift. הלקוח בעצם ישלם את מחיר המקסימום לספק הענן מבחינת ההמרה. הועברו 100 מכונות, כאשר רוב המכונות כלל אינן מנצלות את המשאבים ב-VM. מה הרווח של הלקוח ממעבר כזה? מבחינת ביצועים, אינני בטוח שפתאום יהיו ביצועים גבוהים יותר (אלא אם מעבירים מכונות VM משרתים בני יותר מ-7 שנים). מה שכן, התשלום לספק הענן יהיה הרבה יותר מסיבי: אם הגדרת 100 ג'יגהבייט דיסק וירטואלי מבוסס SSD, אתה תשלם על 100 ג'יגהבייט (במיוחד אם הגדרת את ה-Block Storage מ-SSD מהיר), גם אם השתמשת ב-10 ג'יגהבייט. בענן אין "Thin Provisioning", וכנ"ל לגבי זכרון וכח עיבוד, וכל זה עוד לפני שינויים ואופטימיזציות שהלקוח רוצה לעשות כדי לעבוד בענן..

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

  • שימוש בשרותים מנוהלים במקום מכונות VM שאתה מקים/מריץ. יצא לי לבחון לא מעט שרותים של ספקי ענן שונים ואני חייב לציין שבמרבית המקרים, השרותים של ספקי הענן נתנו ביצועים טובים. בלא מעט מקרים, אצל לקוחות שונים מריצים מכונות VM שמריצים אפליקציות שונות – אין הגדרות ואופטימיזציה טובה. דוגמא פשוטה: אצל ספקי ענן שונים אפשר לאחסן את ה-DB המנוהל באחסון זול ומכני או SSD או ב-SSD מסוג מהיר, כאשר ה-OS יושב על אחסון מסוג אחר. (בסביבות On prem, רוב מכונות ה-VM גם רצות וגם מאחסנות את ה-DB על אותו סטורג)'. נכון, זה עולה יותר, אך הביצועים גם גבוהים בצורה משמעותית, שלא לדבר על כך שכשזה מגיע להגדרות של אפליקציות שונות (שרתי Web, שרתי SQL ועוד) – אצל רבים אין ממש אופטימיזציה – שכן קיימת בשרותים המנוהלים אצל ספקי הענן.
    לכן, לפני שחושבים להעביר את אותו שרת SQL (לדוגמא) – כדאי לחשב מה העלויות של שרות זהה מנוהל עם Instance דרוש ואחסון, וזאת בהשוואה ל-VM שאתם תקימו. כדאי לקחת בחשבון גם תחזוקה והשבתה שתתרחש במקרה של VM שלכם.
  • אפליקציות עצמאיות: שרותים כמו Beanstalk, או App Service של אז'ור, או App Engine של גוגל – ושלל פתרונות זהים אחרים – שרותים אלו נותנים לך בעצם להריץ את הקוד שלך בשפה שאתה כותב – על תשתיות ספק הענן, כאשר אינך צריך להקים תשתית של VM, תשתית Load Balancing ועוד. אתה כותב קוד ומאחסן אותו בשרות כלשהו, מצמיד Webhook לשרות הנ"ל בענן, והשרות כבר ירים ויריץ את כל מה שצריך מבחינת pipelines, הוא יקמפל ויארוז מה שצריך, ויכין Instances חדשים שבחרת את גודלם. אתה לא צריך לדאוג לגבי עומסים, המערכת תדע לבצע אוטומטית Scale Out לאפליקציה שלך ותוסיף/תוריד Instances כנדרש, ותצמיד אותם ברקע לשרות Load Balancing כך שלא תפסיד בקשות מדפדפנים או ממכשירים שונים (בהתאם לאפליקציה). כאן בדיוק נמצא עקב האכילס אצל חברות רבות שמריצות אפליקציות בתשתית On-Prem (או תשתית Hosting) שמשרתות גולשים וה-Scaling שלהם הוא ידני. עם שרותים כנ"ל, אפשר להגדיר Instances קטנים ולשלם מחיר זול רק על מה שהיה בשימוש, הקץ לניחושים והערכות לגבי הקמה של יותר מדי או פחות מדי משאבים.
  • קונטיינרים: זו ה-טכנולוגיה של השנים האחרונות שחברות רבות כבר עברו להשתמש בה (ומי שלא – הסעיף לעיל רלוונטי לגביו) וכאן ספקי ענן שונים מציעים שרותי קונטיינריזציה שונים, בין אם מדובר על שרותי קונטיינר מנוהלים שאתה מחליט כמה Instances להקים/להוסיף/להוריד, ובין אם מדובר בשרותים שאתה כלל לא דואג לתשתית ובמקום זאת אתה פשוט משלם על שימוש בזכרון ובמשאבי עיבוד. השילוב של קונטיינריזציה ושימוש בתשתית של ספקי ענן ציבוריים יכול לתת פתרון עם ביצועים מעולים ולאו דווקא מאוד יקרים.

מעבר לענן ציבורי יכול לחסוך כסף, כל עוד מוכנים "לשנות את הדיסקט" בראש ולוותר על חלק משיטות העבודה מה-20+ שנה האחרונות. שיטות כמו Lift & Shift לא יעזרו הרבה ללקוח אבל הם בהחלט יעזרו לשורה התחתונה מבחינת כספים לספק הענן הציבורי שבו הלקוח משתמש. אם רוצים לעבור לענן ציבורי, אני ממליץ לחשוב על המעבר כעל פתיחת דף חדש, תוך אימוץ טכנולוגיות מודרניות ונטישה הדרגתית של טכנולוגיות Legacy.

גישות SaaS/PaaS והגישה ההיברידית

כמעט בכל חברה יתקיים מצב בו החברה תחפש תוכנה שתבצע שרות X או שתתן שרותי פלטפורמה Y במקום "להמציא את הגלגל" מחדש בכל פעם. אם לדוגמא העסק מעוניין לשלוח איחולי חג שמח לכל הלקוחות, ניתן יכול לשכור שרותי Saas של חברה כמו Mailchimp לדוגמא ובתמורה תקבלו ממשק קל לשימוש וסיכוי מאוד גדול שכל לקוחות העסק יקבלו את המייל. מצד שני אפשר בעזרת מעט סקריפטולוגיה ושימוש באמזון SES לבצע את אותו דבר אך במחיר זול בהרבה (יכול לחסוך לא מעט אם לחברה יש מאות אלפי או מיליוני לקוחות לדוגמא). אפשר כמובן לקחת גם את האופציה החינמית ולהקים שרת מייל או להשתמש בשרת מייל מקומי כדי לשלוח את הררי האימיילים, אבל במקרים כאלו הסיכוי שהמייל יתקבל אצל כל הלקוחות הוא די קלוש – אם לא משקיעים בכל עניין של Whitelist, RBL, דבר שלוקח לא מעט זמן ומשאבים.

יותר ויותר חברות תוכנה מקצצות בהשקעה של כתיבת תוכנות והפצת כ-Stand alone המיועדות לרוץ על שרתים בתשתית מקומית של הלקוח, וזאת ממספר סיבות, הנה 2 העיקריות:

  1. עלויות תמיכה – ככל שתוכנה נמכרת כ-Stand Alone, עלות התמיכה ליצרן התוכנה תהיה גבוהה, מכיוון שיש לא מעט סיכוי שהתוכנה לא תעבוד בסביבות או מכונות שונות, הרשאות שגויות, חוסר ידע טכני של הלקוח ועוד. ככל שהתומכים הטכניים יהיו עסוקים יותר ויותר שעות בפתרון בעיות של לקוח ספציפי זה או אחר, הרווח של יצרן התוכנה ירד. אחרי הכל, אף אחד לא משלם ליצרן התוכנה אם מחלקת התמיכה השקיעה 10 שעות בפתרון בעיה אצל לקוח יחיד לדוגמא.
  2. פיראטיות – בהרבה מאוד חברות הצוות מוריד אפליקציה או פלטפורמות מסויימות למטרת Trial ומיד לאחר מכן הם מחפשים כל מיני כלים ודרכים כדי לפרוץ את ה-Trial. הרווח של יצרן התוכנה ממקרים כאלו – אפס.

מהרגע שיצרן התוכנה מציע את מוצריו כ-PaaS או SaaS, הדברים נהיים יותר קלים עבורו:

  1. אין פיראטיות
  2. עלויות התמיכה מצטמצמות משמעותית הואיל והכל רץ בתשתית וירטואלית של יצרן התוכנה בעננים שונים ומקרי התמיכה נהיים יותר ויותר פשוטים כי ניתן לשחזר את התקלות במחלקת התמיכה של יצרן התוכנה.
  3. תזרים הכנסות חודשי/שנתי רציף מהלקוחות.
  4. קצב הפיתוח מואץ יותר, באגים ופונקציונאליות חדשה נכנסת ל-Life Cycle של השרות במהירות גבוהה יותר ובכך דרישות לדברים חדשים שלקוחות מבקשים – נענים במהירות גבוהה יותר.
  5. אין צורך בתמיכת Legacy הואיל וכולם עובדים על גירסה אחת או שתי גרסאות.

אך יש גם חסרונות:

  1. עלויות תשתית הרבה יותר גבוהות בענן ציבורי. בניגוד למכירת תוכנת Stand Alone שלא מתחברת החוצה, כאן פתרון ה-Saas/PaaS יצטרך חיבור קבוע למשאבים שונים של יצרן התוכנה.
  2. אבטחת המידע צריכה להיות הרבה יותר רצינית בהשוואה למקרים של תשתית סגורה החוצה. מהרגע שמתגלה אצל יצרן כזה דליפת מידע, יש סיכוי לא רע שחלק מהלקוחות יעדיפו לנטוש ולחפש פתרון מתחרה.

אלו, פחות או יותר הסיבות שבגללן חברות תוכנה יעדיפו להציע שרותי PaaS/SaaS.

אחת הנקודות שבמקרים רבים אינני רואה התייחסות מצד אותן חברות – היא למקרים שהלקוח אינו מוכן "לעבור All In", כלומר הלקוח לא מוכן שכל ה-DATA שלו ישב בתשתית של יצרנית תוכנה ולו (ללקוח) לא תהיה שליטה על הנתונים מבחינת אבטחת מידע או בכלל מהבחינה העקרונית שזה ישב בתשתית של חברה אחרת שאין לו מושג ירוק לגביה. זו לדוגמא אחת הסיבות שחברות יעדיפו לוותר על פתרון SaaS/PaaS שמוצע רק על ענן ובמקומו הם יעדיפו פתרון שרץ מההתחלה ועד הסוף על תשתית מקומית (On Prem).

מה שלעניות דעתי אותן יצרניות תוכנה PaaS/SaaS צריכות להציע – הן את האפשרויות הבאות (אחת או יותר), משהו שהוא יותר מעין "Hybrid":

  1. ה-DATA של הלקוח יכול להיות מאוחסן On Prem עם Agent שמתחבר לענן. לשרות תהיה גישה עם הרשאות מאוד מוגבלות
  2. אם ללקוח יש חשבון בענן ציבורי כלשהו, הלקוח יוכל להגדיר אחסון אובייקטים כלשהו (S3 לדוגמא) עם הרשאות מוגבלות שינתנו בעת הפעלה ראשונית של שרות ה-SaaS/PaaS והרשאות אלו יהיו תחומים למשאבים מסויימים בלבד (נניח Bucket כלשהו)
  3. הלקוח יצטרך לבחור כבר בהתחלת שימוש ה-PaaS/SaaS את ה-Passphrase שלו (ובלבד שיהיה מורכב) ועם אותו Passphrase (ואולי יחד עם עוד מספר נתונים) יוצפן ה-DATA של הלקוח כך שגם ליצרן התוכנה לא תהיה גישה לנתונים. (אפשר כמובן במקום Passphrase יהיה אפשר להשתמש במפתחות פרטי/ציבורי יחד עם Passphrase)

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

תשתית מקומית וענן: חסכון – צו השעה

כמעט בכל חברה מגיע מצב שאחת הסיטואציות הבאות מתרחשות:

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

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

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

אז איך בעצם ניתן לחסוך?

בכל הקשור לתשתית מקומית, ההמלצה שלי במקרים רבים היא לפני שאצים רצים לרכוש שרתים חדשים לדוגמא, לשדרג את הקיימים. תחליפו מעבדים לכאלו עם יותר ליבות, תוסיפו זכרון, אם אתם עובדים עם דיסקים מקומיים – תחליפו אותם ל-SSD טובים וכו'. אם לדוגמא רכשתם (בחוכמה) שרתים כמו של חברת SuperMicro, אז אתם בכלל יכולים לעבור קדימה דור של מעבדים (לדוגמא: V3 ל-V4 או Xeon SP דור ראשון לדור שני) – כלומר בלא מעט מקרים ניתן לשדרג תשתית קיימת של שרתים ולהרוויח ביצועים יותר גבוהים, וזאת במחיר קטן בהרבה מרכישת שרת חדש (מה גם שהשדרוג נתמך לחלוטין על ידי היצרן והמפיץ)

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

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

  • להפסיק לחשוב על הענן הציבורי כ-DC פרטי שלנו. ב-VMware, כשמקימים מכונה מקומית וכשאתה מגדיר VM עם 16 ליבות או חצי טרה אחסון (ב-Thin Provisioning) – אז המערכת תהיה מספיק חכמה לתת לך משאבים, אבל לא לחסום את המשאבים הללו משימוש מכונות VM אחרות. בענן ציבורי – אתה משלם על כך, גם אם השתמש באחסון ב-2% ובמעבד ב-4%, אתה תשלם כאילו ניצלת את הכל, אז במקרים כאלו, כדאי לשנות Instance או לבנות אותה מחדש עם משאבים יותר מצומצמים.
  • לנטר ולצמצם – כלים כמו Terraform יודעים היטב לתמוך בכל ספקי הענן הציבורי. נכון, זה לא בדיוק "קליק קליק קליק" אבל בהחלט שווה להשקיע וללמוד ואז להתחיל להריץ את זה על החשבון שלכם ולמצוא מה המשאבים שאינם מנוצלים, דברים שהוגדרו בפראות אבל לא ממש משומשים וכו' – ומשם להחליט מה לעשות עם זה. החסכון בשיטה הזו – גדול מאוד.
  • להפסיק להתעצל! אתה צריך SQL שכל מה שמתחבר אליו זה client ורבע? תקים קונטיינר או Instance כזה בעצמך במקום להשתמש בשרות מנוהל. זה יותר זול. נכון, צריך להשקיע קצת יותר בהקמה והגדרה, אבל זה חוסך בטווח הארוך.
  • לעבור לקונטיינרים במקום מכונות וירטואליות – קונטיינר תופס פחות משאבים, ניתן לרפלק, ויש לו Scaling מעולה. אה, ובחישוב סופי, זה יוצא יותר זול.
  • לבחור תוכנות אחרות שהן יותר "Native" לענן – תוכנות שיודעות לאחסן ב-Object Storage לדוגמא, שהוא הרבה יותר זול מאחסון שמחובר ל-Instance, וזו רק דוגמא אחת.
  • לכבות מכונות – מכונה כבויה עולה הרבה פחות ממכונה פעילה (אתה עדיין צריך לשלם על האחסון שהיא תופסת), אז אולי הגיע הזמן לאיזה סקריפט קטן שרץ על כל המכונות ומכבה כאלו שלא עושות כלום, ואגב, עדיף להגדיר עם Terraform שמכונות מסויימות יכובו אוטומטית (או ימחקו) לאחר זמן מה, כמו מכונות טסטים שהוקמו זמנית ושכחו מהן.

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

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

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

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

נדמיין עתה מצב תיאורתי שבו החלטתי להתחרות בכולם. אני משיג VC נחמדים ומשכנע אותם להשקיע בעסק שלי סכום נחמד של 8 ספרות (בדולרים). אני רוכש כמה עשרות ארונות, מפזר אותם בין ספקי האינטרנט השונים בארץ, "מפוצץ" את כולם בשרתים חדשים ואני מקים בדרך SDN ו-Software defined storage מפלצתי. על כל התשתית הזו אני מקים מערכת שתתן ללקוחות דרך ממשק WEB ודרך API את השרותים הבאים:

וירטואליזציה, קונטיינרים (עצמאית, ללא צורך בהקמת מכונות וירטואליות), Serverless, הקמת "ברזלים" יעודיים ללקוח, שרותי Object Storage ו-Block Storage, שרותי NFS/CIFS יעודיים לרשת שלך בלבד, שרות רשת פרטית משלך (כמו VPC), שרותי Load Balancer, שרותי DNS, שרותי identity, שרותי Imaging למכונות VM שלך, שרותי אורקסטרציה, שרותי Messaging, שרותי התראות, שמירת משאבים וחלוקתם על ידי הלקוח, אורקסטרציית קונטיינרים, ביג דאטה, שירותי גיבוי, שחזור ו-DR, תאימות ל-EC2 (כפרוקסי), מטריקות, ניטור מלא של הכל, שרותי Event (כמו Cloud trail), שרותי Governance ושרות יחודי של Benchmarks, וכמובן – שרותי Billing ו-Chargeback – וכל זה זמין ביום הראשון. תירשם, תכניס פרטי כרטיס אשראי וצא לדרך.

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

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

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

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

לסיכום, אני ממליץ לחשוב על 2 דברים חשובים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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