[![GitHub license](https://img.shields.io/badge/license-BSD-blue.svg)](COPYING) ![Python Versions](https://img.shields.io/badge/python-2.7%20%7C%203.3%20%7C%203.4%20%7C%203.5-green.svg) ![Beta](https://img.shields.io/badge/status-beta-orange.svg) [![PyPI version](https://badge.fury.io/py/gordon.svg)](https://pypi.python.org/pypi/gordon/) [![Travis Build](https://api.travis-ci.org/jorgebastida/gordon.svg?branch=master)](https://travis-ci.org/jorgebastida/gordon) [![Join the chat at https://gitter.im/jorgebastida/gordon](https://img.shields.io/badge/chat-on%20gitter-blue.svg)](https://gitter.im/jorgebastida/gordon)
Gordon is a tool to create, wire and deploy AWS Lambdas using CloudFormation
We think documentation and examples are an important pillar… so here you have a nice list of things you can play with!
Because this project doesn’t introduce anything new. Gordon is just a thin layer of sugar around AWS services and few conventions, which makes deploying and wiring Lambdas really easy.
Under the hood, gordon just generates self-contained CloudFormation templates… which is great!
Why introduce yet-another framework when you can build lambdas using AWS services and tools you already know how to use (pip, npm, grunt, gulp, gradle, Makefile…)
Keep it simple! 😀
Yes, we believe that there must be 100% isolation between your application stages (dev, staging, prod…). That means that resources which (for example) serve a development purpose must not be related to the ones which are serving production load.
On example of this is that it is an AWS [best practice](http://blogs.aws.amazon.com/security/post/TxQYSWLSAPYVGT/Guidelines-for-when-to-use-Accounts-Users-and-Groups) to use different AWS accounts between stages. Although this is not required, it makes evident that mixing resources between stages is a bad idea.
This completely clash with the suggested approach for services such as apigateway, where they emphasize to have several “stages” for the same apigateway resource. We disagree and completely ignore that functionality because we believe is the wrong approach.
Gordon keeps reproducibility and isolation at it’s core. When you apply gordon projects in different stages or regions, you’ll deploy completely isolated Cloudformation stacks which will contain an exact and isolated copy of all the resources you have defined.
One of the best advantages of using AWS is the fact that reproducibility is at it’s core and their ecosystem is full of services which encourage it. Their flagship is CloudFormation.
Then… why not just use CloudFormation? Well, there are three reasons:
This project tries to solve these three issues by:
Yes, we eat our own dog food; We use gordon to create gordon. The idea is that, (unlike many other projects) we don’t think streaming API commands to AWS is a nice solution, so instead, we fill the gaps with custom CloudFormation resources.
Those Custom CloudFormation resources are implemented using Lambdas (deployed by gordon)… crazy uh?!
Why all this madness? Again… because reproducibility. If you manage some resources using CloudFormation, and some others streaming API commands, if/when you try to reproduce or decommission your environment… you are pretty much f***.
We would love to hear as much feedback as possible! If you have any comment, please drop me an email to firstname.lastname@example.org
TODO: Figure out how to actually get changelog content.
Changelog content for this version goes here.