Contributing Analysts:

David Floyer
David Vellante

Premise

The main theme of this research note is that the Oracle Database Appliance (ODA) is a good example of what we see as a specialized private cloud designed to support Oracle database workloads. It sacrifices flexibility and choice of the individual components of a system and higher cost of hardware for much lower cost of Oracle software licenses, much better operational productivity, improved application programmer productivity and faster time to value for solutions built and deployed on the ODA.

Wikibon believes products like ODA underscore a strong long-term trend in the infrastructure business where increasingly IT operations professionals will trade choice of bespoke hardware components for integration and reduced complexity. Fundamentally, we believe the work of testing, maintaining and updating infrastructure should move from enterprise IT staff to the vendor, creating a win-win disruption with significantly lower costs for both parties.

This research note is designed to support the near and mid-term infrastructure plans for Oracle infrastructure practitioners and DBAs, and better understand the fit of products like ODA relative to other appliances in Oracle’s portfolio.

Key Findings of this Study

The following key points from the research we’ve performed are noteworthy:

  • The Oracle Database Appliance is a specialized, integrated system designed specifically for Oracle database workloads. It is designed as an alternative to “roll-your-own” bespoke component systems;
  • The 3-year cost of a bespoke white box/components approach is 260% higher than using a solution like ODA – which we consider to be a building block of True Private Cloud:
    • Major ODA savings come from: 1) operational support; 2) database license and maintenance costs and 3) application maintenance and testing.
    • Of these, by far, the greatest cost savings come from lowering database license and maintenance costs because consolidating the number of processor cores has a direct effect on reducing license costs.
  • Customers evaluating the business case for ODA should view the degree to which the CAPEX costs can be offset by lower administration costs and reduced ongoing operating expenses;
  • The so-called “soft dollar” benefits of using an appliance like ODA include faster time to deploy applications which, depending on application value can be significant;
  • ODA customers value the “one throat to choke” as with other so-called converged infrastructure. The benefits of simplified updates and patching are greater with ODA because the scope of the product includes the database;
  • ODA is limited in size and can handle many, but not the larger enterprise workloads. We believe Oracle has positioned ODA to minimize overlap and not cannibalize Exadata sales;
  • One recent upgrade is that ODA does not require planned downtime for most updates;  practitioners requiring near-zero planned downtime should evaluate solutions like Oracle Data Guard (as part of Oracle 12c) to facilitate almost all updates and upgrades without planned downtime; for Customers requiring automatic reconnect as part of failover should evaluate solutions like Global Data Services (also part of Oracle 12c) to facilitate this;
  • Customers should note that for high availability Oracle RAC deployments, there is no AWS public cloud database service support.

Wikibon Research Methodology

For this research, Wikibon conducted in-depth interviews with Oracle practitioners, technologists and channel members. As well, in 2014, Wikibon developed an economic model assessing the application development impacts of ODA from an ISV perspective. We’ve extended this financial model to specifically focus on the impact of products like ODA on enterprises. The model derives its inputs from interviews with practitioners and previous Wikibon TCO and business value research we’ve been conducting with our community since inception.

