איך אפשר להתמודד עם ה-Legacy ועדיין לאמץ קוד פתוח?
האם המורשת היא מה שדופק לנו את המחשוב? ואם כן - איך אפשר להילחם בזה בלי לחטוף עונש מלמעלה? יש גישה טכנולוגית חדשה, שאמורה לעשות סדר בבלגן
אחת הבעיות הקשות ביותר בתחום המחשוב האירגוני היא בעיית המורשת. לא מדובר בגרסה העסקית להדתה או בזיכרון אירגוני, אלא בבעיית ה-Legacy. כמעט בכל ארגון בינוני או גדול צוברים מערכות מהזן הזה. אותה מערכת תפעולית שעובדת על קובול, או הסוויץ' הזה של סיסקו (Cisco), שקנו אי שם בעשור הקודם, האחסון שעבר זמנו… ובכן, הבנתם את התמונה.
בימינו, יש צורך להשתדרג, להתקדם, להיות גמישים, לאמץ את הקדמה. אבל איך? שואל את עצמו המנמ"ר הממוצע. איך אני אמור להתקדם עם משקולת 10 טון של Legacy על הגב שלי? איך אני אמור לרוץ קדימה ולהתקין מערכות חדשות ותוכנות מבריקות, שיאפשרו אג'יליות, סקלביליות, Mission critical ועוד סדרה של מילים בלועזית, שפרנסי השפה העברית התייאשו מלמצוא להן מונחים מקבילים?
ובכן, כאן טמונה ההזדמנות. כדי להתחיל להתקדם לכיוון פתרון של הבעיה הזו יש צורך בגישה חדשה – כזו שתיקח בחשבון לא רק את הטכנולוגיה החדשה ביותר, אלא גם את זו הוותיקה. לא רק את החומרה העדכנית אלא גם את העובדה שאותה חומרה צריכה לדבר עם מגוון מכשירים של סדרה של ספקים שונים, שאיש לא חלם שייאלצו לדבר האחד עם השני.
הבעיה הזו לא קיימת רק בתוכנות סגורות, פרופרייטרי בלעז. גם בתוכנות קוד פתוח יש בעיה דומה. קחו לדוגמה את Open Stack – מערכת ההפעלה המתקדמת בעולם לענני מחשוב פרטיים. על פניו, היא נשמעת מעולה – קוד פתוח, סטנדרטים, עם סדרה ארוכה של יכולות שלענן ציבורי, פשוט, אין. אך כאן מתחילות הבעיות – מכיוון שכל חברה שעוסקת בתחום לוקחת את בסיס ה-Open Stack ומפתחת עליו ממשקים, שינויים ושיפורים שנועדו לצרכים המסחריים שלה. זה אמנם לא רע לכשלעצמו, אבל נוצר כאן Open Stack שונה לכל חברה וחברה – תצורה שונה, ממשקים שונים והעיקר, המון שעות שנדרשות כדי להתאים אותו למערכות שעובדות בארגון.
דרושה מערכת הפעלה שתדע "לאכול" את הספקים השונים
בפועל, נדרשת גישה אחרת, גישה פתוחה של של קוד פתוח -. An open-open source approach. כלומר, מערכת הפעלה שתדע "לאכול" את הספקים השונים, כזו שתוכל לעבוד עם כל מערכות הווירטואליזציה ולהתממשק לכל מערכי האחסון. כזו שתוכל להפעיל באופן שווה, סטנדרטי לחלוטין, את כל מה שרץ בשוק – בין אם אלה ראוטרים, סוויצ'ים, מערכי אחסון, עננים וכדומה. כי כאשר זו התפיסה, לא משנה אם מדובר בערכת שבבי x86 של אינטל (Intel), ארכיטקטורות מבוססות ARM או Power של יבמ (IBM) – מערכת ההפעלה תוכל לטפל בכל ולאפשר למכשירים השונים לפעול במשותף.
אבל הבעיה לא מסתיימת כאן, כי הגישה הזו חייבת לקחת בחשבון ממד נוסף – השירות. כל מנמ"ר יודע שאם מערך האחסון שלו איבד את עצמו לדעת, יש אפשרות סבירה שמישהו יבוא ויגיד: "אבל עשיתם כאן שימוש בתוכנת הפעלה אחרת ודפקתם את החומרה". או אז, אנחנו בבעיה אמיתית. לכן, כאשר נוקטים בגישה הזו, צריך לפעול לטובת המעטפת, להביא את האישורים הדרושים מספקי החומרה, לבצע בדיקות תאימות ולהניח על השולחן מוצר, מערכת הפעלה, שבא עם שיתוף הפעולה של הספקים. במקרה שכזה, אם יש צורך לדרוש שירות מהספק, איש לא יוכל להגיד שהתוכנה הזו היא שיצרה את הבעיה ולהתנער מהסכם השירות.
בשבוע הבא תציג Suse בפראג את גישת ה-Open-open source, על כל נדבכיה, מתוך כוונה לתת קריאת כיוון לשוק. קריאת כיוון שמשמעותה יותר סטנדרטיזציה, יותר שיתוף פעולה, ותיצוק משמעות אמיתית למושג החבוט של גמישות.
הכותב הוא מנהל ב-Suse ישראל.
מערכת אנשים ומחשבים תדווח מהכנס.
תגובות
(0)