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