Going Serverless With Oracle Stored Procedures

Serverless computing promises greater scalability, faster development, more efficient deployment, and lower cost.

But the benefits of going serverless can feel out of reach for companies that rely heavily on Oracle stored procedures: named PL/SQL blocks which perform specific tasks and are commonly used for building complex enterprise applications on top of relational databases.

Exposing stored procedures has traditionally been an arduous and time-consuming task. And conventional solutions tend to lead to a layered and complex architecture that creates challenges at both design time and runtime for serverless functions.

The Challenge: Complexity of the Application Development Framework 

Exposing Oracle stored procedures to other applications as web services has typically resulted in an extremely layered architecture that increases the complexity of the application, leads to reliance on proprietary tools, and increases technical debt. 

That’s because the traditional approach to exposing Oracle Stored Procedures has been to wrap the PL/SQL in a proprietary Oracle Application Development Framework (ADF). Building the ADF Business Service, following the standard “Rules,” involves multiple manual steps, like:

• Creating a Domain layer for Entity Objects

• Defining View Objects

• Defining Query Objects

• Defining business rules and validation

• Binding Business Services with User Interface

This then requires the creation of an XML schema and the use of an XML process to access the ADF business component. 

Teams that have gone down this route have typically found that the development process is slow and manual – even with developers with the specialized skills necessary to expose Oracle stored procedures. Relying on external consultants is costly, both upfront and for ongoing maintenance. And either way, this approach results in proprietary vendor lock-in.

SOA: The Workaround that Brings More Pain

One workaround that enterprises have turned to has been the use of an SOA binding component. But SOA brings its own challenges:

• Handling of data and database schema changes: SOA requires the implementation of a service on top of the stored procedure to account for changes in the underlying database. In practice, organizations often run into various security issues during implementation. This in turn can lead to undocumented message flows, raising a myriad of maintenance concerns. Ultimately, even a small change in the database can bring the whole message train chain to a stop. 

• Complexity: SOA brings its own architectural complexity, typically requiring hundreds of hours, multiple developer teams, multiple checkpoints, manual coding, and manual testing. 

• Performance issues: Of particular concern for serverless deployment, building digital services on top of an SOA can lead to runtime performance challenges. 

How to Go Serverless With Oracle Stored Procedures

The following playbook has helped many organizations relying heavily on an Oracle stored procedures architecture significantly accelerate serverless development, testing, and deployment:

1. Leverage a set of standard APIs to connect directly to the existing trusted data logic layer. Note that database stored procedures often contain hard-to-migrate, sensitive data logic; extending access to databases without considering the stored procedures may risk data integrity. So any connector that’s built must access the data logic layer, allowing secured access to the data while maintaining its validations and integrity. 

2. Expose database stored procedures as REST APIs or JSON protocols. In order to facilitate rapid development, testing, and deployment, the teams responsible for building serverless functions must be able to easily access representations of stored procedures using familiar digital services. 

3. Use a lightweight node.js implementation to bypass the cold start problem. The cold start challenge is one that impacts all teams looking to launch serverless functions, but is particularly daunting for those that rely on legacy architecture (like mainframes) or SOA. That’s because of both the performance challenges that come from the middleware layer and the large function size and slow initialization time of Java-based approaches. Combined with directly accessing the data logic layer of stored procedures, a Javascript implementation can significantly reduce or eliminate the cold start challenge for stored procedures.

Traditional integration methods for enterprises that rely heavily on Oracle stored procedures (both the Oracle ADF and an SOA approach) present design time and runtime obstacles on the path to serverless adoption.

These are exactly the challenges we set out to solve with OpenLegacy Serverless, the first serverless-native hybrid integration platform built for legacy systems. OpenLegacy Serverless offers organizations running Oracle stored procedures a low-code environment to rapidly build, deploy, and run serverless APIs. 

Ultimately, modernizing their approach to digital integration with stored procedures can help these organizations rapidly accelerate function-as-a-service (FaaS) adoption within their organizations.