דפוסי ארכיטקטורה (Architectural Patterns): דפוסי עיצוב, בגדול

בפוסט זה אנסה לשפוך אור על נושא שיש לגביו בלבול רב - דפוסי ארכיטקטורה. בפשט: דפוסי ארכיטקטורה (כלומר: Architectural Patterns) הם דפוסים חוזרים בארכיטקטורות של מוצרים.

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

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


אתן לכם מטאפורה לדפוסי ארכיטקטורה:

דפוסי ארכיטקטורה הם כמו מתכון למרק

דפוסי ארכיטקטורה הם פתרון מהיר לבעיה שדורשת מיומנות לפתור - אבל המתכון הוא לא בהכרח הפתרון האופטימלי.
אם אתם לא ממש מומחים בבישול - שימוש בדפוס קיים יכול מאוד לעזור. ניסיון "להמציא מתכון מהראש" יכול להסתיים בחוסר נעימות.
מצד שני, המתכון הוא לא האידאל, ושף מוכשר יוכל להרכיב מתכון טוב בהרבה בהתחשב בחומרי הגלם הזמינים, הסועדים, או מצב הרוח. למתכון מוכן אין את ההקשר למצב הייחודי שלכם [א]. המתכון גם פעמים רבות הופשט מהאידאל, בכדי שהיה אפשר להעביר אותו לרבים, ועל גבי תקשורת מוגבלת (זה לא שאתם עוברים Mentoring של כמה ימים על המתכון).


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


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

הדפוסים עליהם נעבור בפוסט

• כדור גדול של בוץ (Big Ball of Mud)
• "הדר המסודר" (Hadar Amesudar)
• "שכבות עוגה" (Layered Architecture)
• MVC (קיצור של Model-View-Controller)
• "דודות מרכלות" (Event-Driven Architecture)
•  Command-Query Separation (בקיצור: CQRS או CQS) 
• "גרעין קטן" (MicroKernel) ודרכו נזכיר גם Plug-in Architecture
• "מיקרו-שירותים" (Micro-Services Architecture, בקיצור: MSA)

דפוסים נפוצים אחרים שלא נעבור עליהם הם, אך שווה להזכיר:

• צינורות ומסננים (Pipes & Filters) - אותו כיסיתי בפירוט בפוסט משלו.
• BlackBoard (רלוונטי בעולם של בינה מלאכותית)
• MVP, MVVM או Presentation-Abstraction-Control (דומים למדי ל MVC)
• Broker (רלוונטי במערכות מבוזרות)
• Model-Driven Architecture (מן "רעיון גדול" שלא ממש "תפס") או Domain-Specific Languages (בקיצור DSL - רעיון שהצליח חלקית).
• וכו'

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

בגדול אזכיר ש:

• לדפוסים יש ערך רב כשפה משותפת וכמקור השראה.
• הצמדות לדפוסים "כפי שהוגדרו" - יכולה להיות הרסנית.
• כדאי ליצור וריאציות שלכם של הדפוסים שיתאימו לכם יותר, או לשלב רעיונות (Mix and Match) מדפוסים שונים.

בואו נצא לדרך!

כדור גדול של בוץ (Big Ball of Mud)

השם ה(לא) מחמיא הזה כמובן ניתן ל Anti-Pattern. כדור גדול של בוץ הוא מצב בו כל המחלקות במערכת שלנו נמצאות ב Pool אחד משותף, ללא חלוקה ברורה ומסודרת.
מצב זה אולי נוח כאשר יש 10 מחלקות, אך מאוד לא נוח כאשר יש כ 1000 מחלקות במערכת.
אפשר בהחלט להתחיל במערכת עם "כדור גדול של בוץ", לגלות את התכונות והמבנה והרצוי של המערכת - ואז לחלק. ככלל אצבע הייתי מצביע על כמה עשרות מחלקות, לכל היותר, כנקודה בה כדאי מאוד שהיה כבר מבנה מוגדר.

