אמלק;
הספר Building Microservices מאת Sam Newman אינו מדריך טכני לבנייה בפועל של סרביסים, אלא מדריך אסטרטגי – מפת דרכים למי שנמצא בשלבים הראשונים של אימוץ מיקרו-סרביסים או פשוט רוצה להבין את האקוסיסטם. הספר נוגע בעשרות תחומים – מתקשורת בין שירותים, דרך פריסה, בדיקות, ועד שיקולים ארגוניים – אבל בכולם הוא בוחר בעומק נמוך ורוחב גבוה. זו חוזקה מסוימת, אבל גם מגבלה
רקע: למה בכלל לקרוא את הספר?
Sam Newman מגיע לעולם המיקרו-סרביסים לא בתור אקדמאי או חוקר תיאוריטי, אלא כאיש שטח – יועץ שעבד עם ארגונים רבים שהחלו את המעבר ממונולית למיקרו-סרביסים. הספר שואב מהניסיון הזה ומנסה לבנות תשתית מושגית לכל מי שרוצה להבין איך נראית מערכת מבוזרת באמת, לא רק איך לכתוב endpoint אחד.
הייחודיות בספר הזה היא בכך שהוא מציג גישות שונות תוך דיון בשיקולים, יתרנות וחסרונות – ולא בוחר ״דרך אחת נכונה״. הוא מדגיש שוב ושוב שהמיקרו-סרביסים אינם מטרה – אלא אמצעי שאמור לשרת צרכים מסוימים, ומומלץ להשתמש בהם רק כשברור שהמונולית אינו משרת עוד את המערכת.
סקירת הנושאים המרכזיים בספר
1. מונולית מול מיקרו-סרביסים – לא שחור ולבן
הספר פותח בדיון חשוב: למה בכלל לפצל? ניומן מסביר שהמונולית – אפליקציה אחת גדולה – היא מבנה פשוט להבנה ונוח לפריסה, בעיקר בתחילת הדרך. אך כשמערכת גדלה, מונולית עלול להפוך לארגז כלים אחד עצום שלא ניתן לשנות בלי לפגוע בכל השאר.
לעומת זאת, ארכיטקטורת מיקרו-סרביסים מחלקת את המערכת לשירותים קטנים, שכל אחד מהם מקבל אחריות למשהו ייחודי. זה מאפשר לצוותים לעבוד במקביל, לשנות רכיב אחד מבלי להשפיע על השאר, ולעשות scaling רק לשירות הנדרש. מצד שני, זה מייצר מורכבות תשתיתית ותקשורתית.
המסקנה של ניומן: מיקרו-סרביסים הם לא תרופה קסומה. לעיתים מונולית עם מודולריות פנימית טובה – עדיף.
2. איך לפצל מונולית בצורה חכמה?
אחד הפרקים החשובים בספר עוסק באתגר המעשי של מעבר ממונולית למערכת מבוזרת. כאן ניומן מציג כמה עקרונות:
- להתחיל מפיצול לוגי – לזהות תחומים עסקיים מובהקים בתוך המערכת
- לא למהר לפצל לתהליכים נפרדים – אפשר להתחיל ממודולים מבודדים באותו תהליך
- להיעזר ב Bounded Context מתוך עולם ה-Domain Driven Design, כדי למפות גבולות טבעיים בין רכיבי המערכת.
הגישה המומלצת היא להתחיל בצעדים קטנים – לפצל שירות אחד או שניים, וללמוד מהכשלונות המקומיים לפני שעוברים לפיצול מאסיבי.
3. תקשורת בין שירותים – לא רק REST
במערכת מבוזרת, התקשורת בין סרביסים הופכת לנושא מרכזי. ניומן מקדיש פרקים שלמים לסוגי תקשורת אפשריים:
- סינכורנית – סרביס A מבצע קריאה ישירה לסרביס B ומחכה לתשובה. פשוט להבנה, אך חושף את A לתקלות זמינות של B.
- אסינכרונית – סרביס A שולח הודעה או איוונט ולא מחכה לתגובה. זה מאפשר גמישות וניטור טוב יותר, אך מייצר קושי במעקב.
- תקשורת מבוססת דאטה – סרביס A כותב לקובץ או למסד נתונים, וסרביס B קורא. גישה שנחשבת לבעיה ארכיטקטונית אם לא נעשית בזהירות לפי ניומן.
- אירועים (Event-Driven) – שירותים מפרסמים אירועים על שינויים, והמאזינים מגיבים לפי הצורך. זו גישה מודולרית שמאפשרת תלות נמוכה בין הסרביסים שלנו.
ניומן מציג את הטכנולוגיות שמשמשות לתקשורת בין סרביסים – REST, gRPC, GraphQL, תורים כמו Kafka או RabbitMQ – אבל מדגיש שהבחירה לא טכנולוגית אלא ארכיטקטונית: מה דפוס השיח, ולא באיזה פרוטוקול הוא ממומש.
4. חוזים בין שירותים – איך לא לשבור את כולם
כל מפתח מכיר את המשפט: ״שיניתי את השם של השדה, ועכשיו שום דבר לא עובד״.
הספר שם דגש רב על חוזה (Contract) בין סרביסים – ההתחייבות בין צד שולח לצד מקבל. ברגע שסרביס A תלוי במבנה הנתונים שמחזיר סרביס B, כל שינוי עלול לשבור את המערכת.
ניומן ממליץ על כמה גישות:
- להשתמש בגרסאות לתקופת המעבר – כל שינוי קטן הוא גרסה חדשה של החוזה, ואז לכל סרביס ברור מול איזה חוזה הוא עובד בכל רגע.
- להימנע משינויים ששוברים את החוזה – עד כמה שאפשר
- לשקול כלי Consumer-Driven Contract, שמוודאים שהסרביסים ממשיכים לקיים את הציפיות ההדדיות שלהם.
ניומן מדגיש שהעקרון המרכזי הוא: יש לנהל את השינויים כחלק מתהליך פיתוח אחראי, לא כתגובה חפוזה לצרכים מקומיים.
5. פריסה – איך פורסים מאות סרביסים?
במונולית, פריסה היא לרוב פעולה אחת build -> deploy.
במערכת מבוזרת, כל שירות הוא יחידת פריסה עצמאית – וזה יוצר סיבוך תפעולי. הספר עוסק בתיאום בין סרביסים, ניהול תלויות על ידי גרסאות, וטכניקות כמו blue/green deployment ו-canary releases. ניומן מציג פתרונות מעשיים לבעיות כמו:
- איך למנוע מצב שסרביס חדש נשבר בגלל תלות שלא עודכנה.
- איך להתמודד עם זמני השקה שונים לסרביסים שמדברים זה עם זה
- למה עדיף שצוותים ייקחו אחריות מלאה על פריסת הסרביסים שלהם.
6. בדיקות – מה בודקים כשיש 80 סרביסים?
במערכת מבוזרת בדיקות E2E הופכות למסורבלות. הספר מדבר על:
- בדיקות יחידה (
Unit Testing) בתוך הסרביסים - בדיקות חוזה בין סרביסים.
- בדיקות אינטגרציה מבוקרות
- שימוש ב-
test doublesו-mocks - איך לתכנן את הפייפליין של
CI/CDכך שיזהה בעיות מוקדם?
ניומן דוגל בגישה של shift-left: כמה שיותר לבדוק מקומית, וסרביסים צריכים לדעת לבדוק את עצמם.
7. מבנה הארגון – איך מתארגנים סביב השירותים?
Conoway's Law אומר שארגונים בונים מערכות שמשקפות את מבנה התקשורת הפנימי שלהם. ניומן משתמש בעקרון הזה כדי להמליץ על:
- לבנות צוותים סביב סרביסים (או קבוצה של סרביסים), ולא סביב ״שכבות (Frontend, DB וכו׳).
- לתת לכל צוות אחריות מלאה: פיתוח, פריסה, תחזוקה
- למדוד הצלחה לפי יכולת הצוות להעביר פיצ׳ר לייצור בלי תלות.
גישה זו תומכת ב-DevOps בתוך הצוותים וב-Ownership מלא של המערכת.
דעתי האישית על הספר
מה אהבתי?
- היקף רחב – הספר מדבר על הכל: תקשורת, פריסה, מבנה ארגון, דאטה, scaling, observability ועוד.
- דיון רפלקטיבי – אין פה העברת תורה או סדרת חוקים של ״כך תעשה״, אלא ״מהן האפשרויות ואיך לבחור״.
- קול פרגמטי – ניכר שניומן ראה מערכות אמיתיות, ולא מדבר מתוך מעבדה.
מה היה חסר לי
- עומק מעשי – ברוב הנושאים, אין דוגמאות קונקרטיות. אין
pseudo-code, תרשימים מפורטים וכו׳. - טכנולוגיה עדכנית – הספר נכתב ב-2015 ועודכן אחרי כמה שנים לגרסה שניה, אבל מאז העולם התפתח מאוד ומבחינת סקירה טכנולוגית הוא קצת מיושן.
למי הספר מתאים?
הספר Building Microservices מתאים בראש ובראשונה למהנדסי תוכנה, ראשי צוותים וארכיטקטים שנמצאים לפני או בתחילת מעבר ממערכת מונוליתית לארכיטקטורה מבוזרת. הוא שימושי במיוחד עבור מי שרוצה להבין את עקרונות המיקרו-סרביסים, לא רק מהבחינה הטכנית אלא גם מהזווית הארגונית והמערכתית.
אנשי דבאופס, למשל, ימצאו בו תובנות חשובות על הקשרים בין סרביסים, ניהול תצורה ופריסה מבוזרת.
גם מפתחים סקרנים שרוצים להבין את התמונה הרחבה – איך כל חלק במערכת תום לארכיטקטורה הכוללת – יפיקו ערך רב.
לעומת זאת, הספר פחות יתאים למי שכבר מתנסה בפיתוח והפעלה של מערכות מקירו-סרביסים מורכבות, שכן הוא לא מספק דיון מעמיק על הסוגיות או מספק כלים מעשיים לעבודה יומיומית, וגם לא יענה על הצרכים של מי שמחפש מדריך עם דוגאמות קוד, קונפיגורציות ו-Design Patterns.
