Serverless ב-GCP: Cloud Functions ו-Cloud Run – מדריך מעשי

מה זה Serverless ולמה זה רלוונטי ב-2026

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

Google Cloud Platform מציעה שני שירותי Serverless עיקריים: Cloud Functions ו-Cloud Run. שניהם מאפשרים לפרוס קוד בלי לנהל תשתית, אבל הם שונים זה מזה בצורה משמעותית. הבחירה ביניהם תלויה בסוג הפרויקט, דרישות הביצועים ומבנה האפליקציה.

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

Cloud Functions: הפונקציה שרצה לבד

Cloud Functions הוא שירות FaaS (Function as a Service). כותבים פונקציה בודדת, מגדירים טריגר, ופורסים. Google דואגת לכל השאר.

איך זה עובד בפועל

Cloud Functions מקבלת אירוע (HTTP request, הודעה ב-Pub/Sub, שינוי ב-Firestore, קובץ שעלה ל-Cloud Storage) ומריצה פונקציה שמטפלת באירוע הזה. אחרי שהפונקציה מסיימת, המשאבים משתחררים.

דוגמה פשוטה ב-Node.js:

"`javascript

const functions = require('@google-cloud/functions-framework');

functions.http('processOrder', async (req, res) => {

const { orderId, customerEmail } = req.body;

// עיבוד הזמנה

await saveOrderToFirestore(orderId);

await sendConfirmationEmail(customerEmail);

res.status(200).json({ success: true });

});

"`

זהו. אין שרת Express, אין Dockerfile, אין הגדרת פורט. הפונקציה מקבלת request ומחזירה response.

מתי Cloud Functions זה הבחירה הנכונה

Cloud Functions מתאימות למקרים הבאים:

• Webhooks שמקבלים נתונים ממערכות חיצוניות (שערי תשלום, CRM, צד שלישי)
• עיבוד אירועים: קובץ עלה ל-Storage? הפונקציה מעבדת אותו
• משימות מתוזמנות (Cron Jobs) כמו שליחת דוחות יומיים או ניקוי נתונים
• אינטגרציות קצרות בין מערכות
• Microservices קטנים שמבצעים פעולה אחת ספציפית

מגבלות שחשוב להכיר

• זמן ריצה מקסימלי של 60 דקות (Gen 2) או 9 דקות (Gen 1)
• אין שליטה על סביבת הריצה, לא אפשר להתקין תוכנות מערכת
• לא מתאים לאפליקציות שצריכות חיבורים קבועים (WebSockets)
• קר בהתחלה, ועל זה נדבר בהמשך

Cloud Run: קונטיינר בלי כאב ראש

Cloud Run הוא שירות שמריץ קונטיינרים (Docker) בצורה Serverless. בניגוד ל-Cloud Functions שבהם כותבים פונקציה בודדת, ב-Cloud Run פורסים אפליקציה שלמה ארוזה בקונטיינר. כל דבר שרץ בקונטיינר יכול לרוץ על Cloud Run.

פריסה עם Docker

הפריסה ל-Cloud Run מבוססת על Docker image. ככה נראה Dockerfile טיפוסי לאפליקציית Node.js עם Express:

"`dockerfile

FROM node:20-slim

WORKDIR /app

COPY package*.json ./

RUN npm ci –only=production

COPY . .

ENV PORT=8080

EXPOSE 8080

CMD ["node", "server.js"]

"`

וקוד ה-Express הבסיסי:

"`javascript

const express = require('express');

const app = express();

app.use(express.json());

app.get('/api/health', (req, res) => {

res.json({ status: 'ok' });

});

app.post('/api/orders', async (req, res) => {

// לוגיקה עסקית מורכבת

const result = await processComplexOrder(req.body);

res.json(result);

});

app.get('/api/reports/:id', async (req, res) => {

const report = await generateReport(req.params.id);

res.json(report);

});

const PORT = process.env.PORT || 8080;

app.listen(PORT, () => {

console.log(`Server running on port ${PORT}`);

});

"`

הפריסה עצמה מתבצעת בפקודה אחת:

"`bash

gcloud run deploy my-service \

–source . \

–region me-west1 \

–allow-unauthenticated

"`

GCP בונה את ה-Docker image, מעלה אותו ל-Artifact Registry ופורס אותו. הכל אוטומטי.

מתי Cloud Run זה הבחירה הנכונה

Cloud Run מתאים כשצריך:

