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

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

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

אם נתייחס למצב בישראל, אז הדבר הכי אירוני שקורה פה בארץ, הוא עניין מחירי שרתי המותג (HP, Dell, Lenovo, Cisco, Fujitsu): המחירים כאן די "דוחפים" את הלקוחות לעבור לשרותי ענן עקב מחירם היקר (מאוד).

הבה נסתכל מהצד השני, אצל ספקי ענן, ולא חשוב אם מדובר בספק קטן יחסית (Linode, Digital Ocean) או על הגדולים (אמזון, גוגל, מיקרוסופט): אצל כל אותם ספקים יש התחמקות רצינית מכל ציוד מותג. אצל הגדולים לא תמצאו שום ציוד מותג של שרתים, לא תמצאו חומרה של Enterprise ממותג (למעט מעבדים), לא תמצאו מתגים של מותגים, אין שום NetApp או EMC שמשמש כ-Storage ל-VM, ועוד. אצל היותר קטנים יכול להיות שתמצאו שרתי מותג – אך הם נרכשים בתצורה הכי בסיסית וכל הציוד הפנימי הוא צד ג' – ללא גרסאות Enterprise. הגדולים בונים לעצמם את הכל ושרתים מיוחדים נרכשים משמות שאף אחד לא מכיר כמו Wywinn הסינית שמייצרת את הדגמים לפי שרטוטי לוחות שספקי הענן מעבירים). בקיצור: המטרה של כל אותם ספקי ענן היא להוציא כמה שפחות כספים על הציוד, ובגלל זה פרויקטים כמו OCP מאוד פופולריים אצל ספקי הענן וכולם משתתפים ותורמים שרטוטים, תכנונים וכו'.

במילים אחרות: כשחברה עוברת לענן, המכונות הוירטואליות לדוגמא שהם יקימו – יוקמו על ציודים שספק אם בחברות ירצו לרכוש אותם מקומית. זה שאתם עוברים לענן לא אומר שלא יהיו לכם מכונות VM תקועות ושאר תקלות. אתם פשוט תצטרכו לבצע Restart והתשתית ענן תקים את ה-VM במכונה אחרת, ומכיוון שתשתית ה-Storage שם שונה לחלוטין מכל NetApp או EMC שאתם מכירים, לא יהיה צורך בביצוע Migrate (ואגב, הדיסקים באותו פתרון Storage – המכניים הם SATA "ביתי" וה-SSD ברובם גם "ביתיים" למעט חלק קטן עבור Write Cache שהם OEM מיצרנים ידועים כמו Samsung).

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

אז איך אפשר לקבל מחיר נמוך, יחד עם עמידה בכל מה ש-Enterprise דורש?

התשובה פשוטה אך לא קלה לעיכול לאנשי מנמ"ר: להחליף את הדיסקט.

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

