בחירת סביבת זמן ריצה מנוהלת של קונטיינר

Last reviewed 2024-08-30 UTC

המסמך הזה יעזור לכם להעריך את הדרישות של האפליקציה ולבחור בין Cloud Run לבין Google Kubernetes Engine (GKE) Autopilot, על סמך שיקולים טכניים וארגוניים. המסמך הזה מיועד לאדריכלי ענן שצריכים לבחור סביבת זמן ריצה של קונטיינר יעד לעומסי העבודה שלהם ב- Google Cloud . ההנחה היא שאתם מכירים את Kubernetes ואת Google Cloud, ויש לכם ידע מסוים בסביבות זמן ריצה ללא שרת (serverless) בענן, כמו Cloud Run, פונקציות Cloud Run או AWS Lambda.

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

‫Google Cloud מהמנוהל ביותר ועד להכי פחות מנוהל.

בתרשים מוצגים הפריטים הבאים:

  • סביבות זמן ריצה בניהול מלא (הנושא של המדריך הזה):

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

  • סביבות זמן ריצה בניהול מינימלי:

    • ‫GKE Standard, שמותאם לעומסי עבודה ארגוניים ומציע יכולת התאמה לעומס (scalability) של אשכול יחיד עד 65,000 צמתים.
    • ‫Compute Engine, שכולל את סדרת המכונות הווירטואליות A3 שמותאמות לצריכת מעבד גבוהה, לעומסי עבודה של למידת מכונה (ML) ומחשוב עתיר ביצועים (HPC).

    האפשרויות האלה דורשות מידה מסוימת של ניהול תשתית ברמת המשתמש, כמו המכונות הווירטואליות (VM) שעומדות בבסיס יכולות המחשוב. המכונות הווירטואליות ב-GKE Standard הן הצמתים של אשכול Kubernetes. המכונות הווירטואליות ב-Compute Engine הן המוצר העיקרי של הפלטפורמה, ואפשר להתאים אותן אישית לפי הדרישות שלכם.

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

סקירה כללית של סביבות

בקטע הזה מופיעה סקירה כללית על היכולות של Cloud Run ושל GKE Autopilot. גם Cloud Run וגם GKE Autopilot משולבים באופן הדוק ב- Google Cloud, כך שיש הרבה דברים משותפים בין שניהם. שתי הפלטפורמות תומכות בכמה אפשרויות לאיזון עומסים באמצעות שירותי איזון העומסים של Google, שהם אמינים וניתנים להתאמה לעומס (scaling). שניהם גם תומכים ברשתות VPC, ב-Identity-Aware Proxy ‏(IAP) וב-Google Cloud Armor, למקרים שבהם נדרשת רשת פרטית מפורטת יותר. בשתי הפלטפורמות אתם משלמים רק על המשאבים שאתם משתמשים בהם בפועל באפליקציות שלכם.

מבחינת הכנת תוכנה להפצה, סביבות זמן הריצה של קונטיינרים ב-Cloud Run וב-GKE Autopilot נתמכות על ידי שירותים שמרכיבים את Google Cloud המערכת האקולוגית של הקונטיינרים. השירותים האלה כוללים את Cloud Build,‏ Artifact Registry,‏ Binary Authorization ופיתוח רציף (CD) באמצעות Cloud Deploy, כדי לוודא שהאפליקציות שלכם נפרסות בסביבת הייצור בצורה בטוחה ואמינה. כלומר, אתם והצוותים שלכם אחראים על ההחלטות לגבי ה-build והפריסה.

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

Cloud Run

‫Cloud Run היא פלטפורמת מחשוב מנוהלת בלי שרת (serverless), שמאפשרת להריץ אפליקציות ישירות בתשתית של Google שניתנת להתאמה לעומס. ב-Cloud Run יש אוטומציה והתאמה לעומס (scaling) לשני סוגים עיקריים של אפליקציות:

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

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

  • פונקציות קטנות ועצמאיות
  • אפליקציות מלאות מקוד מקור
  • אפליקציות בקונטיינרים

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

