נתיב מודרניזציה לאפליקציות ‎ .NET ב-Google Cloud

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

המאמר הזה מיועד למומחי Cloud Architect, לאדמינים של מערכות ולמנהלי טכנולוגיה (CTO) שמכירים את Windows ואת המערכת האקולוגית של ‎ .NET ורוצים ללמוד עוד על תהליך המודרניזציה. המאמר הזה מתמקד באפליקציות שרת בהתאמה אישית (כמו אפליקציות ASP.NET או Windows Services), אבל אפשר ליישם את העקרונות גם בתרחישי שימוש אחרים.

אפליקציות מדור קודם לעומת אפליקציות מודרניות: למה כדאי לעבור למודרניזציה?

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

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

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

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

אפליקציית ‎ .NET מדור קודם היא בדרך כלל מונולית שמבוססת על ‎ .NET Framework, מתארחת בשרת Microsoft Windows מקומי ומחוברת לשרת מקומי שבו פועל Microsoft SQL Server. יכול להיות שהפרטים של הארכיטקטורה שלכם יהיו שונים מהמאפיינים הכלליים האלה, אבל לרוב האפליקציות המונוליטיות יש את המגבלות הבאות:

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

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

  • שילוב עם שירותים מנוהלים מאפשר להקטין את תקורה הניהול.
  • ניידות מלאה עם ‎ .NET וקונטיינרים, ללא תלות ב-Windows או עלויות רישוי.
  • נתיב שדרוג מהיר שמבוסס על מיקרו-שירותים שאפשר לפרוס באופן עצמאי.
  • גמישות מלאה בהתאמה לעומס ולתקציב באמצעות ארכיטקטורה ללא שרת (serverless).

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

נתיב מודרניזציה

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

תהליך, טכנולוגיות ושירותים שמעורבים בתהליך המודרניזציה.

השלבים למודרניזציה מחולקים לשלושה שלבים:

  1. אירוח מחדש בענן (נקרא גם העברה והפעלה)
  2. העברה לפלטפורמה אחרת
  3. ארכיטקטורה מחודשת ובנייה מחדש

הערכה ולמידה לפני המודרניזציה

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

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

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

שלב 1: אירוח מחדש בענן

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

העברה ידנית לעומת העברה באמצעות כלי

בדרך כלל, תהליך ה-lift and shift של אפליקציות .NET מבוססות-Windows מתחיל בהעברת מופעים של Windows Server ו-SQL Server מקומיים למופעים של מכונות וירטואליות (VM) ב-Compute Engine. אפשר לבצע את התהליך הזה באופן ידני או להפוך אותו לאוטומטי בעזרת כלי להעברה.

בהעברה ידנית, אפשר להשתמש בתמונות של Windows Server ב-Compute Engine כדי להפעיל מכונות. ב-Google Cloud Marketplace יש גם פתרונות שמוכנים לפריסה ב-Compute Engine, כמו פתרון ASP.NET Framework, כדי לקבל מכונה וירטואלית של Windows Server שכוללת IIS, ‏ SQL Express ו-ASP.NET.

באופן דומה, אפשר להפעיל מופעים של SQL Server מתמונות של SQL Server, או לעבור ישירות לפתרון מנוהל יותר – Cloud SQL ל-SQL Server.

‫Google Cloud מציע גם כלי העברה כמו Migrate to Virtual Machines או VMware Engine, שיעזרו לכם להעביר מכונות וירטואליות של VMware מקומיות לסביבת VMware ב-Google Cloud.

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

אם אתם צריכים שירותי דומיין בענן, אתם יכולים לפרוס סביבת Microsoft Active Directory עמידה בכשלים ב-Compute Engine עם ענן וירטואלי פרטי (VPC), או לעבור ישירות אל שירות מנוהל ל-Microsoft Active Directory.

קישוריות מקומית וקישוריות לענן

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

הטבות ראשוניות

בסוף שלב 1, תהיה לכם תשתית בסיסית שפועלת בענן, עם יתרונות כמו:

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

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

שלב 2: מעבר לפלטפורמה חדשה

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

ניצול היתרונות של Compute Engine

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

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

חיפוש החלפות במקום

