Wednesday, May 24, 2017

DB2 for z/OS and Data-as-a-Service and Database-as-a-Service

______-as-a-service is all the rage in IT these days, and understandably so -- the "service-ization" of information technology capabilities and interfaces will be transformational; indeed, transformations have already occurred or are underway at many organizations and within many application development and deployment environments. In this blog entry I want to highlight a couple of ______-as-a-service concepts, data-as-a-service (aka DaaS) and database-as-a-service (aka DBaaS), and examine their relevance to DB2 for z/OS. First, a little level-setting terminology clarification is in order.

Data-as-a-service and database-as-a-service -- NOT the same thing

Some folks use the terms "data-as-a-service" and "database-as-a-service" interchangeably, but they do not have the same meaning. The distinction is indicated by the different first words of the terms. When your're talking database-as-a-service, you're talking about the functionality of a database management system, provided as a service. So, what does that mean? Well, it can mean that the database management system in question is deployed in an off-premise cloud environment, but database-as-a-service can also apply to a DBMS that is deployed in an on-premise fashion, and that brings me to what I feel is a very important point: "cloud" doesn't necessarily mean "off-premise," and "off-premise" doesn't necessarily mean "cloud." Take the latter part of this point I just made. For a LONG time, numerous organizations have contracted with various companies (IBM among them) to manage their IT operations. IT outsourcing company X might run organization Y's IT operations out of a data center owned by X. That's off-premise from Y's perspective, but there may be nothing cloudy about the way in which Y's IT operations are managed by X. Similarly, an organization could manage some or all of its IT resources in a cloudy way, even with all the IT resources managed in that way being on-premise. Cloud is about consumption of ______ as a service. To those who consume the service(s) provided, the location of the mechanism of service provision is (or should be) irrelevant.

OK, if database-as-a-service can be implemented in an on-premise way (and again, it can), what kind of services are we talking about, and who consumes those services? Quite often, the consumers are application developers, and the services provided are things like a new schema, or a new database instance, or a data backup or restore operation. More on this a little later on.

While database-as-a-service is concerned with the requisitioning and provisioning of database management system functionality, data-as-a-service is about the programmatic interface to a data server. "Database" is not part of the term because a user, who could be a developer writing a client application, has no need to know (and likely has no desire to know) whether or not a database management system is on the server side of a data request. Many application developers -- even those with strong SQL skills -- see the mechanism by which a data request is serviced (which could be a relational database management system such as DB2 for z/OS) as being part of back-end "plumbing," and plumbing is not their concern. They want a straightforward and consistent interface through which CRUD data services (create, read, update, delete) can be invoked -- an interface that abstracts virtually all of the particulars of the service-providing system. REST (short for REpresentational State Transfer) is one such interface, and in recent years it has become a very popular means of enabling data-as-a-service application architecture.

Data-as-a-service in a DB2 for z/OS context

Responding to the growing preference on the part of application developers for as-a-service interaction with data-providing systems, IBM built a native REST interface into DB2 12 for z/OS, and retrofitted that interface to DB2 11 (via the fix for APAR PI66828). DB2's native REST interface is an extension of the DB2 distributed data facility (DDF), so it leverages existing DDF capabilities such as thread pooling, profile monitoring, workload classification, and accounting and statistics tracing. Another benefit of the DDF tie-in: a SQL statement invoked by way of DB2's REST interface will execute under a preemptible SRB in the DDF address space, making the statement zIIP-eligible (up to 60%).

By way of DB2's REST interface, a single static SQL statement can be exposed in the form of a REST API. Before you start thinking of that "single statement" thing as overly limiting, consider that the single statement can be a call to a DB2 stored procedure (if you decide to make a stored procedure a RESTful service, I'd recommend going with a native SQL procedure, because a native SQL procedure is up to 60% zIIP-eligible when it executes under a DDF preemptible SRB).

In addition to enabling invocation of SQL statements via REST calls, DB2's REST-related capabilities support creation, discovery, management, and securing of SQL-based RESTful services. That functionality becomes more extensive (and more user-friendly) when z/OS Connect front-ends DB2's REST interface (i.e., when DB2 is a REST provider to z/OS Connect); and, z/OS Connect makes all kinds of z/OS-based programmatic assets available to REST clients: not only SQL statements (and stored procedures), but CICS transactions, IMS transactions, WebSphere Application Server for z/OS transactions, and batch jobs, as well.

Database-as-a-service in a DB2 for z/OS context

Quite a lot of work has been going on behind the scenes to provide database-as-a-service capabilities for DB2 for z/OS, and the first fruits of those efforts recently showed up in the form of a pair of DB2 APARs -- more on that in a moment.

