יום שלישי , אוגוסט 22 2017
מבזקים
דף הבית > כתבות IT מגזין > FaaS – Function as a Service השלב האחרון במהפכת הענן?

FaaS – Function as a Service השלב האחרון במהפכת הענן?

מאת: דודו מימרן, אסטרטג חדשנות.

בעשור האחרון עולם תשתיות המחשוב ובוודאי עולם היישומים של צד שרת עובר טלטלה רבה או אם תרצו רנסאנס. קשה לאתר את נקודת ההתחלה שבה עברנו מבניית יישומים שרצים על שרתים פיזיים לגל החדשנויות של מכונות ווירטואליות, Micro Services, Containers ושירותי ענן על כל מופעיו השונים אבל כל מי שחווה את השינויים האלה בין אם כמפתח או כמנהל טכנולוגי חש שהיכולות המוגשות היום על ידי כלים אלה מעצימות בקצב הולך וגובר. לפני כשנתיים נתקלנו בסוג חדש של יכולות, נדמה לי שהפעם הראשונה שנחשפנו לכך היתה באירוע של אמזון ב-2014 עם השקת ה-AWS Lambda, מוצר ה-FaaS של AWS. יכולות אלה נושאות בהבטחה לשנות את המשחק מחדש ומבוססות על הבשורה של Serverless Computing או כפי שמאוחר יותר הוסכם על השם FaaS, Function as a Service.

דודו מימרן

דודו מימרן

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

 מה זה FaaS

האבולוציה של תחום השרתים באה לידי ביטוי באספקטים רבים ואחד מהם הוא הדרך בה מפתחים תוכנה. בהתחלה התרגלנו לבנות יישומים כגוש אחד גדול ומונוליתי שהכיל את כל הפונקציונאליות הדרושה למימוש היישום בדבוקה אחת. החל מהפונקציונאליות היישומית עצמה עד השירותים התשתיתיים הדרושים להרצת היישום. הקפיצה הבאה הייתה פירוק הפונקציונאליות לגושים קטנים ושימוש בשירותי תשתית מבוססי API כאשר מבחינת מפתח התוכנה הסיבוכיות הפנימית של השירותים המוגשים דרך API מוסתרים ומאפשרים בניית פונקציונאליות עשירה בפחות מאמץ. הפירוק היישומי מגוש אחד מונוליטי לקבוצות פונקציונאליות קטנות בא לידי ביטוי ברעיון של Micro Services כאשר כל שרות זעיר עוסק בנושאים ספציפיים המרכיבים ביחד את היישום עצמו. הקפיצה האבולוציונית הבאה הינה כמובן ה-FaaS בה המפתח מתמקד בבניית פונקציות פרטניות המבצעות פעולה אחד וחיבור הפונקציות האלה לפונקציות אחרות או לשירותים מבוססי  API בכדי להרכיב את היישום. בהתחלה תשתיות היו זמינות כשירות בעולם ה- IaaS ולאחר מכן נולד הקונספט של פלטפורמות זמינות כשירות שהקלו מאוד מבחינת סיבוכיות בעולם ה- PaaS והגל החדש הינו ה-FaaS, פונקציות כשירות. ניתן לראות שיש תהליך מתמשך של פירוק הסיבוכיות והסתרת המורכבות הפנימית של כל רכיב שמשתתף ביישום.

יתרונות וחסרונות

