חברת Solidworks מפסיקה לתמוך ב- WinXP

בקושי שמנו לב אבל התמיכה הרשמית של מיקרוסופוט ל- WindowsXP הסתיימה ב- 14 לאפריל 2009. הארגונים ממשיכים להשתמש ב- WindowsXP ורק מתחילים לשקול מעבר ל- Windows7. יש לקוחות שנמצאים עדיין ב- Windows 2000...
אולם מסתבר שחלק מיצרני התוכנה כבר נערכים לכך. בהודעה של Solidworks - תוכנה מובילה בתחום של CAD - עולה בעקבות הספקת התמיכה של מיקרוסופט ב- WindowsXP, הרי שגם Solidworks מפסיקה לתמוך ב- WindowsXP בנושאים שקשורים למערכת הפעלה. כלומר רשמית התמיכה הכוללת נפסקת. מתוך האתר:

Windows XP Retirement Announcement

Microsoft officially retired Windows® XP operating system in April of 2009. SolidWorks 2010 will continue to support Windows XP (32 and 64 bit versions) excluding operating systems related issues or fixes. This level of support will continue through at least one release following SolidWorks 2010. After that, in conjunction with Microsoft’s support policies, only Windows Vista® and Windows 7 (32 and 64 bit versions) operating systems will be supported. The SolidWorks operating system support plan outlined above will also apply to the SolidWorks Simulation and SolidWorks Enterprise PDM product lines.

המשמעות היא שאפשר יהיה להשתמש ב- WindowsXP אבל עם סיכון מסויים. ארגונים רבים אשר משתמשים בתוכנה זו הנם שונאי סיכון- מדובר ב"עבודה יקרה" של מהנדסים רבים ולכן ארגונים אלו כבר שוקלים לעבור ל- Windows7 כבר כעת.

עדכון SOA

רבות כבר נכתב על ארכיטקטורה חשובה זו. עם זאת דומה שאין תמימות דעים לגבי מימוש SOA בפועל. בפוסט זה נתייחס לפירושים הרבים למונח "מימוש SOA" תוך הסתכלות על מידת המימוש בפרספרטיבה של זמן. בעקבות פרסום הפוסט המקורי קיבלתי תגובות מלקוחות המעדנות יותר את מדרג השימוש ב- SOA . אני מפרסם כעת את המדרג המעודכן.
1. סביבת קישוריות מרכזית- ESB (בעבר EAI) כל המערכות מדברות האחת לשנייה כולל רמה של web services דרך תשתית זו. זאת שיטת עבודה מקובלת אצל רוב הארגונים. התשתית מבצעת ניתוב, אבטחת מידע , LOGS, ואפילו לוגיקה בסיסית.
2. שימוש בכלי BPM (חלק מ- SOA) לביצוע משימה ספציפית – במקום קידוד בסביבת פיתוח רגילה. הדבר מתאים במיוחד כאשר המשימה הנה תהליך עסקי המערב אפליקציות קיימות הקיימות בטכנולוגיות שונות, צורות גישה מגוונות (גם GUI גם MAIL גם SMS גם קשר בין אפליקציות) וגם התהליך העסקי משתנה בצורה תדירה. ישנו ניסיון מסוים בשימוש בתחום זה בישראל.
3. כמו הפירוש הראשון אך קיים גם גורם אשר מרכז את הכנסת כל הממשקים\שירותים ומציע את לגופי פיתוח להשתמש בממשקים\שירותים קיימים. זהו שיפור חשוב שמחייב הכנסת כלי soa governance. גופי הפיתוח יכולים להשתמש בשירותים קיימים אך אינם חייבים.
4. המדרג החדש שהוספתי - כמו הפירוש הקודם אך אותו גורם מרכזי שמכניס את השירותים ל- ESB\SOA יכול לאשר או לבטל הכנסה של ממשק\שירות ולהכריח את הגורם הדורש להשתמש בממשק\שירות שכבר קיים (כלומר גורם זה לא רק מציע אלא גם מחייב).
5. הדרגה הגבוהה ביותר של SOA היא שישנה הסתכלות כוללנית על תהליך הפיתוח בארגון. כל משימת פיתוח מוצבת בפני גוף ארכיטקטים המחליט מי מבצע איזה חלק, האם להשתמש בשירותים שכבר קיימים, האם להשתמש בטכנולוגיה של BPM או בטכנולוגיית פיתוח סטנדרטית וכד'. כלומר גוף הארכיטקטים לא מסתכל רק על הממשקים\שירותים "חיצוניים" שאפליקציה צריכה אלא גם מה קורה "בתוך" האפליקציה. מימוש זה מחייב שינוי מהותי בתהליכי הפיתוח של רוב הארגונים. זאת מכיוון שברוב ארגונים לכל גוף עסקי יש גוף ב- IT שממחשב אותו. פחות או יותר בצורה אוטונומית – ללא הסתכלות כוללנית ומשותפת על כל האפליקציות בארגון.

