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

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, בלי ניהול משתמשים של תשתית מחשוב בסיסית.

  • סביבות זמן ריצה עם הכי פחות ניהול:

    האפשרויות האלה דורשות ניהול תשתית ברמת המשתמש, כמו המכונות הווירטואליות (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, שהם אמינים וניתנים להתאמה לעומס. שניהם תומכים גם ברשתות VPC, ב-Identity-Aware Proxy‏ (IAP) וב-Google Cloud Armor, אם נדרשת רשת פרטית עם רמת גרנולריות גבוהה יותר. בשתי הפלטפורמות התשלום הוא רק על המשאבים המדויקים שבהם אתם משתמשים באפליקציות.

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

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

Cloud Run

‫Cloud Run היא פלטפורמת מחשוב מנוהלת ללא שרת שמאפשרת להריץ את האפליקציות ישירות על גבי התשתית הניתנת להתאמה לעומס של Google. ‫Cloud Run מספק אוטומציה והתאמת קנה מידה לשני סוגים עיקריים של אפליקציות:

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

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

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

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

GKE Autopilot

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

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

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

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

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

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

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

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

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

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

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

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

‫Cloud Run תומך ישירות בחלק מממשק Kubernetes Pod API, שמתואר בYAML להפניה לאובייקט Cloud Run Service ובYAML להפניה לאובייקט Cloud Run Job. מדריכי העיון האלה יכולים לעזור לכם להעריך את שתי הפלטפורמות בהתאם לדרישות האפליקציה שלכם.

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

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

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

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

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

הרחבת היקף השימוש בצורה אופקית ואנכית

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

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

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

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

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

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

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

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

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

הפחתת עומס ב-Accelerator

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

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

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

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

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

  1. הדרישות של האפליקציה (לדוגמה, האפליקציה קוראת לממשקי Kubernetes API או משתמשת במשאבים מותאמים אישית של 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, צוות מרכזי של תפעול או הנדסת פלטפורמה יכול לטפל בשדרוגים של Kubernetes במצב Autopilot. השדרוגים מתבצעים באופן אוטומטי, אבל בדרך כלל צוות התפעול עוקב אחריהם כדי לוודא שיהיו כמה שפחות שיבושים בעומסי העבודה. יש ארגונים שבוחרים לשדרג ידנית את הגרסאות של מישור הבקרה. ‫GKE כולל גם יכולות שמפשטות את הניהול של אפליקציות בכמה אשכולות.

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

בחירה

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

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

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

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

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

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

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