היתרונות של FaaS באים לידי ביטוי ב:

  1. ייעול השימוש במשאבי מחשוב מכיוון שאתה משלם רק על הזמן והמשאבים שהפונקציה שלך צרכה בזמן שהייתה פעילה וייעול זה דרמטי מכיוון שהוא פתר בעיות תכנון משמעותיות של תשתית בכדי להגיע לכמות השרתים והמשאבים האופטימלית עבור היישום בזמנים שהשימוש נמוך או גבוה.
  2. הסרת הסיבוכיות של בניית תשתית המאפשרת את הגמישות בזמנים שהשימוש ביישום גבוה או נמוך או כפי שנקרא בעגה המקצועית אלסטיות. לדוגמא אם יש לך אפליקציה שרתית שמחפשת דירות אז אם בלילה אף אחד לא משתמש בה למעשה שום משאב לא מבוזבז ואם במשך היום הייתה קפיצה גבוהה בשימוש הודות לאירוע יחצ״ני של השירות אז המשאבים הדרושים לפונקציה בכדי לשמר את זמן התגובה נתפסים ומשוחררים מיד לאחר שקצב השימוש יורד. וכל זה ללא ידיעת המפתח או כל מאמץ תכנוני או ביצועי מצידו.
  3. היכולת לבנות את הפונקציות בכל שפת התכנות והטענתן בצורה פשוטה לפלטפורמת ה-FaaS כאשר היא דואגת להרצת הקוד בצורה הנכונה.
  4. הסרת הדאגה שמשאבי המחשוב הדרושים יהיו זמינים תמיד – Fault Tolerance, טיפול בכשלים בהרצת הפונקציה, אמינות וזמני התגובה לפי התחייבות.
  5. שירותי תשתית בסיסיים זמינים המאפשרים מעקב אחר ביצועי היישום.
  6. צמצום הסיבוכיות של היישום על ידי היכולת לחבר בצורה קלה שירותים מורכבים כמו אבני לגו ועל ידי כך לבנות יישומים מורכבים בצורה פשוטה ומהירה יותר תוך כדי התמקדות בבעיה שהיישום מנסה לפתור ולא באיך לאפשר את אותו יישום. צמצום הסיבוכיות באופן טבעי תורם ליציבות של היישום שנבנה ולקלות התחזוקה שלו.
  7. ארכיטקטורת תוכנה טובה יותר המשמשת בסיס רחב לשימוש חוזר בפונקציות שנבנו – Code Reuse.

כל פונקציה ב-FaaS מופעלת בעקבות התרחשות אירוע מערכת מסוים בין אם זה לקוח שניגש לפונקציה, העלאת קובץ לספרייה מסוימת או זיהוי שינוי בתנאי סביבתי כמו שינוי מחיר מניה. הקונספט הזה מבוסס Event Driven Programming והוא מותאם יותר לסוג החדש של היישומים שהולכים ונבנים.

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

  1. כל פונקציה שנבנית היא Stateless משמע שהפונקציה לא יכולה לשמור דברים בזיכרון או על הדיסק ולסמוך על זה שבפעם הבאה שהפונקציה תורץ הנתונים יהיו זמינים. כל פונקציה צריכה להניח שסביבת ההרצה המידית שלה תיעלם עם סיום ההרצה של הפונקציה וזה שינוי מחשבתי שקיים גם בעולם ה-Containers ולוקח למפתחים זמן להבין זאת. כמובן שהפונקציות יכולות להשתמש בשירותי אחסון מרכזיים מבוססי זיכרון או דיסק כגון S3 או Redis אבל הגישה אליהם היא דרך API.
  2. פונקציות לרוב מוגבלות בזמן הריצה ולמפתחים שרגילים לחוסר מגבלה הנושא יכול להיות מאתגר. כמובן שמי שמטמיע את הארכיטקטורה החדשה יכול לתכנן את הפונקציות בצורה כזאת שהמגבלה לא תהיה מורגשת.
  3. ישנו עיכוב מסוים בהפעלת הפונקציה מזמן התרחשות האירוע שהעיר אותה ולמרות שהעיכוב מאוד קטן ולרוב היישומים יהיה בלתי מורגש עדיין יישומי זמן אמת רגישים לנושא.
  4. קל מאוד למתכנן היישום שלא באמת הטמיע את החשיבה החדשה הזאת לייצר ערימה של פונקציות שלא בהכרח מהוות בסיס תכנוני נכון ולמעשה להגדיל את הסיבוכיות של היישום. קושי נוסף טמון בניהול גרסאות הקוד שפתאום הופך להיות מפוזר ובלתי תלוי עקב הפירוק לפונקציות. בהחלט מזכיר את עולם ה-Stored Procedures של עולם מסדי הנתונים שהוליד בעיות רבות.
  5. דיבאגינג ומעקב אחר הפונקציות בזמן ריצה בכדי לפתור בעיות ביישום הם נושאים לא פתורים עדיין ומהווים אתגר לא קטן למפתחים.

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

אחד הבאזוורדס שמסתובבים בעולם ה-FaaS זה ה-#NoOps  משמע אין צורך בניהול הפעילות עצמה אלא רק במפתחים וזה בהחלט חלום ורוד אך עדיין די רחוק מלהתממש.

התחנה האחרונה

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

אודות מערכת ITNEWS מאיר עשת

מנהל/עורך אתר ITNEWS. בוגר כלכלה ומנה"ס באונ' בן גוריון ו- MBA בירושליים. בעבר: כהן כיועץ כלכלי מטעם המדינה בהולנד ובהודו. היה סמנכ"ל שיווק בברדר, משנה למנכ"ל בסטארטאפ TVNGO, מנהל IT מגזין של גלובס בשנתיים האחרונות.