כשמעבירים את האפליקציה לענן, צריך לחפש הזדמנויות להחלפת התשתית המתארחת באפשרויות מנוהלות בענן מ-Google ומשותפים של צד שלישי ב-Cloud Marketplace, כולל האפשרויות הבאות:

  • ‫Cloud SQL במקום שרת SQL,‏ MySQL או Postgres באירוח עצמי. עם Cloud SQL אתם יכולים להתמקד בניהול מסד הנתונים במקום בניהול התשתית (למשל, תיקון מכונות וירטואליות של מסד הנתונים לצורך אבטחה או ניהול גיבויים), וליהנות מהיתרון הנוסף של ביטול הדרישה לרישיון Windows.
  • שירות מנוהל ל-Microsoft Active Directory במקום Active Directory באירוח עצמי.
  • ‫Memorystore במקום מכונות Redis באירוח עצמי.

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

שלבים ראשונים עם קונטיינרים של Windows

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

קונטיינר הוא חבילה קלילה שמכילה אפליקציה ואת כל התלויות שלה. בהשוואה להרצת האפליקציה ישירות במכונה וירטואלית, קונטיינרים מאפשרים להריץ את האפליקציות בסביבות שונות ובאופן עקבי, צפוי ויעיל יותר (במיוחד כשמריצים כמה קונטיינרים באותו מארח). המערכת האקולוגית סביב קונטיינרים (כמו Kubernetes,‏ Istio ו-Knative) מספקת גם מספר תכונות של ניהול, חוסן (resilience) ומעקב שיכולות להאיץ עוד יותר את הטרנספורמציה של האפליקציה משירות מונוליתי יחיד לקבוצה של מיקרו-שירותים (microservice) ממוקדים.

במשך תקופה מסוימת, קונטיינריזציה הייתה תכונה שזמינה רק ב-Linux. אפליקציות ל-Windows לא יכולות להפיק תועלת מקונטיינרים. המצב השתנה עם קונטיינרים של Windows והתמיכה שלהם ב-Kubernetes וב-Google Kubernetes Engine‏ (GKE).

קונטיינרים של Windows הם אפשרות טובה אם אתם לא רוצים להעביר אפליקציות של ‎ .NET Framework אל ‎ .NET, אבל עדיין רוצים ליהנות מהיתרונות של קונטיינרים (כמו גמישות, ניידות ושליטה). צריך לבחור את מערכת ההפעלה הנכונה לטירגוט בהתאם לגרסת ‎ .NET Framework, וחשוב לזכור שלא כל הערימה של Windows נתמכת במאגרי Windows. בהמשך המסמך הזה מופיע מידע על המגבלות של הגישה הזו ועל חלופות לגישה הזו במאמר .NET וקונטיינרים של Linux.

אחרי שיוצרים קונטיינר לאפליקציית ‎ .NET Framework בקונטיינר של Windows, מומלץ להריץ אותה באשכול Kubernetes. ‫Kubernetes מספק תכונות סטנדרטיות כמו זיהוי של מצב לא פעיל של Pod של קונטיינר ויצירה מחדש שלו, התאמה אוטומטית לעומס של Pod, השקות אוטומטיות או החזרה למצב קודם ובדיקות תקינות. ‫GKE מוסיף תכונות כמו שינוי גודל אוטומטי של אשכולות, אשכולות אזוריים, מישורי בקרה עם זמינות גבוהה ותמיכה היברידית ורב-עננית עם GKE Enterprise. אם תחליטו להשתמש ב-GKE או ב-GKE Enterprise, תוכלו להשתמש ב-Migrate to Containers כדי לפשט ולהאיץ את ההעברה של מכונות וירטואליות של Windows לקונטיינרים. הכלי Migrate to Containers מאפשר להפוך את האפליקציות במכונות וירטואליות לקונטיינרים באופן אוטומטי, בלי שתצטרכו לכתוב מחדש את האפליקציות או לשנות את הארכיטקטורה שלהן.

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

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

שלב 3: שינוי הארכיטקטורה ובנייה מחדש

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

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

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

למרות שצריך להוסיף קוד כדי לשלב את האפליקציה עם השירותים האלה, זה שווה את המאמץ כי אתם מעבירים את האחריות לניהול הפלטפורמה אל Google Cloud. Google Cloud ספריות לקוח של ‎.NET ו-Cloud Code ל-Visual Studio Code יכולות לעזור לכם להישאר בסביבת העבודה ובכלים של ‎ .NET בזמן שאתם משלבים את השירותים האלה.