Recall my mentioning, early on in this blog entry, that a raison d'etre for an on-premise database-as-a-service implementation could be easy and speedy requisitioning and provisioning of DBMS functions to support the work of application developers. The team within IBM DB2 for z/OS development that is leading the database-as-a-service charge has been focused on precisely that. And so it is that we have new DB2 for z/OS database-as-a-service capabilities that have recently been introduced via the fixes for APARs PI73168 (for DB2 11) and PI73492 (for DB2 12). These APARs leverage the functionality of zOSMF (the z/OS Management Facility), a component of the z/OS operating system that can drive the execution of "workflows" (roughly analogous to what are referred to as "scripts" in the distributed systems world) in response to REST calls. The APARs make available zOSMF workflows that can provide three database functions in an as-a-service manner: creation of a new database, creation of a new schema, and creation of a copy of an existing schema. The latter function, referred to as "schema like" (as in, "create a new schema like that one"), involves using, in addition to z/OSMF, the capabilities of the IBM DB2 Change Management Solution Pack for z/OS, which itself combines the functionality of the IBM DB2 Administration Tool and the IBM Object Comparison Tool.

More DB2 for z/OS database-as-a-service capabilities are being worked on, so watch this space.

All of this is good news for people who support DB2 for z/OS. Making data managed by DB2, and making database functionality provided by DB2, more easily consumable will help development teams to be more agile and more productive in building applications that interact with DB2. Additionally, more fully automating the requisitioning and provisioning of DB2 database management system resources will free DBAs from lots of "blocking and tackling" work around things like setting up new databases and schemas in development environments, and that should enable them to spend more time engaged in higher-value activities like working with developers on the design and architecture of new DB2-accessing applications.

2 comments:

  1. Hey Robert,

    Great blog as always.
    A few questions about the DB-aaS.
    - Are we talking about creating a DB/subsystem on-prem in this context or is it on public cloud(I guess not - but just to be sure. Is there an offering like that at all by the way)?
    - If, say I want to migrate over to Db2 z cloud, from a 3rd party DB(say IDMS or Supra for eg), for applications running COBOL-CICS, how does the cloud offering look like? For applications running on Mainframe itself, does it really 'feel' like cloud?(like Aurora does on AWS)
    - Also, for these offerings from an MLC perspective, is it any different from running DB2 z on-prem? What would be the cost implications?

    IMHO, there's still a lot on ambiguity on the Mainframe cloud offerings in general.

    I understand this is a rapidly evolving space.
    Would be great if you can shed some more light and any further progress in this space since the time of you writing this blog.

    Thanks in advance.

    Cheers,
    Vibin

    ReplyDelete
    Replies
    1. Apologies for the delay in responding, Vibin.

      There is not, at present, a Db2 for z/OS offering that runs in a public cloud environment. There is an IBM offering called Db2 on Cloud that runs in the IBM Cloud environment (see https://www.ibm.com/cloud/db2-on-cloud). It is based on Db2 for Linux/UNIX/Windows. Because SQL DML (data manipulation language - e.g., SELECT, INSERT, UPDATE, DELETE) is virtually identical for Db2 on Cloud and Db2 for z/OS, Db2 on Cloud looks to an application like Db2, period.

      You could also run Db2 (again, Db2 for LUW) in the IBM Cloud Private infrastructure on your premises (see https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=GMS14039USEN).

      If I had a COBOL-CICS-IDMS (or other z/OS-based DBMS) application environment and wanted to make that more cloud-y, I think I'd want to break the effort into stages to minimize risk, while achieving benefits at each stage. First, I'd migrate the data from IDMS to Db2 for z/OS. With the data in Db2 for z/OS, accessed by COBOL CICS transaction programs, I could further open up data access to clients using a JDBC or ODBC interface, or even REST clients, and those client applications could run in your current infrastructure, or in a private or public cloud infrastructure. If I wanted to have some of the Db2 for z/OS data in a cloud-based instance of Db2, that would be pretty easily done. Another possibility: through IBM's z/OS Connect, CICS-IDMS transactions could be exposed as RESTful services. That would allow you to move data from IDMS to Db2 without changing the interface from the perspective of the REST clients.

      From a specifically Db2 for z/OS perspective, data-as-a-service is primarily about access to Db2 data by way of RESTful services, either by direct access from clients to Db2's REST interface, or to Db2's REST interface through z/OS Connect.

      The Db2 for z/OS database-as-a-service story continues to be developer-focused, with an emphasis on easy requisitioning and automatic provisioning of Db2 database services such as schema creation and alteration, population of development-environment Db2 tables with data, "snap" backups of development-environment Db2 tables and restoration of same, data masking, etc. This functionality is delivered through the REST-enablement of Db2 for z/OS itself and of Db2 for z/OS-related tools, along with IBM-provided templates to help database administrators with design and deployment of automated Db2 database services. This technology is available now.

      If you want more information in this area, feel free to e-mail me at rfcatter@us.ibm.com.

      Robert

      Delete