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

61–70 of 104 posts

Re: Serverless Best Practices

#61

Post by lostcolony »

krn wrote: post #57
ryanmarsh wrote: post #55

Earlier quoted context omitted.

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.

So is every managed service then; in AWS almost everything uses IAM and that's not portable. I can't use ECS; that's not portable. I can use EC2s, those are just VMs...except how the heck do I build those? I can't do it by hand, that's not portable, I can't use Cloudformations, that's not portable...I can't even use Terraform, as despite their marketing speak I still have to change out my configs, because they're still cloud dependent.

Really, it's all a sliding scale. Buying into any cloud, even just at the VM level, means you've accepted your automation tools are going to be platform specific, and require changing recipes/configs/etc to go elsewhere. If you want to leverage anything beyond that, such as object storage (S3 in AWS, which is super common), then your code has to become aware of IAM and S3 endpoints. Your code now has to change if you want to deploy it elsewhere.

I would contend your definition needs to be changed if the logical application of it basically makes everything more complex than 'someone else's server' to be "a hack"

Re: Serverless Best Practices

#62

Post by lostcolony »

starkingclojure wrote: post #12

Are there any major success stories of big projects going serverless? I like the idea, but personally it mostly appeals to me as a nice way to reduce maintenance overhead for side-projects rather than something I'd use for a serious project.

iRobot (Roomba)'s are pretty heavily serverless. https://thenewstack.io/irobot-confronts-challenges-running-s...

Re: Serverless Best Practices

#63

Post by staticassertion »

lostcolony wrote: post #60
staticassertion wrote: post #36

Earlier quoted context omitted.

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

Interesting. I'd considered this, but was worried about failure cases. Seems tricky.

Re: Serverless Best Practices

#64

Post by robertonovelo »

IMHO RDBMS and libraries are OK, just make sure you know the tradeoffs and have a strategy to withstand any potential scale issue or trouble. Do not reinvent the wheel, build for scale when it's needed, know both your function's and system scope/scale, etc.

Re: Serverless Best Practices

#65

Post by jmull »

This probably should be retitled “why you shouldn’t use serverless for most things”. You would only need to slightly rephrase the sentences introducing each section.

E.g., the sections could become:

Function Don’t Compose Well

Functions Don’t Connect to Data Stores Well

Otherwise Unnessary Queues are Needed

Based on this article, it makes it sound like current serverless isn’t a very widely useful tool.

Re: Serverless Best Practices

#66

Post by twblalock »

etaioinshrdlu wrote: post #39
k__ wrote: post #37

Earlier quoted context omitted.

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.

I think the problem with that is the performance would be bad, because the database is not designed to be used thay way and those assumptions go as deep as the way it allocates memory.

Re: Serverless Best Practices

#67

Post by [deleted] »

languagehacker wrote: post #5

Big ups for calling out how bad an idea connecting to the database is from a serverless context. I do a lot with serverless on AWS Lambda. Since part of that involves an ETL to write to a database, I also run a server that exposes a service for writing data via RPC. The server provides a connection pool to the database and appropriately encapsulates all the complex functionality we have for incoming data behind a wel…

[deleted]

Re: Serverless Best Practices

#68

Post by idunno246 »

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?

There’s many frontend servers to Dynamodb. Effectively the http endpoints are a connection pool to the actual backing datastore

Re: Serverless Best Practices

#69

Post by twblalock »

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.

It seems like pretty much everything was connection-based a few decades ago, when those systems were written. This can lead to some behavior in legacy software that causes big problems in cloud environments, or really any environments where connections are transitory.

The problem really boils down to the tight coupling between the HTTP layer and the rest of the stuff all the way down the stack. If you assume connections are always long-lived and stateful, you can make performance and memory optimizations by reserving memory buffers and threads for the sole use of a single connection, and using threadlocals for storing session data.

But if each connection gets its own thread (or thread pool), idle connections lock up resources and can prevent new connections from being opened, because all of the threads are currently allocated to existing connections. And setting up every new connection is a bit expensive and wasteful if it's only going to be used for one request.

I think the industry trend toward transitory connections, and even transitory application instances a la Kubernetes pods, is a good thing for a lot of reasons. If nothing else, the knowledge that connections can be short-lived leads to more fault-tolerant software because the business logic layer cannot depend on assumptions about the HTTP layer. The big downside is that a lot of older stuff isn't really suitable for that kind of world, serverless or not, and it can be really hard to refactor.

Re: Serverless Best Practices

#70

Post by staticassertion »

k__ wrote: post #52
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.

Yeah, I wasn't thinking about what goes into a connection to a DB vs a stateless service. Thanks.
Post reply on HN