WEBVTT

00:00:00.000 --> 00:00:03.620
הנושא של היום הוא כזה שכמעט כולם שמעו עליו, אבל כמעט אף אחד לא יכול להסביר.

00:00:03.760 --> 00:00:05.020
ללא שרת, serverless.

00:00:05.180 --> 00:00:08.820
מה זה בעצם? האם זה באמת רק קוד שרץ על כלום, או שזה משהו הרבה יותר גדול?

00:00:09.000 --> 00:00:12.140
בואו נעשה סדר בדברים. ללא שרת, לא אומר שאין שרתים.

00:00:12.340 --> 00:00:16.440
זה אומר שאתם לא צריכים לחשוב עליהם, וההבחנה הזו משנה הכל באופן שבו בונים תוכנה.

00:00:16.580 --> 00:00:21.720
בסוף הפרק הזה, תבינו מה הם באמת Azure Functions, איך התמחור באמת עובד ומתי כדאי להשתמש בהם.

00:00:21.840 --> 00:00:24.840
נפרק את זה לאבני בניין, נתחיל עם המיתוס הכי גדול.

00:00:24.840 --> 00:00:29.000
מה המשמעות האמיתית של ללא שרת? בואו נפריך כמה מיתוסים כבר עכשיו.

00:00:29.140 --> 00:00:32.600
השם ללא שרת, הוא מונח השיווק הגרוע ביותר שמייקרוסופט אי פעם המציע.

00:00:32.760 --> 00:00:35.020
זה גורם לאנשים לחשוב שאין שום שרת מעורב.

00:00:35.180 --> 00:00:37.300
זה לא נכון. יש שרתים, המון כאלה.

00:00:37.420 --> 00:00:38.960
פשוט לעולם לא צריך לגעת בהם.

00:00:39.080 --> 00:00:42.800
לפני 20 שנה, אם רצית להריץ קטע קוד באינטרנט, היית צריך לעבוד קשה.

00:00:42.960 --> 00:00:47.680
היית סוחר מכונה וירטואלית, מתקין מערכת הפעלה, מגדיר שרת אינטרנט ופורס את האפליקציה שלך.

00:00:47.680 --> 00:00:52.580
ואז היית מבלה כל סוף שבוע בהתקנת עדכוני הבטחה ומבדה שהדבר הזה לא יקרוס בית מינוס 3 לפנות בוקר.

00:00:52.680 --> 00:00:53.480
והנה הקטע.

00:00:53.640 --> 00:00:56.340
שילמת על השרת הזה בין אם הקוד שלך רץ ובין אם לא.

00:00:56.460 --> 00:00:59.180
הוא ישב שם וזמזם, שורף כסף בזמן שישנת.

00:00:59.320 --> 00:01:01.680
ללא שרת, הופך את כל המודל הזה על פיו.

00:01:01.820 --> 00:01:05.260
אתה כותב את הקוד, מעלה אותו, והפלטפורמה מטפלת בכל השאר.

00:01:05.400 --> 00:01:08.580
מערכת ההפעלה, עדכוני הבטחה, יכולת גדילה וזמינות.

00:01:08.580 --> 00:01:11.220
התפקיד שלך הוא רק לכתוב את הלוגיקה שחשובה.

00:01:11.300 --> 00:01:15.660
תחשבו על זה כמו ההבדל בין ניהול מטבח של מסעדה לבין שימוש במכונה לממקר אוטומטי.

00:01:15.780 --> 00:01:19.300
מטבח של מסעדה צריך צוות מלא, אספקה קבועה ותחזוקה.

00:01:19.440 --> 00:01:22.580
זה עולה כסף בכל יום, גם אם אף אחד לא נכנס בדלת.

00:01:22.680 --> 00:01:26.960
מכונה לממקר אוטומטי, היא יושבת שם בפינה ולא עושה כלום עד שמישהו לוחץ על כפתור.

00:01:27.120 --> 00:01:29.980
אז היא מתעוררת לחיים, עושה את העבודה שלה וחוזרת לישון.

00:01:29.980 --> 00:01:32.220
אתם משלמים על החשמל רק כשהיא באמת עובדת.

00:01:32.380 --> 00:01:34.040
זה, ללא שרת על קצה המזלג.

00:01:34.160 --> 00:01:36.300
Azure Functions היא הגרסה של מייקרוסופט לזה.

00:01:36.440 --> 00:01:38.760
היא מריצה קטעי קוד קטנים בתגובה לאירועים.

00:01:38.920 --> 00:01:43.160
הקוד שלכם רדום עד שמשהו מאיר אותו, אז הוא רץ מסיים וחוזר לישון.

00:01:43.320 --> 00:01:45.080
אז, איך הקוד הזה באמת נראה?

00:01:45.200 --> 00:01:46.480
מה הם Azure Functions?

00:01:46.680 --> 00:01:49.740
פונקציה היא קטע קוד בודד שעושה עבודה ספציפית אחת.

