Leveraging microservice container to provide tenant isolation in multi-tenant API gateway

Abstract

To provide a method of isolating tenants in a multi-tenant application programming interface (API) gateway.SOLUTION: A method hosts APIs for a plurality of different tenants and receives requests from many different client devices. As the requests are received, an associated tenant can be identified, and a router determines if a container instance is available to service the request. The container instance may be an empty container instance including an internal endpoint, a Web server, and a runtime environment. The empty container instance cannot be associated with a particular tenant. To associate the container instance with a tenant, a data store, such as a key-value data store, retrieves configuration files that turn the agnostic container instance into a container instance that is associated with the particular tenant and includes a configuration code to perform the requisite API functions.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 566,422, filed September 30, 2017, U.S. Provisional Patent Application No. 62 / 566,431, filed September 30, 2017, and U.S. Provisional Patent Application No. 62 / 566,435, filed September 30, 2017. The entire disclosures of U.S. Provisional Patent Application Nos. 62 / 566,422, 62 / 566,431, and 62 / 566,435 are incorporated herein by reference, including any appendices. [Background technology]

[0002] background An application programming interface (API) gateway is a platform that allows developers to create and publish APIs for public consumption. It is a fully managed service that allows organizations to easily deploy, maintain, monitor, and secure their APIs. Tenants can define APIs and expose them to these public API gateways, such as cloud platforms, which can then be made available to client devices. In large API gateways, the environment may include a multi-tenant environment, where multiple different tenants host APIs that are made available through the same hosted service. Summary of the Invention [Means for solving the problem]

[0003] overview In some embodiments, a method of isolating tenants using containers to service requests in a multi-tenant environment may include receiving a first request for a first service provided by a first tenant, selecting an empty container in the multi-tenant environment, loading a first configuration implementing the first service into the container, servicing the first request from the container, receiving a second request for a second service provided by a second tenant, flushing the first configuration from the container, and servicing the second request from the container.

[0004] In some embodiments, a non-transitory computer-readable medium includes instructions that, when executed by one or more processors, cause the one or more processors to perform operations including receiving a first request for a first service provided by a first tenant, selecting an empty container in the multi-tenant environment, loading a first configuration implementing the first service into the container, servicing the first request from the container, receiving a second request for a second service provided by a second tenant, flushing the first configuration from the container, and servicing the second request from the container.

[0005] In some embodiments, a system may include one or more processors and one or more memory devices, the one or more memory devices including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including receiving a first request for a first service provided by a first tenant, selecting an empty container in the multi-tenant environment, loading a first configuration implementing the first service into the container, servicing the first request from the container, and receiving a second request for a second service provided by the second tenant, flushing the first configuration from the container, and servicing the second request from the container.

[0006] In any embodiment, any or all of the following features may be included in any combination and without any limitation: The container may be one of a plurality of containers in a multi-tenant environment instantiated to service a request from a client device. The first configuration may include a size of a heap in memory that may be used by the first service. After flushing the first configuration from the container, the container may include a runtime process having an embedded server and an internal endpoint. The internal endpoint may be invoked by a router in the multi-tenant environment to service the second request. The first configuration may include multiple actions that are chained together to service the request. The multi-tenant environment may prevent the container from simultaneously servicing requests associated with different tenants. The multi-tenant environment may allow the container to simultaneously service requests associated with a single tenant. The method / operation may also include receiving a third request for a second service provided by the second tenant and servicing the third request from the container without flushing the second configuration from the container. The first service may include a public API that is made available throughout the multi-tenant environment. [Brief description of the drawings]

[0007] A further understanding of the nature and advantages of the present invention may be realized with reference to the remaining portions of the specification and the drawings. The same reference numerals are used throughout the several drawings to refer to similar components. In some cases, a sub-label is associated with a reference numeral to indicate one of multiple similar components. When a reference numeral is made without specification to an existing sub-label, it is intended to refer to all such multiple similar components. [Figure 1]FIG. 1 is a simplified block diagram of a system for handling requests in a multi-tenant environment, according to some embodiments. [Diagram 2] 1 is a diagram of a container instance 108 prepared to service requests for a tenant, according to some embodiments. [Diagram 3] FIG. 1 is a block diagram illustrating how an empty container instance can be populated with files from a data store, according to some embodiments. [Figure 4] FIG. 2 illustrates how a populated container can service a request according to some embodiments. [Diagram 5] FIG. 1 is a simplified block diagram of a container being returned to a pool of available containers according to some embodiments. [Figure 6A] FIG. 1 illustrates a state diagram of a container's lifecycle in a multi-tenant environment, according to some embodiments. [Figure 6B] FIG. 2 is an alternative state diagram of the lifecycle of a container in a multi-tenant environment, according to some embodiments. [Figure 7] 1 is a flow chart of a method for isolating tenants using containers to service requests in a multi-tenant environment. [Figure 8] 1 is a flowchart of a method for managing runtime state and service configuration for containers in a multi-tenant environment, according to some embodiments. [Figure 9] 1 is a flowchart of a method for efficiently allocating a pool of containers to service requests in a multi-tenant environment, according to some embodiments. [Figure 10] FIG. 1 is a simplified block diagram of a distributed system for implementing some of the embodiments. [Figure 11] FIG. 1 is a simplified block diagram of components of a system environment in which services provided by components of an embodiment system may be provided as cloud services. [Figure 12]FIG. 1 illustrates an example computer system upon which various embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Detailed Description Described herein are embodiments for managing an API gateway. A cloud system can host APIs for multiple different tenants and receive requests from many different client devices. When a request is received, the associated tenant can be identified and a router can determine whether a container instance is available to service the request. A container instance may be an empty container instance that includes an internal endpoint, a web server, and a runtime environment. An empty container instance cannot be associated with a specific tenant. To associate a container instance with a tenant, a data store such as a key-value data store can look up a configuration file that turns an agnostic container instance into a container instance that is associated with a specific tenant and includes configuration code to perform the required API functions. Once the API in the container has finished servicing the request (or multiple requests for a single tenant), runtime state information can be saved back to the data store and the contents of the container instance can be flushed. This ensures isolation between tenant data in a multi-tenant environment while still allowing reuse of containers and efficient management of pooled resources. The data store can maintain a service registry to allow routers in the system to allocate new container instances when needed and deallocate container instances when they are not being used. The data store can also store runtime state information, configurations, and applications for tenant APIs that can be distributed to any container on an on-demand basis.

[0009] 1 is a simplified block diagram of a system for handling requests in a multi-tenant environment, according to some embodiments. An example of an API gateway may be used throughout this disclosure. However, the embodiments described herein are not so limited. Instead, the functionality described for handling requests to an API gateway may be implemented in any system having an interface for receiving requests.

[0010] A number of client devices 102 (e.g., smartphones, laptops, tablet computers, workstations, servers, etc.) can send requests to a public interface 104, which may include a Load Balancer as a Service (LBaaS) interface. These requests may be associated with a particular tenant in a multi-tenant environment and may reference a particular service provided by that tenant, such as an API function. For example, a request received from one of the client devices 102 may include information such as "Tenant:ACME, API:ProcessInvoice." The public interface 104 parses the request. can be fed into one or more routers 106.

[0011] The router 106 can communicate periodically and in real-time with the data store 112 to determine one or more container instances that are assigned to a tenant and can process a particular request. In the example of FIG. 1, a request for Tenant 2 would have three different container instances from which the router 106 can select. Within the set of container instances assigned to Tenant 2, the router 106 can select one or more container instances that are loaded with configurations and / or applications to service the request. For example, the router 106 can select one or more container instances that are loaded with configurations and / or applications to handle the "API:ProcessInvoice" and that have "Tenant 2" loaded with configurations and / or applications to handle the "API:ProcessInvoice". nant:ACME" to select one of the three container instances assigned to it. If no instance has this configuration already loaded, the router 106 can select an existing empty container or instantiate a new empty container. The router 106 can then handle the particular request for "Tenant:ACME". To create a containerized service that can process Invoice data, the data store 112 can be made to transfer the configuration specific to “API:ProcessInvoice” to an existing / new empty container.

[0012] Once the containerized service has handled the request and returned a response (if necessary) to the client device, the containerized service may be reused to service additional requests for that particular tenant / service combination, or the container with its contents flushed may be made available to other tenants. When a container is flushed and reassigned to a different tenant, the runtime information that needs to be saved in the container may be sent back to the data store 112. This ensures that the next time that particular application or API is instantiated in an empty container, the runtime information will be transferred and can be used by the new container to pick up where it left off.

[0013] The registration service 114 can be used to register new tenants into the multi-tenant environment. New tenants can use the registration service 114 interface to create a new tenant entry in the data store 112 and define parameters for their use of the multi-tenant environment. These parameters may include the maximum, minimum, average, and expected number of container instances that will be available to that particular tenant. In addition, the new tenant can select the number and type of routers to service requests, different configuration services that may be available, different configurations of runtime container pools, as well as other aspects of the registration process.

[0014] The configuration service 110 may provide a web-based user interface that allows tenants to define configurations and select applications that may be made available through a public interface. For example, some embodiments may provide a series of web forms and drop-down boxes that allow tenants to select from a number of different microservices, applications, functions, etc. to build an API. Some embodiments may also allow tenants to select executable applications, such as applications for limiting the number of times an API may be called within a predefined time limit. After configurations and applications are selected / defined through the configuration service 110, they may be stored in the data center 112 for placement into empty containers in the system.

[0015] Note that a given gateway can serve more than one tenant simultaneously. In some embodiments, there may be multiple gateways that are completely separate and run on different availability domains or data centers. For example, There may be a gateway for Phoenix, but However, both of these gateways may still serve the same tenant. End users may still deploy APIs to one or any combination of the multiple gateways using a unique gateway ID. In some embodiments, each gateway may have its own unique key-value data store for storing configurations, applications, etc.

[0016] The following diagram illustrates an example of how requests may be processed by the system. These examples are not intended to be limiting. FIG. 2 illustrates a container instance that is prepared to service requests for a tenant, according to some embodiments. 1 illustrates a diagram of a service registry 108. At this stage, the router 106 has already received a request to be serviced. First, the router 106 can work in conjunction with the data store 112 to determine whether an available container instance is running and available to service the request. The data store 112 can include a service registry 214 that catalogs each of the available instances in the system. The service registry 214 can also track which APIs and tenants are assigned to each instantiated container. When new containers are instantiated or existing containers are removed, the service registry 214 can be updated in real time by the data store 112. The router 106 can maintain a local copy of at least a portion of the service registry 214. The data store 112 can continually update the router 106 with a list of changes to the service registry 214. In some embodiments, the data store 112 can update the router 106 with a list of available container instances that can receive the request. In some embodiments, the total list of instances in the system can be very large, so only the changes or a portion of the service registry 214 are sent to the router 106.

[0017] As shown in FIG. 1, some embodiments may include multiple routers 106. One of the routers 106-2 may be designated as a master router. The master router 106-2 may be designated as the only router 106 permitted to instantiate new container instances if necessary. Thus, if a router 106 in FIG. 2 is designated as a master router, it is free to instantiate new container instances if necessary to service requests for a particular tenant. The master router 106-2 may analyze the configuration provided by the tenant during registration to ensure that the number of container instances assigned to the tenant in the pool is within the min / max number for that particular tenant. If one of the routers 106 is handling a request that requires a new container to be instantiated, the router 106-1 may forward the request to the master router 106-2, which may determine whether or not to instantiate a new container. By allowing only the master router 106-2 to instantiate new containers, this helps ensure that the size of the container pool is efficiently managed. For example, if six different routers all receive simultaneous requests for a particular service for a particular tenant, each of these routers could independently decide to instantiate a new container if one instantiated container would suffice. Directing each of these requests to the master router 106-2 ensures that only a minimum number of new containers are instantiated.

[0018] Conversely, if the router 106 and / or data store 112 determine that unused container instances are allocated to a tenant or that unallocated containers are available in the container pool, a determination can be made that one or more of these unused containers can be removed from the system, thereby freeing up memory and processing power for existing containers to operate. This provides a dynamic pool of container instances that can service requests. This pool can grow / shrink dynamically based on how much request traffic is received at any given time. As described below, flushing container contents allows containers to be reused between different tenants while still ensuring that the tenants are isolated from each other.

[0019] One technical advantage achieved by these embodiments is efficient management of the size of a container pool. A runtime pool may be a collection of runtime instances that all share a common characteristic. Runtime instances in a container pool may be a collection of runtime instances that all share a common characteristic. The pools may be numbered consecutively starting with index 0 such that an instance is uniquely identified by a pair of values ​​{pool name, instance index}. Pool management may depend on the particular container environment used by each embodiment. For example, a Java class may be used to implement pool functionality using the Docker daemon REST API to create / start / stop runtime containers as needed. This class may allow the environment to set the pool's name, number of ports, number of debug ports, container state transition timeout values ​​(described in more detail below), etc. Some embodiments may also allow this class to specify a "minimum size" value that represents the number of running container instances not bound to a tenant that will be available to service requests. In addition, a "maximum size" value may specify the maximum number of runtime container instances in the container pool.

[0020] Once a service has been assigned to a container in the gateway, the service may perform a periodic "heartbeat" as an indication to other services that it is alive and functioning properly. For example, when a service is loaded into a container, When a container is downloaded, it may perform a heartbeat to inform the router that it is available to service requests. Performing a heartbeat may include updating a corresponding entry in the service registry of the data store 112. These heartbeat transmissions may be used to determine the lifecycle of the container in the gateway. For example, some embodiments may use a time-to-live (TTL) interval after which the service may be considered inactive. Alternatively, some embodiments may specify the number of heartbeats that are allowed to be skipped / missed before the service is considered inactive. Heartbeats may occur periodically, such as every 10 seconds, 20 seconds, 30 seconds, 60 seconds, etc.

[0021] In the example of Figure 2, the router 106 can identify an empty container 108-3 that is not currently assigned to a particular tenant, or that is assigned to the request's tenant but is not populated with configuration to execute the request's particular API. Note that container 108-1 and container 108-2 are populated with configuration and assigned to particular tenants. Because they operate in separate containers from container 108-3, the data and operations of these three containers can be strictly isolated from each other.

