הנושא של היום הוא כזה שכמעט כולם שמעו עליו, אבל כמעט אף אחד לא יכול להסביר. ללא שרת, serverless. מה זה בעצם? האם זה באמת רק קוד שרץ על כלום, או שזה משהו הרבה יותר גדול? בואו נעשה סדר בדברים. ללא שרת, לא אומר שאין שרתים. זה אומר שאתם לא צריכים לחשוב עליהם, וההבחנה הזו משנה הכל באופן שבו בונים תוכנה. בסוף הפרק הזה, תבינו מה הם באמת Azure Functions, איך התמחור באמת עובד ומתי כדאי להשתמש בהם. נפרק את זה לאבני בניין, נתחיל עם המיתוס הכי גדול. מה המשמעות האמיתית של ללא שרת? בואו נפריך כמה מיתוסים כבר עכשיו. השם ללא שרת, הוא מונח השיווק הגרוע ביותר שמייקרוסופט אי פעם המציע. זה גורם לאנשים לחשוב שאין שום שרת מעורב. זה לא נכון. יש שרתים, המון כאלה. פשוט לעולם לא צריך לגעת בהם. לפני 20 שנה, אם רצית להריץ קטע קוד באינטרנט, היית צריך לעבוד קשה. היית סוחר מכונה וירטואלית, מתקין מערכת הפעלה, מגדיר שרת אינטרנט ופורס את האפליקציה שלך. ואז היית מבלה כל סוף שבוע בהתקנת עדכוני הבטחה ומבדה שהדבר הזה לא יקרוס בית מינוס 3 לפנות בוקר.

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

זה הכל. זו לא אפליקציה שלמה עם דף התחברות, בסיס נתונים וו-20 עסקים. זו משימה אחת ממוקדת. תחשבו על זה כמו על מתג תאורה בבית, או קבוי או דולק ועובד, ואז חוזר למצב קבוי. שרת אינטרנט מסורתי הוא ההפך, כמו להשאיר את כל האורות בבית דולקים 24 שעות בממה, 7 ימים בשבוע, גם כשאין אף אחד בבית. Azure Functions תומכות במגוון רחב של שפות תכנות. אתם יכולים להשתמש במה שנוח לכם, JavaScript, Python, C-H, Java, PowerShell. אין כאן תשובה אחת נכונה. בחרו את השפה שאתם כבר מכירים. עכשיו, בואו נעשה סדר בבלבול נפוץ. אפליקציית פונקציה היא לא אותו דבר כמו פונקציה. אפליקציית הפונקציה היא הקונטיינר. תחשבו על זה כמו על ארגז כלים. אתם יוצרים אפליקציית פונקציה אחת, ובתוך ארגז הכלים הזה אתם מוסיפים פונקציות מרובות. כל פונקציה היא כלי נפרד שעושה את העבודה שלו. יכולה להיות לכם פונקציה אחת שמטפלת בהרשמות משתמשים, אחרת שמאבדת תמונות שהוא עלו, ושלישית ששולחת דוחות ליליים. כולן חיות באותו ארגז כלים, אבל עובדות באופן עצמאי. עוד דבר אחד על פונקציות, הן חסרות מצב, סטייטלס, מעצם הייצוב שלהן.

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

ישנם ארבעה טריגרים שמתחילים נתקלים בהם הכי הרבה. טריגר ה-HTTP הוא נקודת ההתחלה הנפוצה ביותר. מי שהוא מבקר בכתובת URL או מבצע קריאת API, והפונקציה שלכם מופעלת. כך בונים APIs כלילים מבלי להגדיר שרת אינטרנט מלא. ויש גם את טריגר הטיימר שרץ לפי לוח זמנים. אתה מגדיר ביטוי קרון, למשל הפעלה בכל שעה או בחצות בכל לילה, והפונקציה שלך תופעל בדיוק בזמנים האלה. מושלם למשימות תחזוקה, עבודות ניקוי או יצירת דוחות ליליים. טריגר הבלוב מופעל כאשר קובץ מעולה ל-Azure Storage. נניח שמישהו מעלה קובץ PDF לתקיעה ספציפית. טריגר הבלוב מזהה את ההעלה הזו ומריץ את הפונקציה שלך באופן אוטומטי. זה מצוין לאיבוד תמונה, המרת מסמכים ואימות קבצים. וטריגר התור, Q, מופעל כאשר הודעה מופיעה בתור. תורים הם דרך לנתק בין חלקים שונים של המערכת שלך. שירות אחד מניח הודעה בתור, והפונקציה שלך אוספת אותה ומאבדת אותה כשהיא מוכנה. זה מונע משירות ET1 לחסום את כל השאר. הנה הנקודה המרכזית. כאשר טריגר מופעל, הוא מעביר נתונים לפונקציה שלך באופן אוטומטי.