In addition, Wikibon is continually researching cloud infrastructure, technologies and software in support of its public cloud and “True” Private Cloud 10-year forecasts. The public cloud forecast (August 2015) shows that about 30% of enterprise IT spend is expected to be in public cloud by 2026, broken down as SaaS (Software as a Service, 18% of enterprise IT spend), IaaS (Infrastructure as a Service, 8%, and PaaS (Platform as a Service, 4%). Wikibon has defined True Private Cloud to be very similar in functionality as Public Clouds (see section “Defining True Private Cloud” below for a detailed definition). Wikibon is advising practitioners to expect that True Private Cloud, although very small at the moment, is projected to grow to be similar in spending to public cloud deployments over the next ten years.

Wikibon’s cloud research is based on in-depth interviews with both public cloud and private cloud practitioners and vendors, looking at cost and deployment models for different workloads, industries and enterprise sizes. Wikibon concludes that there are many cases where public cloud offers clear advantages with little migration friction (e.g., application development, applications with very high seasonal peaks, big data analytics model development and many others.) Equally, there are many cases where True Private Clouds offer clear advantages (large system-of-record deployments, Oracle database production deployments, systems of intelligence as combination of systems of record and inline analytics, and many others). Given the much higher friction in converting from on-premises infrastructure to public cloud, together with constraints on data migration and compliance for many workloads, Wikibon believes that both public and True Private Clouds will dominate IT expenditure, with traditional, roll-your-own IT infrastructure being squeezed by the growth of both models.

Wikibon chose the ODA as one of the most advanced platforms on the market today that exhibits most of the True Private Cloud features as we’ve defined them. Wikibon expects that the majority of converged system vendors will conform to True Private Cloud appliances in 2016 and beyond.

Oracle’s Appliance Strategy and the Fit with True Private Cloud

Oracle is building specialized appliances that are targeted to specific workloads. Since the original instantiation of Exadata and the subsequent acquisition of Sun Microsystems, Oracle has aggressively built out the industry’s most comprehensive portfolio of what it calls Engineered Systems. While Oracle has been ambitious with its appliance strategy, developing an appliance for virtually every use case, the message from the company is clear– if there’s a problem that’s large enough, Oracle will build an engineered system to attack it. As well, Oracle is directly competing with other infrastructure players by emphasizing the benefits of running Oracle software on Oracle hardware.

Wikibon views Oracle’s appliance strategy as an attempt to provide what we call True Private Cloud systems in that they reduce the heavy lifting associated with infrastructure management and focus value on integration and full stack functionality on which applications can be deployed. Oracle’s private cloud strategy is unique from most other vendors in that it is essentially trying to duplicate its cloud offerings with its on-premises appliance strategy (and vice versa).  With respect to its on-prem appliances, Oracle is moving to take over complete responsibility for:

  • Testing, maintaining and updating of a complete stack;
  • Providing automation, orchestration and ability to deploy self-service;
  • Enabling virtualization of server and storage;
  • Providing links to Oracle public clouds.

While many of these attributes are similarly touted by suppliers of so-called converged infrastructure, Oracle traditionally goes further up the stack into the database and sometimes the application. While Oracle’s approach, by definition, more narrowly defines the value proposition of its appliances (to the Oracle “Red Stack”), Wikibon research shows that systems that go up the stack – closer to the application – will deliver more value over time. To be clear, we believe customers should not envision ODA as a general purpose appliance designed to support a wide range of weverrizontal applications and databases. Rather in our view it should be thought of as an Oracle database-specific system, designed to support customer homegrown and ISV applications running primarily on Oracle. The value for ISVs is covered in previous Wikibon research entitled “The Value of Oracle Database Appliance (ODA) for ISVs“.

Figure 1 – Executive Summary of Business Case for True Private Cloud ODA vs Traditional White Box Deployment
Source: © Wikibon 2016 – See Table 1 in the Footnotes for Detailed Methodology & Assumptions.

Oracle has introduced a spectrum of these machines ranging from Exadata, which we see as a specialized database machine, through the recently introduced Private Cloud Machine for PaaS and IaaS (PCM), which is a more complete on-premises extension of the Oracle Public Cloud that includes a PaaS layer.

ODA is a lower priced database machine designed for departments (especially distributed) and mid-sized organizations that want the benefit of integration but don’t have an Exadata-sized budget.

Figure 1 shows an executive view of the of the business case (see “Case Study: The Business Case for Enterprise ODA” section below for more granular detail) for a high availability Oracle RAC database environment comparing the 3-year costs of a traditional white box deployment (individual components) versus using a True Private Cloud approach with Oracle ODA. It shows that by adopting the principles of public cloud into a private database appliance, the 3-year cost of ODA ($1.1 million) is less than one half (38%) of the cost of a traditional white box approach ($2.8 million). Putting it the other way round, the 3-year cost of a white box is 162% more expensive over 3 years than using a True Private Cloud.

Note: We often get the question: “What about running Oracle in AWS?” In an effort to compare ODA to an AWS public cloud solution built on roll-your-own Oracle components, we found that as of the date of publication of this research, there is no equivalent Oracle RAC database service solution available on AWS that is supported by Oracle and AWS. Even if it were supported, Wikibon believes an AWS public cloud solution would be significantly more expensive over 3 years than an on-premise ODA solution because of three factors: 1) the license costs – Oracle allows licensing by the core on Oracle engineered systems, meaning that it can isolate the cores that are used for the Oracle database. No equivalent facility exists off Oracle platforms (e.g. AWS, VMWare, etc.); 2) migration and maintenance costs – i.e. moving from on-prem Oracle to AWS and owning the updates, patching, etc. would be much more expensive than ODA on-prem; and  3) the need to buy/rent dedicated resources (i.e. hardware, etc.) to ensure performance adds costs.

