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

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

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

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

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

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

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

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

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

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

  ב-App Hub, אתם יכולים להגדיר מאפיינים עיקריים כמו:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לוודא שההגדרה של App Hub ו-Application Design Center ניתנת להתאמה, ניתנת לניהול ותואמת לשיטות התפעוליות שלכם, כדאי לפעול לפי האסטרטגיות הבאות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שיפור מתמשך

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

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