Microservices vs Monolith, בחירת ארכיטקטורה

ב-2026, 42% חוזרים למונוליט. אז מי צדק?

ב-2023 Amazon Prime Video פרסמה פוסט שהדהים את תעשיית הפיתוח: צוות ה-Video Quality Analysis עבר מ-distributed microservices ל-monolith, ועלויות ה-infrastructure צנחו ב-90%. ב-2026, מחקרים מראים ש-42% מהארגונים שאימצו microservices עוברים חזרה לאיחוד (consolidation). Sam Newman ו-Neal Ford, שני האנשים שכתבו את ספרי הייחוס על microservices, הכריזו על 2026 כ"רנסנס של המונוליט".

זה לא אומר ש-microservices טעות. זה אומר שהשאלה "microservices או מונוליט?" היא השאלה הלא נכונה. השאלה הנכונה היא: האם ה-complexity של distributed systems מוצדק ב-context הספציפי שלך?

בשיעור הזה נלמד לענות על השאלה הזו, ולהשתמש ב-Claude בצורה שתביא תשובות מדויקות, לא עצות גנריות.

שלוש ארכיטקטורות, לא שתיים

רוב הדיונים מדברים על binary: מונוליט או microservices. אבל ב-2025-2026 הוסף שחקן שלישי שמשנה את המשוואה: ה-modular monolith (או "modulith").

קריטריון	Monolith	Modular Monolith	Microservices
גודל צוות	1-10	10-50	50+
Deployment	unit אחד	unit אחד, modules נפרדים	כל service עצמאי
Debugging	stack trace אחד	stack trace אחד, boundaries ברורות	distributed tracing נחוץ
Scaling	הכל יחד	הכל יחד (אבל מוכן לפיצול)	כל service בנפרד
מוכנות לפיצול	קשה	קל, boundaries קיימות	כבר פוצל

Yoav Nordmann מ-Israeli Tech Radar מסכם את זה היטב: "התחל עם business logic. פתור את הבעיה, תוך שמירה על מוכנות לפיצול כשצריך." זו גישת ה-modulith: לא לפתור בעיות לפני שהן קיימות.

Shopify עיבד 30TB לדקה ב-Black Friday 2025, על modular monolith. אם זה מספיק ל-Shopify, זה מספיק לרוב הסטארטאפים הישראליים.

איך לשאול את Claude, החלטת ארכיטקטורה

הבעיה הנפוצה: שואלים "microservices או מונוליט?" וקוחים תשובה גנרית. הפתרון, לתת context ספציפי ולבקש decision tree.

מתי כדאי לעבור ל-microservices?

אני CTO של סטארטאפ ישראלי בתחום ה-SaaS, מערכת ניהול לוגיסטיקה לחברות הובלה. 8 engineers, monolith ב-Node.js (90K LOC), 200 לקוחות B2B, 5M events ביום. שלושה modules עיקריים: משלוחים, billing, ו-driver management. 1. מה ה-architecture המומלץ לשלב הנוכחי, monolith / modular monolith / microservices? 2. אם modular monolith: אלו boundaries לאכוף ואיך (ArchUnit? ESLint rules?)? 3. מה הtrigger שאמור לגרום לנו לפצל service ראשון? 4. איזה service נפצל ראשון ולמה? תן decision tree ולא רק המלצה.

Migration בלי Downtime, Strangler Fig Pattern

כשמחליטים לפצל service ממונוליט, ה-Strangler Fig pattern הוא הדרך הבטוחה. Martin Fowler תיאר אותו בהשראת עץ תאנה שעוטף עץ אחר: מתחיל קטן, צומח, ובסוף מחליף, מבלי שהעץ הישן "יידע" שמשהו קורה.

בפועל: מוסיפים API Gateway מול ה-monolith, ומעבירים endpoints אחד אחד לservice החדש. בכל נקודה, ה-monolith עדיין רץ, המשתמשים לא מרגישים שינוי. זה עבד ל-Wix (migration שנמשך שנים), לבנקים ישראליים שעדיין מבצעים אותו, ולכל חברה שלא רצתה big bang.

