ארכיטקטורת מיקרו שירותים – יתרונות ברורים ושאלות שצריך לשאול

"אם היינו עושים עכשיו איזה שהוא סקר דמיוני, ובמסגרתו מבשרים לכם שהארגון שלכם עומד לעבור הסבה לטכנולוגיית מיקרו שרתים, מה הייתם עונים שאתם צריכים לעשות כדי לממש את זה? האם זה אומר, לדוגמה, שמעכשיו עוברים לעבוד רק עם בסיסי נתונים שהם NoSQL וזהו? האם הייתם חושבים, למשל, על הדרכים לשתף מידע בין המיקרו שירותים הללו? לארכיטקטורה של מיקרו שירותים יש הרבה מאוד יתרונות, כמו זמני הפיתוח הקצרים מאוד באופן יחסי, אבל יש גם הרבה שאלות שצריך לשאול מסביב, במיוחד בהיבט של בסיסי נתונים", כך אמרה ליאת סבג, מומחית ניהול מידע ופתרונות ענן באורקל ישראל השבוע (ב') בכנס Hybrid Cloud & Kubernetes.

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

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

ביחד או לחוד, ואיך מתמודדים?

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

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

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

שכבת קונטיינר מרכזית

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

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

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

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