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

Print Friendly, PDF & Email

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

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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