[0022] FIG. 3 shows a block diagram illustrating how an empty container instance may be populated with files from the data store 112, according to some embodiments. Continuing with the example of FIG. 2, an empty container 108-3 may be assigned to handle a request 304 for a particular tenant. First, the container 108-3 may be assigned to that tenant such that requests for other tenants cannot be serviced through the container 108-3. Next, the tenant and API information from the request 304 may be used to look up configuration, application, and runtime information in the data store 112. In some embodiments, the data store 112 may be a key-value data store. Some embodiments may also allow the data store 112 to be distributed on different systems in a multi-tenant environment or across different platforms. For example, the tenant and / or API from the request 304 may be used as a key to look up values ​​in the data store 112 that return the configuration 202, application 204, and / or any runtime state information.

[0023] In some embodiments, the key-value data store 112 may be used to persist tenant-specific configuration to disk. In addition, the key-value data store may be used to persist all running A central service registry 214 may be provided so that all microservices can "register" themselves and other services can locate and invoke them. For example, a distributed key-value data store such as etcd® may be used to store state information such as configuration captured from management services (e.g., policies, APIs, applications, plan metadata, etc.); runtime container state in the service registry 214; container pool configurations (e.g., minimums, maximums, strategies, timeout intervals, etc.); tenant registration status (e.g., tenants, tenant-to-pool bindings, etc.); rate-limiting configurations, real-time state, etc.

[0024] The composition 202 may include a pipeline of actions 206 defined in the composition service 110 of FIG. 1. These actions 206 may be chained together to form an API or other service for processing data. Each of the actions 206 may include receiving a request, parsing a payload in the request, processing the data in the payload, modifying the data in the payload, calling another service to obtain information, writing information to a file or database, and / or generating a response. In some embodiments, the composition 202 can handle multiple requests simultaneously. Thus, a single container populated with the composition 202 can handle multiple requests for that particular API and for that particular tenant. In general, the composition is stateless (e.g., RESTful) and very efficient at processing information and generating responses quickly.

[0025] In addition to returning the configuration 202, the data store 112 can return one or more applications 204 that can be executed in the container along with the API configuration 202. For example, the application 204 may be a bandwidth-limited application that limits the number of times a particular API can be called within a predefined time interval (e.g., only 100 requests per hour can be serviced). In contrast to the configuration 202, the application 204 may require runtime state information to be saved between executions of the application. In FIG. 3, the application 204 may not have been executed in the past, and therefore there may be no state runtime information saved in the data store 112 for the application 204. The container 108-3 here may represent a microservice that is assigned to a single tenant to handle a particular API request. Once the container 108-3 is bound to a tenant, the instance can load all of the new configuration information, such as API definitions, applications, plans, and subscriptions, on demand from the data store 112.

[0026] The empty container may be a software container, such as a Docker container, and the multi-tenant environment may include an orchestrated container platform, such as Kubernetes. Instantiating a new empty container may include creating an empty container from a container image and populating it with a minimum number of software processes that will be common to any configuration used in the system. For example, some embodiments may specify the empty container as a Docker container that includes a runtime environment 212, such as a Java Runtime Environment (JRE), a web server 210, such as an HTTP server, and an internal endpoint 208. The internal endpoint 208 may be exposed to the router 106 and may be used by the router 106 to send requests to the container 108-3. In some embodiments, container environments other than Docker containers may be used. For example, some embodiments may use UNIX processes to start / stop the runtime container.

[0027] When an empty container is populated, the data store 112 stores the configuration 202 and application In one embodiment, the configuration 202, application 204, and / or runtime state 302 may be transferred to the container 108-3. If runtime state data 302 was available in the data store 112, it would also be transferred to the container 108-3. In this case, the runtime state data 302 is generated by the application as it runs and stored in the container 108-3. For example, the application 204 may record the number of requests received within a given time interval. This information may be saved in the runtime state 302 and transferred back to the data store 112 when the container 108-3 is flushed. In general, transferring the configuration 202, application 204, and / or runtime state 302 to an empty but instantiated container 108-3 is a relatively lightweight process that can be performed very quickly and efficiently to handle requests without significant delay.

[0028] FIG. 4 illustrates how a populated container 108-3 can service requests according to some embodiments. The container 108-3 can service any request for this tenant because of the API defined by the configuration 202. In some cases, this may only involve processing a single request that the configuration 202 caused to be forwarded to the container 108-3. In other cases, this may involve processing multiple similar requests for the same tenant that were sent to the router 106. After all of the requests have been processed and a response (if any) has been sent back to the requesting client device, the container 108-3 can become idle or passive. While the container 108-3 is still assigned or bound to a particular tenant, it is not currently being used to process any requests. After a predefined time interval, the container 108-3 can be deallocated from that particular tenant and returned to the pool of available containers 108-3 awaiting assignment to a new tenant with a new configuration.

[0029] Before container 108-3 is flushed and reallocated to a different tenant, any runtime state information 302 generated or updated by applications 204 executed on container 108-3 may be saved to data store 112. Then, when configuration 202 and / or applications 204 are reallocated to a new container to service future requests, the runtime state information 302 may be sent to the different container.

[0030] FIG. 5 illustrates a simplified block diagram of a container 108-3 being returned to the pool of available containers, according to some embodiments. After the runtime state information 302 is transferred back to the data store 112, the configuration 202, the application 204, and / or the runtime state 302 may be flushed from the container 108-3. The empty container 108-3 may now be reassigned by the router 106 to a different tenant to service different API calls. Although only the container 108-3 is illustrated as being empty in FIG. 5, an actual deployment may typically include multiple empty containers. The router 106 may use different strategies to assign requests to one of multiple available empty containers, such as a brute force strategy. As mentioned above, if the container 108-3 is not assigned to a new tenant / API within a predefined time interval, the container 108-3 may be removed from the multi-tenant environment to conserve memory and / or computing resources.

[0031] As described above, the data store 112 facilitates these operations by distributing configuration, applications, and runtime state to the various containers operating in a multi-tenant environment. The data store 112 may also receive configuration information from tenants upon new registration and even at runtime. The data store 112 also maintains a service registry 214 that monitors the state of the container pool at any given time. The data store 112 uses this service registry 214 to communicate with the router 106 to determine when the pool of available containers should grow and / or shrink.

[0032] FIG. 6A illustrates a state diagram of a container's life cycle in a multi-tenant environment, according to some embodiments. In an initial state 602, the container does not exist. In state 604, the container has already been instantiated with a set of processes (e.g., web servers, endpoints, etc.) as described above, but the container is not bound or assigned to a particular tenant and is empty. When servicing a request, the container can enter state 606, where it is bound or assigned to a particular tenant and is populated with configuration, application, and / or runtime state information. State 606 is referred to as active because the container may be actively servicing requests received from the router 106. In state 608, the container may still be bound or assigned to a particular tenant, but is passive in that it is not actively processing requests with its internally stored configuration. After remaining idle for a predetermined time interval, the container may be allocated or unbound in state 610. If the container is no longer bound to a particular tenant, the internal configuration, application, and / or runtime state may be flushed. In some embodiments, an unbound container does not need to flush its internal contents until it is reassigned to a new tenant. If the container is not assigned to a new tenant, the container may be removed at state 612.

