ITB2016 - AWS lambda
•Transferir como PPTX, PDF•
0 gostou•308 visualizações
AWS Lambda is a compute service that as part of the AWS suite that allows you to have on-demand, event driven compute available to you with AWS Lambda taking care of provisioning and managing the servers required to run your code. In this session you will find out what AWS Lambda is, why and when you might use it and what it is good and not good for along with giving some real world examples.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a ITB2016 - AWS lambda
Semelhante a ITB2016 - AWS lambda (20)
Mais de Ortus Solutions, Corp
Mais de Ortus Solutions, Corp (20)
Último
Último (20)
ITB2016 - AWS lambda
- 1. AWS Lambda What, why, when, how?
- 3. Compute service where you don't think about…
- 4. Servers
- 5. Capacity
- 6. Deployments
- 7. Scaling
- 10. Automatic OS and language updates
- 11. All of that is taken care of automatically
- 12. You can easily…
- 13. Bring your own code, including native libraries
- 14. Run code in parallel
- 15. Lambda use cases
- 16. Create backends
- 19. Serverless
- 22. You never pay for idle!
- 23. How it works
- 24. Upload code in a zip file
- 25. Code can be… v0.10 & v4.3 Java 8 v2.7
- 26. Code is stateless, persistence goes elsewhere
- 27. Monitoring and logging handled automatically by CloudWatch
- 28. Integrates with other AWS services
- 29. S3 DynamoDB RDS VPC CloudWatch CloudFormation Cognito SNSAPI Gateway SES SWF Kinesis CloudTrail CloudWatch All these & more…
- 30. Compute Power 23 "power levels"
- 31. Specified in Lambda as memory
- 33. More memory = More CPU
- 34. Price scales with power level
- 35. Pricing per 100ms (rounded up to nearest 100ms)
- 36. Run durations from 100ms to 5 minutes
- 37. For compute intensive tasks set power level higher
- 38. For I/O intensive tasks set power level lower
- 39. Event Sources • S3 • Schedule events • AWS IoT • CloudWatch • DynamoDB • Kinesis • SNS • API Gateway (sort of)
- 40. “Serverless” API’s with AWS API Gateway & Lambda
- 41. Versioning
- 42. By using versioning nothing changes
- 43. But now you can publish a version
- 44. Versions can have aliases
- 45. VPC Support
- 46. Pricing
- 47. $0.20 per 1 million requests
- 48. Pay for CPU usages in 100ms intervals. Price depends on memory allocation. From $0.000000208 to $0.000002501 per 100ms
- 49. First 1 million request and 400,000 GB-seconds of compute time per month FREE!!!
- 50. This is equal to approx.: 888 hours at 128Mb …. 74 hours at 1.5Gb
- 51. Example uses
- 52. Image processing
- 53. Data processing
- 54. Scheduled Tasks
- 56. If you need help email me andrew.dixon@mso.net
Notas do Editor
- Andrew Dixon Work for a digital agency call mso since 2000 Technical Director We are pivoting from a service agency to a product developer in the education sector Development platform of choice is Lucee but with new services like Lambda we are using these as well when they fit for our purposes
- Introduced by AWS in Oct 2014 Compute service that runs code in response to events
- Compute service and the interesting thing about it is what you don’t have to think about…
- You don’t have to think about infrastructure, which has interesting consequences
- 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
- 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
- Scaling is all done automatically, you just make a request for compute and Lambda gives it to you.
- 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 down Taking 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
- The boiler plate activities like logging come ready made out of the box.
- As well as OS and language updates…
- All taken care of for you, automatically, so there is nothing to manage.
- But it is not a straight jacket Very flexible
- For example, for Node you can bring a library like momentjs
- 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.
- Lambda is excellent for backends, mobile backends, web backends, IoT backends, etc…
- Lambda responds to your events
- If you have some data, somewhere, then you can use Lambda to recognise that data is there and get it to process it.
- 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
- 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
- Billed in fine grain 100ms units so as soon as your computation has finished you stop paying.
- And when you don’t have the infrastructure, you don’t have to worry about under-utilising the infrastructure so you never pay for idle.
- How all of this works is relatively simple Create your function, that does the required task
- Take your code, and native libraries, in the form of a zip file upload that to Lambda either directly or from S3. From that point, Lambda is ready to deploy and run your code.
- Node JS – version 0.10 and 4.3 Java – version 8 Python – version 2.7
- The code that you upload is stateless Persistent data is put elsewhere, e.g. S3, RDS, DynamoDB, etc…
- For monitoring and logging you have built-in support for CloudWatch metrics and logs
- Lambda integrates with lots of other AWS solutions including…
- All these and more… S3, DynamoDB, RDS, API Gateway and so on...
- 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.
- 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.
- For compute intensive, set power level higher so that you pay more per 100ms but run for less time.
- For I/O intensive task, set power level lower as no point in paying for CPU.
- There are 7 “event sources” for Lambda and then there is API Gateway, which can invoke a Lambda function.
- 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).
- 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…
- By using versioning nothing changes in how you use Lambda Upload code Make changes any time Last update wins when no version number is specified
- Publish a new version from development at any time These published versions receive a numbered version and become immutable Version numbers are a simple, integer counter starting at 1 Versions of a function are accessed using the ARN with a colon and the version number, e.g. :1, :2, etc..
- 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.
- Lambda functions can access private resources, e.g. RDS, private EC2 endpoints, Elasticache, etc…
- Pay for CPU usage in 100 millisecond intervals, so if you use 565ms you pay for 600ms. Price depends on memory allocation.
- However first million request and 400,000 GB seconds are free, in perpetuity.
- 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.
- 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”.
- 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.
- 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.
- 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 a 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.
- 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 independatley, without us having to worry about a peak surge in demand, e.g. lots of parents all trying to download their childrens school report as a PDF at the same time.
- Essentially we used Lambda to remove the capacity headache while reducing our costs. Happy to help.