‫GKE Autopilot

‫GKE Autopilot הוא מצב הפעולה המומלץ של אשכולות ב-GKE, והוא מוגדר כברירת מחדל. באמצעות Autopilot אתם יכולים להריץ אפליקציות ב-Kubernetes בלי לנהל את התשתית. כשמשתמשים ב-Autopilot, ‏Google מנהלת היבטים בסיסיים חשובים של הגדרת האשכול, כולל הקצאת צמתים והתאמה לעומס, מצב אבטחה שמוגדר כברירת מחדל והגדרות אחרות שנקבעו מראש. במצב Autopilot, שבו המשאבים של הצמתים מנוהלים, אתם משלמים רק על המשאבים שעומסי העבודה שלכם מבקשים. במצב Autopilot, המערכת עוקבת אחרי הקצאת המשאבים לתשתית ומבצעת אופטימיזציה שלהם באופן רציף כדי לוודא שהם מתאימים בצורה הטובה ביותר, תוך מתן הסכם SLA לעומסי העבודה שלכם.

ב-GKE Autopilot יש תמיכה בעומסי עבודה שלא מתאימים ל-Cloud Run. לדוגמה, GKE Autopilot תומך בדרך כלל בעומסי עבודה (workloads) עם שמירת מצב (stateful) או לטווח ארוך.

בחירת סביבת זמן ריצה

באופן כללי, אם המאפיינים של עומס העבודה מתאימים לפלטפורמה מנוהלת, סביבת זמן הריצה ללא שרת (serverless) של Cloud Run היא אידיאלית. כשמשתמשים ב-Cloud Run, יש פחות תשתית לנהל, פחות הגדרות לניהול עצמי, וכתוצאה מכך פחות תקורה תפעולית. אם אתם לא צריכים או רוצים להשתמש ב-Kubernetes, מומלץ לשקול קודם את סביבת זמן הריצה ללא שרת (serverless) כסביבת היעד. למרות ש-Kubernetes מספק את ההפשטה העוצמתית של פלטפורמה פתוחה, השימוש בו מוסיף מורכבות. אם אתם לא צריכים את Kubernetes, כדאי לבדוק אם האפליקציה מתאימה ללא שרת (serverless). אם יש קריטריונים שבגללם עומס העבודה פחות מתאים ל-serverless, מומלץ להשתמש ב-Autopilot.

בקטעים הבאים מפורטים כמה מהקריטריונים שיכולים לעזור לכם לענות על השאלות האלה, במיוחד על השאלה אם עומס העבודה מתאים ללא שרת. בהתחשב במשותף בין Autopilot ל-Cloud Run, כפי שמתואר בסעיפים הקודמים, המעבר בין הפלטפורמות הוא משימה פשוטה כשאין חסימות טכניות או אחרות. למידע נוסף על אפשרויות ההעברה, קראו את המאמרים העברה מ-Cloud Run ל-GKE והעברה מ-Kubernetes ל-Cloud Run.

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

שיקולים טכניים

הנה כמה מהשיקולים הטכניים שישפיעו על בחירת הפלטפורמה:

  • שליטה ויכולת הגדרה: רמת הפירוט של השליטה בסביבת ההפעלה.
  • ניהול וניתוב של תנועה ברשת: יכולת ההגדרה של אינטראקציות ברשת.
  • יכולת התאמה לעומס אופקית ואנכית: תמיכה בהגדלה ובהקטנה דינמית של הקיבולת.
  • תמיכה באפליקציות עם שמירת מצב: יכולות לאחסון מצב קבוע.
  • ארכיטקטורת המעבד (CPU): תמיכה בסוגי מעבדים שונים.
  • העברת עומס למאיצים (מעבדי GPU ו-TPU): היכולת להעביר את עומס החישוב לחומרה ייעודית.
  • צריכה גבוהה של זיכרון, מעבד (CPU) ומשאבים אחרים: רמת הצריכה של משאבים שונים.
  • תלות מפורשת ב-Kubernetes: דרישות לשימוש ב-Kubernetes API.
  • בקרת גישה מורכבת מבוססת-תפקידים (RBAC) לדיירים מרובים: תמיכה בשיתוף משאבים מאוחדים.
  • זמן קצוב מקסימלי למשימות בקונטיינר: משך ההפעלה של אפליקציות או רכיבים שפועלים לאורך זמן.

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

