Computer-implemented method, system for deploying resources, and computer-readable medium

Abstract

The present disclosure generally describes methods, software, and systems for using resources in the cloud. An integrated flow (iFlow) is deployed as a resource by a cloud integration system. The resource is assigned to one or more pods by a container orchestration service. The iFlow definition mapped to the resource is copied to the corresponding pod by a pod synchronization agent. A unique label is assigned to each resource by a pod synchronization agent based on the iFlow deployed to the pod. A service is created by the cloud integration system as an endpoint for the resource using rules that redirect calls to one or more pods containing the resource.

Description

Technical Field

[0001] The present disclosure relates to handling load distribution of applications running in a cloud. Background Art

[0002] Some cloud integration systems may have difficulty distributing the load of message exchanges, for example, when too many integration scenarios are running on one runtime node. Existing techniques for distributing integration scenarios to multiple nodes encounter limitations when defining routing information in a dynamic manner. The distribution of integration scenarios can be done in a variety of ways. For example, some traditional systems use a separate runtime such as NGINX or another load balancer to route network applications. Separate instances can be installed in a distributed system, and configurations can be run in separate systems, but this creates a disadvantage that separate systems must be maintained and updated. The use of separate runtimes interferes with the platform and creates some problems that must be solved with additional complexity. Summary of the invention

[0003] The present disclosure generally describes computer-implemented methods, software, and systems for implementing the distribution of integration scenarios in the cloud using technology. A computer-implemented method includes: deploying an integration flow (iFlow) as a resource by a cloud integration system; allocating the resource to one or more pods by a container orchestration service; copying the iFlow definition mapped to the resource to the corresponding pod by a pod synchronization agent; assigning a unique label to the pod based on the iFlow deployed to the pod by the pod synchronization agent; and creating a service as an endpoint of the resource by the cloud integration system using a rule that redirects calls to one or more pods containing the resource.

[0004] Each of the foregoing and other embodiments may optionally include one or more of the following features, either alone or in combination. Specifically, an embodiment may include all of the following features:

[0005] In a first aspect, combinable with any of the foregoing aspects, the method further includes: receiving, by a cloud integration system, a request for a service that calls a specific resource; determining, using rules, a specific pod to which the request is directed; determining, by the cloud integration system, a current load of the pod containing the specific resource; and forwarding the request to a pod with a low load using a unique label.

[0006] In a second aspect, combinable with any of the previous aspects, the low load is based on one or more of central processor unit (CPU) usage or memory usage.

[0007] In a third aspect, combinable with any of the preceding aspects, determining a current load of a pod containing a particular resource is performed by a load balancer.

[0008] In a fourth aspect, combinable with any of the preceding aspects, further comprising maintaining information about resources running on each pod using a pod sync agent.

[0009] In a fifth aspect, combinable with any of the preceding aspects, further comprising performing load balancing of resources running on the pods.

[0010] In a sixth aspect, combinable with any of the preceding aspects, the load balancing uses a container orchestration service to access a Uniform Resource Locator (URL) that exposes an endpoint to the service.

[0011] The details of one or more embodiments of the subject matter of the present specification are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages of the subject matter will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a block diagram of an example environment for deploying resources.

[0013] Figure 2 is a block diagram of an example environment for handling load distribution of applications running in a cloud.

[0014] Figure 3 is a flow diagram of an example method for deploying resources.

[0015] Figure 4 is a flow diagram of an example method for processing a service request.

[0016] Figure 5 is a flow chart of an example method for allocating resources to new or otherwise available pods using a scaling module.

[0017] Figure 6 is a flow chart of an example method for allocating resources to a new pod.

[0018] Figure 7 is a block diagram of an exemplary computer system for providing computing functionality associated with the algorithms, methods, functions, processes, procedures, and programs described in this disclosure. DETAILED DESCRIPTION

