4 ms·

It's been mature enough for at least four years. 1. Not an issue for me. Connection reuse support in Lambda is quite good 2. NoSQL is a good skill to keep you

It's been mature enough for at least four years. 1. Not an issue for me. Connection reuse support in Lambda is quite good 2. NoSQL is a good skill to keep your in bucket anyhow. DynamoDB is a different approach, but much of the same tenets you'll find in other NoSQL databases still apply. Using tools like dynamodb-toolbox [1] help greatly with paradigm shifts into Dynamo. 3. True. Ask yourself how much this matters. How likely is it that you'll need to support another cloud provider for a single product? In 20 years I've seen a platform provider switch exactly once. And DynamoDB can be exported easily. 4. Nope. But there are things to learn about cold starts; how to structure code, where to initialize things, which things should be singletons, etc. 5. Depends on the situations and needs. The right tool for the right job, if you will. I've written GraphQL servers that run on lambda which serve 300k users daily. I've also done the same using Fargate/ECS et al. Much of the decisions revolve around complexity of execution and cost factors (e.g. the cost and complexity of running lambda's to process data often versus a Fargate service). You're getting into Software Architecture now. 6. Again, depends on the situation. You'll need to start thinking about what individual services/components/things are doing, what they need, and how they need to run. Gather that information, and then start cost comparisons using the pricing tools the provider has. [1] https://github.com/jeremydaly/dynamodb-toolbox https://github.com/jeremydaly/dynamodb-toolbox

ankush38u 4y ago
Connection reuse is good but when lambda env is killed, the connections become inactive and still lying around, the db connections aren't killed. We are looking to build a serverless tool and trying to understand if the market ready enough to finally move. Basically database compatibility with existing databases still seems like a big question : - Dynamodb's single table design has it's learning curve & hardly any availability of full text search, and much more complex stuff. - mongodb proxies are uncommon, and there is no pre build solution. ( even mongodb.com’s mongodb serverless and data api seems more like an incomplete products) - Rds proxy only available for database on aws. These are all concern, the existing app’s data in real world is sitting in databases on different cloud services be it mongodb, or sqls on GCP, Azure, DO or Aws. And without changing that database layer using serverless become really difficult and migration and change is difficult, nobody wants to do that if not must, so it feels dbs are not ready still in 2022. What’s your opinion on this?

ankush38u 4y ago

Connection reuse is good but when lambda env is killed, the connections become inactive and still lying around, the db connections aren't killed. We are looking to build a serverless tool and trying to understand if the market ready enough to finally move. Basically database compatibility with existing databases still seems like a big question : - Dynamodb's single table design has it's learning curve & hardly any availability of full text search, and much more complex stuff. - mongodb proxies are uncommon, and there is no pre build solution. ( even mongodb.com’s mongodb serverless and data api seems more like an incomplete products) - Rds proxy only available for database on aws. These are all concern, the existing app’s data in real world is sitting in databases on different cloud services be it mongodb, or sqls on GCP, Azure, DO or Aws. And without changing that database layer using serverless become really difficult and migration and change is difficult, nobody wants to do that if not must, so it feels dbs are not ready still in 2022. What’s your opinion on this?