Function execution based on data locality and securing integration flows

Patent metadata

Field	Value
Publication number	US-11301562-B2
Application number	US-201916661016-A
Country	US
Kind code	B2
Filing date	Oct 23, 2019
Priority date	Oct 23, 2019
Publication date	Apr 12, 2022
Grant date	Apr 12, 2022

Abstract

Some embodiments may be associated with a cloud-based computing environment. A WASM runtime may execute as serverless functions on an entity (VM or container) dynamically selected based on a data store location (associated with data locality and/or gravity). The WASM runtime may include one or more sandboxes each running a WASM module. A database service may access the data store, and the database service may execute on the same entity as the WASM runtime. In some embodiments, an orchestration layer selects the entity based on a default policy or user-defined custom rules in accordance with exposed attributes (CPU load, memory load, read/write mixture, etc.). According to some embodiments, the serverless functions execute in a multi-tenant fashion. Moreover, the WASM runtime process may use instruction set secure enclaves to secure an access host such that, even if a root is compromised, an attacker cannot access a sandbox memory heap.

First claim

The invention claimed is:

1. A system associated with a cloud-based computing environment, comprising:
a Web Assembly (“WASM”) runtime process executing as serverless functions on a Virtual Machine (“VM”) dynamically selected based on a data store location, including:
at least one sandbox running a WASM module;

a database service to access the data store, wherein the database service executes on the same VM as the WASM runtime process; and
an orchestration layer that selects the VM based on a policy that provides:
if a Representational State Transfer (“REST”) API request is for a write query, a function gets executed on a master VM, and
if the REST API request is for a read request, the function gets executed on a standby VM.

2. The system of claim 1 , wherein other WASM runtime processes execute as serverless functions on containers.

3. The system of claim 1 , wherein the selection based on the data store location is associated with at least one of: (i) data locality, and (ii) data gravity.

4. The system of claim 1 , wherein the WASM runtime process further includes:
Structured Query Language (“SQL”) Application Programming Interfaces (“APIs”).

5. The system of claim 4 , wherein the SQL APIs exchange file descriptors with the database service via an in-memory domain socket-listener.

6. The system of claim 4 , wherein the serverless functions use exposed SQL APIs from the WASM runtime process to communicate via Inter-Process Communication (“IPC”) domain sockets.

7. The system of claim 1 , wherein the WASM runtime process further includes:
a dynamic WASM loader associated with local and/or remote persistence.

8. The system of claim 7 , wherein the dynamic WASM loader offers dynamic loading of serverless functions in substantially real-time by changing API mappings to WASM mappings in memory and modifying memory pointers during runtime.

9. The system of claim 7 , wherein the WASM runtime process further includes:
a plurality of sandboxes, each running a Web Assembly System Interface (“WASI”).

10. The system of claim 9 , wherein the serverless functions execute in a multi-tenant fashion.

11. The system of claim 10 , wherein the WASM runtime process uses instruction set secure enclaves to secure an access host such that, even if a root is compromised, an attacker cannot access a sandbox memory heap.

12. The system of claim 11 , wherein the WASM runtime process offers, for each sandbox, system isolation for: (i) a central processing unit, (ii) memory, and (iii) files.

13. The system of claim 12 , wherein the WASM runtime process offers no direct references to function pointers that control the instruction pointer to ensure data integrity.

14. The system of claim 13 , wherein the WASM runtime process prevents access to system calls by default.

15. The system of claim 1 , wherein the policy comprises a default policy.

16. The system of claim 15 , wherein the default policy utilizes round robin load balancing across database VMs.

17. The system of claim 1 , wherein an orchestration layer includes:
a computer processor, and
a memory storage device including instructions that when executed by the computer processor enable the system to:
(i) select the VM for the serverless functions based on user-defined custom rules in accordance with exposed attributes.

18. The system of claim 17 , wherein the exposed attributes are associated with at least one of: (i) a central processing unit load, (ii) a memory load, and (ii) a read/write mixture.

19. A non-transitory, computer readable medium having executable instructions stored therein that, when executed by a computer processor cause the processor to perform a method associated with a cloud-based computing environment, the method comprising:
executing a Web Assembly (“WASM”) runtime process as serverless functions on a Virtual Machine (“VM”) dynamically selected based on a data store location, wherein the WASM runtime process includes at least one sandbox running a WASM module;
accessing the data store by a database service, wherein the database service executes on the same VM as the WASM runtime process; and
selecting, by an orchestration layer, the VM based on a policy that provides:
if a Representational State Transfer (“REST”) API request is for a write query, a function gets executed on a master VM, and
if the REST API request is for a read request, the function gets executed on a standby VM.

20. The medium of claim 19 , wherein other WASM runtime processes execute as serverless functions on containers.

21. The medium of claim 20 , wherein the selection based on the data store location is associated with at least one of: (i) data locality, and (ii) data gravity.

22. A computerized method associated with a cloud-based computing environment, comprising:
executing a Web Assembly (“WASM”) runtime process as serverless functions on a Virtual Machine (“VM”) dynamically selected based on a data store location, wherein the WASM runtime process includes at least one sandbox running a WASM module;
accessing the data store by a database service, wherein the database service executes on the same VM as the WASM runtime process; and
selecting, by an orchestration layer, the VM based on a policy that provides:
if a Representational State Transfer (“REST”) API request is for a write query, a function gets executed on a master VM, and
if the REST API request is for a read request, the function gets executed on a standby VM.

23. The method of claim 22 , wherein other WASM runtime processes execute as serverless functions on containers.

24. The method of claim 22 , wherein the selection based on the data store location is associated with at least one of: (i) data locality, and (ii) data gravity.

Assignees

• Sap Se

Inventors

• Tiwary Mayank
• Mishra Pritish
• Jain Shashank Mohan

Classifications

• G06F9/4552

  Involving translation to a different instruction set architecture, e.g. just-in-time translation in a JVM · CPC title

• G06F2009/4557

  Distribution of virtual machine instances; Migration and load balancing · CPC title

• G06F16/2471

  Distributed queries · CPC title

• G06F16/972 Primary

  Access to data in other repository systems, e.g. legacy data or dynamic Web page generation · CPC title

• G06F9/5083

  Techniques for rebalancing the load in a distributed system · CPC title