• API שלם עם מספר endpoints (REST או GraphQL)
• אפליקציות Next.js או Express מלאות
• שירות שצריך חיבורים קבועים (gRPC, Server-Sent Events)
• עיבוד שלוקח זמן ארוך (עד 60 דקות לבקשה)
• אפליקציה שצריכה תלויות מערכת ספציפיות (ספריות C, כלי PDF וכד')
• סביבות Staging ו-Production עם Traffic splitting

Cloud Functions מול Cloud Run: השוואה ישירה

הכלל שאנחנו עובדים איתו ב-SysTech: אם מדובר באירוע בודד שצריך תגובה, Cloud Functions. אם מדובר בשירות שלם עם routing וסטייט, Cloud Run.

Cold Start: הבעיה שכולם שואלים עליה

Cold Start הוא הזמן שלוקח לשירות Serverless להתחיל לרוץ כשאין instance פעיל. כש-Cloud Function או Cloud Run container לא קיבלו בקשות לזמן מה, GCP מכבה אותם כדי לחסוך משאבים. כשמגיעה בקשה חדשה, צריך להרים instance חדש, ולזה לוקח זמן.

מה זה אומר בפועל:

• Cloud Functions (Node.js): Cold start של 0.5-3 שניות בממוצע
• Cloud Run (Node.js/Express): Cold start של 1-5 שניות, תלוי בגודל ה-image

3 שניות אולי נשמעות לא הרבה, אבל עבור API שמחזיר תוצאות למשתמש שמחכה, זה מורגש.

איך מצמצמים Cold Starts

Min Instances: שני השירותים מאפשרים להגדיר מספר מינימלי של instances שתמיד רצים. הגדרה של min-instances=1 אומרת שתמיד יש instance חם אחד שמוכן לקבל בקשות. זה עולה כסף (כי המכונה רצה תמיד), אבל פותר את הבעיה לגמרי.

"`bash

gcloud run deploy my-service \

–min-instances 1 \

–max-instances 10 \

–region me-west1

"`

Docker image קטן: ב-Cloud Run, ככל שה-image קטן יותר כך ה-Cold Start קצר יותר. שימוש ב-node:20-slim במקום node:20, התקנת רק dependencies של production, והימנעות מספריות כבדות שלא צריך.
קוד אתחול יעיל: כל מה שקורה לפני שהשרת מתחיל להאזין, משפיע על Cold Start. אתחול חיבורי Database, טעינת קונפיגורציות, import של מודולים. כדאי לוודא שהקוד עושה רק מה שבאמת צריך בעלייה.

מודל תמחור: כמה זה עולה בשקלים

זה החלק שמעניין את כולם. מודל התמחור של Serverless GCP מבוסס על שלושה רכיבים: זמן מעבד (CPU), זיכרון (RAM) וכמות בקשות. נשים את זה בטבלה עם מחירים מעודכנים.

Cloud Functions Gen 2 (מחירים לאזור me-west1)

• 2 מיליון הפעלות בחודש חינם
• מעבר לזה: כ-0.0000004$ להפעלה (כ-0.0015 ש"ח)
• זמן חישוב: כ-0.0000100$ לכל GB-שנייה
• זיכרון: כ-0.0000025$ לכל GB-שנייה

Cloud Run (מחירים לאזור me-west1)

• 2 מיליון בקשות בחודש חינם
• 180,000 vCPU-שניות בחודש חינם
• 360,000 GB-שניות זיכרון בחודש חינם
• מעבר לזה: CPU כ-0.00002400$ ל-vCPU שנייה, זיכרון כ-0.00000250$ ל-GB שנייה

מה זה אומר בחיים האמיתיים

בואו ניקח דוגמה מעשית. אפליקציה שמשרתת 100,000 בקשות ביום (כ-3 מיליון בחודש), כל בקשה לוקחת חצי שנייה בממוצע, עם 256MB זיכרון:

Cloud Functions: אחרי ה-Free Tier, כ-1 מיליון הפעלות לחיוב. עלות חודשית בסביבות 50-80 ש"ח.
Cloud Run: עם קונפיגורציה של 0.5 vCPU ו-256MB RAM, עלות חודשית דומה, 40-70 ש"ח. אם מפעילים min-instances=1, צריך להוסיף עוד כ-150-200 ש"ח לחודש על ה-instance שתמיד רץ.

לשם השוואה: VM קבוע (Compute Engine, e2-small) עולה כ-60-80$ לחודש (כ-220-300 ש"ח) ללא קשר לצריכה. עבור אפליקציות עם עומס משתנה, Serverless חוסך משמעותית.

עבור מערכות בשלבי MVP או עם תנועה נמוכה, אפשר לפעול בתוך ה-Free Tier לחלוטין, עלות ענן של 0 ש"ח.

סקיילינג אוטומטי: זה קורה לבד

אחד היתרונות הגדולים של Serverless הוא Auto Scaling. לא צריך להגדיר כללי Scaling, לא צריך לנטר CPU ולהחליט מתי להוסיף שרתים. הכל קורה אוטומטית.

ב-Cloud Functions, כל בקשה (או כמה בקשות, ב-Gen 2 עם Concurrency) מקבלת instance. 10 בקשות בו-זמנית? 10 instances. 1,000 בקשות? 1,000 instances. יורד ל-0? לא רצים instances בכלל (ולא משלמים).

ב-Cloud Run, הסקיילינג דומה אבל עם יותר שליטה. אפשר להגדיר:

"`bash

gcloud run deploy my-service \

–min-instances 0 \

–max-instances 100 \

–concurrency 80 \

–cpu 1 \

–memory 512Mi

"`

ההגדרה הזו אומרת: כל instance מטפל בעד 80 בקשות במקביל, מקסימום 100 instances, ויכול לרדת ל-0 כשאין תנועה. ברגע שה-concurrency עובר את הסף, Cloud Run מרים instance נוסף אוטומטית.

Scale to Zero

היופי של Serverless הוא שכשאין תנועה, אין הוצאות. זה הופך את המודל לאידיאלי עבור:

• API פנימי שמשמש רק בשעות העבודה
• כלי ניהול שמשתמשים בו מספר פעמים ביום
• Webhook שמקבל אירועים מפוזרים
• סביבות פיתוח ו-staging שלא רצות 24/7

Use Cases אמיתיים: איפה אנחנו משתמשים בזה

API Gateway למערכת SaaS

מערכת SaaS שפיתחנו ללקוח כוללת API שלם שרץ על Cloud Run. האפליקציה בנויה ב-Node.js עם Express, מתחברת ל-Cloud SQL (PostgreSQL) ומשרתת את הפרונט שבנוי ב-Next.js. ההחלטה ללכת על Cloud Run הגיעה כי מדובר באפליקציה שלמה עם עשרות endpoints, middleware, ו-authentication layer. לקרוא עוד על פיתוח מערכות SaaS.

עיבוד תמונות ומסמכים

Cloud Function שמאזינה ל-Cloud Storage bucket. כל פעם שמשתמש מעלה תמונה, הפונקציה מתעוררת, עושה resize לכמה גדלים, ממירה פורמטים ושומרת את התוצאות. כל התהליך לוקח 2-5 שניות. בלי Serverless, היינו צריכים להחזיק שרת שרץ כל הזמן רק בשביל משימה שמתבצעת כמה עשרות פעמים ביום.

Webhook לשער תשלום

Cloud Function שמקבלת Webhook מספק סליקה, מוודאת שהתשלום עבר, מעדכנת את הסטטוס ב-Firestore ושולחת מייל ללקוח. כל הפונקציה 30 שורות קוד, עלות חודשית של כמעט 0 ש"ח.

דוחות מתוזמנים

Cloud Function שרצה כל בוקר בשעה 7:00 דרך Cloud Scheduler, שולפת נתונים מה-Database, מייצרת דוח ושולחת אותו במייל למנהלים. זמן ריצה: 10-15 שניות פעם ביום. עלות חודשית: אפסית.

מגבלות של Serverless שחייבים להכיר

Serverless הוא לא קסם. יש מגבלות שחשוב להבין לפני שמחליטים:

Stateless: כל בקשה עצמאית. אי אפשר לשמור מידע בזיכרון בין בקשות (טוב, אפשר, אבל אסור לסמוך על זה). צריך לאחסן state ב-Database, ב-Redis (Memorystore) או ב-Cloud Storage.
Cold Starts: כבר דיברנו על זה, אבל שווה להדגיש. לאפליקציות שדורשות זמני תגובה מיידיים (מתחת ל-100ms בכל בקשה), Serverless ללא min-instances הוא לא הפתרון.
Vendor Lock-in: קוד שרץ על Cloud Functions עם טריגרים ספציפיים ל-GCP (Pub/Sub, Firestore triggers) מחובר ל-GCP. מעבר לספק אחר ידרוש שכתוב. עם Cloud Run יש פחות Lock-in כי כל Dockerfile סטנדרטי ירוץ על כל פלטפורמה שתומכת בקונטיינרים.
Debugging מורכב יותר: אי אפשר לעשות SSH לשרת ולבדוק מה קורה. צריך לסמוך על Logs (Cloud Logging) ו-Tracing (Cloud Trace). ב-SysTech אנחנו מגדירים Structured Logging מהיום הראשון בכל פרויקט Serverless כדי שיהיה אפשר לחקור בעיות ביעילות.
גבולות משאבים: Cloud Functions מוגבל ל-32GB RAM ו-8 vCPUs. Cloud Run מוגבל ל-32GB RAM ו-8 vCPUs לכל instance. לעיבודים כבדים (ML inference, עיבוד וידאו גדול) אולי צריך פתרון אחר.

טיפים לפריסה מוצלחת

כמה דברים שלמדנו מניסיון בפרויקטים רבים של פיתוח תוכנה:

1. תתחילו עם Cloud Functions אם יש לכם פונקציונליות בודדת ומוגדרת. אל תבנו אפליקציה שלמה על Functions רק כי זה נראה פשוט יותר.

2. תעברו ל-Cloud Run ברגע שיש יותר מ-3-4 Functions שקשורות אחת לשנייה. שירות אחד עם routing ברור עדיף על עשר פונקציות שמתקשרות ביניהן.

3. תשתמשו ב-Cloud Build לתהליך CI/CD אוטומטי. Push ל-GitHub צריך להפעיל בנייה ופריסה אוטומטית. אל תפרסו ידנית.

4. תגדירו min-instances=1 לשירותים שפונים למשתמשי קצה. ה-Cold Start הוא חוויית משתמש גרועה.

5. תשתמשו ב-Secret Manager לכל הסודות (API keys, connection strings). לעולם אל תשימו credentials בקוד או ב-Environment variables גלויים.

שאלות נפוצות

מה ההבדל בין Cloud Functions ל-Cloud Run?

Cloud Functions מריץ פונקציה בודדת שמגיבה לאירוע. Cloud Run מריץ קונטיינר שלם (אפליקציה עם כמה endpoints). Cloud Functions פשוט יותר לפריסה של משימות קטנות, Cloud Run מתאים לשירותים מורכבים שצריכים שליטה מלאה בסביבת הריצה.

כמה עולה Serverless ב-GCP לעסק קטן?

עסק קטן עם אלפי עד עשרות אלפי בקשות ביום ישלם בדרך כלל בין 0 ל-100 ש"ח בחודש. ה-Free Tier של GCP נדיב מאוד ומכסה שימוש של מערכות קטנות עד בינוניות לחלוטין. עבור מערכות גדולות יותר, העלות עדיין נמוכה משמעותית בהשוואה לשרתים ייעודיים.

האם Serverless מתאים לאפליקציות עם הרבה תנועה?

כן. Serverless מסתדר מצוין עם עומסים גבוהים בזכות Auto Scaling. Cloud Run יכול להגיע למאות instances במקביל. הנקודה החשובה היא להגדיר את ה-max-instances ולוודא שה-Database תומך במספר החיבורים הנדרש. עבור עומסים מאוד גבוהים (מיליוני בקשות בשנייה), GKE עשוי להיות יעיל יותר מבחינת עלות.

איך מתמודדים עם Cold Start?

שלוש דרכים עיקריות: הגדרת min-instances כדי שתמיד יהיה instance חם, שימוש ב-Docker image קטן ומותאם, ואופטימיזציה של קוד האתחול. השילוב של השלושה מביא לזמני Cold Start של פחות משנייה.

האם אפשר להריץ מערכת שלמה על Serverless?

בהחלט. מערכות שלמות עם כמה Microservices, כל אחד על Cloud Run, עם Cloud Functions לטיפול באירועים ומשימות רקע. הארכיטקטורה הזו היא מה שאנחנו ב-SysTech ממליצים לרוב הפרויקטים החדשים. היא משלבת גמישות, עלות נמוכה ותחזוקה מינימלית.

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

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

רוצים לבנות את המערכת הבאה שלכם על Serverless? צרו איתנו קשר ונשמח לדבר על איך להתאים את הארכיטקטורה לצרכים שלכם.