Abstract: According to some implementations, while a proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (cos) pods having first app version containers, configuration information is received including an identification of a second app version container image for a second app version. The second app version is an updated version of the first app version. Cos pods having second app version containers are brought up based on the second app version container image identified in the configuration information. Test and/or warmup traffic is caused to be routed to the second app version containers. Responsive to an indication regarding the routing of the test and/or warmup traffic to the second app version, causing a transition to sending production traffic to the second app version containers instead of to the first app version.

Abstract: According to some implementations, while a proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (cos) pods having first app version containers, configuration information is received including an identification of a second app version container image for a second app version. The second app version is an updated version of the first app version. Cos pods having second app version containers are brought up based on the second app version container image identified in the configuration information. Test and/or warmup traffic is caused to be routed to the second app version containers. Responsive to an indication regarding the routing of the test and/or warmup traffic to the second app version, causing a transition to sending production traffic to the second app version containers instead of to the first app version.

Abstract: According to some implementations, while a proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (cos) pods having first app version containers, configuration information is received including an identification of a second app version container image for a second app version. The second app version is an updated version of the first app version. Cos pods having second app version containers are brought up based on the second app version container image identified in the configuration information. Test and/or warmup traffic is caused to be routed to the second app version containers. Responsive to an indication regarding the routing of the test and/or warmup traffic to the second app version, causing a transition to sending production traffic to the second app version containers instead of to the first app version.

Abstract: According to some implementations, while a proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (cos) pods having first app version containers, configuration information is received including an identification of a second app version container image for a second app version. The second app version is an updated version of the first app version. Cos pods having second app version containers are brought up based on the second app version container image identified in the configuration information. Test and/or warmup traffic is caused to be routed to the second app version containers. Responsive to an indication regarding the routing of the test and/or warmup traffic to the second app version, causing a transition to sending production traffic to the second app version containers instead of to the first app version.

Abstract: Cloud services release orchestration with a reusable deployment pipeline. According to some implementations, responsive to receiving from a COS controller parameters from configuration information provided to the COS controller while an app aware proxy routes production traffic to a first application (app) version that communicates with a database management system (DBMS) and that runs in container orchestration system (COS) pods having first app version containers, causing a validation of a second app version using COS pods having second app version containers that are now live after having been brought up by the COS controller responsive to the provision of the configuration information. After the validation, causing the transition to sending production traffic to the second app version containers that are determined to be live instead of to the first app version containers.

Abstract: Techniques and mechanisms for providing asynchronous web service calls in an on-demand services environment. In response to request from a remote client, a page is provided. The page has content including logic to retrieve information from a remote resource external to an on-demand services environment via at least one asynchronous web service call. A controller component of the page is loaded before rendering a response to the remote computing device. At least one web service call is sent to the remote resource with the controller component. A continuation object is returned with the controller component to release the first thread from waiting for a response to the web service call. The continuation object provides a label to be used when handling the response. The response to the web service call is received from the remote resource and processing is resumed with the continuation object.

Abstract: Cloud services release orchestration with a reusable deployment pipeline. According to some implementations, responsive to receiving from a COS controller parameters from configuration information provided to the COS controller while an app aware proxy routes production traffic to a first application (app) version that communicates with a database management system (DBMS) and that runs in container orchestration system (COS) pods having first app version containers, causing a validation of a second app version using COS pods having second app version containers that are now live after having been brought up by the COS controller responsive to the provision of the configuration information. After the validation, causing the transition to sending production traffic to the second app version containers that are determined to be live instead of to the first app version containers.

Abstract: Cloud services release orchestration with a reusable deployment pipeline. According to some implementations, responsive to receiving from a COS controller parameters from configuration information provided to the COS controller while an app aware proxy routes production traffic to a first application (app) version that communicates with a database management system (DBMS) and that runs in container orchestration system (COS) pods having first app version containers, causing a validation of a second app version using COS pods having second app version containers that are now live after having been brought up by the COS controller responsive to the provision of the configuration information. After the validation, causing the transition to sending production traffic to the second app version containers that are determined to be live instead of to the first app version containers.

Abstract: Methods and systems for optimization of layering of a container image are presented. A modification factor is determined, based on modification events, for each one of multiple software elements. A container image layering structure is determined, based at least in part on the modification factors of the software elements, where the container image layering structure defines a layering order for two or more container sub-images that form the container image, and the layering order determines an order with which container sub-image from the container sub-images are to be executed to form the entire container image, and the container image layering structure further defines for each one of the container sub-images a respective subset of one or more software elements from the plurality of software elements. The container image is deployed based on the container image layering structure to be used for generation of containers in a cloud processing system.

Abstract: A release orchestration mechanism for cloud services. According to some implementations, while an app aware proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (COS) pods having first app version containers, configuration information is received. When a threshold number of the COS pods having the second app version containers are live, a validation of the second app version is caused. Then a transition to sending production traffic to the second app version containers is performed. After causing the transition, timers are started based on a time period indicated in the configuration information and the first app version containers are instructed to gracefully shut down. Based on expiration of the timers, any of the COS pods having the first app version containers that are not yet shut down are forced to shut down.