[0033] FIG. 6B shows another view of the state diagram from FIG. 6A illustrating the life cycle of a container in a multi-tenant environment, according to some embodiments. In the initial state 602, the container does not yet exist or has already been removed from the container environment. Once a container instance is created, it may be unbound in state 604. If the container is idle for a predefined time interval called the "unbound timeout", the container may be removed from the environment and return to state 602. Alternatively, in state 606, the container may be assigned to a tenant and loaded with configuration, applications, state information, etc. From the bound active state 606, the container may be removed from the environment if the router reduces the size of the pool of containers, thus transitioning back to state 602. The container may also be released from the tenant in state 604, flushing its tenant-specific content and returning it to the unbound pool of containers. Additionally, a bound active container in state 606 may become passive in state 608 if it remains idle without servicing a client request for a predefined time interval called the "idle tenant timeout". From the bound passive state 608, a "passive timeout" interval may expire, transitioning the container from the bound passive container state 608 to an unbound pool of containers in state 604. As long as the container exists, the container lifecycle may transition between states.

[0034] FIG. 7 illustrates a flow chart of a method for isolating tenants using containers to service requests in a multi-tenant environment. The method may include receiving (702) a first request for a first service provided by a first tenant. The method may also include selecting (704) an empty container in the multi-tenant environment. The method may additionally include loading (706) a first configuration implementing the first service into the container. The method may further include servicing (708) the first request from the container. The method may also include receiving (710) a second request for a second service provided by a second tenant. The method may additionally include flushing (712) the first configuration from the container. The method may further include servicing (714) the second request from the container. Some embodiments may include a system including one or more processors and one or more memories for performing these method steps. Other embodiments may include instructions to cause the one or more processors to perform these method steps. The method may include a non-transitory computer readable medium for storing instructions.

[0035] In any embodiment, one or more of the following features may be included in any combination and without any limitation: The container may be one of a plurality of containers in a multi-tenant environment instantiated to service a request from a client device. After flushing the first configuration from the container, the container may include a runtime process having an embedded server and an internal endpoint. The internal endpoint may be invoked by a router in the multi-tenant environment to service the second request. The first configuration may include multiple actions that are chained together to service the request. The multi-tenant environment may prevent the container from simultaneously servicing requests associated with different tenants. The multi-tenant environment may allow the container to simultaneously service requests associated with a single tenant. The method may also include receiving a third request for a second service provided by the second tenant and servicing the third request from the container without flushing the second configuration from the container. The first service may include a public API that is made available throughout the multi-tenant environment.

[0036] It should be understood that the particular steps illustrated in FIG. 7 provide a particular method of isolating tenants from one another using containers to service requests in a multi-tenant environment, according to various embodiments of the present invention. Other orders of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Additionally, individual steps illustrated in FIG. 7 may include multiple sub-steps that may be performed in various orders, as appropriate for the individual step. Additionally, additional steps may be added or removed depending on the particular application. Those skilled in the art will recognize many variations, modifications, and alternatives.

[0037] FIG. 8 illustrates a flow chart of a method for managing runtime state and service configuration for a container in a multi-tenant environment, according to some embodiments. The method may include receiving an indication that a request has been received for a service provided in the multi-tenant environment (802). The method may additionally include identifying a configuration that implements the service, where the configuration is stored in a data store (804). The method may also include sending the configuration to a container in the multi-tenant environment to service the request (806). The method may further include receiving runtime state from the container (808). The method may also include storing the runtime state in a data store and flushing the configuration from the container (810). Some embodiments may include a system including one or more processors and one or more memories that perform these method steps. Other embodiments may include a non-transitory computer-readable medium that stores instructions that cause one or more processors to perform these method steps.

[0038] In any embodiment, one or more of the following features may be included in any combination and without any limitation: The configuration may be provided by a tenant of the multi-tenant environment prior to runtime. The data store may include a key-value data store. The key-value data store may include a distributed key-value data store. The identity of the tenant associated with the service may be a key in the key-value data store, and the configuration and runtime state may be values ​​in the key-value data store. The data store may also store a registry of containers that are available in the multi-tenant environment. As new containers become available in the multi-tenant environment, the data store updates the container registry based on the container registry to update the container registry. One or more routers may be updated.

[0039] It should be appreciated that the particular steps illustrated in FIG. 8 provide a particular method of managing runtime state and service configuration for containers in a multi-tenant environment in accordance with various embodiments. Other orders of steps may also be performed in accordance with alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Additionally, individual steps illustrated in FIG. 8 may include multiple sub-steps that may be performed in various orders, as appropriate for the individual step. Additionally, additional steps may be added or removed depending on the particular application. Those skilled in the art will recognize numerous variations, modifications, and alternatives.

[0040] FIG. 9 illustrates a flow chart of a method for efficiently allocating a pool of containers to service requests in a multi-tenant environment, according to some embodiments. The method may include allocating (902) a plurality of containers to a first tenant in the multi-tenant environment. The method may also include identifying (904) one or more containers in the plurality of containers that are allocated to the first tenant but are not being used by the first tenant. The method may additionally include flushing (906) content of the one or more containers. The method may further include re-allocating (908) the one or more containers to a second tenant in the multi-tenant environment. Some embodiments may include a system including one or more processors and one or more memories that perform these method steps. Other embodiments may include a non-transitory computer-readable medium that stores instructions that cause one or more processors to perform these method steps.

[0041] In any embodiment, one or more of the following features may be included in any combination and without any limitation: After flushing the contents of the one or more containers, the one or more containers do not need to be assigned to any tenant for a first time interval before being reassigned to a second tenant. The method may also include identifying a second one or more containers in the plurality of containers that are assigned to the first tenant but are not being used by the first tenant, determining that there are no other tenants that require the second one or more containers, and removing the second one or more containers from the multi-tenant environment. The method may additionally include determining that the first tenant is receiving more requests than can be serviced by the plurality of containers. The method may further include instantiating a new plurality of containers and allocating the new plurality of containers to the first tenant. The method may also include allocating a container previously assigned to another tenant to the first tenant. A gateway of the multi-tenant environment may reassign the one or more containers to a second tenant in the multi-tenant environment.

[0042] It should be appreciated that the particular steps illustrated in FIG. 9 provide a particular method for efficiently allocating a pool of containers to service requests in a multi-tenant environment, according to various embodiments. Other orders of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the invention may perform the steps outlined above in a different order. Additionally, individual steps illustrated in FIG. 9 may include multiple sub-steps that may be performed in various orders, as appropriate for the individual step. Additionally, additional steps may be added or removed, depending on the particular application. Those skilled in the art will recognize many variations, modifications, and alternatives.

[0043] Each of the methods described herein may be implemented by a computer system. Each of these method steps may be performed automatically by a computer system and / or may be provided with input / output involving a user. For example, a user may provide inputs for each step in the method, and each of these inputs may be in response to a particular output that requests such input, and the output is generated by the computer system. Each input may be received in response to a corresponding requested output. Further, inputs may be received from a user, from another computer system, as a data stream, retrieved from a memory location, retrieved over a network, requested from a web service, etc. Similarly, outputs may be provided to a user, to another computer system, as a data stream, stored in a memory location, transmitted over a network, provided to a web service, etc. In short, each of the method steps described herein may be performed by a computer system and may involve any number of inputs, outputs, and / or requests to and from the computer system that may or may not involve a user. Those steps that do not involve a user may be said to be performed automatically by the computer system without human intervention. Thus, it will be understood in light of this disclosure that each step of each method described herein may be modified to include input and output from a user, or may be performed automatically by a computer system without human intervention, in which case all decisions are made by a processor. Additionally, some embodiments of each method described herein may be implemented as a set of instructions stored on a tangible, non-transitory storage medium to form a tangible software product.

