Skip to main content

AWS Announces: C# In Lamba, Step Functions and Lambda@Edge

Posted on December 1, 2016 by DougVanderweideDougVanderweide

Amazon announced three major Lambda updates in today’s re:Invent keynote: Support for C#, Lambda@Edge and Step Functions, which are basically a way to chain together several Lambda functions into a single workflow.

C# Support

The move to incorporate C# code into Lambda functionality is something of a shot across Microsoft Azure’s bow, but one Microsoft probably anticipated.
Microsoft’s .NET Core effort, to decouple the .NET Framework from Windows and to open source the project, has been in earnest. Surely Redmond realized, well before it released version 1.0 in late June, that doing so swung the door wide for all other cloud providers to immediately offer .NET language support in all of their services.
Also, Azure Functions is a considerably less mature offering than Lambda, which came along in 2014. Functions were in preview in March 2016 and didn’t become generally available until two weeks ago. So it’s difficult to say how Amazon’s move to support C# in Lambda might impact Functions, especially because the services are so similar. They use similar pricing models and similar architecture.
Lambda supports more native languages; Python and Java aren’t directly supported in Azure Functions. But Azure’s App Service offering, which backbones Azure Functions, has those runtimes available, so it’s likely that in a few months, Azure Functions will have the same language support as Lambda.

Step Functions

Step Functions is the more interesting development. It’s basically a means of defining a workflow that consists of multiple Lambda functions.
Of course, there’s nothing to stop you from chaining together a bunch of Lambda functions yourself. You can always write in a call to another Lambda function in your code, or just keep creating events with your functions that trigger other functions. Step Functions vastly improve on that methodology by bringing state control to Lambda workflows. That is, it allows us to group together the steps of the process into what AWS calls “transitions.” Each of these transitions is a grouping of one or more Lambda functions.
All these transition groupings are held in what AWS calls a “state machine,” which basically means, a persistent object that understands which transition is being executed and what to do next, based on the outcome of each transition.
For example, I could design a state machine that has two transitions. Its first transition invokes a Lambda function which will return a true or false. The second transition makes use of a decision tree contained in the state machine. If the result of the first transition is true, the state machine will invoke two other Lambda functions at the same time. If it is false, it will only invoke one.
Having decision-tree based control through transitions is super-useful:

  • You can capture whether any transition (a.k.a.”step”) along the way goes deaf, fails, hangs up or returns an unexpected result. That means you can implement retry and failover logic, along with any number of error handling scenarios. State machine has native support for retries, catches and if-then-else transitions.
  • It also means you can hold on to certain variables throughout the execution chain. Suppose you have a complex workload that runs across many Lambda functions. If you chained them together without state, you would have to pass to each function all the variables that any function might need along the way. With a state machine, you can present to each function only the information it needs, making your solution DRY and elegant.
  • You can impose flow control and parallelism. The problem with chaining together several stateless Lambda functions is that they must necessarily execute at the time of a triggering event and necessarily in a serial manner. (Theoretically, you could introduce a delay and parallelism in your function code; but that’s a code smell, because it prevents your function from being used outside of the workflow that requires the delay or parallel executions.) The state machine gives you this functionality.

You can design a state machine graphically through the AWS Management Console and manage them through the AWS APIs or the CLI. Free Tier gives you 4,000 state transitions per month, with each additional 1,000 executions costing 2.5 cents.
Step Functions are available in the US East (Northern Virginia), US East (Ohio), US West (Oregon), EU (Ireland) and Asia Pacific (Tokyo) regions.


One of the things that has been missing from Lambda is client environment awareness. That is, there’s been no practical way, when handling HTTP requests to Lambda functions, to know much about the client or to amend content based on the agent being used, where that agent is in the world, and the like.
To work around that, AWS has implemented Lambda@Edge, which basically allows you to route your Lambda requests through CloudFront. In so doing, your code — provided you use the new Edge Node.js language version — is able to sniff the same environment variables that the CloudFront CDN uses for its rules. This includes HTTP headers and verbs, cookies, IP addresses, geolocation, user agents (e.g., Chrome, Googlebot, Facebook, etc.) and more.
You can run different snippets of code based on whether the request or the response has been cached or not. Says Amazon:

Initially, you will be able to add, delete, and modify the headers. Soon, you will have complete read/write access to all of the values including the body.
Because your JavaScript code will be part of the request/response path, it must be lean, mean, and self-contained. It cannot make calls to other web services and it cannot access other AWS resources. It must run within 128 MB of memory, and complete within 50 ms.

This feature is in preview, so you need to apply to use it.


Leave a Reply

Your email address will not be published. Required fields are marked *