00:01:49.920 --> 00:01:50.480
זה הכל.

00:01:50.640 --> 00:01:54.480
זו לא אפליקציה שלמה עם דף התחברות, בסיס נתונים וו-20 עסקים.

00:01:54.480 --> 00:01:56.020
זו משימה אחת ממוקדת.

00:01:56.120 --> 00:02:01.180
תחשבו על זה כמו על מתג תאורה בבית, או קבוי או דולק ועובד, ואז חוזר למצב קבוי.

00:02:01.300 --> 00:02:08.320
שרת אינטרנט מסורתי הוא ההפך, כמו להשאיר את כל האורות בבית דולקים 24 שעות בממה, 7 ימים בשבוע, גם כשאין אף אחד בבית.

00:02:08.440 --> 00:02:11.180
Azure Functions תומכות במגוון רחב של שפות תכנות.

00:02:11.340 --> 00:02:15.640
אתם יכולים להשתמש במה שנוח לכם, JavaScript, Python, C-H, Java, PowerShell.

00:02:15.760 --> 00:02:16.920
אין כאן תשובה אחת נכונה.

00:02:17.100 --> 00:02:18.760
בחרו את השפה שאתם כבר מכירים.

00:02:18.760 --> 00:02:20.760
עכשיו, בואו נעשה סדר בבלבול נפוץ.

00:02:20.880 --> 00:02:23.120
אפליקציית פונקציה היא לא אותו דבר כמו פונקציה.

00:02:23.280 --> 00:02:24.960
אפליקציית הפונקציה היא הקונטיינר.

00:02:25.060 --> 00:02:26.540
תחשבו על זה כמו על ארגז כלים.

00:02:26.700 --> 00:02:30.260
אתם יוצרים אפליקציית פונקציה אחת, ובתוך ארגז הכלים הזה אתם מוסיפים פונקציות מרובות.

00:02:30.420 --> 00:02:32.780
כל פונקציה היא כלי נפרד שעושה את העבודה שלו.

00:02:32.940 --> 00:02:38.520
יכולה להיות לכם פונקציה אחת שמטפלת בהרשמות משתמשים, אחרת שמאבדת תמונות שהוא עלו, ושלישית ששולחת דוחות ליליים.

00:02:38.520 --> 00:02:41.380
כולן חיות באותו ארגז כלים, אבל עובדות באופן עצמאי.

00:02:41.480 --> 00:02:44.600
עוד דבר אחד על פונקציות, הן חסרות מצב, סטייטלס, מעצם הייצוב שלהן.

00:02:44.740 --> 00:02:46.820
זה אומר שהן לא זוכרות כלום בין הרצה להרצה.

00:02:46.940 --> 00:02:49.600
אם הפונקציה שלכם מאבדת קובץ ומסיימת, זה הכל.

00:02:49.740 --> 00:02:52.740
בפעם הבאה שהיא תרוץ, היא תתחיל מחדש ללא זיכרון מהפעם הקודמת.

00:02:52.860 --> 00:02:56.260
זה נשמע כמו מגבלה, אבל זו למעשה התכונה שהופכת אותן לכל כך עוצמתיות.

00:02:56.260 --> 00:02:58.320
מכיוון שפונקציות לא מחזיקות זיכרון או מצב,

00:02:58.320 --> 00:03:02.080
Azure יכולה להפעיל מאה עותקים של הפונקציה שלכם באופן מיידי כשאומס התעבורה עולה,

00:03:02.200 --> 00:03:03.920
ולסגור אותם באותה מהירות כשהאומס יורד.

00:03:04.040 --> 00:03:06.980
כך אתם מקבלים יכולת הרחבה מבלי לשלם על שרתים בטלים.

00:03:07.180 --> 00:03:10.880
הנה השאלה, אם פונקציה רק יושבת שם ולא עושה כלום עד שמשהו מאיר אותה,

00:03:11.000 --> 00:03:11.820
מה בעצם מאיר אותה?

00:03:11.900 --> 00:03:13.900
כאן נכנסים לתמונה הטריגרים, Triggers.

00:03:14.100 --> 00:03:15.200
טריגרים הם המתי.

00:03:15.200 --> 00:03:18.200
לכל פונקציה חייב להיות טריגר אחד בדיוק, וזה לא רשות.

00:03:18.200 --> 00:03:20.560
הטריגר הוא האירוע שמעיר את הפונקציה שלכם.

00:03:20.700 --> 00:03:23.400
בלעדיו, הקוד שלכם פשוט יושב שם ולא עושה שום דבר בכלל.

00:03:23.560 --> 00:03:25.220
תחשבו על טריגרים כמו על פעמון דלת.

00:03:25.360 --> 00:03:27.340
הפונקציה שלכם נמצאת בתוך הבית ומחכה.

00:03:27.440 --> 00:03:28.580
היא יכולה לחכות לנצח.

