זה טיפה מעבר לזה
ההבדל בין חלוקה של אפליקציה מונוליטית ל - services לבין חלוקה לגישת micro services היא שהמיקרו עושים דבר אחד והם כל כך קטנים שמעלים אותם פעם אחת ולא משנים אותם. במידה וצריך לשנות אותם אתה פשוט מעלה micro service חדש ומוציא את הישן לגמלאות. בנוסף לכל micro service יש owner אחד שהוא המפתח והוא אחראי עליו גם ב Production מרגע שעלה לראשונה ועד שהוא "יוצא לגמלאות". ההיגיון מאחורי זה הוא שכמה שמדברים על קוד שהוא קל לתחזוקה, זה לא באמת עובד בפועל ותמיד תגיע בסוף לקוד ספגטי ולריפקטור בלתי נמנע ולכן אתה מוותר על זה מראש ובונה מלכתחילה יחידות קוד שהן מעין un mutable.
 
זה לפחות מה שאני זכור מהרצאות בנושא שהייתי.
 
הדעה שלי בנושא שזה נחמד אבל ממש לא הייתי בונה מאפס מערכת שמורכבת רק מ micro services כי לדעתי זה מתכון לבלגן, כמה שלא תנסה לנטר אותם ולנהל אותם.. בטח לא הייתי לוקח מערכת קיימת ומפרק את כולה ל micro services (מדובר בעבודה אינסופית היות שצריכים להיות אלפים כאלה במערכת גדולה).
 
אני יותר תומך בעניין של שילוב, מערכת שבנויה מכמה חלקים גדולים לפי חלוקה של business ובמידת הצורך מוסיפים גם micro services כשיש לך באמת רכיבים שהם ממש קטנים ומוגדרים ו re-usable. למשל אני מתכנן אצלנו לבנות micro service אחד שתפקידו למשוך מיילים משרת או שרתי מייל ולדחוף אותם לטור (rabbit) ואחר שתפקידו למשוך הודעות מייל מטור (גם rabbit) ולשלוח אותם במייל.