שיטות מומלצות לניהול אפליקציות

במדריך הזה מפורטות שיטות מומלצות לתכנון, להגדרה ולניהול של אפליקציות ב-App Hub ב-Google Cloud שמתמקד באפליקציות, באמצעות App Hub ו-Application Design Center. השיטות המומלצות האלה חיוניות ליצירת אפליקציות שניתן להפעיל, לנהל ולשלוט בהן, ושמתאימות ליעדים העסקיים שלכם.

עקרונות הליבה של ניהול אפליקציות

הקפדה על העקרונות הבסיסיים הבאים תעזור לכם למקסם את הערך שתקבלו מניהול התשתית שלכם באופן שמתמקד באפליקציה: Google Cloud

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

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

  • גבול ניהול האפליקציות מגדיר את אוסף הפרויקטים שמכילים את המשאבים Google Cloud שבהם אפשר להשתמש כדי לעצב, ליצור ולנהל אפליקציות, כפי שמתואר במאמר מושגי מפתח.
  • היקפי Observability ב-Google Cloud Observability מאפשרים לכם להציג טלמטריה מכמה פרויקטים ביחד.

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

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

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

  במרכז האפליקציות, אפשר להגדיר מאפיינים מרכזיים כמו:

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

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

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

• חזרה על הפעולות ושיפור של מודלים של אפליקציות: חשוב לבדוק באופן קבוע את ההגדרות של האפליקציות ולשנות אותן בהתאם לשינויים במבנה הארגון, בסדרי העדיפויות העסקיים ובארכיטקטורה הטכנית. ב-Cloud Hub מוצגים עדכונים זמינים לאפליקציות שנפרסו מתבניות של Application Design Center, ועוזרים לכם לבדוק את הגדרות האפליקציות ולשנות אותן בהתאם לצרכים המשתנים.

המלצות למודל נתונים

אם תבינו איך ליצור מודלים של המערכות שלכם בעולם האמיתי כאפליקציות, שירותים ועומסי עבודה במסגרת App Hub, תוכלו להשתמש ביכולות ניהול האפליקציות בסביבת Google Cloudבצורה יעילה.

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

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

דוגמה: אפליקציה מבוססת מיקרו-שירותים

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

• אפליקציה: יוצרים או מגדירים אפליקציה אחת ב-App Hub בשם, לדוגמה, my-ecommerce-site. האפליקציה הזו מייצגת את החנות הווירטואלית כולה כיחידה אחת שאפשר לנהל. כדי ליצור קיבוץ לוגי של רכיבים שמספקים יחד את הפונקציה העסקית של החנות הווירטואלית שלכם, צריך לרשום את המשאבים הבאים באפליקציה:

  • מיקרו-שירותים כעומסי עבודה: רושמים את המיקרו-שירותים האישיים שמרכיבים את מערכת המסחר האלקטרוני, כמו Ad,‏ Cart ו-Checkout, כעומסי עבודה בתוך האפליקציה. אלה משאבי מחשוב עם קוד בינארי שמבצעים חלק נפרד של הלוגיקה העסקית, ופועלים כפריסות של Google Kubernetes Engine‏ (GKE).
  • נקודות קצה ברשת כשירותים: רישום של נקודות הקצה ברשת עבור המיקרו-שירותים האלה, כמו מאזני העומסים שלהם, כשירותים של האפליקציה. הן חושפות את הפונקציונליות של החנות הווירטואלית ללקוחות.

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

כשמקבצים את כל המיקרו-שירותים באפליקציה אחת, נהנים מהיתרונות הבאים:

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

דוגמה: אפליקציית אינטרנט תלת-שכבתית

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

המודל הבא ממפה שכבות טכניות לאפליקציית אינטרנט בת שלוש רמות:

• אפליקציה: יוצרים אפליקציה אחת, למשל my-web-app, שתשמש כמאגר לוגי לכל הרכיבים שמרכיבים את אפליקציית האינטרנט.

• שירותים: רישום של ממשקי הרשת שחושפים פונקציונליות לשכבות אחרות או למשתמשים כשירותים, לדוגמה:

  • מאזן העומסים בקצה הקדמי שמקבל תעבורת נתונים של משתמשים.
  • מאזן העומסים הפנימי שמנהל את התנועה בין חזית האתר (frontend) לבין העורף (backend).
  • מופע מסד הנתונים של Cloud SQL או Spanner, שחושף שירות נתונים לשכבת הלוגיקה של הקצה העורפי.

• עומסי עבודה: רושמים את משאבי המחשוב שמריצים את הקוד של האפליקציה כעומסי עבודה. לדוגמה:

  • פריסות של קבוצות מנוהלות של מופעים (MIG) או של Google Kubernetes Engine שמציגות את ממשק המשתמש של חזית האתר.
  • קבוצות ה-MIG או פריסות Google Kubernetes Engine שמריצות את הלוגיקה העסקית של ה-Backend.

כשמקבצים את כל שלושת המסלולים באפליקציה אחת, נהנים מהיתרונות הבאים:

