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

21–30 of 104 posts

Re: Serverless Best Practices

#21

Post by jbergknoff »

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…

Similar experience with Dynamo here: it's very easy to get into a situation where it's unusable (rejecting requests) unless you pre-provision enough capacity. The act of scaling up capacity often takes 5-20 minutes, and then there are the limits on how often you can scale. The backup/restore options are very poor. There's no good way to clear a table besides deleting and recreating it, which can be a problem when there are stream listeners. The tooling around Dynamo, both first party and third party, is also pretty shabby.

Maybe I'm just using it wrong. I wish Dynamo came close to its apparent potential.

Re: Serverless Best Practices

#22

Post by actuator »

anothergoogler wrote: post #20
actuator wrote: post #19

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. 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."

Yeah, but not all of them allow you to scale them independently without a downtime.

For example in traditional MySQL setups to scale up the compute capacity your server has to be unavailable for some time.

Re: Serverless Best Practices

#23

Post by actuator »

travbrack wrote: post #18
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?

Actually RDBMS queries are quite fast. But those systems weren't designed for use patterns which serverless applications typically have. Like MySQL will limit you on connection count and each new connection puts extra overhead on the server. So if every function negotiates its own connection you might eat away DB resources just on negotiating connections even though the DB queries were fast.

Re: Serverless Best Practices

#24

Post by manigandham »

These are all outdated already.

Serverless is a meaningless term. The real name is platform-as-a-service, which is decades old. Running individual functions was just taking that to an extreme but any complex app will have multiple functions working together so it's right back to the same thing.

Many "serverless" environments are in fact converting to running an arbitrary docker container for as long as it needs to run, effectively becoming the next-generation of PaaS where you container can be whatever size you need, while still not worrying about infrastructure and individual servers.

Re: Serverless Best Practices

#25

Post by rhizome »

actuator wrote: post #22
anothergoogler wrote: post #20

Earlier quoted context omitted.

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

Yeah, but not all of them allow you to scale them independently without a downtime. For example in traditional MySQL setups to scale up the compute capacity your server has to be unavailable for some time.

I think people way overestimate the business effects of maintenance windows.

Re: Serverless Best Practices

#26

Post by k__ »

travbrack wrote: post #18
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?

As far as I know, most RDBMS are connection based, which brings an overhead. When you got your connection they're quite fast.

Re: Serverless Best Practices

#27

Post by k__ »

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…

> It’s a shortcoming. Own it.

Well, I don't know much about Oracle and the other players, but AWS at least tries to own it with Aurora Serverless.

Re: Serverless Best Practices

#28

Post by k__ »

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…

>Is the cost of calling the other function negligible (e.g. the functions are called rarely)? If yes, feel free to do it.

The question is more one of errors, I think.

You pump your results in a queue before you let another function do the next step, if one function fails it's not the whole process that is lost.

Step Functions, for example, lets you chain functions and does retries for you if one function failed.

Re: Serverless Best Practices

#29

Post by [deleted] »

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…

[deleted]

Re: Serverless Best Practices

#30

Post by whopa »

k__ wrote: post #26
travbrack wrote: post #18

Earlier quoted context omitted.

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

As far as I know, most RDBMS are connection based, which brings an overhead. When you got your connection they're quite fast.

I wonder why all the predominant RDBMSes are heavyweight connection based, and why this is presumably so hard to change. There's nothing in SQL that requires this to be the case, at least conceptually.
Post reply on HN