The Utoolity team is pleased to present
Tasks for AWS 2.15 –
this release catches up on several
serverless announcements from 'AWS re:Invent 2017': It adds support for the
AWS Fargate launch type in
Amazon ECS, and adds support for
traffic shifting,
concurrency limits, and the C# .NET Core 2.0 and Go 1.x runtimes in
AWS Lambda. You can now run your Docker containers as an
Amazon ECS Task or
Amazon ECS Service without managing servers and clusters, and exercise more control over the deployment and concurrent execution of an
AWS Lambda Function, which can now also use the C# .NET Core 2.0 and Go 1.x runtimes.
Highlights
Use AWS Fargate to run Docker containers on Amazon ECS without managing infrastructure
You can now use the
AWS Fargate launch type to run Docker containers with the
Amazon ECS Task task or the
Amazon ECS Service task without managing servers or clusters – refer to the resp. introductory blog posts for more details:
-
Introducing AWS Fargate – Run Containers without Managing Infrastructure
AWS Fargate is an easy way to deploy your containers on AWS. To put it simply, Fargate is like EC2, but instead of giving you a virtual machine you get a container. It’s a technology that allows you to use containers as a fundamental compute primitive without having to manage the underlying instances. All you need to do is build your container image, specify the CPU and memory requirements, define your networking and IAM policies, and launch. With Fargate, you have flexible configuration options to closely match your application needs and you’re billed with per-second granularity. [...] * AWS Fargate: A Product Overview
Perform gradual deployments of AWS Lambda functions
You can now gradually deploy your Lambda function by shifting traffic between two function versions with the
AWS Lambda Function task – refer to the resp. introductory blog post for more details:
-
Implementing Canary Deployments of AWS Lambda Functions with Alias Traffic Shifting
Before the release of traffic shifting for Lambda aliases, deployments of a Lambda function could only be performed in a single “flip” by updating function code for version
$LATEST
, or by updating an alias to target a different function version. After the update propagates, typically within a few seconds, 100% of function invocations execute the new version. Implementing canary deployments with this model required the development of an additional routing layer, further adding development time, complexity, and invocation latency. While rolling back a bad deployment of a Lambda function is a trivial operation and takes effect near instantaneously, deployments of new versions for critical functions can still be a potentially nerve-racking experience.With the introduction of alias traffic shifting, it is now possible to trivially implement canary deployments of Lambda functions. By updating additional version weights on an alias, invocation traffic is routed to the new function versions based on the weight specified. [...]
Limit concurrent executions of AWS Lambda functions
You can now limit the concurrent execution impact of your Lambda functions by setting a function specific concurrency limit with the
AWS Lambda Function task – refer to the resp. introductory blog post for more details:) task – refer to the resp. introductory blog post for more details:
-
Managing AWS Lambda Function Concurrency
You can now set a concurrency limit on individual Lambda functions in an account. The concurrency limit that you set reserves a portion of your account level concurrency for a given function. All of your functions’ concurrent executions count against this account-level limit by default.
If you set a concurrency limit for a specific function, then that function’s concurrency limit allocation is deducted from the shared pool and assigned to that specific function. AWS also reserves 100 units of concurrency for all functions that don’t have a specified concurrency limit set. This helps to make sure that future functions have capacity to be consumed. [...]
Use the C# .NET Core 2.0 and Go 1.x runtimes for AWS Lambda functions
You can now use the C# .NET Core 2.0 and Go 1.x runtimes in the
AWS Lambda Function task – refer to the resp. introductory blog posts for more details:
Release notes
For more details about this release, please refer to the Tasks for AWS 2.15 Release Notes.