הפרומפט לClaudeלתכנון migration:

We have an Israeli e-commerce monolith (Rails, 180K LOC, 12 engineers, 500K orders/month).
Modules: User management, Product catalog, Order processing, Payment (PayPlus), Notifications, Search.

Using Strangler Fig pattern:
1. Which service to extract FIRST (criteria: low coupling, high independent value)?
2. Step-by-step migration plan, 3 phases, no downtime
3. For Payment service specifically: how to handle Order+Payment as atomic operation across services?
4. What does our API Gateway routing table look like at each phase?

שאל במפורש על distributed transaction, זו הבעיה הקשה ביותר ב-microservices, וClaude ידלג עליה אם לא תבקש.

Communication Patterns, לא החלטה אחת

טעות נפוצה: לבחור "gRPC" או "REST" ולהחיל על כל ה-services. האמת, כל זוג services מחליט בנפרד לפי הצורך שלו:

Auth check (כל request, p99 מתחת ל-10ms): gRPC sync, מהיר, strongly typed, latency נמוכה
Payment charge (חייב להיות אטומי): Saga pattern עם choreography, OrderService שולח event, PaymentService מאזין ומחייב, שולח event חזרה. Compensation אם נכשל.
שליחת מייל אישור (fire and forget): Message queue (SQS/RabbitMQ), Notification service מאזין בנפרד, Order service לא מחכה
Analytics (קריאות batch): Event streaming (Kafka), Analytics service קורא מ-event log, לא מ-live services

Performance overhead של network calls בין services

Distributed systems complexity ו-operational overhead שהארגון לא היה מוכן אליו

עלות infrastructure גבוהה מדי

Technology lock-in לשפות ספציפיות

מעבר מהיר ומלא ממונוליט ל-microservices בבת אחת

הוספת API Gateway שמעביר תנועה בהדרגה לservices חדשים, בעוד המונוליט ממשיך לרוץ

בנייה של modular monolith כצעד ביניים לפני microservices

מניעת cascading failures כשservice נופל

Services גדולות מדי שאפשר לפצל

שימוש ב-gRPC במקום REST

Distributed Monolith, microservices שמשתפות DB ותלויות אחת בשנייה ב-sync

Database per service במקום shared database

שלוש טעויות שהורסות migrations

Distributed Monolith: microservices שעדיין קוראות אחת לשנייה ב-sync לכל operation ומשתפות DB. אתה משלם את מחיר distributed systems ולא מקבל שום יתרון. זה ה-anti-pattern הכי נפוץ בסטארטאפים ישראליים שמיהרו.
Microservices too early: צוות של 5 אנשים עם 30 services כי "כך עושים בנטפליקס". יש תיעוד של סטארטאפ שמת בגלל זה, בילו יותר זמן ב-debugging network latency מאשר בשיחות עם לקוחות. Netflix הגיעה ל-microservices אחרי שנים של scale, לא לפניהן.
Skip operational readiness: microservices דורשות distributed tracing (Jaeger/Zipkin), centralized logging (ELK), service mesh (Istio), ו-Kubernetes. בלי אלה, כשservice נופל בשעה 2 לילה, אתה מחפש מחט בערימת שחת. וודא שהinfra קיים לפני שמתחילים.

סיכום, מה לזכור

ברירת המחדל ב-2026 היא modular monolith, לא microservices. פצל רק כשיש pain אמיתי ומוכח.
המספרים: צוות מתחת ל-10, monolith. 10-50, modular monolith. מעל 50 עם domain teams, אז שקול microservices.
Strangler Fig pattern הוא הדרך היחידה לmigration בלי downtime וסיכון.
Distributed transaction הוא הבעיה הקשה ביותר, שאל על Saga pattern בפירוש.
Claude אפקטיבי ביותר כשנותנים לו context ספציפי: גודל צוות, LOC, load, modules קיימים, לא שאלות גנריות.