בניית Azure שמחזיקה מעמד בעולם האמיתי — עם Mike Martin [MVP]

ארכיטקטורת Azure נראית פשוטה כשהכול עובד.המבחן האמיתי מתחיל כשתלויות נכשלות, אזורים הופכים לזמינים, עומסי תנועה מזנקים, הנחות מתבררות כשגויות, דרישות משתנות, ובסופו של דבר מישהו שואל את השאלה המביכה: למה תכננו את זה כך מלכתחילה?בפרק הזה של M365.FM, Mirko Peters משוחח עם Mike Martin [MVP] על המראה של ארכיטקטורת Azure כשהיא חייבת לשרוד תנאי ייצור אמיתיים, ולא רק להיראות טוב על דיאגרמה.לMike ניסיון של עשרות שנים בפיתוח, תשתיות, ארכיטקטורה, ניהול, אימון, הדרכה ו-Microsoft Azure. אחת התובנות החזקות שלו היא שרבות מהבעיות שארכיטקטים מתמודדים איתן היום אינן חדשות באמת. DNS עדיין נשבר. תלויות ב-IP עדיין חשובות. עלויות עדיין הופכות לבעיה. אינטגרציות עדיין נכשלות. תלויות עדיין נעלמות ברגע הכי גרוע.מה שהשתנה הוא רמת המורכבות שאנו בונים סביב הבעיות האלה.

מ-VISUAL BASIC ועד ארכיטקטורת Azure מודרנית
Mike מסתכל אחורה על כמעט שלושה עשורים בתחום ה-IT, שהחלו כמפתח Visual Basic בשנות התשעים, והמשיכו דרך מערכות מבוזרות, רשתות, תוכנה ארגונית, תשתיות, ולבסוף Azure.התובנה המרכזית שלו פשוטה: בתעשייה ממשיכים לפתור הרבה מאותן בעיות יסוד, אבל הארכיטקטורות סביבן נעשו מורכבות הרבה יותר.מערכות מודרניות עברו מיישומי client-server לארכיטקטורות מבוזרות, פלטפורמות ענן, קונטיינרים, microservices, Kubernetes, סביבות היברידיות וכעת גם פיתוח בסיוע AI.זה יוצר אפשרויות עצומות, אבל גם סיכון חדש: הנדסת-יתר.Mike טוען שצוותים רבים היום הופכים בעיות פשוטות למסובכות מיותר. ארכיטקטורה טובה אינה לרוב עניין של הוספת עוד טכנולוגיה. היא עניין של לדעת מה לא להוסיף.

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

• זהות
• רשתות
• זרימות נתונים
• אבטחה
• ניטור
• אינטגרציה
• תלויות
• מדרגיות
• תפעול
• שחזור
• פריסה
• עלות

Mike גם מאתגר את הרעיון ש-cloud-native אומר בהכרח Kubernetes או קונטיינרים. Azure מספקת שירותים מנוהלים ומקומיים רבים שיכולים לפתור בעיות בלי להכניס תקורה תפעולית מיותרת.תפקיד הארכיטקט הוא להבין את הפתרון במלואו ולבחור בארכיטקטורה הפשוטה ביותר שעדיין עונה על הדרישות האמיתיות.

מתחילים מדרישות עסקיות, לא משירותי Azure
אחד הלקחים החשובים בפרק הוא פשוט: לא מתחילים מהטכנולוגיה.לפני שמחליטים בין Azure Kubernetes Service, App Service, Azure Functions, קונטיינרים, Service Bus או פלטפורמה אחרת, צריך להבין קודם מה הפתרון באמת צריך לעשות.שאלות שכדאי לשאול:

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

השאלות האלה מובילות ישירות למושגים כמו SLA, SLO, RTO ו-RPO.הן גם קובעות אם הארכיטקטורה צריכה להיות באזור יחיד, מרובת אזורים, active-active, active-passive או משהו הרבה יותר פשוט.

RTO ו-RPO בלי המונחים המנופחים
RTO ו-RPO נדונים לעיתים כמו מונחים טכניים, אבל המשמעות האמיתית שלהם עסקית.

• RTO — Recovery Time Objective: כמה מהר המערכת חייבת לחזור אחרי כשל?
• RPO — Recovery Point Objective: כמה אובדן נתונים מקובל?

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

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

• איטית
• מוגבלת בקצב (throttled)
• זמינה חלקית
• תלויה ב-backend שנכשל
• מושפעת מבעיית אינטגרציה
• תחת לחץ אזורי

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

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

• Circuit breakers
• צימוד רופף (loose coupling)
• עיבוד אסינכרוני
• הרחבה עצמאית של רכיבים
• אזורי זמינות מרובים
• אזורים מרובים
• מנגנוני failover
• ניטור
• Infrastructure as Code
• נהלי שחזור שנבדקו

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

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

• רכיבים שונים יכולים להתרחב באופן עצמאי
• שירות אחד יכול להיכשל בלי להפיל את כל הפלטפורמה
• Backends יכולים לעבד עבודה באופן אסינכרוני
• עליות תנועה קלות יותר לספיגה
• רכיבים הפונים למשתמש תלויים פחות בתזמון ה-backend
• קל יותר לבודד כשלים

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