[0019] The present disclosure generally describes computer-implemented methods, software, and systems for handling load distribution of applications running in the cloud. For example, these techniques can be used to provide a method for routing requests to applications. These techniques can use services that expose endpoints to the outside and pods that provide runtime instances. One or more resources can be deployed to each pod. The techniques described in this disclosure may include extensible mechanisms, such as adding new resource types. Labels can be used as tags for pod instances, where each label defines a route associated with a service.

[0020] The techniques described in this disclosure can leverage local technologies to solve routing challenges in integration scenarios. For example, the same integration scenario can be deployed to multiple pods, thereby providing horizontal scaling (scaling out) (or load handling) of the integration scenario. From the perspective of the container orchestration service, the integration scenario can be viewed as a resource and can be deployed to one or more pod instances. After the integration scenario is deployed as a resource, a label can be assigned to each pod instance. The label information can be used to identify which pod instance can be used to route the request.

[0021] Advantages resulting from the techniques described in the present disclosure may include the following. Using the techniques provided by the platform means that there is no need to deploy additional runtimes, such as by using NGINX instances. This can reduce maintenance and development work because the platform can simply handle routing. Since each integration flow can be used as an extended platform resource, the platform native structure and application programming interface (Application Programming Interface, API) can be used to manage the integration flow alone. The integration flow can be scaled alone or automatically scaled by the platform. Lifecycle operations (such as creation, deletion, and automatic restart) can be managed in a manner similar to platform resources (such as pods). Concepts such as rolling updates and zero downtime can also be extended to integration flows. Since the integration flow is a virtual resource managed by the platform and is therefore not directly linked to the system resources of the platform, the integration flow can be independently scaled to other system resources, such as pods and virtual machines. Scaling helps to achieve the maximum density of available system resources.

[0022] Figure 11 is a block diagram of an example environment 100 for deploying resources. The environment 100 includes a cloud integration system 102 that can receive requests from a client / request system 104, such as a request to deploy an integration flow (iFlow) and place the iFlow (as a resource) into a pod instance. The client / request system 104 can include any system that sends a request to the cloud integration system 102. For example, the client / request system 104 can include a client 106 used by a user 108. A network 110 can connect the client / request system 104 to the cloud integration system 102. In some embodiments, the network 110 can include some or all of the cloud integration system 102. An interface 111 can receive a request received from the client / request system 104 via the network 110.

[0023] The cloud integration system 102 includes a container orchestration service 112, which is configured to handle the life cycle of the container instance. The cloud integration system 102 can also perform services such as routing, scaling, and API exposure. The cloud integration system 102 can handle the received, deployed iFlow and placed iFlow (as a resource) into the pod instance.

[0024] The routing analysis module 114 can use information associated with the pods to determine which pods will be sent requests. To support load balancing performed by the platform, routing analysis can be used to analyze the traffic on each integration flow and pod. The analysis can generate metrics and make further resource optimizations, such as using container orchestration services to trigger the increase or decrease of integration flows or the transfer of integration flows from one pod to another. The scaling module 116 can determine when to add more pods.

[0025] The API 118 can be provided as an extension or service of the container orchestration service 112. The API can enable pod identification of tagged resources, including supporting queries for different pods and queries to the pod synchronization agent. An example query can be a query to identify the pod at which the resource is running. The API can provide pod transport, including providing a connection to the pod to send the request after identifying where the request will be sent. The endpoint API can be used to manage the location at which external systems can communicate requests.

[0026] The deployed pod / container component 120 may be configured to analyze resources in the pod and generate labels for the resources. The deployed pod / container component 120 includes a data store for deployed resources / iFlows 122 and at least one pod sync agent 124. When the pod identification is sent, the pod sync agent 124 may return a response to the container orchestration service 112. The pod sync agent 124 may also manage information associated with the connection to the return endpoint API.

