Quick clarification: No need to go through API Gateway if you don't actually need the https endpoint - all AWS SDKs can hit Lambda's REST APIs directly, which also reduces p50 latency.
@hobofan, take a look at our recent API Gateway features and see if the greedy paths and pass-through settings provide what you're looking for (they're also supported by CloudFormation). We tried to simplify the "configure every route" problem, but always looking for additional suggestions to make API config easier.
@jomamaxx (& others): Reducing latency (and latency variability) is a critical goal for our team. We've improved p99 variability in API Gateway-related latency over the last few months, and will be addressing some of the Lambda-related latency that occurs when we refresh containers in the coming months. Additional latency optimizations coming at all levels of the stack, including networking.
A clarification on the discussions about "managed hosting": Lambda is not classic web hosting; in fact, we block Lambda functions from calling socket.listen. In the Lambda model (whatever you prefer to call the broader category), the cloud service sees every request in order to perform scaling and load balancing on the function's behalf.
Happy to chat offline with anyone who has additional questions or feedback: DM me on twitter @timallenwagner
Tim, when are we getting Python 3 support on Lambda?
Being stuck on 2.7 has been the greatest source of issues and the #1 problem we have with Lambda. If Google/Microsoft came out today with Python 3 support in their Lambda competitor, we'd move in an instant.
I'm in the same boat. We're developing a new product with no real reason to stay on Python 2, besides Lambda. Python 3 support would make my life so much easier.
Yep, I hear about the lack of Python3 all the time, and I know our Python users are waiting for it. On the roadmap, and partially complete, but competing with some other language work at the moment.
I would want to know, how do I manage user credentials in AWS lambda. Lambdas are stateless, there is no session, so how do I keep track of which user is executing the current lambda?
How do you do it with a load balanced stateless web server? People have been doing this 10 years, most language should have some frameworks or plugins around it....
Common is to give the client a cookie with a session id (KJASDJKASDASDS) in a cookie. Then in a RDBMS you store this (session KJASDJKASDASDS = User 1234)... and the first part of each web (or lambda call), you go look up the user by session and know who it is.
(You can also store the user ID directly in an encrypted cookie, but that has a few other problems)
Just curious, what would be the major drawbacks of not using relational here? My understanding is that AWS is pushing Dynamo quite a bit and it seems cheaper, so if they're only needing to query off of session id and maybe user id, shouldn't that be sufficient?
Relational is super handy. Very easy to report on and do various things down the road.
If all he needed was session id, sure, NoSQL is more or less the same. But what about when he adds other fields that are related? Say customer address or reports or .... His life may very well be easier with relational.
You should generally start relational. Then branch out if you are hitting the brick walls of relational. People using NoSQL for a 100MB database are making their life SERIOUSLY more difficult than it needs to be. (I have done it before, not fun).
1) A NoSQL DB for the main data providing replication and scalability(e.g. Cassandra or DynamoDB).
2) Another DB for quick access and transient Data where replication is not so important, e.g. storing the session cookie. Relational vs Non-relational would not be an issue since I'm only storing very little data here and want fast access and minimize costs(in DynamoDB you still have to pay per operation). Therefore I'm looking for some simple solution like ElastiCache.
I'm doing a social networking site, so I don't know how much data I will end up with. My reasoning was as follows:
1) The data model is rather simple, basically one table with the user data(name, location, age, etc...) and some images. So it shouldn't be too difficult to do this with NoSql as opposed to SQL. Yes, simpler with SQL but not significantly so.
2) If I ever need to scale, I'd rather make the right choice from the beginning(NoSQL) so as not to need a migration later.
3) In any case NoSQL would be a learning experience for me, so another plus.
If there is a mistake in my reasoning I would be grateful for any one pointing it out.
The point is "serverless" is a sham. Your clients still need to rely on another service API Gateway to communicate with the outside world. So stop with this stupid marketing.
Your are selling a basic pubsub architecture as something "innovative" when the only real innovation is the pricing. That's the exact definition of marketing, and at the same time you are making the community of web developers sound like idiots that don't understand what a server is. You can make plenty of money without being missleading, why do you feel the need to use a misleading language ?
Of course there's a server, or do you think you're the only genius in the room who understands client server communication? "Serverless" is a legitimate phrase to describe a growing phenomenon. Most reasonable people read "serverless" as "server I don't have to admin", not "there is no server". No one wants to read your pedantic bloviating, get over it!
> Most reasonable people read "serverless" as "server I don't have to admin"
Most reasonable people find the "serverless" moniker obnoxious to begin with. If something doesn't require administration then call it "adminless", not "serverless"
Suboptimal ;-). This is a common request, and we're looking at options for a config feature that's independent of the code payload. Tweet or email me detailed suggestions/asks for it: @timallenwagner or timwagne at amazon.com.
Why not inject it to `context` parameter in some variable with known name? As long as the field is exposed to CF and in the panel, it should be all we need.
This is great feedback encoderer. We're going to keep iterating fast to make deployment, packaging, and global (cross-region) updates even easier for AWS Lambda.
Appreciate the feedback/suggestions! We'll take a look at expanding the disk space, probably as part of the "power level" adjustment that already affects memory, CPU power, etc.
AWS Lambda supports nodejs and jvm-based languages (Java, Scala, Clojure, etc.) directly, and lets you run Python, shell scripts, and arbitrary executables as well. We started with nodejs because it worked nicely for expressing our initial launch scenario, event handlers.
yes - I am aware that you support Python, etc. .. but nodejs is your first class language. For example, even your docs only mention nodejs (and java recently) [1]
what is even more interesting is that you felt it worked nicely for expressing event handlers. Can you talk a bit more about that - very interesting to see why not something like python or ruby. I know that nodejs is a callback-oriented framework... was it the fact that you can test locally on nodejs consistently versus what would be the expected output on Lambda ?
Tldr: Only if your events are extremely infrequent. With an inter-event arrival rate of seconds to few minutes, your jvm processes get frozen and thawed out the vast majority of the time to avoid the initialization/load overhead that would otherwise result.
