neo2001

6:29 PM PST We have identified the root cause of the DNS resolution issues in the EU-WEST-1 Region and continue working towards resolution.

sigh

Oh yes there is :D

(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

I think the people from serverless (and apex) are doing an amazing job evangelizing about the benefits of server-less infrastructures and they have an amazing project 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

(Author here)Any feedback about this project would be much appreciated! Hope this tool is useful for somebody out there!

It makes it easy to deploy Lambdas and integrate them with those services. Underneath uses CloudFormation to orchestrate it

Don't want to hijack the thread (sorry) but I've been working for the last 10 months in a tool which might be of the interest of people reading this article.

This tool will be opensource in the following weeks, but at the moment is in closed beta. I'm looking for people interested in giving it a look. If you are interested, drop me an email to me[at]jorgebastida.com and I'll invite you to the repo.

tl;dr version: Dead simple Lambda+Kinesis+Dynamodb+S3+CloudWatch+Apigateway over Cloudformation with support for Python, Javascript, Java, Go etc... Lot's of examples including Telegram, Twilio, Slack... and quite extensive documentation (which I think is the key of adoption of a technology like this).