The Oracle cloud offerings look promising. Although there is currently no offering for an exact ODA replica in the Oracle Public Cloud, customers can construct, within the Oracle cloud offerings, a capability to support ODA environments (e.g., provide a remote site backup). This is not a standard ODA offering, and enterprise users would need to follow normal best practice of become familiar the Oracle cloud services available, understand with how to connect ODA, configure the services required and test the resulting hybrid system.

Defining True Private Cloud

In the past five years, much hype has built around the term Private Cloud. The phrase came from the vendor community in direct response to the ascendency of AWS. However to date, most so-called Private Cloud implementations have fallen short of mimicking public cloud agility.

Wikibon defines True Private Clouds as consisting of four main components:

  1. Highly converged Infrastructure (single source, single update, single handshake and throat to choke);
  2. High virtualization of system resources;
  3. High degree of Orchestration and Automation, including self-service;
  4. Ability to link to public clouds.

Wikibon has publishing an analysis of True Private Cloud vendors in 2015, and a projection of private and public cloud revenues from 2016 to 2026. Wikibon sees the traditional separate hardware and system software markets for server, storage and networking being aggressively squeezed  by public and True Private Cloud deployments.

True Private Cloud Fundamentals

Figure 2 – True Private Database Cloud Topology, a subset of True Private Cloud.
Source: © Wikibon, 2016

Industry terminology ranges from so-called Engineered Systems, to the more commonly used Converged Infrastructure, to the more recent true private cloud. Wikibon generically refers to these systems as Single Managed Entities (SMEs) comprising compute, networking and storage resources in a single system.

Wikibon believes an Oracle practitioner imperative is to reduce non-differentiated infrastructure management by deploying Single Managed Entities as a basis for reducing operational costs and duplicating public cloud economics for Oracle database infrastructure. Figure 2 shows the principle of reducing the number of elements in a True Private Cloud stack (ideally to 1) and reducing the cost of deployment, maintenance and enhancement. (The stack chosen in Figure 2 is a database stack, and the correct terminology is a True Database Private Cloud, a subset of True Private Cloud.) In addition, the costs and time-to- value of system software implementations and upgrades can be significantly reduced, as can the application maintenance, testing and upgrades.

Note: Oracle has announced a number of Enterprise Oracle converged database appliances, ranging from the Oracle SuperCluster to Exadata to Oracle Database Appliance and the recently announced Oracle Private Cloud Machine (PCM). The model used in this research focus only on the Oracle Database Appliance (ODA). Over the course of 2016, we will inform the Wikibon community on our views with respect to other Oracle appliances and where they fit.

Oracle Database Appliance (ODA)

In our opinion, the Oracle Database Appliance (ODA) meets the strict Wikibon definition of a True Private Cloud building block, as shown in Figure 1. The components in the X5-2 latest version of ODA include:

  • Two 2-socket servers, each socket consisting of an 18-core Intel® Xeon® E5 processor;
  • Between 256GB and 768GB of DRAM per server (equal DRAM on each server);
  • One or two storage shelves with 16 3.5-inch 8 TB 7.2K rpm HDDs, a general cache of 4 2.5-inch 400 GB ME SSDs, and 4 2.5-inch 200 GB HE SSDs for database redo logs;
  • Separate mirrored storage for the OS;
  • Pre-installed Appliance Manager;
  • Oracle Linux (Pre-Installed) and Oracle Virtualization (OVM).

The ODA meets the Wikibon single-source part of the definition of a True Private Cloud, with Oracle being the single source for hardware, OS and database, a single update on a quarterly basis, a single contract, a single source for upgrades and a single point for quarterly maintenance and single contact and responsibility for problem resolution.

ODA Virtualization

Virtualization is optionally provided by OVM (Oracle Virtual Machine). Oracle’s OVM implementation is hard partition virtualization (similar to IBM’s LPARs), which allocates cores, memory and virtual disk storage to each partition. It trades the flexibility of on-demand virtualization systems (e.g., VMware, KVM) for the much lower overheads of fixed allocation. This is a sensible approach for more mission critical and expensive database software environments.

