ה-Well-Architected Framework מספק המלצות לאדריכלים, למפתחים, לאדמינים ולגורמים אחרים בתחום הענן איך לתכנן ולהפעיל טופולוגיה מאובטחת, יעילה, עמידה, בעלת ביצועים גבוהים, חסכונית ובת קיימא בענן.
צוות מומחים רב-תחומי ב-Google מאמת את ההמלצות ב-Well-Architected Framework. הצוות אוסף את המידע ב-Well-Architected Framework כדי לשקף את היכולות המתפתחות של Google Cloud, את השיטות המומלצות בתעשייה, את הידע של הקהילה ואת המשוב שלכם. סיכום של השינויים המשמעותיים ב-Well-Architected Framework זמין במאמר מה חדש.
ה-Well-Architected Framework רלוונטי לאפליקציות שנוצרו לענן ולעומסי עבודה שהועברו משרתים מקומיים אל Google Cloud, פריסות בענן היברידי וסביבות מרובות עננים (multi-cloud).
העקרונות וההיבטים של Well-Architected Framework
ההמלצות ב-Well-Architected Framework מאורגנות לפי עקרונות ונקודות מבט חוצות-עקרונות, כפי שמוצג בתרשים הבא.
עמוד ב-Well-Architected Framework מספק עקרונות והמלצות לגבי תחום ספציפי שאינו פונקציונלי: אבטחה, אמינות, ביצועים, עלות, תפעול או קיימות.
פרספקטיבה ב-Well-Architected Framework היא תצוגה חוצת-עמודות של המלצות לטכנולוגיה, לדומיין או למגזר ספציפיים. ההמלצות בפרספקטיבה מסוימת תואמות לעקרונות הכלליים ולהמלצות שמופיעות ב-pillars.
לדוגמה, בפרספקטיבה של שירותים פיננסיים (FS) מומלצת אסטרטגיה להתאוששות מאסון שעומדת בדרישות הרגולטוריות בנוגע למיקום הנתונים. ההמלצה הספציפית הזו ל-FS תואמת לעיקרון של עמודת המהימנות בנושא יעדים ריאליים, כי הדרישות לגבי מיקום הנתונים משפיעות על הבחירה של אזור המעבר לגיבוי, וכתוצאה מכך על יעדי השחזור.
עמודים
- מצוינות תפעולית
- פריסה, הפעלה, מעקב וניהול יעילים של עומסי העבודה בענן.
- אבטחה, פרטיות ותאימות
- מקסום האבטחה של הנתונים ועומסי העבודה בענן, תכנון הפרטיות והתאמה לדרישות ולתקנים הרגולטוריים.
- אמינות
- תכנון והפעלה של עומסי עבודה עמידים וזמינים מאוד בענן.
- הוזלת עלויות
- מקסום הערך העסקי של ההשקעה ב- Google Cloud.
- אופטימיזציה של הביצועים
- תכנון ושיפור של משאבי הענן לביצועים אופטימליים.
- eco קיימוּת
- בנייה וניהול של עומסי עבודה בענן שהם ברי קיימא מבחינה סביבתית.
נקודות מבט חוצות-קטגוריות
- AI ו-ML
- תצוגה של המלצות ספציפיות לטכנולוגיות AI ו-ML, שמתייחסות לכל עומסי העבודה.
- שירותים פיננסיים
- תצוגה של המלצות לעומסי עבודה של FS בכל המוצרים.
עקרונות ליבה
לפני שמעיינים בהמלצות בכל אחד מהעקרונות של Well-Architected Framework, כדאי לעיין בעקרונות הבסיסיים הבאים:
עיצוב לשינוי
אף מערכת לא נשארת קבועה. הצרכים של המשתמשים, המטרות של הצוות שבנה את המערכת והמערכת עצמה משתנים כל הזמן. כדי להטמיע שינויים, צריך לבנות תהליך פיתוח וייצור שמאפשר לצוותים להטמיע שינויים קטנים באופן קבוע ולקבל משוב מהיר על השינויים האלה. היכולת להטמיע שינויים באופן עקבי עוזרת לבנות אמון עם בעלי העניין, כולל הצוותים שאחראים על המערכת והמשתמשים במערכת. שימוש במדדי DORA להכנת תוכנה להפצה יכול לעזור לצוות שלכם לעקוב אחרי המהירות, הקלות והבטיחות של ביצוע שינויים במערכת.
תיעוד הארכיטקטורה
כשמתחילים להעביר את עומסי העבודה לענן או לבנות את האפליקציות, היעדר תיעוד לגבי המערכת יכול להיות מכשול משמעותי. תיעוד חשוב במיוחד כדי להמחיש בצורה נכונה את הארכיטקטורה של הפריסות הנוכחיות.
כדי ליצור תיעוד איכותי, לא צריך ליצור כמות מסוימת של תיעוד, אלא לוודא שהתוכן ברור ושימושי, ושהוא מתעדכן ככל שהמערכת משתנה.
ארכיטקטורת ענן שמתועדת בצורה נכונה יוצרת שפה משותפת ותקנים, ומאפשרת לצוותים עם תפקידים שונים לתקשר ולשתף פעולה בצורה יעילה. במסמכים מפורט גם המידע שנדרש כדי לזהות את ההחלטות העיצוביות העתידיות ולתת להן כיוון. חשוב לכתוב את התיעוד תוך התייחסות לתרחישי השימוש, כדי לספק הקשר להחלטות העיצוב.
עם הזמן, ההחלטות שלכם לגבי העיצוב יתפתחו וישתנו. היסטוריית השינויים מספקת את ההקשר שנדרש לצוותים כדי לתאם בין יוזמות, להימנע מכפילויות ולמדוד ביעילות את השינויים בביצועים לאורך זמן. יומני שינויים שימושיים במיוחד כשמצרפים צוות אדריכל ענן חדש שלא מכיר עדיין את העיצוב, האסטרטגיה או ההיסטוריה הנוכחיים שלכם.
ניתוח של DORA מצא קשר ברור בין איכות התיעוד לבין הביצועים של הארגון – היכולת של הארגון לעמוד ביעדי הביצועים והרווחיות שלו.
פישוט העיצוב ושימוש בשירותים מנוהלים
פשטות היא קריטית לעיצוב. אם הארכיטקטורה מורכבת מדי, יהיה קשה להבין אותה, להטמיע את העיצוב ולנהל אותה לאורך זמן. במקרים שבהם הדבר אפשרי, מומלץ להשתמש בשירותים מנוהלים באופן מלא כדי לצמצם את הסיכונים, הזמן והמאמץ שקשורים לניהול ולתחזוקה של מערכות בסיסיות.
אם אתם כבר מפעילים את עומסי העבודה שלכם בסביבת ייצור, כדאי לבדוק שירותים מנוהלים כדי לראות איך הם יכולים לעזור לכם לצמצם את המורכבות התפעולית. אם אתם מפתחים עומסי עבודה חדשים, כדאי להתחיל בפשוט, ליצור מוצר מינימלי בר-קיימא (MVP) ולהימנע מהנדסת יתר. תוכלו לזהות תרחישי שימוש חריגים, לבצע איטרציות ולשפר את המערכות שלכם בהדרגה לאורך זמן.
הפרדה בין רכיבים בארכיטקטורה
מחקר של DORA מראה שהארכיטקטורה היא גורם חשוב לחיזוי היכולת להשיג מסירה רציפה. הפרדה היא טכניקה שמשמשת להפרדה של האפליקציות ורכיבי השירות לרכיבים קטנים יותר שיכולים לפעול באופן עצמאי. לדוגמה, אפשר להפריד בין רכיבי שירות נפרדים במערך של אפליקציה מונוליתית. בארכיטקטורה עם צימוד רופף, אפליקציה יכולה להפעיל את הפונקציות שלה באופן עצמאי, ללא קשר לתלות השונות.
ארכיטקטורה מופרדת מעניקה לכם גמישות רבה יותר ומאפשרת לכם:
- החלת שדרוגים עצמאיים.
- אכיפה של אמצעי בקרה ספציפיים לאבטחה.
- להגדיר יעדי מהימנות לכל מערכת משנה.
- מעקב אחר הבריאות.
- שליטה פרטנית בפרמטרים של ביצועים ועלויות.
אפשר להתחיל את תהליך ההפרדה בשלב מוקדם של תכנון המערכת או לשלב אותו כחלק משדרוגי המערכת במהלך ההרחבה.
שימוש בארכיטקטורה חסרת מצב
ארכיטקטורה ללא שמירת מצב יכולה לשפר את האמינות והמדרגיות של האפליקציות.
אפליקציות עם מצב מסתמכות על תלויות שונות כדי לבצע משימות, כמו שמירת נתונים במטמון מקומי. אפליקציות עם מצב (Stateful) לרוב דורשות מנגנונים נוספים כדי לתעד את ההתקדמות ולהפעיל מחדש בצורה חלקה. אפליקציות בלי שמירת מצב יכולות לבצע משימות ללא תלות מקומית משמעותית באמצעות נפח אחסון משותף או שירותים נשמר במטמון. ארכיטקטורה ללא שמירת מצב מאפשרת להגדיל את הקיבולת של האפליקציות במהירות עם תלות מינימלית באתחול. האפליקציות יכולות לעמוד בפני הפעלה מחדש, זמן ההשבתה שלהן קצר יותר והן מספקות ביצועים טובים יותר למשתמשי הקצה.