אחד הצוותים נאבק שעות עם שינוי API פשוט בגלל שהוא דרש תיאום בין חמישה שירותים שונים. הם חשבו שיש להם מיקרו-סרביסים, אבל בפועל בנו מונוליט מבוזר, שזה הגרוע משני העולמות.
חבר CTO אמר לי שהוא "מתחרט שנשארנו עם המונוליט יותר מדי זמן", שאילתת מסד נתונים איטית, רק אחת, הפילה את כל האפליקציה. עשרות אנשים חיכו לשינויים פשוטים שלקחו שלושה ימים.
צוות אחר השקיע חמש שעות להוסיף "סינון לפי שכונה" בפאנל הניהול. חמש שעות כדי להוסיף כפתור. כפתור שמציג נתונים קיימים.
שלושה סיפורים שמלמדים דבר אחד: ארכיטקטורת תוכנה טובה לא מתחילה בסכמת מסד הנתונים. היא מתחילה בהבנת העסק.
"הארכיטקטורה זה הסכמה במסד הנתונים"
הרבה אנשים (בעיקר מפתחים) חושבים שארכיטקטורת מוצר תוכנה היא בעיקר סכמה במסד הנתונים. ואולי נוכל להבין את זה אם נשאל מאיפה נגזרת החשיבה הזאת? וכנראה שזה מהנסיון שמפתחים מתחילים בו: כותבים קוד, מגדירים טבלאות, מחברים ביניהם.
אבל פעולות ה"תכנות" האלו, שמבוצעות היום לגמרי עם כלי תכנות כמו קלוד קוד, הם רק קצה קצהו של תהליך בניית הארכיטקטורה ובטח שלא תחילתו.
כשמתכננים מוצר, מה שקורה בפועל הוא תרגום: דרישות עסקיות מתורגמות לחווית משתמש, היא מתורגמת לארכיטקטורה והיא מתורגמת לקוד וגם לסכמה. הסכמה היא תוצאה, לא נקודת ההתחלה.
לכן השאלות הנכונות לשאול לפני כל ארכיטקטורה:
- כמה משתמשים יהיו למוצר? כמה מהם יתחברו בו-זמנית? זה יקבע מהיום הראשון איך תיראה ההתרחבות.
- באיזה כובע המשתמשים האלו ניגשים למוצר? משתמש קצה, מנהל, סוכן אוטונומי: לכל אחד מהם דפוסי שימוש שונים וגם ציפיות שונות לאיך יראה המידע.
- מהי מהירות התגובה הנדרשת? 200ms הם הרבה מאוד לדף שחשוף לציבור הרחב וזה שונה מ-5 שניות עבור הפקה של דוח פנימי, שזה לגמרי בסדר.
- איך מגנים על הפרטיות? הדרישה הזו מעצבת איפה שומרים נתונים ואיך ניגשים אליהם.
ארכיטקטורה שנגזרת מהתשובות לשאלות האלה עומדת בלחץ של צמיחה והתרחבות. ארכיטקטורה שמתחילה מ"מה הכי טרנדי עכשיו" לא תחזיק.
מיקרו-סרביסים כפתרון ומיקרו-סרביסים כבעיה
הדיון על מיקרו-סרביסים הפך לאחד הדיונים האמוציונליים ביותר בהנדסת תוכנה. יש מי שמגן עליהם בלי שום תנאים, ויש אלו שמסרבים להם על הסף.
שניהם טועים.
מיקרו-סרביסים הם לא דיון על אלגנטיות ולא נקבעים בגלל טרנדים. הם דיון על עצמאות של צוותים ודיון על עמידות של מוצר
הסיפור של ה-CTO עם המונוליט ממחיש את זה: עשרות אנשים, דליוורי זריז, הכל עובד, עד שמגיעה נקודת השבר. שאילתה איטית אחת. פיצ'רים חיכו בגלל באג לא קשור. הצוות של המובייל חיכה שלושה ימים לשינוי API. "חשבנו שככה פשוט יותר, אבל התברר שזה צוואר הבקבוק"
מצד שני, הצוות עם החמישה שירותים שהיו לגמרי מתואמים גם כן לא פתר את הבעיה הזו. הם, אולי, פיזרו אותה.
מיקרו-סרביסים אמיתיים מאפשרים לכל צוות לפרוס בצורה עצמאית, להכשל בצורה עצמאית, ולהתרחב בצורה עצמאית. אם שינוי בשירות אחד עדיין דורש תיאום עם ארבעה צוותים אחרים, יש לכם מונוליט מבוזר, לא מיקרו-סרביסים.
ריקו פריטשה מנסח זאת מצוין: הבעיה אינה חוסר בכלים, היא אי-הבנה של מה מודולריות אמיתית אומרת.
פאנל הניהול כמבחן ארכיטקטורה
חמש שעות לסינון לפי שכונה. שתי שעות פרונטאנד, שעה בקאנד, שעתיים QA לבדוק שלא שוברים דפדוף. לכפתור שמציג נתונים קיימים.
מפתחים שונאים לבנות ממשקים כאלה. מנהלי מוצר שונאים לתחזק אותם. צוותי תמיכה שונאים להשתמש בהם.
מנהל פיתוח אחד עשה משהו שנראה במבט ראשון קיצוני: הוא החליף את פאנל הניהול כולו שמומש ב-React עם ממשק של Text-to-SQL. והתוצאה היתה מיידית מהירות הפיתוח עלתה פי שלושה בין לילה. הצוות מגדיר את הסכמה פעם אחת, ואנשי התמיכה שואלים בשפה טבעית: "תראה לי את חמשת המשתמשים עם ה-LTV הגבוה ביותר שלא קנו בחודש האחרון". עכשיו הצוות פנוי לפתח את המוצר.
הנקודה שנמצאת בעומק העניין: חמש שעות לסינון לפי שכונה הן לא בעיית פיתוח, הן בעיית ארכיטקטורה. כשממשקי ניהול הם כבדים וקשים מדי לשינוי, זה סימן שהם לא תוכננו כחלק מהתמונה הכוללת.
נקודות לסיכום
ארכיטקטורה טובה אינה זו שנראית יפה בדיאגרמה, אלא זו שמאפשרת לצוות לנוע מהר, להכשל בצורה בטוחה, ולצמוח מבלי לבנות מחדש כל הזמן.
שלושת הלקחים מהסיפורים האלה:
- התחילו מהעסק, לא מהטכנולוגיה
- בדקו את עצמאות הצוותים לפני שאתם הולכים על מיקרו-סרביסים
- ממשקי ניהול כבדים הם תסמין ארכיטקטוני, לא גזירת גורל