[0027] Memory 126 includes data storage for iFlow definitions 128 of deployed pods. At least one processor 130 may perform processing functions of cloud integration system 102. For example, at least one processor 130 may execute instructions of interface 111 and container orchestration service 112 (including its components).

[0028] Figure 2 1 is a block diagram of an example environment 200 for handling load distribution of applications running in a cloud. For example, environment 200 may include operations corresponding to environment 100.

[0029] Load balancer 202 can perform load balancing, for example, load balancing of an integration scenario running in a cloud. Load balancer 202 can use a load balancing proxy 204 (e.g., catchall.sap.io / *) to interface with container orchestration service 206. Container orchestration service 206 can be implemented, for example, as container orchestration service 112. Container orchestration service 206 can be implemented at least in part using a service of a relational database management system (RDBMS), which can expose endpoints to service 214 using a uniform resource locator (URL). For example, container orchestration service 206 can expose endpoints 208, 210, and 212 corresponding to services 216, 218, and 220, respectively.

[0030] The service 214 may provide access to the pod 222. The pods 222a-222c may be used as ports or worker sets. The documents 224a-224c may represent an iFlow, and each port may have different labels (e.g., aa, bb, and cc) associated with the resource to which the service 214 provides access (e.g., service 216 "AA" corresponding to label "aa", etc.). The label lists 226a-226c may identify labels for each of the pods 222, thereby identifying the resources. For example, the labels "aa" and "bb" are included in the label list 226a, which are labels for resources running on pod 222a. The pod sync agents 228a-228c in the pods 222a-222c may handle synchronization of the pods 222, respectively, including tracking labels corresponding to resources running on the pods. The pods 222 may be implemented, for example, as a deployed pod / container component 120.

[0031] Figure 3 3 is a flow chart of an example method 300 for deploying resources. The method 300 may be performed by the cloud integration system 102. For clarity, the following description generally describes the process of deploying resources in the cloud. Figure 1 and Figure 2 Method 300 in the context of .

[0032] At 302 , the iFlow is deployed as a resource by the cloud integration system. For example, the iFlow of the resource (which will be labeled as “aa” later) can be deployed by the container orchestration service 112 .

[0033] At 304, resources are allocated to one or more pods by the container orchestration service. For example, the container orchestration service 112 can deploy resources (which will then have a label "aa") to pod 222a.

[0034] At 306, the iFlow definition mapped to the resource is copied to the corresponding pod by the pod sync agent. As an example, the pod sync agent 124 can copy the iFlow definition 128 to the pod 222a.

[0035] At 308, a unique label is assigned to each resource by the pod sync agent based on the iFlow deployed into the pod. For example, the pod sync agent 124 may assign a label "aa" to the resource.

[0036] At 310, a service is created by the cloud integration system as an endpoint for the resource using rules that redirect calls to one or more pods containing the resource. As an example, container orchestration service 112 can create service 216 corresponding to a resource with label "aa".

[0037] In some embodiments, method 300 may also include a load balancing step. For example, load balancing may be used to balance the load of resources running on pod 222. Figure 4 Describe the steps of load balancing.

[0038] Figure 4 4 is a flow chart of an example method 400 for processing a service request. The method 400 may be performed by the cloud integration system 102. For clarity, the following description generally describes the process of Figure 1 and Figure 2 Method 400 in the context of .

[0039] At 402, a request to invoke a service of a particular resource is received by the cloud integration system 102. For example, the cloud integration system 102 may receive a request from a client / requesting system 104 to service a currently running iFlow.

[0040] At 404, the rules are used by the cloud integration system to determine the specific pod to which the request is directed. For example, the cloud integration system 102 may determine that the pod 222 is currently running a resource labeled "aa".

[0041] At 406, the current load of the pod containing the particular resource is determined by the cloud integration system. As an example, the load balancer 222 can determine the load on the pod 222 running the resource labeled "aa". The load can be based on one or more of CPU usage or memory usage.