שירותים מנוהלים יכולים גם לתמוך בפעולות של האפליקציה. אתם יכולים לאחסן את יומני האפליקציות ב-Cloud Logging ולשלוח את מדדי האפליקציות ל-Cloud Monitoring, שבו תוכלו ליצור לוחות בקרה עם מדדי שרתים ואפליקציות. Google Cloud מציעה ספריות לקוח של ‎ .NET ל-Cloud Logging, ל-Cloud Monitoring ול-Cloud Trace.

‫.NET ומאגרי Linux

אם האפליקציה שלכם היא אפליקציית .NET Framework מדור קודם שפועלת רק ב-Windows, יכול להיות שתתפתו להמשיך להפעיל אותה בשרת Windows ב-Compute Engine או בקונטיינר Windows Server ב-GKE. למרות שהגישה הזו עשויה לעבוד בטווח הקצר, היא עלולה להגביל אתכם מאוד בטווח הארוך. ל-Windows יש דמי רישוי, והשימוש במשאבים גדול יותר בהשוואה ל-Linux. הגורמים האלה יכולים להוביל לעלות בעלות כוללת גבוהה יותר לטווח הארוך.

‫‎.NET היא הגרסה המודרנית והמודולרית של ‎ .NET Framework. למרות שמיקרוסופט מתכננת לתמוך ב-‎ .NET Framework, כל התכונות החדשות יתווספו רק ל-‎ .NET (ובסופו של דבר ל-‎ .NET 5). גם אם אתם עדיין רוצים להפעיל את האפליקציה ב-Windows, כל פיתוח חדש צריך להתבצע ב-‎ .NET.

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

העברה של אפליקציות .NET Framework ל-‎ .NET

דרך טובה להתחיל לעבור ל-‎ .NET היא לקרוא את המאמר סקירה כללית של העברה מ-‎ .NET Framework ל-‎ .NET. כלים כמו .NET Portability Analyzer ו-.NET API Analyzer יכולים לעזור לכם לקבוע אם הרכיבים והממשקי ה-API ניתנים להעברה. כדאי להשתמש בכלים אחרים להעברה, כמו dotnet try-convert.

כלים חיצוניים יכולים לעזור לכם לזהות בעיות תאימות ולהחליט אילו רכיבים להעביר קודם. בסופו של דבר, תצטרכו ליצור פרויקטים של ‎ .NET, להעביר בהדרגה את הקוד של ‎ .NET Framework לפרויקט החדש ולתקן אי-תאימויות שיתגלו במהלך התהליך. לפני שמבצעים העברה של הקוד, חשוב לבצע בדיקות ואז לבדוק את הפונקציונליות אחרי ההעברה. מומלץ להשתמש בבדיקות A/B כדי לבדוק קוד ישן וקוד חדש. באמצעות בדיקות A/B, אתם יכולים להמשיך להפעיל את האפליקציה הקודמת שלכם, ובמקביל להפנות חלק מהמשתמשים לאפליקציה החדשה. הגישה הזו מאפשרת לכם לבדוק את התפוקות, את יכולת ההתאמה ואת העמידות של האפליקציה החדשה. כדי לעזור בבדיקות A/B, Google Cloud מציע פתרונות לאיזון עומסים כמו Cloud Service Mesh.

שינוי תרבותי

המעבר מ-‎ .NET Framework ומשרתי Windows ל-‎ .NET ולמאגרי Linux הוא לא רק טכני. המעבר הזה דורש שינוי תרבותי בארגון. צוותים שאולי רגילים לסביבות Windows בלבד צריכים להסתגל לסביבות מרובות פלטפורמות. השינוי התרבותי הזה דורש זמן ותקציב להדרכה ב-‎ .NET,‏ Linux ובכלי קונטיינרים כמו Docker ו-Kubernetes. עם זאת, מעבר מארגון שמשתמש רק ב-Windows לארגון שמשתמש בכמה פלטפורמות מאפשר לכם לגשת למגוון רחב יותר של כלים ומיומנויות.

פירוק של מונולית

המעבר מ-‎ .NET Framework ל-‎ .NET יכול להעלות כמה שאלות, כולל השאלות הבאות:

  • האם כדאי לכתוב מחדש את כל האפליקציה ב-‎ .NET?
  • האם אתה מפצל את האפליקציה שלך לשירותים קטנים יותר וכותב אותם ב-‎.NET?
  • האם אתה כותב רק שירותים חדשים ב-‎ .NET?

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

