מה זה Desired State Repository וכיצד תוכלו לפתח את הפתרון בעצמכם

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

אינטגרציה בין שירותים שונים ויכולות התממשקות קלה למערכות תוכנה חדשות (צילום: Dreamstime)

מאת אלכס וולצ'וק, ארכיטקט תוכנה צוותי; ודניאל מנטל, ארכיטקט תוכנה צוותי

הקונספט של Desire State Repository אינו חדש, אך גם אינו מוכר מאוד. מדובר בפיתוח שמאפשר שימוש ב-APIs בצורה אחידה ומרוכזת, ומפשט את הפעלת שירותים ייעודים (Micro-Services), שנועדו לשרת בקשות שונות של משתמשים שונים. אחד העקרונות החשובים של הקונספט הוא פרדיגמה הצהרתית (Declarative Programming), שבה המשתמש מצהיר מהו המצב הרצוי עבורו וספקי השירותים השונים פועלים להשגתו.

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

למה כדאי לעבוד בשיטת Desire State Repository?

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

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

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

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

לדוגמה, מפתח רוצה לפתח שירות שיידע לעשות את הדברים הבאים:
1. ליצור חשבון משתמש חדש
2. ליצור משתמש ראשוני לחשבון
3. לספק שירות A עבור החשבון
4. לספק שירות B עבור החשבון
5. לעדכן את החשבון עם השירותים שסופקו לו.

דוגמת מימוש בצורות העבודה הקיימות (Imperative):

דוגמת מימוש בעבודה הצהרתית (Declarative):

 

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

כך פיתחנו את הפתרון בעצמנו

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

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

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

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

2. האתגר הקונספטואלי: כשהחלטנו לצאת לדרך של פיתוח פתרון Desire State Repository, השלב הראשון היה לתת API contract שיהיה יציב וישקף את היכולות של קוברנטיס. היה חשוב ללמד את הצוותים הראשונים לעבוד עם התפיסה הזו. לכן בשלב הזה הצוותים הראשונים למדו לעבוד עם הפתרון של קוברנטיס, בזמן שאנחנו פיתחנו פתרון דומה שעונה על הצרכים שלנו.

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

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

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

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

  • ניהול מערכת ההרשאות: הפתרון של קוברנטיס מגיע עם מערכת הרשאות מאוד מגוונת. היינו צריכים לפתח מערכת שמאפשרת לנהל הרשאות ותפקידים בצורה דקלרטיבית, ועושה זאת באופן מהיר יחסית. לכן פיתחנו את השכבה הזו כתוספת, כדי שהמערכת תדע לעבוד עם יוזרים שונים ומגוונים ולתת יכולות של התראות ועוד. פיתחנו את הפתרון שלנו לניהול הרשאות מעל התשתית לניהול חוקים והרשאות שנקראת Open Policy Agent (OPA) open source.
  • אתגר ההיקף: היינו חייבים לפתח פתרון שיוכל להתמודד עם היקף עבודה גדול משמעותית מהפתרון שמספק קוברנטיס – כזה שיוכל לספק מענה למיליוני פעולות. כשהתחלנו את תהליך הפיתוח בחרנו לעבוד עם מסד הנתונים Postgres, אבל כשהגענו לאתגר ההיקף היינו צריכים פתרון שונה. התחקיר שעשינו הוביל אותנו למסקנה שיהיה נכון עבורנו לעבור לשירות האחסון Amazon S3, שמאפשר לשמור מסמכים בכמות אדירה.

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

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

הכתבה בחסות SAP

מרכז הפיתוח של SAP בישראל הוא בין המרכזים החדשניים, האסטרטגיים והמובילים של ענקית התוכנה העולמית, עם כ-800 עובדים בשני אתרים - רעננה ות"א. קבוצות הפיתוח בישראל מתמחות ומובילות את עולמות ה- MultiCloud ופלטפורמת הענן של החברה, את תחום ניהול זהויות משתמש, פרטיות משתמשים, פרסונליזציה וחווית משתמש. קבוצות הפיתוח בישראל אחראיות על מוצרים מרכזיים המשמשים את המותגים הגדולים ומוכרים בעולם, ועוסקות בטכנולוגיות המתקדמות ביותר תוך התמחות ב- Cloud Native Architecture, deep learning ו-computer vision ועוד. מרכז הפיתוח בישראל מדורג בצמרת החברות שהכי טוב לעבוד בהן, ומקדם עשייה חברתית וקהילתית ענפה.

כתב אורח

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

הגב

2 תגובות על "מה זה Desired State Repository וכיצד תוכלו לפתח את הפתרון בעצמכם"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
KEY
Guest
אלכס הגישה שלך כל כך מתודולוגית, מעבר לזה שזו דוגמה נהדרת להובלת צוות שעוסק ביזמות מונחת פתרון בעיות לעומת הובלת צוות של כיבוי שריפות לבעיות קיימות. אלכס תבקש מהעורך להוסיף דוגמה לטבלה של POSTGRES ואיך ניתן לשחזר(לפתרון) אחורה טעות שהמשתמש האחרון ביצע כדי לחזור לגרסה המוקדמת טרום אותה טעות. האם לא כדאי לייצר בעדכון האחרון מסגרת גידור של מקבץ עד 3 עדכונים אחורה ובתוכה להכניס גורם בודקמפקח כדי לייעל תהליך ולעלות על הטעות בזמן סמוך לגילוי הטעות? לטווח קצר זה יאריך את העבודה אך לטווח הארוך זה ייעל את התהליך. אין ספק שגיק טיים נותנים פה טעימה מקצועית של כתבות… Read more »
Max
Guest

Sounds like monolith with extra steps…
Event driver/sourcing would solve the problem wothout coupling the solution to a single point of failure

wpDiscuz

תגיות לכתבה: