נקודות מפתח

• כבר כמה שנים שמבטיחים לנו שמחשוב ללא שרת (ללא שרת) יפתח עידן חדש ללא מערכת הפעלה ספציפית להפעלת אפליקציות. אמרו לנו שמבנה כזה יפתור הרבה בעיות מדרגיות. למעשה, הכל שונה.
• בעוד שרבים רואים בטכנולוגיה ללא שרת רעיון חדש, ניתן לאתר את שורשיה בשנת 2006 עם Zimki PaaS ו-Google App Engine, ששניהם משתמשים בארכיטקטורה ללא שרת.
• ישנן ארבע סיבות מדוע המהפכה ללא שרתים נעצרה, מתמיכה מוגבלת בשפת תכנות ועד לבעיות ביצועים.
• מחשוב ללא שרת הוא לא כל כך חסר תועלת. רחוק מזה. עם זאת, אין לראות בהם תחליף ישיר לשרתים. עבור יישומים מסוימים, הם יכולים להיות כלי שימושי.

השרת מת, יחי השרת!

זוהי קריאת הקרב של חסידי המהפכה ללא שרתים. די במבט חטוף בעיתונות התעשייה בשנים האחרונות כדי להסיק שמודל השרתים המסורתי מת ושעוד כמה שנים כולנו נשתמש בארכיטקטורות ללא שרתים.

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

חלק מההבטחות לדגמים ללא שרת בהחלט התגשמו, אבל לא כולן. לא כולם.

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

מה שהבטיחו חובבי המחשוב ללא שרתים

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

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

1. מודלים ללא שרת אינם דורשים מהמשתמשים לתחזק את מערכות ההפעלה שלהם או אפילו לבנות יישומים התואמים למערכות הפעלה ספציפיות. במקום זאת, מפתחים יוצרים קוד משותף, מעלים אותו לפלטפורמה ללא שרת וצופים בו פועל.
2. משאבים במסגרות ללא שרת מחויבים בדרך כלל לפי דקה (או אפילו שניות). המשמעות היא שלקוחות משלמים רק עבור הזמן שבו הם מבצעים את הקוד בפועל. זה משתווה לטובה עם ה-VM המסורתי של ענן, שבו המכונה לא פועלת רוב הזמן, אבל אתה צריך לשלם על זה.
3. גם בעיית המדרגיות נפתרה. משאבים במסגרות ללא שרת מוקצים באופן דינמי כך שהמערכת יכולה להתמודד בקלות עם עליות פתאומיות בביקוש.

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

האם זה באמת רעיון חדש?

למעשה הרעיון אינו חדש. הרעיון של לאפשר למשתמשים לשלם רק עבור הזמן שהקוד פועל בפועל קיים מאז שהוצג תחתיו Zimki PaaS בשנת 2006, ובערך באותו זמן, Google App Engine הגיע עם פתרון דומה מאוד.

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

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

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

בעיות עם דגמים ללא שרתים

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

בגלל זה.

תמיכה מוגבלת בשפות תכנות

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

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

זה מערער את אחד היתרונות המרכזיים של המודל ללא שרת.

מחייב לספק

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

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

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

פרודוקטיביות

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

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

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

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

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

אתה לא יכול להפעיל יישומים שלמים

לבסוף, אולי הסיבה החשובה ביותר לכך שארכיטקטורות חסרות שרת לא יחליפו מודלים מסורתיים בקרוב היא שהם (בדרך כלל) לא יכולים להריץ יישומים שלמים.

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

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

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

תחי המהפכה?

למרות כל התלונות הללו, אני לא מתנגד לפתרונות חסרי שרת כשלעצמם. בִּיוֹשֶׁר. רק שמפתחים צריכים להבין - במיוחד אם הם בוחנים דגמים ללא שרתים בפעם הראשונה - שהטכנולוגיה הזו אינה תחליף ישיר לשרתים. במקום זאת, בדוק את הטיפים והמשאבים שלנו בנושא בניית אפליקציות ללא שרת ולהחליט כיצד ליישם את המודל הזה בצורה הטובה ביותר.

מקור: www.habr.com