[0044] 10 shows a simplified diagram of a distributed system 1000 for implementing one of the embodiments. In the illustrated embodiment, the distributed system 1000 includes one or more client computing devices 1002, 1004, 1006, and 1008 that are configured to execute and operate client applications, such as web browsers, dedicated clients (e.g., Oracle Forms), etc., over one or more networks 1010. A server 1012 may be communicatively coupled to remote client computing devices 1002, 1004, 1006, and 1008 over network 1010.

[0045] In various embodiments, the server 1012 may be adapted to execute one or more services or software applications provided by one or more of the components of the system. In some embodiments, these services are provided to a client computing device as web-based or cloud services, or under a Software as a Service (SaaS) model. The client applications may be provided to users of the client computing devices 1002, 1004, 1006, and / or 1008. Users operating the client computing devices 1002, 1004, 1006, and / or 1008 may then utilize one or more client applications to interact with the server 1012 to utilize the services offered by these components.

[0046] In the illustrated configuration, the software components 1018, 1020, and 1022 of the system 1000 are shown as being implemented on a server 1012. In other embodiments, one or more of the components of the system 1000 and / or the services provided by these components may also be implemented by one or more of the client computing devices 1002, 1004, 1006, and / or 1008. A user operating a client computing device may then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. Distributed Systems It should be understood that a variety of different system configurations are possible that may differ from 1000. The illustrated embodiment is thus an example of a distributed system for implementing an embodiment system and is not intended to be limiting.

[0047] Client computing devices 1002, 1004, 1006, and / or 1008 may be portable handheld devices (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)), or wearable devices (e.g., Google Glass® head mounted display) running software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS, Windows Phone, Android®, BlackBerry® 10, Palm OS, etc., and providing Internet, email, short message service (SMS), BlackBerry®, or other communications protocols. The client computing devices may be general purpose personal computers, including by way of example personal computers and / or laptop computers running various versions of the Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices may be, by way of example, various GNU / Linux operating systems, such as the Google Chrome OS. The client computing devices 1002, 1004, 1006, and 1008 may be workstation computers running any of a variety of commercially available UNIX or UNIX-like operating systems, including, without limitation, the UNIX operating system. Alternatively, or in addition, the client computing devices 1002, 1004, 1006, and 1008 may be any other electronic device, such as a thin-client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect gesture input device), and / or a personal messaging device, capable of communicating over the network 1010.

[0048] Although the exemplary distributed system 1000 is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, may interact with the server 1012.

[0049] The network 1010 in the distributed system 1000 is a TCP / IP (transmission control protocol / Internet protocol) The network 1010 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially available protocols, including, but not limited to, IEEE 802.11b, IEEE 802.11c, IEEE 802.11d, IEEE 802.11b, IEEE 802.11b, IEEE 802.11c ...c, IEEE 802.11b, IEEE 802.11c, IEEE 802.11c, IEEE 802.11b, IEEE 802.11c, IEEE 802.11c, IEEE 802.11c, IEEE 802.11c, IEEE 802.11b, IEEE 802.11c, IEEE 802.11c, IEEE 802.11c, IEEE 802.11c, IEEE 802.11c. networks, extranets, and public switched telephone networks (PS TN), infrared networks, wireless networks (such as the Institute of Electrical and Electronics (IEEE) 802.11 protocol suite) , Bluetooth, and / or any other wireless protocol. networks), and / or virtual networks, including without limitation any combination of these and / or other networks.

[0050] The servers 1012 may be comprised of one or more general purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable configuration and / or combination. In various embodiments, the servers 1012 may be adapted to execute one or more services or software applications described in the foregoing disclosure. For example, the servers 1012 may correspond to a server for performing the above-described processes according to one embodiment of the present disclosure.

[0051] Server 1012 may run an operating system, including any of those mentioned above, as well as any commercially available server operating system. Server 1012 may also run any of a variety of additional server applications and / or mid-tier applications, including a hypertext transport protocol (HTTP) server, a file transfer protocol (FTP) server, a common gateway interface (CGI) server, a JAVA server, a database server, and the like. Exemplary database servers include those from Oracle, Microsoft, Sybase, IBM (International Business Machines), and the like. Examples of suitable fluoropolymers include, but are not limited to, those commercially available from Microelectronics, Inc.

[0052] In some implementations, the server 1012 may include one or more applications for analyzing and consolidating data feeds and / or event updates received from users of the client computing devices 1002, 1004, 1006, and 1008. By way of example, the data feeds and / or event updates may include, but are not limited to, Twitter feeds, Facebook updates, or real-time updates received from one or more third party information sources and continuous data streams that may include real-time events related to sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like. The server 1012 may also include one or more applications for displaying the data feeds and / or real-time events via one or more display devices of the client computing devices 1002, 1004, 1006, and 1008.

[0053] The distributed system 1000 may also include one or more databases 1014 and 1016. The databases 1014 and 1016 may reside in a variety of locations. By way of example, one or more of the databases 1014 and 1016 may reside on a non-transitory storage medium local to (and / or within) the server 1012. Alternatively, the databases 1014 and 1016 may be remote from the server 1012 and communicate with the server 1012 via a network-based or dedicated connection. In one set of embodiments, the databases 1014 and 1016 may reside on a storage-area network (SAN). Similarly, any necessary files to perform the functions ascribed to the server 1012 may be stored locally on the server 1012 and / or remotely, as appropriate. In one set of embodiments, the databases 1014 and 1016 are adapted to store, update, and retrieve data in response to SQL-formatted commands. The database may include a relational database such as that provided by Oracle.

[0054] 11 is a simplified block diagram of one or more components of a system environment 1100 that may provide services provided by one or more components of an embodiment system as cloud services, according to one embodiment of the disclosure. In the illustrated embodiment, the system environment 1100 includes one or more client computing devices 1104, 1106, and 1108 that may be used by a user to interact with a cloud infrastructure system 1102 that provides cloud services. These client computing devices may be configured to run a client application, such as a web browser, a dedicated client application (e.g., Oracle Forms), or some other application, that may be used by a user of the client computing device to interact with the cloud infrastructure system 1102 to use the services provided by the cloud infrastructure system 1102.

[0055] It should be understood that the illustrated cloud infrastructure system 1102 may have other components than those shown, and the illustrated embodiment is merely one example of a cloud infrastructure system that may incorporate an embodiment of the invention. In some other embodiments, cloud infrastructure system 1102 may have more or fewer components than those shown, may combine two or more components, or may have components in a different configuration or arrangement.

[0056] The client computing devices 1104 , 1106 , and 1108 may be devices similar to those described above for 1002 , 1004 , 1006 , and 1008 .

[0057] Although the exemplary system environment 1100 is shown with three client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, may interact with the cloud infrastructure system 1102.

[0058] Network 1110 may facilitate communication and exchange of data between clients 1104, 1106, and 1108 and cloud infrastructure system 1102. Each network may be any type of network familiar to those skilled in the art capable of supporting data communications using any of a variety of commercially available protocols, including those described above for network 1010.