00:03:28.760 --> 00:03:31.140
שום דבר לא קורה עד שמישהו מצלצל בפעמון הדלת.

00:03:31.200 --> 00:03:34.900
ואז הפונקציה קופצת לפעולה, עונה לדלת, עושה את העבודה שלה וחוזרת להמתנה.

00:03:34.900 --> 00:03:37.700
ישנם ארבעה טריגרים שמתחילים נתקלים בהם הכי הרבה.

00:03:37.820 --> 00:03:40.600
טריגר ה-HTTP הוא נקודת ההתחלה הנפוצה ביותר.

00:03:40.740 --> 00:03:44.700
מי שהוא מבקר בכתובת URL או מבצע קריאת API, והפונקציה שלכם מופעלת.

00:03:44.800 --> 00:03:47.900
כך בונים APIs כלילים מבלי להגדיר שרת אינטרנט מלא.

00:03:48.060 --> 00:03:50.920
ויש גם את טריגר הטיימר שרץ לפי לוח זמנים.

00:03:50.920 --> 00:03:58.000
אתה מגדיר ביטוי קרון, למשל הפעלה בכל שעה או בחצות בכל לילה, והפונקציה שלך תופעל בדיוק בזמנים האלה.

00:03:58.100 --> 00:04:01.780
מושלם למשימות תחזוקה, עבודות ניקוי או יצירת דוחות ליליים.

00:04:01.780 --> 00:04:05.080
טריגר הבלוב מופעל כאשר קובץ מעולה ל-Azure Storage.

00:04:05.240 --> 00:04:07.920
נניח שמישהו מעלה קובץ PDF לתקיעה ספציפית.

00:04:08.040 --> 00:04:11.640
טריגר הבלוב מזהה את ההעלה הזו ומריץ את הפונקציה שלך באופן אוטומטי.

00:04:11.800 --> 00:04:14.820
זה מצוין לאיבוד תמונה, המרת מסמכים ואימות קבצים.

00:04:14.820 --> 00:04:17.920
וטריגר התור, Q, מופעל כאשר הודעה מופיעה בתור.

00:04:18.020 --> 00:04:20.940
תורים הם דרך לנתק בין חלקים שונים של המערכת שלך.

00:04:20.940 --> 00:04:25.520
שירות אחד מניח הודעה בתור, והפונקציה שלך אוספת אותה ומאבדת אותה כשהיא מוכנה.

00:04:25.720 --> 00:04:28.340
זה מונע משירות ET1 לחסום את כל השאר.

00:04:28.480 --> 00:04:29.800
הנה הנקודה המרכזית.

00:04:29.940 --> 00:04:33.440
כאשר טריגר מופעל, הוא מעביר נתונים לפונקציה שלך באופן אוטומטי.

00:04:33.440 --> 00:04:36.300
אתה לא צריך לבצע סקר, פולינג, או לבדוק אם קרה משהו.

00:04:36.420 --> 00:04:39.680
הטריגר מגיש לך את כל מה שצריך, והפונקציה שלך רק מאבדת את זה.

00:04:39.800 --> 00:04:42.600
פונקציה ללא טריגר היא סתם קוד שיושב ולא עושה כלום.

00:04:42.720 --> 00:04:44.200
הטריגר הוא מה שנותן לה מטרה.

00:04:44.360 --> 00:04:46.660
אז, הטריגר אומר לפונקציה שלך מתי לרוץ.

00:04:46.780 --> 00:04:48.900
אבל מאיפה מגיעים הנתונים ולאן הם הולכים?

00:04:49.040 --> 00:04:50.660
כאן נכנסים לתמונה הביינדינגס.

00:04:50.740 --> 00:04:53.460
קישורים, ביינדינגס, נתונים נכנסים, נתונים יוצאים.

00:04:53.460 --> 00:04:58.620
קישורים הם דרך לומר לפונקציה שלך אילו נתונים לקרוא ולאן לשלוח תוצאות בלי לכתוב את כל הקוד המיותר.

00:04:58.740 --> 00:05:00.460
זה מורכב, אז תן לי לפשט את זה.

00:05:00.600 --> 00:05:01.620
קיימים שני סוגים.

00:05:01.620 --> 00:05:04.080
קישורי קלט, input bindings, מכניסים נתונים לפונקציה שלך.

00:05:04.180 --> 00:05:06.660
קישורי פלט, output bindings, שולחים נתונים החוצה.

00:05:06.760 --> 00:05:11.780
בלי קישורים, היית צריך לכתוב קוד SDK בכל פעם שרצית לתקשר עם חשבון נכסון, בסיס נתונים או תור.

00:05:11.780 --> 00:05:16.860
היית צריך לטפל במכרוזות חיבור, לנהל ניסיונות חוזרים, לבצע סריאליזציה על נתונים ודסריאליסציה לתגובות.