שליטה והגדרות אישיות

בהשוואה ל-Cloud Run, ‏ GKE Autopilot מספק שליטה מפורטת יותר בסביבת ההפעלה של עומסי העבודה. בהקשר של Pod, ‏Kubernetes מספק הרבה פרימיטיבים שניתנים להגדרה, שאפשר להתאים לדרישות של האפליקציה. אפשרויות ההגדרה כוללות רמת הרשאה, פרמטרים של איכות השירות, רכיבי handler מותאמים אישית לאירועים במחזור החיים של מאגר התגים ושיתוף מרחב השמות של התהליך בין כמה מאגרי תגים.

ב-Cloud Run יש תמיכה ישירה בקבוצת משנה של ממשק ה-API של Kubernetes Pod, שמתואר בקובץ ה-YAML לדוגמה של אובייקט השירות של Cloud Run ובקובץ ה-YAML לדוגמה של אובייקט המשימה של Cloud Run. המדריכים האלה יכולים לעזור לכם להעריך את שתי הפלטפורמות בהתאם לדרישות של האפליקציה.

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

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

ניהול וניתוב של תנועה ברשת

גם Cloud Run וגם GKE Autopilot משתלבים עם Google Cloud Load Balancing. עם זאת, GKE Autopilot מספק גם קבוצה עשירה ורבת-עוצמה של פרימיטיבים להגדרת סביבת הרשת לתקשורת בין שירותים. אפשרויות ההגדרה כוללות הרשאות מפורטות והפרדה בשכבת הרשת באמצעות מרחבי שמות ומדיניות רשת ב-Kubernetes, מיפוי מחדש של יציאות וזיהוי שירותים מובנה של DNS בתוך האשכול. ב-GKE Autopilot יש גם תמיכה ב-Gateway API, שהוא גמיש וניתן להגדרה בקלות. הפונקציונליות הזו מספקת שליטה רבה על האופן שבו התנועה מנותבת אל השירותים באשכול וביניהם.

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

מדרגיות אופקית ואנכית

גם Cloud Run וגם GKE Autopilot תומכים בהתאמה ידנית ואוטומטית של קנה המידה לרוחב בשירותים ובמשימות. התאמה אופקית של קנה המידה מספקת כוח עיבוד מוגבר כשצריך, ומסירה את כוח העיבוד הנוסף כשלא צריך אותו. בעומס עבודה אופייני, בדרך כלל Cloud Run יכול להרחיב אופקית בהתאם לעומס (scale out) מהר יותר מאשר GKE Autopilot, כדי להגיב לעליות חדות במספר הבקשות לשנייה. לדוגמה, הסרטון What's New in Serverless Compute?‎ מראה את Cloud Run כשהוא משתנה מאפס ליותר מ-10,000 מכונות תוך כ-10 שניות. כדי להגדיל את המהירות של התאמה אופקית לעומס (horizontal scaling) ב-Kubernetes (בתוספת תשלום), ב-Autopilot אפשר להקצות קיבולת מחשוב נוספת.

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

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

תמיכה באפליקציות עם שמירת מצב (stateful)

ב-Autopilot יש תמיכה מלאה ב-Kubernetes Volume, שמגובה ב-Persistent Disks ומאפשרת להריץ מגוון רחב של פריסות עם שמירת מצב (stateful), כולל מסדי נתונים בניהול עצמי. גם ב-Cloud Run וגם ב-GKE Autopilot אפשר להתחבר לשירותים אחרים, כמו Filestore וקטגוריות של Cloud Storage. שניהם גם כוללים את היכולת לטעון קטגוריות של מאגר אובייקטים למערכת הקבצים באמצעות Cloud Storage FUSE.

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

