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

51–60 of 104 posts

Re: Serverless Best Practices

#51

Post by AmericanChopper »

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?

A couple of concepts core to the serverless model is that components communicate via API, and that resources are consumed on demand. Traditional RDBMS don’t really fit into that model. Google Spanner is the only thing I’ve seen that seems to come close. AWS doesn’t have much aside from Dynamo, especially considering how poorly lambdas perform when you put them inside a VPC.

Re: Serverless Best Practices

#52

Post by k__ »

staticassertion wrote: post #34

> 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…

The service could be stateless.

Re: Serverless Best Practices

#53

Post by ersiees »

staticassertion wrote: post #36
matchagaucho wrote: post #3

Earlier quoted context omitted.

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?

You don’t need a reconnect for every invocation actually, only per instance. I know you don’t want to think about instances with lambda, but actually they just run on some VM and you can just open one connection per VM.

Re: Serverless Best Practices

#54

Post by krn »

As long as people talk about a development practice only in terms of a set of services from a proprietary cloud platform, you know, that it's not a mature thing.

Re: Serverless Best Practices

#55

Post by ryanmarsh »

krn wrote: post #54

As long as people talk about a development practice only in terms of a set of services from a proprietary cloud platform, you know, that it's not a mature thing.

I don’t follow the logic in this argument. The same patterns work in other cloud platforms.

Re: Serverless Best Practices

#56

Post by wgjordan »

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.

TCP/IP performs a handshake to establish connections so there will always be some per-connection overhead required for this, no matter the service on the other end.

Beyond that, MySQL for example pre-allocates a fixed amount of memory for read, join and sort buffers per connection to efficiently handle different types of queries, though the buffer sizes are all tunable to optimize performance. There is also some OS-scheduler overhead involved in creating and running a separate thread per connection. A thread-cache optimizes the case where lots of short-lived connections are being created. (I dont have direct experience with PostgreSQL but I read that it forks a separate process per connection, which would presumably incur a significantly higher overhead than threads.)

Beyond this, any more specific discussion requires quantifying connection 'weight' to dispel/confirm your superstition that 'all the predominant RDBMSes are heavyweight'. In an apples-to-apples benchmark, it's quite possible that the connection-weight of some RDBMSes might actually be lighter than other database engines. I dont know myself, but would be interested if anyone has any such data to share on this.

Re: Serverless Best Practices

#57

Post by krn »

ryanmarsh wrote: post #55
krn wrote: post #54

As long as people talk about a development practice only in terms of a set of services from a proprietary cloud platform, you know, that it's not a mature thing.

I don’t follow the logic in this argument. The same patterns work in other cloud platforms.

Serverless applications are attached to a single cloud platform they were built on top of. You can't switch between the platforms without changing the code. At its current stage, serverless is more like a hack.

Re: Serverless Best Practices

#58

Post by lostapathy »

pvg wrote: post #49
whopa wrote: post #30

Earlier quoted context omitted.

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.

Part of it is legacy but also, interactions with an RDBMS are often stateful so it's useful to have a session (in which such things as transactions can live, etc). I'd guess there isn't much reason to change this because there are standard and effective workarounds that just haven't yet made their way to things like lambda.

Can you elaborate on what “standard and effective workarounds” you are referring to here?

Re: Serverless Best Practices

#59

Post by e1g »

k__ wrote: post #47
glckr wrote: post #44

Conceptually I would say I'm a fan of these sorts of ideas (serverless, and queues in particular). Forcing you to look at the system as a chain of processes operating on data can really bring architectural problems into line. However, 99% of the work that I've done involves users hitting buttons and us responding to them synchronously. In these scenarios, I simply can't figure out how queues (and chains of serverless…

I heard people were switching API-Gateway out with AppSync (the GraphQL alternative), which allowed them to remove a huge amount of HTTP-bound Lambdas and simply let AppSync manage that part of the stack.

AppSync is more of a wrapper around GraphQL rather than an alternative (including being based on the most popular GraphQL client, Apollo)

Re: Serverless Best Practices

#60

Post by lostcolony »

staticassertion wrote: post #36
matchagaucho wrote: post #3

Earlier quoted context omitted.

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?

Really quickly then -

Background info: A lambda that spins up stays live for a while, and can continue to handle requests. The function handler is called again, so anything scoped to it, will disappear with the function, but anything scoped outside of the function will persist.

Ergo, move your connection creation outside of your handler.

Realistically you may need some abstraction to properly close and reopen the connection in the event of failure (so you can't have a 'bad' lambda, where something has happened to the connection and you can't fix it without deploying code again, to trigger a lambda refresh), but for the most part it just works.

Post reply on HN