The actual name is IBM Wazi Developer for Red Hat CodeReady Workspaces but with so many nouns in a title, the community was relieved when IBM started simply calling it IBM Wazi Developer.
As companies have pushed software development into containers, at least for distributed applications, and due to the close relationship between IBM and Red Hat, it was logical and wise that containerization also be applicable for mainframe development. The classic arguments about mainframe developers nearing retirement, new hires and the skills they have, tools they have learned from or use, developers being responsible for not just the front end rather also the mainframe back-end. These are all reasons to offer mainframe development “in the cloud”. But some of you already know that ZD&T could run in OpenShift since years. With Wazi Developer, this support was extended to Red Hat.
But is that it? Is Wazi Developer only a ZD&T running in Red Hat Openshift? Most distinctly No!
Wazi Developer is a flexible bundle of standardized software development tools which address company enterprise CI / CD environments in this ever-advancing IT landscape. Parts of this bundle have their foundations in non-IBM technology, and needless to say in the original form they are oriented toward front end development. In Wazi Developer, we have added functionality, technology necessary for a complete mainframe development process and naturally the IBM support that belongs with it.
Wazi Developer is made up of three separable parts. We call them: Wazi Sandbox, Wazi Code, Wazi Analyze.
Wazi Sandbox is a z/OS (ZD&T) running in a Red Hat Openshift cluster. Z/OS is intentionally stated due to the ZD&T capability to produce a z/OS deployable image (ZD&T) made from a real z HW LPAR. With the ZD&T component and image concept, users can pick and choose which components belong to a z/OS image, and then with a click of the mouse could deploy to a Linux RHE. With Wazi Developer users can now choose to deploy to a Red Hat Openshift cluster. From a CI / CD perspective this capability is also available thru APIs so that a z/OS image (ZD&T) can be deployed, IPL’d, used for a test, and then destroyed if wanted, all within the pipeline. At the Spring GSE Enterprise Modernization User Group event, 1 session was from a Banking Group which had automated their pipeline so well that from the initial request to the IPL only 4.5 minutes were needed and the deployed image contained the artifacts necessary for the test.
Wazi Analyze is a new addition to the bundle. Within Wazi Developer the concept is a user clones a repository, Git for example. Automatically in this case the branch is scanned and all relationships between artifacts is stored in hypercube memory. Through the browser interface the developer can now discover the relationships within the application(s). The user can make a change and rescan to see if the change has had the desired effect. There are several star advantages to Wazi Analyze. The speed of the scanning is super-fast and queries to an in-memory database also super-fast. Storing the relationships in memory also means that the user is isolated from others, just like the Git branching concept. The user can develop, change, and rescan, make another change, rescan all isolated from others. ADDI (Application Discovery Delivery Intelligence) is a similar tool but uses a database server concept meaning all developers would see the same relationships from the same artifacts. After a commit to the Master branch for example, a server concept would make sense. However, during the development on a branch, being isolated gives the user the changing application relationships without influencing others.
Wazi Code is where a lot of people get confused. The IBM saying behind Wazi Code is: “bring your own IDE”. Why? The eclipse foundation had a browser-based editor project called Che. During the project the framework was adapted to also work on VS Code base. So, we have 2 editors with 1 code base. A browser editor is ideal for containers, the development environment many IT Executives want to move to. A browser editor is light weight and flexible and is a perfect fit in a container such as Red Hat Openshift. VS Code is used by more than 30% of developers using it. Hence, if a language server supporting mainframe languages like COBOL, PL/I, or JCL could be developed, then Che & VS Code could be extended for mainframe development. If light weight connectivity from the code base to a mainframe could be established, like through Zowe then we could gain access to the JES to PDSs. If a light weight RSE command line was available we could even have Remote debugging, a debug session running on z/OS with a Che / VS Code UI. In order to support the younger developers, in order to support the Wazi Sandbox in the Red Hat Openshift container, IBM did just that: Wazi Developer for VS Code and Wazi Developer for Red Hat CodeReady Workspaces was developed. In “bring your own IDE” eclipse is however always mentioned as a 3rd alternative of Wazi Code. This 3rd alternative is called Wazi Developer for Eclipse. It is a lighter version of IBM Developer for z/OS. Multiple features like Code Coverage, zUnit, integration to host based SCMs, even certain mainframe languages are not available. These restrictions naturally apply to the other 2 alternatives of Wazi Code. IDz will remain the top of the line IDE from IBM.
It is worth explaining the flexibility of the Wazi Developer licensing model. It is based on VPCs which stand for Virtual Processor Cores which is a bit misleading as it has nothing to do with hardware rather with Authorized Users (AU). 1 VPC has a list price. With 1 VPC a customer can have 5 AUs accessing a Sandbox or 5 AUs of Wazi Code or 2 AUs of Wazi Analyze. Concerning the Wazi Code, the customer can choose any of the 3 Wazi Developer tools they want or mix them up for example: 3 AUs of Wazi Developer for VS Code and 2 Wazi Developer for Eclipse. With this model a customer has the flexibility to mix and match his IT shop’s needs.
For more information please contact: email@example.com.