Amazon Technologies, Inc.

Microsoft Technology Licensing, LLC

Onur Filiz

Anirudh Balachandra Aithal

Amit Kumar Gupta

Prashant Prahlad

Archana Srikanta

Eswar Chander Balasubramanian

Sri Saran Balaji Vellore Rajakumar

Micah William Hausler

Song Hu

Nadim Y Abdo

Max Alan McMullen

Daniel Wood

Ryan John Marchand

Venkata Satya Shyam Jeedigunta

The present application relates to performing a scale-down of the computing resources allocated to executing a software application. For example, the software application for implementing a web server may be packaged as a container image, and one or more instances of the container images may be executed as one or more tasks. The individual tasks may be allocated a set of computing resources such as CPU and memory, and the incoming requests sent to the web server may be distributed across the tasks. If the volume of incoming requests drops below a threshold level, one or more of the tasks may be placed in standby mode, and the amount of computing resources allocated to such tasks may be reduced. When the volume of incoming requests returns above the threshold level, the amount of computing resources allocated to such tasks can be scaled back up to the full amount.

Scaling down computing resource allocations for execution of containerized applications

The present application relates to performing a scale-up of the computing resources allocated to executing a software application. For example, the software application for implementing a web server may be packaged as a container image, and one or more instances of the container images may be executed as one or more tasks. The individual tasks may be allocated a set of computing resources such as CPU and memory, and the incoming requests sent to the web server may be distributed across the tasks. If the volume of incoming requests drops below a threshold level, one or more of the tasks may be placed in standby mode, and the amount of computing resources allocated to such tasks may be reduced. When the volume of incoming requests returns above the threshold level, the amount of computing resources allocated to such tasks can be scaled back up to the full amount.

Scaling up computing resource allocations for execution of containerized applications

A task pool may be created and maintained, in association with a container management service, which stores a snapshot of a one or more tasks, the performance of which is suspended or paused. Tasks may be defined as applications executable in one or more software containers instantiated on a virtual machine or compute instance, where the snapshot of a task may include an image of the one or more containers associated with the task container and state information of the one or more containers. A task may be initially provisioned in a paused state or paused after executing at least a portion of the task. Paused tasks in the task pool may be readily restarted or resumed by loading the snapshot onto a compute instance. The task pool may manage provisioning new tasks and pause tasks based on changes in demand.

Task pool for managed compute instances

The present application relates to providing a mechanism for specifying multiple network interfaces to be configured for on-demand compute capacity and for obtaining the credentials needed to configure the multiple network interfaces. For example, a container orchestration service may specify, in its code execution request to a serverless container management service, that multiple network interfaces are needed for the requested compute capacity. In response, the serverless container management service can identify the multiple network interfaces, determine the credential to be used to configure each of the multiple network interfaces, and attach the multiple network interfaces to the compute capacity acquired on behalf of the container orchestration service. During execution, the code running inside the compute capacity can utilize the multiple network interfaces as specified by the owner of the code.

Client-specified network interface configuration for serverless container management service

The present application relates to executing a containerized application in a nested manner on two separate container orchestration services. For example, a user may submit a request to a container orchestration service to execute a containerized application, and in response, instead of identifying one of the existing compute instances belonging to the user and executing the containerized application on the identified compute instance, the container orchestration service may generate and submit a request to a serverless container management service that can not only acquire compute resources on behalf of the container orchestration service but also manage the compute resources such that the container orchestration service (or the original requesting user) does not need to manage scaling, monitoring, patching, and security of the compute resources.

Service-managed containers for container orchestration service

Techniques for improved command level remoting are disclosed. In embodiments of the invention, commands to generate vertices are sent in a terminal service session. As commands to draw vertices are generated by a server to be sent to a client to display, they are analyzed by the server. Where some of those vertices have been previously sent to the client, such as to generate a previous bitmap image, the server determines not to send those vertices to the client, and sends the client the new vertices.

Growing community of inventors

Redmond, WA, United States of America

Onur Filiz