________________________________________________________________________________
In the NACA project (offload from a mainframe to Linux on Intel servers through 100% automatic transcoding of the 4+ millions lines of Cobol of the in-house application), in order to reach the maximum level of savings, we took a radical approach (downsize to Linux and stop the mainframe) to free up as much financial resources as possible. We wanted to maximize the investments for upcoming projects in our IT budgets:
- replace IBM operating system zOS by Linux and Cobol by Java (through our automatic transcoder now open-.sourced)
- replace the zSeries architecture of the mainframe by very simple Intel servers as soon as our benchmarks demonstrated that it was feasible at no risk for our level of activity (750'000 CICS transactions per day). Thanks to Moore's Law, the Intel Pentium proved itself to be highly powerful to handle high transactional workloads.
But, since the open sourcing of our NACA transcoding tools, we had the opportunity to discuss with many companies evaluating our technologies or already running transcoding projects with them on 4 continents (only Africa missing as of now!...).
Those discussions led us to develop a smoother and more "fluid" approach for corporations wanting simultaneously to leverage their mainframe assets and their strengths and to rejuvenate their legacy application:
- Rejuvenate the application functionally: via the NACA tools, the Cobol application is automatically transcoded to Java source code and enjoys then following benefits: (a) as new "official" source code is Java, ability to leverage the very sophisticated environment of Java Virtual Machine still evolving very quickly (b) availability of many (open source) Java packages to integrate with the newly transcoded application to augment its capabilities (c) use of a state-of-the art user interface fully web-based (HTML-CSS-AJAX) as transcoded from the original 3270 BMS maps with no human intervention.(d) use of very modern development IDE (Eclipse through a specific plug-in) that strongly increases their productivity of legacy programmers as they continue seeing their initial and familiar Cobol code to maintain it.
- Rejuvenate the application technically: the Java world is still highly dynamic and improving on a recurring basis. When on JRE, an application can progress just by "being here" and not doing much: we saw a 30% improvement in performances just by upgrading from Java 5 JRE to Java 6 JRE. This is in line with official Sun benchmarks. The Java community improves the JVM day after day to make Java now a clear rival of very efficient languages like C/C++.
- Leverage mainframe assets and strengths: IBM wants its current clients to avoid such radical decisions as ours to keep them in the mainframe community. Consequently, IBM has launched some specialized processors dedicated to handling Java workload on the mainframe. They are called Zaap pour "zSystem Applicat ion Assist Processor". By using them and without any major evolution of the mainframe configuration in place, the naca-transcoded application now runs on those dedicated processors and consequently preserves a very stable and deeply known zOS environment.
Those Zaap processors have a double financial advantage as created by the IBM marketing:- they are themselves much cheaper than a regular mainframe processor (GCP)
- their mips don't add themselves on top of the mips of the regular processors: they don't as such have a negative influence on the monthly software bill of the mainframe for zOS essentially based on mainframe performance. As a matter of fact, they even tend to reduce this bill as the workload run on Zaaps means less mips needed in the regular processors. See details of Zaaps below
Consequently, it is possible to use our NACA transcoding tools to transcode 100% automatically to Java and to simultaneously stay in the "comfort" of the established mainframe environment after transcoding. The application will then run under Websphere (or even in the transactional monitor CICS or IMS but in Java) in a JVM powered by Zaap under direct control of zOS. For batch programs, same architecture but simpler: only the JVM is needed.
Such a mainframe-hosted Java architecture is needed by corporations who want to leverage all the benefits of a transcoded application to Java and web-based UI (see above) but who want to keep it on the mainframe. The company can this way maintain all the integration of the transactional activity with other mainframe subsystems (batch, archiving, printing, etc) sometimes developed over many decades.
Everything stays "in the same box" but the end users can benefit right away from additional functionnalities of their application brought to state-of-the-art.
As additional benefit, this architecture can reduce the mainframe total cost of ownership at double level: (1) the Mips of the transactional workload have now migrated from the costly regular processors to the cheap Zaaps (2) the "regular" (Cobol/CICS) mainframe workload has become smaller, replaced by functionally equivalent Java workload, and the monthly software bill can be reduced as less mips are consumed (see IBM below)
The resulting effects are triple:
- The legacy application has become state-of-the art, from both a user and a developer standpoint: 100% Java and Web
- A smooth and fluid evolution: a potential mainframe-less future is prepared at no risk as current machine, very well mastered by teams in place, remains the unique vector of activities.
- Savings generated by optimized configuration: all possible workload is transferred to the cheapest possible Java environment and the requirements of expensive GCP mips is highly reduced through maximum use of Zaaps wherever possible through the CICS workload migrated to Websphere or Tomcat.
============== IBM Zaap processors
Source for schemes of this article: IBM presentations of Kathy Walsh.
Zaap processors are a significant step in the continuous investment by IBM to maintain the competitiveness of its mainframe zOS platform in the market, when facing fierce rivalry from Open Source (Linux) highly due to the intrinsic expensiveness of zSeries.
To achieve this goal, IBM consistently introduces new processors dedicated to some specific workloads. Those workloads transferred on cheaperinternal processors reduce the TCO of the global machine.
By Publicitas, we did start the NACA project on this path of dedicated processors: we initially started on an IFL processor (IFL = Integrated Facility for Linux) integrated in our ultimate mainframe in order to run another operating system than zOS: zLinux (linux distribution for the mainframe). We decided to move to linux on Intel servers only when internal benchmarks demonstrated that there was almost no risk and significant additional financial advantage to do so.
Since then, IBM has strengthened the concept of dedicated processors beyond the IFL original concept: the Zaap doesn't require another operating (zLinux) to offload activities but runs directly under the control of zOS. The slide below demonstrates the technical and marketing goals of IBM in this technology ( the yellow rectangle at bottom is to be read in details):
Through a marketing "secret sauce", it is all about migrating "central" mips to Java mips on a dedicated processor. The emergence of this new technology brings the opportunity of selling it on a different price scale and also the opportunity of eliminating it of the mips total used to bill the zOS software. So, the current software renting by the mips total remains unquestioned by the community of corporation running their core activities on mainframe. At the same time, the Zaap can be presented as the "white knight" reducing the total of mips hence the price.
As a result, the competitiveness of zOS is clearly improve din its current fight against the linux adoption for critical applications.
Source: blog Media & Tech (par didier durand)
Aucun commentaire:
Enregistrer un commentaire