00:05:17.000 --> 00:05:19.040
זה המון קוד תשתית רק בשביל לקרוא קובץ.

00:05:19.160 --> 00:05:21.300
עם קישורים, אתה רק מצהיר על מה שאתה צריך.

00:05:21.400 --> 00:05:25.280
אתה אומר, אני רוצה לקרוא מקונטיינר הבלוב הזה, או, אני רוצה לכתוב לתור הזה.

00:05:25.480 --> 00:05:27.260
סביבת ההרצה דואגת לכל השאר.

00:05:27.400 --> 00:05:31.240
היא פותחת את החיבור, קוראת את הנתונים ומעבירה אותם לפונקציה שלך כפרמטר.

00:05:31.240 --> 00:05:35.360
כשהפונקציה מסיימת, היא לוקחת את ערך ההחזרה וחוטבת אותו לאן שציינת.

00:05:35.460 --> 00:05:37.140
תחשוב על קישורים כמו על צינורות.

00:05:37.300 --> 00:05:40.440
אתה מחבר את הפונקציה שלך לחשבון נכסון, בסיס נתונים או תור.

00:05:40.600 --> 00:05:43.120
הנתונים זורמים דרך הצינורות האלה באופן אוטומטי.

00:05:43.120 --> 00:05:45.580
הפונקציה שלך לא צריכה לדעת איך הצינורות עובדים.

00:05:45.680 --> 00:05:48.240
היא רק מקבלת את מה שעובר ושולחת את מה שצריך לצאת.

00:05:48.400 --> 00:05:49.540
הנה דוגמה קונקרטית.

00:05:49.660 --> 00:05:51.620
נניח שיש לך קישור קלט מסוג בלוב.

00:05:51.620 --> 00:05:55.760
כשהפונקציה שלך מתחילה, היא קוראת אוטומטית קובץ מהיחסון הבלוב ומגישה לך אותו כפרמטר.

00:05:55.860 --> 00:05:57.660
אינך צריך לכתוב קוד SDK להיחסון.

00:05:57.820 --> 00:05:59.660
אתה פשוט מקבל את הנתונים ומעבד אותם.

00:05:59.760 --> 00:06:01.860
דוגמה נוספת, קישור, ביינדינג, פלט לתור.

00:06:02.000 --> 00:06:04.660
הפונקציה שלך מעבדת משהו, ובסוף, אתה מחזיר ערך.

00:06:04.820 --> 00:06:08.160
סביבת ההרצה לוקחת את הערך הזה, ממירה אותו לפורמט סידורי ומכניסה אותו לתור.

00:06:08.300 --> 00:06:09.740
אינך צריך לכתוב שום קוד לתור.

00:06:09.880 --> 00:06:10.940
אתה רק מחזיר ערך.

00:06:11.120 --> 00:06:12.300
קישורים הם אופציונליים.

00:06:12.300 --> 00:06:14.640
אתה יכול להשתמש באפס, אחד או הרבה מהם.

00:06:14.760 --> 00:06:17.240
יש פונקציות שזקוקות רק לטריגר ללא קישורים בכלל.

00:06:17.420 --> 00:06:20.460
אחרות עשויות להזדקק לשלושה או ארבעה קישורים לשירותים שונים.

00:06:20.460 --> 00:06:24.200
השילוב של טריגרים וקישורים הוא מה שהופך את Azure Functions לכל כך עוצמתיות.

00:06:24.380 --> 00:06:27.440
אתה כותב את הלוגיקה העסקית, את קוד קבלת ההחלטות בפועל.

00:06:27.560 --> 00:06:29.620
הפלטפורמה מטפלת בכל האינטגרציה.

00:06:29.780 --> 00:06:33.080
הפונקציה שלך נשארת קטנה, ממוקדת וקלה להבנה.

00:06:33.740 --> 00:06:34.740
סיפור התמחור.

00:06:34.880 --> 00:06:37.040
התמחור הוא מה שמפתיע את רוב המתחילים.

00:06:37.220 --> 00:06:41.900
עבור רוב האנשים, תוכנית הצריכה היא ברירת המחדל, וכדאי להתחיל איתה בית מינוס 90% מהמקרים.

00:06:42.080 --> 00:06:42.980
הנה איך זה עובד.

00:06:42.980 --> 00:06:45.380
אתה משלם רק כשהפונקציה שלך באמת רצה.

00:06:45.480 --> 00:06:47.540
כשהיא במצב המתנה, אתה לא משלם כלום.

00:06:47.680 --> 00:06:48.740
אפס, לא פרוטה.

00:06:48.900 --> 00:06:50.580
שני מרכיבים מרכיבים את החשבון.

00:06:50.760 --> 00:06:54.140
ראשית, מספר ההרצות, כמה פעמים הפונקציה שלך מופעלת.

00:06:54.300 --> 00:06:57.680
שנית, זמן ההרצה, שנמדד במשהו שנקרא GB שניות.

