אם אתם חיים באמצע שנת 2019 ותפקידכם כולל אחריות על בחירה של פתרון ענן, בניית ארכיטקטורה נכונה ותחזוקה שוטפת של תשתיות, חייכם, קרוב לוודאי, אינם קלים. סיכוי גדול שאתם יורים באפלה, או יותר מדויק, באור מסנוור. חברות ענק כמו Amazon, Microsoft, Google, IBM רואות בשירותי הענן את אחד ממנועי צמיחה החשובים שלהן ומשקיעות מאמצי עתק בפיתוח ובמרקטינג שלהם. כתוצאה מכך, כמות הטכנולוגיות והשירותים גדלה בצורה אקספוננציאלית בכל שנה, וגם הטכנולוגיות הקיימות משתנות כל הזמן ולכן, קהל היעד – ארכיטקטים, CTO ים וכל מי שעובד עם פתרונות ענן בארגון, מוצף בשטף אינסופי של הצעות חדשות ומפתות משלל הצורות, מתקשה להישאר עדכני עם הקצב השינויים התמידיים, ולא פעם חש תחושה של חוסר בטחון לגבי בחירותיו היומיומיות.
סדרת הכתבות הזאת נוצרה במטרה לנסות לעשות סדר בבלגן ולהשוואות פתרונות וטכנולוגיות ענן הקיימות בימים אלה, באמצע שנת 2019, בצורה מסודרת ומבנית, שתקל על התמודדות עם הכאוס. היא תעסוק ב-NoSQL DBs מנוהלים, מבחר של message queues, פתרונות סטרימינג, Big Data וכו' וכו', אבל תתחיל עם הטכנולוגיה שעושה הכי הרבה רעש ומושכת הכי הרבה תשומת לב היום, הידועה בתור Serverless.
אז מה זה Serverless בעצם?
ניתן להגדיר Serverlesss כשירות ענן שבו הספק מקצה את המשאבים הנחוצים למשתמש בהתאם לצריכה בזמן אמת, כך שהוא אינו נדרש לשלם מראש עבור נפח או שרתים ייעודיים. נבהיר שדיון על היתרונות וחסרונות של הטכנולוגיה הוא לא המטרה כאן. ההנחה היא, שמי שקורא את השורות האלה בחר בה בחירה מושכלת ורוצה להבין איזה פתרון ומאיזה וונדור לבחור.
יש לציין שישנם הרבה גוונים של Serverless, (פחות מ-50 אבל) ונעסוק בכולם, גם באלה ששומרי הטוהר יכולים להתנגד להגדרתם ככאלה. נתחיל בפתרון הכי Serverlesss שיש, שנקרא FaaS, או Function as a Service.
אמ;לק
המנצח הברור בקרב של ארבעה וונדורים גדולים הוא, באופן לא מפתיע, אמזון עם AWS Lambda, השחקן הוותיק עם השירות שהוא הכי טוב כמעט בכל היבט והיבט. מיקרוסופט, עם Azure Functions רודפת אחרי אמזון במקום שני, כשהיא סוגרת את הפער שנכון ליולי 2019 עדיין די גדול, במיוחד בכל מה שקשור לתמיכה בשפות תכנות. יבמ, עם IBM Cloud Functions שהם חלק מפלטפורמה יותר גדולה OpenWhisk, מצטיינת בתמיכה בשפות תכנות אבל בכל מה שקשור לאקוסיסטם היא מאוד מבודדת ונראה ש Big Blue לא משקיעה מאמצים גדולים מספיק כדי לצאת מהבידוד הזה. Google Cloud Functions נמצאים במקום אחרון, עם השירות שנראה כמו ילד לא רצוי במשפחה, עם פיצ'רים חשובים כמו אלה שנוגעים ב-scale ו-security שעדיין בסטטוס של pre-release - למרות שהשירות הוכרז כמעט שלוש שנים לפני.
ישנם שירותי FaaS נוספים שלא נכנסו לסקירה הזאת, למשל של CloudFlare ,של Oracle (ז''ל) ושל כמה אחרים– מהסיבה הפשוטה שהם או הרחק מאחורי מ-Big Four, או, כמו במקרה של Oracle, הולכים לאחד כוחות עם אחד השחקנים של ה- Big Four.
אז בואו נצלול פנימה ונראה מה יש להציע לכל וונדור בכל היבט והיבט של שירות FaaS שלו.
FaaS: AWS
אמזון היית חלוצה בתחום כשבשנת 2014 הציעה שירות שנקרא AWS Lambda. במשך שנים השם הזה הפך להיות שם נרדף ל-FaaS, ולוונדורים אחרים לא היית ברירה אלא לפתח אותו השירות – וכך זה קרה. אמזון מגדירה Lambda כשירות ענן Serverlesss שהוא מריץ קוד בתגובה לאירועים שונים ומנהל משאבים חישוביים הנדרשים לשם כך בצורה אוטומטית. פשוט מאוד, השירותים האחרים של AWS, או קוד משלך, יורים אבנט מסוים ופונקציה בודדת, עצמאית, וחסרת כל סטייט, מטפלת בו.
כך נראה מסך יצירת פונקציה Lambda חדשה ב-AWS:
בכדי לשים לב שעניין ה-security, וליתר דיוק שכבת ACL, מטופלת ממש בשלב יצירת הפונקציה – ואנחנו נראה שהמצב שונה אצל וונדורים אחרים. מה שלא כל כך ברור זה שהפונקציה החדשה לא שרק לא נחשפת לעולם באופן אוטומטי, אלא היא גם לא מחוברת לשום נקודת קצה עם URL. כדי לעשות זאת, היא צריכה להיות מחוברת לשירות שלAPI Gateway , כפי שאתם יכולים לקרוא על זה כאן, או דרך ALB, כפי שמוסבר כאן.
ישנה גם אופציה ליצור פונקציה חדשה מתוך תבנית מוכנה, ויש 70 כאלו, שכוללים פתרונות עבור שירותים פופולריים של AWS כמו Kinesis.
Event Triggers
Lambda תומכת במגוון טריגרים, שכוללים המון שירותי ענן אחרים של AWS, כמו כן היא יכולה לרוץ לפי לו''ז מוגדר וגם להגיב לאבנטים של פונקציות אחרות. כל טריגר קונפיגורבילי בצורה מלאה וניתן גם לבדוק אותו עם אבנט לדוגמא ב-GUI שהוא די נוח.
Supported Languages
Lambda תומכת natively ב-Java, Go, PowerShell(!), Node.js, C# (Net.Core), Ruby on Railsבחודש נובמבר 2018 אמזון הכריזה על Runtime API , טכנולוגיה שמאפשרת לתמוך בכל שפה אחרת דרך REST API. הכתבה הזאת בבלוג הרשמי של AWS מראה איך לממש “Hello World!” קלסי בשפת C++. מגניב אבל לא ייחודי - ליבמ יש שירות דומה שעובד עם Docker.
ניתן לערוך קוד של הפונקציה בתוך ממשק הדפדפן או להעלות את הקוד כקובץ ZIP משירות S3. האופציה האחרונה עושה עבודה קלה לשלל פתרונות CI/CD הקיימים - אפילו ל-AzureDevOps, המוצר של המתחרה הגודל Microsof, יש פלאגינים תואמים.
Tooling & Debugging
אחת הבעיות המרכזיות שמנעו עד עכשיו התאמה רחבה של הטכנולוגיה היא Tooling מאוד לא מפותח, ובראש ובראשונה חוסר יכולת של דיבוג לוקלי . לאמזון לקח זמן לטפל בבעיה הזאת, אבל לאחרונה היא השקיעה המון בתחום וכתוצאה יש toolkit כמעט לכל IDE פופולרי שמאפשר פיתוח מהיר ונוח בלי לעשותdeploy לענן בכל פעם שאתם רוצים לבדוק משהו. JetBrains, PyCharm, IntelliJ, Visual Studio, Visual Studio Code - רק תבחרו. וכמובן שה-CLI של AWS גם תומך ב-Lambda.
Monitoring & Logging
כמו כל שירות אחר ב-AWS,Lambda שולחת לוגים לקבוצת לוגים משלה ב-CloudWatch. וכמו לכל שירות אחר, זהו פתרון חלקי ולא נוח בעליל, ויש צורך כמעט קיומי בפתרון אחר – או ELK קאסטומי או שירות צד שלישי, כמו Loggly. בנוסף ללוגים, ישנו Monitoring Dashboard שמראה המון מידע שימושי, בין היתר הקריאות הכי יקרות - לאף וונדור אחר אין משהו דומה. ניתן גם ליצור alerts כאשר Lambda יוצאת עם timeout ואז לשלוח אותן לכל שירות צד שלישי כמו למשל Slack – מרשים! כדאי גם לקרוא פוסט של Yan Cui How to monitor Lambda with Cloudwatch metrics, שמתאר עוד כמה טכניקות שימושיות.
Advanced Features
ממש לאחרונה, בנובמבר 2018, אמזון שיחררה פיצ'ר שמאפשר לחלוק קוד בין הפונקציות השונות. ניתן להגדיר "שכבה", או Layer, שיחזיק פריימוורק, חתיכת קוד או SDK שפונקציות שונות יכולות להשתמש בו במשותף. שימושי מאוד, להרחבה ניתן לקרוא בלינק הזה.
Performance & Scaling
לכל שירות FaaS, וLambda- היא לא יוצא מן הכלל, יש הגבלות על גודל הקוד, זמן ריצה, כמות זיכרון המקסימלי המותר להקצאה וכדומה – כי תזכרו שמדובר בחתיכה פונקציונלית מאוד מוגבלת ומוגדרת היטב, שצריך להגביל אותה מבחינת משאבים כדי להקטין כמה שיותר את עלות הריצה. כאן יש רשימה מלאה של הגבלות וגבולות גזרה עבור Lambda.
ואם מסתכלים על עניין הביצועים, אז השני מאפיינים הכי מעניים עבור FaaS הם זמני ריצה מקסימליים של כל פונקציה וכמות הפונקציות שיכולות לרוץ במקביל באותה יחידת זמן – שימו לב, הדעה הרווחת ש-FaaS הוא infinitely scalable היא רחוקה מהמציאות. אז אם מדובר ה-Lambda, המספרים הם 15 דקות זמן ריצה מקסימלי (אז הפונקציה יוצאת עם שגיאת timeout) כאשר רק 1000 פונקציות (למה לא 1024?) יכולות לרוץ במקביל, ואת המספר הזה ניתן לקנפג גם עבור פונקציה בודדת וגם עבור חשבון שלם. אתם מוזמנים לעיין בדוקומנטציה הרשמית של אמזון שעוסקת בנושא.
עוד בעיה ידועה, שמשפיעה על זמני תגובה של כל שירות FaaS היא מה שנקראה "ההתחלה הקרה", או cold start. ל- Lambda שלא היית פעילה הרבה זמן, יכול לקחת עד עשירות שניות (במקרה קיצוני) כדי להתחיל להגיב לטריגרים. יש הרבה דרכים לטפל בזה, אחת הטריוויאליות היא תמיד להחזיק את Lambda במצב פעיל (מיותר להסביר למה הפתרון הזה רחוק מלהיות אידאלי). כדי ללמוד יותר על הבעיה ועל הפתרונות, מומלץ לקרוא פוסט מעולה של חברים מ-Coinbase וגם כתבה לא פחות טובה של רן ריבנזפט, CTO בחברת Epsagon.
Security
AWS לוקחים את עניין ה-Security ברצינות. כדי להראות זאת, הם פרסמו נייר עמדה בנושא, שעוסק בפרטי פרטים של ארכיטקטורה הפנימית של ה-Lambda ומראה עד כמה היא חסינה לפריצות. וכמו כל שירות אחר של AWS, Lambda משתמשת בשירותי IAM עם execution role משלה שניתן לשייך אליה policies שונות ומשונות.
כשמחברים את Lambda לHTTP endpoint בעזרת API Gateway, ניתן להשתמש באוסף פיצ'רים ש-API Gateway מספק, כמו אוטנטיקציה, אוטריזציה וכדומה – תקראו את הכתבה המעולה של חברת puresec. חשוב לציין שכאשר עושים את אותו הדבר דרך ALB, מגוון כלי האבטחה מצומצם בהרבה – אבל זה גם הרבה יותר זול, כפי שנראה בהמשך.
ושירות אחרון שיכול לשמש את Lambda כאמצעי אבטחה הואVPC. נכון לאמצע 2019 זה משהו שממש, אבל ממש לא מומלץ לעשות וההמלצה הזאת עשויה להשתנות בסוף השנה, כאשר עניין של הקצאת ENI, שמקפיץ את זמני cold start , אמור להיות מטופל על ידי מהדסי AWS.
Pricing
מודל התמחור של Lambda מבוסס על כמות הקריאות, זמן ריצה של כל קריאה וכמות הזיכרון שהוקצה עבור כל ריצה. כיוצא מכך אמזון מגדירה מושג GB-SECONDS, וכל אחד מקבל בחינם 1M קריאות ו-400,000 GB-SECONDS כל חודש. נראה משתלם? אם אתם לא מריצים את ה-Lambda שלכם בסקייל , זה אכן נכון. אחרת, זה יכול לעלות לכם הון תועפות והכתבה הזאת מסבירה איך בדיוק זה יכול לקרות.
כדי לציין שחיבור ל-ALB במקום ל-API Gateway יכול להוזיל עלויות בצורה מאוד משמעותית, תקראו את הכתבה הזאת שבוחנת את העניין ממש לעומק.
Wrap Up and Further Reading
נכון ליולי 2019 AWS Lambda הוא השירות FaaS הכי טוב בשכונה. בכל היבט חוץ מאולי Logging היא נותנת מענה שאין שני לו. אם אתם חדשים בתחום ומתלבטים ממה להתחיל – לכו על Lambda.
הרבה מידע מאוד שימושי אפשר להשיג ב-Best Practices for Working With AWS Lambda Functions, AWS Lambda FAQs, AWS Lambda Documentation.
בחלק הבא נתקדם אל פלטפורמת ה-FaaS של אז'ור ולטכנולוגיות אחרות. נתראה!
מאת: איליה קריצמר, CTO בחברת Bridgez, בעלים בחברת Wu Consulting ומנטור ב-WeCode
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
אם אתם חיים באמצע שנת 2019 ותפקידכם כולל אחריות על בחירה של פתרון ענן, בניית ארכיטקטורה נכונה ותחזוקה שוטפת של תשתיות, חייכם, קרוב לוודאי, אינם קלים. סיכוי גדול שאתם יורים באפלה, או יותר מדויק, באור מסנוור. חברות ענק כמו Amazon, Microsoft, Google, IBM רואות בשירותי הענן את אחד ממנועי צמיחה החשובים שלהן ומשקיעות מאמצי עתק בפיתוח ובמרקטינג שלהם. כתוצאה מכך, כמות הטכנולוגיות והשירותים גדלה בצורה אקספוננציאלית בכל שנה, וגם הטכנולוגיות הקיימות משתנות כל הזמן ולכן, קהל היעד – ארכיטקטים, CTO ים וכל מי שעובד עם פתרונות ענן בארגון, מוצף בשטף אינסופי של הצעות חדשות ומפתות משלל הצורות, מתקשה להישאר עדכני עם הקצב השינויים התמידיים, ולא פעם חש תחושה של חוסר בטחון לגבי בחירותיו היומיומיות.
סדרת הכתבות הזאת נוצרה במטרה לנסות לעשות סדר בבלגן ולהשוואות פתרונות וטכנולוגיות ענן הקיימות בימים אלה, באמצע שנת 2019, בצורה מסודרת ומבנית, שתקל על התמודדות עם הכאוס. היא תעסוק ב-NoSQL DBs מנוהלים, מבחר של message queues, פתרונות סטרימינג, Big Data וכו' וכו', אבל תתחיל עם הטכנולוגיה שעושה הכי הרבה רעש ומושכת הכי הרבה תשומת לב היום, הידועה בתור Serverless.
אז מה זה Serverless בעצם?
ניתן להגדיר Serverlesss כשירות ענן שבו הספק מקצה את המשאבים הנחוצים למשתמש בהתאם לצריכה בזמן אמת, כך שהוא אינו נדרש לשלם מראש עבור נפח או שרתים ייעודיים. נבהיר שדיון על היתרונות וחסרונות של הטכנולוגיה הוא לא המטרה כאן. ההנחה היא, שמי שקורא את השורות האלה בחר בה בחירה מושכלת ורוצה להבין איזה פתרון ומאיזה וונדור לבחור.
יש לציין שישנם הרבה גוונים של Serverless, (פחות מ-50 אבל) ונעסוק בכולם, גם באלה ששומרי הטוהר יכולים להתנגד להגדרתם ככאלה. נתחיל בפתרון הכי Serverlesss שיש, שנקרא FaaS, או Function as a Service.
אמ;לק
המנצח הברור בקרב של ארבעה וונדורים גדולים הוא, באופן לא מפתיע, אמזון עם AWS Lambda, השחקן הוותיק עם השירות שהוא הכי טוב כמעט בכל היבט והיבט. מיקרוסופט, עם Azure Functions רודפת אחרי אמזון במקום שני, כשהיא סוגרת את הפער שנכון ליולי 2019 עדיין די גדול, במיוחד בכל מה שקשור לתמיכה בשפות תכנות. יבמ, עם IBM Cloud Functions שהם חלק מפלטפורמה יותר גדולה OpenWhisk, מצטיינת בתמיכה בשפות תכנות אבל בכל מה שקשור לאקוסיסטם היא מאוד מבודדת ונראה ש Big Blue לא משקיעה מאמצים גדולים מספיק כדי לצאת מהבידוד הזה. Google Cloud Functions נמצאים במקום אחרון, עם השירות שנראה כמו ילד לא רצוי במשפחה, עם פיצ'רים חשובים כמו אלה שנוגעים ב-scale ו-security שעדיין בסטטוס של pre-release - למרות שהשירות הוכרז כמעט שלוש שנים לפני.
ישנם שירותי FaaS נוספים שלא נכנסו לסקירה הזאת, למשל של CloudFlare ,של Oracle (ז''ל) ושל כמה אחרים– מהסיבה הפשוטה שהם או הרחק מאחורי מ-Big Four, או, כמו במקרה של Oracle, הולכים לאחד כוחות עם אחד השחקנים של ה- Big Four.
אז בואו נצלול פנימה ונראה מה יש להציע לכל וונדור בכל היבט והיבט של שירות FaaS שלו.
FaaS: AWS
אמזון היית חלוצה בתחום כשבשנת 2014 הציעה שירות שנקרא AWS Lambda. במשך שנים השם הזה הפך להיות שם נרדף ל-FaaS, ולוונדורים אחרים לא היית ברירה אלא לפתח אותו השירות – וכך זה קרה. אמזון מגדירה Lambda כשירות ענן Serverlesss שהוא מריץ קוד בתגובה לאירועים שונים ומנהל משאבים חישוביים הנדרשים לשם כך בצורה אוטומטית. פשוט מאוד, השירותים האחרים של AWS, או קוד משלך, יורים אבנט מסוים ופונקציה בודדת, עצמאית, וחסרת כל סטייט, מטפלת בו.
כך נראה מסך יצירת פונקציה Lambda חדשה ב-AWS:
בכדי לשים לב שעניין ה-security, וליתר דיוק שכבת ACL, מטופלת ממש בשלב יצירת הפונקציה – ואנחנו נראה שהמצב שונה אצל וונדורים אחרים. מה שלא כל כך ברור זה שהפונקציה החדשה לא שרק לא נחשפת לעולם באופן אוטומטי, אלא היא גם לא מחוברת לשום נקודת קצה עם URL. כדי לעשות זאת, היא צריכה להיות מחוברת לשירות שלAPI Gateway , כפי שאתם יכולים לקרוא על זה כאן, או דרך ALB, כפי שמוסבר כאן.
ישנה גם אופציה ליצור פונקציה חדשה מתוך תבנית מוכנה, ויש 70 כאלו, שכוללים פתרונות עבור שירותים פופולריים של AWS כמו Kinesis.
Event Triggers
Lambda תומכת במגוון טריגרים, שכוללים המון שירותי ענן אחרים של AWS, כמו כן היא יכולה לרוץ לפי לו''ז מוגדר וגם להגיב לאבנטים של פונקציות אחרות. כל טריגר קונפיגורבילי בצורה מלאה וניתן גם לבדוק אותו עם אבנט לדוגמא ב-GUI שהוא די נוח.
Supported Languages
Lambda תומכת natively ב-Java, Go, PowerShell(!), Node.js, C# (Net.Core), Ruby on Railsבחודש נובמבר 2018 אמזון הכריזה על Runtime API , טכנולוגיה שמאפשרת לתמוך בכל שפה אחרת דרך REST API. הכתבה הזאת בבלוג הרשמי של AWS מראה איך לממש “Hello World!” קלסי בשפת C++. מגניב אבל לא ייחודי - ליבמ יש שירות דומה שעובד עם Docker.
ניתן לערוך קוד של הפונקציה בתוך ממשק הדפדפן או להעלות את הקוד כקובץ ZIP משירות S3. האופציה האחרונה עושה עבודה קלה לשלל פתרונות CI/CD הקיימים - אפילו ל-AzureDevOps, המוצר של המתחרה הגודל Microsof, יש פלאגינים תואמים.
Tooling & Debugging
אחת הבעיות המרכזיות שמנעו עד עכשיו התאמה רחבה של הטכנולוגיה היא Tooling מאוד לא מפותח, ובראש ובראשונה חוסר יכולת של דיבוג לוקלי . לאמזון לקח זמן לטפל בבעיה הזאת, אבל לאחרונה היא השקיעה המון בתחום וכתוצאה יש toolkit כמעט לכל IDE פופולרי שמאפשר פיתוח מהיר ונוח בלי לעשותdeploy לענן בכל פעם שאתם רוצים לבדוק משהו. JetBrains, PyCharm, IntelliJ, Visual Studio, Visual Studio Code - רק תבחרו. וכמובן שה-CLI של AWS גם תומך ב-Lambda.
Monitoring & Logging
כמו כל שירות אחר ב-AWS,Lambda שולחת לוגים לקבוצת לוגים משלה ב-CloudWatch. וכמו לכל שירות אחר, זהו פתרון חלקי ולא נוח בעליל, ויש צורך כמעט קיומי בפתרון אחר – או ELK קאסטומי או שירות צד שלישי, כמו Loggly. בנוסף ללוגים, ישנו Monitoring Dashboard שמראה המון מידע שימושי, בין היתר הקריאות הכי יקרות - לאף וונדור אחר אין משהו דומה. ניתן גם ליצור alerts כאשר Lambda יוצאת עם timeout ואז לשלוח אותן לכל שירות צד שלישי כמו למשל Slack – מרשים! כדאי גם לקרוא פוסט של Yan Cui How to monitor Lambda with Cloudwatch metrics, שמתאר עוד כמה טכניקות שימושיות.
Advanced Features
ממש לאחרונה, בנובמבר 2018, אמזון שיחררה פיצ'ר שמאפשר לחלוק קוד בין הפונקציות השונות. ניתן להגדיר "שכבה", או Layer, שיחזיק פריימוורק, חתיכת קוד או SDK שפונקציות שונות יכולות להשתמש בו במשותף. שימושי מאוד, להרחבה ניתן לקרוא בלינק הזה.
Performance & Scaling
לכל שירות FaaS, וLambda- היא לא יוצא מן הכלל, יש הגבלות על גודל הקוד, זמן ריצה, כמות זיכרון המקסימלי המותר להקצאה וכדומה – כי תזכרו שמדובר בחתיכה פונקציונלית מאוד מוגבלת ומוגדרת היטב, שצריך להגביל אותה מבחינת משאבים כדי להקטין כמה שיותר את עלות הריצה. כאן יש רשימה מלאה של הגבלות וגבולות גזרה עבור Lambda.
ואם מסתכלים על עניין הביצועים, אז השני מאפיינים הכי מעניים עבור FaaS הם זמני ריצה מקסימליים של כל פונקציה וכמות הפונקציות שיכולות לרוץ במקביל באותה יחידת זמן – שימו לב, הדעה הרווחת ש-FaaS הוא infinitely scalable היא רחוקה מהמציאות. אז אם מדובר ה-Lambda, המספרים הם 15 דקות זמן ריצה מקסימלי (אז הפונקציה יוצאת עם שגיאת timeout) כאשר רק 1000 פונקציות (למה לא 1024?) יכולות לרוץ במקביל, ואת המספר הזה ניתן לקנפג גם עבור פונקציה בודדת וגם עבור חשבון שלם. אתם מוזמנים לעיין בדוקומנטציה הרשמית של אמזון שעוסקת בנושא.
עוד בעיה ידועה, שמשפיעה על זמני תגובה של כל שירות FaaS היא מה שנקראה "ההתחלה הקרה", או cold start. ל- Lambda שלא היית פעילה הרבה זמן, יכול לקחת עד עשירות שניות (במקרה קיצוני) כדי להתחיל להגיב לטריגרים. יש הרבה דרכים לטפל בזה, אחת הטריוויאליות היא תמיד להחזיק את Lambda במצב פעיל (מיותר להסביר למה הפתרון הזה רחוק מלהיות אידאלי). כדי ללמוד יותר על הבעיה ועל הפתרונות, מומלץ לקרוא פוסט מעולה של חברים מ-Coinbase וגם כתבה לא פחות טובה של רן ריבנזפט, CTO בחברת Epsagon.
Security
AWS לוקחים את עניין ה-Security ברצינות. כדי להראות זאת, הם פרסמו נייר עמדה בנושא, שעוסק בפרטי פרטים של ארכיטקטורה הפנימית של ה-Lambda ומראה עד כמה היא חסינה לפריצות. וכמו כל שירות אחר של AWS, Lambda משתמשת בשירותי IAM עם execution role משלה שניתן לשייך אליה policies שונות ומשונות.
כשמחברים את Lambda לHTTP endpoint בעזרת API Gateway, ניתן להשתמש באוסף פיצ'רים ש-API Gateway מספק, כמו אוטנטיקציה, אוטריזציה וכדומה – תקראו את הכתבה המעולה של חברת puresec. חשוב לציין שכאשר עושים את אותו הדבר דרך ALB, מגוון כלי האבטחה מצומצם בהרבה – אבל זה גם הרבה יותר זול, כפי שנראה בהמשך.
ושירות אחרון שיכול לשמש את Lambda כאמצעי אבטחה הואVPC. נכון לאמצע 2019 זה משהו שממש, אבל ממש לא מומלץ לעשות וההמלצה הזאת עשויה להשתנות בסוף השנה, כאשר עניין של הקצאת ENI, שמקפיץ את זמני cold start , אמור להיות מטופל על ידי מהדסי AWS.
Pricing
מודל התמחור של Lambda מבוסס על כמות הקריאות, זמן ריצה של כל קריאה וכמות הזיכרון שהוקצה עבור כל ריצה. כיוצא מכך אמזון מגדירה מושג GB-SECONDS, וכל אחד מקבל בחינם 1M קריאות ו-400,000 GB-SECONDS כל חודש. נראה משתלם? אם אתם לא מריצים את ה-Lambda שלכם בסקייל , זה אכן נכון. אחרת, זה יכול לעלות לכם הון תועפות והכתבה הזאת מסבירה איך בדיוק זה יכול לקרות.
כדי לציין שחיבור ל-ALB במקום ל-API Gateway יכול להוזיל עלויות בצורה מאוד משמעותית, תקראו את הכתבה הזאת שבוחנת את העניין ממש לעומק.
Wrap Up and Further Reading
נכון ליולי 2019 AWS Lambda הוא השירות FaaS הכי טוב בשכונה. בכל היבט חוץ מאולי Logging היא נותנת מענה שאין שני לו. אם אתם חדשים בתחום ומתלבטים ממה להתחיל – לכו על Lambda.
הרבה מידע מאוד שימושי אפשר להשיג ב-Best Practices for Working With AWS Lambda Functions, AWS Lambda FAQs, AWS Lambda Documentation.
בחלק הבא נתקדם אל פלטפורמת ה-FaaS של אז'ור ולטכנולוגיות אחרות. נתראה!
מאת: איליה קריצמר, CTO בחברת Bridgez, בעלים בחברת Wu Consulting ומנטור ב-WeCode
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר