המסמך הזה יעזור לכם להעריך את הדרישות של האפליקציה ולבחור בין Cloud Run לבין Google Kubernetes Engine (GKE) במצב Autopilot, על סמך שיקולים טכניים וארגוניים. המסמך מיועד ל-Cloud Architects שצריכים לבחור Google Cloud סביבת זמן ריצה של קונטיינר יעד לעומסי העבודה שלהם. אנחנו מניחים שאתם מכירים את Kubernetes ואת Google Cloud, ושיש לכם ידע מסוים בסביבות זמן ריצה בלי שרת בענן, כמו Cloud Run, פונקציות Cloud Run או AWS Lambda.
Google Cloud מציע כמה אפשרויות של סביבות זמן ריצה עם מגוון יכולות. התרשים הבא מציג את מגוון המוצרים המנוהלים: Google Cloud
בתרשים מוצגים הפריטים הבאים:
סביבות זמן ריצה מנוהלות ברובן (המיקוד של המדריך הזה):
- Cloud Run, כולל פונקציות Cloud Run.
- GKE Autopilot.
האפשרויות האלה מנוהלות על ידי Google, בלי ניהול משתמשים של תשתית מחשוב בסיסית.
סביבות זמן ריצה עם הכי פחות ניהול:
- GKE Standard, שמותאם לעומסי עבודה של ארגונים ומציע מדרגיות של אשכול יחיד עד 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, שהם אמינים וניתנים להתאמה לעומס. שניהם תומכים גם ברשתות 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 יכול לתמוך במגוון רחב של ארכיטקטורות אפליקציות, תוך יישום שיטות מומלצות שמאפשרות למפתחים להתמקד בקוד.
ב-Cloud Run אפשר גם לפרוס קוד אפליקציה מהמקורות הבאים:
- פונקציות קלות משקל נפרדות
- אפליקציות מלאות מקוד מקור
- אפליקציות בקונטיינרים
ב-Cloud Run יש יכולת ליצור ולפרוס קונטיינרים שתומכת גם ב-FaaS וגם ביצירת קונטיינרים מקוד מקור, בנוסף ליכולת להשתמש בזמן ריצה של קונטיינר שנוצר מראש. כשמשתמשים ב-Cloud Run בצורה הזו, השלבים של יצירה ופריסה של קובץ האימג' של הקונטיינר של האפליקציה שיבוצעים הם אוטומטיים לחלוטין, ולא נדרש מכם לבצע הגדרה בהתאמה אישית.
טייס אוטומטי של GKE
GKE Autopilot הוא מצב הפעולה המומלץ והמוגדר כברירת מחדל באשכולות של GKE. Autopilot מאפשר להריץ אפליקציות ב-Kubernetes בלי להשקיע משאבים בניהול התשתית. כשמשתמשים ב-Autopilot, Google מנהלת היבטים בסיסיים מרכזיים של הגדרת האשכול, כולל הקצאה של צמתים ושינוי גודל, מצב אבטחה שמוגדר כברירת מחדל והגדרות אחרות שהוגדרו מראש. כש-Autopilot מנהל את משאבי הצמתים, אתם משלמים רק על המשאבים שעומסי העבודה שלכם דורשים. Autopilot מנטר ומבצע אופטימיזציה של הקצאת משאבי התשתית באופן רציף כדי להבטיח את ההתאמה הטובה ביותר, תוך מתן SLA לעומסי העבודה.
GKE Autopilot תומך בעומסי עבודה שאולי לא מתאימים ל-Cloud Run. לדוגמה, GKE Autopilot תומך בדרך כלל בעומסי עבודה (workloads) ארוכי טווח או בעלי מצב.
בחירת סביבת זמן ריצה
באופן כללי, אם מאפייני עומס העבודה מתאימים לפלטפורמה מנוהלת, סביבת זמן הריצה ללא שרת של 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 מורכב לריבוי דיירים: תמיכה בשיתוף משאבים משותפים.
- זמן קצוב לתפוגה (timeout) מקסימלי של משימת קונטיינר: משך הביצוע של אפליקציות או רכיבים לטווח ארוך.
בקטעים הבאים מפורטים השיקולים הטכניים האלה כדי לעזור לכם לבחור סביבת זמן ריצה.
שליטה ויכולת הגדרה
בהשוואה ל-Cloud Run, GKE Autopilot מספק שליטה מפורטת יותר בסביבת ההרצה של עומסי העבודה. בהקשר של Pod, Kubernetes מספק הרבה פרימיטיבים שניתנים להגדרה, שאפשר להתאים אותם לדרישות של האפליקציה. אפשרויות ההגדרה כוללות רמת הרשאה, פרמטרים של איכות השירות, מטפלים מותאמים אישית באירועים של מחזור החיים של הקונטיינר ושיתוף של מרחב שמות של תהליכים בין כמה קונטיינרים.
Cloud Run תומך ישירות בקבוצת משנה של Kubernetes Pod API surface, שמתוארת בYAML לדוגמה לאובייקט Cloud Run Service ובYAML לדוגמה לאובייקט Cloud Run Job. מדריכי העיון האלה יכולים לעזור לכם להעריך את שתי הפלטפורמות בהתאם לדרישות של האפליקציה שלכם.
הסכם הקונטיינר לסביבת ההרצה של Cloud Run הוא פשוט יחסית ומתאים לרוב עומסי העבודה של ההגשה. עם זאת, בחוזה מפורטות כמה דרישות שצריך לעמוד בהן. אם האפליקציה או התלות שלה לא עומדות בדרישות האלה, או אם אתם צריכים שליטה מדויקת יותר בסביבת ההפעלה, יכול להיות ש-Autopilot יתאים לכם יותר.
אם אתם רוצים לצמצם את הזמן שאתם משקיעים בהגדרה ובניהול, כדאי לבחור ב-Cloud Run כסביבת זמן הריצה. ל-Cloud Run יש פחות אפשרויות הגדרה מאשר ל-Autopilot, ולכן הוא יכול לעזור לכם למקסם את הפרודוקטיביות של המפתחים ולצמצם את התקורה התפעולית.
ניהול וניתוב של תנועה ברשת
גם Cloud Run וגם GKE Autopilot משתלבים עם Cloud Load Balancing. עם זאת, GKE Autopilot מספק בנוסף קבוצה עשירה ורבת עוצמה של פרימיטיבים להגדרת סביבת הרשת לתקשורת בין שירותים. אפשרויות ההגדרה כוללות הרשאות גרנולריות והפרדה בשכבת הרשת באמצעות מרחבי שמות ומדיניות רשת, מיפוי מחדש של יציאות וגילוי שירותי DNS מובנה בתוך האשכול. GKE Autopilot תומך גם ב-Gateway API, שהוא גמיש וניתן להגדרה במידה רבה. הפונקציונליות הזו מספקת שליטה רבה באופן שבו התנועה מנותבת אל השירותים באשכול וביניהם.
מכיוון שאפשר להגדיר את Autopilot בצורה מפורטת, הוא יכול להיות האפשרות הכי טובה אם יש לכם כמה שירותים עם תלות גבוהה ברשת, או דרישות מורכבות לגבי אופן ניתוב התנועה בין רכיבי האפליקציה. דוגמה לדפוס כזה היא אפליקציה מבוזרת שמפורקת למיקרו-שירותים רבים עם דפוסי תלות מורכבים. בתרחישים כאלה, אפשרויות ההגדרה של Autopilot יכולות לעזור לכם לנהל ולשלוט באינטראקציות בין השירותים.
הרחבת היקף השימוש בצורה אופקית ואנכית
Cloud Run ו-GKE Autopilot תומכים בהרחבה אופקית ידנית ואוטומטית של שירותים ועבודות. הרחבה אופקית מספקת יותר כוח עיבוד כשצריך, ומסירה את כוח העיבוד הנוסף כשלא צריך אותו. בעומס עבודה טיפוסי, בדרך כלל Cloud Run יכול להתרחב מהר יותר מ-GKE Autopilot כדי להגיב לעליות חדות במספר הבקשות לשנייה. לדוגמה, בסרטון ההדגמה "מה חדש ב-Serverless Compute?" רואים את Cloud Run מתרחב מאפס ליותר מ-10,000 מופעים בכ-10 שניות. כדי להגדיל את מהירות ההרחבה האופקית ב-Kubernetes (בתוספת עלות), ב-Autopilot אפשר להקצות קיבולת מחשוב נוספת.
אם אי אפשר להרחיב את האפליקציה על ידי הוספת מופעים כדי להגדיל את רמת המשאבים הזמינים, יכול להיות ש-Autopilot תתאים יותר. Autopilot תומך בשינוי גודל אנכי כדי לשנות באופן דינמי את כמות כוח העיבוד שזמין בלי להגדיל את מספר המופעים הפועלים של האפליקציה.
Cloud Run יכול להקטין את מספר הרפליקות של האפליקציות שלכם לאפס באופן אוטומטי כשהן לא בשימוש. זה שימושי במקרים מסוימים שבהם יש דגש מיוחד על אופטימיזציה של העלויות. בגלל המאפיינים של האופן שבו האפליקציות שלכם יכולות להתרחב לאפס, יש מספר שלבים לאופטימיזציה שתוכלו לבצע כדי לצמצם את הזמן שחולף בין קבלת הבקשה לבין הזמן שבו האפליקציה שלכם פועלת ויכולה לטפל בבקשה.
תמיכה באפליקציות עם שמירת מצב
Autopilot מציע תמיכה מלאה בנפח אחסון של Kubernetes, שמגובה על ידי Persistent Disks שמאפשרים להריץ מגוון רחב של פריסות עם שמירת מצב, כולל מסדי נתונים בניהול עצמי. גם Cloud Run וגם GKE Autopilot מאפשרים להתחבר לשירותים אחרים כמו Filestore וקטגוריות של Cloud Storage. בנוסף, שניהם כוללים את האפשרות לטעון קטגוריות של אחסון אובייקטים למערכת הקבצים באמצעות Cloud Storage FUSE.
Cloud Run משתמש במערכת קבצים בזיכרון, ולכן יכול להיות שהוא לא מתאים לאפליקציות שדורשות מערכת קבצים מקומית קבועה. בנוסף, מערכת הקבצים המקומית בזיכרון משותפת עם הזיכרון של האפליקציה. לכן, גם מערכת הקבצים הזמנית וגם השימוש בזיכרון של האפליקציה והקונטיינר תורמים למיצוי מגבלת הזיכרון. כדי להימנע מהבעיה הזו, אפשר להשתמש בנפח אחסון ייעודי בזיכרון עם מגבלת גודל.
למאגר של שירות או משימה ב-Cloud Run יש זמן קצוב לתפוגה של משימה. אפשר לתזמן מחדש מאגר שפועל בתוך Pod באשכול Autopilot, בכפוף לאילוצים שהוגדרו באמצעות Pod Disruption Budgets (PDBs). עם זאת, פודים יכולים לפעול עד שבעה ימים כשהם מוגנים מפני הוצאה שנגרמת משדרוגים אוטומטיים של צמתים או מאירועים של הקטנת קנה מידה. בדרך כלל, הזמן הקצוב לתפוגה של משימה הוא שיקול חשוב יותר לעומסי עבודה של אצווה ב-Cloud Run. לעומסי עבודה לטווח ארוך ולמשימות אצווה שלא ניתן להשלים בתוך משך הזמן המקסימלי של המשימה, יכול להיות ש-Autopilot היא האפשרות הטובה ביותר.
ארכיטקטורת המעבד (CPU)
כל פלטפורמות המחשוב תומכות בארכיטקטורת מעבד x86. Cloud Run לא תומך במעבדים עם ארכיטקטורת Arm, אבל Autopilot תומך בצמתים מנוהלים שמגובים על ידי ארכיטקטורת Arm. אם עומס העבודה שלכם דורש ארכיטקטורת Arm, תצטרכו להשתמש ב-Autopilot. Google Cloud
הפחתת עומס מאיץ
Autopilot תומך בשימוש ב-GPU ובשימוש ב-TPU, כולל היכולת לצרוך משאבים שמורים.Cloud Run תומך בשימוש ב-GPU עם כמה מגבלות.
דרישות גבוהות של זיכרון, מעבד (CPU) ומשאבים אחרים
בהשוואה למגבלות על בקשות למשאבים ב-GKE Autopilot, המשאבים המקסימליים של מעבד וזיכרון שאפשר לצרוך על ידי שירות או משימה יחידים ב-Cloud Run (מופע יחיד) הם מוגבלים. בהתאם למאפיינים של עומסי העבודה, יכול להיות שיש ב-Cloud Run מגבלות אחרות שמצמצמות את המשאבים שזמינים. לדוגמה, יכול להיות שזמן קצוב לתפוגה של ההפעלה והמספר המקסימלי של חיבורים יוצאים מוגבלים ב-Cloud Run. ב-Autopilot, יכול להיות שחלק מהמגבלות לא יחולו או שהערכים המותרים שלהן יהיו גבוהים יותר.
תלות מפורשת ב-Kubernetes
יכול להיות שלחלק מהאפליקציות, הספריות או המסגרות יש תלות מפורשת ב-Kubernetes. יכול להיות שהתלות ב-Kubernetes נובעת מאחת מהסיבות הבאות:
- הדרישות של האפליקציה (לדוגמה, האפליקציה קוראת לממשקי Kubernetes API או משתמשת במשאבים מותאמים אישית של Kubernetes).
- הדרישות של כלי הפיתוח שמשמש להגדרת האפליקציה או לפריסתה (כמו Helm).
- דרישות התמיכה של יוצר או ספק צד שלישי.
בתרחישים האלה, סביבת זמן הריצה של Autopilot היא סביבת היעד, כי Cloud Run לא תומך ב-Kubernetes.
RBAC מורכב לריבוי דיירים
אם לארגון שלכם יש מבנים ארגוניים מורכבים במיוחד או דרישות לריבוי דיירים, כדאי להשתמש ב-Autopilot כדי לנצל את הבקרת הגישה לפי תפקידים (RBAC) של Kubernetes. אם אתם מחפשים אפשרות פשוטה יותר, אתם יכולים להשתמש ביכולות האבטחה וההפרדה שמובנות ב-Cloud Run.
שיקולים ארגוניים
אלה כמה שיקולים ארגוניים שישפיעו על הבחירה שלכם בסביבה:
- אסטרטגיה טכנית רחבה: הכיוון הטכני של הארגון.
- מינוף הסביבה העסקית של Kubernetes: התעניינות במינוף קהילת ה-OSS.
- כלים קיימים בתוך הארגון: שימוש בכלים מסוימים.
- פרופילים של צוותי פיתוח: מערכי מיומנויות וניסיון של מפתחים.
- תמיכה תפעולית: היכולות וההתמקדות של צוותי התפעול.
בקטעים הבאים מפורטים השיקולים הארגוניים האלה כדי לעזור לכם לבחור סביבה.
אסטרטגיה טכנית רחבה
יכול להיות שארגונים או צוותים סיכמו על אסטרטגיות מסוימות להעדפת טכנולוגיות מסוימות על פני אחרות. לדוגמה, אם צוות מסוים הסכים לתקנן, במידת האפשר, את השימוש ב-serverless או ב-Kubernetes, יכול להיות שההסכם הזה ישפיע על סביבת זמן הריצה המיועדת או אפילו יכתיב אותה.
אם עומס עבודה מסוים לא מתאים לסביבת זמן הריצה שצוינה בשיטה, אפשר לבצע אחת או יותר מהפעולות הבאות, עם האזהרות הנלוות:
- שינוי הארכיטקטורה של עומס העבודה. עם זאת, אם עומס העבודה לא מתאים, יכול להיות שהביצועים, העלות, האבטחה או מאפיינים אחרים לא יהיו אופטימליים.
- רישום עומס העבודה כחריגה מהכיוון האסטרטגי. עם זאת, שימוש יתר בחריגים עלול להוביל לתיק טכנולוגיות מגוון מדי.
- כדאי לשקול מחדש את האסטרטגיה. עם זאת, פעולה כזו עלולה לגרום לתקורה של מדיניות, שיכולה לעכב או לחסום את ההתקדמות.
שימוש במערכת האקולוגית של 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, או בשניהם. כדאי להיעזר בשיקולים הטכניים והארגוניים שמופיעים במסמך הזה כדי להנחות את השיחה ולהעריך את מידת ההתאמה של האפליקציה לכל אחת מהפלטפורמות הפוטנציאליות.
מומלץ לתזמן פגישה אחרי כמה חודשים כדי לאשר את ההחלטה או לבדוק אותה מחדש על סמך התוצאות של פריסת האפליקציה בסביבה החדשה.
המאמרים הבאים
- מידע נוסף על סביבות זמן הריצה האלה זמין במאמר GKE Autopilot Qwik Start ובמאמר Cloud Run lab.
- מידע נוסף על העברה מ-Cloud Run ל-GKE ומ-Kubernetes ל-Cloud Run
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: Henry Bell | אדריכל פתרונות ענן
תורמי תוכן אחרים:
- Marco Ferrari | Cloud Solutions Architect
- גארי סינג | מנהל מוצר יוצא
- מרידי (ראג'ו) מקאראג'ו | מוביל טכני בנושא תמיכה
- Parag Doshi | Key Enterprise Architect
- Daniel Stamer | Customer Engineer, Digital Natives
- סטארן ג'יאניני | מנהל קבוצת מוצרים
- ויקטור סזלווי | מנהל מוצר בכיר
- ויליאם דניס | מנהל קבוצת מוצרים