[0042] At 408, the cloud integration system may use the unique label to forward the request to a pod with a low load. For example, if pod 222b is under a lighter load than other pods 222, load balancer 222 may forward the request to pod 222b.

[0043] Figure 5 is a flow chart of an example method 500 for allocating resources to a new or otherwise available pod using a scaling module. The method 500 may be performed by the cloud integration system 102. For clarity, the following description generally describes the Figure 1 and Figure 2 Method 500 in the context of .

[0044] At 502 , an iFlow is deployed by the cloud integration system as a resource with a scaling factor X. For example, the cloud integration system 102 can deploy the iFlow as one of the deployed resources / iFlows 122 .

[0045] At 504, the iFlow resources are allocated to the X pods by the scaling module. For example, the scaling module 116 may allocate the iFlow to the X pods.

[0046] At 506, the affected resources are allocated by the scaling module to new or other available pods to match the scaling factor. For example, in the event that any pod crash affecting iFlow resources is detected, the scaling module 116 can allocate resources to other pods.

[0047] Figure 6 6 is a flow chart of an example method 600 for allocating resources to a new pod. The method 600 may be performed by the cloud integration system 102. For clarity, the following description generally describes the Figure 1 and Figure 2 Method 600 in the context of .

[0048] At 602 , iFlow is deployed by the cloud integration system as a resource with an auto-scaling factor. For example, the auto-scaling factor may represent an initial number of pods for initial deployment of iFlow by the cloud integration system 102 .

[0049] At 604 , the load and traffic of the single iFlow are analyzed by the route analysis module and scaled to X. For example, the scaling module 116 may determine X after analyzing the traffic on the single iFlow.

[0050] At 606 , the iFlow resources are allocated to the X pods by the scaling module. As an example, the scaling module 116 may allocate the iFlow resources to the X existing pods, updating the deployed pods / containers 120 .

[0051] At 608, the platform scaler in the container orchestration service is triggered by the scaling module to create a new pod. For example, the container orchestration service 112 can be triggered to create a new pod in the deployed pod / container 120.

[0052] At 610, the iFlow resources are allocated to the newly created pod by the scaling module. For example, once a new pod is created, the scaling module 116 can allocate the iFlow resources to the new pod and update the deployed pod / container 120.

[0053] The techniques described in this disclosure can be used to manage integration flows and pass them to a runtime integration engine. The integration flow can replace the dynamic runtime content provided to the corresponding dynamic runtime engine, for example, using the examples listed in Table 1:

[0054]

[0055] Table 1 - Dynamic runtime content and runtime engines

[0056] Figure 7 is a block diagram of an exemplary computer system 700 for providing computing functionality associated with the algorithms, methods, functions, processes, procedures, and programs described in this disclosure.

[0057] The computer 702 shown is intended to cover any computing device, such as a server, a desktop computer, a laptop / notebook computer, a wireless data port, a smart phone, a personal data assistant (PDA), a tablet computing device, one or more processors within these devices, or any other suitable processing device, including physical or virtual instances of computing devices (or both). In addition, the computer 702 may include a computer including an input device, such as a keypad, a keyboard, a touch screen, or other device that can accept user information, and an output device that transmits information associated with the operation of the computer 702, including digital data, visual or audio information (or a combination of information) or a graphical user interface (GUI).

[0058] The computer 702 can act as a client, a network component, a server, a database or other persistence, or any other component of a computer system for performing the subject matter described in the present disclosure (or a combination of roles). The computer 702 is shown communicatively coupled to a network 730. In some embodiments, one or more components of the computer 702 can be configured to operate within an environment, including a cloud-based, local, global, or other environment (or a combination of environments).

[0059] At a high level, the computer 702 is an electronic computing device operable to receive, send, process, store or manage data and information associated with the subject matter. According to some embodiments, the computer 702 may also include or be communicatively coupled to an application server, an email server, a web server, a cache server, a streaming data server, a business intelligence (BI) server or other server (or a combination of servers).

