Code packaging for flexible deployment within multi-tenant systems

Abstract

A multicloud system allows independent software vendors (ISVs) to install software in different ways, such as within the user space of the multicloud system's organizational tenant, within the ISV's space within the multicloud system, or within the multicloud system's own space. The packaging and installation capabilities of the multicloud system enable ISVs to easily specify how their code will be made available to users via the multicloud system, without having to perform the necessary configurations and create different configurations depending on the ISV's required usage.

Description

Technical Field

[0001] This application claims the benefit of, and priority to, the filing date of U.S. Patent Application No. 18 / 104,227, filed on January 31, 2023, entitled "CODE PACKAGING FOR FLEXIBLE DEPLOYMENT WITHIN A MULTI-TENANT SYSTEM", the content of which is hereby incorporated by reference in its entirety for all purposes.

[0002] The present disclosure generally relates to multi-cloud multi-tenant computing systems, and more specifically to the packaging and deployment of code within such multi-cloud systems.

Background Art

[0003] In a multi-cloud system (also referred to as a multi-tenant system (hereinafter, MTS)), different organizations register with the MTS, obtain their own accounts for using the MTS, and this multi-cloud system provides many advantages such as computing flexibility and scalability to its users. However, the MTS architecture is more complex than a conventional single-tenant system and offers more options, so installing new software within the MTS is also more complex than installing it on a single-tenant system. Therefore, it can be a significant burden for third-party independent software vendors (ISVs) that develop software to configure the software to operate properly on the MTS in one of the desired ways among different possible ways.

Brief Description of the Drawings

[0004] Embodiments of the present disclosure will have other advantages and features that will become more readily apparent from the following detailed description and the appended claims in conjunction with the examples of the accompanying drawings.

[0005] [Figure 1]This document illustrates an environment in which the MTS functions as a platform for users to utilize software, based on several embodiments.

[0006] [Figure 2] A simplified diagram of one component of the space in Figure 1 is shown as an example of several embodiments.

[0007] [Figure 3] This sequence diagram illustrates the interactions of various components in Figure 1 when installing and running ISV software using various approaches according to several embodiments.

[0008] [Figure 4] This section illustrates exemplary user interfaces provided by an app store that allows users to identify and purchase software, such as software created by ISVs for use on the MTS shown in Figure 1, according to several embodiments.

[0009] [Figure 5] The following illustrates the steps performed by a packaging module when packaging ISV software for use within the MTS shown in Figure 1, according to several embodiments.

[0010] [Figure 6] The following are examples of steps performed by the installation module in Figure 1 when installing software ("function") within a space for use by a user, according to several embodiments.

[0011] [Figure 7] This is a high-level block diagram illustrating the physical components of a computer used as part or all of the MTS shown in Figure 1, according to one embodiment. [Modes for carrying out the invention]

[0012] The figures and the following description relate to preferred embodiments for illustrative purposes only. It should be noted from the following considerations that alternative embodiments of the structures and methods disclosed herein are readily recognizable as viable alternatives that may be used without departing from the principles of the claims.

[0013] Figure 1 illustrates an environment in which the MTS functions as a platform for users to use software, according to several embodiments. Some of the software that runs on the MTS 100 is produced by one or more ISVs 130 and is run by users via their user devices 110. The software that is run may be stored as an image 152 in an app store 150, which may be part of the MTS 100 or managed separately.

[0014] Network 140 may be any suitable communication network for data transmission. In embodiments such as those illustrated in Figure 1, Network 140 may use standard communication technologies and / or protocols and may include the Internet. In another embodiment, the entity may use custom and / or proprietary data communication technology.

[0015] The MTS100 has an execution subsystem 101 having a set of language runtimes 103 corresponding to a set of languages ​​supported by the MTS100, such as Apex®, Java®, JavaScript®, and C#®. The MTS100 also has a set of spaces 102, which are the logic portions of the MTS that their owners can use to perform operations. The spaces 102 include a set of user spaces for various users of an organization registered as a tenant of the MTS100, a set of ISV spaces for ISVs also registered as tenants, and spaces reserved for the MTS itself. The MTS100 also has a packaging module 104 for packaging software into an executable form on the MTS, and an installation module 106 for installing the packaged software on the MTS. The execution is resilient and scalable, and can provide the running software with as many computing resources (processing, memory, storage, etc.) as needed for its computations.

