NonStop TBC 2022 kicked off a new round of modernization with a friendly competition to come up with a sustainable design to replace SCOBOL requesters with the latest and greatest tech available on and off NonStop. As judges, we found the choices that the teams proposed to be both diverse and really cool. The solutions the teams came up with ranged from innovative replacements to component-by-component evolution. It was very revealing of what is possible on our platform and just how far we have come, but also of how far we have to go.
The architecture for the existing application was as follows:
The four teams and their proposed solutions were:
- NonStop Eagles (Chris Capitolo, Gravic Inc. and Vedant Shrivastava, Idelji): The Eagles proposed using JPath to update the screens to web pages for their first pass, for fast time to market. Future development options include adopting the LightWave Client and Server. hosting would be on iTP Webserver, with a future move to NSHTTP.
- TCM Technokrats (Rick Stather and Shiva Subramanian, TCM): They called their design an ‘inside out’ approach, using Angular, open source (Google), and Javascript.
- Team CS (Werner Alexi, CS Software Consulting and Services GmbH and Falk Dresser, CS Software Concepts and Solutions GmbH): Their proposal used quite a few Open-Source frameworks, with two key ones being GraphQL for a Real-Time Publish strategy and Kafka (fed from a TMF Audit Feed). They proposed either Shadowbase or Striim to keep the automatically updated counters on the UI.vvvTS/MP
- Team FNBJ (Gustavo Cavazos, NuWave Technologies, and Leon Arens, First National Bank of Omaha): They used NuWave’s LightWave Client to refresh requests and used the concept of an ‘Aggregator’ server to assume the role of the logic that currently resides in the SCOBOL client. The web service they proposed was to build using Spring Boot. They suggested limiting Screen Update transactions, along with some caching (possibly in the Aggregator) to lessen database impact.
We judged their proposed solutions on six criteria:
- Time to market
- Security
- Long-term stability and adaptability
- Maintenance
- Feasibility
- Coolness factor
At the core of the judging, we found that the choices relating to modernization were both varied and complex to evaluate. There was chatter among the judges from worries about staffing the projects, the complexity of new technology, retaining existing staff who are retiring, all while trying to work out which projects were feasible. This type of decision goes well beyond the friendly event and gets into many parts of our day jobs.
When it came down to the judging, the results were so close that it was difficult to distinguish between any of the contestants. As judges, we really had to work hard to decide who won. Of course, the obvious answer was that everyone won, especially the NonStop platform.
In today’s IT world, the security aspect of modernization requires increasing attention. As hacking has gotten closer and closer to NonStop, keeping technology up to date has become crucial and also problematic. As an example, there are still customers who are using OpenSSL 1.0.2 for compatibility reasons. One key component of modernization is actually keeping informed enough about cybersecurity to know when and why to move up to a more recent version of the technology we currently use. In the OpenSSL case, the key compatibility question revolves around compatible cyphers more than the specific version of the software. Specifically, if you don’t have the same cyphers on both sides, you can’t communicate. Similarly, if you don’t support the same TLS level, you can’t communicate. So, you actually might be successful having a 1.0.2 client talking to a 1.1.1 or 3.0 server, while keeping up to date with Critical Vulnerability and Exposure (CVE) updates for the software components you use. However, as compute capabilities grow and vulnerabilities get uncovered, at some point it becomes necessary to stop using older, weaker cyphers – which affects both communication endpoints.
As an example, we saw the cypher issue come up at L21.09 when a new version of NonStop SSH came up with new cyphers turned on and older cyphers turned off by default. This is not normally what one thinks of as modernization, but it is. Processes, policies, and procedures also need to be modernized on an ongoing basis, now more than ever.
Another perennial challenge came up at the TBC, where some of our vendors are no longer even around, but the challenge is met with new and existing vendors taking more active roles on the NonStop ecosystem.
All in all, modernization seems as much like having to watch your back for trouble as scheduling a new project. Each piece of software must evolve as its dependencies evolve, and we need to be aware of what is coming. If nothing else, this is a crucial potential benefit to social media in a technology space – we can keep each other up to date on what is happening and how we can continue to operate with a world-changing out from under us. Perhaps the discussion should turn from “modernization” to “evolution”…
Be the first to comment