בפרק זה רן וליאור מדברים על AWS Lambda והנסיון של רן בכתיבת crawler מעל שרות זה.
3:37 המוצר AWS Lambda נוצר ע״י אמאזון עם הקונספט של ״פונקציות ולא סרברים״. אין לך סרבר משלך , המתכנת מממש פונקציה משלו ב Node.js, Python, Java או אחר. ואלו רצות על תשתיות על אמאזון מבלי דאגות של Scale.
5:00 ההבדל בין Microservice לבין AWS Lambda, אוסף של פונקציות לעומת תשתית
6:57 ההבדל המשמעותי בין Lambda לבין Heroku ו Paas אחרים הוא שב Lambda כותבים אך ורק פונקציה - היחידה האטומית היא מאוד קטנה לעומת כתיבת Service שהוא שרת שלם.
7:46 הסוד הוא ב UNIXification של התוכנה. כותבים הרבה מאוד יחידות קטנות של פונקציונליות ומחברים אותן עם כלים חזקים כמו Message queues או דאטאבייסים המייצאים Stream, והתשתית הזו מסופקת ע״י אמאזון (או ספק אחר). הכלים הללו הבשילו לרמת פרודקשן והופכים לאופציה ריאלית לפיתוח.
9:30 קונספטים של למבדה: הפונקציות הן Stateless - בין הרצה להרצה לא שומרים על קבצים, אחרי ריצה - הדיסק ״מתאדה״. כשפונקציה מתחילה לרוץ היא מתחילה ״מאפס״ - ומוזנת מ ה Event או מידע מ S3 או דאטאבייס. זה אמנם אילוץ, אך הוא דוחף לארכיטקטורה נכונה שניתן לעשות לה Scale בפשטות יחסית.
11:24 אין סרברים, לא צריך לתכנת אותם, לתחזק אותם, לנטר אותם. הכל מאחורי אבסטרקציה, ומוריד הרבה מטלות תחזוקה.
12:25 הפונקציות הן Event driven - מחכות להודעות כדי לעבוד. יכולות להיות מוזנות ע״י הזנה לחלק אחר מהאקוסיסטם של אמאזון - S3, SQS, Kinesis, Dynamo DB. לדוגמא, אפשר לכתוב פונקציית Lambda, שבכל הזנה של קובץ תמונה ל S3, מייצרת עבורו גם Thumbnail (תמונה מוקטנת). הפונקציה תופעל לאחר שהוספת הקובץ ל S3, תבצע ״Trigger״ באופן אוטומטי של ה״Event״.
13:45 שימוש ב Api Gateway של אמאזון כדי לחבר גם פעולות שמקורן בווב. זו אבולוציה של ה Lambda שהחל כיכולת ״פנימית״ בלבד לארכיטקטורה ואח״כ התווספה היכולת לקבל איוונטים מבחוץ ולהחזיר תשובות.
15:10 הקונספט של ״Infinite Scalability, Zero maintenance״ - כמובן בגבול הסביר.
16:10 שירות בשם iron.io שגם מציע אלטרנטיבה דומה.
16:55 סכנת ה Lock-in לספק השירות הספציפי - למשל ב AWS, התשתית תהיה תלויה בשירותים המשלימים של אמאזון ונוצרת סכנה של ״Vendor Lock in״. הקוד עצמו (הלוגיקה) גנרי ולא תלוי תשתית, אך התלות ב״דבק״ - השירותים שמשנעים את המידע, מאוד תלוי ספק.
18:40 דוגמא איך הבדלי סמנטיקה בין ה Message Queues יכולה להשפיע על המימוש וליצור Lock-in, אפילו למוצר מסויים בתוך אותו השירות (כמו SQS לעומת Kinesis ששניהם שירותי תורים של AWS).
20:45 זה לא לחלוטין ניתן להעברה. יש Vendor Lock in גבוהה יותר מאשר כתיבת שרת ״old fashioned״, של node+ express, אבל זה צפוי להשתפר.
21:52 בטווך הארוך הרעיון הוא לבנות תשתית פונקציונלית בסיסית, והציפייה היא שהשירותים יישרו קו ויתמכו בפורמטים דומים.
23:00 טוב שיש תחרות מגוגל - כי יש בעיות רבות ואמאזון צריכים תחרות
23:30 מימוש: אפשר לכתוב Node.js, Python, Java או לכתוב Shim שיאפשר לכתוב בשפה אחרת - למשל Go, ע״י הרצתו כ Process עם Input - output. פריימוורק שמאפשר את זה מבלי לכתוב את ה Shim בעצמך הוא Apex.
24:57 התהליך של העלאת הפונקציות וניהולן די מתיש מול הממשק של AWS, ובגלל שצריך גם ניהול קוד. Apex נותן פתרון טוב ל Version control, Deployment, Rollback ותמיכה ב Go בנוסף לשפות שמוצעות ע״י Lambda.
27:00 בנוסף Apex נותן יכולות טובות לחיבור הפונקציות ל Events וניטור של התהליך. הניהול הזה הוא חלק נכבד מתהליך הפיתוח ב Lambda.
28:03 ב Apex החליטו לעבוד עם Terraform, כלי לניהול ה Infrastructure בענן. הכלי יכול לשמש למגוון של use cases להגדרת התשתיות בקוד (עם Version control). ב Apex השימוש ב Terraform הוא די הכרחי. ייתכן כי Apex יתרחב בעתיד מעבר לתשתיות של AWS בלבד.
31:31 נקודת התורפה בקונספט - האם באמת נחסך הצורך בלימוד כלים לניהול ה Infrastructure? אכן הניהול הוא נקודת חיכוך משמעותית ב Flow של Lambda.
32:43 זה יהיה הרבה יותר נחמד אם זה פשוט יעבוד. זה לא בשמיים לחבר פונקציה לתור והאבסטרקציה תגיע בקרוב. AWS LAmbda עוד צעיר ונמצא בגרסא 0.7
33:57 פריימוורק נוסף Serverless גם מנסה להתחרות בספייס הזה - להריץ Lambda על עננים שונים (כרגע רק באמאזון). Apex יחסית פשוט יותר, אבל שניהם בכיוון הנכון. חיוני להשתמש באחד מהם כדי לעבוד עם Lambda.
35:09 ניהול התשתיות הוא נקודת חיכוך שקיימת גם ככה בניהול שרתים ״Old school״. עדיף לעשות את זה נכון עם ניהול הרשאות
36:05 ה Tool fatigue מהאקוסיסטם של Javascript מגיע גם ל Devops, ולימוד של כלי חדש (כמו Lambda) מכריח ללמוד כלים נלווים נוספים.
38:28 יש מגוון Use cases. למשל Api Gateway + Lambda. שירות Cronjob (למשל שליחה ל Slack פעם ביום בשעה 10). דוגמא נוספת ל Slack היא שליחת הודעות בתגובה ל Events בתשתית (העלאת שרת, הורדת שרת). העלויות זניחות למקרה שבו ה Workload נמוך - זה עדיף מהחזקת שרת לצורך המשימה.
40:44 שימוש ב Analytics. חברת Segment.com פרסמה תיאור מעניין של Data pipeline בעזרת Lambda. זה יכול לשמש גם לניתוח מסוג Crawling. העלויות לעיבוד בקנה מידה גדול משמעותיות, וזה יכול להוות פקטור בבחירת הטכנולוגיה.
43:21 מימוש Data pipeline באמצעות Lambda Architechture, המימוש של AWS Lambda דומה בקונספט ל Use case של Data processing - פונקציות קטנות שהן Stateless שעושות את עבודתן ומעבירות הלאה. לא להתבלבל בין שניהם.
44:55 מימוש של רן ל Crawler הוא ניסוי. כרגע נראה שזה לא משתלם מבחינת זמן, אבל רק בעתיד נדע.
45:29 המלצה להשתמש ב Lambda רק עבור שירותים פנימיים ולא כחלק מליבת המוצר. זה כדי לחסוך בעלויות ולהכיר את טכנולוגיית העתיד במקום עם סיכון נמוך.
48:10 ב Bringg מגייסים מתכנתי iOS.
תודה רבה לשי אלון על התקצור. הקובץ נמצא כאן.