אתה לא צריך לבצע סקר, פולינג, או לבדוק אם קרה משהו. הטריגר מגיש לך את כל מה שצריך, והפונקציה שלך רק מאבדת את זה. פונקציה ללא טריגר היא סתם קוד שיושב ולא עושה כלום. הטריגר הוא מה שנותן לה מטרה. אז, הטריגר אומר לפונקציה שלך מתי לרוץ. אבל מאיפה מגיעים הנתונים ולאן הם הולכים? כאן נכנסים לתמונה הביינדינגס. קישורים, ביינדינגס, נתונים נכנסים, נתונים יוצאים. קישורים הם דרך לומר לפונקציה שלך אילו נתונים לקרוא ולאן לשלוח תוצאות בלי לכתוב את כל הקוד המיותר. זה מורכב, אז תן לי לפשט את זה. קיימים שני סוגים. קישורי קלט, input bindings, מכניסים נתונים לפונקציה שלך. קישורי פלט, output bindings, שולחים נתונים החוצה. בלי קישורים, היית צריך לכתוב קוד SDK בכל פעם שרצית לתקשר עם חשבון נכסון, בסיס נתונים או תור. היית צריך לטפל במכרוזות חיבור, לנהל ניסיונות חוזרים, לבצע סריאליזציה על נתונים ודסריאליסציה לתגובות. זה המון קוד תשתית רק בשביל לקרוא קובץ. עם קישורים, אתה רק מצהיר על מה שאתה צריך. אתה אומר, אני רוצה לקרוא מקונטיינר הבלוב הזה, או, אני רוצה לכתוב לתור הזה.

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

אחרות עשויות להזדקק לשלושה או ארבעה קישורים לשירותים שונים. השילוב של טריגרים וקישורים הוא מה שהופך את Azure Functions לכל כך עוצמתיות. אתה כותב את הלוגיקה העסקית, את קוד קבלת ההחלטות בפועל. הפלטפורמה מטפלת בכל האינטגרציה. הפונקציה שלך נשארת קטנה, ממוקדת וקלה להבנה. סיפור התמחור. התמחור הוא מה שמפתיע את רוב המתחילים. עבור רוב האנשים, תוכנית הצריכה היא ברירת המחדל, וכדאי להתחיל איתה בית מינוס 90% מהמקרים. הנה איך זה עובד. אתה משלם רק כשהפונקציה שלך באמת רצה. כשהיא במצב המתנה, אתה לא משלם כלום. אפס, לא פרוטה. שני מרכיבים מרכיבים את החשבון. ראשית, מספר ההרצות, כמה פעמים הפונקציה שלך מופעלת. שנית, זמן ההרצה, שנמדד במשהו שנקרא GB שניות. זה בעצם כמה זמן הפונקציה שלך הרצה כפול כמה זיכרון היא צרכה. המענק החינמי הוא נדיב. אתה מקבל מיליון הרצות בחודש וב מינוס 400 אלף ג'יגבייט שניות בחינם לחלוטין. עבור רוב הפרויקטים הקטנים, אפליקציות תחביב ועבות טיפוס, לעולם לא תשלם סנט. לעולם, אם אתה עובר את המענק החינמי, התעריפים עדיין זולים להפליט.

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

קבצים גדולים עולים יותר להיחסון, הם מעטים את האתר בכל פעם שמישהו טוען דף. והם מתסכלים את המשתמשים שצריכים לשבת ולחכות לתמונות. לכן, אתם צריכים דרך לחבץ את התמונות האלה באופן אוטומטי. ללא Azure Functions, הייתם צריכים לבנות עובד רקע מאפס. זה אומר להשיג שרת נפרד, להגדיר תור לניהול עומס העבודה, ולכתוב קוד שיתפל בכל החלקים הנעים. זו כמות עצומה של מורכבות מיותרת למה שהוא פשוט כמו קיבוץ תמונה. עם Azure Functions, כל מה שצריך זה טריגר של בלוב אחד ופונקציה אחת. אין שרתים שצריך לדאוג לגביהם. הרשו לי להסביר לכם איך זה עובד. משתמש מעלה תמונה דרך האתר שלכם, והקובץ נוחת ב-Azure Blob Storage. ברגע שהוא מגיע, טריגר של בלוב מופעל באופן אוטומטי. הפונקציה שלכם מתעוררת, מריצה את קוד הדחיסה, ושומרת את הגרסה הקטנה יותר חזרה להיחסון. כל זה קורה תוך שניות. המשתמש לעולם לא מחכה כי כל התהליך רץ מאחורי הקלעים, שקוף לחלוטין. הנה עוד דוגמה יומיומית, שליחת אימייל ברוכים הבאים כשמישהו נרשם לשירות שלכם. טריגר HTTP תופס את בקשת ההרשמה מהאתר שלכם.

