במאמר הזה אנחנו עוזרים לכם להעריך את הדרישות של האפליקציה ולבחור בין Cloud Run לבין Google Kubernetes Engine (GKE) במצב Autopilot, על סמך שיקולים טכניים וארגוניים. המסמך הזה מיועד לארכיטקטים של ענן שצריכים לבחור Google Cloud סביבת זמן ריצה של קונטיינר יעד Google Cloud עבור עומסי העבודה שלהם. אנחנו מניחים שאתם מכירים את Kubernetes ואת Google Cloud, ושיש לכם ידע מסוים בסביבות זמן ריצה בענן בלי שרת (serverless), כמו 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) ארוכי טווח או בעלי מצב.
בחירת סביבת זמן ריצה
באופן כללי, אם המאפיינים של עומס העבודה מתאימים לפלטפורמה מנוהלת, סביבת זמן הריצה ללא שרת (serverless) של Cloud Run היא הפתרון האידיאלי. השימוש ב-Cloud Run יכול להוביל לצורך בניהול פחות תשתיות, פחות הגדרות בניהול עצמי ולכן גם להוצאות תפעול נמוכות יותר. אלא אם אתם רוצים או צריכים Kubernetes באופן ספציפי, מומלץ לשקול קודם סביבת זמן ריצה בלי שרת (serverless) כסביבת היעד. למרות ש-Kubernetes מספק הפשטה עוצמתית של פלטפורמה פתוחה, השימוש בו מוסיף מורכבות. אם אתם לא צריכים את Kubernetes, מומלץ לבדוק אם האפליקציה שלכם מתאימה לשימוש בשרתים וירטואליים. אם יש קריטריונים שמצביעים על כך שעומס העבודה שלכם פחות מתאים לשימוש בשרתים וירטואליים, מומלץ להשתמש ב-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 מספקת הרבה פרימיטיבים שניתנים להגדרה שאפשר לשנות כדי לעמוד בדרישות של האפליקציה. אפשרויות ההגדרה כוללות רמת הרשאה, פרמטרים של איכות השירות, מטפלים מותאמים אישית באירועים של מחזור החיים של מאגר התגים ושיתוף של מרחב שמות של תהליך בין כמה מאגרי תגים.
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 משולבים עם Google Cloud Load Balancing. עם זאת, במצב Autopilot ב-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, שמגובה על ידי Persistent Disks שמאפשרים לכם להריץ מגוון רחב של פריסות עם שמירת מצב, כולל מסדי נתונים בניהול עצמי. גם Cloud Run וגם GKE Autopilot מאפשרים להתחבר לשירותים אחרים כמו Filestore וקטגוריות של Cloud Storage. שתי האפשרויות כוללות גם את היכולת לטעון קטגוריות של חנות אובייקטים למערכת הקבצים באמצעות Cloud Storage FUSE.
Cloud Run משתמש במערכת קבצים בזיכרון, ולכן יכול להיות שהוא לא מתאים לאפליקציות שדורשות מערכת קבצים מקומית קבועה. בנוסף, מערכת הקבצים המקומית בזיכרון משותפת עם הזיכרון של האפליקציה. לכן, גם מערכת הקבצים הזמנית וגם השימוש בזיכרון של האפליקציה והקונטיינר תורמים למיצוי מגבלת הזיכרון. כדי להימנע מהבעיה הזו, אפשר להשתמש בנפח אחסון ייעודי בזיכרון עם מגבלת גודל.
לכל קונטיינר של שירות או משימה ב-Cloud Run יש זמן קצוב לתפוגה של משימה. אפשר לתזמן מחדש קונטיינר שפועל בתוך Pod באשכול Autopilot, בכפוף למגבלות שהוגדרו באמצעות Pod Disruption Budgets (PDBs). עם זאת, פודים יכולים לפעול עד שבעה ימים אם הם מוגנים מפני הוצאה שנגרמת משדרוגים אוטומטיים של צמתים או מאירועים של הקטנת קנה מידה. בדרך כלל, סביר יותר שצריך להתייחס לפסק זמן של משימה בעומסי עבודה של אצווה ב-Cloud Run. עבור עומסי עבודה לטווח ארוך ומשימות אצווה שלא ניתן להשלים בתוך משך הזמן המקסימלי של המשימה, יכול להיות שאוטופילוט היא האפשרות הכי טובה.
ארכיטקטורת המעבד (CPU)
כל פלטפורמות Google Cloud החישוב תומכות בארכיטקטורת מעבד x86. Cloud Run לא תומך במעבדים עם ארכיטקטורת Arm, אבל Autopilot תומך בצמתים מנוהלים שמגובים על ידי ארכיטקטורת Arm. אם עומס העבודה שלכם דורש ארכיטקטורת Arm, תצטרכו להשתמש ב-Autopilot.
העברת נתונים למאיץ
Autopilot תומך בשימוש במעבדי GPU ובשימוש במעבדי TPU, כולל האפשרות להשתמש במשאבים שמורים. Cloud Run תומך בשימוש ביחידות GPU עם כמה הגבלות.
דרישות גבוהות של זיכרון, מעבד (CPU) ומשאבים אחרים
בהשוואה למגבלות על בקשות למשאבים ב-GKE Autopilot, המשאבים המקסימליים של CPU וזיכרון ששירות או משימה ב-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.
- כלים קיימים בתוך הארגון: שימוש בכלים מסוימים.
- פרופילים של צוותי פיתוח: מערכי מיומנויות וניסיון של מפתחים.
- תמיכה תפעולית: היכולות וההתמקדות של צוותי התפעול.
בקטעים הבאים מפורטים השיקולים הארגוניים האלה כדי לעזור לכם לבחור סביבה.
אסטרטגיה טכנית רחבה
יכול להיות שארגונים או צוותים סיכמו על אסטרטגיות מסוימות להעדפת טכנולוגיות מסוימות על פני אחרות. לדוגמה, אם צוות מסוים הסכים להשתמש ב-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
- גארי סינג | מנהל מוצר (Outbound)
- מרידי (ראג'ו) מקאראג'ו | מוביל טכני בנושא תמיכה
- Parag Doshi | Key Enterprise Architect
- Daniel Stamer | Customer Engineer, Digital Natives
- סטארן ג'יאניני | מנהל קבוצת מוצרים
- ויקטור סלבי | מנהל מוצר בכיר
- ויליאם דניס | מנהל קבוצת מוצרים