Serverless Day at the AWS Loft 2018

Summarising all of the interesting Serverless offerings from AWS might require more book than blog but here goes! fourTheorem spent a fruitful day at the AWS Loft in NYC hearing about all the cool new features being provided to customers.

Session 1: AWS Lambda and Serverless

Presenter: Chris Munns (munns@amazon.com)

Chris Munns kicked the day off with an overview of AWS Lambda and Serverless concepts. Chris is a New Yorker and a self-professed internet infrastructure geek who began working at AWS as a DevOps Business Development Manager, moving on to Senior Developer Advocate on the Serverless team.

What exactly does Serverless mean?

Serverless architecture is a product of cloud computing. It is an event-driven application design and deployment paradigm in which computing resources are provided as scalable cloud services. 

With Serverless, you don’t have to deploy any virtual or physical servers, any containers, or any operating system. The cloud platform provider handles all this under the covers. Not having to fret about infrastructure frees us up to focus on coding our service(s) as a series of standalone functions triggered and run only when required.

• You never have to pay for idle time. Gartner estimates that, on average, IT infrastructure is idle for about 80% of the time.
• No servers to provision or manage. Think of the DevOps time saved here.
• Serverless scales with usage. No worries about autoscaling or load-balancing.
• Availability and fault-tolerance are built into the service.

• Web Applications
• Backends for mobile apps and IoT
• Data Processing
• Powering chatbot logic
• Amazon Alexa
• IT Automation such as policy engines

AWS Lambda is a compute service that lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and scales automatically, from a few requests per day to thousands per second.

Lambda takes an event source such as an API endpoint request, or changes in a resource state, and triggers a function/functions. The Lambda function, in turn, outputs to other services which can be both internal and external to AWS. Lambda is a serverless Function-as-a-Service (FaaS), which is a sub-category of Function-as-a-Service, which in turn is a subcategory of event-driven computing.

The current languages supported by Lambda are: Node, Java, Python, C#, and Go. It offers flexibility, supporting synchronous and asynchronous mode, integrates seamlessly with other AWS services. and authorisation with fine-grained control. It is stateless and persists data using external storage.

Eric Jonas, a postdoctoral research student at University of California-Berkeley’s AMPLab, has created a software package called PyWren to help researchers with their investigations. PyWren provides the ability to parse out Python-based scientific workloads across many different Lambda instances, in effect creating a giant, if extremely temporary, computing cluster.

The PyWren project has benchmarked 60-80 GB/s across 2800 Lambda functions, as well as 25TFLOPS (25 trillion floating-point operations per second) from a fleet of AWS Lambdas.

Waiting for a response from another service, for example, can create orchestration problems. In order to keep orchestration out of your Lambda code, AWS has developed the Step Functions service. This allows you to decompose your business workflow into separate objects, automatically triggering and tracking each step, retrying on error, allowing an application to execute in defined order. It also logs the state of each step so you can see when things go wrong. It is Serverless workflow management with zero admin

AWS offers a myriad of managed services that wrap around Lambda. Unless complex authentication systems are your thing, and is where your business derives value (aka revenue), why build such a system yourself? Why setup, maintain, and monitor database servers when there are plenty of cloud managed services out there? Why build out an API, when you can create one within AWS API Gateway?

Amazon’s API Gateway creates a unified API frontend for multiple micro-services. There are lots of other third party API gateway options to choose from, but it doesn’t make much sense to build and maintain these yourself within the AWS environment. Why not save yourself the hassle and build on top of Amazons hard work?

All this is great but you’re probably asking yourself “Where do I start?” There are many serverless frameworks you could use to get yourself going, including the following recommended examples:

• AWS Chalice – A Python serverless “microframework” for AWS Lambda and Amazon API gateway
• Claudia.js – A Node.js framework for deploying projects to AWS Lambda and Amazon API Gateway.
• ServerLess
• APEX
• Sparta
• Zappa

Lambda functions accept the passing of variables, which can be useful for deploying to different environments (e.g. dev, testing, production).

• Variables are Key/Value pairs that can be dynamically passed to your function.
• Variables are available via standard environment variable API’s such as process.env for Node.Js or os.environ for Python.
• Variables can optionally be encrypted via AWS Key Management Service (KMS) which allows you to specify an IAM role that has access to the keys to decrypt the information.

• Stage variables act like environment variables.
• Use stage variables to store configuration variables.
• You can map API stage variables to Lambda aliases to support multiple environment stages.

The downside is Lambda aliases map back to a single function version and are immutable.

By default, an alias points to a single Lambda function version. When the alias is updated to point to a different function version, incoming request traffic instantly points to the updated version. This exposes that alias to any potential instabilities introduced by the new version.

To minimise this impact, you can implement the routing-config parameter of the Lambda alias that allows you to point to two different versions of the Lambda function and dictate what percentage of incoming traffic is sent to which version. Alias Traffic Shifting can be used for implementing a canary deployment of AWS Lambda functions as well as routing and configuration using the AdditionalVersionWeight property.

Using Sam you have Globals and Safe Deployment functions. SAM can slowly switch over more and more traffic to a new version. If the canary function triggers too many predefined alarms, SAM can rollback. AWS CodeDeploy supports SAM and Lambda traffic shifting, thus enabling canary and blue/green styles of deployment.

Not an exhaustive list by any means, but some useful Lambda testing tools mentioned include:

For code/test coverage

• Landscape.io (only Python)
• Codeclimate.com
• Coveralls.io (mocking/stubbing)
• Github.com/Atlassian/localstack – fully functional local AWS cloud stack for developing and testing apps offline.

API / UI testing

• Runscope.com – API monitoring/testing
• Ghostinspector.com – Web testing

If you are interested in how fourTheorem can help you with Machine Learning on AWS, DevOps, cloud migration and architecture, please contact us and we’ll be happy to help.