מה זה Serverless? מדריך בשפה פשוטה ליזמים

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

אז מה זה Serverless באמת?

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

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

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

איך תשלום-לפי-שימוש עובד בפועל

מודל החיוב הוא לב העניין, אז שווה לראות את ההבדל מהצד אל צד.

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

היתרונות האמיתיים

Serverless הוא לא רק באז - לעומסי העבודה הנכונים זו באמת עסקה טובה יותר. היתרונות המרכזיים:

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

החסרונות שכדאי להכיר

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

• Cold start. כשפונקציה לא רצה זמן מה, הקריאה הראשונה יכולה לקחת חלקיק שנייה נוסף כדי להתעורר. בדרך כלל לא מורגש, אבל יכול לשנות לפיצ'רים שרגישים להשהיה.
• העלות מתהפכת בנפח גבוה ויציב. תשלום-לפי-שימוש מצוין לתעבורה זינוקית או נמוכה. אבל לאפליקציה שרצה במלוא הקצב 24/7, שרת שכור רגיל יכול להפוך לזול יותר מתשלום לפי בקשה. יש נקודת מעבר. חשוב גם לזכור שעלויות ספקי הענן (AWS, Google Cloud וכד') משולמות ישירות לספק ואינן חלק מתמחור הפיתוח - כדאי להיות מודעים לזה בתכנון התקציב.
• פחות שליטה. רצים בתוך הקופסה של הספק, עם המגבלות שלו על זמן ריצה וזיכרון. רוב האפליקציות לא יגיעו לגבולות האלה, אבל עומסים כבדים מסוימים כן.
• תלות בספק. קוד Serverless נכתב לרוב לדרך הספציפית של ספק אחד, כך שמעבר לאחר בהמשך דורש עבודה. שווה לחשוב על זה מראש.
• קשה יותר לחזות עלות. חשבון שמבוסס על מיליוני הרצות קטנות פחות צפוי מדמי שרת חודשיים קבועים - לכן כדאי להקים ניטור מוקדם.

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

מתי Serverless הוא הבחירה הנכונה

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

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

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

אז האם כדאי לכם לאכפת מ-Serverless?

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

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