JBOSS EAP Technology

JBOSS EAP Technology

Feature การทำงานของ JBOSS ที่เป็น Modern Middleware Technology ทั้งในด้านของ การจัดการโครงสร้าง (JBOSS Architecture) 

การจัดการการกำหนดค่าต่าง ๆ ของระบบ (JBOSS Configuration) อีกทั้งด้านความน่าเชื่อถือ (JBOSS Reliability) ที่ผ่านเงื่อนไขการรับรองทางด้านความปลอดภัยที่เป็นระดับสากล และมีการตัดสินใจที่จะนำเอา JBOSS มาใช้ในองค์กร ซึ่งเนื้อหาในตอนนี้จะเป็นการให้แนวทางตลอดจน ขั้นตอนการเตรียมการ และการวิเคราะห์ ในการที่จะ เปลี่ยน Middleware ของระบบเดิมที่มีอยู่ มาเป็น JBOSSEAP JBOSS Migration Startup โดยทั่วไปการทำ JBOSS Implementation มีได้หลายแบบ เช่น

  • การ Implement JBOSS กับระบบใหม่
  • การ Upgrade Version/Patch ของ JBOSS
  • การเปลี่ยน Middleware ของระบบเดิม มาเป็น JBOSS

ในส่วนของ “การ Implement JBOSS กับระบบใหม่” และ “การ Upgrade Version ของ JBOSS” นั้น ไม่ยุ่งยาก มากนัก เป็นขั้นตอนในการทำงานเหมือนกับการ Installation หรือ Upgrade Software ใหม่ โดยทั่วไป แต่สำหรับ “การเปลี่ยน Middleware ของระบบเดิม มา เป็น JBOSS” จะมีขั้นตอนในการทำงานที่พิเศษกว่า การ Installation หรือ Upgrade Software กล่าวคือ เนื่องจากมี Application ที่ทำงานกับ Middleware ตัวเดิมอยู่แล้ว จึงจะ ต้องมีการศึกษาถึงการทำงานของระบบบน Middleware เดิม และต้องมีการตรวจสอบให้แน่ใจว่า การทำงานของระบบยัง คงดำเนินต่อไปได้เป็นอย่างดี หลังจากเปลี่ยนเป็น JBOSS EAP ดังนั้น จึงจำเป็น ต้องมีการเตรียมการวิเคราะห์ และ จัดทำแผนการในการปรับเปลี่ยน ซึ่งเราจะเรียกว่าเป็น “JBOSS Migration Planning”

JBOSS Migration Planning ในการทำ JBOSS Migration Planning จะมีการแบ่งการ ทำงานออกเป็นขั้นตอน หรือ Phase การทำงานย่อย ได้เป็น 4 Phase คือ

  1. Perform an Application and Infrastructure Assessment
  2. Measure Organizational Readiness
  3. Develop a Strategic Migration Plan
  4. Implement the Migration Plan

Phase I: Perform Application and Infrastructure Assessment  

เป็นขั้นตอนในการศึกษา รวบรวมข้อมูลของ Application และระบบ Infrastructure เดิม ของระบบ ที่ต้องการเปลี่ยน เป็น JBOSS และระบบที่เกี่ยวข้องทั้งหมด เพื่อให้เราสามารถ นำเอาข้อมูลเหล่านี้ไปวิเคราะห์และทำแผนการ Migration ให้พบปัญหาที่คาดไม่ถึงให้น้อยที่สุด

โดยมีประเภท และรูปแบบเอกสาร (Template) ที่ใช้ในการ เก็บข้อมูล ตัวอย่างดังต่อไปนี้ ซึ่งในแต่ละองค์กรอาจมีปัจจัย หรือลักษณะการทำงานที่ต่างกัน รูปแบบเอกสารก็อาจแตกต่าง กันไปในรายละเอียดบ้างตามแต่องค์กรนั้นๆ

  1. Application Contacts เพื่อรวบรวมเอาข้อมูลเบื้องต้น ของ Application ทั้งในส่วน ของเจ้าของ (Application Owner) หรือผู้ดูแล (Application Administrator) ที่มีสิทธิต่างๆ ในการเข้าถึงข้อมูล รวมถึง ต้องการผู้ที่มีอำนาจในการตัดสินใจ ทั้งในมุมมองของ Technical และในมุมของ Business อีกด้วย จากประสบการณ์จุดนี้เป็น ปัจจัยที่มีความสำคัญ ที่สามารถทำให้โครงการผ่านไปได้ด้วยดี หากเราได้รายชื่อของผู้ที่มีอำนาจในการตัดสินใจได้จริงมา เริ่มทีมตั้งแต่แรกเริ่มโครงการ
  2. Infrastructure Analysis เพื่อรวบรวมเอาข้อมูลด้าน Infrastructure ของ Application ที่เกี่ยวข้อง อาทิเช่น Server Information, Network Specification, Software และรายละเอียดต่างๆ Database Information ซึ่งเป็นการให้ข้อมูลร่วมกันทั้งจากฝั่ง Infrastructure และฝั่ง Application
  3. Application Dependencies เพื่อรวบรวมเอาข้อมูล Application Dependencies ของ Application เพื่อให้มองเห็นภาพความเกี่ยวข้องกันของ Application ทั้งหมด เพื่อป้องกันให้ไม่เกิดปัญหา กรณีหาก เราต้องทำการเปลี่ยนแปลง Application ใด Application หนึ่ง แต่ไม่ได้ทำการทดสอบ Application รอบๆ ที่ Application นั้นเชื่อมต่อหรือมีความเกี่ยวข้องอยู่
  4. Application Assessment ส่วนนี้เป็นการรวบรวมเอาข้อมูลรายละเอียดของ Application ในเชิงลึก เพื่อเป็นข้อมูลประกอบในส่วนของ Technical เพื่อ นำไปวิเคราะห์ความยากง่าย ความเข้ากันได้รวมไปถึงระยะ เวลาที่จะต้องใช้ในการทำ Migration Plan โดยมีหัวข้อที่ ต้องการข้อมูลจาก Application เช่น
  • Application Name
  • Current Technologies
  • Proprietary Libraries
  • JBOSS Technologies
  • Open Source Libraries
  • Migration Hours
  • Rating
  • Engineering Contact
  • Testing Contact

