AWS Lambda – What, why, when, how?

Today I presented a session at the Ortus Solutions Into the Box conference held at the University of St. Thomas in Minneapolis, Minnesota, USA. I presented about the AWS Lambda services, which allows you to develop event-driven serverless applications. 

Here is the slide deck from the presentation:

Slide Notes

Slide 2

• Introduced by AWS in Oct 2014
• Compute service that runs code in response to events
  

Slide 3

• A compute service and the interesting thing about it is what you don’t have to think about.

Slide 4

• You don’t have to think about infrastructure, which has interesting consequences.

Slide 5

• Don’t worry about being under or over capacity, you can just give work to Lambda and it will do the compute for you.
• Same way as you give S3 your objects to store.
• Problems of having too many or too few servers don’t occur.

Slide 6

• As your not worrying about the infrastructure, you don’t have to worry about how to get things onto the infrastructure.
• No challenge of deploying code onto a fleet of servers, that’s Lambda’s problem.

Slide 7

• Scaling is all done automatically, you just make a request for compute and Lambda gives it to you.

Slide 8

• Again, all taken care of automatically by Lambda, it is fully managed and under the hood it sorts everything out, like:
  • Availability zones
  • Spinning machines up and downTaking care of unhealthy hosts
• All the things that have nothing to do with your business value as such, but stand between you and deploying production apps at scale.

Slide 9

• The boiler plate activities like logging come ready made out of the box.

Slide 10

• As well as OS and language updates.

Slide 11

• All taken care of for you, automatically, so there is nothing to manage.

Slide 12

• But it is not a straight jacket
• Very flexible

Slide 13

• For example, for NodeJS you can bring in libraries like momentjs

Slide 14

• Because each Lambda call is a separate instance it automatically allows you to run code in parallel.
• Massively and easily in parallel.
• Tell Lambda what you want it to run and it figures out how to get the code started.

Slide 16

• Lambda is excellent for backends, mobile backends, web backends, IoT backends, etc…

Slide 17

• Lambda responds to your events.

Slide 18

• If you have some data, somewhere, then you can use Lambda to recognise that data is there and get it to process it.

Slide 19

• Amazon talk about Lambda as being a “serverless” environment, which of course is a misnomer.
• But because of this, one of the most interesting things is the economics of it.
• Because you are not worrying about all the management there is a productive benefit to you because you don’t have to spend time and therefore money on it.

Slide 20

• This means that you don’t have to worry about under or over provisioning to handle burst capacity.
• The scale is driven automatically from the events.

Slide 21

• Billed in fine grain 100ms units so as soon as your computation has finished you stop paying.

Slide 22

• When you don’t have the infrastructure, you don’t have to worry about under-utilising the infrastructure so you never pay for idle.

Slide 23

• How all of this works is relatively simple.
• reate your function, that does the required task.

Slide 24

• Take your code, and native libraries, in the form of a zip file
  • Upload that to LambdaEither directly or from S3.
• From that point, Lambda is ready to deploy and run your code.

Slide 25

• Node JS – version 0.10 and 4.3
• Java – version 8
• Python – version 2.7

Slide 26

• The code that you upload is stateless.
• Persistent data is put elsewhere, e.g. S3, RDS, DynamoDB, etc…

Slide 27

• For monitoring and logging you have built-in support for CloudWatch metrics and logs.

Slide 28

• Lambda integrates with lots of other AWS solutions.

Slide 29

• All these and more…
• S3, DynamoDB, RDS, API Gateway and so on…

Slide 32

• Ranging from 128MB to 1.5GB from a pre-defined list in 64MB increments
• While the power levels are express as memory, you should think about them as the percentage of the machine that you are requesting.
• At 128MB you are getting a small slice of the machine and at 1.5GB you are getting the full power of the machine.

Slide 33

• For CPU bound tasks allocate more memory for lower latency.
• For example, choosing 256MB allocates approximately twice as much CPU power as requesting 128MB of memory and half as much as choosing 512MB.

Slide 37

• For compute intensive, set power level higher so that you pay more per 100ms but run for less time.

Slide 38

• For I/O intensive task, set power level lower as no point in paying for CPU.

Slide 39

• There are 7 “event sources” for Lambda and then there is API Gateway, which can invoke a Lambda function.

Slide 40

• You can call Lambda functions to power an API via the API gateway, meaning you can create “serverless” API’s
• API gateway allows you to create HTTP endpoints that invoke a Lambda function(s).

Slide 41

• Published versions are given and number and become immutable
• Aliases can map to versions to give the end user a stable ARN, e.g. prod, dev, etc…

Slide 42

• By using versioning nothing changes in how you use Lambda
  • Upload code.Make changes any time.Latest update wins when no version number is specified.

Slide 43

• Publish a new version from development at any time
  • These published versions receive a numbered version and become immutableVersion numbers are a simple, integer counter starting at 1Versions of a function are accessed using the ARN with a colon and the version number, e.g. :1, :2, etc..

Slide 44

• Versions can have aliases and aliases can move from one version to another
  • e.g. you could have a prod and dev alias and today prod points at version 1 and dev at version 2 but tomorrow prod could be at version 2 and dev at version 3, etc…This means the client can have a stable ARN but have the ability to change what that ARN does.
• Aliases can be moved to any version at anytime, so you could use it to roll forwards and roll back.

Slide 45

• Lambda functions can access private resources, e.g. RDS, private EC2 endpoints, Elasticache, etc…

Slide 48

• Pay for CPU usage in 100 millisecond intervals, so if you use 565ms you pay for 600ms.
• Price depends on memory allocation.

Slide 49

• •However, the first million request and 400,000 GB seconds are free, in perpetuity.

Slide 50

• So if you have a small system with a limited number of requests you could get away without paying for any Lambda time at all.

Slide 51

• We’ve been using Lambda for over a year now for various different things.
• Mainly to try and remove “heavy lifting” from Lucee so we can reduce the instance sizes we are using.
• This has allowed us to reduce are overall cost base for “compute”.

Slide 52

• Image processing is very CPU intensive.
• We have several clients that do a lot of image processing, both on user uploaded images and on images they are generating themselves.
• By shifting this to Lambda not only does it mean we can get maximum concurrency •e.g. if 50 people all upload an image at the same time It can process all of them at the same time.
• But the instance(s) the site is running on doesn’t have to be able to cope with this.

Slide 53

• Product used by schools – process large amounts of data from them every day.
• Originally this was all done in Lucee, but not sustainable.
• We would have to keep adding more and more instances to cope.
• Moving it to Lambda has given us as much capacity as we will need, when we need it, without having to pay for it all the time.
• Not only can we run the data imports for all schools simultaneously, something we couldn’t really do effectively in Lucee, but schools can also run it “on-demand” without it being a concern to us.

Slide 54

• We always had an issue with multiple instances or with “auto-scaling” clusters with scheduled tasks and where to trigger them from.
• You would not want your tasks on all instances if you only want that task to be run once an hour or once a day on one server, e.g. to send an email, etc…
• We are now using Lambda to trigger tasks, written in Lucee, using a simple HTTP call from Lambda.

Slide 55

• Again, something else that can be “heavy lifting” like image processing, the generation of documents like PDFs, Word Documents, etc… can be CPU intensive.
• Lambda let us move that off the web server and be dealt with independently, without us having to worry about a peak surge in demand, e.g. lots of parents all trying to download their children’s school report as a PDF at the same time.

• Category: AWS, Coding, Speaking