Oracle Integration uses more than 10,000 instances of Autonomous Database, managing over 470 TB of data, with no dedicated administrative resources.
“Today we deploy over 10,000 databases managing over 470 terabytes of data and we don’t need a single dedicated database administrator. I sleep better at night knowing I don’t have to worry about the database my service depends on.”
Oracle Integration provides prebuilt connectivity to SaaS and on-premises applications, run-ready process automation templates, and a visual application builder for web and mobile application development. It helps developers and cloud architects connect both SaaS and on-premises applications to address issues that one application alone cannot handle. For example, an organization may want to link an HR application (identifying current employees) with a payroll application (that deposits money into bank accounts). Oracle Integration links those two applications and enables them to work together to solve a business problem.
In the example above you can think of two main constructs or activities. First there are connectors, which enable two applications to communicate in some way. Second, there is orchestration, which automates and coordinates multiple steps in a workflow. Together they enable developers and architects to build out complex business processes.
Underlying that big picture is data, of course. Static metadata captures information about the applications and the data they hold. For example, what is that HR application and what does an “employee” look like in the data store. Runtime metadata captures information about workflows, capturing the state of any actions. Going back to the payroll example, runtime data would be updated to indicate that the payroll application had called HR and was waiting for a response.
The previous Oracle Integration used an earlier version of Database Cloud Service, which required developers to manage and operate all their databases themselves. They wanted to eliminate that work, the additional headcount required, and the management headache that it created.
Why Oracle chose Autonomous Database
The development team chose Autonomous Database for transaction processing and mixed workloads. Since the database now is responsible for all administration, it makes the team more efficient because staffers can focus solely on building their service.
Today Oracle Integration uses over 10,000 unique database instances, manages more than 470 terabytes of data, and in a recent quarter processed over 17 billion messages. Despite the scale of this deployment, all the database administration work is now handled autonomously. The development team has no dedicated DBA headcount. The people who used to handle database administration were reallocated to work on the core service, improving overall efficiency.
The development team is investigating using Autonomous Data Guard, which was not an option with the previous version of the service. This offers a simple path to a disaster recovery solution, which would be valuable for customers.
All database instances are initially deployed without autoscaling enabled. However, the service switches on autoscaling for customers whose usage grows and therefore use a larger proportion of provisioned OCPUs. Doing this ensures that customers continue to experience consistent performance, and are never slowed down by lack of database resources.
Occasionally security or other patches are released that need to be quickly installed. Today the development team can rely on Autonomous Database to get those deployed automatically, which represents a significant savings in both time and management overhead.
The team members building Oracle Integration Cloud are developers first and foremost. They wanted to focus on the service, not on managing the databases that it depends on. Autonomous Database saves having to hire and pay for two full-time administration people, eliminates the need to monitor alarms and other events, and makes the team more efficient.