מבחינת מידע מהשטח, רוב הפידבקים שאנחנו מקבלים עוסקים ברמת המימוש הראשונית – חיבור של כל האפליקציות דרך תשתית מרכזית. לקוחות מדברים על כך שייצוב התשתית אורך זמן וגם שלא פשוט "לחנך" את המפתחים להשתמש בתשתית זו למול point to point. דבר נוסף בעייתי הוא נושא השליטה והבקרה. אין לעלות לאוויר ללא תשתית שליטה ובקרה מתאימה בין אם מפותחת בארגון או מוצר מהתחום של Run Time SOA Governence (כמו Amberpoint או DataPower). יש לציין שרוב הלקוחות מתייחסים לתשתית הקישוריות הארגונית כדבר הכרחי.
לגבי המדרגים הבאים יש פחות ניסיון כאשר מה שמעכב את התהליך הוא הצורך בשינוי ארגוני אך מצד שני ישנו פוטנציאל רב הן בחסכון כי מפתחים רק פעם אחת והן (יותר חשוב) באפשרות לענות על הדרישות העסקיות בצורה מהירה יותר. פידבק נוסף הוא שניהול הפרויקטים בצורה זו מורכב הרבה יותר.
זאת בקצרה. אני ממליץ גם לקרוא בבלוג של אבי רוזנטל שמכסה תחום זה בצורה מעמיקה וגם בבלוג של עקיבה מרקס בעל נסיון רב מהשטח. בכדי לקבל הסברים בעברית על המונחים הרבים בתחום זה מומלץ לבדוק ב- WIKIT.

חברת REDHAT הודיע על הפסקת תמיכה ב- Itanium

חברת Redhat הודיעה על הפסקת תמיכה של מוצר הדגל שלה- Redhat Enterprise Server במעבד ה- Itanium. מעבד ה- Itanium נחשב במשך זמן רב כמעבד הטכנולוגי המוביל של חברת אינטל. המעבד מבוסס על ארכיטקטורה בשם EPIC- Explicitly Parallel Instruction Computing . לב ליבה של הארכיטקטורה היא המקביליות- אפשרות של הריץ פקודות במקביל בין CORES שונים ומעבדים שונים – בצורה משופרת יותר מהמקביליות שאפשרית בארכיטקטורה הסטנדרטית יותר ה- X64.
השימוש במעבדים הוא בעיקר במשפחת השרתים של HP - מערכת ההפעלה הבשלה HPUX אך גם בפלטפורמת Windows (בעיקר MSSQL אבל ללא אפליקציות כמו Exchange) וגם Linux כאשר ההכרזה של לינוקס משנה תמונה זו.
הבעיה ב- Itanium היא שיצרני התוכנה חייבים לבצע קומפילציה מחדש של התוכנה בכדי שהיא תעבוד בצורה סבירה ב- Itanium. נכון להיום ישנם יצרני תוכנה רבים שעדיין לא ביצעו עבודת הסבה זו ולא ברור אם הם יעשו זאת בעתיד.
בעיה נוספת היא שלמרות שקיים שיפור ביצועים וישנו פוטנציאל לשיפור ביצועים בעתיד, השיפור למול הארכיטקטורה הסטנדרטית, ה- X64, אינו מצדיק את הכניסה לטכנולוגיה שאינה סטנדרטית. לקוחות דיברו על כך בזמנו שאם הביצועים של itanium היו פי 3 או 4 מביצועי X64 אז ילכו בשמחה לפתרון זה אולם בשביל שיפור של כמה אחוזים – הדבר אינו כלכלי.
לסיכום, נכון להיום לא מסתמן ש- Itanium תהפוך להיות אבן בניין המקובלת בסביבה הסטנדרטית – Windows ו- Linux כאשר ההכרזה הנוכחית רק מדגישה עובדה זו.