[0016] Various software, including those from ISV130, can be made available to MTS users in various ways. As a first example, ISV130's software may be installed within a user space belonging to one of the organizations registered as tenants of MTS100, and users of that organization may run the software within that user space. Such an installation essentially provides isolation of software use by one customer organization from use by other customer organizations, as each organization has its own copy of the software and that copy runs within its own user space. On the other hand, such an installation tends to require additional configuration and maintenance, as the ISV130 selling the software may need to customize the software environment for each customer organization purchasing the software. In some embodiments, MTS100 prevents users of an organization from accessing the software code, only granting them the ability to execute the code.

[0017] As a second example, ISV130's software may be installed within its own ISV space in space 102 of MTS100 and run by customer organizations within that ISV space. This type of installation has the advantage of simplifying installation and subsequent maintenance, as only a single installation (within the ISV space) is required, rather than one installation per customer organization. On the other hand, depending on the implementation, such an installation may not provide isolation between organizations unless the ISV's software itself is explicitly designed to provide such isolation, which could expose data from one organization to other organizations using the same software within the ISV space. In this type of installation, the system provides ISV130 with the option to specify the specific geographical areas where the software will be deployed and / or areas where the software will not be deployed.

[0018] As a third example, the ISV130 software may be installed within the MTS space of the MTS100 itself in space 102. The mechanism of the MTS100 provides inter-organizational isolation of software, for example, by running the software within its own process container or other software modules.

[0019] Figure 2 illustrates a simplified diagram of one component of Space 200 within Space 102 in Figure 1, according to several embodiments. Space 200 includes a core partial space 210 for code and other content originating from MTS 100 itself, and a third-party ISV compute partial space 219 for code (referred to here as “functions”) and other content originating from ISV ​​130. The core partial space 210 includes an event manager 218 that responds to events occurring within MTS 100 for the owner of that particular space 102, an application programming interface (API) 214 for calling functions provided by MTS 100, an in-network routing module 216 for sending messages between the core partial space 210 and the ISV compute partial space 219 based on the issuance of events within the core partial space 210 and subscription to those events within the compute partial space, and a controller 212 that provisions the components within Space 200 and ensures that the components are properly connected and functioning.

[0020] The ISV compute portion space 219 contains an ISV function pod 220 for each function. The ISV function pod 220 contains a proxy container 221 that receives requests for the corresponding function and returns the output of the function call. The proxy container 221 contains a proxy source 223 that processes incoming requests for the function, validates the requests, issues access tokens, monitors the health of the function container, issues metrics, and processes the asynchronous request response back to the core. The proxy container also contains a proxy runtime 225 that underlies the proxy source 223, ensuring that the proxy source is functioning correctly. The ISV function pod 220 also contains an ISV function container 222 that handles the execution of the function. Specifically, the ISV function container 222 contains source code 226 created by the ISV (code written by the ISV), a language-specific SDK 227 written in the same language as the source code 226 and using that language to call API 214, and a language-specific runtime 103 that executes the source code 226. Containers 221 and 222 may be implemented using container technology such as Docker® containers.

[0021] During execution, when a specific function is called, the core partial space 210 calls the in-network routing module 216, which makes a request (e.g., via HTTP) to the proxy container 221 in the function pod 220. The proxy 221 calls the function 226 running in the container 222, which makes the necessary calls to the MTS100's functionality by accessing the API 214 using the SDK 227. The output of function 226 is returned to the caller of the function (e.g., via the proxy 221).

[0022] Figure 3 is a sequence diagram that illustrates the interaction of various components of FIG. 1 when installing and executing ISV software in various approaches according to some embodiments. ISV 130 creates software (305) for use on MTS 100 and provides that code to the app store 150 of MTS 100 (310). ISV 130 additionally submits instructions along with the code, and these instructions specify a simple choice of how the software should be installed (e.g., within the user space 102 of the user, or within the space 102 of the ISV itself, or within the space 102 of MTS). The code is stored in the app store 150 and is made available to the users of MTS. The remaining steps in FIG. 3 illustrate three different approaches to the installation and execution of the code, selected based on the instructions provided by the user of ISV 130 who submits the code.