אפשרויות פריסה של קונטיינרים של ‎ .NET

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

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

  • מה מפעיל את האפליקציה? כל פתרונות האירוח מתאימים ל-HTTP(S) רגיל, אבל אם הפרוטוקול שלכם הוא TCP/UDP או פרוטוקול קנייני, יכול להיות ש-GKE היא האפשרות היחידה שלכם.
  • האם האפליקציה שלך דורשת חומרה ספציפית? ב-Cloud Run יש כמות סבירה אבל מוגבלת של זיכרון RAM ומעבד לכל בקשה. ‫Knative serving מציע אפשרויות נוספות להתאמה אישית, כמו GPU, נפח זיכרון גדול יותר ומקום בדיסק.
  • מהן הציפיות שלך לגבי התרחבות? אם באפליקציה שלכם יש תקופות של חוסר פעילות, פתרונות בלי שרת (serverless) כמו Cloud Run יכולים להציע את האפשרות לצמצם אנכית בהתאם לעומס (scale down) לאפס.
  • עד כמה זמן האחזור חשוב, ומה רמת הסבילות של האפליקציה ל הפעלות מההתחלה (cold starts)? אם אתם לא רוצים שיהיו הפסקות בהפעלת האפליקציה, כדאי להשתמש במספר מינימלי של מכונות ב-Cloud Run או ב-GKE עם התאמה אוטומטית לעומס.

מומלץ לקרוא את התיעוד של כל סביבת אירוח כדי להכיר את היכולות, היתרונות והחסרונות שלה ואת מודל התמחור שלה.

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

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

‫Kubernetes ו-GKE

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

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

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

‫GKE יכול לנהל קונטיינרים של Windows ושל Linux. היכולת הזו שימושית אם רוצים לשמור על סביבה היברידית אחת לאפליקציות מבוססות-Windows ולאפליקציות מבוססות-Linux מודרניות.

‫Knative ו-Cloud Run

עבור קונטיינרים של ‎ .NET בלי שמירת מצב, ‏Knative והגרסה המנוהלת שלו, Cloud Run, מספקים סביבת קונטיינרים בלי שרת (serverless). קונטיינרים בלי שרת מציעים יתרונות כמו הקצאת משאבים, התאמה אוטומטית לעומס ואיזון עומסים בלי תקורה של ניהול התשתית.

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

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

‫Knative serving היא גרסה גמישה יותר של Cloud Run שמציעה את הפשטות של Knative ו-Cloud Run עם הגמישות התפעולית של Kubernetes. לדוגמה, ב-Cloud Run ב-GKE Enterprise אפשר להוסיף יחידות GPU למופעים הבסיסיים שמריצים את הקונטיינרים, או להגדיל את מספר הקונטיינרים של האפליקציה.

‫Cloud Run משולב עם שירותים אחרים כמו Pub/Sub,‏ Cloud Scheduler,‏ Cloud Tasks ועם שירותי קצה עורפיים כמו Cloud SQL. אפשר להשתמש בו גם בחזיתות אינטרנט עם שינוי גודל אוטומטי וגם במיקרו-שירותים פנימיים שמופעלים על ידי אירועים.

מודרניזציה של פעולות

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

‫Cloud Build יכול לעזור לכם לחדש את מחזור הפיתוח, הבדיקה והפריסה של האפליקציה ולהפוך אותו לאוטומטי. ‫Cloud Build לא רק מספק כלי build ל-‎ .NET, אלא גם משתלב עם סורק הפגיעויות של Container Registry ועם Binary Authorization כדי למנוע הפעלה בסביבת הפריסה של תמונות שנוצרו מקוד מקור לא ידוע או ממאגרי מידע לא מאובטחים.

‫Google Cloud Observability (לשעבר Stackdriver) מציע כמה שירותים שמאפשרים לכם לחדש את יכולות התצפית של האפליקציה:

אתם יכולים להשתמש בספרייה Google.Cloud.Diagnostics.AspNetCore כדי לייצא יומנים, מדדים ועקבות אל Google Cloud עבור אפליקציות ASP.NET. כדי לייצא מדדים של OpenTelemetry אל Google Cloud, אפשר להשתמש בספרייה OpenTelemetry.Exporter.Stackdriver.

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

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