As Autonomous Database services have launched over the past 2 years, I’ve been often asked by customers, “will the Autonomous Database features become available to on-premises deployments?”
The answer is yes, but with a large caveat. Actually, the question itself is slightly misguided and made me realize that some fundamentals seem to be missing from the Autonomous Database dialog.
To clarify, we must first consider that there is a big difference between a database and a database service. The Autonomous Database is a service, it’s much more than a database.
A Database is software technology in a bundled set of binaries licensed and installed by a customer onto a predetermined set of infrastructure (compute, storage and network). Once installed, the customer is responsible for all aspects of the database operation, including dealing with optimal workload configuration, the availability and expansion of physical resources like storage for data, taking backups of the database for regulatory and recovery purposes, the availability of the database in the face of hardware and software level failures, updating the software to get new features or patch software flaws, addressing security concerns like protecting access to the data, etc.
On the other hand, a Database Service is not only database software technology, but a set of integrated capabilities designed to use automation to enhance the customer experience of using a database in an end to end solution. A Database Service transfers many responsibilities involved in operating the database to the service provider. An obvious example being that not every customer must install a database (or even create one for that matter), rather the service provider has automated access so new databases can be available for use in minutes instead of hours or even days. Another example being that a customer no longer must download and install software maintenance updates, rather they can simply be scheduled or initiated on demand and the service provider automation takes care of all the dirty work to get the update completed. Database Services provide capabilities beyond database operations, they can include solution components like identity management, resource governance and operational notification services, just to name a few. Also, at Oracle, the Database Services have additional data management capabilities built-in like deep monitoring, data modeling tools, data visualization, low code development environments, an array of additional value add that surrounds “the database”. This is in essence what customers of Oracle’s Co-Managed Database Services have when using Oracle Database Cloud Service (DBCS) or Exadata Cloud Service.
Now, the question is what makes an Autonomous Database, a Database Service that is self-driving, self-securing and self-repairing? The answer is that an Autonomous Database includes an additional artificial intelligence (A.I.) software layer, a layer that leverages Machine Learning algorithms and decision making to harden software automation, so it’s proactive rather than reactive and it becomes software rather than people operating the database.
Humans are especially good at abstracting. For example, coming up with a system design for dynamic process monitoring and automation. However, unlike a computer, humans are not good at scanning large quantities of data while looking for divergent patterns. For example, humans are not good at deep packet inspection of flowing zeros and ones in a network routing algorithm. The A.I. layer is a special purpose computer process, efficient and looking at large quantities of data in a way that is impossible for humans. The A.I. layer is comparing what it sees to patterns (commonly referred to as models) in that data, and is then capable of making fast decisions based on past patterns of successful operation as well as anti-patterns, data and patterns that lead to failure. Using an A.I. layer allows to minimize the number of humans in the operating loop, so there is a faster, more repeatable and reliable response to emerging conditions.
The data and patterns being examined by the A.I. layers in an Autonomous Database go well beyond the database operating logs. The data and patterns extend to every aspect of the service including the operating system, hypervisor, compute and storage level metrics, network logs, logs of supporting processes as well as the logs of adjunct functions like modeling and low code development tools.
Even further, a decision made by the A.I. layer may involve some rather complex activities such as the decision to decommission a compute server, put another one in place to handle the old server’s activities, move the software processes to the new server, update networking layers to incorporate the new server in service call routing, etc. These things are possible because the Autonomous Database service is operating in the Cloud where there is an effectively unlimited amount of infrastructure available and an API enabling a software defined infrastructure setup. It is possible to spin up new resources on demand to proactively mitigate any approaching failure condition.
It is also important to note that the data and patterns of importance can be highly influenced by the underlying components of the service, whether that’s a specific version of some software library or a specific vendor and model storage device, memory card, network switch, etc. This is how real machine learning works, it needs a sample data set from a larger (bigger is better) system set to train the models and if the system set changes, the models can become invalid.
So, let’s now revisit the question, “will the Autonomous Database features become available to on-premises deployments”?
From a traditional database deployment perspective, hopefully its clear now, Autonomous Database is a service, it is much more than a database. Much of the additional value add that comes with the service is not available in any on-premises form factor. There is no on-premises notion of a self-service software defined infrastructure, a centralized logging service, a resource governance and operational notification service nor any complete set of highly available tooling that supports the capabilities that surround the database. Finally, the system as a whole, it’s tooling and the A.I. layer depends on both the accessibility of a virtually unlimited set of infrastructure that can be called upon on demand and a set of machine learning patterns (models) that depend on a data set that is specific to the configuration running inside the Oracle Cloud, from the supporting software libraries to the specific vendor hardware running in our Infrastructure as-a Service layer.
Given all of this, the answer to our question for a traditional database deployment is necessarily, No. The large caveat is that Autonomous Database will not become available for traditional on-premises deployments.
So, why then is the answer given at the start of the blog, yes? Well, just when you thought it was all finally understood, let’s talk about non-traditional database deployments. There is a version of Autonomous Database coming to what is called an Oracle Gen 2 Exadata Cloud at Customer service deployment. This is a representative slice of the Oracle Cloud that a customer can host inside their data center, inside their network and behind their own firewall. The Oracle Gen 2 Exadata Cloud at Customer has a light weight design to allow the Autonomous Database A.I. layer and all of the supporting adjunct service capabilities to live and run in the Oracle Cloud, while using the A.I. and Autonomous Database automation to operate the database while it runs on your premises. Only in this specialized extension of the Oracle Cloud to your data center will it be possible to have an Autonomous Database on premises. Keep an eye out for a future blog with more details on this exciting Autonomous Database deployment option.