[0023] In one approach, a user (such as an administrator of an organization using MTS 100) purchases the software (330) via the app store 150 via the user device 110. The user who purchases provides instructions that the software should be executed from the user space of the user's organization, and MTS accordingly installs the software within the user space (340). At a later time, the user device 110 (e.g., the device of another user of the organization that purchased the software) requests the execution of the software (345). MTS executes the software within the user space for the organization and returns the results to the user device 110.

[0024] In an alternative approach, ISV130 desires that its software run within its own space on the MTS. (This is suitable, for example, if ISV130 has designed its software to provide appropriate inter-organizational isolation so that data from one organization is not accessible to another organization in any way.) Thus, ISV130 provides an instruction specifying that the software be installed within its own space, and the MTS accordingly installs the software within ISV130's space on the MTS100 (360). When a user of the organization purchases the software (355), the MTS100 also establishes a link to the installed software (360), sets up a trusted connection between the core partial space 210 and the ISV compute partial space 219, and causes calls to the software from the user device 110 to run the software from within the ISV space. At some point later, the user runs the software using the user device 110 (365). The MTS100 then executes the software within the ISV space (for example, after first verifying that the user's organization has purchased the right to use the software) and returns the results to the user device 110.

[0025] In yet another approach, the ISV 130 desires that the software be executed within the MTS's own space on the MTS 100. (This is suitable, for example, when the ISV 130 desires to provide that separation to the MTS 100 since the software itself does not provide inter-organization separation). Thus, the ISV 130 provides an instruction specifying to install the software within the MTS's own space, and the MTS accordingly installs the software within its own space (380). Upon purchase of the software by a user of the organization (385), the MTS 100 also establishes a link to the installed software (390) and causes the software to be executed from within the MTS space by a call to that software from the organization's user device 110. At some later point, the user of the organization uses the user device 110 to execute the software (395). The MTS 100 accordingly executes the software within the MTS space and returns the results to the user device 110.

[0026] Figure 4 illustrates an exemplary user interface provided by an app store that enables users to identify and purchase software produced by ISVs for use on MTS 100, according to several embodiments. The user can search the app store 150 using area 405, for example, by the name of the software. Area 410 provides information about the currently viewed software, and area 415 provides details about pricing. By clicking a user interface element (e.g., a "Get Now" button 420) or selecting in other ways, the user acquires the ability to use the selected software on MTS 100, regardless of how the software is deployed on MTS (e.g., in user space, ISV space, or MTS space). That is, MTS 100 handles the details of properly configuring the software, whether in user space or ISV space, or in any other way specified by ISV 130. (In the example in Figure 3, using the "Get Now" button 420 corresponds to purchase steps 330, 355, and 385.) Therefore, the user does not need to configure the software differently based on the method chosen by ISV130 to make its software available on MTS100.

[0027] Figure 5 illustrates the steps performed by the packaging module 104 when packaging ISV software for use within MTS 100, according to several embodiments. The software code ("function") 505 and other project files are input to the packaging step 510, resulting in metadata 511 describing the function (for example, for use in the app store 150 when displaying the software to a user), and the push 512 of the function source files to a remote build service in the ISV's production space, resulting in an image of the function. Within the ISV's core space 210, the function metadata is assembled and validated, and a reference to the function is created, which is combined with the image of the function stored in the core. The reference to the function enables the integration of the function within other features of MTS 100, such as the UI wizard, integrated development environment (IDE), and language constructs, and is also used to verify the existence of the function and its accessibility to calling components.

[0028] Figure 6 illustrates the steps performed by the MTS100 installation module 106 when installing software ("functions") within space 102 for use by a user, according to several embodiments. The installation process makes the functions available by determining whether the package contains functions (605), and if so, by installing function references to the core, enabling lookups of functions by name, and by exposing an application image and creating a virtual computing environment (e.g., a container) on which the functions can be executed. In some embodiments, different types of functionality, such as procedural code, declarative web components, and declarative flows, can be packaged as functions.

[0029] MTS100 ensures that the installation process satisfies the "ACID" property and rolls back the installation if any part of the installation fails. To do this, it uses the installation status API 610 to evaluate whether there was an error in either the function package or the metadata installation process, and if there is an error, it uses the "abandon installation" API 615 to erase any data from the affected portion of the attempted installation, remove the function image from the local registry, and wipe the computing environment.

