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

41–50 of 104 posts

Re: Serverless Best Practices

#41

Post by k__ »

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.

True.

Maybe DynamoDB works better with this model, because it is build up without the idea of maintaining connections?

Re: Serverless Best Practices

#42

Post by k__ »

GuB-42 wrote: post #15

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

Not having to set up and maintain your own web/app/db-servers is quiet a nice thing to have, especially for small companies that don't have much money.

Re: Serverless Best Practices

#43

Post by oxymoron »

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…

It’s not about TCP per se. RDMS connections are usually highly stateful and resource consuming on the server end. That’s why they are usually pooled.

Re: Serverless Best Practices

#44

Post by glckr »

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 functions as advocated by this blog) are supposed to work (if they are at all). There seem to be many ways to solve this when the queues are all flowing freely, but as soon as there's any sort of pressure on the system these things all look to fall down.

Looking at the amazon booking flow as an example -- it appears that they always show a "your order has been placed" page with a big green banner synchronously at the end of the cart flow. Some time later the user may then receive an email saying their payment method was declined. This certainly works, but a) it's horrible UX and b) it only works at the final stage of the process.

I see queues (and serverless) advocated as good architectural decisions, but every time they come up in a lecture/blog they're given in toy or data-sciency sort of examples. Is it possible to use these patterns in a sensible way where users are actually involved? (the blog mentions CQRS, but that seems... not a perfect solution)

Re: Serverless Best Practices

#45

Post by k__ »

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…

Some time ago I read they revamped the provisioning/boosting algorithms, to get around some of the issues.

Re: Serverless Best Practices

#46

Post by [deleted] »

k__ wrote: post #42
GuB-42 wrote: post #15

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

Not having to set up and maintain your own web/app/db-servers is quiet a nice thing to have, especially for small companies that don't have much money.

[deleted]

Re: Serverless Best Practices

#47

Post by k__ »

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.

Re: Serverless Best Practices

#48

Post by rhizome »

etaioinshrdlu wrote: post #31
rhizome wrote: post #25

Earlier quoted context omitted.

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.

The overestimation is in whether a company should be using s3 as an operational standard.

Re: Serverless Best Practices

#49

Post by pvg »

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.

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.

Re: Serverless Best Practices

#50

Post by suzzer99 »

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…

Same concerns here. I've read so much theory on event-based architecture and CQRS, but the examples are rarely applied to user-facing web-app scenarios. Back-end technology should never dictate UX imo.

We're building a user-facing app from scratch - the plan is to start with big coarse grained services, and just use REST for service to service communication when a user is waiting on the line.

But of course favor breaking up the services so there's no communication required is the first preference, and queue-based where it makes sense is the second preference.

Post reply on HN