תהליך המודרניזציה לענן הציבורי- חלק שלישי — ההיבט התוכנתי.

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

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

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

האתגרים מההיבט התוכנתי:

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

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

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

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

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

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

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

נקודות כשל קריטיות

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

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

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

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

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

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

דרכי ההתמודדות עם האתגרים — פחות מורכבות

שיפור אלגוריתם בקוד — אנו יכולים להריץ כלי פרופילר (profiler) שמבצעים ניתוח של ניצול משאבי המעבד והזיכרון ובעזרתם נוכל לאתר שורות או שיטות (methods) בקוד שאפשר לשפר שם את האלגוריתם כך שיהיה יותר יעיל. ניקח מקרה לדוגמא: נניח יש לנו שיטה שמבצעת חישוב ויש בה שני לולאות מקוננות אזי הסיבוכיות תהיה O(n²) בכלי הפרופילר נוכל לזהות את השיטה הנ”ל ולנסות לשפר את האלגוריתם שיעבוד בסיבוכיות נמוכה יותר מאשר O(n²).

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

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

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

שימוש במודול צד שלישי (3th party module) — במידה ויש לנו אלגוריתם שדורש עיבוד מורכב וניתן להשתמש במערכת צד שלישי שהמערכת שלנו תוכל להכיל, ובכך נחסוך משאבים של זמן וכסף כאשר נדרשים אנשים מומחים כדי לכתוב את המודול.

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

שימוש ב — CI CD- ברגע שיש לנו מנגנון אינטגרציה והתקנה אוטומטי אנו נוכל לשמור על רמת קוד גבוהה ואיתור תקלות לפני שהן מגיעות לסביבת הלקוח.

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

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

דרכי ההתמודדות עם האתגרים — דרכים מורכבות יותר לביצוע

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

שימוש בתבניות עיצוב Design patterns — ע”י שימוש בתבניות עיצוב אנו יכולים להתגבר על אתגרים שעולים כתוצאה משינוי או תוספת של קוד חדש, אם נשתמש בפתרון מוכר וידוע כגון מתאם (Adapter) , מפעל אבסטרקטי (Abstract Factory), סינגלטון וכו’ נוכל להתמודד עם האתגרים בצורה טובה תוך שמירה על איכות הקוד ומערכת גמישה לשינויים.

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

תשתיות וביצוע בדיקות לקוד החדש, כמובן שיש לזה מחיר גבוה בכדי להגיע לרמת קוד ייצור.

לסיכום

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