Oracle Openworld 2013 Days 3 & 4 : Oracle Cloud, OBIEE and ODI Futures

It's getting to the end of day 4 of Oracle Openworld, with Team Oracle USA coming back from 8-1 down and pulling-off the unlikeliest of comeback victories, and Openworld sessions covering OBIEE, ODI and Oracle Cloud futures. Here's the details:

1) Oracle's Cloud Strategy

Last year Oracle announced a number of cloud initiatives, with database and java cloud service announcements followed by availability later in 2013.  Unlike Amazon's Web Services offering though which basically gave you an open platform for deploying database and web applications (Infrastructure-as-a-service, or "Iaas"), Oracle's offerings last year were designed to be simpler, and offered you a single database schema in the case of the Database Cloud product, and a Java Cloud Service offering a single WebLogic managed server.

The Database Cloud Service only let you access the schema via HTTP and a RESTful API though, because providing SQL*Net access opened up security issues around the database listener, which left you with programmatic calls or uploading data via ApEx and spreadsheet uploads. Similarly, the Java Cloud Service was only really aimed at small applications and websites, and you could imagine building a simple web app using the Java Cloud front-end and the database cloud backend - but this was really PaaS (Platform-as-a-Service) and not something that would really be of interest to BI&DW developers  - as there was no ETL capability and no way to run BI tools such as OBIEE.

In the meantime, organisations (such as ourselves) that wanted to run complete OBIEE, or a complete data warehouse, in the cloud have had to use services such as Amazon AWS, where compute, storage, network and other infrastructure are provided as-a-service, with few restrictions and with billing by the hour. In most cases, these are considered "BYOL" (bring your own license), with the customer providing the license, and also performing all the DBA and sysadmin work - what Amazon do is provide the virtual hardware, and host it for you in their cloud. Once you're there though there are other options around the database - a few weeks ago I covered Amazon Redshift and EnterpriseDB as two alternatives to the Oracle database for cloud-based systems - and pricing for the Amazon AWS service itself is rock-bottom, making it quite an interesting option for customers that don't have a big IT department, or big-company departments looking to spin-up sandbox or short-term development servers.

So Oracle's announcements on Tuesday were very interesting - what they're basically planning to offer is a direct competitor to Amazon AWS albeit Oracle-centric, so that they will in future offer infrastructure-as-a-service (basic compute, storage and networking services), alongside their existing platform-as-a-service; and, as we'll see in a moment, they'll also be offering applications such as OBIEE and their Fusion ERP stack as turnkey cloud applications with credit card sign-ups and consumer-level interfaces - this is Oracle moving full-scale into the cloud. 

As well as this infrastructure-as-a-service offering, their platform-as-a-service database and java offerings will be expanded to now include full database-as-a-service, and a full WebLogic cluster-as-a-service to complement what's now being referred to as schema-as-a-service and java-as-a-service. The full database-as-a-service (DBaas) will provide a full licensed Oracle instance (via the new pluggable database feature in 12cR1), your own listener, SQL*Net access and therefore the ability to ETL into it, but with backups and "tuning" covered in the background by Oracle's staff.

Similarly, the updated WebLogic cloud service will support full WLST access, JMX interfaces and so on, arranged in a WebLogic cluster for high-availability and failover. So this setup will be conceptually similar to Amazon AWS, but run using Oracle software and with platform services designed around the needs of database, and Java application server, software.

No details on pricing and release dates were made in the session, but given last year's releases I'd expect these to be available late summer next year.

2) OBIEE in the Cloud

So following on from the cloud keynote, the OBIEE roadmap session built on this announcement to provide details on their "reporting-as-a-service" offering, based on OBIEE but with a simplified, more consumer-style interface. What this seems to be offering is full OBIEE but with new, web-based tools for building the RPD, and with previews of new capabilities such as data mashups, faster previews of new visualisations, and a new cloud-style look and feel to match the rest of Oracle's new cloud products.

Importantly though, reporting-as-a-service will come with a number of initial restrictions aimed at making the product as self-service and self-provisioning as possible; it's likely that in the first iteration, it'll only connect to the database schema-as-a-service offering, meaning that the only way you'll get data in is via Apex and spreadsheet uploads or more likely, through Java applications you also build in Oracle's platform-as-a-service cloud. Over time, presumably it'll connect to the full DBaaS service making it possible to ETL data in, but for now it's more aimed at departmental solutions and sandbox applications - but it's a very interesting taste of the future.

3) ODI, and Moving to it from OWB

Moving on to today now, Rittman Mead's Stewart Bryson along with Sumit's Holger Friedrich presented alongside Oracle on ODI12c, with the session I attended being all about making the move to ODI from Oracle Warehouse Builder. ODI12c's still in beta and we're on the beta program, so I'll have to be a bit circumspect with what I say on the blog, but in terms of the planned migration path from OWB, the plan from Oracle is that there'll be three stages to a typical customer migration (if they want to migrate, that is):

1. From the first release of ODI12c, it'll be possible to execute and monitor OWB jobs from within ODI, giving you a central place to run and control all of your Oracle ETL jobs

2. Then, shortly afterwards, there'll be a command-line utility for migrating OWB project objects to their ODI equivalent, covering most object types but not process flows and data quality projects, for example

3. And then for all new ETL work, you'd use ODI 12c.

OWB itself will continue to be supported for many years, but the most recent release was the last one. Look out for more details on the blog once ODI 12c goes GA, and as one of the beta testers for the tool itself, and the migration utility, we'll have a lot of advice and experiences to share once we're allowed to talk about it publicly.

So that's it for now - check back tomorrow for the last post in this series, where I'll recap on the week