מחבר: ליאור בר-און

על InsurTech – הדומיין, והבאזז

טוב, אפתח בעדכון אישי קצר:

עזבתי את Gett (לשעבר GetTaxi). הגעתי למסקנה שהמקום, שחוויתי בו את התקופה אולי הכי מעניינת בחיי המקצועיים – כבר לא בשבילי. בקרוב אתחיל במקום חדש, חברת סטארט-אפ קטנה שנקראת Next Insurance.

"תקרא קצת באינטרנט, זה נקרא InsurTech – אפילו לא FinTech, ויש שם התעוררות משמעותית" – אמר לי אחד היזמים באחת מהשיחות הראשונות בינינו. מאוד התחברתי לצוות, פילוסופיית וצורת העבודה של נקסט (נראה לי שאני כבר יודע לקלוט את זה מהר, וזה הדבר הראשון שאני מסתכל עליו) – והחלטתי להצטרף.

עכשיו גם הגיע הרגע להתעמק בדומיין, ולנסות להבין באיזה ביזנס מדובר. לקח לי קצת זמן להגיע לשלב הזה, כנראה בגלל ש"ביטוח" לא נשמע הדבר הכי מרגש בעולם (… גם "מוניות" לא נשמע – אבל זה שוק סוער ומסעיר). החברה גייסה סכומי כסף יוצאים מן הכלל (13 מ' סיד, 35 מ' סבב A תוך שנה) – מה שנסך בי ביטחון שלא מדובר ב"חלטורה". היזמים גם מגיעים מתחום דומה (מכרו את Check, אפליקציה לניהול פיננסי, ב 360 מיליון) – יתרון משמעותי מאוד. הם גם שלושתם צמחו מעולם התוכנה – מה שכנראה יאפשר להוציא מה R&D את המקסימום.

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

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

אני מסתכל לאחור על הפוסט שכתבתי על עולם המוניות עוד לפני שהגעתי לגט-טקסי: מצד אחד הוא נאיבי משהו, קל לי להסתכל עליו היום בחיוך. מצד שני, כן – יש בו ידע חשוב להבנה בסיסית של הביזנס. בחלקים ממנו (עם הרבה העשרה) – השתמשתי כשבנינו תוכן להרצאה שעובר כל עובד R&D חדש שנכנס לחברה. הרצאה שמי שעובר אותה מעיד שהיא אחת החשובות והמעניינות בתהליך ה Onboarding המורחב.

נתחיל.

סוגים שונים של ביטוח

כשאומרים "ביטוח", הכוונה היא למרחב גדול של נושאים ותחומים.

ננסה להסביר את זה בעזרת דומיין מוכר: המושג "היי-טק" לאדם מבחוץ נשמע אחיד: "זה כל החברות האלה שאנשים מתקתקים על המקלדת, גיקים כאלה – אבל מרוויחים אחלה כסף".
הבדלים בין חומרה ותוכנה, בין מוצרי On-Demand ומוצרי On-Premises, או בין מוצרי B2C ו B2B – נראים שוליים. אם אתם עובדים ב"היי- טק" – אתם בוודאי רואים כמה ההבדלים הללו הם משמעותיים.

כן, יש שם הרבה כסף. מקור: WordStream

ומה עם עולם הביטוח? לכאורה זה עשוי להישמע לנו שולי, אך יש תחומים שונים ודיי נפרדים זה מזה בעולם הביטוח:

  • ביטוח בריאות (health) – עוזר בכיסוי הוצאות רפואיות בעת הצורך.
    • מדינות רווחה מספקות ביטוח בריאות ממלכתי, שמאורגן על ידי המדינה ומוצע לכל האזרחים, ויש ביטוח בריאות המסופק ע"י חברות הביטוח.
    • בישראל, למשל, יש 3 מסגרות של ביטח בריאות:
      • ביטוח ממלכתי – דמי הביטוח נגבים ע"י מיסים (כחלק מתשלום הביטוח הלאומי) וכדמי חברות בקופת-חולים, והכיסוי אחיד לכל התושבים. סל הבריאות (נקרא בטעות גם "סל התרופות") הוא חלק מהביטוח הממלכתי.
      • שירותי בריאות נוספים – המוצעים ע"י קופות החולים, למשל "מכבי זהב".
      • פוליסות ביטוח פרטיות ("ביטוח משלים") – המוצעות ע"י חברות הביטוח, למשל: ביטוח סיעודי.
    • זה תחום אחד. הנה ב Udemy קיימים 1 2 3 4 קורסים שונים – ספציפית על תחום ביטוח הבריאות.
  • ביטוח חיים (life) – ביטוח המאפשר תשלום חד פעמי גבוה, או הכנסה קבועה – בעת פטירת המבוטח. הביטוח בעצם מגן על המשפחה מאבדן הכנסה.
    • וריאציה חשובה היא ביטוח אבדן כושר עבודה (annuity) –  המפצה את המבוטח במידה ואיבד את חוסר היכולת להמשיך ולעבוד (בשל נכות, למשל).
    • "ביטוח מנהלים" בישראל – הוא בעצם ביטוח חיים. פנסיה, היא סוג של ביטוח annuity – המנוהל בד"כ ע"י המדינה.
  • ביטוח רכוש (property) – דירה היא הנכס בעל הערך הכספי הגבוה ביותר של משפחה ממוצעת, ולכן יש ערך רב להתמודדות עם מצב שנפגעה: שריפה, נזקי מזג-אוויר, נזילות, או פגעים אחרים.
    • תת-תחום מרכזי הוא ביטוח תכולת דירה (content) – ביטוח על הריהוט ורכוש, לרוב בעקבות שריפה או פריצה.
    • גם שדה חקלאי, מלאי של חנות / מפעל, ספינות מטוסים, ועוד – מבוטחים כ property.
    • תת-סעיף אחר הוא ביטוח מוצרים (product) – הרחבת אחריות היצרן לתקופה נוספת, למשל למכונת כביסה או מקרר.
  •  ביטוח בפני תאונות/אסונות (casualty) – ביטוח הרכוש עצמו, (וגם ביטוחים אחרים) – לרוב לא כוללים כיסוי למקרי קיצון. זה סיכון אחר, עם משמעות אחרת. למשל: ביטוח רכוש פעמים רבות לא מכסה מקרה של גניבה. ההשלמה הזו (שמופיעה כאופציה בפוליסה) – נחשבת ביטוח casualty. לרוב מתייחסים לביטוחים הללו ביחד, כ property & casualty -למרות שמבחינת תהליך הביטוח – ההבחנה היא חשובה.
    • ישנם שורה של ביטוחי casualty למקרים נדירים פחות ויותר: ביטוח בפני פריצה ופשעים אחרים, ביטוח בפני אירועי טרור (בביטוחי נכסים לרוב יהיה סעיף שמחריג אירועי טרור), ביטוח בפני חטיפה, ביטוח בפני חטיפה ע"י חייזרים (כן, כן), וכו'.
    • ביטוח שנהיה פופולרי בתחום הוא ביטוח כנגד התקפות סייבר. לא הצלחת למנוע? לפחות תתגונן ביטוחית בפני הנזק.
  • ביטוח רכב (auto) – העוזר בכיסוי עלויות רפואיות, עלויות לרכוש (תיקון הרכב / רכב חדש), ו Liability – תשלום לצד אחד – במידה והוא נפגע (רפואית / רכוש) בגללנו.
    • בגלל שחלקים מהביטוח ("ביטוח חובה", בישראל), מחויבים ע"פ חוק – השוק הזה גדול ומשמעותי.
    • בעצם מדובר בשורה של סוגי ביטוחים (בריאות, רכוש, liability) – שמאחדים בשל גודל השוק והדרישה הרגולטורית.
אלו הן ה"גורילות" של עולם הביטוח – היכן שרוב הכסף הולך, מתוך מחזור שנתי של 4.8 טריליון ( 4,800,000,000,000 $) דולר בשנה ברחבי העולם. בארה"ב, ביטוח מהווה כ 7% מהתל"ג – חלק משמעותי ביותר!
רשת Starbucks, למשל, מוציאה יותר על ביטוח – מאשר על חומרי גלם לקפה.

עדיין, קיימים עוד סוגים רבים של ביטוחים – למשל:

  • ביטוח בריאות לעובדים / ביטוח בפני תאונות עבודה – ביטוח B2B, הנמכר לעסקים.
  • ביטוח נסיעות (Travel) – ביטוח בפני קשת רחבה של אירועים שעשוי להתרחש בנסיעה, ולגרום להפסדים כספיים.
  • ביטוח אחריות (Liability) – תחום רחב של ביטוחים בפני נזקים שנגרמו על מה שחוקית הוא באחריות המבוטח, אך נעשה ללא כוונת זדון.
    • שני הצדדים העיקריים של הביטוח הם סיוע משפטי (במידה והוגשה תביעה), ותשלום פיצויים לנפגעים.
  • ביטוחים פיננסים כאלו ואחרים – ביטוחים של מתן הלוואות (גם משכנתה), עסקאות כספיות גדולות, וכו'.
ישנם עשרות ומאות תתי סעיפי ביטוח לכל תחום – שלא נראה לי שיש טעם לפרט.

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

ככלל, שוק הביטוח הוא מבוזר למדי:

  • תחומים שונים, כמו ביטוח חיים וביטוח רכבים – עליהם דיברנו הרגע.
  • לכל מדינה יש רגולציות רבות ושונות לתחום הביטוח, הדורשים התמחות עמוקה – ועל כן יש מעט חברות "גלובליות".
    • גם כאשר משתמשים באותו brand (למשל: AIG או AXA) – במדינות שונות אלו לרוב יהיו חברות שונות.
  • בשום שוק של ביטוח אין כמעט שחקן שגדול מ 10% מהשוק. יש ריבוי שחקנים, וכבר לאורך זמן.
