מה זה שרת, ומה זה בכלל Serverless¶
המילה Serverless מטעה מהרגע הראשון, וזה לא במקרה. "בלי שרתים" נשמע כמו קסם, וזה בדיוק מה שמשווקים רצו שתחשבו. אבל האמת פשוטה יותר, וברגע שתבינו אותה, גם ההבדל בין שרת רגיל לServerless יהיה ברור לגמרי.
קודם כל, מה זה שרת בכלל¶
שרת הוא בגדול מחשב שתפקידו לחכות לבקשות ולענות עליהן. כשאתם נכנסים לאתר, הדפדפן שלכם שולח בקשה למחשב שרץ איפשהו, אותו מחשב מעבד את הבקשה, ושולח בחזרה תשובה - עמוד HTML, נתונים, תמונה, מה שצריך. המחשב הזה, שתפקידו לתת שירות (serve) לבקשות, הוא השרת.
בגישה המסורתית, "להריץ שרת" אומר שיש לכם מכונה - פיזית או וירטואלית בענן - שרצה כל הזמן, 24 שעות ביממה, גם כשאף אחד לא מבקש ממנה שום דבר. אתם משלמים עליה גם ברגעים שבהם היא פשוט מחכה, לא עושה כלום. וגם אתם אחראים לנהל אותה - לעדכן אותה, לוודא שהיא לא נופלת, ולהתאים את כמות השרתים לעומס.
אז מה זה Serverless בעצם¶
Serverless לא אומר שאין שרתים. יש שרתים, כמובן - מישהו חייב להריץ את הקוד שלכם על חומרה כלשהי. ההבדל הוא מי אחראי לנהל אותם. בגישת Serverless, אתם לא מקימים ולא מתחזקים שום שרת בעצמכם. אתם פשוט כותבים פונקציה - קטע קוד שעושה משהו ספציפי - ומעלים אותה לספק ענן (למשל AWS Lambda). ספק הענן דואג לכל השאר.
כשמגיעה בקשה, ספק הענן מריץ את הפונקציה שלכם על שרת כלשהו, ברגע שהוא מחליט, על חומרה שהוא בוחר. כשהפונקציה מסיימת לרוץ, המשאבים משתחררים. אתם משלמים רק על משך הזמן שהקוד שלכם באמת רץ, ולא אגורה אחת יותר מזה. אם אף אחד לא קורא לפונקציה שלכם במשך שבוע שלם, אתם לא משלמים כלום.
היתרונות של Serverless¶
- תשלום לפי שימוש בפועל, עד הרזולוציה של מילישניות. אין תשלום על זמן המתנה שבו כלום לא קורה.
- אין ניהול תשתית. לא צריך לדאוג לעדכוני אבטחה, קיבולת, או תחזוקת שרתים - הספק עושה את זה.
- קנה מידה אוטומטי לחלוטין. אם פתאום מגיעים אלף בקשות בו זמנית, ספק הענן פשוט מריץ אלף עותקים של הפונקציה במקביל, בלי שאתם צריכים להגדיר משהו מראש.
אבל יש גם חסרונות אמיתיים¶
Serverless הוא לא פתרון קסם, ויש לו מגבלות שכדאי להכיר לפני שקופצים עליו בעיניים עצומות:
- Cold Start. אם הפונקציה שלכם לא רצה לאחרונה, קריאה ראשונה אליה יכולה לקחת עוד כמה מאות מילישניות עד שנייה, כי הספק צריך "להתעורר" ולהכין סביבה חדשה. לאפליקציות שרגישות לזמן תגובה, זה יכול להיות בעיה.
- מגבלות זמן ריצה. פונקציות Serverless בדרך כלל מוגבלות בכמה זמן הן יכולות לרוץ ברצף (לרוב כמה דקות לכל היותר), אז זה לא מתאים למשימות ארוכות וכבדות.
- מורכבות בדיבוג. כשקוד רץ על תשתית שאתם לא שולטים בה ולא רואים ישירות, לפעמים קשה יותר לאתר בעיות.
- עלות בקנה מידה גדול מאוד. אם יש לכם עומס גבוה וקבוע, לפעמים שרת רגיל שרץ כל הזמן דווקא יוצא זול יותר מלשלם לפי כל קריאה בנפרד.
אז מתי בוחרים מה¶
שרת רגיל מתאים כשיש לכם עומס יציב וצפוי, כשהאפליקציה מורכבת ודורשת שליטה מלאה על הסביבה, או כשזמן תגובה עקבי קריטי לכם בלי חשש מ-Cold Start.
Serverless מתאים לעומסים לא סדירים - למשל פונקציה שרצה רק כשמישהו מעלה קובץ, מעבדת אותו, וזהו. גם לסטארטאפים בשלבים מוקדמים זה נהדר, כי אין תשלום קבוע כשאין עדיין הרבה משתמשים.
בפועל, הרבה מערכות אמיתיות משלבות את שניהם - ליבת האפליקציה רצה על שרתים רגילים, ומשימות נקודתיות (עיבוד תמונה, שליחת התראה, ניקוי נתונים תקופתי) רצות כפונקציות Serverless.
איך זה נלמד בפועל¶
להבין את ההבדל הזה זה בדיוק החלק הראשוני בהבנה רחבה יותר של איך לתכנן תשתית backend נכונה. בקורס צד-שרת שלנו אנחנו לומדים לבנות שרתים אמיתיים, להריץ אותם בענן, ולהבין מתי בכלל כדאי לבחור בגישה אחרת.
קורס צד-שרת - מלמד את כל זה בעברית, בחינם, עם דוגמאות אמיתיות ולא רק תיאוריה.
יש לכם שאלה ספציפית על הפרויקט שלכם - שרת קבוע או Serverless? בואו לשאול בקהילה, יש שם אנשים שכבר קיבלו את ההחלטה הזאת בעצמם.
לסיכום¶
Serverless הוא לא "בלי שרתים", אלא "בלי לנהל שרתים בעצמכם". השם השיווקי מטעה, אבל הרעיון עצמו חזק - להעביר את האחריות על תפעול התשתית לספק הענן, ולשלם רק על מה שבאמת רץ. זה לא פתרון אוניברסלי, אבל זה כלי חשוב שכדאי להכיר, כי במקרים הנכונים הוא חוסך גם כסף וגם כאב ראש.