No need to look so far. The logo for Half-Life was always the Greek letter lambda (certainly because it's often used in physics and chemistry to represent the decay constant, which is a simple function of half-life). And that level is probably just named in keeping with the game's identity.
I still remember when my chemistry teacher first drew a lambda on the chalkboard and said "this will give us the half-life". I felt like all the pieces finally came together in my life.
Yes. It's adorable. Now all we need is an open-source service compatible with AWS lambda that can run on your own servers. We could call it... freeman.
Yes, I know that defeats the point of using lambda, but I felt the joke was worth it.
> Yes. It's adorable. Now all we need is an open-source service compatible with AWS lambda that can run on your own servers. We could call it... freeman.
i would like to see an libre software serverless service. one huge concern of AWS Lambda is being locked into AWS's goodwill.
If you're interested in dirt simple Lambda deployment, check out Kappa[0], written by the same person as boto.
Gordon looks interesting and I'm definitely going to check it out, but from what I can tell, one of the downsides is that it uses CF.
Don't get me wrong, I love CF for it's reproducibility, but waiting for a CF stack to run on every deploy will be frustrating for rapid iteration. CF is great for managing your infrastructure once you have a good idea of how it should look and aren't making constant changes anymore.
I suspect my workflow will be something like using Kappa while I'm iterating, and then using Gordon for the final deployment once it looks like everything is working as expected.
Can Kappa support custom versions and aliases? That's been one thing I haven't seen able to be controlled via kappa config or command line, and it's been the reason I haven't used it.
I've got multiple lambda functions that need to be associated with each other for an AWS Simple Work Flow. For CI I've it set up to update the versions of each lambda in a project repo. During packaging and deployment I inject the configuration of the git sha so that the next lambda function in the workflow that is called is consistent. Once the new workflow lambda call-chain is in place I can test / validate the new environment and then roll over the lambda that starts the workflow.
What I need to make sure of is that all the lambda functions / roles are updated before the starter so that the workflow doesn't break, as there could be breaking changes between commits.
A suggestion would be to create a repo per lambda function, but that becomes a hassle to manage after a few dozen, and just throws in even more work on ensuring the order of updates necessary. It is easier to flow between commit versions.
Yeah serverless is a little smarter and directly uploads lambda functions.
The main reason I don't use serverless is because it's geared towards web development -- the lambdas and the api gateway are tied together. Most of what I'm doing is not web based.
I think the people from serverless (and apex) are doing an amazing job evangelizing about the benefits of server-less infrastructures and they have amazing projects they should be quite proud of.
Than been said, I think both projects walk different paths in order to achieve similar goals.
What is different with other approaches?
* Isolation is one of the most important things for us. Each of the stages of your application are deployed into independent Cloudformation stacks.
* We don't stream commands to the AWS api. Every single of your resources are created using CF.
* We respect the tooling of each of the runtimes so javascript, java or python developers should not get exposed to software they are not use to.
* Convention over configuration. Perhaps this is because my background is the Python/Django ecosystem, but writing 200 lines configuration files in JSON feels completely wrong to me.
* Documentation documentation documentation: Again, perhaps I've been badly educated by the Django community, but documentation and examples are (for me) the most important thing a project like this should have. That's why gordon's documentation is quite complete (I would say) and we have more than 20 example project including integrations with Slack, Telegram, Twilio... and AWS services such as Kinesis, Dynamodb, Apigateway, S3, Cloudwatch Events, Cloudwatch Scheduled Events, etc...
I think is an amazing moment to be involved in the server-less community and we'll all benefit from a thriving ecosystem like this :D
Great work on this. We're actually moving in a similar direction at Serverless with full Cloudformation support in our current development branch for all the reasons you listed. Would love to chat sometime, email is in my account page.
FWIW, I've been using serverless the last couple of weeks and I find the request-response parameter mapping absolutely maddening.
Most of us have become used to frameworks like express for specifying our routes and manually specifying API gateway rules feels like a huge step backwards.
Messing with Gordon now, but I've messed with nearly every other serverless framework. If you're looking for something express-y then you might like claudia.js's ApiBuilder, but the underlying API Gateway is always the lowest common denominator so this just adds some prettiness on top. https://github.com/claudiajs/claudia
This is great. I wish this was around 8 months ago when I built lambda infrastructure at Cronitor. Local invocation, multi region deploys and config management all took far too much development time.
Agreed, doing all that crap myself has been my biggest complaint about AWS Lambda so far. I can't understand why Amazon doesn't offer something like this as part of their CLI tools.