[0060] Computer 702 may receive requests from a client application (e.g., a client application running on another computer 702) via network 730 and respond to the received request by processing the request in an appropriate software application. In addition, requests may also be sent to computer 702 from internal users (e.g., from a command console or through other appropriate access methods), external or third parties, other automated applications, and any other appropriate entity, individual, system, or computer.

[0061] Each component of computer 702 can communicate using system bus 703. In some embodiments, any or all components of computer 702, both hardware or software (or a combination of hardware and software), can use API 712 or service layer 713 (or a combination of API 712 and service layer 713) to interface with each other or interface 704 through system bus 703 (or a combination of both). API 712 can include specifications for routines, data structures, and object classes. API 712 can be independent of the computer language or can be dependent on the computer language and refers to a complete interface, a single function, or even a collection of APIs. Service layer 713 provides software services to computer 702 or other components (whether shown or not) that are communicatively coupled to computer 702. The functions of computer 702 can be accessible to all service consumers using the service layer. Software services such as those provided by service layer 713 provide reusable, defined business functions through defined interfaces. For example, the interface may be software written in JAVA, C++, or other suitable languages, providing data in Extensible Markup Language (XML) format or other suitable formats. Although shown as an integrated component of the computer 702, alternative embodiments may show the API 712 or service layer 713 as an independent component with respect to other components of the computer 702 or communicatively coupled to other components of the computer 702 (whether or not shown). In addition, without departing from the scope of the present disclosure, any or all portions of the API 712 or service layer 713 may be implemented as a child or sub-module of another software module, enterprise application, or hardware module.

[0062] Computer 702 includes interface 704. Although Figure 7 704, but two or more interfaces 704 may be used depending on the specific needs, desires, or specific implementations of the computer 702. The computer 702 uses the interface 704 to communicate with other systems in a distributed environment connected to a network 730 (whether or not shown). Typically, the interface 704 includes logic encoded in software or hardware (or a combination of software and hardware) and is operable to communicate with the network 730. More specifically, the interface 704 may include software that supports one or more communication protocols associated with the communication, so that the network 730 or the hardware of the interface is operable to communicate physical signals within and outside the computer 702 shown.

[0063] Computer 702 includes processor 705. Although Figure 7A single processor 705 is shown in the figure, but two or more processors may be used depending on the specific needs, desires, or specific implementation of the computer 702. In general, the processor 705 executes instructions and manipulates data to perform the operations of the computer 702 and any algorithms, methods, functions, processes, procedures, and programs described in this disclosure.

[0064] The computer 702 also includes a memory 706 that stores data for the computer 702 or other components (whether or not shown) that may be connected to the network 730 (or a combination of both). For example, the memory 706 may be a database that stores data consistent with the present disclosure. Figure 7 A single memory 706 is shown in the figure, but two or more memories may be used depending on the functionality and the particular needs, desires, or particular implementation of the computer 702. Although the memory 706 is shown as an integral component of the computer 702, in alternative implementations, the memory 706 may be external to the computer 702.

[0065] The application 707 is an algorithmic software engine that provides functionality, particularly with respect to the functionality described in the present disclosure, in accordance with the specific needs, desires, or specific implementations of the computer 702. For example, the application 707 may be implemented as one or more components, modules, applications, etc. Furthermore, while illustrated as a single application 707, the application 707 may be implemented as multiple applications 707 on the computer 702. Additionally, while illustrated as being integrated into the computer 702, in alternative implementations, the application 707 may be external to the computer 702.

[0066] There may be any number of computers 702 associated with the computer system containing computer 702 or external to the computer system, each computer 702 communicating via network 730. In addition, the terms "client," "user," and other appropriate terms may be used interchangeably as appropriate without departing from the scope of the present disclosure. In addition, the present disclosure contemplates that many users may use one computer 702, or that one user may use multiple computers 702.

