שאלה לגבי serverless arch + פונקציות

[zaske]

שאלה לגבי serverless arch + פונקציות

עדיין לא ממש יצא לי לכתוב AWS lambda או נניח Google functions אבל קראתי מאמר בנושא ושם אמרו שאחד המינוסים הוא תלויות בספריות חיצוניות. למשל - צריך לעלות איזה zip "שמן" שמכיל את כל הספריות של התלויות.

יש פתרון יותר אלגנטי? שימוש בקונטיינרים בצורה נורמלית בשביל זה? משהו אחר?

 

[יבגניי34]

באופן כללי יש בעיית deployment לפחות ב aws lambda

וכן, אין פתרון נאה לעין או משובב נפש לעניין. לא על aws.
יש פרוייקט שאני עוקב אחריו אבל עוד לא ניסיתי: serverless.com. הם מתיימרים לבנות שכבה אחידה מעל aws lambda / google / azure, משהו סטייל terraform אבל רק ל serverless.
אני ממתין שתקרה לי הזדמנות בעבודה לדחוף את זה...

 

[הסלע האדום]

יש לי ניסיון עם AWS Lambda Functions בייצור וServerless

אני לא רואה היכן הבעיה בZIP עם כל התלויות.
אם נדבר על ג'אווה. ברגע שאתה מייצר jar של Spring Boot, הוא לא מכיל את כל התלויות?
אז גם כאן זה אותו דבר, רק שבמקום בjar, אתה מכווץ את הכל בZIP.

לגבי Serverless. אין ספק שזה כלי מדהים.
יש גם את SAM של אמזון, שזה הכלי הרשמי שלהם לביצוע Deploy של AWS Lambda שהוא לא ממש משתווה לServerless, ואפשר בעזרתו לעשות CI/CD לAWS Lambda Functions.

https://github.com/awslabs/serverless-application-model

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

אני משתמש ב AWS Lambda functions בייצור וכמובן מבצע deploy עם Serverless.
אם יש לך עוד שאלות, אשמח לעזור.

 

[zaske]

אתה צודק לגבי Spring boot

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

 

[אוהב להתווכח]

מנצל"ש לשאלה שרציתי לשאול

מתי אתם רואים את היתרון הגדול של סברלס?
וליתר דיוק, מתי אתם רואים את היתרון הגדול שלו על autoscaling.
שמעתי על זה לא מעט הרצאות כולל מחברות שמתמשות בפרודקשיין ועדיין לא הבנתי למה auto scaling רגיל לא היה עובד להם.
&nbsp

 

[יבגניי34]

כמה שפחות דברים לנהל - יותר טוב. השאלה צריכה להיות הפוכה

למה אני צריך לעשות ביביסטר ל״שרת״ כשכל מה שמעניין אותי זה להריץ איזו פונקציה כשאני מקבל GET מקליינט.

אז אני אענה לשאלה ההפוכה - מתי *לא* כדאי לעבוד ככה:
- כשכבר יש לך משהו עובד והמעבר לא שווה את זה.
- כשפרופיל הטראפיק שלך ידוע ורגוע
- כשיש לך תלויות חיצוניות שמחייבות יותר שליטה על ה host שמריץ את הקוד שלך (בפרט native code)
- כשלא אכפת לך מעלות התפעול כי מישהו אחר משלם אותה

- (הכי חושב שכחתי) כשאתה צריך סוג של geo filtering או fail2ban שכרגע התמיכה של aws lambda בזה היא בזיון.

 

[אוהב להתווכח]

התשובות שלי

לכל ספק ענן יש שירותי PAAS שבהם אתה לא מנהל כלום ויש להם גם auto scaling.
אני אחדד את השאלה שלי: מה היתרון של סרברלס על paas?
&nbsp
בוא נזכור שלסרברלס יש הרבה חסרונות משלו כמו תלות בקוד שלך בספק הענן שלך, לוגים בעייתים ועוד. בוודאי בשלב הזה של המוצר.
&nbsp

 

[יבגניי34]

מינימום ניהול, חסכון בעלות תפעול, סקלביליות משופרת

ה״לא מנהל כלום״ הזה פירושו ניהול (instance type, termination rules, /etc crap), פירושו ניטור, פירושו ״zero downtime deploy strategy״ . עדכוני אבטחה. התקורה הזו מיותרת.

מעבר לכך, autoscale זה דבר מוגבל ממס׳ טעמים: ראשית, יש ramp up שיכול לקחת מס׳ דקות. שנית, אתה צריך להגדיר את חוקי ה autoscale, לבדוק אותם, לשנות אותם - ולבסוף הם לא יחזיקו מים במצב של פיק לא צפוי. הדרך היחידה להחזיק מערכת כזאת היא לרוץ ב over capacity, וזה מה שכולם עושים (גם אתה).

 

[אוהב להתווכח]

כתבתי לך תשובה ארוכה ומושקעת והכל נמחק

מקווה שיהיה לי כוח לכתוב שוב.

 

[Grosseto]

תתקין ditto

 

[יבגניי34]

lazarus