מה לאגף הפיתוח ול- VDI ?

טכנולוגיית ה- VDI היא טכנולוגיה תשתיתית מובהקת אשר מעניינת ארגונים רבים בתקופה האחרונה.
מסתבר שלמרות העובדה שמדובר בטכנולוגיה תשתיתית קלאסית - הרצה של סביבת משתמש מלאה בשרת והעברת תמונת המסך - ישנם מקרים שבהם אגף הפיתוח משפיע בצורה משמעותית האם להכניס טכנולוגיה כזו לארגון או לא.
זאת מכיוון שהטכנולוגיה הקרובה לטכנולוגיה זו היא טכנולוגיית ה- Terminal Server (מוצרים כמו CITRIX או Windows Terminal Server או Jetro). טכנולוגיה זו הנה בשלה יותר ועל פי המסתמן גם מסוגלת לספק יחסים משופרים יותר מבחינת מספר משתמשים סופיים לשרת.
אולם טכנולוגיה זו מחייבת לפעמים שינויים באפליקציות כך שיתאימו לסביבת ה- Terminal Server - העתק אחד של האפליקציה אשר נמצא בשימוש בין כל המשתמשים על אותו השרת.
ישנם ארגונים שבהם אגף הפיתוח עמוס כל כך עד שאינו יכול להקדיש את התשומות לביצוע השינוי באפליקציות (שינוי שלאחריהם מתחייבות בדיקות קפדניות) ובמקרים אלו אין ברירה לגוף התשתיות אלא לפנות לטכנולוגיית ה- VDI למרות שבפועל היה מעדיף לפנות לטכנולוגית ה- Terminal Server הבשלה יותר.
כלומר אגף הפיתוח "מחליט" בסופו של דבר איזה טכנולוגיה תשתיתית תיושם.

מה זה - שדרוג או הקשחה?

ארגוני מדווחים על קושי בפרויקטים המשנים ומגבילים את סביבת הלקוח. פרויקטים כמו הקשחת מחשבים או SBC – Server Based Computing (שימוש ב- thin clients).
אחד הלקוחות סיפר על דוגמה טובה לפרוייקט הקשחת מחשבים. משמעות הקשחת המחשבים היא שכעת ניתן להשתמש רק בתוכנות אשר אושרו מראש בארגון וגם לא ניתן לחבר התקנים ניידים כ- disk on key.
מנהל התשתיות באותו ארגון המתין עם הפרוייקט למועד מתאים ואיתר את המועד כאשר הוחלט על מעבר ל- Office 2007. ואז, במקום פרוייקט "הקשחה" התבשרו עובדי הארגון על פרוייקט "שדרוג" שבו יקבלו Office 2007 , מצלמת אינטרנט לשיחות וידאו בתוך הארגון ועוד. כאשר הסתבר לעובדים שחלק מהתוכנות שעליהם עבדו לא קיימות יותר לאחר ה"שדרוג" נמסר להם שמדובר בבעיות תאימות ולא ב"פרוייקט הקשחה".
זכורה לי סיטואציה דומה אשר בה הוחלפו מחשבים אישיים בעמדות thin client כאשר רק מי שביצע את ההחלפה קיבל מסך דק – דבר חדשני בזמנו.
לסיכום – יש זמן ומועד לכל דבר כאשר העטיפה חשובה לא פחות מהתוכן.