הפונקציה שלכם מופעלת, לוקחת את כתובת האימייל של המשתמש, שולחת הודעת ברוכים הבאים דרך סנדבריד, וזהו. המשתמש מקבל את האימייל שלא כמעט מיידית. אין שרת אימייל להגדיר, אין תור שליחה לנהל, רק פונקציה אחת, משימה אחת, וזהו. אלו הן בדיוק המשימות שעבורן עוצבו Azure Functions. משימות קטנות, ממוקדות ומבוססות אירועים. לא אפליקציות ענק, לא זרימות עבודה מורכבות, רק דבר אחד שנעשה היטב, שמופעל על ידי משהו שקורה במקום אחר. מתי להשתמש ב-Azure Functions? אז מתי כדאי לבחור בפונקציה? ומתי כדאי להשתמש במה שהוא אחר? הנה דרך מהירה להחליט. שלו את עצמכם אם המשימה קצרה, אם היא מבוססת אירועים, ואם היא ללא מצב, stateless. אם עניתם כן על כל השלושה, Azure Functions הוא כנראה הכלי הנכון. בואו נתחיל עם מקרי השימוש הטובים. API וWebhooks הם התאמה מושלמת. אתם צריכים נקודת קצה קלה שמגיבה לבקשת HTTP. עושה דבר אחד ומחזירה תוצאה, וזה בדיוק מה שתרגרים של HTTP נועדו עבורו. עיבוד קבצים ותמונות הוא עוד מקרה גדול. קובץ נוחת בהכסון, הפונקציה שלכם מופעלת, מאבדת אותו ושומרת את התוצאה, הכל ללא שרת.

משימות מתוזמנות כמו ניקוי לילי או הפקת דוחות עובדות מצוין עם טריגרים מבוססי זמן. גם טרנספורמציה של נתונים עבור צינורות ETL היא נפוצה. ופונקציות הן דבק אינטגרציה מושלם, שמחבר בין שני שירותים שלא מדברים זה עם זה באופן טבעי. כעת, בואו נדבר על מתי פונקציות הן לא בחירה מתאימה. תהליכים ארוכים הם בעייתיים, כי בתוכנית הצריכה לפונקציות יש מגבלת זמן קצובה של 5 דקות כברירת מחדל או עד 10 דקות בהגדרה ידני. אם העבודה שלכם נמשכת זמן רב יותר, אתם צריכים משהו אחר. אפליקציות עם ניהול מצב, סטייטפור, הן התאמה לא נכונה נוספת. פונקציות לא זוכרות שום דבר בין הרצה להרצה. אם אתם צריכים לשמור על מצב של סשן או לעקוב אחר התקדמות בין שלבים, אתם פועלים נגד הייצוב שלהן. עומסי עבודה כבדים של חישוב הם גם לא מתאימים. אם אתם צריכים CPU עוצמתי למשך דקות או שעות, מכונה וירטואלית או קונטיינר הם בחירה טובה יותר. ותהליכי עבודה מורכבים, שבהם משימה אחת תלויה באחרת, מטופלים טוב יותר על ידי Durable Functions או Logic Apps. הנה סקירה מהירה של החלופות.

Azure Logic Apps היא האפשרות ללא קוד, NO קוד, לחיבור שירותים. אם אתם לא צריכים לכתוב קוד מותאם אישית, Logic Apps יכולים לבצע את העבודה עם מעצב ויזואלי. Azure App Service מיועד לאפליקציות אינטרנט מלאות שרצות 24 שביעיות. אם אתם צריכים אתר אינטרנט מלא או API שתמיד פעיל, זה הכלי שלכם. Azure Container Apps נותן לכם מיקרו שירותים מבוססי קונטיינרים עם יותר שליטה על סביבת הריצה. ו-Azure Virtual Machines נותן לכם שליטה מלאה על מערכת ההפעלה אם תצטרכו זאת. הנה כלל אצבע פשוט. אם אתם יכולים לתאר את העבודה במשפט אחד, כנראה שזה מועמד טוב לפונקציה. תחיסת תמונות כשהן מועלות. שליחת מייל ברוכים הבאים כשמישהו נרשם. הרצת משימת ניקוי בכל לילה בחצות. משפט אחד, עבודה אחת, פונקציה אחת. טעויות נפוצות של מתחילים שיש להימנע מהן. עכשיו, בואו נדבר על כמה דברים שכדאי לשים לב עליהם. אלו הן הן הטעויות שמכשילות כמעט את כולם כשהם מתחילים. טעות נפוצה של מתחילים היא לחשוב שפונקציות הן תמיד בחינם. המענק החינם היא נדיב, אני יודע שמיליון הרצות נשמע הרבה.

