NonStop SQL as a Service

In the January edition of NonStop Insider, Justin Simmonds explored the idea of “NonStop as a Service”, asking himself “what if a NonStop system could be made available with ‘some’ management?”

It made me think of the option that goes one step further: “What if NonStop SQL/MX could be made available as a service?” And this is exactly what is possible today on L-series system software with NonStop SQL/MX DBS. The DBS acronym in the name stands for “Database Services” and this is a reference to what is described in the industry as Database-as-a-Service or DBaaS.

I am assuming that the readers of NonStop Insider are NonStop users already. For these users, SQL/MX DBS provides an opportunity to make even better use of the existing NonStop infrastructure for example, to host data that would otherwise require additional resources, system management and resiliency.

The idea of SQL/MX DBS is to provide NonStop SQL to users, for example developers or application users, without the need for them to learn how to work with the NonStop operating environment.

Even though OSS with the large selection of Open Source utility software has the look and feel of a Linux environment, there will be differences, and given the nature of developers, they will encounter these, and before you know it, there will be questions and discussions with the NonStop system admins, who may not always be ready to talk the language of these “new kids on the block”.

Once Nonstop SQL/MX DBS has been installed, developers of database applications do not need any direct access to the NonStop (database) server to be productive. Instead, they can use common development tools that they run from their favorite environments, be it Linux, Windows, or Apple, as long as they use the JDBC and ODBC database APIs to communicate with the database. Database definitions (DDL) can be entered using common tools like DBVisualizer, DBeaver, Eclipse, SQuirreL and so on.

SQL/MX DBS automatically provides useful defaults that allows a developer or DBA to define tables, views, indexes and so on without needing to know the specifics of the NonStop SQL filesystem. For example, partitioning of data is automatic: depending on the size of the database, database partitions will be created automatically. But of course, the “brave DBAs” will still have all the detailed DDL configuration parameters at their disposal. Within limits of course, because SQL/MX DBS will not allow users to configure objects on data volumes that are not part of the storage assigned to them.

SQL/MX DBS users don’t even need to have a NonStop (Guardian) user ID and the NonStop admin does not need to take care either. User IDs for DBS can be as simple as an email id, something that unfortunately cannot act as a Safeguard alias. And therefore, SQL/MX DBS adds a translation between the common database user ID and the internal NonStop user ID. It has the additional benefit that users are restricted to only access their data via their own set of connections.

Does this sound simple enough?

Let’s consider the following use case and think what it would take for a NonStop system administrator to allow a Linux database developer to run a little POC sprint on NonStop SQL/MX.  With DBS, the system administrator would set up the database in less than two minutes. The developer is able to download the appropriate JDBC or ODBC drivers directly from the database server. And make a connection to the database and create the first table using standard SQL create commands.

Once the developer has finished the work, the environment can be removed and returned to the DBS resource pool with a simple command, either by the developer or by the system administrator. Removal is as just as easy and quickly as deploying a database.

How is this different from setting up a dedicated set of virtual machines to run a private NonStop system? SQL/MX DBS is a multi-tenant database where the tenants share the hardware, which may be virtualized of course, plus the system- and database software. It therefore avoids database sprawl, where data stores are appearing in an uncontrolled way. In addition, it allows centralized services such as backup, recovery and even multi-site Business Continuity services.

This may be a little too much for the developer user case I described in this article, but who knows what users may do once they got used to “Database as a Service” with NonStop SQL/MX!

Installation of SQL/MX DBS is very simple if SQL/MX is already installed. There is no additional software required and only needs a little configuration and some dedicated storage volumes.

I explain the process in a 12-minute video on my YouTube channel which can be found at https://www.youtube.com/channel/UCPFo-_xTLaYPVXiHDOrgAlg

A dedicated manual to SQL/MX DBS is available on the HPE Support Center at https://hpe.com/info/nonstop-ldocs.

It provides a good overview of the capabilities. For those who like videos for their inspiration, please watch the YouTube channel! And if you have questions, drop me an email.