הבדלים בצריכת הביטוח ברחבי העולם.
ככל שהמדינה מפותחת יותר – כך ביטוח הוא מוצר נפוץ ומשמעותי יותר. רואים איזה כתם קטן במזרח התיכון?

מכאן זה נשמע פשוט: תוכנה שמשרתת חברות ביטוח – מעכשיו נקראת "InsurTech", והנה יש לנו באזז חדש!
Sapiens, למשל, החברה הישראלית שמפתחת תוכנה לחברות ביטוח מאז 1982 – היא בוודאי חברת InsurTech. נראה שהכל ברור!

בפועל:

הכוונה ב InsurTech היא לחברות שהולכות לעשות שינוי משמעותי באופן שבו תחום הביטוח עובד. לרוב מדובר על חברות startup.

את חברות ה InsurTech מחלקים ל-2 קטגוריות עיקריות (ולא חד-משמעיות):

  • חברות שמנסות להחליף את חברות הביטוח שפועלות היום. למשל:
    • Lemonde [רכוש, היבטים מסוימים של P2P] – חברה ישראלית צעירה בתחום ביטוח הרכוש, בעלת פרופיל תקשורתי גבוה. Lemonade שכרו את פרופ' דן אריאלי כיועץ. במודל של למונייד הלקוחות מאוגדים כ"קבוצות עניין" ותורמים את עודפי הביטוח שלא התממש לצדקה – מה שאמור (בתאוריה) לצמצם את ניגוד האינטרסים המזיק בין חברת הביטוח למבוטח, וגם לצמצם הונאות.
    • Zenefits [בריאות עובדים] – מספקים בחינם תוכנת HR לארגונים, על מנת ליהנות מעמלת תיווך בביטוח בריאות לעובדי החברה שנעשה דרך התוכנה – דבר שנמצא בשטח האפור בתחום הרגולציה, והם כבר זכו לכמה תביעות.
      החברה קיימת כ-4 שנים בלבד, אבל גייסה כבר יותר מחצי מיליארד דולר.
    • FriendsInsurance [אישי / רכוש, P2P] הגרמנית, מציעה מודל P2P – בו קבוצת חברים שזקוקה לביטוח בתחום דומה, יוצרת בינה לבין עצמה pool של הון, שישמש לפיצוי אפשרי במידה ואחד החברים נפגע. חברת הביטוח מספקת ביטוח-משנה ל pool (נניח: כל החברים היו מעורבים ביחד בתאונת שרשרת בטיול לכנרת). בכלל, "pools משותפים של הון" – הם באזז בתוך עולם ה insurTech.
    • Cover [רכוש] – חברה שמספת ממשק מאוד חדשני לביטוח פריטים (תכשיטים, אלקטרוניקה, וכו'): מצלמים באפליקציית מובייל את הפריט, מקבלים הודעה מאוחר יותר על הצעה לביטוח, ומאשרים באפליקציה. תמונה (שכוללת את האלמנטים הנכונים) – שווה אלף מילים.
  • חברות שמנסות לשפר תהליכים של חברות הביטוח שפועלות היום. למשל:
    • Cape Analytics [ביטוח רכוש, שיפור חיתום] – משתמשת בתצלומי אוויר + computer vision בכדי לזהות פגעים בנכס מבוטח, ומשווה צילומים לאורך זמן על מנת לזהות שינויים בנכס.
מקור: Cape Analytics
    • SocialIntel.com [שיפור חיתום / ביטוח רכב] – חברות הביטוח היום, בנוסף לפרטים שממלא המשתמש, קונות גם מידע על Credit History, ו driving history של הלקוח בכדי להעריך את הסיכון – מידע לא זול. SocialIntel מציעה אלטרנטיבה: היא "כורה" נתונים על המשתמש מתוך הרשתות החברתיות, מזקקת את התובנות השימושיות עבור חברות הביטוח – ומוכרת אותו בהרבה יותר זול. כמו כן היא תמשיך לאסוף מידע על המשתמש גם לקראת תביעה ו/או חידוש הפוליסה 😕.
    • עוד חברה ששווה להזכיר היא Nexar הישראלית [ביטוח רכב / Telemetrics], שמספקת אפליקציה שעוזרת להתריע בפני סכנות בכביש ("כמו מובילאיי, ללא חומרה ייעודית"). Nexar היא לא חברת InsurTech ייעודית, אלא זהו פן אחד במוצר שלה: המידע על אופן הנהיגה של המשתמש יכול להיות מועבר לחברת הביטוח על מנת לקבל הנחה בביטוח – אם הנתונים מראים אכן שהמשתמש נוהג בזהירות. חברות דומות הן Greenroad ו lytx, הקצת יותר ותיקות.
    • חברות שונות מנסות לשפר את תהליכי ה Big Data והתהליכים הפנימיים של חברות הביטוח – ששניהם נחשבים מיושנים ומסורבלים בצורה מהותית, אולם לא מצאתי חברות מעניינות במיוחד ששווה להזכיר.

שרשרת המזון בעולם הביטוח, וחברות ה InsurTech

חוץ מה vertical הביטוחי, חברות ביטוח פועלות בשלבים שונים של התהליך הביטוחי. נחלק את תהליך הביטוח ל 3 שלבים / אזורי מומחיות:

  • הפצה – למכור את הביטוח. מלבד ביטוח בריאות או רכב, שיש רגולציה שמחייבת אנשים לקנות ביטוח שכזה (כמה נוח!), ביטוח הוא סוג מוצר ש"מוכרים", ולא כ"כ "קונים". לבנאדם לא "מתחשק" בוקר יום אחד לרכוש ביטוח לתכולת דירה (בניגוד, אולי, לסמארטפון חדש).
  • חיתום (Underwriting) – מישהו צריך להתמחות בתחום המסוים, ולשערך את הסיכון.
    • כמה מסוכן להוביל פסנתר כנף עתיק בכבישים של דרום פינסלבניה? לחברות הביטוח הגדולות יש מאות, ואלפי אנסליסטים – אבל הם מתמקדים בשווקי הביטוח העיקריים. את שאר שערוך הסיכונים – עושים שותפים של חברות הביטוח, כל אחד – המתמחה בתחומו [א].
    • מקור המינוח Underwriting, אגב, הוא מהביטוח הימי. באותם ימים היה מסמך שתיאר את פרטי הסכם הביטוח והסיכונים הנלקחים, והמבוטח היה כותב את שמו המלא (writing) באזור שנשמר לכך תחתית המסמך (under).
  • ניהול נכסים (Portfolio Management) – הפער בין הזמן בו הלקוח הממוצע משלם עבור הביטוח, ועד הזמן שהוא מגיש תביעה (claim) ומקבל חזרה את הכסף, הוא זמן לא מבוטל שבו הכסף "יושב" בידי חברת הביטוח.
    • חברות הביטוח, אם כן, מחזיקות סכומים אדירים של כסף – חלקו לזמן ארוך מאוד (למשל: ביטוח חיים).
    • את הכסף הזה חברות הביטוח משקיעות פיננסית, ועבור חלק מחברות הביטוח – הרווח מהשקעות הוא יותר משמעותי מהרווח שמושג מפרמיית הביטוח (premium).
    • הרגולציה מחייבת את חברות הביטוח לשמור את סכומי כסף מסוימים נזילים בכל עת: אם יש "spike" של תביעות – על חברת הביטוח להיות מסוגלת לשלם אותן.
הרגולציה קשה עבור סטארט אפ שרק קם, שלא לדבר על דרישות ההון, ודרישות להסמכות בתחום הביטוח של העובדים.
לרוב חברות ה InsurTech מנסות לתפוס אחת מ 4 פוזיציות ב"שרשרת המזון" הביטוחית (בצהוב), כאשר יש tradeoff מובנה בין סיכון, מורכבות, וחסמי כניסה – ל margins הפוטנציאליים.

חברות הביטוח הגדולות מצידן, גם הן ששות לשיתופי פעולה (מסיבות שאפרט בהמשך) – וכך ניתן לראות שיתופי-פעולה רבים בין חברות ביטוח מסורתיות ל startups בתחום ה InsurTech.

הנה סוגי ה"פוזיציות" השונות בתחום הביטוח ל insurTech startups, והמשמעות של כל פוזיציה:

  • Lead Generator (בקיצור: LeadGen) הוא שחקו שעוזר לבצע מכירות, או לפחות להשיג Leads. הוא לוקח עמלה מכל עסקה, מה שמהווה עבורו מעט מאוד סיכון.
    • Wobi הישראלית היא דוגמה טובה לכך: היא מאפשרת השוואות חינם בין ביטוחים מסוגים שונים. העמדה הזו מאפשרת לה למכור Leads לחברות, או לגזור עמלה מכל עסקה שנסגרה דרכה (אני לא יודע מה המודל העסקי שלהם).
    • Lead Generators טובים יותר הם אלו שיודעים לעשות סינון ראשוני ל Leads ולהעביר לחברות הביטוח את ה Leads המבטיחים. סתם Leads – זו לא בעיה לייצר, וחברת הביטוח לא רוצה להשקיע זמן ב Leads חלשים.
    • Axiom, למשל, קונה Leads, מאמתת אותם – ומוכרת אותם הלאה. עושה סוג של qualifications על ה Leads ומוסיפה ערך בשרשרת.
    • שחקנים במגזר הזה צריכים לשים לב לשורה של חוקים להגנת הצרכן / פרטיות – שעליהם לכבד.
  • "סוכני הביטוח" (נקראים גם Producers) מתחלקים לכמה סוגים, אבל בעיקר לAgents ו Brokers.
    • סוכן עצמאי (Independent Agent) – המייצג כמה חברות ביטוח (carriers) ומוכר מוצרים שונים שלהן. מוצר הוא פוליסת ביטוח עם תנאים מסוימים, וחברת הביטוח מאשרת רשימה של מוצרים שהיא מתירה לסוכן למכור.
    • ברוקר (Broker) – הוא דומה מאוד לסוכן עצמאי, אך חוקית הוא משרת את הצד הקונה את הביטוח. אין לו הסדר עם חברות ביטוח (הוא לא "מאושר" על ידן), והוא מחפש ללקוח שלו מוצר מתאים.
    • Captive Agents – הם סוכנים המחויבים למבטח אחד, ומוכרים רק מוצרים שלו. המודל העסקי שלהם מתבסס על מומחיות מיוחדת בתחום (בד"כ – נישה).
    • Wholesale broker – הם מתווכי ביניים המהווים ערוץ מכירות לא-ישיר של חברות הביטוח מול סוכני ביטוח / ברוקרים רגילים, שאין להם "הסמכה" למכור מוצרים של חברת הביטוח. מדוע להוסיף עוד שכבה, שגוזרת חלק מהרווח – אתם בוודאי שואלים? בגלל שעולם הביטוח הוא מבוזר וכולל נישות רבות – בהן קשה ואולי אף לא יעיל לחברת הביטוח להתמחות.
    • Sub Producer – היא חברה שעושה שימוש במינוי שניתן לסוכן ביטוח, על מנת להיות מוכר-משנה של אותו סוכן ביטוח.
    • שוני מהותי בין LeadGens ו סוכנים/ברוקרים הוא שסוכנים וברוקרים בד"כ יכולים לבצע bind לפוליסה: לספק ביטוח זמני (binder) למבוטח, עד אשר החיתום אצל חברת הביטוח יסתיים (מה שיכול לארוך גם שבוע-שבועיים)
    • סוכן ביטוח זקוק להסמכה ע"י חברת הביטוח, וגם ע"פ רגולציה במדינה – שלעתים כוללת מבחן עיוני שהעובדים צריכים לעבור. בארה"ב יש 50 מדינות – כל אחת עם הרגולציה שלה, שגם שונה מתחום לתחום (חיים, בריאות, רכוש, וכו'). הרגולציה הזו היא חסם כניסה משמעותי לסטארט אפים בתחום הביטוח.
      • שווה להזכיר שיש יוזמה לאחד את הרגולציה ברמה הפדרלית בארה"ב – רגולציה אחת לכל המדינות.
  • Managing General Agent (בקיצור MGA) – הוא סוג מיוחד של agent/broker שלו יש גם יכולת חיתום (Underwriting), ולהתמודד עם תביעות (claims).
    • MGAs גם יכולים למנות סוכנים (producers / sub-producers) ממש כמו carriers.
    • MGAs במקור קיימים כתחום התמחות בנישה מסוימת, שחברת הביטוח הגדולה אינה מכסה.
    • המודל הכלכלי של MGAs הוא עמלות, בצד שותפות הרווח/הפסד עם חברת הביטוח של החיתום שעשו.
    • MGA, בדומה ל carrier, זקוק לרישיון רגולטורי לפעילות – ע"פ חוק.
    • סוג של MGA הוא "quasi-carrier" שלוקח בתוכנית fronting מול חברת ביטוח (להלן ה Fronting Partner).
      • תוכנית ה fronting מאפשרת ל MGA להשתמש ברישיון של חברת הביטוח וההון שברשותה (כחלק מדרישות הרגולציה), בתמורה לנתח ברווחים.
  • חברת ביטוח (Carrier, נקרא גם "provider") – זה "הדג השמן" בעולם הביטוח. הוא עשוי להתפרס על תחומים שונים (ביחידות שונות), ועל חלקים שונים בשרשרת המזון (חיתום, bind, טיפול בתביעות, מכירות, השקעות פיננסיות, וכו') – אם כי לרוב חברות הביטוח עובדות עם ריבוי שותפים, בכדי לכסות תחומי מומחיות שונים.
    • חברת ביטוח יכולה ללבוש אחת מ-2 צורות רגולטוריות:
      • admitted – חברה בעלת רישיון בכל מדינה שהיא פועלת בה, למשל 50 מדינות בארה"ב.
      • non-admitted – מודל בו חברה יכולה לפעול במדינה תחת רגולציה פחות מחמירה, אך גם חוסר הגנה מצד המדינה. כשיש פחות רגולציה, הפרמיות לרוב יהיו זולות יותר, אך יש גם יותר סיכון למבוטח, שמא החברה תיקלע לקשיים לא-צפויים ולא תזכה להגנת המדינה.
    • captive – היא חברת ביטוח, שהיא בעצם חברת בת של חברה שאינה עוסקת בביטוח ומספקת ביטוח לחברת האם (לרוב: חברות ענק שמשתלם להן להקים כזו אופרציה). ה captive insurer לעתים יכול לקום במדינה עם רגולציה עדיפה (כמו אירלנד, לוקסמבורג, ברמודה, מלטה) – מה שמספק בהקמה, ובתשלום מסים. הנה מקור שמסביר טוב יותר את הנושא.
    • חברות הביטוח מרוויחות לא פחות מהשקעות, מאשר ממכירת פרמיות – ועל כן זהו עיסוק מרכזי אצלן.
      • בשנים האחרונות, כאשר הריבית ברחבי העולם היא אפסית – הרווחים מהשקעות פחתו, מה שדוחף את חברות הביטוח לחפש רווחים וצמיחה במקומות אחרים, למשל – בשותפות עם חברות startup.

בביטוח יש מונח בשם ה Insurance Cycle – מחזור בן כמה שנים בו העסקים טובים, יש יתרות של מזומנים (בעיקר בביטוח property & casualty) ואז התחרות גורמת להורדת מקדמי הסיכום והוזלת הפרמיות.

מה קורה אז? אסון, מגמה עולמית כלשהי, משהו שלא ניתן לחזות בדיוק – אך שגורם לסיכון להתרחש בצורה תדירה יותר ו בכמויות גדולות, ולחברות הביטוח – להפסיד כספים רבים.
בציניות של השנים האחרונות אפשר לומר: "ואז המדינה נכנסת ומכסה את חובות חברות הביטוח".
זה אמנם קורה, אך לחברות הביטוח יש מנגנונים בסיסיים יותר להתאושש מהלא-צפוי.
מנגנון חשוב אחד הוא Re-insurance: חברת הביטוח מבטחת את עצמה בפני גל בלתי צפוי של הפסדים. במידה וההפסד בתחום מסוים, בשל סיכון נתון שהוגדר היטב – חרג ממסגרת מסוימת, ה reinsurer ישלם אחוז מסוים או אפילו את כל ההפסד שחרג מהמסגרת (הכל ע"פ ההסכם).
ה Re-Insurer יכול לקום כ captive insuser, חברת בת, של חברת הביטוח. ייתכנו מבנים מורכבים של חברות וחברות-בת, וקבוצות ביטוח. נושא סבוך ובעיקר – מתיש! נדלג.
בתחום ה Re-insurance סטארט-אפים פחות פעילים. אולי רק ביישום פתרונות לחברות ה Re-insurance הקיימות.

נתוני השקעה ב startups בתחום ה insurtech. מקור: דו"ח על תעשיית ה InsurTech של גיקטיים, 2017
* באמצע 2015 היו 2 השקעות-ענק בתחום: כמיליארד דולר ל ZhongAn הסינית, וחצי מיליארד דולר ל Zenefits האמריקאית.

איך אפשר לדעת ש InsurTech הוא לא "באזז חסר משמעות"?

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

לפעמים נראה שטרנדים של השקעות בסטארט-אפים מגיעים כגל: הרבה השקעות שמגיעות משום מקום, ובמכה.
זה דיי נכון: הטרנד של InsurTech נוצר כנראה משורה של קרנות הון-סיכון שהחליטו להיכנס לתחום המסוים הזה. אם הקרן החליטה להתמקד בתחום – היא לומדת אותו, ואז עשויה להשקיע בחמש, עשר, אולי חמש-עשרה סטארט אפים שונים בתחום שבחרה. יש לה התמקצעות – ויש לה מגוון: שזו גישה מאוד הגיונית לקרן הון-סיכון.
באופן הזה, מספר לא גדול של קרנות (5-10) – יכול "להרים" טרנד ברמת התעשייה. כדי שהטרנד ימשיך – קרונות נוספות צריכות להיכנס, וההשקעות צריכות להתחיל ולהראות הצלחה.

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

אמנם ה Obamacare יצר צמיחה גדולה בביטוח הרפואי בארה"ב, אולם בסה"כ הלחצים על חברות הביטוח – גוברים:

  • הריבית בעולם בשפל –> הרווחים מהשקעות פוחתים (והמשקיעים לא אוהבים את זה).
  • חלק מסוגי הביטוחים נמצאים ברגרסיה: בשנות השישים, כ 59% מאזרחי ארה"ב החזיקו בביטוח חיים. כיום – רק 36% מחזיקים. לא נראה שהצורך נעלם, אלא שהתעשייה לא הסתגלה לשינויים.
  • חלק גדול מפרמיית הביטוח "הולך" על תחזוקת מנגנונים מסורבלים והונאות. יש הרבה פוטנציאל התייעלות באזורים הללו, בעזרת טכנולוגיות-מידע עַכְשְׁוִיּוּת.
  • לחברות הביטוח יש קושי גדול מאוד לגייס כשרונות (talent). חבר'ה צעירים ומוכשרים – לא נוהרים לחברות הביטוח המסורתיות.

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

התעשייה זקוקה לעזרה.

האמון בין חברת הביטוח והמבוטח – היא בעיית ליבה בתחום. מתוך ה Urban Dictionary.

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

  • מובייל ואונליין הוא כבר הסטנדרט לתקשר עם לקוחות ברוב התעשיות. בביטוח, מלבד ביטוח הרכב – כמעט ואין נוכחות אונליין לחברות. זהו צד טכנולוגי שכבר עכשיו מוביל צמיחה גדולה בעולם הביטוח.
  • Big Data ו AI – מה יותר טבעי מ Machine Learning לבניית מודלים לחיתום וחיזוי סיכונים? חברות ביטוח רבות עדיין משלמות שכר גבוה לאנליסטים שעובדים באקסל.
    • כמויות ה Data הזמינות ושניתן לאסוף היום גדלו בצורה משמעותית – מה שאמור לאפשר בניית מודלים יעילים יותר להערכת סיכונים.
  • IoT ו Wearables – מאפשרות לחברות להציע למבוטח שיתוף מידע שגם יכול להעיד על מבוטח מועט סיכון לו אפשר להפחית את הפרמיה, וגם לגרום למבוטח להתנהגות "טובה" יותר – המפחית סיכון.
    • באופן מפתיע, אחוז גדול למדי (70-90%, תלוי במדינה) של משתמשים מצוטט במחקרים שיסכים לשתף נתונים – תמורת הנחה בפרמיית הביטוח.
  • Blockchain – היא טכנולוגיה בעלת פוטנציאל לשינויים עמוקים. למשל: להיות בסיס לתהליכי ביטוח שקופים ואמינים יותר.
נדגים את הנושא הבסיסי ביותר – הנגשת הביטוח ללקוח Online. חברות הביטוח היום, עוד רחוקות משם מאוד:

חברה בשם Oscar, למשל, לביטוח בריאות בארה"ב החלה להציע חוויה נעימה ומודרנית לביטוח.

זה מתחיל ברישום אונליין, בטופס דינאמי ולא מאיים: ללא שדות לא ברורים / שאין צורך למלא, ובלי מונחים מאיימים (שאפילו לא כל סוכני הביטוח באמת מבינים):

וגם הפעלה של הביטוח, נעשית דרך האפליקציה בצורה מאוד נעימה – תוך סיפוק תובנות חשובות ללקוח:

השווי של Oscar כבר מוערך בכמעט 3 מיליארד דולר, והיא נמצאת במקום יפה ברשימת ה Unicorns (כלומר: לא רק היזמים שלה טוענים לשווי שכזה).

מה Oscar עשתה? בגדול – ביטוח כפי שכל בן מילניום היה מצפה שיהיה: פשוט, נוח, נגיש, ו informative ("מיידע").

האם השוק הזה כבר מוצה? ממש לא:

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

מה עם חברות הביטוח עצמן?

חברות הביטוח עצמן מחפשות את השותפות עם חברות הסטארט-אפ לצורך הצמיחה שלהן עצמן. במקום איום – הן רואות ב InsurTech הזדמנות.
תחושת הביטחון של חברות הביטוח, נגזר בוודאי מהקשיים הגדולים להקים חברת ביטוח (carrier) חדשה:

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

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

מתוך PwC Global InsuTech Report 2017

ע"פ הדוח של PwC, כחצי מחברות הביטוח שאיתן דיברו סיפרו שהן כבר נמצאות בשיתוף פעולה עם סטארט-אפים בתחום ה InsurTech.

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

אחד ממוקדי תשומת-הלב העיקריים של חברות הביטוח היום הוא לשפר את ה customer engagement. ליצור קשרים חזקים ומשמעותיים עם הלקוחות, ולא דרך צד-שלישי. הקשר של לקוח עם תעשיית הביטוח, הוא בפעמים רבות – שנתי, וזה לא מצב שמייצר נאמנות לקוחות:

הנה שיקוף של הטכנולוגיות שחברות הביטוח רוצות להטמיע בשנה הקרובה:

SMB

Next Insurance פונה לשוק מאוד ספציפי: שוק העסקים הקטנים בארה"ב. ביטוח שנראה לי שהוא (אני עדיין לא יודע) בעיקר ביטוח Liability ו Property & Casualty – מה שגם נקרא Commercial Insurance.

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

ההערכה של מקינזי היא ש 40% מהעסקים הקטנים בארה"ב הברית לא מבוטחים, מה שמספק מרחב צמיחה מרשים.
מספר העסקים הקטנים בארה"ב – גם הוא צומח:

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

השוק הפוטנציאלי של ביטוחים לעסקים קטנים בארה"ב הוא 100B $ בשנה – שוק לא קטן בכלל!

נשמע שיש על מה לדבר 😃

שיהיה לנו בהצלחה!

—-

קישורים רלוונטיים נוספים

המכתב השנתי של וורן באפט (עיקר הפעילות של ברקשייר האת'וויי – הוא תחום הביטוח) למשקיעים – ממנו אפשר ללמוד לא מעט על מצב הביטוח בעולם, ובשפה פשוטה: http://www.berkshirehathaway.com/letters/letters.html

יסודות הביטוח: http://continuations.com/post/141655994885/insurance-fundamentals-contd-adverse-selection

—-

[א] שום חברת ביטוח לא הסכימה לבטח את האסטרונאוטים של NASA במשימת אפולו, אבל סוכן הביטוח שלהם יעץ להם לכתוב "מכתב ביטוח" ולחתום עליו. אם ימותו במשימה ערך המסמך כפריט אספנות בוודאי יזנק – והמשפחות יוכלו למכור אותו. בפועל: נוצר כאן סוג של "ביטוח חיים" לא רשמי.

שלום, AWS Lambda! (חלק ב')

בפוסט הקודם שלום, AWS Lambda! הצגנו את למבדה, ובעיקר כיצד ה main successful flow עובד.
לא הספקנו כמעט ולהיכנס לעומק / להתנהגויות השונות במודל של למבדה.זה מה שננסה לעשות בפוסט הזה.

The Container Model

כאשר מתבצעת הפעלה (invocation) ראשונה של הפונקציה שלנו, למבדה מפעילה "Container" שבו תרוץ הפונקציה.
מהו ה container הזה? אין תיעוד מדויק, אך מדובר בסופו של דבר בסביבת ההרצה של הפונקציה, ע"פ ה settings שהגדרנו.

הרצת ה container אורכת זמן מסוים, נאמר כ 100-200ms – מה שנקרא cold start.
על הזמן הזה – המשתמש מחויב.

  • אם הפונקציה רצה עשר פעמים בדקה – אזי זו הפעלה אחת לכל גרסה / עותק חדש של פונקציה (הסבר בהמשך). הבדל זניח.
  • אם הפונקציה רצה פעם בעשר דקות, וזמן ה execution שלה קצר – ה cold start עשוי להכפיל את העלויות.

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

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

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

  • אין קונטיינר זמין – למשל "הרגו" אותו לא מזמן…
  • הבקשה הגיעה ל Availability Zone A, אבל הקונטיינר נמצא ב Availability Zone אחר.
  • יש מספר הרצות מקביל של הפונקציה: אם מספר ההרצות בשניה עלה מ 10 ל 100, למבדה תתחיל להריץ עוד ועוד קונטיינרים במקביל – עד שהצורך יסופק.
    כלומר: ייתכן ויש כבר 6 קונטיינרים עובדים, אך במקום לחכות שקונטיינר יתפנה – למבדה החליטה להפעיל קונטיינר שביעי.

    • בעת כתיבת הפוסט, אמזון לא תריץ יותר מ 1000 קונטיינרים במקביל – אלא אם ביקשתם.
    • למבדה תקבע את כמות המקביליות כתלות במקור ה event:
      • אם מדובר בהודעות ב Queue (או "stream-based-event") – המקביליות תהיה ע"פ כמות ה shards של queue.
      • כאשר מדובר בקריאות ישירות (למשל HTTP) – המקביליות תהיה מספר הקריאות בשניה * כמה שניות לוקח לפונקציה לרוץ בממוצע.
    • בכל מקרה, למבדה היא לא קסם. גם אם יש spike "מטורף" – אמזון לא תפתח יותר מ 500 קונטיינרים חדשים בדקה. אפשר לקרוא עוד פרטים על המדיניות כאן.
  • סיבה אחרת לא מתועדת / שאני לא מכיר.
זמני ה Cold Start תלויים ב:
  • כמובן: הקוד שלכם. אם אתם משתמשים ב ORM, או ספריות שדורשות אתחול משמעותי – הזמן הזה ישולם ב Cold Start.
  • כמות הזיכרון שהוקצתה לפונקציה (=> CPU). יותר זיכרון – אתחול מהיר יותר.
  • כמות הקוד שנטען ב ZIP, ספריות וכיוצ"ב: פחות קוד – אתחול מהיר יותר.
  • קוד ב node.js ופייטון יאותחל מהר יותר מקוד ג'אווה או #C.
זמני ההרצה של 4 עותקים זהים של פונקצית למבדה. הפונקציה memInfo0 נקראת בצורה תדירה – ולכן כמעט ואינה מושפעת מ cold start, לעומת הפונקציות האחרות שחוות cold start כמעט כל פעם: כלל שהפונקציה תדירה פחות – הסיכוי ל cold start גדל. מקור: New Relic.

למרות החשש האפשרי מ cold start על הביצועים – ההשפעה של ה cold start על משתמש הקצה היא לרוב קטנה למדי. הנה רכיבים טיפוסיים שגם להם אנו ממתינים בהפעלה של פונקציית למבדה:

  • network latency – עוד כ 100ms או יותר (?), אלא אם אתם קוראים לפונקציה באותו ה region – ואז ה latency הוא מילישניות בודדות.
  • זמני הריצה של ה API Gateway – כ 30 עד 150 מילישניות (ע"פ נתונים של New Relic).
    • הקמת חיבור מאובטח (TLS/SSL) – עשוי לארוך עוד 50-200 מילישניות.

דיי פופולארי היום לדבר על טכניקות ל"שמירת ה container חי" והימנעות מ Cold Start.
בשקלול של כל הרכיבים, נראה ש"הימנעות מ Cold Start" היא התעסקות דיי מיותרת – המשקל של הרכיבים האחרים הוא גדול יותר. לפחות, ברוב הגדול של המקרים.

Container reuse

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

  • הגדרות "סטטיות" שנעשו מחוץ ל handler function – עדיין תקפות: חיבור לבסיסי נתונים / רדיס וכו'.
  • Cache ששמרתם בזיכרון – עדיין מלא.
  • דברים שנרשמו לדיסק עדיין שם (יש לכם עד חצי ג'יגה אכסון בתיקיה tmp/)
זה פוטנציאל לשיפור ביצועים משמעותי.
כמובן, שלעולם אי אפשר להסתמך על container reuse: אם הוא יצא – אפשר לנצל אותו, אם לא אז לא. עליכם לכתוב את הקוד בהתאם.
כמו כן, חשוב להבין את התנהגות ה cache בצורה נכונה: אם יש מקביליות גבוהה (concurrent invocation), אזי יש כמה  containers שכל אחד עם cache ב state שונה. חשוב לקחת את זה בחשבון. אם חשוב לכם cache אחיד – פשוט השתמשו ברדיס.
Throttling: a process responsible for regulating the rate at which application processing is conducted
מקור: Robyn

Throttling and retries

כאשר יש הרבה יותר בקשות הרצה להפעלה של פונקציות מאשר containers – למבדה תגדיל את מספר ה containers הרצים.
כאשר יש מעט יותר בקשות הרצה להפעלה של פונקציות מאשר containers – למבדה תבצע throttling. כלומר: תמתין עם הבקשה עוד קצת – ואז תפעיל אותה על גבי ה containers הקיימים.

  • עבור מקורות מסוג Queue (רשמית: "stream-based events") – למבדה תבצע retry לעד. עד שהבקשות מטופלות.
  • עבור מקור קריאה אסינכרונית – למבדה תבצע retry בטווח של עד 6 שעות מרגע הקריאה, עם המתנה בין ניסיון לניסיון, מה שאמור ליצר סיכוי נמוך מאוד למצב של הודעה שלא טופלה.
  • עבור קריאות סינכרוניות (ה event source ממתין לתשובה) – למבדה תחזיר לאפליקציה HTTP status code של 429 – ותצפה שהאפליקציה תבצע retry בעצמה.
Throttling הוא מצב תקין וצפוי בלמבדה – מצב שעליכם לקחת בחשבון! הוא יקרה.
פונקציית הלמבדה שלכם כמובן יכולה להחזיר שגיאות. כאלו שחזרו מלבדה עצמה או מהקוד שלכם.
בלמבדה יש הפרדה בין 2 סוגי Exceptions:

  • Synchronous Exception – כזו שתוצאתה חוזרת למי שקרא לפונקציה.
  • Asynchronous Exception – כזו שתוצאתה מגיעה ל cloudwatch. לקוח הפונקציה לא מודע לדבר.
כשאר הפעלה של פונקציה נתקלה ב Synchronous Exception (שנגרמה ע"י הקוד שלכם או ע"י למבדה) – למבדה תבצע retry ע"פ המדיניות הבאה:
  • עבור מקורות מסוג Queue (רשמית: "stream-based events") – למבדה תבצע retry כל עוד ה data מבחינת ה queue הוא בתוקף.
  • עבור מקור קריאה אסינכרונית – למבדה תבצע retry עוד שתי פעמים, בד"כ בהפרש של כדקה, ואז תשלח את ההודעה ל Dead Letter Queue שהוגדר על ידכם על גבי SNS או SQA.
    • ליתר דיוק בדיקות הראו שאכן ב 99% מהפעמים יהיו 2 retries, אבל לעתים רחוקות יהיה רק retry אחד – ולפעמים גם יבוצעו עד שש retries. מקור.
  • עבור קריאות סינכרוניות (ה event source ממתין לתשובה) – הודעת השגיאה תחזור לאפליקציה, ובאחריותה לבצע retries.
חשוב לציין מגבלה שלא כתובה פה: בעת כתיבת הפוסט, ל API Gateway יש timeout קבוע של 30 שניות. אם יש לכם פונקציה שזמן הריצה שלה ארוך יותר – API Gateway יבצע timeout, בכל זאת.
בשלב הזה אתם אמורים להבין כמעט את כל המדדים שמסופקים ב Monitoring של למבדה:

המדד היחידי שלא הוסבר הוא ה iterator age שרלוונטי רק למקורות מסוג stream-based events.
הוא מציין כמה זמן ארך מרגע שפונקציית הלמבדה שלנו קיבלה batch של הודעות, ועד שסיימה לטפל בהודעה האחרונה. כלומר: מה ה latency המרבי של טיפול בהודעות ב batch, שהגיעו ממקור שכזה.

Lambda@Edge

שווה להזכיר את שירות ה Lambda@Edge ששוחרר לאחרונה, שירות המאפשר להריץ פונקציות למבדה (Nodejs בלבד, כרגע) על ה PoPs (כלומר: Point of Presence) של CloudFront.

לאמזון יש כ 14 regions בעולם עליהם אפשר להריץ את כל שירותי ה AWS, אבל יש לה קרוב ל 100 מיקומים בהם יש לה נוכחות – עבור שירות ה CDN שלה, הרי הוא CloudFront.

עבור פעולות פשוטות למדי, אם תוכלו להריץ את הקוד קרוב מאוד ללקוח שלכם – תוכלו לספק לו תשובה מהירה ביותר: ה latency ל"קוד" שלכם עשוי להיות עשרות מילי-שניות, ולא מאות מילי-שינות.
למבדה_על_הקצה (Lambda@Edge) תנהל עבורכם את שכפול הקוד לרחבי העולם – ותדאג שהלקוחות שלכם, יקבלו זמני תגובה משופרים.

את פונקציית הלמבדה_על_הקצה שלכם, אפשר לחבר לארבע נקודות-חיבור שונות בתהליך של cloudfront (בתרשים: החצים הירוקים והכתומים), ולבצע שינוי על המשאב שהתבקש.

מקור: אמזון

כמובן שבשירות כזה מאוד חשוב לספק זמני תגובה מהירים מאוד – מה שלא תמיד מתרחש בצמד למבדה + API Gateway.

ה API Gateway הוא מחוץ לתמונה, יצירת ה HTTP connection עם TLS/SSL – כבר מתבצע ע"י cloudfront, ולכן הרכיב היחידי שעלול לגרום לעיכובים (ולייתר את היתרון שבריצה על PoP) הוא זמן האתחול של ה container של למבדה. לא סתם התחילו ב nodejs כסביבת-ריצה.

ללמבדה_על_הקצה – יש מגבלות משלה (מקסימום 128MB זיכרון, זמני ריצה קצרים יותר, אין גישה לשירותים אחרים של אמזון, וכו')

שירותים נוסח למבדה_על_הקצה כבר היו קיימים (למשל: PubNub Blocks) – אבל לאמזון יש יתרון מובנה מול מתחרים קטנים יותר.

יהיה מעניין!

סיכום

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

שיהיה בהצלחה!

—-

לינקים רלוונטיים

Lambda@Edge

קוטלין (Kotlin) למפתחי ג'אווה ותיקים – חלק ג': מחלקות

פוסט זה הוא חלק מסדרה:

הגדרת מחלקה פשוטה

בואו נתחיל עם המחלקה הפשוטה ביותר האפשרית בקטולין:

פשוט, לא?
האמת שזה דיי דומה למחלקה ריקה בג'אווה: פשוט אם אין body – אז אין צורך בסוגריים מסולסלים.

מה השימוש במחלקה ריקה?

לא הרבה.
אפשר לייצר ככה custom exception או Marker interface או Marker Annotation (בתחביר מקוצר הרבה מג'אווה).

טוב, עכשיו נתחיל יותר ברצינות:

  1. בקוטלין לא ניתן להגדיר שדות (fields) למחלקה. במקום זאת – מגדירים תכונות (properties). מה זה אומר?
    1. השורה שלנו תגרום לקומפיילר לייצר גם שדה, וגם accessor methods לשדה הזה.
      1. כאשר כותבים  בקוטלין – הגישה לתכונה (property) תעשה בעזרת person.age – כאילו זהו field שהוא פשוט public.
      2. כאשר כותבים בג'אווה – הגישה לתכונה של מחלקה הכתובה בקוטלין תעשה בעזרת ()person.getAge  ו ()person.setAge – כמקובל.
    2. מאחורי כל תכונה (property) באמת קיים שדה (field). לעתים – לא יהיה בשדה הזה בכלל שימוש. נראה דוגמה בהמשך.
    3. הסיבה מאחורי הוספת properties לשפה, היא כנראה Item 14 בספר "Effective Java" – המזהיר בפני חשיפת שדות שאז לא יהיה ניתן לשנות, לבקר, ולהגביל את הגישה אליהם. "אחרי שנחשפו – זהו!… התלות קיימת וזו יכולה להיות עבודה קשה להסיר אותה…"
    4. בקוטלין נתנו לנו את האפשרות להוסיף custom getter/setter בכל יום שנצטרך – אבל בלי הסרבול של לכתוב getters / setters בעצמנו, בכל פעם, כי "אולי בעתיד יהיה צורך".
      להיות עם – ולהרגיש בלי.
  2. בקוטלין יש primary constructor, וייתכן שיהיו secondary constructors.
    ה primary constructor מוגדר באותה שורה עם הגדרת המחלקה.

    1. מגדירים אותו בעזרת המילה השמורה constructor.
    2. מגדירים אלו פרמטרים הוא יקבל.
    3. אם לא מגדירים primary constructor אזי נוצר default primary constructor – ללא פרמטרים.
  3. ה init block נקרא בכל יצירה של instance של המחלקה, והוא בעצם משמש כגוף הפונקציה של הבנאי הראשי (primary constructor) – אם צריך כזה.
    1. כל התכונות של המחלקה צריכות להיות מאותחלות. אם נסיר את השורה "age = 0" – נקבל שגיאת קומפילציה.
      הקומפיילר דורש שאנו נאתחל את התכונות באותה השורה (מה שנקרא initializer, כמו ב name) – או שנאתחל אותם ב init block / בבנאי הראשי.
  4. הנה הגדרה של בנאי משני למחלקה.
    1. ההגדרה שלו נעשית בעזרת המילה השמורה constructor.
    2. מגדירים את הפרמטרים של הבנאי המשני.
    3. חובה להפעיל את הבנאי הראשי:
      1. או ישירות – ע"י קריאה עם הפרמטרים המתאימים.
      2. או ע"י קריאה לבנאי משני אחר – שהוא יפעיל את הבנאי הראשי.
      3. כאשר קיים default primary constructor – אין צורך ב ()this :.
  5. הנה יצירת מופע של המחלקה בעזרת שימוש בבנאי הראשי.
  6. הנה יצירת מופע של המחלקה – בעזרת שימוש בבנאי המשני.
  7. הנה קריאה לתכונה – היא באמת נראית כמו קריאה לשדה בג'אווה – מה שהופך את הקוד למעט יותר "נקי בעין".
יש לא מעט מידע בפסקה הזו – אולי תרצו לעבור עליה שוב.
אתם בוודאי רואים שיש פה השפעה לא מעטה #C וגם קצת מסקאלה.
האמת, שיש דרך פשוטה יותר לכתוב את המחלקה Person. הנה היא לפניכם:
  1. הצלחנו לפשט את המחלקה דרמטית, בעזרת הגדרה "נבונה" יותר של הבנאי הראשי.
    1. המילה constructor בשורת המחלקה, לתיאור הבנאי הראשי – היא אופציונלית, ואפשר לוותר עליה.
    2. אם מגדירים val או var על הפרמטרים של הבנאי הראשי – הרי זה שקול להגדרת תכונות בגוף המחלקה. הארגומנטים שנשלחו לבנאי – יאתחלו את התכונות הללו. קצר ונוח.
      יכולת זו שמורה לבנאי הראשי בלבד.
    3. השימוש ב default value בחתימה של הבנאי הראשי – ייתרה את הצורך בבנאי משני.
      1. במקרים לא מעטים, השימוש ב default values – יכול לחסוך שימוש ב Builder Pattern, ולחסוך לא-מעט קוד.
  2. הנה ההרצה: אין שום שינוי, כי לא היה שום שינוי. הקוד שקול לחלוטין.

אמנם כך עדיף לכתוב את המחלקה, אך היה חשוב לי לעבור בדרך הארוכה – עבור הלמידה.

עוד קצת על תכונות (Properties)

בואו נחזור ונחדד עוד כמה דברים לגבי תכונות:

  1. הגדרנו למחלקה תכונה בשם age – ודרסנו את ה getter. ממש דומה לתחביר של #C.
    1. כעקרון, כאשר דורסים רק שלפן (accessor) אחד, במקרה שלנו: getter, השלפן השני – עדיין קיים במימוש ברירת המחדל שלו. כלומר: ל age עדיין יש default setter.
    2. ספציפית במקרה שלנו, מכיוון ש age הוגדר כ val (כלומר "immutable") – לא ייווצר setter.
  2. רק לצורך ההדגמה יצרתי תכונה מאוד דומה, אותה הגדרנו כ var. במקרה כזה, אנחנו מחויבים לאתחל את השדה של התכונה – גם אם לא יעשה בו שימוש לעולם (במקרה הזה: עם הערך אפס).
  3. כאשר ה getter שלי הוא פשוט – אני יכול להשתמש בתחביר shorthand, בעזרת הסימן =.
    1. יכולתי להשתמש בתחביר shorthand גם עבור age.
  4. אם אני לא רוצה שיגשו ל setter של התכונה – אני פשוט אגדיר אותה כ private.
    התחביר הזה אומר לקומפיילר: צור default setter – אך עשה אותו private.
  5. הנה – סתם בשביל ההדגמה: אני יכול להשתמש ב setter של התכונה בתוך המחלקה.
  6. אגדיר תכונה נוספת בשם nickname – אין לי בעיה לאתחל אותה בערך שנגזר מתכונה אחרת – name.
  7. כאן מימשתי setter לדוגמה. ה getter ה default-י עדיין קיים וזמין.
  8. מה קורה כאשר אנחנו רוצים, ב customer accessor שלנו לגשת לשדה שמאחורי התכונה?
    1. עושים את זה בעזרת המילה field.
    2. field היא מה שנקרא soft keyword, כלומר: keyword שקיים רק ב context מסוים. ממש כמו it – שראינו בפוסט הקודם.
  9. בניסיון ההרצה, שלושת השורות הללו יגרמו ל compilation error.
    1. את לשלושת התכונות הללו: age, name, ו ageNextYear – לא ניתן לקבוע ערך מחוץ למחלקה.
הנה תוצאת ההרצה:

Visibility Modifiers

בקוטלין, visibility ברירת המחדל היא תמיד public. יש שוני קטן בהגדרות כאשר ה visibility modifier מוגדר:

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

הנה ההגדרות:

  • private 
    • יתנהג כמו ג'אווה בתוך מחלקה
    • יגביל גישה לאותו קובץ בלבד, אם השתמשו בו ב top-level.
  • protected
    • יתנהג כמו ג'אווה בתוך מחלקה
    • לא ניתן להשתמש בו ב top-level.
  • internal
    • היא נראות חדשה לקוטלין, שמגדירה אפשרות לגשת לכל מי שנמצא באותו המודול.
      • כיצד מוגדר מודול? ע"י תהליך הקומפליציה: קבצים שקומפלו ביחד.
        זה יכול להיות מודול של Maven, של Gradle, או מודול ב IntelliJ – למשל.
    • היא מתנהגת אותו הדבר בתוך המחלקה, וב top-level

בואו נראה קצת קוד:

  1. הגדרתי את המשתנה כ private – לא יוכלו לגשת אליו מקובץ אחר.
  2. הגדרתי מחלקה שהיא internal – זמינה רק בתוך ה module.
    1. כל המחלקות בקוטלין הן final – לא ניתן לרשת מהן, אלא אם מרשים זאת במפורש בעזרת השימוש ב open. אהבתי!
  3. מה עושים כאשר רוצים להגדיר "שדה פנימי" בקוטלין? רק לשימוש המחלקה?
    – מגדירים תכונה שהיא private, ומשתמשים בה.
  4. פה נראה שאולי עשיתי איזה טריק: הגדרתי getter ו setter על התוכנה – כך שאי אפשר לגשת ל accessors שלה. האם הפכתי אותה ל private?
    1. בפועל: אין תחביר כזה:
    2. הקומפיילר מתעלם מ get ומגדיר רק את ה default setter כ private.
    3. תראו למטה – אמנם הקוד מתקמפל, אבל אני בהחלט יכול לגשת ל someHiddenField ממחלקה אחרת. אופס!
  5. הנה דוגמה תקינה ל default setter שהוא private. אפשר כמובן גם להגדיר custom setter באותו האופן.
  6. ניסיתי להגדיר internal getter – אך קיבלתי שגיאת קומפילציה: ה getter של תכונות חייב להיות באותה נראות כמו התכונה עצמה. חשבו אילו בעיות יכלו להיות אם לא…
  7. באופן הבא אני יכול להגדיר נראות (private) על primary constructor.
    כאשר אני משתמש ב visibility modifier על הבנאי – אני חייב להשתמש במילה constructor.
  8. על השורה הזו אני מקבל warning בקומפליציה: ה class לא הוגדר כ open – אז לא ניתן לרשת ממנו. אין טעם או משמעות להגדיר נראות של protected. צודק הקומפיילר.
נמשיך הלאה, ל"סוגים מיוחדים" של מחלקות בקוטלין.

Data Class

אחד הבזבוזים הגדולים של boilerplate code בג'אווה הוא ביצירה של data classes – מחלקות שכל תפקידן להחזיק כמות מסוימת של נתונים.

אני תמיד הייתי משתמש ב public fields, אבל יש כאלו שהקפידו על getters ו setters, וגם hashCode ו equals וכו'… הרבה קוד – עבור משהו מאוד סטנדרטי.

בקוטלין אפשר להגדיר data class, מחלקה שמספקת לנו:

  • תיאור כוונות ברור: המילה data מצביעה בבירור על הכוונה מאחורי המחלקה.
  • מימוש ל ()equals(), hashCode(), clone, ומימוש default-י וסביר לחלוטין של ()toString.
    בערך כל מה שמחלקה כזו צריכה.
  1. כך מגדירים data class, שהיא מחלקה לכל דבר. את התכונות של ה dataclass הגדרתי בתוך הבנאי הראשי – כמו שהראנו קודם. זה הכי נוח.
  2. מכיוון שזו מחלקה לכל דבר, אני יכול להגדיר לה member function. כמובן שבד"כ לא יהיו פונקציות ל data class.
  3. אמנם קיבלתי מימוש סטנדרטי של כמה מתודות, אבל אם צריך – אני יכול לדרוס אותן.
    בקוטלין override היא לא optional annotation, אלא mandatory keyword. טוב מאוד!
  4. הנה אני עושה השוואה בין אובייקטים של ה data class שלי. הם לא שווים, כי המימוש שמסופק ל equals – משווה את כל התכונות של המחלקה.
  5. לאחר שעשיתי השמה (שימוש ב ()clone) – האובייקטים שווים. זו אכן ההתנהגות הצפויה מ data class.

שני Data Classes שימושיים שמסופקים כחלק מהשפה הם Pair ו Triple, המאפשרים לנו להעביר זוגות או שלשות של פרמטרים.

אלו באמת רק Data Classes. למשל, הנה המימוש של Triple:

Enum Class

בדומה לג'אווה, לקוטלין יש enum… class. בואו נראה כיצד הוא נראה:

  1. הנה דוגמה ל enum פשוט. כל איבר הוא בעצם אובייקט – מופע של המחלקה.
    1. זהו אחד המקרים המעטים בהם צריך בקוטלין לכתוב יותר קוד מאשר בג'אווה: "enum class" במקום "enum"  😏
    2. מכיוון שהאיברים הם אובייקטים, אני יכול להרחיב אותם, למשל: לדרוס פונקציה של המחלקה (או להוסיף פונקציה חדשה). הפונקציות הללו שייכות לאובייקט, ולא למחלקה!
  2. אני יכול הוסיף גם פונקציה למחלקה, שתהיה זמינה לכל אחד מהאובייקטים ב enum.
  3. יש מקרה דיי נדיר בו עלי להשתמש בנקודה-פסיק בקוטלין:
    1. אם הוספתי ל enum class פונקציות, הקומפיילר יבקש עזרה לדעת היכן נגמרה רשימת האיברים, והיכן מתחילה המחלקה. ההפרדה מסומנת בעזרת נקודה-פסיק.
    2. שימו לב שב TriColor לא היינו צריכים להוסיף נקודה-פסיק (אבל יכולנו – זה תקין).
  4. מכיוון ש BLUE הוא אובייקט – כאן תופעל, באופן טבעי, הפונקציה ()toString.
  5. לכל enum class יש את הפונקציה ()valueOf, המחפשת איבר ע"פ השם שלו.
    1. ניתן להציץ בקוד המקור של ה Abstract Enum Class כאן.
  6. לכל אובייקט ב enum יש 2 תכונות מובנות:
    1. name – (ששווה לשם האיבר), בחוסר תלות מ ()toString.
    2. ordinal – שהוא האינדקס של האיבר.
  7. תכונה אחרונה חשובה של enum היא הפונקציה ()values – המחזירה מערך של האיברים. לצורך הפלט – המרתי את המערך לרשימה.
  8. אני יכול לשנות את המחלקה ולהוסיף לה תכונות דרך הבנאי הראשי.
    הנה ל TwoColor הוספתי תכונה בשם value – שיש לכל אחד מהאיברים שלה.
הנה הפלט:

סיכום

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

שיהיה בהצלחה!

שלום, AWS Lambda!

למבדה, שירות ה FaaS של AWS, הוא שירות המאפשר להריץ "פונקציות" בצורה מנוהלת:
אין צורך לחשוב על שרתים, על תשתיות, High Availability ו Fault tolerance, או על Scaling.

אתם כותבים את הפונקציה, ומוסיפים קצת הגדרות.
שירות למבדה יעשה עבורכם את הניהול: הקצאת CPU, רשת ו I/O, זמינות, טיפול ב scale, וכו'.

ללמבדה יש גם גם כמה נקודות שכדאי להיזהר איתן:

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

בעת כתיבת הפוסט, השירות תומך בסביבות הריצה של Java, Node.js, Python, ו #C.
עם מעט "tweaking", ניתן להריץ שפות נוספות כמו Go על גבי סביבות הריצה הקיימות.

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

מקור: אמזון

שלום, למבדה!

הנה פונקציית ה Hello World בלמבדה. היא מאוד פשוטה.

ה event הוא אובייקט ה input שלנו, הוא יכיל את כל המידע שזמין להפעלת פונקציית הלמבדה. פונקציית למבדה היא מעין "טריגר ל event" – ועל כן המינוח.
בג'אווה וב #C יש וריאציה בה ניתן לקבל את ה input כ stream.

ה context הוא אובייקט בעזרתו אנחנו מתקשרים עם סביבת הריצה של למבדה, למשל: לבדוק כמה זמן ריצה נותר לנו (()context.getRemainingTimeInMillis) או כדי לקבוע את תוצאת הרצת הפונקציה (succeed או fail).

ה callback ספציפי למימוש של Node.js – ולו קוראים כאשר סיימנו את הפעולה (אם אנחנו רוצים לשדר פלט).
הפרמטר הראשון הוא error (אם יש), השני הוא אובייקט התוצאה, שיעבור ()JSON.stringify.

מדוע בחרתי ב node.js עבור הדוגמה?
זו הסביבה הכי קלה לשימוש והכי מתועדת של למבדה. ג'אווהסקריפט היא קלילה (זמן טעינה מהיר) ואינה צורכת הרבה זיכרון – מה שטוב עבור פונקציות למבדה. גם פייטון נמצאת במקום טוב, אבל התיעוד על Java ו #C – נמצא מאחור.

מה עושים עם הקוד? "איפה שמים אותו"?
בואו נראה קצת מסכים (מה AWS Console) – ה UI עוזר לשקף דברים שלא נראה ב aws-cli:

הלכתי ב AWS Console (קרי – ה UI) לאזור של למבדה, ויצרתי פונקציה חדשה.
אני אבחר את ה template הריק. באופן כללי אני לא אוהב להסתמך על templates…

טריגרים? – לא מעניינים אותי. אני רוצה רק קוד! נקסט!

  1. שם הפונקציה, כפי שיופיע ב console ובכלי האדמיניסטרציה.
  2. כאן בוחרים סביבת-ריצה. לסביבות השונות יש defaults שונים וגם פרמטרים שונים לקונפיגורציה.
  3. יש אופציה להקליד את קוד הפונקציה בתוך online editor – אבל בסביבה אמיתית הרבה יותר הגיוני לטעון את הקוד ל S3 – ולהשתמש בו משם. ממש path לשם הקובץ.

הנה עוד הגדרות, והן קצת יותר מעניינות:

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

    1. ללמבדה יש monitoring שיראו לנו אם הפונקציה שלנו מתקרבת לקצה הזיכרון שמוקצה לה (או כשלה בשל מחזור בזיכרון) – ואז אפשר להגדיל את נפח הזיכרון. המקסימום הוא 1.5GB.
    2. החיוב בלמבדה נעשה ע"פ GB-second שנצרכו ע"י הפונקציה, כאשר אמזון מעגלת את זמן ריצת הפונקציה לרזולוציה של 100ms כלפי מעלה. פונקציה שרצה במשך 6ms – תחויב בעשירית GB-second על ההרצה הספציפית.
    3. למבדה תקצה CPU לפונקציה ע"פ הזיכרון שהוגדר. לא מפורט כמה CPU זה יהיה, אך יש קשר ישיר בין כמות הזיכרון שהוקצתה – ל CPU שיוקצה: על מכונה עם 4GB זכרון, פונקציה שהוקצה לה 1GB זיכרון – תקבל 25% מה CPU time – יחס ישר. המודל הזה מפשט לאמזון את ה scheduling של invocation של פונקציות – לחומרה הזמינה. הגיוני.
      1. המשמעות הראשונה היא שאם יש לי פונקציה שזקוקה להרבה CPU, ומעט זיכרון – יהיה עלי להקצות עבורה הרבה זיכרון בכדי לקבל חלק גדול יותר מה CPU.
        בחישובי עלות, פעמים רבות יהיה יותר זול להקצות לפונקציה הרעבה ל CPU יותר זיכרון/CPU. היא תרוץ מהר יותר – וכף נחוייב על פחות GB-sec.
      2. למרות שאין תיעוד ברור בנושא, נראה שמעל הקצאה של 1GB – ייתכן ופונקציית הלמבדה תקבל הקצאה של שני cpu cores. אין מניעה להשתמש ב threads בתוך פונקציית למבדה.
    4. מעניין לציין, שה default ב UI של nodeJs הוא 128MB זיכרון, בעוד זה של ג'אווה הוא 512MB זיכרון. לא קשה להגיע בג'אווה לצריכה גבוהה של זיכרון – בשל tradeoff תכנוני שנלקח ע"י מתכנני ג'אווה וה JVM. אמזון לא רוצה להכשיל אתכם – ולכן מקצה ב default גבוה מספיק עבור רוב הפונקציות האפשריות.
  2. עלי גם להגדיר timeout להרצת הפונקציה. ישנן פונקציות ש invoication שלהן עשוי לארוך דקה או שתיים – וזה בסדר. בפונקציה כמו שלי ("שלום עולם") – זמן ריצה של דקה משמעו באג שגרם ל infinite loop, שיגרום לי לשלם הרבה יותר ממה שהתכוונתי. האחריות על ה tradeoff בין סיכון לקטיעת הפונקציה ובין סיכון לתשלום מוגזם – היא על המשתמש (אבל ה default הוא הגיוני).
    1. לא ניתן כיום לקבוע timeout ארוך מ 5 דקות לפונקציה. אם יש לכם עיבוד כבד (נאמר: ETL) – אזי יהיה עליכם לשבור את העבודה ל chunks קטנים יותר. זה בריא גם בשבילכם מהסיבות הנ"ל.
  3. כאן אני מצביע על נקודת ההרצה של הפונקציה (ה "main" שלה).
    במקרה של nodejs, אם שם הקובץ שלי הוא index.js, ועשיתי export לפונצקיה בשם handler אזי עלי להקליד "index.handler". לכל סביבת ריצה יש חוקים מעט שונים.
  4. אלו הן הרשאות הריצה (execution) של הפונקציה – הרשאות לגשת לשירותים אחרים של AWS.
    יצרתי role עם הרשאות ה default (קרי basic execution policy – גישה לכתיבת לוגים וזהו) – וקראתי לו lambda_basic_execution – שאוכל להשתמש בו בפונקציות נוספות.

אני ממשיך הלאה, מאשר את יצירת הפונקציה, ומגיע למסך ניהול הפונקציה:

הוספתי שורת קוד של logging בכדי להדגים את כלי האדמיניסטרציה של למבדה. היכולת לכתוב לוגים היא חשובה מאוד – זו הדרך הכי יעילה לבדוק איך הפונקציה רצה. ב nodeJS פעולת logging נעשית באמצעות console.log (הרי "קל" לדרוס את console). בג'אווה, למשל, מקבלים את ה Logger מתוך ה context.

אני יכול ללחוץ על פתור "Test" – ולראות את הפונקציה שלנו בפעולה!

  1. הנה ה output של ריצת-הבדיקה. יש פלט – זה כבר טוב! אחרת הייתה לי הודעת שגיאה.
  2. הנה הלוג של ריצת-הבדיקה – אני יכול לראות שם את הלוג שכתבתי.
  3. מאחר ולא הרצתי את הפונקציה לאחרונה, אנו רואים ביצועים של cold state. בהרצות הבאות שאריץ בטווח של דקות – הביצוע ייקח פחות מ 1ms (זמן הביצוע הוא רק של הקוד שלי, ולא כולל את החלק של למבדה). ה cold start – הוא נושא לפוסט המשך.
  4. הנה אפשר לראות את צריכת הזכרון של ההרצה. בהרצה עוקבת הזיכרון מעט יותר גבוה: 22-24MB. מדוע? – פוסט המשך.
כמובן, שברגע שאני רוצה שהפונקציה שלי תהיה reproducible (ליצור אותה קודם על סביבת בדיקות ורק אז ליצור בדיוק אותו דבר בסביבת הפרודקשיין), אני לא אשתמש ב UI אלא בכלי ניהול תצורה כמו Terraform בכדי לייצר אותה.

למבדה Prison Break

איזה יופי! איזו גאווה! כתבנו פונצקיית למבדה שרצה. אשכרה רצה!
אני לוחץ שוב, ושוב על כפתור ה "Test" – ואני מרוצה.

אבל נניח שאני רוצה לקרוא לה ממקור שאינו ה UI של אמזון. כרגע, זה לא אפשרי…

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

זוכרים את הטריגר שדילגנו עליו למעלה, ממש בהתחלה? – הגיע הזמן להשלים אותו.

לפונקציות למבדה יש שני סוגי הרשאות:

  • הרשאות ריצה (Execution) – הרשאות לגשת לשירותים אחרים של AWS.
    • את ההרשאות האלו מגדירים כ IAM role – כמו "lambda_basic_execution" שהגדרנו למעלה.
    • בתיעוד של למבדה קוראים לחלק הזה גם בשם Pull Model – מה הפונקציה שלכם יכולה "למשוך".
    • לפעמים הטריגר של הפונקציה יהיה רק scheduler ("רוצי כל 5 דקות") ואז נפונקציה תקרא ל SQS או Kinesis – למשוך משם נתונים ולטפל בהם.
  • הרשאות הפעלה (Invocation) – הרשאות הנדרשות ע"י ה trigger / event source – על מנת להפעיל את פונקצית הלמבדה.
    • את ההרשאות מגדירים גם כ IAM role – אבל על מי שרוצה לקרוא ללמבדה, למשל: API ב API Gateway.
    • בתיעוד של למבדה קוראים לחלק הזה גם בשם Push Model – מי מפעיל את הפונקציה שלכם.
נגדיר טריגר מסוג AWS API Gateway.

כמובן שעדיף להגדיר IAM role, אבל כרגע לצורך הדוגמה – אני בוחר ב "Open": כל מי שיש לו את ה URL יכול להפעיל את הפונקציה (ולחייב אותי).

סיימנו. תוכנית הבריחה הושלמה!

אני לוחץ על קישור 1 – שהוא ה URL של ה API שיצרתי:

אופס! ב Prison Break, כמו ב Prison Break – תוכניות משתבשות. צריך לעבוד על עוד משהו.
אני בודק שוב: הפונקציה שלי תקינה.

אז מה הבעיה?

בלמבדה זו שאלה שתשאלו את עצמכם לא מעט. כלי העבודה העיקרי – הוא לוגים.

לכן אני אלחץ על קישור 2 – שלוקח אותי ל view הכללי  של ה API שהגדרתי ב API Gateway. משמעות המונח "ANY" = כל מתודות ה HTTP.

המסך הזה ממש "מצייר" את ה flow שמתרחש: מהלקוח, דרך ה API Gateway (קודם צד ה HTTP, ואז צד ה Integration / Transformation), עד ללמבדה – ובחזרה.

אני יכול להקליד על 1 לראות את מהות האינטגרציה. מכיוון שה Integration type הוא lambda_proxy – אזי כמעט ואין מה להגדיר. כמעט הכל מנוהל ע"י אמזון. כנ"ל לגבי הטרנפורמציה בחזרה.
קישור 2 – מוביל אותי חזרה למסך של ניהול פונקציית הלמבדה שלי.
אני לוחץ על קישור 3 – שמאפשר לי לבדוק, מקצה לקצה, את ה API ביחד עם פונקציית הלמבדה.
שם, בתוך הלוג – אני מוצא את הבעיה:

לפני הטרנספורמציה הכל נראה בסדר.
שניה! איזו טרנספורמציה?

קריאת ה HTTP עצמה לא מתאימה בדיוק לאובייקט ה event שאנחנו מקבלים. מישהו לקח את ה HTTP payload (טקסט רציף), פרסר אותו וסידר אותו יפה במבנה היררכי של פרמטרים. מי שעשה את זה הוא ה lambada_proxy של ה API gateway: הוא המיר את ה HTTP למבנה json שלמבדה יודעת לקבל ולעטוף באובייקט ה event.

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

הנה, שינינו את הקוד למבנה המצופה ע"י ה lamda_proxy והנה התוצאה:

איזה כיף!

סיכום

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

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

מקווה שהצלחנו.

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

עדכון: הנה חלק ב' של הפוסט.

שיהיה בהצלחה!

רפרנסים

מדריך למפתח של אמזון על פונקציות למבדה
AWS Lambda Blog

רברסים 2017

כנס רברסים 2017 מגיע עלינו לטובה.
לפני כמה ימים נסתיים שלב הגשת ההצעות – והשבוע מצביעים על התוכן שיוצג.
הכנס יתקיים השנה במכללה למנהל שבראשון לציון.

אם אתם לא מכירים את כנס רברסים – חפשו בגוגל…
לדעתי זה הכנס הכי משמעותי בעולם התוכנה שמתקיים בישראל.
אני חושב שחוץ מאשר הגימיקים (שזה שטויות) – הוא משתווה לכנסים הטובים ברמה הבין לאומית דוגמת QCON ו/או ;GOTO.

כעת, יש לכם הזדמנות להשפיע – כמות הצביעים היא לא כ\"כ גדולה.
אחרי שתצביעו – אתם כבר \"בפנים\". יעניין אתכם לראות איזה אג\'נדה יצאה בסוף… הבחירה שלכם – מול של כלל האנשים.

אני הצעתי סשן על Effective Software Design (או ESD) – שיתבסס על פוסט באותו נושא שפרסמתי לא מזמן.
נתקלתי בעוד 20~ הצעות של אנשים שאני מכיר – שזה תמיד נחמד!

הצביעו לסשנים שנראה לכם שתרצו ללכת אליהם. אני הצבעתי 😇.

איך מצביעים:

  • נרשמים באתר: https://summit2017.reversim.com/
    • אני מקווה שישלחו למי שנרשם לאתר תזכורת להירשם לכנס. כל המקומות נתפסים בד\"כ ביום הראשון להרשמה.
  • ניגשים להצעות: https://summit2017.reversim.com/proposals
יש כ 330 סשנים, ואין דרך כ\"כ יעילה לפלטר אותם, ה tags הם בקשר של \"and\" – מה שהופך בחירה של כמה tags לדבר לא יעיל.

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

כשאתם מוצאים סשן שנראה מעניין – פתחו את הליק למטה (\"Show more\", אפשר גם פשוט להקליד על הכותרת) בטאב חדש – שלא תצטרכו להתחיל אח\"כ מהתחלה.

אחרי שהצבעתם – אפשר לסגור את הטאב ולהמשיך לגלול.

ככה לפחות אני עבדתי.

שיהיה בהצלחה!