[0067] In some embodiments, the components of the above systems and environments can be any computer or processing device, such as a blade server, a general-purpose personal computer (PC), a Macintosh, a workstation, a UNIX-based workstation, or any other suitable device. In other words, the present disclosure contemplates computers other than general-purpose computers, and computers without traditional operating systems. In addition, the components can be adapted to run any operating system, including Linux, UNIX, Windows, Mac, and the like. Java TM 、Android TM, iOS or any other suitable operating system. According to some embodiments, the component may also include, or be communicatively coupled to, an email server, a web server, a cache server, a streaming data server, and / or (a plurality of) other suitable servers.

[0068] The processors used in the above environment and system can be a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other suitable components. Generally, each processor can run instructions and manipulate data to perform operations of various components. Specifically, each processor can run functions such as sending requests and / or data to components of the environment and receiving data from components of the environment in communications between external, intermediate, and target devices.

[0069] The above components, environment and system may include one or more memories. The memory may include any type of memory or database module, and may take the form of volatile and / or non-volatile memory, including but not limited to magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media or any other suitable local or remote memory component. The memory may store various objects or data (including caches, classes, frameworks, applications, backup data, business objects, jobs, web pages, web page templates, database tables, repositories for storing business and / or dynamic information), and any other appropriate information (including any parameters, variables, algorithms, instructions, rules, constraints) for reference associated with the purpose of the target, intermediate and external devices. Other components within the memory are also possible.

[0070] Regardless of the specific implementation, "software" may include computer-readable instructions on a tangible medium (temporary or non-temporary, as the case may be), firmware, wired and / or programmed hardware, or any combination thereof, which, when executed, are operable to perform at least the processes and operations described herein. In fact, each software component may be written in whole or in part in any suitable computer language (including C, C++, Java, etc.). TM , Visual Basic, Assembler, Any suitable 4GL version and others) written or described. As appropriate, the software may instead include many sub-modules, third-party services, components, libraries, etc. Conversely, as appropriate, the features and functions of various components may be combined into a single component.

[0071] The device may include a computing device such as a smart phone, a tablet computing device, a PDA, a desktop computer, a laptop / notebook computer, a wireless data port, one or more processors within these devices, or any other suitable processing device. For example, the device may include a computer including an input device and an output device, the input device such as a keypad, a touch screen or other device that can accept user information, and the output device transmits information associated with the components of the above-mentioned system and environment, including digital data, visual information or a GUI. The GUI is connected to at least a portion of the above-mentioned system and environment for any suitable purpose (including generating a visual representation of a web browser).

[0072] The accompanying drawings and accompanying descriptions illustrate example processes and computer-implemented techniques. The above environment and system (or their software or other components) may be considered to use, implement or run any suitable technique for performing these and other tasks. It should be understood that these processes are only for illustrative purposes, and described or similar techniques may be performed at any appropriate time, including simultaneous, independent, parallel and / or combined execution. In addition, many operations in these processes may occur simultaneously, concurrently, in parallel and / or in a different order than shown. In addition, as long as the method remains appropriate, the process may have additional operations, fewer operations and / or different operations.

[0073] In other words, although the present disclosure has been described according to certain embodiments and generally related methods, the changes and permutations of these embodiments and methods will be apparent to those skilled in the art. Therefore, the above description of the example embodiments does not limit or constrain the present disclosure. Other changes, substitutions and variations are also possible without departing from the spirit and scope of the present disclosure.

Claims

1. A computer-implemented method comprising: The cloud integration system deploys the integration flow iFlow as a resource; The container orchestration service allocates the resources to one or more pods. The pod synchronization agent copies the iFlow definition mapped to the resource to the one or more pods; The pod synchronization agent assigns a unique label to the resource based on the iFlow deployed in the one or more pods, wherein the unique label identifies the resource; Creating a service by the cloud integration system as an endpoint for the resource using a rule that redirects calls to one or more pods containing the resource; The cloud integration system receives a request for invoking a service of a specific resource; Determining, by the cloud integration system, a specific pod to which to direct the request using the rule by determining, by the cloud integration system, a current load of the pod that contains the specific resource; as well as The request is forwarded using the unique label to a pod having a low load and executing the specific resource tagged with the unique label.