[0059] The cloud infrastructure system 1102 may include one or more computers and / or servers, which may include those described above for the server 1012.

[0060] In one embodiment, the services provided by the cloud infrastructure system may include numerous services made available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. The services provided by the cloud infrastructure system may be dynamically scaled to meet the needs of its users. A particular instantiation of a service provided by a cloud infrastructure system is referred to herein as a " A cloud service provider's system is referred to as a "service instance." In general, any service that is made available to a user from a cloud service provider's system over a communications network, such as the Internet, is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's system are distinct from the customer's own premises servers and systems. For example, the cloud service provider's system may host an application, and a user may order and use the application on demand over a communications network, such as the Internet.

[0061] In some examples, services in a computer network cloud infrastructure may include protected computer network access to storage, hosted databases, hosted web servers, software applications, or other services provided to users by a cloud vendor or otherwise known in the art. For example, a service may include password-protected access to remote storage on the cloud over the Internet. As another example, a service may include a web-services-based hosted relational database and scripting language middleware engine for private use by networked developers. As another example, a service may include access to an email software application hosted on a cloud vendor's website.

[0062] In one embodiment, cloud infrastructure system 1102 may include a suite of application, middleware and database service offerings that are delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available and secure manner. One example of such a cloud infrastructure system is the Oracle Public Cloud (Oracle Public Cloud) offered by the present assignee. Public Cloud).

[0063] In various embodiments, the cloud infrastructure system 1102 may be adapted to automatically provision, manage, and track customer subscriptions to services offered by the cloud infrastructure system 1102. The cloud infrastructure system 1102 may provide cloud services through different deployment models. For example, the services may be provided under a public cloud model, where the cloud infrastructure system 1102 is owned by an organization that sells the cloud services (e.g., owned by Oracle) and the services are made available to the general public or different industry enterprises. As another example, the services may be provided under a private cloud model, where the cloud infrastructure system 1102 is operated only for a single organization and may provide services for one or more entities within that organization. Cloud services may also be provided under a community cloud model, where the cloud infrastructure system 1102 and the services offered by the cloud infrastructure system 1102 are shared by several organizations in an associated community. Cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0064] In some embodiments, the services provided by the cloud infrastructure system 1102 may be in the Software as a Service (SaaS) category, the Platform as a Service (PaaS) category, the Infrastructure as a Service (IaaS) category, or the Cloud as a Service (Cloud) category. One or more services offered under other categories of services, including hybrid services A customer may order one or more services offered by cloud infrastructure system 1102 via a subscription order. Cloud infrastructure system 1102 then performs processing to provide the services in the customer's subscription order.

[0065] In some embodiments, the services provided by the cloud infrastructure system 1102 may include, without limitation, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall under the SaaS category. For example, the SaaS platform may provide the ability to build and deliver a suite of on-demand applications on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure for providing the SaaS services. By utilizing the services provided by the SaaS platform, customers can utilize applications that run on the cloud infrastructure system. Customers can obtain application services without the need for the customers to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, without limitation, services that provide solutions for sales performance management, enterprise integration, and business flexibility for large organizations.

[0066] In some embodiments, platform services may be provided by the cloud infrastructure system via a PaaS platform. The PaaS platform may be configured to provide cloud services that fall under the PaaS category. Examples of platform services may include, without limitation, services that enable organizations (such as Oracle) to consolidate existing applications on a shared common architecture, and the ability to build new applications that leverage shared services provided by the platform. The PaaS platform may manage and control the underlying software and infrastructure for providing the PaaS services. Customers can obtain the PaaS services provided by the cloud infrastructure system without the customer having to purchase separate licenses and support. Examples of platform services include, without limitation, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), and the like.

[0067] By utilizing the services provided by the PaaS platform, customers can adopt programming languages ​​and tools supported by the cloud infrastructure system as well as control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion Middleware services), and Java cloud services. In one embodiment, the database cloud services may support a shared service deployment model that allows organizations to pool database resources and provide database-as-a-service in the form of a database cloud to customers. The middleware cloud services may provide a platform for customers to develop and deploy various business applications, and the Java cloud services may provide a platform for customers to deploy Java applications in the cloud infrastructure system.

[0068] In a cloud infrastructure system, a variety of different infrastructure services may be provided by the IaaS platform that facilitate management and control of basic computing resources, such as storage, network, and other underlying computing resources, for customers that utilize the services provided by the SaaS and PaaS platforms.

[0069] In an embodiment, cloud infrastructure system 1102 may also include infrastructure resources 1130 for providing resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, infrastructure resources 1130 may include a pre-integrated and optimized combination of hardware, such as servers, storage, and networking resources for running the services offered by the PaaS and SaaS platforms.

[0070] In some embodiments, resources in cloud infrastructure system 1102 may be shared by multiple users and dynamically reallocated per demand. In addition, resources may be allocated to users in different time zones. For example, cloud infrastructure system 1130 may allow a first set of users in a first time zone to utilize resources of the cloud infrastructure system for a certain number of hours, and then allow reallocation of those same resources to another set of users located in a different time zone, thereby maximizing resource utilization.

[0071] In one embodiment, a number of internal shared services 1132 may be provided that are shared by different components or modules of cloud infrastructure system 1102 and by the services provided by cloud infrastructure system 1102. These internal shared services may include, without any limitation, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelist services, high availability, backup and recovery services, services to enable cloud support, email services, notification services, file transfer services, etc.

[0072] In an embodiment, cloud infrastructure system 1102 may provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functionality may include capabilities for provisioning, managing, tracking customer subscriptions received by cloud infrastructure system 1102, and the like.

[0073] In one embodiment, as shown, cloud management functionality may be provided by one or more modules, such as an order management module 1120, an order orchestration module 1122, an order provisioning module 1124, an order management and monitoring module 1126, and an identity management module 1128. These modules may include or be provided using one or more computers and / or servers, which may be general purpose computers, dedicated server computers, server farms, server clusters, or any other suitable configuration and / or combination.

[0074] In an exemplary operation 1134, the client computing devices 1104, 11 A customer using a client device, such as 1106 or 1108, may interact with cloud infrastructure system 1102 by requesting one or more services offered by cloud infrastructure system 1102 and placing a subscription order for one or more services offered by cloud infrastructure system 1102. In an embodiment, a customer may access a cloud user interface (UI), cloud UI 1112, cloud UI 1114 and / or cloud UI 1116, and place a subscription order via these UIs. Order information received by cloud infrastructure system 1102 in response to a customer placing an order may include information identifying the customer and the one or more services offered by cloud infrastructure system 1102 to which the customer intends to subscribe.

[0075] After an order is placed by a customer, order information is received via cloud UI 1112, 1114, and / or 1116.

[0076] At act 1136, the order is stored in an order database 1118. The order database 1118 may be one of several databases operated by the cloud infrastructure system 1118 along with other system elements.

[0077] At operation 1138, the order information may be routed to the order management module 1120. In some cases, the order management module 1120 may be configured to perform billing and accounting functions related to the order, such as validating the order and booking the order after validation.

