כמה מילים על ענני צעצוע

כשפתחתי את "חץ ביז" לפני מס' שנים, התחום הראשון שנכנסתי אליו היה עסקי ה-Hosting עם טוויסט מסוים: יש לי נסיון עשיר באופטימיזציה, כך שהלקוחות מקבלים מכונות VM מהירות על שרתים שלא יהיו עמוסים. התחרות באותן שנים היתה רצינית מאוד, וספקי הענן הציבורי הציעו תצורות יקרות, ולא ממש קלות לשימוש ולהגדרה על ידי משתמש ממוצע שאין לו מושג ירוק מה זה AWS. אחרי כשנתיים, כשראיתי שההכנסות מהתחום לא ממש מכסות את ההוצאות (במיוחד לאחר שמחיר התשתית ששכרתי עלה ביום אחד ב-100%) – העברתי את הפעילות העסקית הזו לקבוצת OMC.

חלפו מספר שנים מאז אותה תקופה, והתחרות נהייתה הרבה יותר רצינית – מחו"ל. חברות כמו Linode, Digital Ocean ואחרות הציעו חבילות במחיר מפתה ולשוק הזה נכנסה בשנים האחרונות אמזון עם חבילות Lightsail שהוצעו במחירים המתחרים באותם ספקי Hosting. כאן בישראל לעומת זאת, נסגרו מספר ספקי Hosting ונכנסו ספקים גדולים – רוב ספקי התקשורת וה-Hosting הגדולים בארץ – שהחלו להציע "ענן" ללקוחות פרטיים ועסקים. במקביל, בשנתיים האחרונות ספקי CDN החלו "לגלות" את ישראל והם הקימו כאן נקודות Edge כך שלקוחות ישראלים יוכלו להנות ממהירות גלישה מקומית (לאתרים שמשתמשים באותן רשתות CDN).

בעסקים כמו בעסקים, אף חברה לא תציע שרותי ענן אם אין לה הכנסות כמו שהיא מצפה או שפתרון ענן לא נותן לה את מה שהיא מצפה (לדוגמא: "ענן" כ-Loss leader כשהכסף הרציני מגיע מהשכרת שרותים שהחברה מספקת לאותם לקוחות ענן). איך חברות עננים מקומיות מרוויחות מהשכרת מכונות VM? פשוט: חוסר ידע של לקוחות. מישהו מקצועי שמבין טוב בלינוקס לדוגמא שיודע להריץ מספר אפליקציות Benchmark, היה מסתכל על המספרים ומיד מבטל את העיסקה תוך שעה-שעתיים, אך מכיוון ש-99% מאותם לקוחות לא מבינים איך אפילו להריץ Benchmark, הם שוכרים תוך מחשבה שהם מקבלים יתרונות של ענן כמו משאבים חזקים, שרידות, גדילה וכו'.

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

  • שרידות – אם VM נופל ומריצים אותו מחדש, הוא ירוץ על מכונה אחרת. אצל ספק צעצוע: זה ירוץ מחדש על אותו שרת, כך שאם יש תקלה בשרת, יהיה מצב שמכונת ה-VM תיפול שוב ושוב.
  • אחסון – אצל ספק ענן ציבורי, ה"דיסק" של המכונה הוירטואלית יושב במערך ענק של דיסקים עם שרידות הרבה יותר גבוהה מ-Five Nines. אצל ספק ענן צעצוע? או שזה ישב בדיסקים מקומיים בשרת או על סטורג' כלשהו, והביצועים ירדו ככל שיש יותר ויותר מכונות VM.
  • HA – ברוב מוחלט של המקרים אין את זה לספקי ענני צעצוע. אצל ספק ענן ציבורי ניתן להגדיר זאת די בקלות, הנה דוגמא ב-AWS.
  • גדילה דינמית – קיים אצל ספק ענן ציבורי, לא קיים אצל ספק ענן צעצוע.
  • אחסון אובייקטים – כנ"ל.

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

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

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

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

קצת על CDN וישראל

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

הדוגמא הכי פשוטה שאני יכול לתת היא בלוג זה שאתם גולשים בו כרגע. הוא מתארח ב-AWS בוירג'יניה, אך הוא נעזר בשרותי CDN של Cloudflare וכ-600-1500 איש גולשים בו ביום, הם מקבלים את הדפים במהירות, והעלות הכוללת היא מזערית (20$ + מע"מ לחודש). בלי שרותי CDN, המכונה הקטנה הזו (2 ליבות, 4 ג'יגה זכרון) לא היתה מחזיקה מעמד עם אותה כמות של גולשים ובלוגים שאני כותב.

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

  • שרתים וירטואליים (או פיזיים) שמפוזרים ביבשות ובמדינות מפתח שונות הכוללים שרתי Web, שרתי אפליקציה, שרת (או שרותי) בסיסי נתונים, שרות DNS ועוד ועוד. לחלופין במקום שרתים, אפשר להשתמש (ומומלץ) בקונטיינרים עם שרותי קונטיינריזציה שספקי ענן ציבורי מציעים (או להקים משלכם, אם כי בעננים ציבוריים זה קצת פחות מומלץ והרבה יותר מסובך).
  • תשתית שמאפשרת לבצע Scaling דינמי
  • תשתית אחסון
  • תשתית ניטור
  • הגנה – חומת אש, WAF…
  • CDN
  • ועוד ועוד..

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