ซึ่งการเก็บข้อมูลในส่วนนี้ เราสามารถนำ Tools เข้ามาช่วย ได้เพื่อให้การทำงานง่ายขึ้น Tools ที่สามารถเข้ามาช่วยได้ใน ขั้นตอนนี้คือ “Windup” ซึ่งเป็น Tools ที่รองรับการทำงาน สำหรับ Application ที่เป็น JAVA EE Application โดย เฉพาะใช้สำหรับเข้ามาช่วยในการทำการวิเคราะห์ Code ใน การ Migration จาก Middleware เดิมมาเป็น JBOSS สามารถ ออก Report ในรูปแบบ HTML โดยจะแสดงในจุดที่จะกระทบ หรือจุดที่ต้องการการเปลี่ยนแปลงในการทำ Migration

Phase II: Measure Organizational Readiness

เป็นการทำงานใน Phase ที่ต้องตรวจสอบความพร้อมของ องค์กร ซึ่งโดยทั่วไปการเปลี่ยนแปลง ไม่ว่าจะเป็นการเปลี่ยน ไปสู่ Technology ที่ใหม่กว่า การปรับเปลี่ยน Product ที่ ล้าสมัย เป็นเรื่องธรรมดาที่จะเกิดขึ้นกับงานทางด้าน IT อยู่แล้ว ซึ่งการปรับเปลี่ยน Middleware จาก Commercial Product มาเป็น Open Source Product อย่าง JBOSS เองก็เช่นกัน ดูเหมือนจะเป็นงานที่เป็นเหมือนงานธรรมดา ทั่วไปแต่ในความจริงแล้ว อาจจะผ่านไปไม่ได้เลย หากองค์กร ไม่ได้เตรียมตัวไว้ก่อน ดังนั้น เพื่อไม่ให้เกิดปัญหาขึ้น เราควร จะมีการเตรียมความพร้อมไปด้วย โดยมีขั้นตอนคือ ทำการประเมินปัญหาขององค์กรที่เป็นไปได้ และความเสี่ยง และนำไปวางแผนการดำเนินการแก้ไขปรับปรุง ซึ่งมีปัจจัยในการตรวจสอบความพร้อมขององค์กร ดังนี้

Training and Knowledge Gaps

– ประเมินว่ามีพนักงานที่มีความรู้ความสามารถใน Tools ที่จะนำมาใช้อยู่แล้วหรือไม่

– มีการจัดตั้งหน่วยงานหรือ มี Process ในการที่จะให้ ความรู้หรือไม่

 Workload Factors

– พนักงานที่จะมาร่วมทีมในการทำ Migration นั้น สามารถแบ่งเวลาจากงานประจำที่รับผิดชอบอยู่ได้โดย ไม่เกิดปัญหา Work Load หรือไม่

– อุปกรณ์ Hardware ต่างๆ เพียงพอต่อการทำการ ทดสอบหรือไม่

Cultural Factors

– การตัดสินใจขององค์กรเป็นแบบ Bottom-Up หรือ Top-Down

– องค์กรให้ความสำคัญกับคุณภาพของงาน ต้องการงาน ที่ Quality สูง มากกว่าที่จะสนใจในเรื่อง Cost หรือไม่

Budget

– สำหรับโครงการที่มีการซื้อ Software ใหม่ หรือ Implement Product ใหม่ มีการลงค่าใช้จ่ายเป็น CAPEX (Capital Expenditure) หรือ OPEX (Operating Expense)

– การนำเสนอ Model สำหรับโครงการของ IT ใช้วิธี ROI (Return on Investment) หรือ TCO (Total Cost of Ownership)

Phase III: Develop Strategic Migration Plan

