המרוץ, או ליתר דיוק הנהירה, להעביר שירותים לתשתית בענן בעיצומה. הענן הפך לעין "ארץ מובטחת" – שבה השירותים "אף פעם לא נכשלים" ואפשר להיות בטוחים שהשירותים יהיו זמינים 24/7.
אבל אם נסתכל מקרוב, במבט כנה, נגלה שיש אמת לפתגם: אם משהו נשמע טוב מכדי להיות אמיתי, הוא בדרך כלל לא אמיתי.
אין סביבה החסינה מפני נפילות בין אם זה Microsoft 365 או גוגל או AWS. וככל שפלטפורמות הענן הופכות למורכבות יותר ויותר, וככל שספקים מוסיפים עוד תכונות ושירותים, תחזוקה חסינת תקלות תהיה קשה ומאתגרת יותר. זאת אומרת שצוותי ספקי שירותי ענן יצליחו פחות ופחות להשתלט על האופן שבו הכל עובד ומקושר זה לזה, ולפתור באגים כשתהיה הפסקת שירות.
אז אל תיפול למיתוס "always on". אלא אם אתם יכולים לחיות 5 שעות כששירותים קריטיים מושבתים, כגון הצפה במרכז נתונים בפריז. אבל אם אתם לא יכולים להרשות לעצמכם downtime כזה, עדיף לתכנן מערכת גיבוי בארכיטקטורה שלך כדי להתגבר על הפסקת שירותי ענן הגדולה הבאה שבדרך.
יש הרבה מה ללמוד מתכנון רשת לאומית על כיצד לעשות זאת בצורה הטובה ביותר.
דוגמה טובה היא איך מחב"א מפעילה את רשת המחקר הלאומית (NREN) של ישראל. במהלך ה-30 שנה אחרונות, השקנו טכנולוגיות רשת רבות – מ-frame relay, ל-ATM, MAN ו-ethernet. האקסיומה שלנו תמיד הייתה לבנות את הרשת שלנו עם יתירות. כל אוניברסיטה מחוברת באמצעות שני קישורים שונים. תמיד יש את הספק הראשי וספק הגיבוי – שאנחנו מתעקשים שתמיד יהיו ספקים שונים.
במהלך השנים, ספקים רבים פנו אלינו והציעו הנחות ענק אם רק נאפשר להם לספק את שני הקישורים. הם הבטיחו שהמעגלים מגוונים לחלוטין ו"עמידים בפני תקלות".
אבל הניסיון שלנו למד אותנו שתמיד יש איזו תשתית משותפת שיכולה להיפגע מ"חוק מרפי."
אנחנו תמיד מזמינים קישורים מספקים שונים ותמיד מסיימים את המעגלים בנתבים שונים ובבניינים שונים בתוך הקמפוסים. במהלך השנים האסטרטגיה הזו הוכיחה את עצמה פעם אחר פעם.
אז היזהרו מלתת למוסדות לשים את כל ביצי הענן שלהם בסל אחד. עודדו אותם להיות זהירים ולבחור ביתירות ובתשתיות גיבוי חזקות בכל עת ובכל מקום שהם יכולים. תמשיכו לעודד ולעזור להם להיות עם "ראשם בעננים". אבל תראו להם איך לעשות את זה בזהירות ובתבונה כמו שרק NREN אקדמי יכול.