ישנם לא מעט חברות המציעות שרותי CDN. כל ספקי הענן הציבורי מציעים זאת, וכמובן חברות כמו Cloudflare, Akamai, Brightcove, Incapsula ועוד ועוד. ספציפית לגבי ישראל, לכל ספקי ה-CDN היעודיים יש בארץ נקודות שמזרימות תכנים אל גולשים ישראליים ומבחינת ספקי ענן – כרגע רק אמזון מציעה נקודה כזו (שנקראת POP) בישראל.

אחרי שאנחנו מבינים את הצורך ב-CDN, נשאלת השאלה – איזה CDN כדאי להשתמש?

שרותים כמו Incapsula ו-Cloudflare מציעים פתרון שמאוד מזכיר דבר כמו Reverse Proxy. אתה צריך להעביר את ניהול ה-DNS שלך לספק כזה ומאותו רגע, כל התעבורה אל ומהאתר שלך עוברת דרך אותו ספק ענן (אפשר כמובן להחריג בכך שבוחרים רשומות A records מסויימים שלא יעברו דרך הענן). בשיטה זו יש יתרון גדול בכך שאותו ספק CDN יכול לאפשר לך דברים כמו:

  • חסימת כתובות IP מסויימים או חסימת גלישה ממדינות שונות
  • שרותי הגנה נגד התקפות שונות
  • SSL חינמי
  • שרות DNS מאובטח
  • אופטימיזציה של התכנים מבחינת תעבורה
  • טעינה זריזה של דפים
  • שמירת Cache מקומית
  • ועוד

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

ה-CDN של ספקי הענן הציבורי – שונה והוא יותר ה-CDN ה"קלאסי" המוכר. אתה ממשיך להשתמש בשרותי ה-DNS שלך (או בשרותי ה-DNS של ספק הענן, גם אם זה ספק ענן אחר ממה שאתם משתמשים לארח את התשתית האחרת שלכם) ואתה צריך לפתוח A record נוסף שישמש לשרותי ה-CDN וכמו כן עליך לבצע שינויים באתרים שלך על מנת שתוכלו להשתמש בשרותי ה-CDN (במקרה של אמזון יש ספר שנגיש דרך אפליקציית Kindle במחיר של 0$ כאן איך להשתמש בשרותי ה-CDN שלהם).