[0030] Figure 7 is a high-level block diagram illustrating the physical components of a computer 700 used as part or all of the MTS 100 from Figure 1, according to one embodiment. At least one processor 702 coupled to a chipset 704 is illustrated. Memory 706, a storage device 708, and a network adapter 716 are also coupled to the chipset 704. In one embodiment, the functionality of the chipset 704 is provided by a memory controller hub 720 and an I / O controller hub 722. In another embodiment, memory 706 is directly coupled to the processor 702 instead of the chipset 704.

[0031] The storage device 708 is any non-temporary computer-readable storage medium, such as a hard drive, compact disc read-only memory (CD-ROM), DVD, or solid memory device. The memory 706 holds instructions and data used by the processor 702. The network adapter 716 connects the computer 700 to a local area network or a wide area network.

[0032] As is known in the art, computer 700 may have components different from and / or other components shown in Figure 7. Additionally, computer 700 may lack certain exemplified components. Furthermore, the storage device 708 may be local and / or remote from computer 700 (e.g., embodied within a storage area network (SAN)).

[0033] Computer 700 is adapted to run computer program modules for providing the functions described herein. As used herein, the term “module” refers to computer program logic used to provide a specified function. Thus, modules can be implemented in hardware, firmware, and / or software. In one embodiment, a program module is stored in a storage device 708, loaded into memory 706, and executed by a processor 702.

[0034] Embodiments of entities described herein may include modules other than those described herein and / or different modules. Additionally, functions assigned to modules may, in other embodiments, be performed by other modules or different modules. Furthermore, for clarity and convenience, this description may occasionally omit the term “module.” Other Considerations

[0035] The processes described above can be implemented in various types of computer systems, including multi-tenant computer systems (one type of which is a multi-cloud system). In a multi-tenant computer system, multiple tenants share the use of the computer system but do not have access to or knowledge of each other's data or activities. Each tenant may be a company. For example, one tenant could be a company that employs a sales force where each salesperson uses a client device to manage their sales process. Thus, all users may maintain contact data, lead data, customer follow-up data, performance data, goal and progress data, etc., that are applicable to their personal sales processes.

[0036] In one embodiment, a multitenant computer system implements a web-based customer relationship management (CRM) system. For example, the system includes an application server configured to implement and run a CRM software application, and to provide and receive relevant data, codes, forms, web pages, and other information to and from client devices, and to store and retrieve relevant data, objects, and web page content in a database system. The capabilities described above are part of the CRM software application. The activities being analyzed may be past, present, and future sales transactions.

[0037] In a multi-tenant system, data for multiple tenants may be stored in the same physical database. However, tenant data is typically arranged in such a way that one tenant's data remains logically isolated from the data of other tenants, preventing one tenant from accessing another's data unless such data is explicitly shared. A tenant metadata store stores information that enables the identification of data for different tenants, for example, using an identifier that uniquely identifies each tenant.

[0038] In certain embodiments, the system implements applications other than the CRM application, or applications in addition to the CRM application. For example, the system may provide tenant access to multiple hosted (standard and custom) applications, including the CRM application. According to one embodiment, the system is configured to provide web pages, forms, applications, data, and media content to client devices to support access by client devices as tenants of the system. Thus, the system provides a security mechanism to keep each tenant's data separate, unless that data is shared.

[0039] A multi-tenant system may implement security protocols that keep data, applications, and application usage separate for different tenants. In addition to user-specific and tenant-specific data, the system may maintain system-level data or other data that can be used by multiple tenants. Such system-level data may include industry reports, news, posts, etc., that can be shared among tenants.

[0040] The processes described above may also be implemented in other types of systems, such as client-server systems, mobile technologies and devices, mobile networks, wearable devices, tablets, PCs, software-as-a-services, etc.

[0041] Alternative embodiments are implemented in computer hardware, firmware, software, and / or combinations thereof. The implementation can be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor, and the steps of the method can be executed by a programmable processor that executes a program of instructions to perform a function by acting on input data and producing an output. Embodiments can be advantageously implemented in one or more computer programs executable in a programmable system including a data storage system, at least one input device, and at least one output device, coupled to at least one programmable processor to receive and transmit data and instructions. Each computer program can be implemented in a high-level procedural or object-oriented programming language, or optionally in assembly language or machine language, in which case the language can be compiled or interpreted. Preferred processors include, as an example, both general-purpose microprocessors and special-purpose microprocessors. Generally, the processor will receive instructions and data from read-only memory and / or random-access memory. Generally, a computer includes one or more mass storage devices for storing data files, such devices may include magnetic disks, magneto-optical disks, and optical disks, such as internal hard disks and removable disks. Suitable storage devices for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including, for example, semiconductor memory devices such as EPROMs, EEPROMs, and flash memory devices, magnetic disks, magneto-optical disks, and CD-ROM disks, such as internal hard disks and removable disks. Any of the foregoing may be supplemented by or incorporated into ASICs (Application-Specific Integrated Circuits) and other forms of hardware.