00:06:57.860 --> 00:07:01.380
זה בעצם כמה זמן הפונקציה שלך הרצה כפול כמה זיכרון היא צרכה.

00:07:01.480 --> 00:07:02.900
המענק החינמי הוא נדיב.

00:07:03.040 --> 00:07:07.300
אתה מקבל מיליון הרצות בחודש וב מינוס 400 אלף ג'יגבייט שניות בחינם לחלוטין.

00:07:07.300 --> 00:07:11.500
עבור רוב הפרויקטים הקטנים, אפליקציות תחביב ועבות טיפוס, לעולם לא תשלם סנט.

00:07:11.660 --> 00:07:15.180
לעולם, אם אתה עובר את המענק החינמי, התעריפים עדיין זולים להפליט.

00:07:15.260 --> 00:07:16.760
20 סנט למיליון הרצות.

00:07:16.940 --> 00:07:17.800
זו לא טעות דפוס.

00:07:17.960 --> 00:07:19.520
20 סנט עבור מיליון הרצות.

00:07:19.700 --> 00:07:22.480
תחשוב על זה כמו לשלם על חשמל רק כשאתה מדליק את המתג.

00:07:22.620 --> 00:07:25.360
אין תשלום חודשי בסיסי על עצם קיום החיבות בקירות שלך.

00:07:25.500 --> 00:07:27.540
אתה משלם רק על הכוח שאתה באמת צורך.

00:07:27.640 --> 00:07:29.080
כעת, ישנן תוכניות אחרות.

00:07:29.080 --> 00:07:32.040
פלקס קונסמפשון היא חדשה יותר ומעניקה לך תמיכה ברשת וירטואלית.

00:07:32.140 --> 00:07:33.900
פרימיום שומרת על הפונקציות שלך חמות תמיד.

00:07:34.060 --> 00:07:35.260
כך שאין עיכוב, התנאה קרה.

00:07:35.440 --> 00:07:38.580
דדיקייטד נותנת לך קיבולת קבועה בתוכנית שירות אפליקציות מסורתית.

00:07:38.700 --> 00:07:41.480
אבל כדי להתחיל, קונסמפשון היא הבחירה הנכונה כמעט תמיד.

00:07:41.660 --> 00:07:46.360
אז הרע אחת, בכל זאת, המענק החינמי משותף בין כל אפליקציות הפונקציות שלך באותו מנוי.

00:07:46.360 --> 00:07:50.080
אם יש לך עשר אפליקציות פונקציה, כולן צורכות מאותו מיליון הרצות חינמיות.

00:07:50.220 --> 00:07:52.820
אז שים לב לזה אם אתה מתחיל לבנות יותר מכמה בודדות.

00:07:53.000 --> 00:07:56.620
התמכור נהדר, אבל בואו נהפוך את זה לממשי בעזרת דוגמה קונקרטית.

00:07:56.760 --> 00:07:58.000
תרחיש מהעולם האמיתי.

00:07:58.140 --> 00:08:01.180
תארו לעצמכם שאתם מנהלים אתר שבו משתמשים מעלים תמונות פרופיל.

00:08:01.320 --> 00:08:04.060
התמונות האלה ענקיות בערך 10 מגה בייט כל אחת.

00:08:04.160 --> 00:08:05.760
וזה גורם לכמה בעיות אמיתיות.

00:08:05.760 --> 00:08:09.920
קבצים גדולים עולים יותר להיחסון, הם מעטים את האתר בכל פעם שמישהו טוען דף.

00:08:10.120 --> 00:08:12.760
והם מתסכלים את המשתמשים שצריכים לשבת ולחכות לתמונות.

00:08:12.860 --> 00:08:16.200
לכן, אתם צריכים דרך לחבץ את התמונות האלה באופן אוטומטי.

00:08:16.340 --> 00:08:19.720
ללא Azure Functions, הייתם צריכים לבנות עובד רקע מאפס.

00:08:19.920 --> 00:08:25.740
זה אומר להשיג שרת נפרד, להגדיר תור לניהול עומס העבודה, ולכתוב קוד שיתפל בכל החלקים הנעים.

00:08:25.920 --> 00:08:29.460
זו כמות עצומה של מורכבות מיותרת למה שהוא פשוט כמו קיבוץ תמונה.

00:08:29.460 --> 00:08:33.280
עם Azure Functions, כל מה שצריך זה טריגר של בלוב אחד ופונקציה אחת.

00:08:33.420 --> 00:08:35.200
אין שרתים שצריך לדאוג לגביהם.

00:08:35.320 --> 00:08:37.000
הרשו לי להסביר לכם איך זה עובד.

00:08:37.160 --> 00:08:40.900
משתמש מעלה תמונה דרך האתר שלכם, והקובץ נוחת ב-Azure Blob Storage.

00:08:41.080 --> 00:08:43.800
ברגע שהוא מגיע, טריגר של בלוב מופעל באופן אוטומטי.

