ב-Server-Based השרת רץ תמיד, המפתח אחראי על ניהולו, וחיבורי מסד הנתונים נשמרים פתוחים לאורך זמן. ב-Serverless ספק הענן מנהל את כל התשתית, הפונקציות חיות זמן קצר ומופעלות לפי דרישה — ומשלמים רק על שימוש בפועל. כל מודל מתאים לצרכים שונים.
בפיתוח אתרים קיימות שתי גישות עיקריות לבנייה ואירוח של שירותים דיגיטליים: הגישה הראשונה (Server-based Applications) והגישה השנייה (Serverless Applications).
שירותים דיגיטליים כמו אתרים, אפליקציות ווב וכדומה, מתארחים על שרתים פיזיים או וירטואליים (בענן). למפתחים יש אחריות לנהל את השרתים האלה, לדאוג לעדכוני תוכנה ולוודא שהשרת מסוגל להתמודד עם עומסי תעבורה (כלומר, הרבה בקשות שמגיעות מהמשתמשים לאותו שירות). בשיטה הזו, השרתים נשארים פעילים כל הזמן (long-lived connections) וממתינים לבקשות.
המונח "serverless" עשוי להטעות בהתחלה כי זה נשמע שלא מעורבים בכלל שרתים, אבל זה לא נכון כי כן יש שרתים שמעורבים בתהליך אבל הם לא באחריות של המתכנתים. במקום זאת, זה באחריות ספקי הענן (cloud provider) כמו AWS, Google Cloud, Azure וכדומה. הם אלו שדואגים לנהל את השרת, לדאוג לעדכוני תוכנה, לוודא שהשרת מסוגל להתמודד עם עומסי תעבורה ולשמור על בריאות השרת.
הגישה הזו מוכנה לעיתים "פונקציה כשירות" Function as a Service - (FaaS). בגישה זו, הקוד מאורגן כמערכת של פונקציות שכל אחת מטפלת במשימה ספציפית. הפונקציות האלה מופעלות בתגובה לאירועים מסוימים, כמו בקשות HTTP, אינטראקציה של משתמש, או טריגרים אחרים. מכאן מגיע המונח "פונקציה כשירות" (Function as a Service - FaaS), שמתאר את המודל שבו כל פונקציה פועלת בנפרד לפי הצורך.
ב-Next.js לדוגמה, ניתן להגדיר API routes כאל serverless functions כאשר האפליקציה מתוחזקת על פלטפורמה serverless (כמו Vercel). הפונקציות הללו, שמכונות לעיתים גם Lambda functions, מופעלות אוטומטית בתגובה לבקשות HTTP שמגיעות מהמשתמשים. עם זאת, אם האפליקציה רצה על שרת מסורתי (server-based), ה-route לא יתפקד כפונקציה serverless.
אחד המאפיינים המרכזיים בארכיטקטורת serverless הוא שזמן החיים של הפונקציות קצר מאוד (short-lived). בניגוד לארכיטקטורת שרת מסורתי שבה החיבור למסד הנתונים נשאר פתוח לאורך זמן (long-lived connections), ב-serverless החיבור נפתח רק כאשר מגיעה בקשה מהמשתמש. לאחר הטיפול בבקשה, החיבור נסגר. הפונקציה תיפתח חיבור חדש במקרה הצורך לבקשות עתידיות.
אחד האתגרים בארכיטקטורת serverless הוא תופעת ה-"cold start", שבה יש עיכוב בזמן שהפונקציה מופעלת מחדש לאחר פרק זמן שבו לא הייתה בשימוש. כאשר מגיעה בקשה חדשה, הפונקציה צריכה להקים מחדש את החיבור למסד הנתונים ולמשאבים אחרים, דבר שעלול לעכב את הטיפול בבקשה. משך העיכוב נע בין כמה מילישיות לשניות בודדות, תלוי במורכבות הפונקציה והחיבורים הנדרשים.
בין המודלים של Serverless ו-Server-Based, קיימים גם מודלים נוספים המספקים פתרונות מגוונים לניהול שירותים ותשתיות בענן. שלושת המודלים המרכזיים – PaaS, IaaS, ו-SaaS – ממלאים תפקיד חשוב בארכיטקטורות שונות, ומציעים רמות שונות של שליטה וגמישות למפתחים ולחברות. בואו נעמיק ונסביר מה כל אחד מהם מציע.
המפתחים מקבלים גישה מלאה לשרתים וירטואליים, לרשת, ולאחסון, ויש להם שליטה על מערכת ההפעלה, התוכנות, והגדרות השרת. כלומר במודל זה, למפתחים יש את השליטה הרחבה ביותר על התשתית, מה שמתאים לצרכים מורכבים שדורשים התאמה אישית של השרתים והרשת. רק החומרה מנוהלת על ידי ספק השירות. דוגמאות לספקי IaaS הן AWS EC2, Azure, Google Compute Engine ועוד.
המפתחים אינם צריכים לנהל את התשתית הפיזית או מערכת ההפעלה, אלא מתמקדים רק בכתיבת הקוד ופיתוח האפליקציות. הספק אחראי על ניהול השרתים, אבטחה, עדכונים ותשתיות אחרות. במילים אחרות, במודל PaaS, המפתחים נהנים מסביבה מוכנה שבה הם יכולים לפתח בקלות ללא התעסקות עם השרתים, אך יש להם פחות שליטה מאשר במודל IaaS. דוגמאות לספקי PaaS הן Heroku, Google App Engine ועוד.
זה שירות שאתם ניגשים אליו דרך האינטרנט, בלי צורך להוריד או להתקין שום דבר על המחשב שלכם. מוצרים כמו Gmail, פייסבוק ואפילו Coding with Saar – כל אלה הם דוגמאות למוצרי SaaS. כל מה שאתם צריכים זה חיבור לאינטרנט ודפדפן, וכל התשתית והניהול מתבצעים בענן של אותה חברה. גם אם יש לאותה חברה גרסה להורדה אליכם למחשב, כמו Netflix או GitHub Desktop, כל העדכונים והתשתית עדיין מנוהלים בענן, אז זה עדיין נחשב SaaS.
במערכות מבוססות-שרת (Server-based), החיבור למסד הנתונים נשאר פתוח לאורך זמן (long-lived connections). כלומר, כשאנחנו רוצים לבצע שאילתות למסד הנתונים, אין צורך לבדוק או לפתוח כל פעם חיבור חדש, מכיוון שהחיבור נשמר פתוח. לדוגמה אפליקציה שמבוססת על Express ו-Node.js המתארחת בשרת מסורתי או בענן (כמו AWS EC2 או DigitalOcean).
לעומת זאת, בסביבה סרברלס (Serverless), החיבור למסד הנתונים אינו נשאר פתוח באופן קבוע. בכל פעם שמגיעה בקשה חדשה, יש לפתוח חיבור חדש למסד הנתונים או לבדוק אם קיים כבר חיבור פעיל. עם זאת, כדי למנוע פתיחה חוזרת ונשנית של חיבורים רבים, אנו יכולים להשתמש ב-connection pooling.
Connection pooling הוא מנגנון המנהל מאגר של חיבורים למסד הנתונים, כך שכאשר בקשה חדשה דורשת חיבור, היא יכולה "לשאול" חיבור קיים מהמאגר במקום לפתוח חיבור חדש. לאחר השלמת הבקשה, החיבור מוחזר למאגר ויכול לשמש לבקשות נוספות. הדבר חשוב במיוחד בסביבה סרברלס, שבה פתיחת חיבורים מחדש בכל פעם יכולה לגרום לעיכובים ולצרוך משאבים רבים.
שימוש נכון ב-pooling בסביבה סרברלס מאפשר לנו לייעל את הביצועים, להפחית את העומס על מסד הנתונים, ולשמור על זמני תגובה מהירים גם כאשר יש תעבורה גבוהה.
אז לדוגמה אפליקציה בסביבה סרברלס כמו Vercel עם Next.js בכל פעם שמגיעה בקשה חדשה (למשל דרך API routes), השרת צריך לבדוק אם יש חיבור פעיל למסד הנתונים. אם אין חיבור כזה, יש לפתוח חיבור חדש או לבצע connection pooling.
הבחירה מבוססות בצרכים שלכם. אם יש לכם רמה גבוהה של מומחיות טכנית בנושא ואתם רוצים שליטה מלאה על הסביבה שלכם, traditional server-based עשוי להיות הפתרון המתאים יותר בשבילכם.
לעומת זאת, אם אתם מעדיפים לא לעסוק בניהול שרתים ורוצים פתרון חסכוני שבו אתם משלמים רק על מה שאתם משתמשים ואתם רוצים שינהלו לכם את הסביבה, אז ארכיטקטורת serverless יכולה להיות בחירה מצוינת.
ב-Server-Based המפתח מנהל שרת שרץ תמיד — מעדכן תוכנה, מנהל קיבולת ומפקח על בריאות השרת. ב-Serverless ספק הענן (AWS, Vercel, Google Cloud) מנהל הכל. המפתח כותב פונקציות שמופעלות רק כשמגיעה בקשה — ומשלם רק על שימוש בפועל.
Cold Start הוא העיכוב שנוצר כאשר פונקציה Serverless מאותחלת מחדש לאחר תקופת חוסר פעילות. הפונקציה צריכה לפתוח חיבור לDB ולמשאבים — מה שעלול לגרום לעיכוב של מיליות שניות עד שניות בודדות בתגובה הראשונה.
IaaS (כמו AWS EC2) — גישה לשרת וירטואלי, המפתח מנהל מערכת ההפעלה ומעלה. PaaS (כמו Heroku) — ספק מנהל התשתית, המפתח מפתח קוד בלבד. SaaS (כמו Gmail) — שירות מוכן שניגשים אליו דרך האינטרנט, ללא ניהול כלל.
Connection Pooling הוא מנגנון שמנהל מאגר של חיבורים פתוחים לDB. בסביבת Serverless — שבה כל בקשה עלולה לדרוש חיבור חדש — Pooling מונע צוואר בקבוק ומקטין את עלויות ה-Cold Start. Prisma ו-PgBouncer הם כלים נפוצים לכך.
Serverless מתאים כשרוצים: לשלם רק על שימוש בפועל, לא לנהל תשתית, לבנות מיקרו-שירותים, או שהעומס משתנה מאוד. Server-Based עדיף כשצריך שליטה מלאה, חיבורים ארוכי-טווח, ביצועים מקסימליים, או עיבוד כבד ורציף.
