 |
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Feature Articles: Technologies for Promoting Use of Open Source Software that Contribute to Reducing TCO of IT Platform Vol. 12, No. 6, pp. 7–13, June 2014. https://doi.org/10.53829/ntr201406fa1 OSSMA: Facilitating Migration to OSSAbstractThe NTT Open Source Software Center promotes the use of open source software (OSS) in order to reduce the total cost of ownership of systems within the NTT Group of companies. It also provides total support related to OSS migration in the form of its OSS Migration Assist (OSSMA) service. This article introduces OSS migration technologies, describes the OSSMA service and its benefits, and gives some application examples. Keywords: OSS, migration, system development  1. IntroductionAt NTT Group companies, efforts to promote the use of open source software (OSS) for in-house operation systems and middleware are taking root in order to reduce the total cost of ownership (TCO) of systems. These Feature Articles introduce some of the achievements of NTT Open Source Software (OSS) Center’s technological developments that are aimed at accelerating the use of OSS at NTT Group companies [1]–[7]. 2. Background to this initiativeThe functionality and quality of OSS such as Linux have increased in recent years. This has been advantageous for companies using OSS for business systems, as it has resulted in reduced system development costs and lower system operation costs by avoiding vendor lock-in. For system development in the NTT Group, we are actively introducing OSS for system upgrades as well as for new systems. Most system development proposals are for updates (over 80% of development proposals the NTT OSS Center is involved in), but most of these cases use particular functions of commercial middleware, or have application program (AP) specifications that depend heavily on such middleware. As a result, a development cost, referred to as a migration cost, is incurred to eliminate these dependencies. There have been cases where OSS migration had to be abandoned because the migration cost was estimated to be higher than necessary, or the cost of the OSS migration work was higher than expected, and consequently, the TCO was not reduced. Thus, it is important to improve the accuracy of estimating the migration cost and to reduce the actual cost of migration. To resolve these issues, the NTT OSS Center is accumulating know-how for checking whether OSS functionality and performance are sufficient for system requirements and what the extent of the effect will be on APs when using OSS. It is also providing the OSS Migration Assist (OSSMA) service to provide total support for the system development process. 3. Importance of determining migration feasibility in the initial study phaseThe support provided by OSSMA in each development process is shown in Fig. 1. The initial study phase is particularly important here. In this phase, the scope of the effect of migrating from a commercial operating system (OS) and middleware to OSS is ascertained, a decision is made as to whether or not OSS can be applied, and if it can, an estimate of the cost of migration work is calculated. Two important points to ascertain regarding the scope of the effect are described below.
3.1 Checking adaptability to system requirementsHere, we check whether OSS can satisfy the functional and performance requirements of the system. If there will be difficulty satisfying these requirements, alternate solutions for the insufficiencies are considered, and the cost of such solutions is estimated. If these issues cannot be resolved, it will be necessary to forgo the use of OSS. 3.2 Checking the scale of migrationHere, we identify areas of the AP that will be affected by using OSS, study how revisions will be made, and estimate the cost of the development phase of the AP migration (from design through testing). If the AP migration cost is too high or the revisions are too difficult, it will be necessary to forgo the use of OSS. The method of deciding whether TCO reductions can be gained through OSS migration is shown in Fig. 2. As shown in the figure, the TCO for a simple upgrade (upgrading the existing OS and middleware) is compared with that for migration to OSS; if the TCO of the OSS migration is lower, then the OSS migration should be selected. In order to compare TCOs appropriately, it is important to clarify the level of difficulty and the scale of the effect of the AP migration, and to estimate the migration cost in detail.
4. Overview of OSS migration technology and benefits of OSSMAGenerally, the part of the migration cost that is most difficult to estimate is the cost of porting APs, which requires clarifying problems in porting, comprehensively extracting the corresponding sections in the source code, and considering suitable ways to revise them. For example, one area affected by OS migration is computations involving unions*1. However, not all unions require revisions; the effects depend on the type of data stored in the union and the method of computation. Revisions are only necessary when APs are affected, and the revisions should be made in such a way that the source code does not depend on differences in the central processing unit (CPU) architecture. With OSSMA, tools implementing the accumulated know-how of the NTT OSS Center are used to extract areas affected by migration to four products: Linux, JBoss*2, PostgreSQL*3, and Crane*4. Technical issues when porting applications to each of these products are explained below. 4.1 OS• For shell programs and APs written in the C programming language, differences in OS commands, system call specifications, and memory storage formats for different CPU architectures (big-endian, little-endian, etc.)*5 must be considered. • OSSMA tools conduct over 2000 logic checks in analyzing AP syntax. 4.2 Application server• Even though the effects of changing products are relatively small because Java is a platform independent language, APs must be revised with respect to upgrading Java itself and differences between any commercial middleware being used and OSS functionality. • Upgrading Java itself must also be considered when upgrading commercial middleware. • The TUBAME*6 OSS tool can be used to identify the extent of these effects. 4.3 DBMS• Structured Query Language (SQL) used in C, Java APs and shell scripts, as well as database definitions, must be revised where they use proprietary features (non-standard SQL functions, preprocessors, etc.) of a commercial database management system (DBMS). • The db_syntax_diff*7 OSS tool can be used to identify the extent of these effects; the tool checks over 1400 points in analyzing SQL logic. • The business data stored in the database must also be migrated. 4.4 Operations management• Parameter definitions used in a jobnet*8 of commercial operations management software need to be revised in order to use the jobnet functions of Crane. • Revising the jobnet means that operational procedures change, so maintenance workflows and procedures must be reviewed as well. Using OSSMA is beneficial in that the parts of APs affected can be checked quickly during the initial study phase, so the upgrade plan can be decided quickly. The areas affected and how to revise them can also be clarified in the initial study phase, which provides the added benefit of reducing the cost of coding and unit testing during the production and testing phases. The benefits of using OSSMA over the entire development process are shown in Fig. 3.
5. OSSMA application exampleHere, we give an example of using OSSMA when updating a business support system (System A) in an NTT Group company. System A was developed during the period from May to December in 2012 and has been provided commercially since January 2013. The software architecture of System A before and after updating is shown in Fig. 4. The OS and main software applications were switched from commercial products to OSS. Two points of concern were identified while studying the system’s applicability during the initial study phase: (1) PostgreSQL may not meet the performance requirements. (2) The AP revision cost for PostgreSQL is high, so the benefit of reducing TCO may not be attainable.
The concerns raised in the initial study phase had many significant effects on the basic system design, so at the NTT OSS Center, we placed particular emphasis on them in our consultations. For this project, we handled these two issues as follows. 5.1 Issue (1)The pre-update system used a partitioning function*9 of the commercial DBMS in order to increase processing performance. There was a risk that performance requirements would not be met when porting this function to PostgreSQL (with partitioning), so we prepared a test environment with the same specifications as System A and tested the performance with respect to partitioning. The results of these tests are shown in Fig. 5. The figure shows that System A performance requirements will be met with PostgreSQL, eliminating the concern regarding the development project. It also shows that performance requirements will be met with PostgreSQL without partitioning, which contributes to development efficiency by simplifying the system design.
5.2 Issue (2)We obtained the source code for the existing system and used db_syntax_diff to extract the affected sections of the APs and estimate the scale of revisions required. The results of studying the portability are shown in Figs. 6(a) and (b). The scale of the revisions are shown in Fig. 6(a), which indicates that the source code has a scale of 250 kL (kilo-lines) of code, and the required revisions are on a scale of 9 kL (just under 4% of the source code). The results of evaluating the level of difficulty of the revisions are in Fig. 6(b). Out of the 9 kL to be revised, more than 99% have a difficulty level of Low 1 or Low 2. (After the development was completed, we received feedback from the project team members who said that these results were very thorough and extremely useful.)
The migration cost of the project was estimated based on the above results. The project team recognized that TCO would be reduced sufficiently, so they decided to use PostgreSQL. We continued to provide technical support throughout the entire development process; we supported tasks such as updating files, which reduced any uncertainty the team members had about the development project.
6. Future developmentWe will continue to work to expand the scope of migration products and the accuracy in identifying areas in APs that will be affected so that OSSMA can be used more widely. We are actively making improvements to create a service that is easier to use based on feedback from actual projects and customer requests. We will continue to work from a customer perspective with OSSMA and other services, so that NTT OSS Center activities contribute to further increasing the competitive strength of NTT. References
|
|||||||||||||||||||||||||||||||||