• יכולת צפייה מאוחדת: אתם יכולים לעקוב אחרי התקינות והביצועים של האפליקציה כולה מלוח בקרה אחד ב-Application Monitoring, במקום להרכיב נתונים משלוש אפליקציות נפרדות.
• בעלות ברורה: אתם יכולים להקצות בעלים של העסק, המפתחים והמפעילים לאפליקציה my-web-app, וכך להבהיר מי אחראי על כל הפונקציות העסקיות.
• ניהול פשוט יותר: אפשר להחיל מדיניות ובקרת גישה ברמת my-web-app, וכך לתמוך בניהול עקבי בכל הרמות.

אסטרטגיות לעיצוב אפליקציות ולניהול שלהן

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

בחירה בין אפליקציות גלובליות לאפליקציות אזוריות

המיקום שבוחרים לאפליקציה, גלובלי או אזורי, הוא החלטה מהותית שמשפיעה על הטיפול בנתונים, על זמן האחזור ועל התאימות:

• העדפה של אפליקציות אזוריות: בכל הזדמנות, כדאי להגדיר את האפליקציות כאזוריות. השיטה הזו מספקת יתרונות כמו צמצום זמן האחזור, חיסכון פוטנציאלי בעלויות ועמידה בדרישות של מיקום הנתונים. מומלץ להשתמש באפליקציות אזוריות אם כל רכיבי האפליקציה נמצאים באזור אחד, כי הן תואמות באופן מובנה לתכונות ספציפיות לאזור ולדומיינים של כשלים. Google Cloud Google Cloud הנחיות ליצירת מערכות עם זמינות גבוהה מפורטות במאמר יצירת מערכות עם זמינות גבוהה באמצעות יתירות משאבים.
• שימוש אסטרטגי באפליקציות גלובליות: כדאי לבחור באפליקציה גלובלית רק אם הרכיבים של המערכת שלכם חייבים להיות מפוזרים בכמה אזורים או אם הם כוללים משאבים Google Cloud גלובליים, כמו מאזן עומסים חיצוני גלובלי של אפליקציות (ALB).
• פירוק מערכות מרובות אזורים: אם יש לכם משאבים בכמה אזורים שלא יוצרים פונקציה גלובלית מגובשת אחת, כדאי להגדיר אפליקציות אזוריות נפרדות לרכיבים בכל אזור. השיטה הזו מאפשרת למקסם את היתרונות של אזוריזציה בכל פריסה.

השוואה מפורטת בין המיקומים הגיאוגרפיים השונים לפריסה ב-מרכז האפליקציות זמינה במאמר בנושא אפליקציות גלובליות ואזוריות.

הפרדת סביבות לאפליקציות נפרדות

כדי לתמוך בבידוד לצורך אבטחה, הרשאות וסיכון תפעולי, מייצגים סביבות פריסה שונות, כמו פיתוח, Staging וייצור, כאפליקציות נפרדות. לדוגמה, אפשר ליצור את המבנה הבא של האפליקציות: my-app-dev, my-app-staging ו-my-app-prod.

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

התאמת הגבולות של ניהול האפליקציות למבנה הצוותים

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

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

מעקב אחרי מחזור החיים של האפליקציה

שילוב של מרכז האפליקציות עם Application Design Center כדי ליהנות מחוויה חלקה לאורך מחזור החיים של האפליקציה:

• יש לכם משאבים קיימים שאתם רוצים לרשום באפליקציה: אתם יכולים להשתמש ב-App Hub כדי לרשום את Google Cloud המשאבים הקיימים שלכם כשירותים או כעומסי עבודה באפליקציות. השיטה הזו מאפשרת לכם לקבל במהירות תצוגה מאוחדת ושליטה תפעולית בתשתית הנוכחית שלכם. אפשר גם ליצור תבנית ב-Application Design Center מאפליקציה פעילה כדי לתקנן את הארכיטקטורה לפריסות עתידיות.
• אין לכם משאבים קיימים לרשום באפליקציה: אתם יכולים להשתמש ב-Application Design Center כדי לעצב ולפרוס אפליקציות חדשות מתבניות מנוהלות לשימוש חוזר. כשפורסים אפליקציה מתבנית של Application Design Center, הרכיבים נרשמים אוטומטית ב-מרכז האפליקציות, כך שמודל האפליקציה משקף בצורה מדויקת את העיצוב המיועד. בנוסף, Application Design Center עוזר לכם לנהל עדכונים עקביים של האפליקציות על סמך גרסאות תבניות. אם מעדכנים את התבנית, אפשר לפרוס מחדש את האפליקציה כדי להפיץ את השינויים, וכך לשמור על עקביות ועל ניהול.

שיקולים לגבי היררכיית המשאבים

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

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

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

שיפור מתמשך

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

מומלץ להשתמש בתובנות מ-Cloud Hub ומ-Gemini Cloud Assist כדי לזהות הזדמנויות לאופטימיזציה ולהתאים את האפליקציות בהתאם. אפשר להשתמש ב-Application Design Center כדי ליצור מודלים של שינויים בארכיטקטורה ולפרוס אותם, ולנהל את מחזור החיים של האפליקציות באמצעות תבניות.