OVM meets Wikibon’s definition of highly virtualized system resources for compute and storage and networking. Network virtualization is provided though OVM VLANs, which are supported by ODA. In addition, the ODA appliance pre-configures all the networking parameters to meet Oracle’s database pre-requisites, and requires only a couple of hours of network administration to integrate the ODA into an enterprise IT network environment.

Virtualization using OVM is strongly recommended by Wikibon, not least because it enables easier management of Virtual On-demand Software Licensing, the subject of the next section.

ODA On-demand Software Licensing

One very important ODA feature is on-demand Software Licensing for Oracle 12c or 11g enterprise editions and features, which allows any even number of cores to be licensed. This is available for both virtualized and bare metal implementations.

Oracle does not offer on-demand software licensing on non-Oracle hardware platforms, requiring all the cores on a socket to be licensed. The strategy recommended by Wikibon to minimize software licenses on non-Oracle hardware and virtualization software is to deploy high performance processors with far fewer cores, and utilized flash-only storage.

The Oracle ODA uses 18-core processors, which significantly reduces the cost of compute. Because the cost of the Oracle enterprise licenses (the business case below assumes $76,300 for 2 cores, assuming a 50% discount), the on-demand software licensing feature alone can almost always easily justify the ODA.

ODA Support of Oracle Global Data Services (GDS)

ODA supports Oracle Global Data Services (GDS), an extension to Oracle Active Data Guard in Oracle 12c. GDS extends dynamic scaling beyond a single cluster to across replicated clusters. Recovery is seamless, and does not need  custom connection managers to be configured and tested.

GDS enables replicated databases to be added to the GDS infrastructure dynamically and transparently.  This additional resource capability scales the application workloads on demand. GDS allows this with no change to the application configuration or client connectivity.

This enables three advantages of GDS for ODA:

  1. GDS allows for seamless and optimized failover across ODA’s in the event of a data center outage, without the need to enable connection services;
  2. It allows fail over procedures for all quarterly updates and upgrades to be made dynamically without any interruption to service, including those requiring a full outage on a single ODA – Wikibon recommends close evaluation of these procedures to ensure compliance with RPO and RTO requirements;
  3. It allows ODAs to be daisy-chained with read-only copies of databases, which in some deployments can lead to an ability to extend the number of transactions supported on an ODA complex.

ODA Orchestration and Automation

Oracle provides Integrated Lights Out Manager (Oracle ILOM) which runs on the service processor and provides remote management, support for LDAP, Microsoft Active Directory, and RADIUS.

Oracle Enterprise Manager (OEM) provides the basic framework for what we consider to be True Private Cloud orchestration and automation. There is an OEM plug-in extension for ODA. However, the setup of OEM is the responsibility of the IT department deploying the ODA, usually the database administrator (DBA).

A GDS configuration (see previous section) can be administered by the Oracle Enterprise Manager Cloud Control.

Wikibon users report that remote management is excellent with ODA. However, full orchestration and automation of processes with OEM is not currently provided as (say) a set of templates. This is currently the weakest link component of True Private Cloud deployment of ODA. Wikibon expects this to improve over the next 18 months.

Case Study: The Business Case for Enterprise ODA

The case study is based on the implementation of a database application comparing a traditional white box with a True Private Cloud solution (using ODA as a reference model). Figure 3 shows a detailed breakdown of the cost components of architecting, purchasing, configuring, installing and maintaining two alternative solutions to providing infrastructure for internal applications. The applications use Enterprise Oracle 12c as the database. The high availability and rapid recoverability SLAs are met using Oracle RAC and Active Data Guard features of 12c. A single quarterly update process is assumed. The two solutions compared are:

  1. A traditional white box solution with best of breed components;
  2. A True Private Cloud solution, using ODA as a reference architecture.

Table 1 gives a very detailed breakdown of each step, the assumptions made, and the cost and elapsed time for each step. The estimates were made using in-depth interviews (IDIs) with ODA practitioners and managers. Some of the interviews were conducted in 2014, and some in 2015. The cost figure were updated in 2016. There has been a marked increase in the acceptance of quarterly updating, and an increase in the savings realized with ODA. In general, the more complex the database setup and the more Oracle features utilized, the greater the savings.

Figure 3 – Detailed Business Case for True Private Cloud ODA vs Traditional White Box Deployment
Source: © Wikibon 2016 – See Table 1 and Table 2 in Footnotes for Detailed Methodology & Assumptions.