00:08:43.900 --> 00:08:48.620
הפונקציה שלכם מתעוררת, מריצה את קוד הדחיסה, ושומרת את הגרסה הקטנה יותר חזרה להיחסון.

00:08:48.760 --> 00:08:50.040
כל זה קורה תוך שניות.

00:08:50.040 --> 00:08:54.580
המשתמש לעולם לא מחכה כי כל התהליך רץ מאחורי הקלעים, שקוף לחלוטין.

00:08:54.720 --> 00:08:59.000
הנה עוד דוגמה יומיומית, שליחת אימייל ברוכים הבאים כשמישהו נרשם לשירות שלכם.

00:08:59.120 --> 00:09:02.140
טריגר HTTP תופס את בקשת ההרשמה מהאתר שלכם.

00:09:02.260 --> 00:09:04.820
הפונקציה שלכם מופעלת, לוקחת את כתובת האימייל של המשתמש,

00:09:05.040 --> 00:09:07.040
שולחת הודעת ברוכים הבאים דרך סנדבריד, וזהו.

00:09:07.120 --> 00:09:09.340
המשתמש מקבל את האימייל שלא כמעט מיידית.

00:09:09.340 --> 00:09:13.900
אין שרת אימייל להגדיר, אין תור שליחה לנהל, רק פונקציה אחת, משימה אחת, וזהו.

00:09:14.000 --> 00:09:16.640
אלו הן בדיוק המשימות שעבורן עוצבו Azure Functions.

00:09:16.820 --> 00:09:19.100
משימות קטנות, ממוקדות ומבוססות אירועים.

00:09:19.260 --> 00:09:21.320
לא אפליקציות ענק, לא זרימות עבודה מורכבות,

00:09:21.500 --> 00:09:24.600
רק דבר אחד שנעשה היטב, שמופעל על ידי משהו שקורה במקום אחר.

00:09:24.760 --> 00:09:26.500
מתי להשתמש ב-Azure Functions?

00:09:26.660 --> 00:09:28.140
אז מתי כדאי לבחור בפונקציה?

00:09:28.340 --> 00:09:30.060
ומתי כדאי להשתמש במה שהוא אחר?

00:09:30.060 --> 00:09:31.620
הנה דרך מהירה להחליט.

00:09:31.760 --> 00:09:36.040
שלו את עצמכם אם המשימה קצרה, אם היא מבוססת אירועים, ואם היא ללא מצב, stateless.

00:09:36.200 --> 00:09:39.780
אם עניתם כן על כל השלושה, Azure Functions הוא כנראה הכלי הנכון.

00:09:39.980 --> 00:09:41.780
בואו נתחיל עם מקרי השימוש הטובים.

00:09:41.960 --> 00:09:44.220
API וWebhooks הם התאמה מושלמת.

00:09:44.380 --> 00:09:47.260
אתם צריכים נקודת קצה קלה שמגיבה לבקשת HTTP.

00:09:47.700 --> 00:09:52.000
עושה דבר אחד ומחזירה תוצאה, וזה בדיוק מה שתרגרים של HTTP נועדו עבורו.

00:09:52.120 --> 00:09:54.280
עיבוד קבצים ותמונות הוא עוד מקרה גדול.

00:09:54.280 --> 00:09:59.660
קובץ נוחת בהכסון, הפונקציה שלכם מופעלת, מאבדת אותו ושומרת את התוצאה, הכל ללא שרת.

00:09:59.820 --> 00:10:04.520
משימות מתוזמנות כמו ניקוי לילי או הפקת דוחות עובדות מצוין עם טריגרים מבוססי זמן.

00:10:04.740 --> 00:10:07.920
גם טרנספורמציה של נתונים עבור צינורות ETL היא נפוצה.

00:10:08.020 --> 00:10:13.080
ופונקציות הן דבק אינטגרציה מושלם, שמחבר בין שני שירותים שלא מדברים זה עם זה באופן טבעי.

00:10:13.180 --> 00:10:15.960
כעת, בואו נדבר על מתי פונקציות הן לא בחירה מתאימה.

00:10:15.960 --> 00:10:23.340
תהליכים ארוכים הם בעייתיים, כי בתוכנית הצריכה לפונקציות יש מגבלת זמן קצובה של 5 דקות כברירת מחדל או עד 10 דקות בהגדרה ידני.

00:10:23.520 --> 00:10:26.340
אם העבודה שלכם נמשכת זמן רב יותר, אתם צריכים משהו אחר.

00:10:26.500 --> 00:10:29.080
אפליקציות עם ניהול מצב, סטייטפור, הן התאמה לא נכונה נוספת.

00:10:29.180 --> 00:10:31.360
פונקציות לא זוכרות שום דבר בין הרצה להרצה.