[0078] At operation 1140, information regarding the order may be communicated to the order orchestration module 1122. The order orchestration module 1122 may utilize the order information to orchestrate the provisioning of services and resources for the order placed by the customer. In some cases, the order orchestration module 1122 may orchestrate the provisioning of resources to support the subscribed services using the services of the order provisioning module 1124.

[0079] In one embodiment, the order orchestration module 1122 enables management of business processes associated with each order and applies business logic to determine whether the order should proceed to provisioning. Upon receiving a new subscription order at operation 1142, the order orchestration module 1122 sends a request to the order provisioning module 1124 to allocate resources and configure those resources required to fulfill the subscription order. The order provisioning module 1124 enables the allocation of resources for the services ordered by the customer. The order provisioning module 1124 provides a level of abstraction between the cloud services provided by the cloud infrastructure system 1100 and the physical implementation layer used to provision resources to provide the requested services. The order orchestration module 1122 may thus be decoupled from implementation details such as whether the services and resources are actually provisioned on the fly or whether they are pre-provisioned and allocated / allocated only upon request.

[0080] At operation 1144, once the services and resources are provisioned, notification of the provided services is sent to the order provisioning server of the cloud infrastructure system 1102. The request may be transmitted by the switching module 1124 to the customer on the client device 1104, 1106, and / or 1108.

[0081] At operation 1146, the customer's subscription order may be managed and tracked by the order management and monitoring module 1126. In some cases, the order management and monitoring module 1126 may be configured to collect usage statistics for the services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, the amount of system uptime and system downtime.

[0082] In an embodiment, cloud infrastructure system 1100 may include an identity management module 1128. Identity management module 1128 may be configured to provide identity services, such as access management and authentication services, in cloud infrastructure system 1100. In some embodiments, identity management module 1128 may control information about customers who wish to utilize services provided by cloud infrastructure system 1102. Such information may include information authenticating the identity of such customers and information describing what actions those customers are authorized to perform on various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). Identity management module 1128 may also include management of descriptive information about each customer and how that descriptive information may be accessed and modified and by whom.

[0083] 12 illustrates an exemplary computer system 1200 upon which various embodiments of the present invention may be implemented. System 1200 may be used to implement any of the computer systems described above. As shown, computer system 1200 includes a processing unit 1204 that communicates with a number of peripheral subsystems via a bus subsystem 1202. These peripheral subsystems may include a processing accelerator 1206, an I / O subsystem 1208, a storage subsystem 1218, and a communication subsystem 1224. Storage subsystem 1218 includes a tangible computer readable storage medium 1222 and a system memory 1210.

[0084] Bus subsystem 1202 provides a mechanism for allowing the various components and subsystems of computer system 1200 to communicate with each other as intended. Although bus subsystem 1202 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1202 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) bus, and the like. It may include a local bus, and a Peripheral Component Interconnect (PCI) bus, which is manufactured according to the IEEE P1386.1 standard. It can be realized as a mezzanine bus.

[0085] The processing unit 1204, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1200. The processing unit 1204 may include one or more processors. These processors The processor may include a single-core or multi-core processor. In some embodiments, the processing unit 1204 may be implemented as one or more independent processing units 1232 and / or 1234, with a single or multi-core processor included in each processing unit. In other embodiments, the processing unit 1204 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0086] In various embodiments, the processor 1204 can execute various programs in response to program code and can maintain multiple programs or processes running simultaneously. At any given time, some or all of the program code to be executed may reside in the processor 1204 and / or in the memory subsystem 1218. Through suitable programming, the processor 1204 can provide the various functionality discussed above. The computer system 1200 may additionally include a processing accelerator 1206, which may include a digital signal processor (DSP), a special purpose processor, or the like.

[0087] The I / O subsystem 1208 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen integrated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include motion sensing and / or gesture recognition devices such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and verbal commands. User interface input devices may also include eye gesture recognition devices such as a Google Glass® blink detector that detects eye activity from a user (e.g., “blinking” during picture taking and / or menu selection) and translates the eye gesture as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (eg, the Siri® navigator) through voice commands.

[0088] User interface input devices may also include, without limitation, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. In addition, user interface input devices may include medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound, etc. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, etc.

[0089] The user interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), a liquid crystal display (LCD), or a plasma display, a projection device, or a The output device may be a display device, a touch screen, etc. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1200 to a user or to another computer. For example, user interface output devices may include, without limitation, various display devices that visually convey text, graphics, and audio / visual information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0090] Computer system 1200 may include a storage subsystem 1218 that includes the software elements currently illustrated as located within system memory 1210. System memory 1210 may store program instructions loadable and executable on processing unit 1204, as well as data generated during the execution of these programs.

[0091] Depending on the configuration and type of computer system 1200, the system memory 1210 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or presently being operated on and executed by the processing unit 1204. In some implementations, the system memory 1210 may include a number of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system containing the basic routines that help to transfer information between elements within the computer system 1200, such as during start-up. A BIOS (BIOS for the system) may typically be stored in ROM. As such, system memory 1210 also illustrates application programs 1212, which may include client applications, a web browser, a middle tier application, a relational database management system (RDBMS), and the like, program data 1214, and operating system 1216. By way of example, operating system 1216 may include various versions of the Microsoft Windows, Apple Macintosh, and / or Linux operating systems, various commercially available UNIX or UNIX-like operating systems (including, without limitation, various GNU / Linux operating systems, Google Chrome OS, and the like), and / or mobile operating systems, such as iOS, Windows Phone, Android OS, BlackBerry 10 OS, Palm OS operating systems, and the like.

[0092] The storage subsystem 1218 may also provide a tangible computer-readable storage medium for storing data structures and basic programming that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processor, provide the functionality described above may be stored in the storage subsystem 1218. These software modules or instructions may be executed by the processing unit 1204. The storage subsystem 1218 may also provide a repository for storing data used in accordance with the present invention.

[0093] The storage subsystem 1200 may also include a computer readable storage medium reader 1220 that may be further connected to a computer readable storage medium 1222. In conjunction with the system memory 1210, and optionally in combination with the system memory 1210, the computer readable storage medium 1222 may be used to temporarily and / or permanently store computer readable information in addition to remote, local, fixed and / or removable storage devices. The term may generally refer to any storage medium for persistently containing, storing, transmitting, and retrieving information.

[0094] The computer readable storage medium 1222 containing the code or portions of code may also include any suitable medium known or used in the art, including storage and communication media such as volatile and non-volatile, removable and non-removable media, etc., implemented in any method or technology for storing and / or transmitting information. This may include tangible computer readable storage media, such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage, or other tangible computer readable media. This may also include non-tangible computer readable media, such as data signals, data transmissions, or any other medium that can be used to transmit the desired information and that is accessible by the computing system 1200.

[0095] By way of example, the computer readable storage medium 1222 may include hard disk drives that read from and write to non-removable, non-volatile magnetic media, magnetic disk drives that read from and write to removable, non-volatile magnetic media, and optical disk drives that read from and write to removable, non-volatile optical disks, such as CD ROMs, DVDs, Blu-Ray® disks, or other optical media. The computer readable storage medium 1222 may include, but is not limited to, Zip® drives, flash memory cards, universal serial bus (USB) flash drives, secure digital (SD) cards, DVD disks, digital video tapes, and the like. The computer readable storage medium 1222 may also include flash memory-based solid-state drives (SSDs), enterprise flash drives, solid-state SSDs may include those based on non-volatile memory such as ROM, solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, volatile memory-based SSDs such as magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs using a combination of DRAM-based SSDs and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 1200.

