פונקציות ענן לעומת מנוע קיברנט

עודכן באוגוסט 2019.

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

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

3 שפות לא מתכוונות לחתוך את זה

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

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

מהירות

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

עיבוד כבד ועומסי עבודה גדולים

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

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

טירוף הפתיחה

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

תקשורת Microservice

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

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

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

רשימה זו אינה ממצה והיא בהחלט פתוחה לפרשנות. שוב, זה מבוסס על הצרכים שלך כחברה וארגון. קוברנט עדיין צומחת בקצב מהיר ולא לכולם יש מפתח / צוות שעומד לרשותם ניהול פרויקט Kubernetes Engine עבורם. מצד שני, אולי יש לך הרבה שירותי .NET Core שברצונך לפרוס ופונקציות ענן פשוט לא יחתכו אותם מכיוון שאתה צריך להשתמש ב- Node.js, Python או Go. תמיד כדאי לקחת צעד אחורה ולחשוב על הטכנולוגיות השונות העומדות בפנינו ואיך נוכל למנף אותם להיות פרודוקטיביים ככל האפשר.

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