יש מספר יתרונות של ה-CDN של ספקי ענן כמו אמזון מול שרותי CDN כמו Cloudflare:

  • אין צורך בשרתים ובאחסון להנגיש תכנים סטטיים. פשוט מאחסנים אותם ב-Object Storage כמו S3 ומגדירים את ה-CDN להנגיש אותם לפי הצורך.
  • ניתן להנגיש דרך ה-CDN תכנים מוגנים כמו וידאו, מוסיקה, וקבצים מיוחדים שמיועדים ללקוחות משלמים בין כהורדה ובין כהזרמה (Stream).
  • ניתן לקבל Raw Access Log (ב-Cloudflare זה בתשלום, ב-Cloudfront זה ללא תשלום נוסף) שניתן להכניס למערכת עיבוד לוגים (Elastic Stack וכו')
  • ניתן להשתמש ב-Wildcard SSL
  • ניתן "לדחוף" תכנים

(מצאתי כאן טבלה שמשווה בין Cloudflare ו-Cloudfront אך היא אינה מעודכנת לגמרי).

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

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

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

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

פרויקט נימבוס – מחשוב הענן הממשלתי

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

anan

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

  1. אחד הדברים הבולטים לטובה במסמך הוא התייחסות למחשוב ענן כמו שספקי הענן הציבורי מציגים ומוכרים ולא כל מיני "ענני צעצוע" שכל מיני חברות בארץ מציעות/מוכרות. התנאים עצמם ישר פוסלים את אותם "ענני צעצוע" בכך שיש דרישות שלספקים בארץ אין אותם, הן מבחינת הכנסות והן מבחינת Availability Zones (שמשום מה במסמך הם נקראים "Domains"), מיקומים גיאוגרפים וכו' ואף אחד מהספקים בארץ גם לא מציע 500+ שרותים שונים באותו ענן.
  2. אני שמח לראות שבמשרד האוצר מחפשים שהזוכה יקים בעצם Region אחד ובתוכו Availability Zones אולם לעניות דעתי, חשוב שבמשרד יתעקשו על כך שה-AZ יהיו במרחק רב אחד מהשני.
  3. נקודה שלדעתי חסרה במסמך וחשוב שתצוין (ושהמשרד יעמוד על כך) – שה-AZ יהיה מחובר בחיבורי תקשורת מספקי אינטרנט שונים ולא מספק יחיד. רק לפני חודשים ספורים אלפי אתרים נותקו מהאינטרנט עקב "תקלת תקשורת" של ספק אינטרנט מרכזי. האם משרד האוצר רוצה לחוות חוויה כזו?
  4. אם המתמודדים הם בעצם ספקי הענן הציבורי, מומלץ לבקש לדעתי במסמכי המכרז כי הספק הזוכה ייבא וישתמש בציוד שלהם ולא בציוד COTS. הציוד של ספקי הענן שונה לחלוטין מציוד שחברות רוכשות החל ברמת המעבדים, זכרונות, לוחות, אחסון, תשתיות תקשורת וכו' ויש סיבה טובה לכך – ביצועים הרבה יותר גבוהים.
  5. בבקשה, בבקשה – בלי Azure Stack. כתבתי כאן מדוע לא.
  6. נקודה נוספת שאולי כדאי שמשרד האוצר יחשוב לגביה – שה-AZ יהיו מחוץ ל-Data Centers של ספקי האינטרנט שונים במיקומים כמו הגליל ובאר שבע לדוגמא. בחירה במקומות כאלו יכולה לייצר באופן ישיר מספר מקומות עבודה ובאופן עקיף לאורך זמן – יותר ויותר חברות שיעבדו במקומות אלו.

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

  • מיקרוסופט – Azure
  • אמזון – AWS
  • גוגל – GCP
  • אורקל – Oracle Cloud
  • IBM Cloud

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

יש משהו אחד שקצת לא מסתדר לי עם המכרז והפרויקט עצמו. כן, זה בהחלט דבר טוב שמשרד האוצר עושה צעדים להקים פה Region, אבל הבעיה הגדולה ביותר קשורה לשיטות העבודה והפיתוח במשרדי הממשלה השונים ושוחחתי בעבר עם לא מעט עובדים במשרדים הממשלתיים על כך: צריך לשנות מקצה לקצה את כל מתודות העבודה. להתחיל לעבוד מול GIT, לשלב CI/CD, אוטומציה, להוריד כמה שיותר את העבודה עם מכונות וירטואליות ולהתחיל לעבוד מול קונטיינרים ומול שרות/פלטפורמה כמו Kubernetes/OpenShift, לעבוד במתודה של Scale Out, להשתמש ב-Object Storage, להתחיל לעבוד במתודות Serverless אולי, ועוד ועוד – וכל אלו הם דברים שונים ממה שהמשרדים משתמשים כיום. אם משרד האוצר הולך לשלם על Region עם מספר AZ ושיטות העבודה ישארו השיטות הישנות, אז ניצול ה-Region יהיה אחוזים בודדים בלבד, ובכך יווצר בזבוז כספים משווע (ומה לעשות, לא מדובר פה בתשלום חד פעמי אלא חודשי), ולכן אני תוהה אם משרד האוצר מוכן כבר עכשיו לתכנן מהלך הדרגתי לעבור למתודות העבודה החדשות.

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

מיקרוסופט SQL ללינוקס – ההמשך

לפני כשנה כתבתי את הפוסט הזה לגבי Microsoft SQL 2017 גירסת לינוקס שמיקרוסופט הוציאה. מיקרוסופט הסבה את המוצר ללינוקס מכמה סיבות:

  • לכבוש נתח שוק מאורקל
  • לנסות לחדור לכל מיני שווקים שמשתמשים רק בלינוקס

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

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

מיקרוסופט הוכיחה לאחרונה שאין צורך לחשוש. הם בהחלט ממשיכים עם גירסת לינוקס ל-SQL עם Microsoft SQL 2019.

בגירסה החדשה ללינוקס, מיקרוסופט הוסיפה חלקים שלא היו קיימים ב-SQL 2017 ולראשונה יש תמיכה לא רק להרצה בתוך Docker אלא בתוך Kubernetes (אפשר לראות מה חדש כאן) וסוף סוף יש גם רפליקציה טבעית, תמיכה ל-PV/PVC (כלומר Persistent Volumes). הדוגמאות שמיקרוסופט נותנת בתיעוד קשורות אמנם ל-Azure אבל אני מאמין שזה ירוץ גם על Kubernetes מקומי ובשרותים של ספקי ענן ציבוריים מתחרים.

הבעיה היחידה שאני רואה קשורה יותר לתמחור. SQL בסביבה רגילה במצב שרידותי עובד ב-2 שרתים, הן Active/Passive או Active/Active וזה עובד יפה, אך ב-Kubernetes הדברים שונים לחלוטין, אין Active/Passive ודברים כאלו, יש רפליקציות של Pods וקונטיינרים לפי הגדרות שמחליטים, לדוגמא: אם משאבי זכרון/מעבד מגיעים ל-90% – תרים Pod נוסף עם הקונטיינרים הרלוונטיים, בצע Load Balance (תלוי בשכבת הרשת שהוגדרה ל-Kubernetes) בין ה-Pods שמריצים את ה-SQL. מה המחיר שמיקרוסופט תגבה על כל SQL כזה? אי אפשר לגבות מחיר בשיטה הישנה של Cluster.

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

כמה מילים בעניין חוק המחשבים

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

קצת רקע לגביי: אינני מבצע בדיקות באתרים חיצוניים כביזנס וברוב המקרים הדיווחים שלי ל-SoC של בנקים מגיעים לאחר שאני או חבריי מקבלים הודעת Phishing, אני מבקש להעביר את ההודעה אליי, אני מנתח את האתר, כתובות IP, ספק ועוד דברים – ומעביר במייל ממני אל ה-SoC את כל הפרטים ללא בקשת תמורה כלשהי. השרות המסחרי שהעסק שלי מציע לחברות בכל הקשור לאבטחת מידע קשור להקשחת שרתים, כחלק משרותים אחרים שהעסק שלי מציע.

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

כשזה מגיע לאבטחת מידע, רוב החברות שבטוחות שהן מוגנות ב-95%+ הן טועות, מכיוון שברוב החברות רוכשים כל מיני פתרון כמו חומות אש, WAF, IPS/IDS וכו' ולפיכך הן סוברות שהן מוגנות. ההגנה שהציודים הללו נותנים היא חלקית בלבד. פורץ מתוחכם לא יחפש איך לתחמן את חומת האש או ה-WAF שלך, אלא יכנס לקוד שהדפדפן מוריד למחשב המקומי ולפרמטרים בשורת ה-URL. בחלקים הללו הוא ינסה למצוא את הכשלים והחורים. אחד הטיעונים המגוחכים ששמעתי ש"אין למשתמש שמריץ את ה-web service אפשרות shell". מדוע מגוכך? כי אפשר ליצור shell בכל שפה דרך הדפדפן. להלן דוגמא של shell ב-PHP שכל מה שהפורץ צריך לעשות זה למצוא מקום שההרשאות יותר מדי פתוחות כדי להעלות את הקובץ ומשם לחגוג (אם בשרת יש תמיכת PHP).

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

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

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

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

בשביל לדווח על פריצה, יש צורך ב-3 דברים:

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

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

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

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

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

  • הבודק (ראובן) לא ניסה לשבש את פעילות השרתים בהתקפות כמו DDoS, Brute Force ואחרים
  • לראובן לא היתה כוונה מסחרית להרוויח מהפריצה.
  • ראובן שלח את כל הפרטים כולל פרטיו אל בעל האתר ומוכן לשתף פעולה עם בעל האתר על מנת לסגור את הפירצה.
  • ראובן לא ביקש ביקש ולא ניסה לסחוט את החברה (מסירת פרטי פריצה תמורת סכום כסף)

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

אשמח לשמוע את דעתכם.

כמה מילים על Azure Stack וספקי אינטרנט

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

בישראל החלה חברת Med One להציע שרותים המבוססים על Azure Stack ואני מאמין שהמתחרים בארץ כבר במחשבות או בדרך לרכוש ולהציע את השרותים הללו. חשוב לי להדגיש – הפוסט הזה אינו בא "לקטול" ספק ISP זה או אחר אלא לתת דגש לגבי פתרון Azure Stack (אם יש איזו חברה בארץ שהולכת להכניס את ה-Outposts של אמזון – אשמח אם היא תוכל ליצור עימי קשר).

קצת על Azure Stack: מיקרוסופט פיתחה מערכת שהיא "מיני Azure". מיני בכל מובן: מעט מהשרותים שתמצא בענן של Azure תמצא אותם כאן, התמחור שונה בהשוואה להשכרה  קלאסית של מכונות VM/קונטיינרים/אחסון בלוק/אחסון אובייקטים וכמובן – תעבורה. על כל פיפס אתה צריך לשלם – כמו בענן של Azure, גם ב-Azure Stack (כן, גם אם רכשתם בעצמכם את ה-Azure Stack לחברה שלכם, אגב).

מערכת Azure Stack בנויה לשימוש ב-2 אופנים: Connected ו-Disconnected, כאשר ב-Connected אתם יכולים להעביר את התשתית הוירטואלית/מכונות/קונטיינרים/אחסון לענן האמיתי של Azure ובמצב Disconnected – האינטרנט מנותק, והכל רץ מקומית בארונות של ספק ה-Azure Stack שלכם (או אצלכם מקומית אם רכשתם את המערכת).

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

החסרונות של Azure Stack לעומת היתרונות – גדולים:

  • הסיבה המרכזית שחברות עוברות לענן – זה ה-Scaling שאותו לא מקבלים באותה צורה ובאותו גדול בהשוואה לענן עצמו. כנ"ל לגבי שרידות – לכל ספק ענן ציבורי יש Zones ויש Regions ואפשר להקים שרידות נפלאה. איזו שרידות תקים ב-Azure Stack? בין שרתים שהכל מקומית? אנשים שוכחים בכל פעם את התקלות שיש פה לכל מיני ISP שמשביתות אלפי לקוחות במכה אחת, ובענן ציבורי אפשר לבנות מערכת שגם תעמוד ברעידות אדמה, זה לא כזה מסובך.
  • ביצועים – עם Azure Stack אנחנו חוזרים שוב למודל ה-Enterprise מבחינת ציוד, וזאת בניגוד מוחלט למה שיש בענן ציבורי: באף ענן ציבורי אין שרתי מותג, אין דיסקים Enterprise, אין מתגים של מותג מסוים – הכל בניה "מקומית", החל מרמת המעבד והזכרון וכלה באוורור, ובעברית: מכונת VM שרצה בענן תרוץ יותר לאט על השרתים הקנייניים שמריצים את Azure Stack כי גם המעבד וגם הזכרון שונים (ספקי ענן רוכשים גרסאות Custom של מעבדים וזכרונות הרבה יותר מהירים ממה שיש בשרתים הרגילים).
  • מחירים: בניגוד למצב רגיל שאתה לוקח מספק Hosting כלשהו מכונת VM נניח עם 4 ליבות, 8 ג'יגה זכרון, 40 ג'יגה דיסק ותעבורה של 5 מגהביט והכל כלול במחיר אחד – כאן הכל שונה, אתה משלם על כל פיפס בנפרד. נתראה בחשבונית החודשית (וכן – התכוונתי ל-Azure Stack. מיקרוסופט מכתיבה זאת).
  • שרותים – הבסיסיים נמצאים + עוד כמה שרותים. השאר? עדיין נמצאים רק בענן הציבורי.
  • תאימות API בין ריצה ב-Azure Stack ל-Azure הרגיל – חלקית בלבד. תצטרכו לעשות לא מעט פליק פלאק כדי להעביר דברים מהענן מקומית וההיפך.

מיקרוסופט מנסה כבר שנתיים למכור את ה-Azure Stack ואין לה הרבה הצלחה עם זה. היא גם מוציאה את Azure Stack HCI שמנסה להתחרות בפתרונות מקומיים (vSAN, Nutantix, Simplivity) שהיתרון היחיד שלו – זה אינטגרציה עם Azure. זה יכול להיות מעניין אולי עבור חלק מהחברות, רק שכדאי לקחת בחשבון שלהגדיר את הדברים שם – אתם תתלשו שערות מהראש.

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

למי מתאים OpenStack?

"היי חץ, אנחנו שוקלים מעבר מפלטפורמת VMWare למשהו אחר, עדיף יותר זול. האם OpenStack יכול להתאים לנו?"

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

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

נניח ויש לכם מערכת VMWare ואתם צריכים לבצע את אחד (או יותר) מהדברים הבאים:

  • הקמת והגדרת Cluster
  • ביצוע Live Migration למספר מכונות VM בין Clusters
  • ביצוע Live Migration בין 2 Datastores
  • הגדרות Fault Tolerance

איך אתם תבצעו את הדברים?

  • דרך ה-Vcenter web client (הממשק הוובי) או ה-vcenter client שרץ על מכונת Windows
  • דרך PowerShell או דרך סקריפטים שכתבתם בפייתון או בשפה אחרת

התוצאות:

  • אם אתם משתמשים אך ורק בכלי ה-GUI/WEB ש-VMWare מספקת – תרדו מהמחשבה על מעבר ל-OpenStack.
  • אם אתם "פוחדים"/מתעצלים/לא מעוניינים להשתמש ב-API או לכתוב סקריפטים לאוטומציה או שימוש On Demand במקרה הצורך – רדו מ-OpenStack.

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

ברכותיי, חסכתם כמה מאות שקלים של דמי יעוץ 🙂

אחד הדברים שבגינם אני כותב את הפוסט הזה, זו המחשבה המוטעית ש-OpenStack הוא איזה פתרון CSN (כלומר Compute, Storage, Network) שמהווה תחליף ל-VMware. מבחינה טכנית "על הנייר" – הוא מסוגל בהחלט לתת שרותי CSN, אבל לא בשביל זה קונים ומטמיעים את OpenStack, כמו שלא מקימים מערכת Kubernetes בשביל להריץ 2-3 קונטיינרים.

הדברים שצריך להבין לגבי ה-OpenStack ומדוע הוא ה"דארלינג" של כל עסק HyperScale (כלומר עסק גדול שנותן שרותי ענן – כמו רוב חברות התקשורת הגדולות בחו"ל – AT&T, Verizon, SK-Telecom ועוד רבים אחרים) הם דברים מהותיים כמו:

  • OpenStack מאפשר לך להקים שרותים כמו Object ו-Block storage מצד אחד, אבל מצד שני, OpenStack יכול להתחבר בקלות לסטורג' שלך ולקבל את השרותים מהסטורג', וכל יצרני הסטורג' הגדולים (והיקרים) תומכים ב-OpenStack. שלח מייל ליצרן הסטורג' שרכשתם ותקבל בחזרה קובץ PDF או קישור איך לחבר ביניהם, כך ש-OpenStack לא מנסה להתחרות ביצרניות האחרות, אבל מצד שני אם אין לך את המשאבים/תקציב – הוא מאפשר לך להקים פתרון.
    אותו דבר מבחינת שרותי וירטואליזציה – אתה יכול להשתמש בשרותי ה-KVM של OpenStack או לחבר את ה-vSphere אל ה-OpenStack כך שמערכות ESXI יריצו את המכונות הוירטואליות. הנה התיעוד.
  • מבחינת רשתות (סיבה עיקרית שחברות הטלקום אוהבות אותו) ה-NFV (כלומר Network Functions Virtualized) של OpenStack מאפשר להתרחב למימדים מפלצתיים! גם כאן, אפשר או להקים או פשוט לפנות ליצרן ציוד התקשורת שלך שכבר תומך מספר שנים ב-OpenStack (כן, כל הגדולים תומכים).
  • שרותים, שרותים, שרותים: OpenStack התחילה את חייה כמערכת IAAS קלאסית, אבל כיום OpenStack מציעה מאות שרותים שאתה יכול לשלב ל-OpenStack ולתת/למכור את השרותים הללו ללקוחות. הלקוח רוצה שרותי ניהול DNS? אולי DB? להריץ קונטיינרים ב-Kubernetes או OpenShift? ניהול, הקמת והגדרות ברזלים (Provisioning)? שרותי Identity? שרותי Telemetry ועוד? יש, רק תגדיר במערכת ותתחיל להשתמש ולהציע ללקוחות – ולמנמר"ים שכמובן חושבים על תקציבים ותשלומים בראש ובראשונה – אני רוצה להכיר לכם את … CloudKitty.

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

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

ה"חסרון" של OpenStack – הוא שמדובר במערכת שאינה "קליק קליק קליק". כן, יש ממשק Web אך הוא יחסית די בסיסי (במיוחד אם מנסים להשוות אותו לממשקים כמו של VMWare) ורוב העבודה נעשית מול API או binding עם שפות כמו Python. זו מערכת מסובכת, מורכבת, אבל לאחרונה (בגירסת Stein) קיימת תת-מערכת חדשה, AirShip שמאפשרת הקמה והגדרת דברים בצורה קצת יותר קלה – עם YAML (אגב, למי שרוצה לשחק עם Airship על מכונת לינוקס, אפשר להריץ את הפקודות כאן ולהתרשם בעצמכם).

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

קליפים על הקמה/שימוש ב-OpenStack – בקרוב.

ההכרזה של אינטל על חומרה חדשה

אינטל לאחרונה הכריזה על שורת מוצרים חדשים – משפחת מעבדי ה-Xeon Cascade Lake שמהווים שדרוג למשפחה הנוכחית, Xeon Scalable. אלו שרוכשים שרתים מ-Dell יוכלו להתחיל לרכוש את הדור הבא של השרתים (סידרת ה-R650,750 וכו') בשבועיים הקרובים (לפחות בחו"ל). חברת HPE עוד לא הכריזה על תאריך השקה וגם לא לנובו. בסיסקו הולכים להוציא את המשפחה החדשה בערך בעוד חודש וחצי. בהשוואה למעבדים הנוכחיים, המעבדים החדשים יהיו קצת יותר מהירים אך באותו מחיר כמו הקיימים, וניתן יהיה (לאחר עדכון BIOS) להחליף את המעבדים הנוכחיים במעבדים החדשים. פוסט יותר מפורט על המעבדים החדשים (כולל רשימת המעבדים) – יופיע פה בבלוג בקרוב.

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

נתחיל בדיסק ה-SSD החדש של אינטל, ה-DC D4800X (תבדילו בינו ל-P4800X). ה-D בשם המוצר מסמן Dual Port. זהו SSD בחיבור NVME כפול. בשביל מה צריך כפול? כדי לקבל שרידות כמובן!…

אממה .. מישהו שכח או התעלם מכלל פשוט שקיים בכל PC, החל מלאפטופ ועד שרת עצבני עם 8 מעבדים: כשיש לך תקלה בחיבור PCIe, המערכת פשוט תקפא או תקרוס. לגמרי. נסיון לבצע כיבוי/הפעלה מחדש לא יצליח לעבור את ה-POST. (בעקרון, כשמפעילים את המכונה, לאחר שהמעבד הופעל וה-BIOS נכנס לשליטה, הוא מריץ את המיקרוקוד שבתוכו, הוא מתחיל לאפס את תושבות וציודי ה-PCIe. כשהוא לא מצליח – תופיע שגיאה שלא תאפשר המשך הפעלת המכנה). במילים אחרות – זה ציוד מעולה .. אם יש לכם Mainframe של IBM, שם אפשר להחליף כמעט את כל הציוד שהמכונה פעילה (וניתן להפעיל/לכבות תושבות PCIe בזמן ריצה) – אבל לא כל כך רלוונטי בשרתים.

מכאן – נעבור ל-Optane DC.

למי שלא מכיר – Optane DC זו גירסת SSD שאינה מתחברת לתושבת PCIe אלא יושבת בתוך תושבות הזכרון של השרת. בתמונה משמאל תוכלו לראות אותם כ"מקלות זכרון" (עם המדבקות, כלומר 3 מקלות Optane DC ו-3 מקלות זכרון DDR4 ECC). כל מקל Optane DC מגיע ב-3 גדלים – 128, 256 או 512 ג'יגהבייט אחסון! (המחירים, אגב, לאלו שרוצים לדעת – ואלו לא מחירים סופיים: 893, 2461 דולר וה-512 ג'יגהבייט עדיין לא יצא). אלו אינם מקלות זכרון, כך שאם יש לך מול מעבד כ-256 ג'יגה זכרון והכנסת מקל Optane DC של 256 ג'יגהבייט, לא יהיה לך זכרון של כחצי טרה, אלא 256 ג'יגה זכרון ו-256 ג'יגה של אחסון מהיר.

בכנס Ignite האחרון, מיקרוסופט הדגימה איך ה-Optane DC עוזר בסביבת HCI שמורכבת מ-Hyper-V, Storage spaces direct וכו'. להלן הוידאו:

שימו לב למשהו אחד חשוב שקצת פחות מודגש בוידאו: כל ה-Optane DC שבשרתים בהדגמה משומש ל-Cache בלבד ולא כ-Storage! במילים אחרות, גם אם תכניס טרהבייט של Optane DC בשרת, עדיין תצטרך Storage כלשהו, ולכן השימוש של Optane DC יותר מתאים כ-Cache ל-DB או למכונות וירטואליות. ניתן לראות את הדגש הזה גם במסמך הזה שהוציאה VMWare שמתייחסת ל-Optane DC ולגירסה עתידית של vSphere.

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

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

אחד המוצרים הנוספים שאינטל הכריזה עליו הוא Intel SSD D5-P4326 – כונן SSD בתצורת "סרגל" (שמו הטכני של הסטנדרט: EDSFF E1.L – שם שממש מתגלגל בפה). כל סרגל SSD כזה יכיל בדור הנוכחי עד 15.32 טרהבייט אחסון… רק לפני שמתלהבים, האחסון מורכב מ-QLC NAND, הווה אומר שבתא NAND אפשר לאחסן 4 ביטים, מה שמאפשר לאחסן יותר מידע פר תא, אך מצד שני, מהירות הכתיבה – איטית מאוד בהשוואה לכונני SSD מדור נוכחי מבוססי TLC (כלומר 3 ביטים בתא). אינטל ושותפיה ימכרו שרת 1U שבו יהיה ניתן להכניס 32 סרגלים כאלו ליצור אחסון עד כמעט חצי פטהבייט שמיועד יותר לאחסון מידע לקריאה, ובמילים אחרות – לא מאחסנים על זה מכונות וירטואליות, קונטיינרים ושאר דברים שמצריכים קריאה/כתיבה מהירה יותר ממה שאותם סרגלי SSD יכולים להציע.

הבעיה המרכזית במוצר היא התחרות שלו מול דיסקים קשיחים מכניים. נכון, SSD נותן מהירות קריאה הרבה יותר גבוהה מכל דיסק מכני, אבל דיסק מכני כמו Seagate Baracuda בגודל 14 טרהבייט ל-Enterprise עולה בסביבות ה-550$ ואילו סרגל של 15.3 טרהבייט של אינטל עולה פי 8. את עניין הבדלי הקריאה/כתיבה ניתן תמיד לפתור בעזרת מספר דיסקים SSD שישמשו ל-Cache כך שהפתרון של אינטל עדיין אינו שווה לדעתי מבחינה כלכלית.

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

תחום ה-VDI וענן – עדכון מצב

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

על מנת להבין את הבעיה, נתחיל בהתחלה הפשוטה: כל ספקי הענן ישמחו לאפשר לך לשכור מכונה (Instance או VM) מבוססת Windows, בין אם מדובר על Windows Server 2012, 2016 או אפילו 2019. אין שום בעיה. רוצה משהו כמו Windows 10 או גירסה מתחת? תשכח מזה. ספקית ענן כמו אמזון שמחה להציע משהו "דומה ל-Windows 10" לדוגמא. מה שתקבל בעצם זה Windows Server 2016 ששינו לו מספר גדול של ערכים ב-Registry, שהותקן עליו Windows Experience וגם מספר אפליקציות בסיסיות. יש גם את חבילת ה"פלוס" שכוללת אופיס, אבל אז אתה משלם תוספת שכוללת תשלום חודשי למיקרוסופט לא רק על ה-OS, אלא גם על ה-Office שמותקן ב-Instance. למכונה כזו אתה יכול להתחבר עם כלים שונים שמתאימים לכל מערכת הפעלה קיימת, כולל סלולרי/טאבלט/כרומבוק וכו'.

אז מדוע אף אחד לא מציע מכונה מבוססת Windows 10? אחרי הכל, שרות שידע להקים מכונה כזו מ-אפס או אפילו לקחת Sysprep שלך ו"להלביש" אותו על ה-OS זה לא משהו כזה מסובך לכתוב…

הבעיה מגיעה מכיוון רדמונד. מיקרוסופט לא רוצה (ולפעמים גם נלחמת באמצעים משפטיים) ששום ספק יציע שרות כזה, ולא חשוב אם מדובר בספק ענן ענק, או בחברת Hosting פצפונת. מבחינת מיקרוסופט, המוצרים היחידים מבחינת OS המוצעים לספקי Hosting וענן כאחד – הם אלו הכלולים תחת רשיון SPLA בהם הספק משלם למיקרוסופט כל חודש על רשיונות ה-Windows Servers (וכלים אחרים) ואת המחיר הוא מגלגל על הלקוח. במסגרת הדברים המוצעים ב-SPLA, אין שום הצעה/שורה למערכת דסקטופ כלשהי, ולא חשוב אם מדובר בגירסת Home או Enterprise.

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

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

וכאן נשאלת השאלה שכולם ירצו לדעת: האם זה שווה פיננסית? ניקח דוגמא: ראובן, CTO של חברה גדולה מעוניין לזרוק/לגרוט את כל ה-800 דסקטופים של החברה. להתקין לכולם Thin Client (ואלו שמחוץ לחברה ישתמשו בתוכנת Client יעודית או בדפדפן) ופשוט לעבוד בענן. אם מחר ראובן היה שוכר את שרותי היעוץ שעבדכם הנאמן מציע – מה הייתי אומר לו?

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

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

בקיצור: אם ספקי הענן יציעו שרות של מכונות וירטואליות עם Windows 10 כ-שרות VDI והם יגבו כמו שהם גובים כיום על Instances, המחיר הכולל פשוט לא יהיה שווה מכיוון שעלויות התקשורת יהיו אסטרונומיות. החברות יצטרכו להציע חבילות Bundle הכוללות מספר טרהבייט תעבורה בחודש עם שרות VDI.

לסיכום: VDI בענן במחשבה ראשונה יכול להישמע רעיון לא רע, אבל כשמתחילים לחשוב על העלויות של Instances ובמיוחד העלויות של תקשורת בין הענן אל המשתמשים בארגון, ואם מוסיפים לכך ענייני רגולציה ובעיות תקשורת עקב כך שהכתובות IP אינן ישראליות – הרעיון כרגע אינו שווה כל כך פיננסית. אם לעומת זאת ספקי הענן יתנו חבילות תקשורת עם מחיר טוב בכל הקשור לתעבורת VDI וניתן יהיה לקשר כתובות IP ישראליות מספק מקומי אל ספק הענן (כמו שרות BYOIP שאמזון מציעים) – יכול להיות שזה יהיה משתלם. האם ניתן יהיה להעביר הכל לענן? לא. כל דבר שמצריך VPN לא ניתן יהיה להעביר (מכיוון שמשתמשים בתקשורת אל ה-VM ש"נופלת" ברגע שיש שכבת VPN, ובמקרים של VPN כמו של סיסקו המערכת פשוט לא נותנת להתחבר) ויש כמובן את המכונות המקומיות שקשורות לכל מיני ציודים שיש בהם צורך מקומית (GPU, תקשורת לסטורג' מקומי וכו').

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

נקודות למחשבה לגבי מעבר לענן (2019)

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

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

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

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

נניח וירון בוחר את השיטה להחליף "ברזלים" – נניח R710/R720 ב-R740 – העלות שלו תהיה Fixed ומשולמת מראש. נניח לשם הדוגמא ש-R740 עולה 10,000$ ויש לו 3 שרתים ישנים והוא מעוניין להחליף את כולם, אז העלות תהיה בעצם 30,000$. במחיר הזה ירון מקבל את האפשרות להביר מכונות VM לתשתית החדשה תוך שימוש ברשיונות קיימים (בדרך כלל, קיימות גם חריגות) והוא יכול בהמשך להוסיף עוד מכונות VM ללא עלות נוספת (שוב, למעט מקרים של רשיונות ל-OS וכו').

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

אז בואו נחשב מחיר: יש לנו 50 מכונות VM שפרוסים על 3 שרתים והם יתנו שרות לפחות ל-3 שנים הקרובות. מחיר פר VM יצא 600$. אפשר כמובן לקצץ ולרדת ל-2 שרתים עם מעבדים חזקים מרובי ליבות וכמות זכרון משמעותית (נניח 256 ג'יגה פר שרת פיזי). חושבים שזה יעזור? מהרגע שעוברים ממעבדים כמו Xeon SP Silver למשהו יותר רציני – המחיר יטפס בכמה אלפי דולרים, כך שלא בטוח שאם נרד בכמות השרתים (אך נשדרג במעמד ההזמנה את אלו שאנחנו רוצים לרכוש במפרט יותר "כבד") זה יעזור. אנחנו יכולים לרדת במחיר VM מ-600$ נניח ל-500$ ואפילו $400. המחיר ירד יותר אם אותן מכונות VM יעבדו יותר שנים, כמו לדוגמא 5 שנים – אז אנחנו יכולים לרדת ל-$133 פר VM.

נניח עתה שירון רוצה להסתכל על הפתרונות בענן. שיהיה מה להשוות.

אז בואו נאמר שב-AWS ניקח מכונה צנועה, 2 ליבות, 8 ג'יגה זכרון, תעבורת תקשורת נמוכה ו-80 ג'יגה דיסק (EBS). המחיר לחודש – 80$. את המחיר הזה ניתן "לחתוך" אם ירון מוכן לשלם לשנה מראש או 3 שנים מראש על אותו VM. אם זה לשנה, הוא יצטרך לשלם $1740 ואם זה ל-3 שנים, אז הוא יצטרך לשלם $1159 (כלומר אפקטיבית הוא כביכול ישלם 32.20$ לחודש) – אז בתכל'ס ניתן להגיע למחירים טובים פר VM (זה קיים אצל כל ספקי הענן הגדולים, אגב). יש,אגב, מסלולים שונים, תלוי בספק הענן.

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

  • רוצים קו יעודי (MPLS) של 100 מגה נניח מחברתכם אל אמזון? זה יעלה כמה אלפי דולרים, לאמזון ולספק התשתיות שלכם.
  • לא רוצים פתרון MPLS אלא VPN? אין בעיה. התשלום יהיה על ה-Instance שיריץ את פתרון ה-VPN ועל התעבורה היוצאת מאמזון אליכם (משלמים על הכיוון מאמזון החוצה, לא להיפך)
  • יציאה לאינטרנט – אתם משלמים על כל ביט שיוצא החוצה לאינטרנט מהתשתית שלכם בענן, ותלוי גם לאן התקשורת יוצאת – כל אזור והמחיר שלו (המחיר הולך פר ג'יגהבייט)
  • רוצים לגבות את התכנים? רעיון מעולה! כל ספקי הענן מציעים שרותי אחסון שונים (כמו S3 ועוד) ויש עלויות של כמה סנטים פר ג'יגהבייט (תלוי בענן, ובסוג שרידות שאתם מחפשים עבור הגיבוי).
  • כתובות IP אמיתיות – כל כתובת עולה כסף ואם ביקשתם הקצאת כתובות ולא השתמשתם – המחיר פר IP קופץ פי 3-4 (המחיר הוא בדרך כלל ל-IP אמיתי בשימוש בסביבות 1-2$ לחודש)
  • החלטתם להשתמש בשירותים שונים כדי לחסוך הקמה ותחזוקה של שרות דומה? יש מחירים Pay as you go ויש מקרים שאפשר לשלם מראש ולחסוך. ככל שיש יותר שימוש, המחיר עולה.

(עכשיו אתם מבינים מדוע אני מתייחס לעננים המקומיים שמציעות חברות תקשורת מקומיות שונות שמריצות תשתית של VMWare או Hyper-V כבדיחה?)

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

  • ב-On Prem אתה משלם על הציוד פעם אחת ואם אתה רוצה להוסיף נניח עוד מכונות VM, העלות תהיה אפסית (למעט במקרים שצריך שדרוג ציוד).
  • ב-On Prem כשיש תקלה, אפשר לטפל בה מקומית 24X7 ולא תלוים בספק הענן (אם משתמשים בשרותים של ספק הענן לדוגמא) עד שיתקנו את התקלה.
  • בענן אפשר תוך דקות ספורות להתחבר לשרותים שונים שחוסכים הקמת שרתים/הגדרות/תחזוקה ואפשר להשתמש ישירות בשירות. כך לדוגמא, במקום להחזיק Cluster של SQL, אפשר להשתמש בשרותי RDS.
  • בענן מחירי ה-VM יותר זולים – אם מוכנים לשלם מראש.
  • בענן אתה תמיד רץ על תשתית חזקה ואף אחד לא מכניס את ה-Instances שלך למכונות שכבר עמוסות. במקרים רבים ה-Instances רצים על מעבדים יחודיים חזקים שלא זמינים לשוק הרחב.
  • שרותי תמיכה בענן ישירות מספק הענן – אינם זולים.
  • נקודה חשובה: ב-On Prem אין לך הפתעות במחיר או בחשבונית חודשית.
  • כשזה מגיע לתשלום – בענן אין "שוטף/שוטף פלוס". התשלום הוא בתחילת החודש הבא.

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

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

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