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

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

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

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

הנקודה הראשונה היא עניין הידע הטכני שקיים באותה חברה. בסטארטאפים לדוגמא, כל עניין ההקמה, תחזוקה, הגדרות, אוטומציה – נופל על איש (או צוות, בהתאם לגודל הסטארטאפ) ה-Devops. מכיוון שרוב מוחלט של הסטארטאפים מקימים את התשתית שלהם בגוגל או באמזון, קיימת חובה מצד איש ה-Devops לדעת היטב דברים כמו Bash, Python הבנה של פורמט קבצים כמו JSON, YAML וכמובן אוטומציה כמו Puppet או Chef, Ansible. בלי זה – איש ה-Devops לא יתקבל לעבוד ב-Startup. זה שמישהו מכיר סיסטם Windows או ניסה פעם אובונטו וגם אם הוא יודע PowerShell, ידע זה לא ירשים את המראיין והוא יפסול את המועמד.

לעומת זאת, חברות לא מעטות בארץ ובחו"ל מעדיפות את הענן של מיקרוסופט, וכאן איש ה-Devops יצטרך יודע ידע בטכנולוגיות של מיקרוסופט (PowerShell ואחרים) כדי לעבוד. מיקרוסופט נותנים SDK לשפות אחרות ו-CLI למערכות הפעלה פופולריות, אך מי שעובד לדוגמא הרבה עם AWS ויעבור להשתמש ב-Azure, יגלה לאחר זמן מה שמיקרוסופט יותר משקיעה בטכנולוגיות שלה מאשר בטכנולוגיות האחרות. כך לדוגמא אם תרצה לבצע אוטומציה עם הכלים הפופולריים בלינוקס, החיים שלך לא יהיו כל כך קלים.