אבל אם הפונקציה שלכם הופכת לוויראלית או מותקפת על ידי בוט, ההרצות האלו מצטברות מהר. אז, עקבו אחרי השימוש שלכם, הגדירו התרעת תקציב באז'ר, ואל תופתעו מחשבון בסוף החודש. טעות נוספת היא התעלמות מהתחלות קרות, קולד סטארטס. בפעם הראשונה שהפונקציה שלכם רצה לאחר שהייתה במצב המתנה, זה לוקח זמן רב יותר. בתוכנית הצריכה, זה יכול לקחת כמה שניות. עבור רוב מקרי השימוש, זה בסדר גמור. אבל, אם אתם בונים API רגיש לשיהוי שבו כל מילי שנייה קובעת, שקלו את תוכנית הפרימיום או הפעילו מופעים שתמיד מוכנים. ויש גם כתיבת פונקציות שרצות זמן רב מדי. לתוכנית הצריכה יש זמן קצוב, 5 דקות, כברירת מחדל, 10 דקות לכל היותר. אם הפונקציה שלך זקוקה ל-15 דקות כדי לאבד קובץ, היא תעצר באמצע התהליך. חלק את המשימה לחלקים קטנים יותר או השתמש בתוכנית אירוח אחרת. טעות נפוצה נוספת היא שימוש בפריסה מתוך חבילה Run From Package. זהו שינוי הגדרה פשוט שמשפר את זמני ההתחלה הקרה והופך פריסות להאמינות יותר. במקום להעתיק קבצים בודדים, אתה פורס חבילת זיפ.

זאת תיבת סימון אחת בפורטל, פשוט בצה הזאת. חשיפת נקודות קצה של HTTP ללא אימות עם על קודת נוספת. קל להשאיר פונקציה במצב אנונימי בזמן בדיקות, ואז לשכוח לחסום אותה. הגדר את רמת ההרשאה שלך בצורה נכונה כבר מההתחלה. השתמש במפתחות פונקציה או במפתחות ניהול. אל תשאיר את הדלת פתוחה. שימוש חוזר בחשבונות איחסון עבור מספר אפליקציות פונקציה הוא גם בעיה. בשלב הפיתוח, זה בסדר לשתף. בסביבת ייצור, לכל אפליקציית פונקציה צריך להיות חשבון איחסון משלה. אחרת, תיתקל בבעיות שכן רועש שבהן התעבורה של פונקציה אחת מתה פונקציה אחרת. ולבסוף, אי הפעלת אפליקיישון אינסייטס. בלעדיו, אתה עובד בחושך. לא תראה כשלים, שגיאות או בעיות ביצועים. לא תדע אם הפונקציה שלך הרץ הזמן רב מדי או נכשלת בשקט. הפעל אותו מהיום הראשון. זה לוקח 30 שניות וחוסך שעות של ניפוי שגיאות. כלל הזהב לכל זה הוא לשמור על הפונקציות קטנות, ממוקדות וחסרות מצב, סטייטלס. משימה אחת לכל פונקציה, לא יותר. אז זו המערכת. Azure Functions הוא מחשוב ללא שרת, Serverless, המריץ חלקי קוד קטנים בתגובה לאירועים.

אתה משלם רק כאשר הקוד שלך הרץ. טריגרים אומרים לפונקציה מתי להתעורר, קישורים, ביינדינגס, מחברים אותה לנתונים הדרושים לה, ותוכנית הצריכה שומרת עליה כמעט בחינם עבור פרויקטים קטנים. המהלך הכי טוב של לך כרגע הוא ליצור פונקציה פשוטה מופעלת HTTP בפורטל Azure. זה לוקח 5 דקות ולא עולה דבר. הרשם לMicrosoft Knowledge Nuggets לעוד הסברים בשפה פשוטה, ושתף זאת עם מישהו ששואל כל הזמן מה זה אומר ללא שרה. פרו.