[0042] While the detailed description includes many specific details, these should not be interpreted as limiting the scope of this disclosure, but merely as illustrating different examples. The scope of this disclosure should be understood to include other embodiments not discussed in detail above. Various other modifications, changes, and variations will be made to the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims, which would be obvious to those skilled in the art. Therefore, the scope of the patent rights should be determined by the appended claims and their legal equivalents.

Claims

1. A method implemented in a computer, The app store of a multi-tenant system (MTS) receives code for software created by an independent software vendor (ISV) registered with the MTS, and selections made by the ISV within a graphical user interface (GUI) that specify means for making the code available to customers. The entry for the aforementioned code is stored in the aforementioned app store, The following method, namely, In response to the selection specifying the customer organization installation, Receiving a request from the first customer to acquire the right to use the aforementioned code, Installing the code within the space of the MTS belonging to the first customer, Receiving a runtime request from the first customer to use the functionality of the code, A method of executing code for the function within the space of the MTS belonging to the first customer, In response to the aforementioned selection specifying ISV installation, Receiving a request from the first customer to acquire the right to use the aforementioned code, In response to the aforementioned request, establish a link to the code installed within the MTS space belonging to the ISV, Receiving a runtime request from the first customer to use the functionality of the code, A computer-implemented method comprising, in at least one of the following ways of doing so, executing the code in response to the runtime request via the link, and making the code available to the customer in response to the selection.

2. The following method, namely, In response to the selection specifying the MTS installation, Installing the code within the space of the MTS that belongs to the MTS itself, A computer-implemented method according to claim 1, comprising executing code for the function in the space of the MTS belonging to the MTS, and making the code available to a customer.

3. To provide a customer graphical user interface that includes a user interface element that displays information about the software and indicates that the customer wishes to acquire the software for use in the MTS, The computer-implemented method according to claim 1, further comprising configuring the software to run on the MTS in response to the selection of the user interface elements, in response to the selection by the ISV.

4. A computer-implemented method according to claim 1, further comprising packaging the software for use on the MTS, wherein packaging inputs the software and outputs software metadata, a software image, and a software reference.

5. The computer-implemented method according to claim 1, wherein installing the code within the space of the MTS belonging to the first customer comprises creating a container for the first customer to execute the code.

6. The computer-implemented method according to claim 1, wherein installing the code in the space of the MTS belonging to the first customer allows the first customer to execute the code but does not allow the first customer to view the code.

7. A non-temporary computer-readable storage medium for storing instructions that cause a computer processor to perform the computer-implemented method described in any one of claims 1 to 6.

8. A multi-tenant system (MTS) is Computer processors and A multitenant system comprising a non-temporary computer-readable storage medium that stores instructions causing a computer processor to perform a computer-implemented method according to any one of claims 1 to 6.

9. It is a device, Means for receiving, through the app store of a multi-tenant system (MTS), the code of software created by an independent software vendor (ISV) registered with the MTS, and a selection by the ISV within a graphical user interface (GUI) that specifies means for making the code available to customers. Means for storing an entry for the code in the app store, The following method, namely, In response to the selection specifying the customer organization installation, Receiving a request from the first customer to acquire the right to use the aforementioned code, Installing the code within the space of the MTS belonging to the first customer, Receiving a runtime request from the first customer to use the functionality of the code, A method of executing code for the function within the space of the MTS belonging to the first customer, In response to the aforementioned selection specifying ISV installation, Receiving a request from the first customer to acquire the right to use the aforementioned code, In response to the aforementioned request, establish a link to the code installed within the MTS space belonging to the ISV, Receiving a runtime request from the first customer to use the functionality of the code, An apparatus comprising, in at least one of the following ways of performing: executing the code in response to the runtime request via the link, and, in response to the selection, means for making the code available to the customer.

Images