
Gordon: a tool to create, wire and deploy AWS Lambdas - timf
https://github.com/jorgebastida/gordon
======
m_mueller
Is the name a reference to Half-Life / Gordon Freeman due to its lambda
complex level?

~~~
pierrec
>due to its lambda complex level

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.

~~~
marxidad
Half Life one confirmed

~~~
fapjacks
Heh! Here, have an upvote.

------
johnwheeler
Starred. This looks fantastic. I've been exploring lambda deployment options
for my new Alexa skills kit library, since Amz pushes lambda.

[https://github.com/johnwheeler/flask-
ask](https://github.com/johnwheeler/flask-ask).

Can you please explain any differences over Zappa and if you're deploying
flask?

Oh, and the project name is oh so damn cool.

------
jedberg
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.

[0] [https://github.com/garnaat/kappa](https://github.com/garnaat/kappa)

~~~
Leon
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.

~~~
jedberg
It doesn't support custom versions and aliases yet. Curious what your use case
is.

It sort of does custom aliases by giving the function an alias with the
environment name, but that probably isn't what you want.

~~~
Leon
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.

------
nzoschke
This looks great.

I'm particularly excited about the CloudFormation support.

If you're managing stuff on AWS without CloudFormation you're missin out on
one of the most powerful features of the platform.

CF can be pretty hard to use, which is why I love seeing OSS projects that
solved the tedious parts of it for all of us to use.

------
buremba
+1 for support of local execution of lambdas.

------
jwerle
what about github.com/apex/apex ?

~~~
neo2001
(Author of Gordon here)

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

~~~
matlock
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.

~~~
orasis
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.

~~~
rajington
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](https://github.com/claudiajs/claudia)

------
encoderer
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.

~~~
robterrell
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.

------
rajington
Added: [https://github.com/anaibol/awesome-
serverless](https://github.com/anaibol/awesome-serverless)

------
fiatjaf
Why not
[https://github.com/Miserlou/Zappa](https://github.com/Miserlou/Zappa)?

~~~
hltbra
Zappa is web-specific (API Gateway + Lambda). Gordon seems to be more
generalist: it's for whatever you want to run on AWS Lambda.

------
jayzalowitz
How does this compare to serverless? (full disclosure, we are starting to use
it a ridiculous amount at fanatics)

~~~
juanriaza
check
[https://news.ycombinator.com/item?id=11821474](https://news.ycombinator.com/item?id=11821474)

------
jimpick
Nice work! Potentially I could use this to deploy lambda-comments. :-)