Figure 3 shows that the percentage savings for:

  • 72% savings for on infrastructure architecture, procurement, installation, configuration & documentation;
  • 67% savings on 3-year infrastructure operational support;
  • 61% savings for database software & maintenance;
  • 67% additional costs for infrastructure hardware and maintenance;
  • Overall a 72% savings on a True Private Cloud database solution with ODA compared to a traditional white box build-and-maintain approach.
Figure 4 – Comparison of Time-to-value for True Private Cloud ODA vs Traditional White Box Deployment
Source: © Wikibon 2016 – See Footnotes for Detailed Methodology & Assumptions in Table 1 and Table 2

Figure 4 show a comparison of the time to value for the two solutions. All the ODA users that Wikibon spoke to praised the speed to deploy. One user said “It used to take us 3 to 6 weeks to fully deploy an Oracle RAC server configuration. Now it is one day, with half a day of sys-admin and two hours of a network specialist.”

Figure 4 shows that the total elapsed time for implementing a Oracle RAC system with Active Data Guard is 32 days. This is nearly 4 times slower than using a True Private Cloud approach using ODA (8.3 days).

Another consistent theme from respondents is the simplification of the jobs to install, manage, update and upgrade database systems. “It has taken away the need for specialized training” was one comment.

Wikibon believes the finding from the case study is strong support for the thesis that true private clouds will move work to be done by vendors that historically has been done by enterprise IT professionals. True private clouds will allow the work to be done quicker, more efficiently and at much lower overall cost.

Conclusions and Recommendations

The Oracle X5-2 meets the Wikibon definition of a True Private Clouds. It offers excellent converged infrastructure covering the hardware through to the database. The virtualization is adequate for general purpose database workloads. A framework for automation and orchestration is in place, but still requires significant IT resources to deploy (albeit much lower than a bespoke roll-your-own approach). The most important cost control element of ODA is the on-demand licensing of Oracle databases. Customers should focus senior management on this aspect of the ODA business case.

The impact of ODA is to reduce time to deploy a solution, and minimizing the operational cost of deploying, maintaining and upgrading application software. The ODA platform is a sound basis for implementing DevOps principles, and of using improved application development constructs.

The Oracle X5-2 ODA is an excellent solution for Oracle development, for deployment of departmental solutions, and for remote office implementations. Many large IT organizations also deploy IDA as a lower-cost and simple way of developing and running applications requiring Oracle.

One disadvantage of ODA is the same as its advantage. “One throat to choke” implies one vendor with the potential for lock-in. The vertical scaling of the ODA servers and storage is limited, which means it cannot cover all the potential use cases for enterprise IT.

However, where suitable, the choice of ODA private cloud is an absolute no-brainer as, relative to bespoke solutions, it can support database workloads at one third the cost. These reduced costs, especially the Oracle license and maintenance costs, are nearly always lower, and the elapsed time for deployment is much reduced.

Action Item:

This study and other Wikibon work shows very clearly that enterprise IT should deliver their software and solutions using True Private Cloud solutions where possible. The reduction in operational costs from reduced testing, lower operational maintenance costs enable both lower IT solution costs and faster time to value for application deployment. Because of the additional integration of the Oracle hardware and database software, and the virtual licensing costs of the Oracle database, the Oracle Database Appliance is very likely to be the lowest cost solution, and give the fastest time-to-value when compared to bespoke component solutions. When the ODA fits the performance requirements of an application, Wikibon recommends enterprises using an Oracle database always include Oracle’s ODA private cloud on the RFP. Senior Enterprise Managers should be pushing and negotiating with Oracle to provide improved orchestration and automation capabilities for ODA.

Footnotes:

Table 1 and Table 2 below give the detailed assumptions and calculations behind Figure 1 and Figure 3 in the body of the report.

Table 1 – Detailed Assumptions and Calculation of the Business Case for True Private Cloud ODA vs Traditional White Box Deployment.
Source: © Wikibon 2016 – See Table 2 in Footnotes for Detailed Oracle Licensing Costs.
Table 2 – Detailed Oracle Licensing Cost and Other Assumptions for the Business Case for True Private Cloud ODA vs. Traditional White Box Deployment, shown in Table 1 above.
Source: © Wikibon 2016