เป็นการนำเอา Assessments Result ต่างๆ ที่ได้จาก Phase I-Application and Infrastructure Assessment และ ข้อมูล ขององค์กรที่ได้จาก Phase II-Measure Organizational Readiness มาปรับให้เป็น Strategic Migration Plan คือ Plan งานในการทำการ Migration ที่เหมาะสมกับแต่ละองค์กร ในขั้นตอนนี้ สามารถเพิ่มการทำ Strategic Migration Roadmap คือมองภาพของทั้งองค์กร อาจเป็นการมองในทุก Application หรือ ในแต่ละ Business Area ที่ควรและสามารถ จะถูกปรับเปลี่ยน Middleware ไปเป็น JBOSS ได้ ซึ่งจะ เกิดประโยชน์ในภาพรวมมากขึ้น หากต้องการทำ Strategic Migration Roadmap ในส่วนของ Phase I-Application and Infrastructure Assessment อาจจะต้องมีการเก็บข้อมูล ของApplication / Infrastructure ที่มากขึ้นไปด้วย

Phase IV: Migration Plan Implementation

เป็นขั้นตอนสุดท้ายคือการ Implement Migration Plan ตาม Strategic Migration Plan ที่กำหนดไว้ซึ่งควรจะมีการกำหนด Plan และผู้เกี่ยวข้อง (Stakeholder) ให้ชัดเจน อีกทั้งขั้น ตอนในการทำการทดสอบ (Testing) ก่อนที่จะถูก Deploy หรือนำขึ้นไปใช้บน Production Environment ก็เป็นเรื่อง ที่จำเป็นและสำคัญมากซึ่งเป็นการรับประกันว่า Application ยังคงสามารถทำงานได้เป็นปกติโดยอาจแยกการทดสอบ (Testing) ออกเป็นหลายมุมมอง ขึ้นอยู่กับความจำเป็นและ ความต้องการของแต่ละองค์กร เช่น • Functional Testing เป็นการทดสอบการทำงานของ Application ว่ายังสามารถ ทำ Function ต่างๆ ได้เป็นเหมือนปกติ

System Integration Testing

เป็นการทดสอบการเชื่อมต่อของระบบ ว่ายังสามารถเชื่อมต่อหรือทำงานร่วมกับระบบที่เกี่ยวข้องได้เป็นปกต

Non-Functional Testing

เป็นการทดสอบในส่วนอื่นๆ ที่ไม่ใช้Function การทำงาน ของ Application เช่น

  • Performance Testing เป็นการทดสอบเพื่อหา Based Line ของประสิทธิภาพ ในการทำงานของ Application โดยอาจแยกเป็น Based Line ในแต่ละ Function การทำงาน เช่น หน้า Login ต้องมีResponse Time ภายใน 3 วินาทีเป็นต้น
  • Security Testing เป็นการทดสอบความปลอดภัยระบบเพื่อให้แน่ใจว่าไม่ มีช่องโหว่ ให้ถูกโจมตีจากผู้ไม่หวังดีได้ทั้งในเรื่องของ
  • Platform Security ตรวจสอบความปลอดภัยใน ส่วนของ Firewall, Web Server, Application Server, DB Server เช่น การตรวจสอบในด้านการ ปรับปรุง Version ของ Software ต่างๆ ให้Update อยู่เสมอ การตรวจสอบ Security Misconfiguration ตรวจสอบการถูกโจมตีโดย DDOS Attack เป็นต้น
  • Application Code Security ตรวจสอบความ ปลอดภัยของการทำงานในส่วนของ Code คือไม่มี ส่วนของการทำงานของ Code ที่ยังคงเปิดให้มี ช่องโหว่ ให้ถูกโจมตีได้ เช่น SQL Injection, Cross-Site Scripting (XSS), Cross Site Request Forgery (CSRF) เป็นต้น

ทั้งนี้การเลือกประเภทในการทดสอบ (Testing) ยังมีปัจจัย อีกหลายอย่าง เช่น ขึ้นอยู่กับความสำคัญของ Application และการวาง Infrastructure ของ Application นั้นๆ ตัวอย่าง เช่น

  • เป็น Web Application ที่วางอยู่เครือข่ายด้านนอก Firewall ที่อนุญาตให้คนทั่วไปเข้ามาใช้งานได้การ ทดสอบด้าน Security ก็จะมีความจำเป็นมากกว่า Application ที่วางอยู่ด้านใน Firewall
  • เป็น Web Application ที่ให้บริการที่เน้นในด้านการ บริการที่ต้องการความรวดเร็ว การทดสอบด้าน Performance ก็จะมีความจำเป็น

บทสรุปส่งท้าย จากข้อมูลทั้งหมดน่าจะเพียงพอในการที่จะ ตัดสินใจ เลือกใช้ JBOSS EAP Middleware ที่คุ้มค่า ทั้งใน ด้านประสิทธิภาพและในด้านราคา อีกทั้ง Methodology และขั้นตอนในการทำ Migration ก็สามารถทำให้มั่นใจได้ เพราะมีขั้นตอนต่างๆ ตั้งแต่เก็บข้อมูล การวิเคราะห์ การ Implement ตลอดจนการทดสอบ (Testing) ก่อนที่จะขึ้นไป ยังระบบจริง (Production Environment) ทำให้มั่นใจได้ว่า โครงการ JBOSS Migration จะประสบความสำเร็จอย่าง แน่นอน



Top