21–30 of 100 posts
Earlier quoted context omitted.
*It allows devs to create those apps _within a VPC_. You could always have fast startup with Lambda + database outside the VPC.
Also, wasn't Aurora Serverless created because of that problem?
This is huge for Lambda. It allows devs to create “serverless” apps [1], with relational databases, without 10+ second cold-start times. In the article, they measure it as 988ms. I have tried building an API using API Gateway Lambda, but had to choose between using DynamoDB to store data (no-SQL, so challenging to query) or suffering unacceptably long response times whenever a request happens to cause a cold-start. T…
*It allows devs to create those apps _within a VPC_. You could always have fast startup with Lambda + database outside the VPC.
I think it’s best not to expose the DB to outside connections in general, although it is still possible [1] when using RDS instances.
I think this is different for things like DynamoDB because, instead of a standard SQL-like db “connection”, they use AWS role-based auth for each request.
Of course, one could always configure some type of proxy service between the lambda and the DB... but that seems antithetical to going “serverless” in the first place.
[1] https://stackoverflow.com/questions/45227397/publicly-access...
Edit: I thought it was not possible to expose an RDS instance outside of a VPC, but I was wrong (you can place it in a public subnet, linked in [1]).
Earlier quoted context omitted.
*It allows devs to create those apps _within a VPC_. You could always have fast startup with Lambda + database outside the VPC.
Also, wasn't Aurora Serverless created because of that problem?
[1] https://forums.aws.amazon.com/thread.jspa?threadID=288043
Iconoclast view ahead (change my mind please): AWS does tons of stuff around VPCs....I feel like they really want me to use them (or their customers really want to use them), but I just don't see why. I just run RDS on the internet. I don't have to muck with the complexity or cost of NATs or peering or Lambda slow start or any other weird networking issues. I know it's "public", but that seems irrelevant in the era o…
This solves one part of the cold start problem. Starting the container and loading the image on to it is still going to cause some latency.
Overall, definitely a big win!
This solves one part of the cold start problem. Starting the container and loading the image on to it is still going to cause some latency.
This solves one part of the cold start problem. Starting the container and loading the image on to it is still going to cause some latency.
Which can be mitigated by invoking your own Lambda functions once every minute or 5 minutes. Usually does not blow the budget.
There has never been a guarantee of environment reuse. Any architecture which isn't capable of incurring cold starts is not a good fit for serverless.
This solves one part of the cold start problem. Starting the container and loading the image on to it is still going to cause some latency.
You can connect API-Gateway with other services via Velocity templates, which don't have cold starts.
AppSync also doesn't suffer from cold starts.
Both are also serverless services.
Lambda is good if the other solutions are missing something, so you can drop it in quickly, but I wouldn't use it as the go to services for that...
Earlier quoted context omitted.
So making the actual listening port for a database server "public" is generally a bad idea as that is another attack surface of code that honestly is hardly ever made public... but if when you say "public" you mean you are using security groups (which are super trivial to use and easy to understand) to define which other AWS devices can access the port, then yeah: I have never seen any reason why this entire feature…
My theory is that a bunch of entrenched network engineers just really like subnets and IPv4 and NAT and don't realize how mostly unnecessary it is in an era of cloud infrastructure and IPv6. My grandchildren are still going to be NAT'ing.