לסיכום נקודה זו: Azure יותר מתאים לחברות שיש להן תשתית בסיס שמורכבת מתשתיות מבוססות מיקרוסופט (AD וכו') וגם יש לאותה חברה שרתי Linux (סתם דוגמא: 70 VM של Windows ו-30 לינווקס) עם אנשים שרובם מבינים בתשתית של מיקרוסופט. אם המצב לעומת זאת הפוך, הפתרונות של גוגל ושל אמזון (לעניות דעתי) יתאימו הרבה יותר לעבודה.

הנקודה השניה החשובה לדעתי זו המחשבה של העברת מכונות אחת לאחת מה-DC שלכם לענן (לדוגמא: העברת 100 VM מה-DC שלכם לענן הציבורי). לא חשוב איך תסתכלו או איזה ספק ענן תבחרו, החשבוניות שתקבלו יהיו מבהילות מסיבה אחת פשוטה: שום ספק ענן ציבורי לא מחפש למשוך לקוחות רק כדי לארח את ה-VM שלהם כ"ספק טיפש" כמו אלפי ספקי VPS בעולם. כל הנקודה של ספקי הענן היא שתשתמשו בשירותים שלהם. אל תרימו Exchange לדוגמא, אלא תשתמשו בשרותי המייל שלהם. אל תרימו SQL משלכם אלא תשתמשו בפתרון ה-SQL שלהם ובכך תוכלו להתחיל בקטן ולגדול עד למימדים מפלצתיים, הכל בתשלום לפי שעה (חלקם לפי דקה) ובמקרים כמו אמזון (בחלק מהמקרים) – ההמלצות הם להשתמש בדברים כמו Serverless ללא צורך ב-VM יעודי, במקום להשתמש ב-Load Balancer הקלאסי שכולנו מכירים – להשתמש בשרות (החדש) ALB שעושה Load Balancing לאפליקציות במקום שכבות.

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

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

בהצלחה 🙂

המעבר לעננים

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

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

האם המעבר לאופיס 365 תגרום ל-Corporates השונים בארץ לעבור לגמרי לענן? לעניות דעתי – לא כל כך מהר. בשביל Mail, השהיה (Latency) של 100 מילישניות לערך אינה כזה עניין גדול, לא מרגישים את זה, אך כשמדובר ב-RDP או פרוטוקולים אחרים כמו HTTP ואחרים – העניין הופך לבעייתי ובכלל בארץ, בניגוד לסטארטאפים שמתחילים מהדקה הראשונה עבודה על ענן, ה-Corporates מאוד שמרנים ויקח זמן עד שהם יעברו לענן. גוגל, אמזון ומיקרוסופט מודעות בהחלט לעניין, ומיקרוסופט לדוגמא מכינה את ה-Azure Stack – הנה לך אדוני המנמ"ר/CTO "מיני Azure" שכולו יושב ב-Data Center שלך. כל ה-DATA שלך יושב בחווה שלכם ושום דבר לא זז החוצה אם לא תרצה, ואם תרצה – תוכל לחבר את ה-Stack הזה בקלות ל-Azure הענן. גם אמזון התכוננו לרגע הזה והם חתמו עם VMWare על פרויקט חדש שנקרא VMWare Cloud on AWS שנותן לך גם פתרון שמשלב את ה-Data Center שלך עם AWS כך שתוכל להתרחב מה-DC שלך החוצה ל-AWS (והפוך). גם לגוגל יש פתרון שהוא בפיתוח ובשלב זה אין עליו מידע פתוח.

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

ובכל זאת, חברות רבות "מסתקרנות" לגבי מעבר לענן. הסיפורים של כל מיני סטארטאפים איך הם נותנים שרות למליוני אנשים ומשלמים רק כמה אלפי דולרים בודדים בחודש לספק הענן גורם לסקרנות ולרצון להתנסות, המחירים בסנטים גם קורצים לחברה שמסתקרנת רצון לטבול אצבעות, ואז הן הולכות למחשבונים של ספקי הענן ואחרי מספר חישובים הן נרתעות. סתם דוגמא: באמזון, שרת Windows יחיד עם 8 ליבות ו-32 ג'יגה זכרון עם דיסק (EBS) של 200 ג'יגה יעלה לחברה $733 בחודש וזה כמובן לא כולל תעבורה החוצה וגם התמיכה של אמזון היא ברמת הבסיס. זול – זה לא. (אגב, גם בגוגל וגם במיקרוסופט המחיר יהיה פחות או יותר זהה) – אז הרעיון לנסות מעבר כלשהו נכנס בחזרה למגירה.

הרווח הגדול של ספקי הענן הגדולים מגיע מהשכרת שרתים ובמיוחד מהליבות (cores). הם מוכרים כל ליבה במחיר מוערך של 30-50$ לחודש וגם הזכרון אינו זול (בערך 10-20$ לחודש, תלוי בקונפיגורציה, מערכת הפעלה, סוג תקשורת וכו'). מדוע? כי כמות הליבות שניתנת למכירה בשרת אינה כה גדולה. שרת עם 16 ליבות אפשר למכור לדוגמא ל-20 לקוחות שכל אחד מקבל ליבה, אבל לא ל-30 לקוחות – כי הלקוחות רוצים ביצועים (בניגוד לספקי VPS שדוחפים עשרות לקוחות על מכונה עם 8 ליבות). ספקי הענן יכולים לרכוש שרתים עם 8 מעבדים כשכל אחד מהם כולל 16 ליבות לדוגמא, אבל העלות של שרת כזה גבוהה מדי בשבילם ולכן ברוב המקרים אם תבדקו מה המעבד שנמצא במכונה שלקחתם מספק הענן, תמצאו שהמכונה מכילה מעבדים כמו Xeon E5 26XX (כלומר מקסימום 2 מעבדים ועד 8 ליבות פר מעבד, ברוב הזמן זה יהיה דגם של 4 ליבות). יש לספקי הענן גם מכונות עם מספר מעבדים וליבות גדולים, אך המחיר – גבוה בהרבה מהמחיר שציינתי.

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

אז איך לדוגמא חברת X תוכל להתנסות בענן ציבורי מבלי לשרוף אלפי דולרים בחודש על PoC?

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

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

לאחר שהנתונים יועלו לספק הענן, נצטרך להתחיל לבנות את התשתית המאובטחת שלנו מבחינת כתובות IP פנימיות, Subnet, Internet Gateway וכו' וכו' ולהחיל אותם על ה-VM שלנו שבענן (אצל חלק מהספקים יש צורך בהקמת ה-VM מהגיבוי שהעלתם/שלחתם, אצל חלק זה אוטומטי). אחרי שיש לנו את ה-VM למעלה, יכול להיות שנצטרך לשנות כתובות IP בהתאם לתשתית שהגדרנו. המטרה הסופית היא שבסוף כל ה-VM ששלחתם יעלו ותהיה לכם תקשורת אליהם בדיוק כמו שיש אצלכם ב-DC (אם כי ישנם שינויים שתצטרכו לעשות, כמו לא לתת כתובת IP חיצונית לכל שרת אלא לעבוד בצורה מסודרת מול Gateway או עם Bastion אם אתם עובדים עם מכונות לינוקס). הכל עובד? מצוין. בשלב זה תתחילו לעבוד עם המערכת כמו שהיא בימים או שבועות הקרובים. קיבלתם קרדיט, זה לא עולה לכם שקל, נצלו את זה 🙂

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

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

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

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

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

ולמי שמעוניין לעבור את התהליך או לקבל יעוץ – אשמח לסייע 🙂

הכנת VM מבוסס לינוקס לשימוש אצל ספקי ענן

חברות רבות משתמשות כיום בשרותיהן של ספקי ענן (אמזון, גוגל, Azure, Rack Space, Digital-Ocean ועוד) ובמקרים רבים אנשים מקימים לעצמם את השרתים בשיטה הקלאסית: בוחרים מערכת הפעלה מהתפריט שהספק מציע (או משתמשים ב-Image שהספק מציע), ולאחר מכן הם מבצעים כניסת SSH, ומשם הם ממשיכים להתקין חבילות, לבצע הגדרות, להעלות סקריפטים, להוסיף משתמשים וכו' וכו'.

שיטה זו היא שיטה מעולה – אם כל מה שיש לך זה שרת יחיד או כמות Fixed של שרתי VM. אחרי הכל, חברות רבות מעדיפות להקים מספר קבוע של X שרתים ועם זה הם יתמודדו, יגדירו Flow וכו'.

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

הבעיה בהקמת שרת נוסף היא הזמן שלוקח לשרת כזה "לקום". הבלוג של חברת Flycops נותן דוגמא מצוינת לכך. במקרה שלהם, כל שרת חדש שהיה מוקם במסגרת ה-Scale Up לקח לו לא פחות מ-6 דקות עד שהוא היה מסוגל לקבל גולשים. זה אולי נשמע זמן קצר, אבל אלו 6 דקות שאתם כחברה תפסידו גולשים שמגיעים מכל מיני מקומות שונים (גוגל, בלוגים, אתרים שמפנים אליכם, לינקים מאימיילים וכו') וחבל.

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

איך עושים זאת? די פשוט:

  • בשלב ראשון נשתמש במערכת וירטואליזציה שיש לנו מקומית. זה יכול להיות ESXi, זה יכול להיות VMWare לדסקטופ, זה יכול להיות VirtualBox או יכול להיות (ומה שהח"מ משתמש) KVM.
  • נקים Guest חדש ונשתמש ב-ISO של הפצת הלינוקס המועדפת עלינו. מבחינת גודל דיסק, לא מומלץ "להשתולל" (במיוחד לאלו שאינם יכולים להקים מכונה עם Thin Provisioning) – ברוב המקרים 8-10 ג'יגה אמורים להספיק בהחלט. מבחינת Partitions, כל אחד יכול להחליט באיזה שיטה ללכת, עם או בלי LVM. אני ממליץ לבצע Partition יחיד (flat) שהכל ישב שם. חשוב: מבחינת חבילות לא מומלץ להתקין GUI גרפי, זה סתם יתפוס מקום ומשאבים.
  • לאחר שסיימנו עם ההתקנה נפעיל את המכונה הוירטואלית, נתחבר אליה (ב-SSH) ונוודא שיש לה חיבור לאינטרנט.
  • בשלב הבא אנחנו צריכים להתקין את האפליקציות שאנחנו צריכים שיהיו ב-VM. אני ממליץ לבחור באחת מהפתרונות הבאים:
    • יש את Packer (שכתובה ב-Go – תודה לעמוס על התיקון) שאיתה אפשר לבנות את כל ההתקנה שאתם צריכים על ה-VM. היא מתאימה מאוד לחובבי JSON.
    • יש את Cloud-Init שכתבו קנוניקל ורד-האט "אימצה" בשמחה. היתרון שלו שהוא הרבה יותר ידידותי לאנשי סיסטם שלא מעוניינים להתעסק יותר מדי "בקרביים". עם Cloud-init מגדירים מה המשתמשים שיהיו, מה החבילות שצריך, וב-reboot הבא המערכת כבר תעשה את הכל לבד.
      שימו לב: את Cloud-init יש להתקין בתוך ה-VM. מכיוון שהוא נמצא ב-REPO של EPEL, יש לבצע yum install epel-release (לא צריך את ה-URL עם הגירסה האחרונה אם אתם משתמשים ב-CentOS, זה אוטומטי), ולאחר מכן yum install cloud-init.
    • אפשרי לעבוד עם Puppet – כל עוד אתה יודע לעבוד ללא Puppet Master.
    • חשוב מאוד – בצעו update לאחר שהתקנתם את מה שרציתם. המכונות שיבוססו על ה-image הזה ישרתו אנשים מבחוץ ולא נעים לחטוף פריצה רק בגלל ששכחנו לעדכן את כל ה-DEB/RPM.

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

  • כבו את המכונה הוירטואלית וגשו למחיצה שבה היא נמצאת.
  • התקינו את חבילת libguestfs בהתאם להפצת לינוקס שאתם משתמשים בה (מחוץ ל-VM)
  • מכיוון שיכול להיות שהמכונה כוללת דברים שאין לנו צורך בהם (מפתחות שונים שהשתמשנו כדי להעתיק ממקומות אחרים, תעודות SSL, קבצי מטמון וכו') נשתמש בפקודה virt-sysprep כדי לנקות את ה-Image. הריצו את הפקודה virt-sysprep -a image.vmdk (כאשר image.vmdk זהו שם ה-image של ה-VM שלכם). פעולת ה-virt-sysprep תנקה את כל מה שלא צריך וגם תמחק את כל ה-MAC Address שיש לכרטיסי רשת.

לפני שאנחנו מעלים את ה-image לענן, חשוב לבדוק שאתם מגדירים partitions ודברים נוספים (kernel modules, הגדרות שונות) לפי מה שהספק ענן שלכם מבקש, וכל ספק עם השטיקים שלו.

אם אתם משתמשים ב-Ravello (כדי לבצע testing, PoC):
אנחנו צריכים להקטין את ה-image לגודל קטן (מכיוון שהתקנות יוצרות קבצים זמניים שנמחקים, ה-image בעקרון אינו קטן בצורה אוטומטית). לשם כך נשתמש בפקודה virt-sparsify (שוב, לשים לב שהמכונת VM כבויה) בפורמט הבא:
virt-sparsify image.qcow2 final.qcow2
(שוב, image.qcow2 הוא שם המכונה שלכם כרגע, final.qcow2 זה השם image לאחר ההקטנה).

אם אתם משתמשים ב-Google Compute Engine
במקרה זה מומלץ לעקוב אחר ההוראות כאן כיצד להעלות את ה-image ומה מומלץ שיהיה בו.

אם אתם משתמשים בשרות של אמזון
במקרה של שרות באמזון, לצערי בשלב זה הם אינם מקבלים קבצי qcow2 ולכן תצטרכו להמיר את ה-image שלכם ל-VMDK (ההוראות הן כמו הקישור לעיל, רק שבמקום O qcow2- תצטרכו לכתוב
O vmdk- ).

כעת נוכל להשתמש ב-image שהעלינו כ-Template. מומלץ לשמור את ה-image היכן שהוא ולעדכן אותו אחת לתקופה ולהעלות אותו שוב (לאחר שעבר virt-sysprep) לענן ולהשתמש ב-image החדש כ-template.

גוגל נכנסת חזק לתחום הענן הציבורי

עד לאחרונה, בכל הקשור למחשוב ענן שפתוח לציבור, האפשרויות הכי ידועות היו אמזון (כמובן) ומיקרוסופט עם Azure, כאשר אמזון מובילה בביטחה בכמות המשתמשים, הפתרונות, הפלטפורמות וכמובן – ערימת השרותים שהיא מציעה הכוללת שורה ארוכה של שרותים שאף ספק מתחרה לא נותן תחת קורת גג אחת. מכיון שאמזון מציעה את כל אותם שרותים במחירים תחרותיים מאוד, הרבה מאוד סטארט-אפים וגם חברות גדולות וידועות (טוויטר?) משתמשים בתשתיות של אמזון ולאמזון יש תשתיות בשפע ופתרון כמעט לכל דבר שתרצה, החל מענייני ניתוב DNS, אם זה CDN, הרמה של כמות מכונות גדולה בזמן קצר כדי להתמודד עם עומסים, מאזן עומסים (Load Balancer), ועוד – וכל זאת במחירים נמוכים (יחסית, כמובן. אם אתה צריך רק שרת אחד שעליו אתה עושה הכל בלי שום שרותים נוספים ובלי שרידות, אמזון לא מתאימה לך).

לתחום הענן הציבורי נכנסה בשנתיים האחרונות (באיחור אופנתי, כרגיל) מיקרוסופט עם ה-Azure שלה. בהתחלה כמערכת שאתה מפתח עליה אפליקציות במגוון שפות, ולאחר מכן שרותי Azure גדלו ל-IAAS/PAAS. במיקרוסופט, שהכח העיקרי שלה מגיע מהשוק העסקי, עשו דברים קצת שונים מאמזון והחלו את המתקפה על השוק העסקי עם Office 365 כשהם משכנעים ארגונים רבים לאחסן את המייל/יומן/מסמכים בענן, ורק לאחרונה נודע כי מיקרוסופט הולכת להציע שרותים אלו גם גירסה אישית במחיר של 7$ לחודש (או 90$ לשנה) שאותה אפשר להריץ על Windows או MAC או בגרסאות הטאבלט/מובייל שמיקרוסופט הוציאה ותוציא. במקביל מיקרוסופט מנסה לדחוף בצורה אגרסיבית את שרותי ה-IAAS כתחליף לאמזון ולשם כך היא משתמשת ב"צבא" אנשי המכירות שיש להם עם דילים שונים בהתאם לגודל הארגון. עד כה המאמצים להעביר חברות מאמזון ל-Azure לא ממש מנחילים הצלחה רבה למיקרוסופט, אבל תסמכו על מיקרוסופט שיעשו הכל כדי שחברות סטארט-אפ או כל חברה שמציעה שרותי Web ישתמשו ב-Azure. מיקרוסופט אפילו נותנת תמיכה (לא מי יודע מה, למען האמת) בגרסאות לינוקס CentOS/RHEL (מנסיון אישי שלי: אם נתקלת בבאגים, תתחיל לחפש פתרונות בגוגל, התמיכה של מיקרוסופט כולל תמיכה בחו"ל פשוט לא יודעים לתמוך בלינוקס, במיוחד אם אתה מרים הגדרות רשת מורכבות.)

לשטח הזה נכנסים גוגל (ליתר דיוק נכנסו). עד כה גוגל הציעו את ה-App Engine, שרות PAAS שמאפשר לך לפתח אפליקציה שתרוץ בענן של גוגל, אולם בשנה האחרונה גוגל התחילה להציע שרותי IAAS כאשר ההצעות שהם מציעים נשמעים מעולים לאנשי לינוקס שמכירים לינוקס טוב, אבל לך תסביר את הדברים למנהל מעליך, במיוחד שכמות מערכות ההפעלה שנתמכות היתה די קטנה וממש מיועדת לגיקים (Debian 6,7, CentOS 6.2), או שתסביר לו כמה זה מעולה שאתה יכול להרים מערכות Diskless, את זה שאתה יכול להרים 1200 מערכות מאפס תוך פחות מדקה, ושלל דברים מגניבים ששוב – מדברים לגיקים שבינינו אבל קשה לשכנע את ההנהלות לקחת את ה-IAAS ולהשתמש בו כמשאב עיקרי לחברה, כך שהמצב היה שגוגל התחילה להציע דברים, אבל מבחינת שוק – לא הרבה נכנסו אליו. אבל דברים מתחילים להשתנות אצל גוגל ועכשיו הם מתחילים לצאת לאור, ועבדכם הנאמן יגלה כאן כמה דברים שאותם תשמעו רשמית עוד שבועיים: גוגל אתמול הוציאה הודעה שעשתה כאב ראש רציני למתחרים: חיתוך מחירים סופר אגרסיבי באחסון און ליין, ספציפית ב-Google Drive. מעתה, 100 ג'יגהבייט יעלו לך בחודש רק $1.99. רוצה טרהבייט של מקום? בכיף, המחיר צונח מ-50 דולר ל-$9.99 לחודש. רוצה לאחסן את כל ספריית המוסיקה/קליפים/תמונות שלך וצריך 10 טרה? זה יעלה לך $99.99 לחודש, כלומר המחיר צנח בעשרות אחוזים כלפי מטה.  זה נחמד, אבל מה עם האחסון ב-IAAS? (מה שתואם ל-S3 של אמזון) – ובכן, גם הוא בעוד שבועיים יקבל הנחתת מחיר אגרסיבית.

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

  • צריך גרסאות Windows? כן, גם בגוגל שמעו שעסקים מעוניינים ב-Windows Server והם שכרו צוותים שלמים לתמיכה והקמת מערכות כך שתוכל להקים לך Windows Server 2012 כ-VM כולל כל השרותים והתמיכה שתצטרך.
  • ה-App engine יעבור שדרוג מאסיבי ומעתה תוכל להרים עליו שרותים כמו Joomla ועוד – כך שכל מה שתצטרך זה להקים Engine, לזרוק עליו Joomla עם העיצובים והתוספים שלך. לגבי כל עניין ה-Scaling לא תצטרך לדאוג כי המערכת של גוגל תדאג לזה (אה, ולא תצטרך לשבור את הראש על ההגדרות של Web Server או MySQL וכו' – הכל יהיה יותר קל)
  • אפליקציות נוספות יתמכו ללא שינוי קוד דרך ה-App Engine
  • הרצת כל גירסת Linux וכל Kernel שתרצה. (כן, כולל תמיכה ב-SELinux וגם הפצות מבוססות Rolling Release).
  • תמיכה מלאה ב-Docker (כך שתוכל להקים כמה קונטיינרים עם מערכות לינוקס אחרות על VM יחיד)
  • הבטחה להגנה נגד DDoS
  • ואת שאר הדברים תשמעו עוד שבועיים (אני לא מעוניין למתוח את החבל יותר מדי עם גוגל..)

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

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

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