הדור הבא של ארכיטקטורת הפיתוח בענן: ה-Server-less מבית מיקרוסופט

מהו פתרון Server-less וכיצד הוא מתחבר למתודולוגית הענן הקלאסיות, כמו תשתית כשירות (IaaS) ופלטפורמה כשירות (PaaS)?
"המעבר לטכנולוגיית הענן יצר אבולוציה מתבקשת בתחומי הטכנולוגיה ותהליכי הפיתוח שהיו נפוצים בעולם בשנים האחרונות. בשנותיו הראשונות של הענן, המעבר מעולם ה-On Premise אמנם טמן בחובו חיסכון משמעותי ברכישה וניהול של תשתיות פיזיות, אך עדיין חייב את מפתחי האפליקציות ואנשי ה-DevOps לשמור על עדכניות מערכת ההפעלה, תמיכה בסקייל ופתרונות לשמירה על שרידות. הדור הבא של הענן, שמתבטא בעיקר בעולם הפלטפורמה כשירות, שאותו מיקרוסופט (Microsoft) מקדמת כבר מימיו הראשונים של ענן ה-Azure, נולד מתוך חשיבה שתכליתה לנצל את טכנולוגיות הענן ליותר מאירוח תשתיתי ולפנות עם הצעות ערך למפתחים. הפלטפורמה כשירות אכן הצליחה לצמצם חלק גדול מהניהול של השרתים והגדילה את המיקוד בכתיבת הקוד עצמה.

תפיסת ה-Server-less, שמתבטאת בפלטפורמות פונקציה כשירות (Function as a Service), נחשבת כחוד החנית של מהפכת הענן והדור הבא של פתרונות הפלטפורמה כשירות. בתצורה זו, כל תפיסת הפיתוח המבוססת על שרת משתנה, מכיוון שקונספט השרת עצמו נעלם והופך לאבסטרקטי, כך שהוא לא נגיש למפתח. הפיתוח הוא של פונקציות המגיבות למגוון רחב של אירועים ו-Triggering, כאשר כל ההרצה וההתרחבות של הפונקציה מתבצעת על ידי הענן. במודל זה, הפוקוס היחיד שנותר למפתחי אפליקציות הינו אך ורק על האפליקציה והקוד עצמו: כיצד לפתח את האפליקציה בארכיטקטורה שתתמוך במתודולוגית Server-less?"

מהם עקרונות הפיתוח של ה-Server-less?
"מתודולוגיית ה-Server-less מתבססת על שלושה עקרונות משמעותיים. העקרון הראשון הוא האבסטרקציה של צד השרת. אין כוונה לכך שלא קיים שרת מאחורי הקלעים, אלא שפלטפורמת הענן מטפלת בתפעול שלו באופן מלא בשביל המפתח. העקרון השני הוא מודל האירועים, שהינו תצורת ההפעלה של הפונקציות השונות. פונקציה דורשת טריגר כדי 'להתעורר' ולהריץ את הקוד הנדרש ולכן, כל ארכיטקטורת ההפעלה והתקשורת בין רכיבים שונים דורשת חשיבה קצת שונה ממה שהתרגלנו בימי השרת-לקוח. העקרון האחרון הוא היכולת להגיע לסקייל באופן מידי באמצעות הפלטפורמה, שבעצמה מטפלת בהרצה מקבילה של אותה פונקציה ממגוון רחב של טריגרים, מבלי שהמפתח יידרש לבצע תכנון קיבולת (Capacity Planning) לטובת היערכות לביצועים. באותו האופן, פונקציות מתאימות למודל התשלום של הענן בצורה אופטימלית, שכן הן מציעות מודל מיקרו-בילינג, כאשר התשלום הוא רק על זמן הפעילות של הפונקציה והמשאבים המדויקים שהיא צרכה. בהשוואה לפתרונות התשתית כשירות מהדור הקודם של הענן, בהם אנו משלמים על רכיבים רבים בתוך השרת, בין אם הוא פעיל ובין אם לא, כעת משלמים רק על מה שצריך. מסתתרת כאן בשורה כלכלית משמעותית – של מעבר לפיתוח ענני".

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

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

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

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