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

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

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

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

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

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

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

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

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

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

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

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

הפשרות שכדאי להכיר

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

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

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

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

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

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

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

אז האם צריך לאכפת לך מ-Serverless?

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

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