בפיתוח אתרים קיימים שני פרדיגמות עיקריות לבנייה ואירוח של יישומי אינטרנט: הגישה המסורתית traditional server-based, והשיטה החדשה המכונה serverless.
באופן מסורתי, יישומים מאוחסנים על שרתים, פיזיים או וירטואליים. למפתחים יש את האחריות לנהל את השרתים האלה, להבטיח שהתוכנה שלהם מתעדכנת, ולהגדיר את השרת כדי שיתמודד עם anticipated application traffic. טכנולוגיה מוכרת שמאמצת את הגישה הזו היא Express.js, שהיא Node.js framework שמאפשרת פיתוח קל של יישומי אינטרנט. מודל server-based מאופיין על ידי long-lived connections שזה אומר שהשרתים רצים באופן מתמשך, מחכים לעיבוד בקשות נכנסות.
המונח "serverless" עשוי להטעות בהתחלה כי זה נשמע שלא מעורבים בכלל שרתים, אך זה לא נכון כי אכן יש שרתים מעורבים בתהליך אך הם לא באחריותם של המתכנתים. במקום זאת, המתכנתים יכולים לדאוג לכתיבת הקוד שלהם, והספק הענן cloud provider (כמו AWS, Google Cloud, או Azure) דואגים להריץ את השרת, לשנות את המשאבים באופן דינמי בהתאם לביקוש, ולשמור על בריאות השרת.
הגישה הזו מוכנה לעיתים כ"פונקציה כשירות" Function as a Service - (FaaS). במודל זה, קוד של המתכנתים מאורגן כסדרה של פונקציות, כך שכל אחת מטפלת במשימה מסוימת. הפונקציות האלה מופעלות כתגובה לאירועים מסוימים, כמו אינטראקציה של משתמש באתר, HTTP וכדומה.
דוגמה ל-framework שתומכת בפרדיגמה של serverless, היא Next.js. ב-Next.js, כל route יכול לתמוך ב-serverless function אם האפליקציה מתוחזקת על שרת serverless. פונקציות אלו, שלעיתים מכונות 'Lambda functions', מופעלות כתגובה לבקשות HTTP. אם האפליקציה מותקנת על שרת server-based, אז ה-route לא יהפוך אוטומטית ל-serverless function.
אחת מהתכונות של ארכיטקטורת serverless היא short-lived. בניגוד ל-traditional server-based ששומרים על חיבור מתמשך למסד נתונים (long-lived), serverless functions פותחות חיבור למסד הנתונים כאשר מגיעה בקשה, משתמשות בחיבור הקיים (אם יש) כדי לטפל בבקשה, ואז סוגרות את החיבור. לכן מתארים serverless functions כאילו להן יש "short-lived" למסד נתונים.
ארכיטקטורת serverless מובילה לתופעה המכונה "cold starts", עיכוב שמתרחש כאשר serverless function מופעלת לאחר שנכבתה. כשתכנס בקשה נוספת לאותה הפונקציה, הפונקציה תצטרך להקים חיבור חדש למסד הנתונים, דבר שעשוי לקחת קצת זמן.
שירותי PaaS, כמו Heroku או Google App Engine, מספקות אמצעי ביניים, בין traditional server-based לבין serverless. שירותי PaaS מספקים פלטפורמה שבה מפתחים יכולים להפעיל ולנהל את יישומיהם ללא דאגה על התשתית, בדיוק כמו serverless. אבל, בניגוד ל-serverless, יישומים על PaaS רצים באופן מתמשך (long-lived), דומה ליישומים מסורתיים מבוססי שרת. PaaS מספק יותר שליטה על סביבת היישום בהשוואה ל-serverless, אך שליטה פחותה בהשוואה לשיטות מסורתיות מבוססות שרת (traditional server-based).
הפרדיגמה של serverless יכולה להיות משומשת גם בטכנולוגיות שנועדו יותר ל-traditional server-based, לדוגמה Express.js שירותים כגון AWS Lambda, Google Cloud Functions או Azure Functions יכולים להריץ יישומי Express.js כפונקציות ללא שרת (serverless functions).
הבחירה מבוססות בצרכים שלכם. אם יש לכם רמה גבוהה של מומחיות טכנית בנושא ואתם רוצים שליטה מלאה על הסביבה שלכם, traditional server-based עשוי להיות הפתרון המתאים יותר בשבילכם.
לעומת זאת, אם אתם מעדיפים לא לעסוק בניהול שרתים ורוצים פתרון חסכוני שבו אתם משלמים רק על מה שאתם משתמשים ואתם רוצים שינהלו לכם את הסביבה, אז ארכיטקטורת serverless יכולה להיות בחירה מצוינת.