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

31–40 of 104 posts

Re: Serverless Best Practices

#31

Post by etaioinshrdlu »

rhizome wrote: post #25
actuator wrote: post #22

Earlier quoted context omitted.

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.

Disagree completely. Services that you can mostly depend on to never go down, and scale as far as you will ever want, are a huge relief. Like S3.

We should ask for the same thing with rdbms's.

Re: Serverless Best Practices

#32

Post by etaioinshrdlu »

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 don't get the difference particularly... You have to open a tcp connection to talk to dynamodb, right?

Re: Serverless Best Practices

#33

Post by AYBABTME » 

    This one will get me into the most trouble. A lot of web application
    people will jump on the “but RDBMS are what we know” 
    bandwagon.
    
    It’s not about RDBMS. It’s about the connections. Serverless.
    works best with services rather than connections.
Guess what a service call will use to do its RPC...? a connection. This advice makes no sense. Maybe you don't care about the response to your service? That's different from saying "don't use connections". (I doubt most serverless RPC calls are over UDP like protocol)

Re: Serverless Best Practices

#34

Post by staticassertion »

> Functions have cold starts (when a function is started for the first time) and warm starts (it’s been started, and is ready to be executed from the warm pool). Cold starts are impacted by a number of things, but the size of the zip file (or however the code is uploaded) is a part of it. Also, the number of libraries that need to be instantiated.

I'm curious what size packages people are loading in lambdas currently. My largest lambda is a 4.7MB zip.

If anyone has some anecdotal info on runtime + package size I'm super curious to hear.

> So if you have to use an RDBMS, but put a service that handles connection pooling in the middle, maybe an auto scaling container of some description simply to handle that would be great.

Not sure I understand this. If I put another service in between me and the database don't I just end up having to open connections to that service?

I have an Aurora instance my lambda talks to, and it creates a new connection every time, and that's a bummer so I'm curious about how I could optimize that patch.

Re: Serverless Best Practices

#35

Post by k__ »

whopa wrote: post #30
k__ wrote: post #26

Earlier quoted context omitted.

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.

Saves overhead.

Crappy application-servers pump queries like nobodies business, so you need to shave every byte of them you can.

Re: Serverless Best Practices

#36

Post by staticassertion »

matchagaucho wrote: post #3
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…

Moving away from RDBMS just wasn't an option for us. But AWS serverless provided a couple benefits: 1. Aurora Serverless RDBMS (In pilot) 2. Lambda function property caching (for which we cache connections)

How does Aurora Serverless help with the issue of having to reconnect for every lambda? (I am unfamiliar with the Aurora Serverless offering)

Also, can you elaborate/ point me to info on 2?

Re: Serverless Best Practices

#37

Post by k__ »

etaioinshrdlu wrote: post #32
k__ wrote: post #26

Earlier quoted context omitted.

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

I don't get the difference particularly... You have to open a tcp connection to talk to dynamodb, right?

From the docs: DynamoDB is a web service, and interactions with it are stateless. Applications do not need to maintain persistent network connections. Instead, interaction with DynamoDB occurs using HTTP(S) requests and responses.

Re: Serverless Best Practices

#38

Post by AmericanChopper »

jbergknoff wrote: post #21
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 the…

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

Maybe, but you might also be using it for the wrong thing. Any business logic that requires table scans (which are perfectly fine on RDBMS), is going to suck in any document database. The way you win at Dynamo is by making sure that one user operation is as close to one Dynamo call as you can make it. If your workload can't be designed to suit that paradigm, then Dynamo will only bring you pain and suffering.

That said though, migrations are terrible in Dynamo. Altering a table will often involve creating a new one, backfilling it, and then cutting over. Which you have to implement your own logic for. Also, think the GSI limit is 5? In practice it's actually 4, because if you want to recreate a GSI, you need to create a new one, and then drop the old one, so you have to keep one spare to accomodate that process.

Re: Serverless Best Practices

#39

Post by etaioinshrdlu »

k__ wrote: post #37
etaioinshrdlu wrote: post #32

Earlier quoted context omitted.

I don't get the difference particularly... You have to open a tcp connection to talk to dynamodb, right?

From the docs: DynamoDB is a web service, and interactions with it are stateless. Applications do not need to maintain persistent network connections. Instead, interaction with DynamoDB occurs using HTTP(S) requests and responses.

One could, if they wanted, open a new MySQL connection for every statement, which seems similar. One could do this asynchronously in the background too, simulating the eventually consistent nature as well.

Re: Serverless Best Practices

#40

Post by k__ »

AYBABTME wrote: post #33

This one will get me into the most trouble. A lot of web application people will jump on the “but RDBMS are what we know” bandwagon. It’s not about RDBMS. It’s about the connections. Serverless. works best with services rather than connections. Guess what a service call will use to do its RPC...? a connection. This advice makes no sense. Maybe you don't care about the response to your service? That's different from s…

Well, talking to a RDBMS works a bit different than HTTP, both use TCP.
Post reply on HN