
Support for tagging of Lambda functions and for the Python 3.6 runtime - muramira
https://aws.amazon.com/releasenotes/5198208415517126
======
ak217
This is awesome. If you're deploying stuff with Python on Lambda, I highly
recommend checking out Chalice
([https://github.com/awslabs/chalice](https://github.com/awslabs/chalice)) and
also an extension to it that I wrote for using Lambdas on SNS/S3/Cloudwatch
events or scheduled events -
[https://github.com/kislyuk/domovoi](https://github.com/kislyuk/domovoi)
(which I now need to go update to support this as well).

~~~
Mizza
Zappa can do all of that and more out of the box:

[https://github.com/Miserlou/Zappa](https://github.com/Miserlou/Zappa)

Comparison: [https://blog.zappa.io/posts/comparison-zappa-verus-
chalice](https://blog.zappa.io/posts/comparison-zappa-verus-chalice)

It also lets you build fully-fledged event-driven apps with a single line of
code: [https://blog.zappa.io/posts/zappa-introduces-seamless-
asynch...](https://blog.zappa.io/posts/zappa-introduces-seamless-asynchronous-
task-execution)

~~~
brian_herman
Zappa is amazing I am currently using it to make an alexa app.

------
scrollaway
Finally!! Thank you Amazon.

... I know what I'm doing tomorrow.

Edit: I know what I'm doing today.

------
abhirag
Finally
Zappa([https://github.com/Miserlou/Zappa](https://github.com/Miserlou/Zappa))
would be able to support web services written in python 3!

~~~
ak217
I much prefer Chalice
([https://github.com/awslabs/chalice](https://github.com/awslabs/chalice))
which just got a synchronized release supporting Python 3 as well.

~~~
scrollaway
Have you tried both? Can you explain what you prefer in Chalice over Zappa?

~~~
ak217
Yes. In my impression Chalice is designed to be a microframework (emphasis on
_micro_ ) with the bare minimum of glue necessary to make deploying Lambda
apps easy. Zappa is designed around an ill-fitting API (while WSGI is
widespread, it's clunky and a layering violation of sorts when put in the
Lambda runtime environment) and has a development philosophy that I don't
agree with.

------
INTPenis
Yeah but in what region? As a european I've been disappointed before by lack
of python support in european regions.

Edit: Just noticed in my AWS account that there's 3.6 in Europe. This will get
me away from GCP.

~~~
StreamBright
Is there a particular reason of getting away from GCP? I am just curious.

~~~
INTPenis
Grass is greener and I already have two major projects that require me to use
python 2, excl. ansible modules, so I don't want more.

I want to use european regions for my testing, not us.

Other than that I find the GCP interface easier to work with, when it's
working.

I'm eager to try AWS.

------
nikolay
No CloudFormation support for tagging and embedding python3.6 code in the
templates - they really do their best to push us away from using
CloudFormation!

~~~
svdgraaf
They do get their tags automagically from the CF stack, right? (haven't tested
it myself, but that's usually what happens)

~~~
nikolay
No, they don't. You can't even specify template-level tags in the template.

I think they have very incapable developers on the CloudFormation project.
This could have been a game changer, but it's been a source of pain.

For example, they introduced YAML, and !Sub, but you can nest tags, yet,
!ImportValue in many cases needs a nested !Sub. So, also, you can't have "$",
"{", and "}" characters in the exported name, but they didn't add string
templates to functions such as !ImportValue. Total nonsense!

Also, as you've assumed logically, all stack resources need to inherit the
tags of the owner stack, but no, you have to do tons of copypasta!

Last, but not least - it's all designed that the templates are stored on S3 -
most people use source control. Their other services already support Git -
Elastic Beanstalk, CodeBuild, CodePipeline, etc. Why they don't allow Git-
hosted templates?!

Anyway, when I see the complexity of my templates to have a basic Magento
infrastructure running in VPC, which I've been working on, it's very
disgusting. Lots of manual steps if you don't want to have a monolithic
template, lots of CLI, and build steps. This is not how things like these
should be implemented in 2017!

Lastly, they introduced CloudFormation exports. Okay, decent feature, but not
in the real world! So, if you refactor your infrastructure, it becomes a huge
pain as you cannot delete exports for some reason - they belong to the stack.
So, if I decide to rename or split an export, I need to have an intermediate
step, which duplicates the old and the new exports, I updated all importing
stacks, to use the new values, and so on. Most AWS resources have "retain"
capability - S3 buckets, ECRs, Route 53 records, etc. - CloudFormation exports
don't! Honestly, they need to put some more experience and brighter developers
on the team!

------
andrewstuart
It was strange that it ever supported Python 2 given how recent the AWS Lambda
Python product is - they could have avoided the support burden of Python 2
entirely.

------
m23khan
Thank you AWS Team!! Can now look forward to moving ahead with python3 dev
fully

------
abalone
Maybe tangential but how do people feel about implementing a typical RESTful
database API in Lambda & API Gateway?

Most of the prototypical examples of Lambda I see are for things like data
processing pipelines. I know _in theory_ Lambda should be able to handle just
about any kind of request from a browser or mobile app short of a websocket
connection, and Amazon does have some sample code and a brief case study on
their site. But I'm wondering if it's really ready for this or if people have
experiences going near-100% serverless for their apps.

~~~
andrewstuart
I've built a complete web application that is entirely serverless except for
the database - I have an instance running Postgres. This is because Postgres I
the only database I want to use because it always meets my needs.

Everything else is serverless however.

My application has:

\-- AWS Cognito as the user management and auth

\-- AWS Cloudfront serving a Reactjs front end as static files

\-- AWS EC2 running Postgres as the database

\-- AWS Lambda Python functions for the back end

\-- AWS SES serverless email inbound and outbound processing

\-- AWS SQS for email processing coordination

Oh I do in fact have another server which does spam checking of emails, PDF
conversion of emails, text extraction of emails and parsing of emails - this
works best on a server rather than serverless.

The most interesting thing I found along the way is that the API gateway
(which I liked a whole lot by the way, and found to be powerful and easy to
configure) is completely unnecessary. My application simply directly calls the
Lambda functions to get and set the data that it needs - dramatic
simplification.

Of further note is that I only have one Lambda function for the entire back
end - this further reduces the need for layers of APIs and parameters. All my
Python code goes into the one function which is structured as a complete
application. An additional benefit of this is that AWS Lambda can be slow to
first run a function unless it is "warm". If you have lots and lots of small
Lambda functions then any given function is less likely to be warm. With
everything in the one Lambda function, then all parts of my Lambda function
are more likely to be warm.

So no API gateway completely rips out an entire layer of complexity, and then
only one single Lambda function rips out another layer of complexity. It's
very nice to be able to write front end functions in ReactJS that just call
the back end function that they need. Making changes means I just change the
functions and don't need to fiddle with all sorts of REST API layers or
anything to accommodate the change.

I started with node.js as the Lambda back end but switched to Python because
personally I find that Python with its synchronous programming model is much
easier to reason about for back end stuff. I'm more than happy using ES2015 at
the front end for ReactJS.

~~~
derivagral
Is this a hobby project? What ballpark are your hosting costs? I left AWS for
Heroku after they wanted over $50/mo for postgres+route53+ec2 small; if Heroku
got expensive for me I'd hit something like Linode/DO before AWS at this
point.

As a reference, this is for non-revenue generating hobby sites/projects.

~~~
andrewstuart
Well it's intended to make money, although not finished yet.

So I don't know what the costs but I don't imagine much.

------
braidenj
CloudFormation has developed support for Lambda tagging, Python3.6 and
Node6.10 inline code and it will be part of our next release. Keep an eye on
[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ReleaseHistory.html)
for more details.

------
jgill
What about Python 3.6 support for ElasticBeanstalk?

~~~
kinghajj
At least you can use the Docker environment type and deploy your own image
with Python+your code.

~~~
Alex3917
If you want to spend multiple weeks rewriting your deployment process. EBS
promised a new Python image a few months ago, and now that Django 2.0 is going
to drop support for 3.4 by the end of the year it's getting to be time for
them to deliver on that.

------
IanCal
Well this will drastically clean up some code I've just written! I was using
2.7 for the lambda code and 3.x for the rest of the processing.

------
Rapzid
It's a shame boto3 doesn't support async...

------
wahnfrieden
Tangent: anyone find a satisfactory way to do blue/green or canary deployments
with Lambda?

~~~
mason55
Create a new alias with a unique ID for each lambda deployment. Then manage
your application to point at the proper alias. Roll out just becomes updating
the apps however you update them normally.

------
QuinnyPig
Don't bury the lede; we get tagging too!

~~~
sctb
Thanks, we updated the title from “AWS introduces lambda support for
python3.6” a little while ago.

