in media, myblog

בעשור האחרון עולם תשתיות המחשוב ובוודאי עולם היישומים של צד שרת עובר טלטלה רבה או אם תרצו רנסאנס. למרות שזה לא היה מזמן קשה לאתר את נקודת ההתחלה שבה עברנו מבניית יישומים שרצים על שרתים פיזיים לגל החדשנויות של מכונות ווירטואליות, 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. צמצום הסיבוכיות של היישום על ידי היכולת לחבר בצורה קלה פונקציות בודדות לשירותים (API) כמו אבני לגו. יכולת זו מאפשרת לבנות יישומים מורכבים בצורה פשוטה ומהירה תוך כדי התמקדות בבעיה שהיישום מנסה לפתור ולא באיך לאפשר אותו יישום לרוץ. צמצום הסיבוכיות באופן טבעי תורם ליציבות של היישום שנבנה ולקלות התחזוקה שלו.
  7. ארכיטקטורת תוכנה טובה יותר המשמשת בסיס רחב לשימוש חוזר בפונקציות שנבנו – Code Reuse.

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

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

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

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

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

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

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

פורסם במגזין Globes IT מהדורה ינואר 2017

Share on Facebook0Tweet about this on TwitterShare on LinkedIn0Email this to someone