לקונטיינר של שירות או משימה ב-Cloud Run יש זמן קצוב מקסימלי לתפוגה של משימה. אפשר לתזמן מחדש קונטיינר שפועל בתוך pod באשכול Autopilot, בכפוף למגבלות שמוגדרות בתקציבים לשיבוש Pod‏ (PDB). עם זאת, פודים יכולים לפעול עד שבעה ימים כשהם מוגנים מפני פינוי שנגרם כתוצאה משדרוגים אוטומטיים של צמתים או מאירועי צמצום אנכי בהתאם לעומס (scale down). בדרך כלל, זמן קצוב לתפוגה של משימה הוא שיקול שרלוונטי יותר לעומסי עבודה באצווה ב-Cloud Run. יכול להיות ש-Autopilot היא האפשרות הכי טובה לעומסי עבודה ארוכי-טווח ולמשימות באצווה שאי אפשר להשלים במסגרת משך הזמן המקסימלי למשימה.

ארכיטקטורת המעבד (CPU)

כל פלטפורמות המחשוב של Google Cloud תומכות בארכיטקטורת מעבד (CPU) מסוג x86. ב-Cloud Run אין תמיכה במעבדים בארכיטקטורת Arm, אבל ב-Autopilot יש תמיכה בצמתים מנוהלים שמגובים בארכיטקטורת Arm. אם עומס העבודה שלכם דורש ארכיטקטורת Arm, תצטרכו להשתמש ב-Autopilot.

הפחתת עומס באמצעות מאיץ

ב-Autopilot אפשר להשתמש במעבדי GPU ובמעבדי TPU, כולל במשאבים שמורים. ב-Cloud Run אפשר להשתמש ביחידות GPU, עם כמה מגבלות.

דרישות גבוהות של זיכרון, מעבד (CPU) ומשאבים אחרים

בהשוואה למגבלות על בקשות למשאבים ב-GKE Autopilot, המשאבים המקסימליים של מעבד וזיכרון שיכולים לשמש שירות או משימה בודדים ב-Cloud Run (מופע בודד) הם מוגבלים. בהתאם למאפיינים של עומסי העבודה, יכול להיות שיהיו ב-Cloud Run מגבלות אחרות על המשאבים הזמינים. לדוגמה, יכול להיות שזמן הקצוב לתפוגה של ההפעלה ומספר החיבורים היוצאים המקסימלי יהיו מוגבלים ב-Cloud Run. ב-Autopilot, יכול להיות שחלק מהמגבלות לא יחולו או שיהיו להן ערכים מותרים גבוהים יותר.

תלות מפורשת ב-Kubernetes

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

  1. הדרישות של האפליקציה (לדוגמה, האפליקציה קוראת לממשקי API של Kubernetes או משתמשת במשאבים בהתאמה אישית של Kubernetes).
  2. הדרישות של הכלים שמשמשים להגדרה או לפריסה של האפליקציה (כמו Helm).
  3. דרישות התמיכה של יוצר או ספק מצד שלישי.

בתרחישים כאלה, Autopilot היא סביבת זמן הריצה המטורגטת כי Cloud Run לא תומך ב-Kubernetes.

RBAC מורכב לריבוי דיירים

אם לארגון שלכם יש מבנים ארגוניים מורכבים במיוחד או דרישות לדיירים מרובים, כדאי להשתמש ב-Autopilot כדי שתוכלו לנצל את היתרונות של בקרת גישה מבוססת-תפקידים (RBAC) של Kubernetes. כדי לפשט את התהליך, אתם יכולים להשתמש ביכולות האבטחה וההפרדה שמובנות ב-Cloud Run.

שיקולים ארגוניים

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

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

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

אסטרטגיה טכנית רחבה

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

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

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

שימוש בסביבה העסקית של Kubernetes

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

כלי פיתוח פנימיים קיימים

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

פרופילים של צוותי פיתוח

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

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

תמיכה תפעולית

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

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

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

בחירה

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

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

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

המאמרים הבאים

שותפים ביצירת התוכן

מחבר: הנרי בל | אדריכל פתרונות ענן

תורמים אחרים: