[nulagrithom]

Wondering if I could use this like SQLite for Lambdas. I'd like to build some serverless apps, but the commitment to a monthly fee from DynamoDB puts me off. Could I use Athena to drive down my cost to zero as long as the app is unused?

[asteadman]

Note the 10MB minimum "charge" per Query. For small datasets under 10MB, you'd only get up to 200 Queries for the minimum billable $0.01. That would be a fairly small number of queries, so probably not that useful. Plus you'd have all kinds of issues regarding consistency if your data was dynamic (s3 is a blob store, not a database, normal s3 consistency guarantees still apply).

I'm confused though. The monthly fees for dynamodb only apply after you exceed the free tier, and for someone who is unable to commit to a monthly fee because they envision low usage, shouldn't the free tier be sufficient? (Honest question, I'm looking at using dynamodb, but comments like this make me think I'm missing something)

[nulagrithom]

Only thing you're missing is that I didn't realize DynamoDB's free tier was a non-expiring free tier.

[brilliantcode]

DynamoDB is like $5 or $10 bucks a month? but I understand the need to keep it to a minimum.

Athena is really interesting and if it can be as it is advertised "Serverless SQL" then they've got a killer product in the pipes: A future where developers no longer need to spend time on scaling, configuring, maintaining, strategizing deployments but upload code and instantly begin reaping the benefits of serverless tech.

The only missing component that would be a killer feature is something that answers to Azure's Active Directory. It would be nice if we had serverless plug-and-play user authentication and access control that integrated with Lambda and Athena.

I'd imagine some sort of "RoR on Serverless" type of framework that will scaffold out CRUD, User Management & REST Api is going to be in the works as well.

The only potential downside I see at the moment for Serverless is the uncertainty surrounding cold boots, it will directly affect user experience. It's fine when you got enough traffic to keep things in the "warm" state but there needs to be no dead zone when the call to the API Gateway is taking many seconds waiting for Lambda function to fire.

[sciurus]

Just because you can query it with SQL doesn't make it a relational database suitable for use for OLTP. Athena is built on Presto, so see https://prestodb.io/docs/current/overview/use-cases.html for an explanation.

[asteadman]

Re: users auth. Isn't that what Cognito is supposed to be? I mean, I don't fully understand it, but I think so.

As for the cold boot issue, I thought the standing solution was to have a "fast-exit" ping-like code-path within the lambda. Query it on a regular basis (you can even do it with a lambda scheduled-event). That way your lambda should be kept warm.

[brilliantcode]

TIL Cognito!

That completely flew under my radar, not sure why I didn't see it before (oh that's right I was heads down in Azure).

With Athena the circle is complete for me.

That fast exit ping thing is pretty cool, any more information regarding that?

Your comment is probably the most valuable one I came across to date since signing up, I wish there was a way to award a gold star like on reddit :D

There's very little objection at this point in moving to a Serverless architecture = Athena (SQL) + Lambda (CPU) + Cognito (User).

[asteadman]

What's your usecase for Athena (Really curious how this changes anything)?

You can hook your lambda up to a cloudwatch scheduled event (http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Sc...). If you don't do much when this happens (like, you exit immediately), then you won't be charged much compute time. Can't find the reference to how often you should ping it to keep it warm, probably varies, IIRC hourly would be plenty.

[brilliantcode]

building user management, security has always been a "build your own wheel". While I think a properly secured SQL table with encrypted keywords is certainly possible the risk remains. We see even for prolific and large websites their entire user tables are dumped online on a regular basis.

Off-loading this burden on a cloud vendor whose sales are directly tied to the security, gives me peace of mind. Ashley Madison had no financial incentive to keep their user base as secure as possible or actively defend against it using R&D. Yahoo Mail as well. But AWS and Active Directory are products that sell this security and for them to fuck up on an epic scale would mean their end.

so the tldr is piggybacking on the tremendous resources from a cloud giant which frees up resources to focus on the core product.

This is not to say that it's impossible to roll out your own wheel, I'm just saying it makes more sense to align the financial incentives of vendors maintaining the user base security. This may or may not mean I'm open to focusing on companies solely focused on user auth/management products, it's tough to beat the branding and trust built into AWS & Azure that developers are voting everyday with their money & data.

[xmly]

My solution currently is : Aws API gateway + Cognito + lambda + DynamoDB for webservice. S3 for html/css/js. CodeDeploy + Cloudformation for deployment.

Athena does not gurantee for timing, use it for async call and offline processing

[brilliantcode]

super cool! would love to find out more about your workflow using those AWS components.

what did you mean by your last sentence?

[gbrits]

Not OP, but athena returns results for most queries in a couple of seconds (quote is somewhere in the blogpost) this would likely not be enough for your typical request/response flows.