00:10:31.480 --> 00:10:35.660
אם אתם צריכים לשמור על מצב של סשן או לעקוב אחר התקדמות בין שלבים, אתם פועלים נגד הייצוב שלהן.

00:10:35.660 --> 00:10:38.060
עומסי עבודה כבדים של חישוב הם גם לא מתאימים.

00:10:38.160 --> 00:10:42.680
אם אתם צריכים CPU עוצמתי למשך דקות או שעות, מכונה וירטואלית או קונטיינר הם בחירה טובה יותר.

00:10:42.880 --> 00:10:48.300
ותהליכי עבודה מורכבים, שבהם משימה אחת תלויה באחרת, מטופלים טוב יותר על ידי Durable Functions או Logic Apps.

00:10:48.460 --> 00:10:50.080
הנה סקירה מהירה של החלופות.

00:10:50.260 --> 00:10:53.500
Azure Logic Apps היא האפשרות ללא קוד, NO קוד, לחיבור שירותים.

00:10:53.660 --> 00:10:57.540
אם אתם לא צריכים לכתוב קוד מותאם אישית, Logic Apps יכולים לבצע את העבודה עם מעצב ויזואלי.

00:10:57.540 --> 00:11:01.180
Azure App Service מיועד לאפליקציות אינטרנט מלאות שרצות 24 שביעיות.

00:11:01.340 --> 00:11:04.820
אם אתם צריכים אתר אינטרנט מלא או API שתמיד פעיל, זה הכלי שלכם.

00:11:04.940 --> 00:11:09.020
Azure Container Apps נותן לכם מיקרו שירותים מבוססי קונטיינרים עם יותר שליטה על סביבת הריצה.

00:11:09.140 --> 00:11:13.060
ו-Azure Virtual Machines נותן לכם שליטה מלאה על מערכת ההפעלה אם תצטרכו זאת.

00:11:13.160 --> 00:11:14.400
הנה כלל אצבע פשוט.

00:11:14.580 --> 00:11:19.120
אם אתם יכולים לתאר את העבודה במשפט אחד, כנראה שזה מועמד טוב לפונקציה.

00:11:19.120 --> 00:11:21.020
תחיסת תמונות כשהן מועלות.

00:11:21.020 --> 00:11:23.600
שליחת מייל ברוכים הבאים כשמישהו נרשם.

00:11:23.760 --> 00:11:25.880
הרצת משימת ניקוי בכל לילה בחצות.

00:11:26.080 --> 00:11:28.360
משפט אחד, עבודה אחת, פונקציה אחת.

00:11:28.480 --> 00:11:30.660
טעויות נפוצות של מתחילים שיש להימנע מהן.

00:11:30.760 --> 00:11:33.300
עכשיו, בואו נדבר על כמה דברים שכדאי לשים לב עליהם.

00:11:33.400 --> 00:11:36.020
אלו הן הן הטעויות שמכשילות כמעט את כולם כשהם מתחילים.

00:11:36.160 --> 00:11:39.260
טעות נפוצה של מתחילים היא לחשוב שפונקציות הן תמיד בחינם.

00:11:39.260 --> 00:11:42.560
המענק החינם היא נדיב, אני יודע שמיליון הרצות נשמע הרבה.

00:11:42.800 --> 00:11:45.920
אבל אם הפונקציה שלכם הופכת לוויראלית או מותקפת על ידי בוט,

00:11:46.100 --> 00:11:47.560
ההרצות האלו מצטברות מהר.

00:11:47.680 --> 00:11:49.220
אז, עקבו אחרי השימוש שלכם,

00:11:49.380 --> 00:11:50.640
הגדירו התרעת תקציב באז'ר,

00:11:50.780 --> 00:11:52.260
ואל תופתעו מחשבון בסוף החודש.

00:11:52.380 --> 00:11:54.120
טעות נוספת היא התעלמות מהתחלות קרות,

00:11:54.260 --> 00:11:54.800
קולד סטארטס.

00:11:54.920 --> 00:11:57.220
בפעם הראשונה שהפונקציה שלכם רצה לאחר שהייתה במצב המתנה,

00:11:57.380 --> 00:11:58.100
זה לוקח זמן רב יותר.

00:11:58.260 --> 00:12:00.240
בתוכנית הצריכה, זה יכול לקחת כמה שניות.

00:12:00.240 --> 00:12:02.460
עבור רוב מקרי השימוש, זה בסדר גמור.

00:12:02.600 --> 00:12:06.160
אבל, אם אתם בונים API רגיש לשיהוי שבו כל מילי שנייה קובעת,

00:12:06.340 --> 00:12:08.780
שקלו את תוכנית הפרימיום או הפעילו מופעים שתמיד מוכנים.

00:12:08.940 --> 00:12:11.440
ויש גם כתיבת פונקציות שרצות זמן רב מדי.

00:12:11.580 --> 00:12:13.000
לתוכנית הצריכה יש זמן קצוב,

