Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless Best Practices

medium.com

Post reply on HN
Print view View original

11–20 of 104 posts

Re: Serverless Best Practices

#11

Post by actuator »

tachang wrote: post #4
tomcam wrote: post #2

I still don’t understand how you do a PostgreSQL insert on a serverless system—please help! Also, this statement is patently silly: > The biggest point to make here is that serverless architecture may well require you to rethink your data layer. That’s not the fault of serverless. Well, it is the fault of serverless. It’s a shortcoming. Own it. The trade off may we be worthwhile, I just can’t tell yet. I’m trying to…

I agree with this. Having a traditionally relational store can be a huge help: lots of people know it well, the disadvantages are well known, and everything is insanely mature. I dislike how the article tries to say that isn’t serveless’s fault when it is just a trade off.

Yeah, RDBMSs do have some big advantages; one of them being the plethora of query patterns possible.

If there are other parts of your application which are consuming the same data but in different patterns, it might not be necessary that systems like DynamoDB work in those cases. You might need to make several secondary indexes in those cases and all of them require provisioning of their own. The other alternative being setting up some ETL layer which transforms the data and sends to appropriate sinks, from where they can be consumed; but for small services that adds more moving parts and cost to the system.

Re: Serverless Best Practices

#13

Post by tylerhou »

Agebor wrote: post #9

I would rather disagree with these practices. Some of them are subjective and some will likely be outdated soon. > Each function should do only one thing. The problem with one/a few functions running your entire app, is that when you scale you end up scaling your entire application. Sure, but is that a problem in general? Same thing can be said about a monolith vs microservices, and there is always a trade-off. A fun…

> Functions don’t call other functions

I think this point may might also be about reducing complexity, not just cost. Pushing to a queue instead of directly calling another function decouples the two functions and might make it easier to reason about how logic flows.

Re: Serverless Best Practices

#14

Post by Agebor »

actuator wrote: post #10

He mentions DynamoDB for the data layer instead of regular RDBMS. I have tried to use DynamoDB several times but have been disappointed with it. I am not saying traditional RDBMSs solve the problem that DynamoDB has, but even DynamoDB is a poor fit for systems with rapidly changing load patterns. Some things that have been big pain points while using DynamoDB: - It has autoscaling built in now but even that leads a l…

Not sure what do you mean about scaling storage layer separately from the compute layer. It's how it's usually done currently, with the disk being the storage layer.

As long as there are machines/containers to be started, there will always be some latency, though we can expect it to improve in the next years.

AWS now has the Aurora Serverless, though I don't have any real-life experience with it's latency yet (VPC requirement is a downer for now). https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

Re: Serverless Best Practices

#15

Post by GuB-42 »

> If you’re not aiming to scale that far, then you can probably get away without following these best practices anyway.

If you don't intend to scale beyond what a server can offer (which is a lot!), you probably shouldn't be "serverless" in the first place.

Re: Serverless Best Practices

#16

Post by Agebor »

tylerhou wrote: post #13
Agebor wrote: post #9

I would rather disagree with these practices. Some of them are subjective and some will likely be outdated soon. > Each function should do only one thing. The problem with one/a few functions running your entire app, is that when you scale you end up scaling your entire application. Sure, but is that a problem in general? Same thing can be said about a monolith vs microservices, and there is always a trade-off. A fun…

> Functions don’t call other functions I think this point may might also be about reducing complexity, not just cost. Pushing to a queue instead of directly calling another function decouples the two functions and might make it easier to reason about how logic flows.

True, might make it easier in some cases. This is a general architecture decision, unrelated to serverless.

Re: Serverless Best Practices

#17

Post by deeg »

tomcam wrote: post #2

I still don’t understand how you do a PostgreSQL insert on a serverless system—please help! Also, this statement is patently silly: > The biggest point to make here is that serverless architecture may well require you to rethink your data layer. That’s not the fault of serverless. Well, it is the fault of serverless. It’s a shortcoming. Own it. The trade off may we be worthwhile, I just can’t tell yet. I’m trying to…

Agreed. Perhaps the first thing a "best practices" post should start off with is what kinds of problems serverless is best suited for.

Re: Serverless Best Practices

#18

Post by travbrack »

tomcam wrote: post #2

I still don’t understand how you do a PostgreSQL insert on a serverless system—please help! Also, this statement is patently silly: > The biggest point to make here is that serverless architecture may well require you to rethink your data layer. That’s not the fault of serverless. Well, it is the fault of serverless. It’s a shortcoming. Own it. The trade off may we be worthwhile, I just can’t tell yet. I’m trying to…

So why is rdbms and serverless seemingly mutually exclusive? Are rdbms queries really that slow compared to something like dynamodb?

Re: Serverless Best Practices

#19

Post by actuator »

Agebor wrote: post #14
actuator wrote: post #10

He mentions DynamoDB for the data layer instead of regular RDBMS. I have tried to use DynamoDB several times but have been disappointed with it. I am not saying traditional RDBMSs solve the problem that DynamoDB has, but even DynamoDB is a poor fit for systems with rapidly changing load patterns. Some things that have been big pain points while using DynamoDB: - It has autoscaling built in now but even that leads a l…

Not sure what do you mean about scaling storage layer separately from the compute layer. It's how it's usually done currently, with the disk being the storage layer. As long as there are machines/containers to be started, there will always be some latency, though we can expect it to improve in the next years. AWS now has the Aurora Serverless, though I don't have any real-life experience with it's latency yet (VPC re…

> Not sure what do you mean about scaling storage layer separately from the compute layer. It's how it's usually done currently, with the disk being the storage layer.

Yeah, I meant that only. DynamoDB and Aurora Serverless are examples where they are decoupled and can be scaled independently. So, I wanted to know about more products like them but ones that scale with load really well.

> AWS now has the Aurora Serverless, though I don't have any real-life experience with it's latency yet (VPC requirement is a downer for now).

I have tried Aurora Serverless and I like it but it also plagued by the provisioning problems for now. The lack of options to customize database parameters was kind of a downer. Also for some weird reason they only support MySQL in t type instances.

> (VPC requirement is a downer for now)

BTW, you have an use case where you need to use DB from outside VPC and you can't do peering?

Re: Serverless Best Practices

#20

Post by anothergoogler »

actuator wrote: post #19
Agebor wrote: post #14

Earlier quoted context omitted.

Not sure what do you mean about scaling storage layer separately from the compute layer. It's how it's usually done currently, with the disk being the storage layer. As long as there are machines/containers to be started, there will always be some latency, though we can expect it to improve in the next years. AWS now has the Aurora Serverless, though I don't have any real-life experience with it's latency yet (VPC re…

> Not sure what do you mean about scaling storage layer separately from the compute layer. It's how it's usually done currently, with the disk being the storage layer. Yeah, I meant that only. DynamoDB and Aurora Serverless are examples where they are decoupled and can be scaled independently. So, I wanted to know about more products like them but ones that scale with load really well. > AWS now has the Aurora Server…

I don't understand what you're looking for here. A network file system? Every database decouples storage from "compute."
Post reply on HN