Abstract: Upon receiving instructions from a release orchestrator to validate a second application version prior to a transition to sending production traffic to the second application version instead of a first application version, a determination of an application version identifier for a second application version is performed. Tests are selected based on the application version identifier and version rules. The tests are performed by sending test traffic to the second application version via a routing engine while the routing engine routes production traffic to the first application version. Based on the responses to the test traffic, a determination that any failure rules for any of the tests that failed indicate that on a failure the transition should not occur is performed. Responsive to that determination, a communication to the release orchestrator that the second application version is not validated for production traffic and the transition should not occur is performed.

Abstract: A release orchestration mechanism for cloud services. According to some implementations, while an app aware proxy routes production traffic to a first application (app) version that runs in a plurality of container orchestration system (COS) pods having first app version containers, configuration information is received. When a threshold number of the COS pods having the second app version containers are live, a validation of the second app version is caused. Then a transition to sending production traffic to the second app version containers is performed. After causing the transition, timers are started based on a time period indicated in the configuration information and the first app version containers are instructed to gracefully shut down. Based on expiration of the timers, any of the COS pods having the first app version containers that are not yet shut down are forced to shut down.

Abstract: Methods and systems for optimization of layering of a container image are presented. A modification factor is determined, based on modification events, for each one of multiple software elements. A container image layering structure is determined, based at least in part on the modification factors of the software elements, where the container image layering structure defines a layering order for two or more container sub-images that form the container image, and the layering order determines an order with which container sub-image from the container sub-images are to be executed to form the entire container image, and the container image layering structure further defines for each one of the container sub-images a respective subset of one or more software elements from the plurality of software elements. The container image is deployed based on the container image layering structure to be used for generation of containers in a cloud processing system.

Abstract: Cloud services release orchestration with a reusable deployment pipeline. According to some implementations, responsive to receiving from a COS controller parameters from configuration information provided to the COS controller while an app aware proxy routes production traffic to a first application (app) version that communicates with a database management system (DBMS) and that runs in container orchestration system (COS) pods having first app version containers, causing a validation of a second app version using COS pods having second app version containers that are now live after having been brought up by the COS controller responsive to the provision of the configuration information. After the validation, causing the transition to sending production traffic to the second app version containers that are determined to be live instead of to the first app version containers.

Abstract: A method for performing pre-release, version specific testing to validate application versions is described. Upon receiving instructions from a release orchestrator to validate a second application version prior to a transition to sending production traffic to the second application version instead of a first application version, a determination of an application version identifier for second application version is performed. Tests are selected based on the application version identifier and version rules. The tests are performed by sending test traffic to the second application version via a routing engine while the routing engine routes production traffic to the first application version. Based on the responses to the test traffic, a determination that any failure rules for any of the tests that failed indicate that on a failure the transition should not occur is performed.

Abstract: Techniques and mechanisms for providing asynchronous web service calls in an on-demand services environment. In response to request from a remote client, a page is provided. The page has content including logic to retrieve information from a remote resource external to an on-demand services environment via at least one asynchronous web service call. A controller component of the page is loaded before rendering a response to the remote computing device. At least one web service call is sent to the remote resource with the controller component. A continuation object is returned with the controller component to release the first thread from waiting for a response to the web service call. The continuation object provides a label to be used when handling the response. The response to the web service call is received from the remote resource and processing is resumed with the continuation object.

Abstract: Techniques and mechanisms for providing asynchronous web service calls in an on-demand services environment. In response to request from a remote client, a page is provided. The page has content including logic to retrieve information from a remote resource external to an on-demand services environment via at least one asynchronous web service call. A controller component of the page is loaded before rendering a response to the remote computing device. At least one web service call is sent to the remote resource with the controller component. A continuation object is returned with the controller component to release the first thread from waiting for a response to the web service call. The continuation object provides a label to be used when handling the response. The response to the web service call is received from the remote resource and processing is resumed with the continuation object.

Abstract: A method for the managing access to a software resource is disclosed. The method may include receiving, from a particular consumer, a request for a number of permits corresponding to units of a software resource. The numbers of permits may be compared to a total number of available permits. In response to determining that the number of permits is greater than the total number of available permits, rejecting the request in response to determining the number of permits requested is within a threshold value of permits requested by another consumer who has requested the largest number of permits in a preceding time period.

Abstract: A method for the managing access to a software resource is disclosed. The method may include receiving, from a particular consumer, a request for a number of permits corresponding to units of a software resource. The numbers of permits may be compared to a total number of available permits. In response to determining that the number of permits is greater than the total number of available permits, rejecting the request in response to determining the number of permits requested is within a threshold value of permits requested by another consumer who has requested the largest number of permits in a preceding time period.

Abstract: Techniques are disclosed relating to caching web application data. In some embodiments, a computing system maintains a multi-tenant database and an in-memory cache for the database. In some embodiments, the computing system is configured to store data in an entry in response to a store request and retrieve data in response to a read request. In various embodiments, data cached by one tenant is not visible to other tenants. The cache may be partitioned and each partition may have an assigned capacity. The computing system may be configured to evict cached data based on capacity thresholds, least-recently-used information, time-to-live information, amount of data in an entry, etc. The cache may indicate misses when requested data is not present. Various disclosed techniques may improve web application performance while maintaining privacy between tenants.