[0096] The communications subsystem 1224 provides an interface to other computer systems and networks. The communications subsystem 1224 serves as an interface for receiving data from and transmitting data to other systems other than the computer system 1200. For example, the communications subsystem 1224 may enable the computer system 1200 to connect to one or more devices over the Internet. In some embodiments, the communications subsystem 1224 may include a radio frequency (RF) transceiver controller for accessing wireless voice and / or data networks (e.g., using cellular technology, advanced data network technology such as 3G, 4G, or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family of standards), or other mobile communications technologies, or any combination thereof). Component, Global Positioning System (GPS) receiver component In some embodiments, the communications subsystem 1224 can provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0097] In some embodiments, the communications subsystem 1224 may also receive incoming communications in the form of structured and / or unstructured data feeds 1226, event streams 1228, event updates 1230, etc., for one or more users using the computer system 1200.

[0098] As an example, the communications subsystem 1224 may provide Twitter feeds, Facebook updates, Rich Site Summary (RSS) feeds, and other similar services. The social network may be configured to receive data feeds 1226 in real time from users of social networks and / or other communication services, such as web feeds, such as social media feeds, and / or real-time updates from one or more third party sources.

[0099] Additionally, the communications subsystem 1224 may also be configured to receive data in the form of a continuous data stream, which may be continuous or infinite in nature with no apparent end, which may include an event stream 1228 of real-time events and / or event updates 1230. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

[0100] The communications subsystem 1224 may also be configured to output structured and / or unstructured data feeds 1226, event streams 1228, event updates 1230, etc. to one or more databases that may be in communication with one or more streaming data source computers coupled to the computer system 1200.

[0101] The computer system 1200 may be one of a variety of types, including a handheld mobile device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0102] Due to the ever-changing nature of computers and networks, the description of computer system 1200 shown in the figure is intended only as a specific example. Many other configurations are possible having more or fewer components than the system shown in the figure. For example, customized hardware may also be used and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections to other computing devices, such as network input / output devices, may be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other ways and / or methods for implementing various embodiments.

[0103] In the preceding description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of various embodiments of the present invention. However, it will be apparent to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

[0104] The foregoing description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of exemplary embodiments will provide those skilled in the art with an enabling description for implementing the exemplary embodiments. Elements may be modified without departing from the spirit and scope of the present invention as set forth in the appended claims. It should be understood that various changes may be made in the function and arrangement of.

[0105] In the foregoing description, specific details are given to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may have been shown as components in block diagram form so as not to obscure the embodiments in undue detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may have been shown without unnecessary detail so as not to obscure the embodiments.

[0106] It should also be noted that the particular embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe operations as a sequential process, many of the operations may occur in parallel or simultaneously. Additionally, the order of operations may be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to which it was called or to the main function.

[0107] The term "computer-readable medium" includes, but is not limited to, portable or non-removable storage devices, optical storage devices, wireless channels, and various other media capable of storing, containing, or carrying instructions and / or data. A code segment or machine-executable instruction may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, dispatched, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0108] Furthermore, the embodiments may be implemented in hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium. A processor may perform the necessary tasks.

[0109] In the foregoing specification, aspects of the invention have been described with respect to specific embodiments thereof, but those skilled in the art will recognize that the invention is not limited thereto. The various features and aspects of the invention described above may be used individually or together. Also, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive.

[0110] Additionally, for purposes of illustration, the methods have been described in a particular order. It should be understood that in alternative embodiments, the methods may be performed in an order different from that described. The methods described above may be performed by hardware components or embodied in a sequence of machine-executable instructions that can be used to cause a machine, such as a general purpose or special purpose processor, or logic circuitry programmed with the instructions, to perform the methods. It should also be understood that the machine-executable instructions may be stored on one or more machine-readable media, such as a CD-ROM or other type of optical disk, a floppy diskette, a ROM, a RAM, an EPROM, an EEPROM, a magnetic or optical card, a flash memory, or other type of machine-readable medium suitable for storing electronic instructions. Alternatively, the method may be performed by a combination of hardware and software.

Claims

1. 1. A method for isolating tenants using containers to service requests in a multi-tenant environment, the method comprising: receiving a first request for a first service provided by a first tenant; selecting an empty container in the multi-tenant environment; loading a first configuration implementing the first service into the container; servicing the first request from the container; receiving a second request for a second service provided by a second tenant; flushing the first configuration from the container; and servicing the second request from the container.

2. The method of claim 1 , wherein the container is one of a plurality of containers in the multi-tenant environment that are instantiated to service requests from client devices.

3. The method of claim 1 , wherein the first configuration includes a size of a heap in memory that can be used by the first service.

4. The method of claim 1 , wherein after flushing the first configuration from the container, the container includes a runtime process having an embedded server and an internal endpoint.

5. The method of claim 4 , wherein the internal endpoint is invoked by a router in the multi-tenant environment to service the second request.

6. The method of claim 1 , wherein the first configuration comprises a number of actions that are chained together to service a request.

7. The method of claim 1 , wherein the multi-tenant environment prevents the container from simultaneously servicing requests associated with different tenants.

8. The method of claim 1 , wherein the multi-tenant environment enables the container to simultaneously service requests associated with a single tenant.

9. receiving a third request for the second service provided by the second tenant; and servicing the third request from the container without flushing a second configuration from the container.

10. The method of claim 1 , wherein the first service includes a public API made available throughout the multi-tenant environment.

11. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations, the operations including: receiving a first request for a first service provided by a first tenant; selecting an empty container in the multi-tenant environment; loading a first configuration implementing the first service into the container; servicing the first request from the container; and receiving a second request for a second service provided by a second tenant; flushing the first configuration from the container; and servicing the second request from the container.

12. 12. The non-transitory computer-readable medium of claim 11, wherein the first configuration includes a size of a heap in memory that can be used by the first service.

13. 12. The non-transitory computer-readable medium of claim 11, wherein after flushing the first configuration from the container, the container includes a runtime process having an embedded server and an internal endpoint.

14. 14. The non-transitory computer-readable medium of claim 13, wherein the internal endpoint is invoked by a router in the multi-tenant environment to service the second request.

15. 12. The non-transitory computer-readable medium of claim 11, wherein the first configuration includes a number of actions that are chained together to service a request.

16. 1. A system comprising: one or more processors; one or more memory devices, the one or more memory devices containing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including: receiving a first request for a first service provided by a first tenant; selecting an empty container in the multi-tenant environment; loading a first configuration implementing the first service into the container; servicing the first request from the container; and receiving a second request for a second service provided by a second tenant; flushing the first configuration from the container; and servicing the second request from the container.

17. The system of claim 16 , wherein the first configuration includes a size of a heap in memory that can be used by the first service.

18. 20. The system of claim 16, wherein after flushing the first configuration from the container, the container includes a runtime process having an embedded server and an internal endpoint.

19. 20. The system of claim 18, wherein the internal endpoint is invoked by a router in the multi-tenant environment to service the second request.

20. 20. The system of claim 16, wherein the first configuration includes a number of actions that are chained together to service a request.

Images