להלן מספר נקודות כלליות שיש לתת עליהן את הדעת:

  • וירטואליזציה – 2 הדברים החשובים כשמקימים ענן פרטי זה יציבות ומחיר נמוך (כשאני מדבר על מחיר נמוך, אני מדבר על מחיר תלת ספרתי בדולרים פר ברזל בגירסה המסחרית, או גירסת קוד פתוח עם חוזה תמיכה מבחוץ). מי שמעוניין ב-OpenStack, כדאי שיצור קשר עם SuSE ישראל (המחיר זול בעשרות אחוזים מהמחיר של Red Hat). מי שמעוניין בפתרון שהוא וירטואליזציה נטו, כדאי שיסתכל על RHV של Red Hat.
  • שרתים – אתם יכולים להשתמש בשרתים קיימים או לרכוש שרתים מתור קודם (ברוב המקרים, ההבדל בביצועים בין הדור הקודם לנוכחי לא כזה גדול). אני ממליץ גם להסתכל על השרתים של SuperMicro ושל חברת Tyan. ספציפית ל-SuperMicro יש מבחר הרבה יותר גדול של שרתים לצרכים שונים ופתרונות חדשניים שעדיין לא קיימים אצל HP או DELL לדוגמא, ובמחיר שהוא זול בהרבה בהשוואה לחמשת היצרנים שציינתי לעיל. אגב, הנה משהו מעניין שכתבה חברת Barrons על Supermicro. שרתים שאני לא ממליץ – הם דווקא של HP ובסעיף הבא אסביר מדוע.
  • דיסקים – עולם הדיסקים משתנה כל הזמן. דיסק SATA טיפוסי שבעבר היה נותן מהירות קריאה של 110-150 מגהבייט לשניה נותן כיום 250 מגהבייט לשניה ובקרוב יצאו דיסקים מכניים שנותנים מהירות שמגיעה ל-420 מגהבייט בשניה ובחיבור NVME (כן, SAS/SAS-HD מגיע לסוף דרכו). המבחר די גדול וכפי שהוכיחה חברת BackBlaze בדו"ח אחרי דו"ח (הם מנפיקים דו"ח פר רבעון והם קונים אלפי דיסקים) – דיסקים ל-Enterprise לא נותנים מאומה הן מבחינת ביצועים והן מבחינת שרידות. גם מבחינת מחיר, בממוצע אתה יכול לרכוש 3 דיסקים במחיר שקונים לדוגמא דיסק קשיח מ-HP, כך שאתה יכול להגדיר 2 דיסקים ב-RAID-1 ועוד דיסק כ-Hot Spare, ואתה מסודר לתקופה ארוכה – פר שרת. אני לא ממליץ על שרתי HP מבחינת דיסקים מכיוון ש-HP נועלים אותך על דיסקים שלהם בלבד (שעולים פי 3 בלי הצדקה, במיוחד כשרוכשים פתרון כולל SLA ואז עניין כל החלפת הדיסקים הוא על מי שנותן לכם שרות).
  • דיסקים SSD – עולם ה-SSD מתעדכן כמעט כל חצי שנה במהירות ויש המון יצרנים וסוגי SSD שונים. המצב מול SSD ל-Enterprise הגיע למצב כזה מגוחך כשראיתי אצל לקוח דיסק SSD שעלה המון והביצועים שאותו SSD נותן הם פחות ממחצית מדיסק SSD שיושב לי פה במחשב הדסקטופ שלי, ואני שילמתי רבע מחיר ממה שהוא שילם. לכן, חשוב לבחור יצרן שרתים שמאפשר הכנסה של כל דיסק צד ג' ובכך להנות מהתחרות בשוק.
  • מעבדים – המלצתי בעבר על EPYC ואני עדיין ממשיך להמליץ על מעבדים אלו מהסיבה הפשוטה שמקבלים יותר ביצועים וליבות ומשלמים פחות. החשבון פשוט.
  • תקשורת – זמן רב שהמחירים לא זזו בצורה רצינית בתחום התקשורת אולם כיום יש ירידה במחירים ולכן מומלץ לצייד כל מכונה בכרטיס עם זוג כניסות בחיבור +SFP כתקשורת עיקרית ומתגים עם חיבורים של 10 ג'יגה ו-Up/DownLink של 40 או 50 ג'יגה. אגב, יש בהחלט גם מתגים שתומכים ב-RJ45 וחיבור 10 ג'יגה על CAT6 (למרחקים קצרים) או DAC (גם למרחקים קצרים) או סיבים אופטיים (למרחקים יותר ארוכים).
  • סטורג' – אף אחד מספקי העננים, גדולים כקטנים, לא משתמש בסטורג'. כיום הבון טון הוא שימוש בדיסקים מקומיים עם פתרון Scale Out לסטורג' בין כל המכונות הפיזיות. הפתרונות הפופולריים כיום הם CEPH ו-GlusterFS.

פתרון מבוסס על הדברים שציינתי יתן לכם:

  • אפשרות קלה לשדרוג והוספת מכונות
  • פתרון ענן ל-3-5 שנים כולל תמיכה שוטפת
  • הרצת מכונות וירטואליות, קונטיינרים ועוד.

לסיכום: אפשר להקים תשתית שיכולה בחישוב ROI/TCO להיות יותר נמוכה ממחירים של ענן ציבורי – אם "משתחררים" מהראש של ציוד Enterprise ממותג מהיצרנים שציינתי בתחילת הפוסט. הציוד שתיארתי יכול לעמוד בדרישות פרודקשן חמורות והוא כבר עומד – אצל ספקי עננים קטנים לדוגמא (אגב, כשאני מדבר על "קטנים" אני מדבר על ספק עם מינימום 5 DC ואלפי שרתים פיזיים). כל עוד הדרישות שלכם מסתכמות במכונות וירטואליות וקונטיינרים – זה עובד. יש כמובן דברים שעננים מקומיים לא כל כך נותנים כמו כל עניין ה-Serverless או API ענק כמו של אמזון ל-1001 שרותים שונים, ואם רוצים להשתמש באותם API, אין מנוס מאשר לחתום מול ספק ענן ציבורי.

סטארטאפים ואבטחת מידע בענן

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

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

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

וכאן בדרך כלל מתחילות הבעיות הקשורות לאבטחת מידע.

לא מעט אנשים שמתחילים סטארטאפים חושבים להם שאם יקימו את התשתית שלהם בענן, ספק הענן יגן עליהם בצורות כלשהן וזו כמובן טעות ענקית. לא חשוב מי ספק הענן, כמות ההגנה המסופקת ללקוח היא ברמה אפסית (אינני מדבר על הגנות בתוספת תשלום כמו נגד DDoS). אתה יכול להפעיל Multi Factor Authentication כדי למנוע כניסת אנשים לא מורשים לחשבון בענן, אבל זה לא אומר כלום לגבי ה-Instances שאתה משתמש. מהרגע שיש לך Instance חי ויש לו כתובת IP ציבורית, עשרות אלפי סקריפטים ינסו לחדור לשרת שלך בכל דרך. כל שרות שתפעיל באותו Instance ושאינו סגור לכתובת הציבורית (כמו שרבים נוטים להשאיר פורטים פתוחים לשרותי SQL/NOSQL, GUI, או SSH עם סיסמא (ללא מפתחות) – הסקריפטים ינסו להיכנס, ואם הם יצליחו, חלקם יעבירו את המידע חזרה מבלי לנגוע במידע בשרת וחלק אחר של סקריפטים פשוט "יגייסו" את המכונה להריץ BOT או תולעים או 1001 דברים מזיקים אחרים ויש כמובן גם סקריפטים שישמחו פשוט למחוק את המכונה.

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

לכן ההמלצה הראשונה שלי לכל סטארט אפ שכולל מס' קטן של מפתחים זה לקחת מישהו חיצוני שיעשה את עבודות הסיסטם ואבטחת מידע ברמה מספקת של הגנה כלשהי על התשתית. הגנה ברמה גבוהה מצריכה הרבה עבודה בכל מיני אספקטים כמו API, שרתי Web שנותנים את השרות, TLS ודברים רבים אחרים וכאן זה תלוי אם איש ה-Devops שלכם יודע לעשות זאת או שילוב של מישהו חיצוני שיעבוד יחד עם איש ה-Devops שלכם.

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

  • אם מדובר במספר עובדים בסטארטאפ אחד שיושבים במשרד כלשהו, דאגו ל-VPN וחברו את ה-VPN כ-Site To Site לחשבון הענן שלכם. מי שרוצה להתחבר מהבית, יתכבד הבחור ויתחבר ל-VPN שלכם ומשם לתשתית.
  • עבודה עם סיסמאות לכניסה לשרתי לינוקס היא no no. השתמשו במפתחות בלבד והחליפו את קבצי ה-PEM שניתנו לכם ע"י שרות הענן שלכם במפתחות שלכם בחלוקה של פרטי/ציבורי (עדיף ליצור עבור כל מפתח מפתח, להכניס את החלק הציבורי לשרת ואת החלק הפרטי למכונה של המפתח כך שאפשר לדעת מי נכנס עם איזה מפתח), כך שמי שצריך להיכנס למכונה יהיה לו את החלק הפרטי של המפתח (החלק הציבורי נמצא בשרת). קבצי ה-PEM למיניהם קל "לדוג" אותם מכל מיני פורומים, אימיילים ושאר מקומות.
  • מקימים DB? ראשית יש להקשיח את ה-DB לפני שמכניסים אליו נתונים. אם זה mysql לדוגמא, יש להריץ קודם כל mysql_secure_install, ואם זה mongoDB יש למחוק משתמש דוגמא,  ובכל המקרים יש לוודא כניסה רק דרך IP מסוים פנימי.
  • משתמשים בשרותים שונים של ספק הענן? ודאו שאתם משתמשים בכתובות IP פנימיות בלבד. זה לא מצליח? יש לכם בעיה עם ה-VPC (במקרה של אמזון), כדאי לבדוק הגדרות.
  • שימוש ב-DB – לפני שכותבים נתונים ל-DB, כדאי "להמליח" דברים כמו סיסמאות ומידע חשוב (להלן לינק לוידאו המסביר איך לעשות זאת ב-MySQL לדוגמא), כך שמי שיצליח לגנוב את ה-DB, לא יוכל לעשות הרבה עם זה. אפשר כמובן לשפר את זה ולהשתמש בכל מיני שרותי Vault לשמור את המפתח להמלחה אך זה כבר עניין אחר.
  • גיבויים ל-S3 או כל מקום ששומר Object Storage – לאחר יצירת הגיבוי, יש להצפין אותו ורק אז להעלות אותו (כמובן שכדאי לוודא שהרשאות ה-S3 שלכם מוגדרות בצמצום).
  • לא לקחת כתובות IP ציבוריות עבור כל Instance (טריק שלצערי ראיתי פעמים רבות שנעשה בחברות שונות). אם אין אפשרות להקים ולהשתמש ב-VPN ויש צורך להתחבר ממקומות שונים עם IP שונה, מומלץ להשתמש בטריק שנקרא Linux Bastion, זו מכונת לינוקס קטנה שבה נשתמש כ"מקפצה" (להלן לינק למאמר שמסביר זאת) ולמכונה זו יש להגדיר Security Groups עם הכתובות שיכנסו אליה (חשוב: לא להוסיף כל פעם כתובות אלא לעדכן ב-SG).
  • תעודות SSL – אם המכונה פונה החוצה ואין לכם עדיין תעודות SSL מסודרות, אפשר להשתמש ב-Let's Encrypt כדי ליצור תעודות SSL תקינות זמניות (שניתנות להארכה בפקודה פשוטה) במקום להשתמש ב-Self Signed Certificates. באותה הזדמנות כדאי לבטל Ciphers ישנים ולאפשר אך ורק ל-TLS מהגירסא האחרונה להיכנס.

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

על עסקים קטנים ומעבר לעננים. כדאי?

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

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

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

אתן דוגמא: אתם קוראים את הבלוג הזה, שהוא חלק ממספר בלוגים שעבדכם הנאמן כותב. כל הבלוגים רוצים בשרת וירטואלי עצמאי שהיה נמצא בחברת Digital Ocean ועתה הוא נמצא באמזון תחת Amazon Lightsail. האתר עצמו, וה-Database שלו ושרת ה-Web – כולם מותקנים על שרת וירטואלי יחיד שעולה לי בחודש 40$. זה מה שאני משלם בכל חודש, בין אם נכנסו 3 גולשים או 2000 גולשים ביום, מכיוון שכמות ה-DATA היוצאת מהשרת אינה עוברת את כמות ה-DATA המוקצית עבורי בחבילה. יש חבילות כמובן יקרות יותר ויש זולות יותר, בהתאם לצרכי הלקוח והחברות המציעות שרותים אלו ושאני יכול להמליץ עליהן (כולל Amazon Lightsail שהזכרתי לעיל) הן Digital Ocean ו-Linode ויש כמובן חברות נוספות בהתאם להמלצות שאתם יכולים לקבל מאחרים אולם אלו ההצעות הפופולריות ורציניות.

כמובן שגם ספקי הענן הציבורי מציעים מוצרים כמו קונטיינרים, מכונות וירטואליות וכו', אולם שם התעריפים שונים מההצעות לעיל. לדוגמא: אם באמזון ניקח מכונה ב-EC2 (לא בחבילת ה-Lightsail) כמו המכונה שיש לי, המחיר יהיה $43.63 עד לתעבורה של 100 ג'יגהבייט, אולם אם מחר אפרסם פוסט שיהפך לויראלי, אני אגיע בקלות גם לתשלום של 50-100$ לחודש. אם נבנה ב-Google Cloud את אותו מפרט של מכונה (מכונה מבוססת לינוקס, 2 ליבות, 4 ג'יגהביייט זכרון, 40 ג'יגה דיסק SSD ו-100 ג'יגהבייט תעבורה החוצה) נגיע ל-$61.22. ב-Azure אותה חבילה תעלה לנו $48.42. כך יוצא שהלקוח משלם יותר על פחות. (אגב, ב-Azure תצטרכו לשלם יותר כי הדיסק מוגדר "זמני", ודיסק מבוסס רשת עולה יותר). הערה: המחירים יכולים להיות אצל חלק מהספקים זולים יותר – אם אתם משלמים מראש שנה או שנתיים.

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

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

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

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

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