00:12:13.120 --> 00:12:15.560
5 דקות, כברירת מחדל, 10 דקות לכל היותר.

00:12:15.680 --> 00:12:18.900
אם הפונקציה שלך זקוקה ל-15 דקות כדי לאבד קובץ,

00:12:19.020 --> 00:12:20.140
היא תעצר באמצע התהליך.

00:12:20.140 --> 00:12:23.480
חלק את המשימה לחלקים קטנים יותר או השתמש בתוכנית אירוח אחרת.

00:12:23.560 --> 00:12:27.180
טעות נפוצה נוספת היא שימוש בפריסה מתוך חבילה Run From Package.

00:12:27.340 --> 00:12:30.260
זהו שינוי הגדרה פשוט שמשפר את זמני ההתחלה הקרה

00:12:30.260 --> 00:12:31.700
והופך פריסות להאמינות יותר.

00:12:31.880 --> 00:12:33.500
במקום להעתיק קבצים בודדים,

00:12:33.700 --> 00:12:34.840
אתה פורס חבילת זיפ.

00:12:35.040 --> 00:12:37.400
זאת תיבת סימון אחת בפורטל, פשוט בצה הזאת.

00:12:37.520 --> 00:12:40.880
חשיפת נקודות קצה של HTTP ללא אימות עם על קודת נוספת.

00:12:40.880 --> 00:12:43.300
קל להשאיר פונקציה במצב אנונימי בזמן בדיקות,

00:12:43.300 --> 00:12:44.520
ואז לשכוח לחסום אותה.

00:12:44.620 --> 00:12:46.940
הגדר את רמת ההרשאה שלך בצורה נכונה כבר מההתחלה.

00:12:47.100 --> 00:12:48.840
השתמש במפתחות פונקציה או במפתחות ניהול.

00:12:48.960 --> 00:12:50.120
אל תשאיר את הדלת פתוחה.

00:12:50.260 --> 00:12:52.980
שימוש חוזר בחשבונות איחסון עבור מספר אפליקציות פונקציה הוא גם בעיה.

00:12:53.120 --> 00:12:54.820
בשלב הפיתוח, זה בסדר לשתף.

00:12:54.980 --> 00:12:57.960
בסביבת ייצור, לכל אפליקציית פונקציה צריך להיות חשבון איחסון משלה.

00:12:57.960 --> 00:13:01.980
אחרת, תיתקל בבעיות שכן רועש שבהן התעבורה של פונקציה אחת מתה פונקציה אחרת.

00:13:01.980 --> 00:13:04.360
ולבסוף, אי הפעלת אפליקיישון אינסייטס.

00:13:04.500 --> 00:13:06.040
בלעדיו, אתה עובד בחושך.

00:13:06.200 --> 00:13:08.360
לא תראה כשלים, שגיאות או בעיות ביצועים.

00:13:08.520 --> 00:13:11.560
לא תדע אם הפונקציה שלך הרץ הזמן רב מדי או נכשלת בשקט.

00:13:11.680 --> 00:13:12.960
הפעל אותו מהיום הראשון.

00:13:13.160 --> 00:13:15.600
זה לוקח 30 שניות וחוסך שעות של ניפוי שגיאות.

00:13:15.600 --> 00:13:19.740
כלל הזהב לכל זה הוא לשמור על הפונקציות קטנות, ממוקדות וחסרות מצב, סטייטלס.

00:13:19.860 --> 00:13:21.740
משימה אחת לכל פונקציה, לא יותר.

00:13:21.920 --> 00:13:23.000
אז זו המערכת.

00:13:23.140 --> 00:13:24.680
Azure Functions הוא מחשוב ללא שרת,

00:13:24.680 --> 00:13:27.140
Serverless, המריץ חלקי קוד קטנים בתגובה לאירועים.

00:13:27.260 --> 00:13:29.240
אתה משלם רק כאשר הקוד שלך הרץ.

00:13:29.360 --> 00:13:30.980
טריגרים אומרים לפונקציה מתי להתעורר,

00:13:31.140 --> 00:13:33.340
קישורים, ביינדינגס, מחברים אותה לנתונים הדרושים לה,

00:13:33.500 --> 00:13:36.040
ותוכנית הצריכה שומרת עליה כמעט בחינם עבור פרויקטים קטנים.

00:13:36.040 --> 00:13:40.720
המהלך הכי טוב של לך כרגע הוא ליצור פונקציה פשוטה מופעלת HTTP בפורטל Azure.

00:13:40.960 --> 00:13:42.840
זה לוקח 5 דקות ולא עולה דבר.

00:13:43.020 --> 00:13:46.280
הרשם לMicrosoft Knowledge Nuggets לעוד הסברים בשפה פשוטה,

00:13:46.280 --> 00:13:49.280
ושתף זאת עם מישהו ששואל כל הזמן מה זה אומר ללא שרה.

00:13:49.420 --> 00:13:49.780
פרו.