תגית: ענן

על מעבר לעננים, אירוח אתרים ועוד כמה דברים

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

נתחיל בתחום האירוח אתרים. עד היום חברות שונות בארץ ששוכרות מקומית מכונות וירטואליות/שרתים לשם אירוח האתרים מהסיבה הפשוטה של Latency ו-SEO (לנקודת ה-SEO לדעתי אין שום אחיזה בכל מה שנוגע ל-Latency ואני יכול להעיד שיש לי כמה מילות מפתח במקום ראשון בגוגל והשרת הוירטואלי שלי נמצא בכלל ב-Amazon Lightsail בוירג'יניה!). עד היום היה ניתן לארח את האתר שלכם בחו"ל ולהשתמש בשרות CDN כמו של Incapsula שלהם יש שרתי EDGE פה בישראל. החל מעתה, גם למתחרה הגדול שלהם (Cloudflare) יש נקודת EDGE פה בישראל כך שאפשר בהחלט להשיג Latency מאוד נמוך גם מבלי לשכור מכונות בארץ ובכך ניתן לחסוך בעלויות השכרה.

מכאן נעבור לעננים ציבוריים ולחברות בינוניות עד גדולות (במובן האמריקאי/אירופאי, פחות במובן הישראלי). בשנים האחרונות, עם כניסת העננים הציבוריים יותר ויותר לקידמת הבמה, חברות בסדר הגודל שהזכרתי לעיל "השתעשעו" (במובן של PoC, העברת מספר מכונות לענן ציבורי כלשהו לצרכי טסטים ו"טבילת אצבעות" וכו'). חברות רבות קיבלו קרדיטים מספקי הענן הציבורי (בסכומים הנעים מעשרות עד מאות אלפי דולרים). חברות רבות השתמשו באותם קרדיטים כדי להעביר תשתיות כלשהן לענן ובאותו זמן לפי כל החברות המודדות מכירות שרתים, מתגים, סטורג' וכו' (חברות כמו IDC, מורגן סטנלי, גרטנר ואחרים) הוציאו דוחות שכמות הציודים ל-DC/שרתים שנמכרת מאותם יצרנים הולכת וקטנה והטרנד הזה נמשך כבר יותר מ-5 שנים, אולם לקראת סוף 2016 האחוזים עלו במעט ואילו ב-2017 האחוזים עלו בצורה יפה (7% בהשוואה ל-2016) לפי הדו"ח של חברת Canalys שהופיע ב-The Register כאשר Cisco מכרה יותר מאשר Dell/EMC (ו-Dell/EMC מכרה יותר מ-HPE). דו"ח של חברת Morgan Stanley ציין פחות או יותר את אותם דברים בחודש שעבר.

אבל (וזה "אבל" גדול) – יש כאן גם טוויסט…

חברת ששמעו, התעניינו או הקימו PoC (או אולי עברו) לפתרונות HC (כלומר Hyperconverge) ראו שפתאום הם לא חייבים לרכוש את הסטורג'ים היקרים (מאוד) או סוויצ'ים סופר יקרים שעושים המון דברים. פתרונות Hyperconverge כמו ה-VSAN של VMWare, או Nutanix או SimpliVity או OpenStack (או RHV של רד-האט) נותנים גם ביצועים יפה וגם שרידות מרשימה – והכל רץ על שרתים סטנדרטיים כשהכל בעצם רץ כ-(Software defined (storage/network. ולפי 2 הדוחות, חברות מגלות יותר ויותר עניין בפתרונות כאלו מאשר הפתרונות הקאלסיים של ברזלים קניינים ויעודיים.

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

כמה מילים על לימוד-מכונה ועל GPU ועננים

עדכונים לפוסט – בסופו.

בשנים האחרונות, תחום ה"לימוד מכונה"/"לימוד עמוק"/"AI" ושלל שמות נוספים (ותוסיפו לכך טונות של Hype) קיבלו תאוצה מאוד חזקה. כיום התחום "חם" מאוד ואלו שמכירים את התחום נחטפים, וחברות כמו אמזון וגוגל מציעות משכורות מאוד מפתות (כמה מפתות? 50K ומעלה לחודש, בשקלים כמובן, ויש גם מענק חתימת-חוזה, תלוי כמה אתה מכיר, וכמה אתה מנוסה). סטארט אפים לנושאים אלו צצים כמו פטריות לאחר הגשם וכמובן שחברות הענן הציבורי הזדרזו להוציא שרותים שמציעים תחומים אלו בקלות מופלאה – תכניס את ה-DATA, הנה API קל לשימוש ובהצלחה.

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

מכיוון שהתחומים הללו מכסים תחומים כמו אודיו, וידאו, צ'אט בוטים ודברים רבים נוספים, לא ניכנס לדברים במובנים הטכניים לעומק אלא נדבר על הדברים בכלליות. באופן עקרוני, לא חשוב איזה AI או Deep Learning או Machine Learning מדובר, הכללים די ידועים:

  • אתה בונה את התוכנה (או משתמש בשילוב של Tensorflow, Caffe2 ושאר ספריות) ו"מסביר" לתוכנה מה אתה בעצם רוצה לעשות.
  • אתה מכניס את הנתונים שאתה רוצה לעבד.
  • אתה מכוון שוב ושוב ושוב ו"מאמן" את האלגוריתמים שהתוכנה תכיר את הנתונים ותתן תוצאות שאתה רוצה שתתן – עד לתוצאות שאתה רוצה.

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

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

זה – במבט על מגבוה בערך מה שקורה.

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

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

חברות גדולות שעוסקות בתחומים הללו כבר למדו שבכל מה שקשור לאימון, עדיף לעשות זאת In house ולא לסמוך על עננים, ומכיוון שהן חברות גדולות, הן יכולות להרשות לעצמן לרכוש מכונה כמו ה-DGX-1 של nVidia. כמה עולה המכונה הזו? 130,000 דולר, סכום שאין להרבה סטראטאפים או חברות קטנות או בינוניות. בשרת זה ישנם 8 כרטיסי Tesla מבוססי Volta (הארכיטקטורה החדשה של nVidia) שכוללים ליבות יעודיות ל-Tensor והרבה ליבות שמיועדות ל-CUDA. בנוסף, הכרטיסים מחוברים ביניהם עם NVLink שנותן מהירות מדהימה של 200 ג'יגהבייט לשניה פר כרטיס. בקיצור – מפלצת יעודית ל-AI/DL/ML. (אפשר ללחוץ על התמונה על מנת לקבל את הפרטים).

לאחרונה חברת nVidia הבינה שאותם חברות קטנות ובינוניות מעוניינות גם בפתרון. הם לא מחפשים לקנות DGX-1 והם מעדיפות פתרון יותר זול אך חזק. כרטיסים גרפיים כמו GTX 1080TI או אפילו Titan Xp הם טובים, אך המהירות עדיין אינה מספיקה.

לכן nVidia הוציאה בימים האחרונים את הכרטיס מימין. תכירו – זה ה-Titan V, ה"אח הקטן" של Tesla V100. מדובר על כרטיס עם אותו GPU כמו אחיו הגדול, אך יש לו 12 ג'יגהבייט זכרון (ב-Tesla יש 16), אין אפשרות לשרשר אותו עם Titan V אחרים (ואין SLI) ויש עוד מס' הבדלים – טבלת השוואה ניתן לראות כאן. אגב, אם אתם רוכשים כרטיס כזה, שדרגו ל-CUDA 9.1 שידע לתמוך בכל הפונקציות של הכרטיס.

מחיר הכרטיס (לא כולל מסים ומכס) – 3000$. יקר בהרבה מכל כרטיס אחר שמיועד ללקוחות פרטיים, אבל עדיין זול בהרבה בהשוואה ל-Tesla V100 (שאותו בין כה לא תוכלו להכניס לרוב השרתים). עם כרטיס כזה, אני יכול להבטיח לכם שהביצועים שלו יהיו גבוהים בהרבה מכל Instance עם GPU שתרימו בענן. (ניתן כמובן להרים מס' מכונות VM בשרתים מקומיים ולכל מכונה להצמיד GPU כזה בשיטת GPU Passthrough, כדאי לשאול את יצרן השרת לגבי התמיכה ב-Passthrough ולגבי IOMMU).

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

השלב השני לעומת זאת, עדיף לבצע אותו בענן, מכיוון שהתהליך ה-Evaluation של המידע שנכנס מהלקוח הוא הרבה יותר קצר ולכן גם חלק מ-GPU יכול להספיק לכך, מה עוד שבענן הרבה יותר קל לעשות Scale Out ולשרת בכך יותר ויותר לקוחות.

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

עדכון 17/12/17: קיבלתי פניה לגבי מידע שגוי שאני מפרסם בפוסט זה ולכן אני רואה צורך להבהיר: אינני אומר ששום ענן ציבורי לא נותן תשתית מואצת GPU (במקרה של אמזון ומיקרוסופט – Tesla ובמקרה של גוגל – TPU). כולם נותנים שרות SAAS כזה או אחר ל-ML/DL מואצים, אבל זהו שרות SAAS. למי שמחפש פתרון VM או קונטיינרים נטו שבהם הוא יכול להשתמש בפשטות ב-tensorflow-gpu עם PIP ועם הקוד שלו – זה כרגע למיטב ידיעתי והבנתי – לא קיים.

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

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

קוד פתוח מול קוד סגור ו"נעילת" לקוחות

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

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

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

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

הנה דוגמא: לא מעט חברות שנכנסות יותר ויותר בשימוש עננים ציבוריים "מגלים" כשהם משתמשים בלינוקס ומערכות CI/CD את האוטומציה, ותתפלאו – חברות רבות לדוגמא עד היום לא הכניסו שום אוטומציה. יש פלטפורמות אוטומציה רבות ללינוקס כמו Chef, Puppet, SALT ובוודאי עוד כמה – אולם אני ממליץ ספציפית על Ansible מכמה סיבות:

  • הקוד של "המנוע" – פתוח לחלוטין וכתוב ב-Python.
  • אין צורך ב-"שרת" Ansible. כל הפעילות היא Serverless לחלוטין.
  • הכתיבה של ה"תסריטים" (או Playbooks איך שזה נקרא ב-Ansible) היא פשוטה ולוגית. המשתמש יכול תוך שעה שעתיים אחרי שהוא קרא את התיעוד לכתוב דברים בסיסיים שיכולים לרוץ על המכונה שלו ומכונות אחרות, כך שעקומת הלימוד – היא די קטנה.
  • יש לכם שרתי Windows? אולי הגיע הזמן גם ששם תהיה אוטומציה? אז ל-Ansible יש גם מודולים ל-Windows, בין אם מדובר להתקין קבצי MSI, להגדיר IIS, להעתיק קבצים, פעולות דוט NET, ניהול משתמשים וקבוצות ודברים נוספים. העלות לחברה? יקרה מאוד .. אפס שקלים.
  • מחפשים ממשק Web? אתם יכולים לרכוש את Ansible Tower (וביחד עם זאת לקבל תמיכה רשמית מ-רד-האט) או שאתם יכולים להשתמש בממשק וובי אחר (ויותר בסיסי) בקוד פתוח שנקרא Ansible Semaphore.
  • חושבים לעבור לאוטומציה אחרת מסיבה כלשהי? לרוב המתחרים יש כלים אוטומטיים להעביר את ה-Playbooks שכתבתם אל המערכת החדשה (אם כי עדיין לא נתקלתי בחברה שעברה מ-Ansible למערכת אחרת).

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

אותו הדבר גם בכלים לניהול סביבת חיים (Life Cycle) של קונטיינרים וסביבות המורכבות מעננים פרטיים וציבוריים. ניקח לדוגמא את קטגוריית ה-CMP (כלומר Cloud Management Platform). בתחום זה יש מתחרים רבים, החל מ-VMWare עם ה-vRealize לגרסאותיו, RightScale, ועוד. האם פלטפורמות אלו מבצעות את מה שהן מבטיחות? בהחלט! אולם אם תפסיק לשלם את התשלום החודשי או השנתי, תיתקלו באחת מהסיטואציות הבאות:

  • במקרים כמו של RIghtScale – אתה "בן ערובה", כל עוד שתשלם – הכל עובד. הפסקת לשלם, תתחיל לבנות מחדש את כל מה שבנית – על מוצר אחר.
  • במקרים כמו vRealize אם אתה מפסיק לשלם, המערכת לא תתעדכן לשרותים והגדרות חדשות של עננים ציבוריים, OpenStack ואחרים, אין תמיכה ואין עדכונים לגרסאות חדשות.

לעומת זאת, במוצר כמו CloudForms שנותן לך לבצע CMP (כולל כמובן עמידה ברגולציות וכו'), אם לא בא לך לשלם יותר, אתה יכול לייצא ולייבא את ההגדרות, הקבצים והתכנים לגירסת הקוד הפתוח (ManageIQ) בדיוק כמו שאתה יכול לעבור מ-RHEL ל-CentOS מבלי לאבד פונקציונאליות או תאימות. כשזה מגיע לקונטיינרים, אתה יכול לעבור מגירסת OpenShift מסחרית ל-OpenShift Origin שמבוססת על Kubernetes כך שבעצם למעט שרותי תמיכה (שאותם תוכל לקבל מצד ג' בין כה), אינך מפסיד דבר. להיפך: אתה שומר על כל העבודה שהצוות ביצע ואפשר לאחר המרה לגירסת קוד פתוח – להמשיך לעבוד כרגיל.

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

שבוע טוב 🙂

המעבר לעננים

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

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

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

לא להעביר כל דבר ל"מחשוב ענן"

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

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

מבחינת רשיון, מיקרוסופט אוסרת על ספקים להציע ללקוחות שרותים כמו Windows 7 ב-Remote, והאיסור נכלל ברשיון ה-SPLA ורשיונות אחרים, מה שמשאיר את אפשרות של שרותי RDP (או Terminal Services) דרך Windows Server 2008.

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

אבל הבעיה המרכזית היא שיהיו בעיות רבות עם הסצינה הזו מהצד של הגולש: חברות ועסקים רבים בארץ שיש להם חיבור אינטרנט, לוקחים קוים סימטריים של 2-10 מגהביט, ועם זה הם גולשים ברשת, מוציאים/מקבלים דואר ועוד.

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

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

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

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

בחירת ספק VPS: אמזון מתאים לכולם?

אם יש ספק שרתים וירטואליים (VPS) שמגיע לו “שאפו”, זה אמזון (Amazon) עם שרותי ה-EC2. ב-2002 כשאמזון החלו להציע שרותים (עוד לפני שהם הציעו שרתי VPS) כמחשוב ענן, כולם הרימו גבה: מה לאמזון ולתחום הזה בכלל? אבל כיום אמזון מובילים בשוק מחשוב הענן והם אחד הספקים היחידים שאפשר לאמר עליהם שהם בהחלט מציעים מחשוב ענן אמיתי (בניגוד לכל מיני ספקים בארץ ובחו”ל שמציעים “מחשוב ענן” שהוא לא יותר מכמה הצעות לשרתי VPS ותו לא).

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

השרותים של אמזון מתאימים מאוד לחברות תוכנה שמציעות שרותים למשתמשים רבים מאוד ברשת, ושיש ברשותם מתכנתים שיכולים להשתמש ב-API של אמזון כדי להקים ולהרוג מכונות, להשתמש בשרות ה-Load Balancing, ב-S3 וב-Storage שלהם. באתר של אמזון ניתן למצוא מגוון מדריכים לשימוש בשפות שונות כדי להשתמש ב-API, יש קהילה ערה שדנה בכל נושא, וחברות רבות ומפורסמות (כמו Twitter ואחרות) משתמשות בשרותים אלו.

אך האם הפתרונות של אמזון מתאימים לכל אחד שמעוניין בשרת VPS? לאו דווקא.

אתן לכם דוגמא אישית פשוטה: לעבדכם הנאמן יש שרת VPS באמזון (חבילת ה-Micro) שמשמש אך ורק כשרת DNS משני (Slave) ו-rsync פשוט לשמירת ה-Zones. אין בשרת שום שרות אחר שרץ. אמזון מציעים את השרות חינם בשנה ראשונה וזו השנה השניה שאני משתמש בשרות הזה. נכון לחודש זה, החשבונית שקיבלתי מאמזון על שרת זה: 19 דולר וקצת עודף.

לי, כאדם פרטי לא משתלם יותר השרת באמזון. בעבר הייתי יכול לקחת הצעה כמו Linode 512 של Linode באותו מחיר שאמזון גובה לי (כיום לנו יש הצעות במחירים מאוד נמוכים בכל הנוגע לשרתים באירופה ובארה”ב). בנוסף, הייתי יכול להעביר יותר נתונים פנימה והחוצה, והדיסק הקשיח היה יותר גדול. לאמזון יש תשובה: שלם כך וכך עשרות דולרים לשנה מראש, והמחיר פר שעה ירד ב-40%.

אבל האם עדיין לי, כאדם פרטי עם שרת VPS בודד, שווה לקחת את ההצעה הזו?

לא תמיד.

הנה מספר סיטואציות שיכולות לקרות לכל אחד:

  • שינית הרשאות קבצים ותיקיות "ביד נדיבה" (בלינוקס לדוגמא עם פרמטר כוכבית או R-)
  • הכנסת Kernel חדש למערכת אולם ביצעת שינוי "מינורי" ב-GRUB והשינוי היה שגוי
  • מודול מסויים נופל ומפיל דברים אחרים, מה שלא מאפשר לך לבצע SSH.
  • (תקלה מוכרת שחוזרת במקרים רבים): ישנו שיבוש ברמת ה-File system והמערכת ממתינה שתכניס סיסמא
  • כל תקלה אחרת שמונעת מהמערכת לסיים את ה-Boot
  • שינוי הגדרות רשת וכתוצאה מכך הרשת אינה עולה ב-VPS
  • במקרה של Windows – תקלת STOP

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

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

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

מיתוס: מחשוב ענן בישראל

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

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

ההצהרה הזו קצת חזקה, לא? ובכן, ראשית נסביר מה זה בכלל מחשוב ענן.

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

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

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

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

Exit mobile version