מדוע כדאי לנו לחלק את המערכת לחלקים? בגלל:

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

את 2 הבעיות הראשונות תיארתי בפירוט בפוסט מדוע אנו זקוקים ל Software Design?

"הדר המסודר"

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

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

• מחלקות עד 1000 שורות קוד
• מחלקות מתחת ל 1000 שורות קוד
• קבועים, enums, או data objects (שהם בד"כ מאוד קטנים)

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

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

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

• דואר נכנס
• דואר יוצא
• אנשי קשר
• קונפיגורציה
• אחר

החלוקה הזו נשמעת יותר הגיונית, אבל גם בה יש בעיות עקרוניות. למשל: הקבוצה "אחר" יכולה להכיל לא-מעט מחלקות שלא מתקשרות ישירות לפונקציה "עסקית" (persistence, helpers, פקדי UI שבשימוש חוזר, וכו'). יצרנו שם "כדור בינוני של בוץ" בפני עצמו. ההתמצאות עצמה היא בעיקר ברמת האזורים ("שכונות בעיר") אך לא מכסה רזולוציה קטנה יותר ("רחובות").
דבר נוסף הוא שכדי להשיג Developer Scalability (היכולת של הרבה אנשים לעבוד על המערכת במקביל) אנו נרצה להטיל מגבלות על היכולת של החלקים השונים של המערכת לתקשר זה עם זה.

מדוע אנו מעוניינים בסדר וניהול תלויות?

נמשיל את העניין לבעיה פשוטה מאוד: הפרדה של קוד בין 2 מחלקות:

את קוד ה Parser אנו מחלקים ל2 חלקים. מדוע?

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

* כל עוד החלוקה היא אפקטיבית

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

• הכמסה (encapsulation) - מגבלה מאוד מקובלת בעולם ה OO, שמפרידה בין חלקים ציבוריים (בהם ניתן ליצור תלות) ופרטיים (בהם לא ניתן ליצור תלות). עצם כך שצמצמנו את התלויות - הגברנו את הסיכוי ששינוי בקוד (באזור הפרטי) לא ידרוש שינויים או ישפיע על מחלקות שתלויות במחלקה זו - שוב: Developer Scalability, תחזוקה קל היותר, ויכולת לבצע שינויים בצורה פשוטה יחסית (באזורים הפרטיים).
• ניהול תלויות (dependency management) - מגבלה שאומרת שמחלקת ה Document Parser רשאית לקרוא ל Paragraph Parse - אך לא להיפך. צמצמנו כך את התלויות עוד יותר.

אציין שבניהול תלויות המטרה היא לצמצם תלויות, לא רק "לנהל/לעקוב" אחריהן.

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

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

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

הכללים המגבילים, מציבים בפנינו שקלול-תמורות מסוים:

• פחות מדי מגבלות: כולם מדברים עם כולם במערכת - ונפגעת מאוד תכונת ה Development Scalability.
• יותר מדי מגבלות: מקשות על ה productivity של המפתחים.

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

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

Layered Architecture

דפוס השכבות הוא הדפוס הארכיטקטוני בשימוש הנרחב ביותר.
הוא נפוץ במיוחד במערכות מידע / Web Applications / Enterprise Applications (מבחינה ארכיטקטונית, הן בערך אותו הדבר) - והוא כנראה גם הדפוס השולט גם ב domains רבים אחרים. חשבו: כמה מקובל להציג ארכיטקטורה כקוביות בזו מעל זו, ומה צורה זו מתאר.
באופן לא מפתיע, עם הפופולריות מגיעה גם כמות יפה של חוזר-הבנה, ושימוש לא נכון.

כללי החלוקה של דפוס השכבות הוא כדלהלן:

• נפריד את מאגר המחלקות במערכת שלנו לכמה שכבות: שכבות עליונות לטיפול בעניינים ברמת הפשטה גבוהה, כאשר רמת ההפשטה יורדת ככל שיורדים בשכבות.
• לוגיקה בשכבה גבוהה (n) תהיה מורכבת מהפעלה של לוגיקות (או פונקציות) בשכבה שמתחתיה (n-1). כמו כן, לוגיקה בשכבה גבוהה (n) תעזור להרכיב את הפונקציות בשכבה הגבוהה ממנה (n+1).
• בד"כ השכבה הגבוהה ביותר היא זו שמתקשרת עם העולם החיצון: משתמש או מערכות אחרות.
• החלוקה של המחלקות לשכבות היא שלב אחד, ובד"כ יש חלוקות נוספות בתוך השכבה למודולים / תתי-מערכות (sub-systems). 
• בד"כ בכל שכבה יש תת-שכבת API (או "Facade") מנוהלת - בה, ורק בה השכבה העליונה יכולה להשתמש. לא נרצה שכל ה APIs שזמינים בתוך השכבה יהיו זמינים לשכבה מעל - אחרת, איזו משמעות יש להפרדה שהגדרנו?!

בהצצה לתוך השכבה הבודדת, המבנה עשוי להראות דומה למבנה הבא:

פרשנות נפוצה של מודל השכבות 

במערכות ווב, מערכות מידע, או Enterprise Systems יש מן מתכון מקובל של לחלוקה המערכת לשכבות.
אין לכם כח לקבוע רמות הפשטה שונות ושימושיות של המערכת? - השתמשו במתכון מוכן (מתכון של מתכון):

• UI - ממשק המשתמש
• Business Logic - הפונקציה העיקרית שהמערכת ממלאה (ניהול ספקים, רכש, מלאי, וכו')
• Data Access - בשכבה זו פעם היה הרבה קוד מתוחכם, אך היא הוחלפה חלקית ע"י מערכות ORM - ומה שנשאר בה הם האובייקטים של המערכת שמתארים את הנתונים (Entities, Collections, וכו').
• Persistency - שכבה זו מתייחסת לבסיס הנתונים (בהנחה שיש כזה, בד"כ רלציוני) - סקריפטים ליצירת הטבלאות (DDL) ולעתים גם קוד שרץ בתוך בסיס הנתונים (stored procedures) [ב].

לחלוקה זו יש וריאציות שונות (הוספת שכבת Service מעל ה Business Logic, או שכבת Presentation Logic מתחת ל UI, וכו') - אבל סה"כ היא מאוד מקובלת.

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

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

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

דפוס ארכיטקטוני שעשוי להתאים במקרים בהם כל פיצ'ר / פיתוח קטן נוגע בכל (או רוב) השכבות הוא דפוס ה microservices - שזוכה לפופולריות רבה לאחרונה. האם גם אותו אפשר "לפספס"? - כמובן!

אציין, שבמערכות Enterprise כדוגמת ERP של סאפ - יש ערך ממשי בחלוקה הנ"ך לשכבות: מערכות אלו מבוססות במידה רבה על מידול (modeling) של נתונים, ואז באמת יש פיתוחים ב Business Layer שלא צריכים לעדכן את ה UI (כי הוא נבנה מתוך מודל הנתונים שלא השתנה), ולא צריכים לעדכן כמעט את הטבלאות בבסיס הנתונים. שכבת ה Business Layer היא משמעותית ומשתנה תדיר - ויש ערך רב בהפרדה זו. כמו כן ניתן לשנות את ה UI (כיצד מרנדרים את המודל) - מבלי לשנות את שכבת ה Business Logic בכלל, וכו'.

עוד בעיה נפוצה היא פרשנות של המודל ע"פ פונקציה אותה ממלאת המחלקה / מודול ולא ע"פ רמת הפשטה, כך שלמשל, כל פעולת גישה לדיסק נכנסת לשכבת ה Persistence באופן אוטומטי - "כי דיסק הוא Persistence" ואף אחד לא שוקל מהי רמת ההפשטה של הפעולה. למשל: קריאה של קובץ מהדיסק ששקול ל Input מהמשתמש - נכון יותר, כנראה, שהיה בשכבת ה UI. זו אותה רמה הפשטה. שכבת ה Persistence הוגדרה מכיוון שיש הרבה מאוד פעולות דיסק שהם ברמה נמוכה - אך לא כולן הן כאלה.
התעלמות מהעיקרון של רמות ההפשטה השונות - גורם ל"פספוס" ביישום של מודל השכבות.

"הב לי עלים ירוקים..."

Model-View-Controller

בתיאוריה, MVC הוא דפוס נהדר לחלוקה של שכבת ה UI.
תאוריה בצד. בפועל: יש לו בעיה מהותית - שמונעת ממנו לעתים "להמריא".

דפוס MVC בא לחלק אפליקציית UI לחלקים מוגדרים היטב - ולהגדיר תלויות ביניהן.
המקור של MVC הוא ב framework של שפת Smalltalk-80 משנת 1980 בשם "Model-View-Controller Editor".

ה Framework הזה היה מיועד לאפליקציות command line (שיא ה UI באותה תקופה), והחלוקה הייתה בין:

• Model - הנתונים של האפליקציה / מבני נתונים
• View - תצוגת הפלט, מה לרשום על המסך
• Control - קבל ה Input מהמשתמש וטיפול בקלט הזה - בעצם ה Business Logic.

MVC "קלאסי" / "המקורי"

כל מחלקה (או פונקציה) נופלת באחד מהאזורים - וחייבת לציית לכליל הנראות. בת'כלס ה Controller רק יוצר את ה View ולא משתמש בו אח"כ, ושניהם מכירים את המודל. בין מחלקה של View למחלקה של Controller יש בד"כ קשר של 1:1 - והם מתארים "מסך" או "תפריט" באפליקציה.

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

אם כולם היו מכירים את MVC ומשתמשים בו באותו האופן - לדפוס זה היה ערך רב יותר. אולם, יש 2 בעיות:

• MVC המקורי לא כ"כ מתאים לאפליקציות Desktop, Web או כל מה שאינו command line.
• יש המון וריאציות של MVC: חלקן קיבלו שמות נבדלים (יחסית) כמו MVP, MVVM או PAC - אבל רוב הווריאציות פשוט משתמש בשם "MVC", תוך כדי ביצוע שינויים במודל "המקורי".

התוצאה המידית היא בלבול וחוסר תקשורת -  FUD. אם דיברנו על כך שדפוסים משמשים כשפה משותפת, אזי MVC משמש לרוב כאנטי-שפה-משותפת: מתכנת אחד אומר "Controller" והשני שומע "Kotroller" (כלומר: מה שהוא מכיר כ Controller). שני המתכנתים רבים כמה ימים, אולי שבועות - עד שהם מצליחים להסכים שבעצם השני לא אידיוט/מפגר/לא מבין - שניהם פשוט מכירים שתי וריאציות שונות של MVC.

בפועל, אוותר על הניסיון לתאר ולאפיין את כל הווריאציות התאורטיות של MVC (להזכיר: יש כאלו שהם Client-Side, כאלו שהם MVC צד שרת, כאלו שהם מערבים צד-לקוח וצד-שרת, וכאלו שמתאימים לאפליקציות Desktop או Native Mobile).

אני ממליץ לוותר על ההגדרות, ופשוט להיצמד לספרייה הרלוונטית שבה אתם משתמשים - והכללים שהיא מכתיבה: בסוף, התועלת העיקרית היא מכללים ברורים שכולם מצייתים להם - קצת פחות אם כלל מסוים מנוסח בווריאציה 2א' או בווריאציה 3ג'.

יש ספריות יש רבות הממשות (וריאציה של) דפוס זה: Struts, Play!, Grails, Ruby on Rails, Django, ASP.NET MVC , Angular.js, Backbone.js ועוד....

מבנה של MVC צד-לקוח מודרני טיפוסי אפשרי

העיקרון המשמעותי ביותר, והמוסכם ביותר בקרב ספריות "MVC" מודרניות הוא ההפרדה בין UI (כיצד משהו נראה על המסך) ל Presentation Logic (כיצד להחליט מה יש להציג על המסך). למשל (דוגמה סופר-פשוטה):

במקום לקבוע כלל ש:

• אדם עם +500 חברים מקבל icon מיוחד.

מחלקים את המימוש ל2 אזורים:

• Presentation Logic - אדם עם 500+ מתויג כ "אדם פופולרי במיוחד" (What)
• UI - אדם המתויג כ "אדם פופולרי במיוחד" מקבל icon מיוחד.

הפרדה זו יוצרת מעט overhead על הפיתוח, אך היא מאפשרת להחליף את ה presentation (כלומר: אלמנטים ב UI / כל ה UI) בצורה קלה יחסית, מבלי "לאבד" או לשנות את ה Presentation Logic שהוא יותר יציב, או לחלופין להוסיף presentation נוסף (נאמר: mobile version), מבלי לשכפל את הקוד לגמרי.

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

סיכום

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

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


שיהיה בהצלחה!




---

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

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

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

Stored Procedures הם דוגמה מצוינת ליכולת שכזו, שכמעט תמיד משתמשים בה בצורה שסותרת בצורה בוטה את העקרונות של מודל השכבות: לוגיקה עסקית (רמת הפשטה גבוהה) מנוהלת בתוך בסיס הנתונים (שכבת הפשטה הכי נמוכה) - ויוצרת תלות קשה בתחזוקה, ביכולת להחליף מימוש של שכבות, וכו'.


---


לינקים מעניינים

הדוד בוב בביקורת עוקצנית על MVC (וידאו): "MVC is not an Architecture"

OpenStack - ענן בקוד פתוח, חלק ב'

בפוסט זה נדבר על שירותי OpenStack (בקיצור: OSK) שאינם שירותי ליבה. בכל זאת - חלקם מאוד שימושיים!

את השירותים אחלק ל-2 קבוצות:

• שירותי אחסון (Swift, Cinder ו Trove)
• שירותים אחרים (Heat ו Ceilometer)

הקשרים בין השירותים השונים של OpenStack

שירותי האחסון (Storage)

כשירות בסיסי, OpenStack מספק 3 צורות אכסון:

• Ephemeral (קצר-טווח, מיושם ע"י Cinder) 
• Block (מיושם ע"י Cinder)
• Object (מיושם ע"י Swift)

להזכיר: Cinder הוא המקביל ל (EBS (Elastic Block Storage של אמזון, ו Swift הוא המקביל של S3.

שירות נוסף שכללי בקטגוריה הוא שירות Trove שהוא בעצם רק storage-related: הוא אחראי על provisioning אוטומטי של instances של בסיסי-נתונים.

Block Storage (שם קוד: Cinder)

משמעות השם Cinder הוא גחלת - פחם שחדל לבעור, אך הוא עדיין חם.

Cinder הוא שירות הפשטה וניהול של Backends של אחסון. בצד אחד הוא מנהל מערכות אחסון נתונים קיימות (כמו netapp או EMC) ומצד שני הוא חושף API של הקצאת שטח אחסון (מופיע כדיסק SCSI) ל VM שרץ על נובה.

ה Ephemeral Storage מוקצה למכונה כ"דיסק מקומי" וזמני. ברגע שה VM "יורד", התוכן שנשמר בבלוק שהוקצה - יימחק.

ה Block Storage גם הוא מוקצה ל VM ספציפי, אולם אם נותק מה VM - הנתונים שעליו עדיין יישמרו. עליו נשמור את הנתונים הייחודיים / בעלי המשמעות במכונה. בדומה ל EBS, ניתן בכל שלב ליצור snapshot של הבלוק, עבור גיבוי או שכפול.

מדוע הוא שימושי?

נניח אנו רוצים לעבור ממכונה m1.small למכונה גדולה יותר m1.large, או בין תמונת-דיסק ("Image") של Padora ל RHEL (הפצות שונות של לינוקס). ברגע שאנו משתמשים ב Block Storage אנו יכולים לנתק אותו מ VM אחד - ולהקצות אותו מיד ל VM חדש, מבלי לבצע העתקה ארוכה. יש בעיות עם RHEL? נקים מחדש VM של Padora ונחזיר אליו את ה Storage.

לסינדר יש דרייברים לספקי אחסון שונים (פתרונות NAS או SAN) התומכים בפיצר'ים השונים, עבור גרסאות שונות של OSK). ניתן למצוא כאן את טבלת הדרייברים הזמינים והיכולות הנתמכות.
ניתן להשתמש במקביל בכמה Storage Backends.

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

Object Storage (שם קוד: Swift)

בעוד Cinder הוא יחסית פשוט (הוא בעיקר מנהל מערכות Storage חיצוניות), שירות Swift הוא מורכב יותר. לפעמים מריצים את Swift כשירות עצמאי, ללא שימוש ב Stack המלא של OpenStack.
Swift היא הטכנולוגיה מאחורי שירות ה cloud-files, של Rackspace.

Swift היא מערכת מבוזרת, fault-tolerant, אלסטית, ו eventually consistent לאכסון אובייקטים. מלבד העובדה שגודל האובייקטים הוא עד 5GB (ניתן לקונפיגורציה) - היא דיי דומה לכמה בסיסי-נתונים NoSQL מסוג K/V מוכרים.

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

כל התקשורת מול הצרכנים של סוויפט נעשית דרך שרת(י) ה Proxy של סוויפט, בעזרת REST-ful APIs (כלומר: על גבי HTTP). ניתן לחבר ל Proxy שירות Caching (בד"כ Memcached) לטיפול מיידי בבקשות הנפוצות ביותר.

סוויפט הוא multi-tenant בצורה מובנה, וכל tenant מקבל הפרדה מגישה של tenants אחרים. מלבד יכולת (יחסית ייחודית?) של multi-tenancy, סוויפט גם נחשב קל / יעיל מאוד לניהול.

לפזר מידע על דיסקים, דרך RESTful API זה לא דבר כ"כ מורכב. החלק המורכב באמת בסוויפט הוא גילוי והתאוששות מתקלות (בעיות consistency, תקלות חומרה וכו').

סוויפט מחזיק כמה סוגי של שרתי (או תהליכי) consistency לצורך זה:

• Auditors רצים ברקע על כל שרת של סוויפט וסורקים את הדיסקים לוודא את תקינות המידע עליהם. אם יש תקלות - הקובץ מועבר ל quarantine area, ועותק "בריא" של הקובץ (זוכרים? יש יתירות) - מועתק במקומו.
• Updaters מוודאים שה metadata על הקבצים הוא נכון ועקבי. הם גם מנהלים counters על כמות האכסון, ומספר האובייקטים, וכו' ברמות הניהול השונות. בגדול, סוופיט מגדיר accounts (שהם ה tenants), בתוכם ניתן להגדיר containers (כמו תקיות) ובתוכם מנהלים את האובייקטים.
• Replicators מוודאים שיש מספיק יתירות של קבצים במערכת. מספיק? ע"פ הגדרות SLA - כמובן. שמירת היתירות היא משימה עקבית, כי מדי-פעם קבצים מתגלים כשגויים או שסתם שרתים "נופלים".

על סוויפט לבדו, ניתן לכתוב ספר שלם. בעצם... כבר כתבו (ועוד אחד, ועוד אחד)

DBaaS (שם קוד: Trove)

כפי שציינתי, שירות Trove ("אוצר בלום") הוא לא שירות אחסון, אלא שירות הקשור לאחסון. הוא אמור לפשט את המשימה של התקנה של בסיס נתונים. יש המתארים אותו כ "Database as a Service".

מדוע בסיס נתונים הוא שונה מכל VM אחר? הרי ניתן בעזרת נובה ל"הרים" VM עם תמונת-דיסק מוכנה בזמן קצר מאוד - ועליה יכול להיות בסיס נתונים.

מייד אפרט את היתרונות שיש בשירות כמו Trove, אולם הסיבה שאלו דווקא בסיסי נתונים כנראה נעוצה בכך שבסיסי נתונים הם נפוצים מאוד. באותה המידה היה הגיוני לעשות שירות דומה ל Applications Servers. אולי... במידה, זה מה ש PaaS עושה. אז מה Trove מסייע לנו לעשות ב instance של בסיס הנתונים שהוקם?

• ניהול משתמשים בבסיס הנתונים / ניהול הרשאות על אובייקטים בצורה מרכזית.
• Backup / Restore מנוהל בקנה מידה גדול, או Patching.
• ניהול Quota.
• Vertical Scalability פשוט לניהול: שינוי גודל הזיכרון / כח מחשוב / דיסק - ע"פ ה workload באותו הרגע.
• ניטור מצרפי ו diagnostics.

ניתן למצוא היום את Trove בכמה מוצרים בפרודקשן:

• Cloud Databases של Rackspace
• HP DBaaS
• eBay (שימוש פנימי)

כרגע Trove תומך רק ב MySQL ותואמים שלו (MariaDB, Percona), אולם יש תוכניות קונקרטיות לתמוך ב MongoDb, Cassandra, Redis, CouchBase ועוד, וכן לתמוך בקונפיגורציות High Availability של MySQL. יש להזכיר שהוא רק שוחרר בגרסת (IceHouse (2014 - ויש לו עוד הרבה לאן להתפתח.

מקור: Mirantis

שירותים אחרים

OpenStack Orchestration (שם קוד: Heat)

Heat הוא הגרסה של OSK ל CloudFormation של אמזון.
שירות זה דומה במטרתו לשירות תמונות-הדיסק (שם קוד: Glance), אך הרזולוציה שבה הוא עובד היא של landscapes שלמים.
ה landscape הרצוי מתואר בקובץ בפורמט HOT (קיצור של Heat Orchestration Template. נקרא גם בקיצור Template), קובץ שהוא human readable, ושניתן לערוך ידנית.

הנה דוגמה של קובץ HOT בסיסי ביותר, המבקש שירות של nova להרצת image מסוים על מכונה קטנה:

heat_template_version: 2013-05-23

description: Simple template to deploy a single compute instance

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      key_name: my_key
      image: F18-x86_64-cfntools
      flavor: m1.small

בעוד Glance מדבר ברזולוציה של תמונת-דיסק, Heat מקשר אותה גם לחומרה, רשת, הגדרות משתמשים וקונפיגורציה. בקובץ ה HOT ניתן להשאיר משתנים חסרים - שאותם יתבקש המשתמש למלא בזמן שהוא מבקש הקמה של Landscape ע"י התבנית המדוברת, בכדי להפריד בין הגדרת ה HOT file, לבין הפעלה שלו בוריאציות שונות.

OpenStack Monitoring & Billing (שם קוד: Ceilometer)

ה Ceilometer הוא מכשיר שמודד בעזרת לייזר את גובה העננים (לצורך חזאות). אני מניח שמקור השם משרבב בתוכו את המילה Ceiling (תקרה).
שירות זה הוא מעט יותר SaaS-י באופיו: הוא אוסף את נתוני השימוש של לקוחות (פנימיים או חיצוניים) במשאבי הענן לצורך חיוב. את מידע ה billing ניתן להזין למערכות חיצוניות (למשל: מערכות ERP).

אפילו במקרה של ענן פרטי פנים ארגוני, יש הרבה היגיון ומוטיבציה לחייב את הגופים השונים (שיווק, מכירות, כח-אדם) ע"פ מידת השימוש שלהם במשאבים. Ceilometer מתחבר לשירותים האחרים של OSK שיש להם משמעות של שימוש במשאבים (למשל: נובה או Cinder), ואוסף מהם את נתוני שימוש.

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

שימוש חשוב של Celiometer ו Heat ביחד הוא Auto-Scaling:

• Ceilometer עוקב אחרי ה nodes השונים ומזהה את עומס העבודה שלהם.
• ברגע שיש treshhold מסוים של שימוש - הוא מדווח על כך ל Heat.
• ב HOT file של HEAT יש הוראות כיצד לבצע up/down scaling - ו HEAT פועל ע"פ ההנחיות בכדי להפעיל / לכבות VMs ולהתאים את השירותים הרצים ל Scale הנדרש.

סיכום + הקשר ה PaaS-י

סקרנו את השירותים הזמינים ב OpenStack - שזו דרך טובה להבין מה OSK יכול לספק, וכיצד.
אפשר לציין כמה מהשירותים העתידיים שכרגע נמצאים באינקובציה (Incubation projects):

• Designate - שירותי DNS (כלומר: Domain Name Server)
• Marconi - שירותי Message Queuing
• Barbican - שירותי Secure Storage
• Sahara - שירותי Data Processing / Big Data מעל Hadoop
• Mistral - שירותי תזמון משימות / Workflows

אתם בוודאי יכולים לזהות דפוס דיי ברור:

מלבד Designate (וביחד עם Trove ואולי גם Ceilometer) - אלו הם בעיקרון שירותים שמתאימים יותר להגדרה של PaaS מאשר IaaS.

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

יכולת מרכזית שחסרה בתמונה, שבלעדיה OpenStack לא יחשב כ PaaS היא הרזולוציה של ה deployment וניהול ה "Compute": הרזולוציה היא עדיין של VM ולא של אפליקציה.

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

כרגע הפרויקטים (Solum הוא המשמעותי בין השניים) הם בשלבים ראשוניים, ולא נחשבים לשחקנים חשובים בעולם ה PaaS. מי שרוצה PaaS על גבי OSK משתמש לרוב ב OpenShift או CloudFoundry.

בכל זאת, כאשר משתמשים בפתרונות כמו CloudFoundry או OpenShift יש כפילויות פונקציונלית בין המערכות: 

• Authentication
• DNS & Messaging (בקרוב)
• Load Balancing
• Dashboard & Monitoring
• וכו'

כפילות זו ברורה לכל משתמש עסקי.

מצד שני, בעת הפיתוח של Solum, קהילת OSK לא מוכנה לקבל ב Solum כפילויות מול פונקציונליות שקיימת כבר (+ באינקובציה) ב OSK. להישאר DRY (קרי: Don't Repeat Yourself).
Solum מקבל המון מ OSK, אבל הוא גם נאלץ להשתמש בשירותים שיועדו להיות אופטימליים ל IaaS ולא ל PaaS - וכנראה שלא תמיד כ"כ מתאימים.

שיקול זה כנראה מובן בעיקר למפתחים ותיקים ושבעי-קרבות.

מה יהיה?
כבר כמה אלפי שנים שאין נביאים בארץ ישראל. נחכה ונראה.


שיהיה בהצלחה!

-----

לינקים מעניינים:

"CloudFoundry ו OpenStack - זיווג מגן-עדן"
"OpenShift ו OpenStack - זיווג מהעננים"

מה עדיף?! עננים או גן-עדן?