מה זה Microservices? הסבר + משרות פתוחות בישראל

מיקרוסרוויסים היא ארכיטקטורה שבה המערכת מפוצלת לשירותים קטנים ועצמאיים, שכל אחד מהם נפרס, מתוחזק ומוגדל בנפרד ומתקשר עם האחרים דרך ממשק מוגדר. בלוח HiTakeJob פתוחות כרגע 30 משרות שמזכירות Microservices, 25 שמזכירות Kafka ו-110 שמזכירות Kubernetes.

מה הבעיה שזה בא לפתור - והיא לא טכנית

ההנחה הרווחת היא שהמניע הוא ביצועים. בפועל, המניע העיקרי ארגוני: כשחמישה צוותים עובדים על אותו בסיס קוד, כל שחרור דורש תיאום בין כולם, וצוות אחד מעכב את השאר. פיצול לשירותים נותן לכל צוות בעלות על משהו שהוא יכול לשחרר לבד.

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

מה מרוויחים - ומה משלמים

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

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

איך מחליטים איפה לחתוך?

זו ההחלטה שקובעת אם הארכיטקטורה תעבוד. הכלל המנחה הוא לחתוך לפי תחום עסקי ולא לפי שכבה טכנית:

• נכון: שירות משרות, שירות מועמדויות, שירות התראות - כל אחד מחזיק את הנתונים ואת הלוגיקה שלו.
• שגוי: שירות "מסד נתונים", שירות "לוגיקה", שירות "ממשק" - כל שינוי עסקי נוגע בשלושתם.
• גבול טוב הוא כזה שרוב השינויים נוגעים בשירות אחד בלבד.
• סימן לגבול שגוי: כמעט כל פיצ'ר דורש שחרור מתואם של שניים או שלושה שירותים.
• שירות שהוא בעצם טבלה עם ממשק מעליה כמעט תמיד קטן מדי.

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

איך שירותים מדברים זה עם זה

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

25 משרות פעילות מזכירות Kafka, שהיא הפלטפורמה הנפוצה לשתי השורות האחרונות. הכלל המעשי: כל פעולה שאפשר לדחות בשנייה - שליחת מייל, עדכון אנליטיקה, סנכרון - עדיף שתהיה אסינכרונית, כי היא מנתקת את זמינות השירות שלכם מזמינות האחרים.

איך מונעים מכשל אחד להפיל את הכול

שלושה מנגנונים שנחשבים היום לחובה בכל קריאה בין שירותים, ושחסרונם הוא הסיבה הנפוצה ביותר לתקלה מתפשטת:

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

מה נעשה קשה יותר

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

הסעיף השני הוא מה שהופך ניטור ממותרות להכרח: במערכת מבוזרת, בלי מעקב מבוזר, חקירת תקלה הופכת לניחוש. הרחבנו על כך במה זה Observability.

מה חייב להיות קיים לפני שמפצלים

ארגון שמפצל בלי התשתית הזו מקבל את כל המורכבות ומעט מהתועלת. רשימת המינימום:

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

הסעיף האחרון הוא זה שנשכח, והוא הופך אחרי שנתיים לבעיה הגדולה ביותר: שירות שאיש לא מכיר, שרץ בייצור, ושכולם חוששים לגעת בו.

מה שואלים על זה בראיון

בראיונות System Design בישראל זה נושא כמעט ודאי, והשאלות חוזרות:

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

הכנה מלאה נמצאת בראיון System Design, ואפשר לראות משרות במשרות Microservices ובמשרות Kafka.

שאלות נפוצות

מאיזה גודל צוות זה מתחיל להיות מוצדק?

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

כל שירות חייב מסד נתונים משלו?

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

מה זה מונוליט מודולרי?

מערכת שנפרסת כיחידה אחת אבל בנויה פנימית ממודולים עם גבולות ברורים וממשקים מוגדרים. זו נקודת הפתיחה המומלצת היום: היא זולה לתפעול, ומאפשרת לחלץ מודול לשירות נפרד כשמתעורר צורך אמיתי.

כמה משרות מיקרוסרוויסים יש בישראל?

29 משרות פעילות מזכירות את המונח במפורש, לצד 110 שמזכירות Kubernetes ו-25 שמזכירות Kafka - הכלים שמשמשים לרוב בארכיטקטורה כזו. חלק מהמשרות לא מזכירות את המילה אף שהמערכת בנויה כך.

האם זה משפר ביצועים?

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

מה ההבדל בין מיקרוסרוויס לפונקציה ללא שרת?

מיקרוסרוויס הוא שירות שרץ ברציפות ומחזיק את הלוגיקה של תחום עסקי; פונקציה ללא שרת רצה רק כשמפעילים אותה ומתאימה למשימות נקודתיות. הן משלימות - ארגונים רבים מריצים שירותים קבועים לליבה ופונקציות לעיבוד אירועים.

איך מתחילים פיצול של מערכת קיימת?

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