Surprise, surprise.
Larry Ellison, Oracle’s CEO, may have an issue with the (ab)use of the term “cloud computing” (and frankly it’s very hard to not agree with him) but the rest of his company seems busy preparing to embrace the IT-as-a-service model in a big way.
To be fair, Oracle announced cloud-ready products in September 2008, allowing core products like Database 11g, Fusion Middleware and Enteprise Manager to run inside Amazon EC2.
Oracle itself acts as a cloud hosting provider, opening its Platform for SaaS (the one where CRM on Demand and Argus Safety run) to external developers.
Anyway the company didn’t touch at all the infrastructure layer so far. The corporate FAQ page about the topic simply suggests to look at the Oracle virtualization offering to those customers that are looking to build a private cloud. But the offering is about to become a lot more articulated.
A couple of weeks ago Oracle in fact published a new Cloud Resource Model API on its Oracle Technology Network (OTA).
The document, version 1.0/0.34, seems clear about the plan to release an Infrastructure-as-a-Service (IaaS) cloud computing platform:
The Oracle Cloud API defines an Application Programming Interface (API) to consumers of IaaS clouds based on Oracle’s solution stack.
Where, of course, the Oracle’s solution stack is the Xen-based VM Server virtual infrastructure. The document includes an additional reference to the stack calling it the Oracle Cloud Computing Platform.
The API, which leverages the REST protocol, is designed to allow the following features:
- Browse templates that contain definitions and metadata of a logical unit of service
- Deploy a template into the cloud and form an IT topology on demand
- Perform operations (such as ONLINE, OFFLINE) on the resources
- Take backups of the resources
The described design of the API exposes a number of objects that will be exposed by the Oracle Cloud Computing Platform: cloud, virtual data centers (vDCs), zones, virtual machines (VMs), volumes, archives, virtual networks (vNets), network interfaces, service templates, assembly instances and scalability groups.
The document clarifies that a vDC object is a collection of VMs, and that a zone is a logical segmentation used to define how resources must be assigned:
A zone represents a logical boundary where the resources may reside. For example, a zone can represent a particular geographically location such as Europe Zone, North America Zone, East Asia Zone, and so forth. A zone can also represent characteristics such as high network bandwidth or DMZ secured. Furthermore, a zone can be organizational in nature, such as Financial Department Zone, Testing Zone, Development Zone and so forth.
There should not be any assumption of exclusivity of underlying infrastructures in the zones unless otherwise noted. For example, Zone A and Zone B can be on the same physical network serving two different departments, but their physical infrastructure setup is transparent to cloud users.
The zone SHALL support the union of the service characteristics of the list of the profiles. The relationship 626 between Zone/Profile/Characteristics is:
- Profile contains a list of service characteristics
- Zone is assigned profiles
The document also clarifies that this IaaS cloud will support the standard packaging format OVF.
The most interesting thing anyway is that Oracle submitted this new API to the Distributed Management Task Force (DMTF), exactly like VMware did for its vCloud API and like Rackspace will do for its brand new OpenStack API.
The information comes from William Vambenepe, Architect for the application and middleware management part of Oracle Enterprise Manager.
Vambenepe clarifies that Oracle submitted to the DMTF just a subset of the Cloud Resource Model API:
It is titled the “Oracle Cloud Elemental Resource Model” and is essentially the same as the OTN version, minus sections 9.2, 9.4, 9.6, 9.8, 9.9 and 9.10
…
IaaS goes beyond the scope of the Elemental Resource Model. We’ll need load balancing. We’ll need tunneling to the private datacenter. We’ll need low-latency sub-networks. We’ll need the ability to map multi-tier applications to different security zones. Etc. Some Cloud platforms support some of these (e.g. Amazon has an answer to all but the last one), but there is a lot more divergence (both in the “what” and the “how”) between the various Cloud APIs on this. That part of IaaS is not ready for standardization.
Then there are the extensions that attempt to make the IaaS APIs more application-aware. These too exist in some Cloud APIs (e.g. vCloud vApp) but not others. They haven’t naturally converged between implementations. They haven’t seen nearly as much usage in the industry as the base IaaS features. It would be a mistake to overreach in the initial phase of IaaS standardization and try to tackle these questions. It would not just delay the availability of a standard for the base IaaS use cases, it would put its emergence and adoption in jeopardy.