One of the most complex and common enterprise application suites available today is Oracle E-Business Suite (EBS).  EBS is perhaps the poster child representative of ‘stuff that will never be fully refactored’ due to its massive size and complexity – EBS is actually an enormous collection of PL/SQL, Java, miscellaneous code, databases, web applications, business process and functions that are wrapped together in a semi-integrated suite. Nearly every Fortune 1000 company has parts of EBS running somewhere, with a massive ecosystem of Oracle and other 3rd party (usually custom) ancillary processes, programs, feeds, and targets associated with it. It is usually at the center of the business function enterprise application ecosystem and as such generates an enormous amount of data gravity around which the vast majority of the other corporate applications revolve.  EBS is a huge gravity well that keeps most other applications firmly tethered to where it lives.  EBS leverages an n-tier architecture with (currently) over eight hundred different schemas and many thousands of tables.

Realistically EBS may never be successfully fully refactored, but it may (and probably should) eventually be replaced, but… for now, for most organizations — it will remain firmly entrenched until a viable and cost-effective long-term refactoring and/or re-platforming strategy can be designed and implemented.  This leaves only one real option: to migrate EBS into a modern cloud computing paradigm — bring on the Lift and Shift.

The various options for lifting and shifting EBS to the cloud include:

  • OCI on Exadata as a cloud service
  • OCI on non-Exadata platforms
  • Azure with native premium storage
  • Azure with the Silk Cloud Platform

Let’s look at the merits of each of these options.

The current long-term version of EBS s 12.2 R2. This version is will be supported by Oracle until 2031. 

This means that the EBS is not going anywhere for a long while – except maybe – to the cloud. So which cloud, and running on what platform?

OCI Exadata

Oracle Corporation urges organizations to move their enterprise workloads to OCI based Exadata Solutions. This is perhaps an expensive and (in my opinion) possibly a highly problematic solution.  This involves using proprietary hardware that might be aging and may be in constant need of high touch care and attention to keep it operating. Exadata (in our experience) has high overhead no matter where it ends up in the RACI model, but today, in all cases Oracle DEV/Ops themselves are responsible for the firmware, hardware, hypervisor and OS.  As a customer you may be subject to the whims of their internal patching schedule and (repeated) attempts at fixes and maintenance.  

Oracle DBaaS

Oracle’s OCI DBaaS offering is a semi RDBMS/Linux PaaS service that is limited to 48 OCPUs. This significantly limits how large a deployment can be used and, in many cases, it is on the smallish side for true ERP workloads that require a good amount of processing power.

There is no OCI based EBS PaaS service per se but there are some OCI marketplace images that can be deployed. It remains essentially an IaaS based solution with some OCI DB automation for patching and backups.  This would require a lot of manual work to get something equivalent to on-prem EBS up and running on OCI. It is certainly not a PaaS solution.

Azure with Native Disk

Azure has a good story to tell regarding EBS and has published some reference architectures for its implementation. Azure’s approach is to place Oracle workloads on Azure IaaS, which opens up some potential financial savings along with providing architectural flexibility especially when coupled with Silk.

The issue however becomes performance when the operational requirements are high. Native Azure premium disk is still a factor of 10X slower latency than Silk + premium Azure disks and lacks any of the extended functionality that Silk offers. Likewise bandwidth and throughput are multiples better with Silk than Azure Premium.

If the operational limits of premium disk are going to be exceeded – or greater performance is required – Silk is the answer.

Azure, Silk, and EBS

Coupled with Silk, Azure IaaS based Oracle EBS solutions can run at Exadata performance levels without layers and layers of proprietary, failure prone hardware, firmware and software.

What makes EBS databases a good target for Exadata also make it a good target for Silk + Azure. EBS workloads have high memory and CPU demands as well as extreme I/O requirements. Characterizing the EBS workload as demanding is often an understatement.  This makes it an ideal candidate for Silk as well. EBS data intensive batch work benefits from the high IO rates and throughput Silk can provide. Silk’s extremely low sub-millisecond I/O latency boosts OLTP performance and user response time.

Silk also provide snapshot management, zero cost duplication and compression features which will simplify EBS devops procedures and practices as well as optimize costs.  Azure based high end IaaS VM’s coupled with Silk can achieve the functional equivalent of Exadata Performance with a simpler more cost-effective technology stack starting with a Silk Data Pod as the primary performance enhancement.

While in no way mimicking Oracle Exadata performance features, Silk is still able to provide comparable I/O performance at the Oracle instance level for the most demanding workloads – such as EBS. It does this while often providing significant compute and Oracle licensing cost savings.

If using an Azure/IaaS with Silk EBS solution the Oracle database will be single instance with DataGuard failover capabilities designed in from day one. This allows the expensive ( 23k per processor!) RAC license to be avoided.

The Silk/Azure combination based on IaaS gives customers much greater control over their environment than any other model. Since most enterprise workloads ‘come equipped’ with an existing IT support and operations team – IaaS allows you to retain that training and those procedures and those people.

On Azure IaaS with Silk, available large memory and CPU VM shapes can be coupled with Silk data services to provide an extremely performant but cost effective EBS platform.

RAC licensing overhead can be eliminated. Other expensive options such as Advanced Compression and Multi-Tenant might also be eliminated by being replaced with Silk features and functionality. This is especially true with compression, and zero overhead snapshots.

To summarize, Silk provides:

  • Faster Than On-Prem Performance – No throughput limitations with sub millisecond latency
  • No Footprint Inflation – With Silk’s data reduction capability, prevent inflation of your Exadata workloads
  • Control Costs – With zero-footprint clones, you can keep your resources in check and within budget

Conclusion

Oracle EBS workloads are a challenging proposition to effectively and successfully move to the cloud.  An Azure IaaS/Silk based solution will provide high performance, stability and reliability and will also help to optimize cost for cloud resources and licensing costs. Azure and Silk should be one option considered seriously when pondering EBS migration to the cloud.

Get under the hood and learn more about the Silk Cloud Platform architecture here.