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: 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: 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: 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 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: 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.

Abstract: Techniques are disclosed relating to an in-memory cache. In some embodiments, in response to determining that data for a requested entry is not present in the cache (e.g., because it has been evicted), a computing system is configured to invoke cached program code associated with the entry. In some embodiments, the computing system is configured to provide data generated by the program code in response to requests that indicate the entry. In some embodiments, the computing system is configured to store the generated data in the cache. In various embodiments, this may avoid cache misses and provide configurability in responding to requests to access the cache.

Abstract: Techniques are disclosed relating to an in-memory, software-managed cache configured to store web application data. In some embodiments, operations to cache data specify a visibility parameter for the data, among a plurality of namespaces. In some embodiments, requests to access cached data are checked, based on a request's namespace and the visibility parameter for the cached data, to determine whether they are allowed to proceed. In some embodiments, this may facilitate caching data using shared computing systems and data structures while maintaining configurable privacy for cached data.

Abstract: Techniques are disclosed relating to an in-memory cache for web application data. In some embodiments, received transactions include multiple operations, including one or more cache operations to access the in-memory cache. In some embodiments, transactions are performed atomically. In some embodiments, data for the one or more cache operations is stored locally in memory by an application server outside of the in-memory cache until the transaction is successfully completed. This may improve performance and facilitate atomicity, in some embodiments.

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.

Abstract: Techniques are disclosed relating to an in-memory cache. In some embodiments, in response to determining that data for a requested entry is not present in the cache (e.g., because it has been evicted), a computing system is configured to invoke cached program code associated with the entry. In some embodiments, the computing system is configured to provide data generated by the program code in response to requests that indicate the entry. In some embodiments, the computing system is configured to store the generated data in the cache. In various embodiments, this may avoid cache misses and provide configurability in responding to requests to access the cache.

Abstract: Techniques are disclosed relating to an in-memory, software-managed cache configured to store web application data. In some embodiments, operations to cache data specify a visibility parameter for the data, among a plurality of namespaces. In some embodiments, requests to access cached data are checked, based on a request's namespace and the visibility parameter for the cached data, to determine whether they are allowed to proceed. In some embodiments, this may facilitate caching data using shared computing systems and data structures while maintaining configurable privacy for cached data.

Abstract: Techniques are disclosed relating to an in-memory cache for web application data. In some embodiments, received transactions include multiple operations, including one or more cache operations to access the in-memory cache. In some embodiments, transactions are performed atomically. In some embodiments, data for the one or more cache operations is stored locally in memory by an application server outside of the in-memory cache until the transaction is successfully completed. This may improve performance and facilitate atomicity, in some embodiments.