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

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

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

האתגרים מההיבט החומרתי

נקודות הדורשות זמן וכוח אדם מיומן

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

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

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

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

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

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

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

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

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

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

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

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

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

· הגדרת החומרה ((Configuration — לאחר התקנת החומרה יש צורך להגדיר את ההגדרות שלה, רצוי לא להשתמש בהגדרות ברירת המחדל של החומרה, אלא להגדיר את החומרה לצרכים של המוצר.

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

דרכים להתמודד עם האתגרים:

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

· פיתוח ושימוש בשפת פיתוח אגנוסטית לחומרה– במידה ואנו בוחרים בשפת תכנת שקוד המקור שלה יכול לרוץ על חומרות שונות מבלי צורך לשנות את קוד המקור, זה יעזור להתגבר על בעיית תאימות של המערכת שלנו לחומרה חדשה. שפה כמו JAVA לדוגמא אין צורך לשנות את קוד המקור במידה ונצטרך להריץ את התוכנה על בארכיטקטורתX86 או x64. גם שפת GO מאפשרת להריץ את אותו קוד מקור על ארכיטקטורות חומרה שונות. (יש לציין שJAVA אומנם אגנוסטית לארכיטקטורת החומרה אך במידה ולא כתבנו קוד בצורה נכונה, יכול להיות שהקוד לא יעבוד תקין על Linux OS במידה ובקוד המקור שנכתב בWindows כתבנו למשל את נתיב הקובץ בצורה שמערכת ההפעלה וינדוס עובדות ולא כמו שמערכת ההפעלה לינוקס עובדת,במקום להשתמש ב- “ File.separator” השתמשנו ב “\\” ולכן קוד זה לא יעבוד על מערכת לינוקס מכיוון שנתיב מפריד בין ספריות הוא “/” .

· כתיבת מערכת מכוונת תהליכים Microservices — במידה ויש לנו אפשרות לתכנן או להסב מערכת קיימת לארכיטקטורת Microservices זה יכול לתת פתרון, ארכיטקטורה זו תומכת בגדילה אופקית (Horizontal scale) דבר המתמודד עם בעיית הגדילה האנכית (Vertical scale) שבה קיימת תקורה של גדילה אשר מתבססת על הגדלת משאבים על שרת בודד זה שראינו שיש לו מגבלות ועליות גבוהות, לעומת גדילה אופקית שעלות הגדילה היא לינארית.

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

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

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

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

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

מאת: ניר מקמל, ארכיטקט תוכנה למערכות מבוזרות מתקדמות. |