When you switch from building your own infrastructure to a Platform-as-a-Service, you trade a little bit (or a lot) of flexibility. Lambda does have limits, but you may find they don’t really affect you. If they don’t, then getting out of the “managing servers” business is a great trade.
The first limitation that most developers think about is the five minute execution maximum, but for event-driven workloads this is rarely an issue. Outside of ETL or video processing workloads, it’s hard to take that long to handle one event.
Performance Limits
If you’ve used EC2 for any length of time, you know about the wide array of instance sizes and types built to fit every need from low-utilization web server (the T2 series)to I/O- or RAM-heavy data crunching (I2 or R3 respectively). In Lambda, the choices are more limited. There’s just one performance-related knob to tweak, and that’s memory.
CPU and network bandwidth scale along with memory, but it can mean you pay for more RAM than you need to meet your compute performance requirements. As usual, more performance directly correlates to more dollars.
Default Libraries and SDKs
Node.js has ImageMagick and the AWS JavaScript SDK
installed, covering many common use cases. For anything else, you’ll have to
bundle libraries and upload the .zip to S3. Having the SDK included
makes it easy to use the Management Console to write functions that only depend
on other services, and keeps function warmup time low.
The Python runtime includes boto3 and the Python standard library
which, as you’d imagine, covers a wide range of use cases. One day, maybe
requests will get included too so we can pretend urllib2 isn’t a thing.
Java is remarkably bare - it doesn’t include any libraries at all, not even the AWS Java SDK.
There is only one Lambda execution image
Every Lambda function is executed on a copy (depending on your region) of the same machine image (AMI). Because you don’t manage any servers when using Lambda, it’s no surprise that there’s only one option for running functions. Each region has a standard Amazon Linux AMI, and you can always spin up your own as part of a build pipeline. Here’s the ID’s as of October 2015.
- AMI ID:
ami-1ecae776in us-east-1 US East (N. Virginia) region. - AMI ID:
ami-e7527ed7in us-west-2 US West (Oregon) region. - AMI ID:
ami-a10897d6in eu-west-1 EU (Ireland) region. - AMI ID:
ami-cbf90ecbin ap-northeast-1 Asia Pacific (Tokyo) region.
If your code uses any C bindings for performance, make sure the version you bundle is targeted for these AMIs. You’ll need to do your own testing, but I’ve found it’s worth the extra work to compile libraries like PyYAML with their C bindings. Remember you’re paying for every 100ms of runtime in Lambda, so time is quite literally money.
If none of the available language suit you, remember that any JVM language can also be used fairly easily. That means that fans of Clojure, Scala, JRuby, and others can also take advantage of Lambda.
Imagination
Once you know the technical limits to Lambda, it’s time to start thinking about what you want to do. Anything you already do that’s scriptable and takes less than five minutes is fair game. Do you want to…
- …add smarter self-healing or autoscaling to your other infrastructure?
- …kill off that server you use to run cronjobs?
- …auto-respond to emails from SES?
- …schedule automatic backups?
If you have an idea, but don’t know how to start, send me an email at ryan@serverlesscode.com and I’ll try to implement it, and feature it in a post here.