NonStop Trends and Wins: NonStop at 50 Part II

Nonstop Trends and Wins

I ended Part 1 of this article in about 2010 with the demise of Neoview, the NonStop Enterprise Data Warehouse (EDW), which had been adopted by a number of customers and HP itself. As mentioned, it was end-of-life, I believe, mostly as a backlash to CEO Mark Hurd. At one point, NonStop was separated from Neoview into two different business units. The NonStop side started a new “skunkworks” project code-named Flatland. This was around 2007. This was a project that included HP Labs. At this time, unstructured data was becoming a hot topic within IT. Structured data is what everyone has been dealing with since Bill Inmon, the father of data warehousing, proposed the Enterprise Data Warehouse in the late 1980s/early 1990s.

Back then, Tandem had Bill Inmon come in and do a presentation for us on the data warehouse, and I had a copy of his video for a long time. Tandem did some forays into Data Warehousing in the early 1990s, but we never got many sales and moved away from that market. Perhaps a mistake. We could have competed with Teradata effectively if we’d stuck with it, but I digress. The next hot item was unstructured data, and we felt it would be as big, if not bigger, than the EDW market. The amount of data was a lot more, but of much less quality. HP Labs already had a number of patents in the unstructured data area, specifically one related to legal documents. With that as our test case, the team started building a system that could support unstructured data on NonStop using SQL/MX. The team succeeded in creating a working model, and we were in discussions with a major healthcare company about ingesting surgery notes and running analytics against them. Additionally, we had a second pilot, kicking off with a state government. We had funding. When the financial crisis hit, everything appeared great, and all pilots were canceled. We were waiting for that to happen when Leo Apotheker replaced Mark Hurd as CEO. In 11 months, he managed to tank the stock price ($55 to $16), suggest HP would spin off the desktop/printer group, launch, and then kill the HP tablet and acquire Autonomy for $11 Billion (eventually written off). Autonomy was an unstructured data company, so funding for Flatland was canceled, which was too bad since Autonomy’s capabilities were never realized.

Given the move toward ‘Big Data’ at the time, HP offered something called HAVEN, which stood for Hadoop, Autonomy, Vertica, Enterprise security, and apps (I never understood why apps were ‘N,’ but oh well). In NonStop, there was a push to have the ‘N’ stand for NonStop, and we were somewhat resurrecting ZLE (Zero Latency Enterprise) concerning real-time processing but with a twist: we were looking at specifically data-in-motion from the edge to the data center and performing cleansing along with in-flight analytics. NonStop was making some headway, however all the other parts of HAVEN were in the HP Software business unit, while NonStop was in the mission-critical compute business unit. I should mention that Meg Whitman had replaced Leo as CEO and was working on straightening out HP. One of the first big moves was splitting HP into HP and HPE. HP was about a $128B company, and both of the split companies had about $64B in revenues, almost even. Meg stayed as the CEO of HPE. After settling things down a bit, she began what was known as the spin/mergers. The first to go was Enterprise Services (ES), which was the remnant of EDS, which HP had acquired several years back. ES was merged with Computer Sciences Corp (CSC), forming a new company, DXC. That is important because the next spin/merger was the software business unit of HPE to Micro Focus. Pretty much everything in HAVEN was spun off to Micro Focus. Perhaps it is a good thing that NonStop did not become part of HAVEN after all.

In about 2010, a skunkworks project was started based on an idea from our LAMP project. LAMP, which stood for Linux, Apache, MySQL, Perl/PHP/Python, was an OSS project supporting LAMP migrations onto NonStop. Unfortunately, serious performance issues arose and could not be overcome. One idea from that was to run programs (aka serverclassess, microservices) on a Linux server but have Pathway (TS/MP) monitor and control them. This idea bubbled up again, and a new project called GuardianAngel was developed to showcase NonStop control and availability on Linux and in the cloud. At the 2011 HP Discover show (prior to the HP/HPE split), Meg Whitman ‘announced’ that HP would be getting into the cloud, while in a small booth at Discover NonStop, was demonstrating the ability to start microservices in Amazon and auto restart them during a simulated Amazon zone failure. An Amazon ‘cloudburst’ was also demonstrated to show scale-up in the public cloud, but at that time, NonStop customers had no interest in it and were quite scared of it. At the NonStop Technical Boot Camp this year in Monterey, we will discuss the Public Cloud offerings announced last year, but it’s worth noting that NonStop has been playing around with Public Cloud since early 2011. The GuardianAngel prototype was given to Infrasoft, which completed it and released it as a product called MaRunga (See Figure 1). It was, perhaps, ahead of its time and was eventually taken off the market.

Figure 1 – MaRunga
Figure 1 – MaRunga

After GuardianAngel had run its course, the NonStop strategy team began looking for large and growing markets that would require some mission-critical processing. The Internet of Things (IoT) seemed like an interesting target market. With our friends at Infrasoft a working version of javascript called node.js was ported to NonStop. Node.js was particularly attractive to NonStop since the model was single-threading and most implementations followed the Reactive Manifesto which fit NonStop to a tee (see figure 2).