2. The computer-implemented method of claim 1 , wherein: The low load is based on one or more of central processing unit (CPU) usage or memory usage.

3. The computer-implemented method of claim 1 , wherein: Determining the current load of the pod containing the specific resource is performed by a load balancer in the cloud integration system for performing load balancing. 4 . The computer-implemented method of claim 1 , further comprising maintaining, using the pod sync agent, information about resources running on each pod.

5. The computer-implemented method of claim 1 , further comprising performing load balancing of resources running on the pods.

6. The computer-implemented method of claim 5, wherein: The load balancing uses the container orchestration service to access a uniform resource locator URL that exposes an endpoint for the service.

7. A system for deploying resources, the system comprising: A memory storing a table, wherein the table stores the deployed integration flow iFlow and iFlow definition; and A server performs operations including: iFlow is deployed as a resource by the cloud integration system; The container orchestration service allocates the resources to one or more pods. The pod synchronization agent copies the iFlow definition mapped to the resource to the one or more pods; The pod synchronization agent assigns a unique label to the resource based on the iFlow deployed in the one or more pods, wherein the unique label identifies the resource; Creating a service by the cloud integration system as an endpoint for the resource using a rule that redirects calls to one or more pods containing the resource; The cloud integration system receives a request for invoking a service of a specific resource; determining, by the cloud integration system, a specific pod to which to direct the request using the rule by determining, by the cloud integration system, a current load of the pod containing the specific resource; and The request is forwarded using the unique label to a pod having a low load and executing the specific resource tagged with the unique label.

8. The system according to claim 7, wherein: The low load is based on one or more of CPU usage or memory usage.

9. The system according to claim 7, wherein: Determining the current load of the pod containing the specific resource is performed by a load balancer in the cloud integration system for performing load balancing.

10. The system of claim 7, the operations further comprising maintaining, using the pod sync agent, information about resources running on each pod.

11. The system of claim 7, the operations further comprising performing load balancing of resources running on the pods.

12. The system according to claim 11, wherein: The load balancing uses the container orchestration service to access a URL that exposes an endpoint for the service.

13. A non-transitory computer-readable medium encoded with a computer program, the program comprising instructions that, when executed by one or more computers, cause the one or more computers to perform operations comprising: iFlow is deployed as a resource by the cloud integration system; The container orchestration service allocates the resources to one or more pods. The pod synchronization agent copies the iFlow definition mapped to the resource to the one or more pods; The pod synchronization agent assigns a unique label to the resource based on the iFlow deployed in the one or more pods, wherein the unique label identifies the resource; Creating a service by the cloud integration system as an endpoint for the resource using a rule that redirects calls to one or more pods containing the resource; The cloud integration system receives a request for invoking a service of a specific resource; Determining, by the cloud integration system, a specific pod to which to direct the request using the rule by determining, by the cloud integration system, a current load of the pod that contains the specific resource; as well as The request is forwarded using the unique label to a pod having a low load and executing the specific resource tagged with the unique label.

14. The non-transitory computer readable medium of claim 13, wherein: The low load is based on one or more of CPU usage or memory usage.

15. The non-transitory computer readable medium of claim 13, wherein: Determining the current load of the pod containing the specific resource is performed by a load balancer in the cloud integration system for performing load balancing.

16. The non-transitory computer-readable medium of claim 13, the operations further comprising maintaining, using the pod sync agent, information about resources running on each pod.

17. The non-transitory computer-readable medium of claim 13, the operations further comprising performing load balancing of resources running on the pods.

Images