While Functions as a Service (FaaS) has been around for a bit, the "serverless" buzz has continued to mount in the last year or so. The version AWS offers is called Lambda, and it's quite interesting.

I've worked a bit with Lambda before, so I know a little bit about how it works from a "normal" AWS account. I might do a tutorial runthrough on how to set it up, but not in this entry -- this will be more high level.

Lambda, like any FaaS offering, only charges you for the compute and memory you use when you are running; so the leaner your program is, and the faster it runs, the less you pay. You don't pay for idle time when your program is just waiting for clients to touch it, and (mostly) things scale up to whatever demand you might have. For a lightweight service, API or startup exploring options, these are all interesting options.

What can be tough it to understand errors and limitations imposed by the scaffolding that runs Lambda. On a conventional account, adding some Lambda functions lights up the account like a Xmas tree -- you have (small) entries in 8 categories. It's not as clear due to the setup in the AWS Educate account where you are touching, and how things are tied together. For instance, I hadn't used the logging bits in AWS before experimenting with Lambda, but without them it'll be harder to do debugging and catch errors in your code.

While I'm still a bigger fan of conventional VM processes, I can see the use case and understand the upside of Lambda/Serverless, and I'll be playing with it a bit more. It's definately a service that you can explore pretty fully as part of the Educate account.