Figure 2 Reactive Manifesto: Responsive, Resilient, Elastic and Message Driven
Figure 2 Reactive Manifesto: Responsive, Resilient, Elastic and Message Driven

Using the node.js environment an impressive demonstration was developed and showcased at the technical Bootcamp in 2015 showcasing several IoT devices interfacing with a NonStop system (see figure 3).

Figure 3 IoT Demonstration
Figure 3 IoT Demonstration

It was an impressive demo that showed Arduino, ESP, and Raspberry Pi devices interfacing with each other, running through a NonStop, supporting a Mosca broker, and using the Redis NoSQL database. This was a frontrunner to IMC our NonStop implementation of Redis.
One of the next big markets to come along was Blockchain. The most famous Blockchain implementation is Bitcoin, which came as a reaction to the financial crisis and was designed as a way to exchange something without financial or government backing. This continues with cryptocurrencies, but at the time, this was a burgeoning market with lots of potential, and we felt NonStop should be involved. What was needed for NonStop to participate in that exciting new market? In Figure 4, the components that were required were broken out, and many of those components already existed on the NonStop system. The node.js port allowed access to Restful services and to anything in the open-source arena – which could have included some blockchain (BC) APIs, smart contracts, and even some rules engines.

Figure 4 Blockchain components
Figure 4 Blockchain components

Items in blue indicate what NonStop already had, and once again, the NonStop architecture having a single system image, massive scalability, and parallel processing created a compelling fit for the new market. And, we reasoned, why wouldn’t a customer want to host a private master chain on a system with the highest out-of-the-box availability in the industry? This led to a partnership with R3 Corda, a Distributed Ledger Technology (DLT) Fintech. Discussions with many banks ensued, and many wanted to pilot Blockchain/DLT, but not many wanted to go into production with it.

Thinking outside of financial services, we created another ‘stalking horse’ code-named PillSAFE, which was a combination of technologies starting with a freestanding unit to dispense pills. The items in the pill dispenser could be a combination of Over-The-Counter (OTC) and prescription medications. The unit itself was envisioned to have individual pill-holding areas that would dispense a pill based on the prescription timetable. For example, once a day, twice daily, with meals, etc. The unit required identity verification of the individual, caregiver, or approved person (relative) to dispense medication. Authentication may be done through a number of methods, such as smartphone proximity, such as password, challenge, biometrics, or a combination of these. The physician or pharmacy could override or clear security issues. The unit would have its own distributed ledger/Blockchain which would serve both as an event log and a verification of medication taken. Based on smart contract technology, once a medication has been taken (or missed), an alert will be sent to interested parties (physician, hospital, relative, and caregiver). The unit will be considered tamper-resistant in that if any unauthorized attempt to open the unit is detected, either an alert can be sent to interested parties, or if more engineering is placed into the unit, all pills could be flushed to a shredding component or otherwise destroyed (method TBD) while alerting all interested parties to that event. As a result of medication destruction, a replacement medication request would immediately be sent to the prescribing physician and the pharmacy through smart contract technology.

The R3 Corda Distributed Ledger Technology (DLT) was considered a perfect fit for these requirements. The DLT will require mission-critical notary technology based on legal requirements. The model called for limited sharing of information. A PillSAFE unit would only have its ledger transactions and the ones associated with the prescribing physician and pharmacy. A prescribing physician’s ledger would contain all the patients related to that physician. The pharmacy ledger (NonStop) would include all local customers and their prescribing physicians. In the diagram below, ledgers A, B, and C represent individual PillSAFE units at a residence. Ledger D is the ledger associated with the prescribing physician. Ledger E is the ledger associated with the local pharmacy. The diagram shows that A, B, and C do not share information—the ledgers for the physician and pharmacy share information from each patient and with each other.

R3 Corda Distributed Ledger Technology (DLT)

The NonStop team was beginning to create some patents in conjunction with HP Labs when HPE unexpectedly abandoned its Blockchain/DLT business unit. Thus, our foray into Blockchain ended.

NonStop continues to explore interesting areas, including AI system interactions. Since we are nearing real-time, I’ll end the lookback here.

Author

  • Justin Simonds

    Justin Simonds is a Master Technologist for the Americans Enterprise Solutions and Architecture group (ESA) under the mission- critical division of Hewlett Packard Enterprise. His focus is on emerging technologies, business intelligence for major accounts and strategic business development. He has worked on Internet of Things (IoT) initiatives and integration architectures for improving the reliability of IoT offerings. He has been involved in the AI/ML HPE initiatives around financial services and fraud analysis and was an early member of the Blockchain/MC-DLT strategy. He has written articles and whitepapers for internal publication on TCO/ROI, availability, business intelligence, Internet of Things, Blockchain and Converged Infrastructure. He has been published in Connect/Converge and Connection magazine. He is a featured speaker at HPE’s Technology Forum and at HPE’s Aspire and Bootcamp conferences and at industry conferences such as the XLDB Conference at Stanford, IIBA, ISACA and the Metropolitan Solutions Conference.

Be the first to comment

Leave a Reply

Your email address will not be published.


*