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