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

81–90 of 104 posts

Re: Serverless Best Practices

#81

Post by grzm »

a_silly_name wrote: post #75
manigandham wrote: post #24

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

I'd appreciate it if others could chime in on this one. I'm mystified by the word 'serverless'. Why are we using this word? There are clearly, _quite clearly_ servers involved. The wacky bugs involved in these 'server-less' services... are going to come down to what's happening on the servers involved. EDIT: my question seems to have offended. Unfortunate, and unintentional!

Serverless refers to you administering the application and its resources but not the server directly. Yes, at some level servers are involved, but generally the organization deploying applications is not responsible for administering the hardware, the OS, other resources, often including the scaling of the server resources: they're only concerned with the administration of the application. One can argue that at some level the organization deploying the application is often still concerned with the underlying server and where that line is drawn, but many find it meaningful to make such a distinction.

https://en.wikipedia.org/wiki/Serverless_computing

Re: Serverless Best Practices

#82

Post by gbrits »

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.

To solve connect to a connection pool service instead of a RDBMS directly. E.g. Pgbouncer for Postgres

Re: Serverless Best Practices

#83

Post by k__ »

e1g wrote: post #59
k__ wrote: post #47

Earlier quoted context omitted.

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)

Oh, I meant it was a GraphQL based alternative to use API-GW backed by Lambdas.

Re: Serverless Best Practices

#84

Post by bni »

actuator wrote: post #19
Agebor wrote: post #14

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. As long as there are machines/containers to be started, there will always be some latency, though we can expect it to improve in the next years. AWS now has the Aurora Serverless, though I don't have any real-life experience with it's latency yet (VPC re…

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

> BTW, you have an use case where you need to use DB from outside VPC and you can't do peering?

Lambda in VPC have unacceptable cold-start for interactive applications. This is partly why DynamoDB use is so popular with Lambda, it does not have to be in VPC.

Re: Serverless Best Practices

#85

Post by bni »

gbrits wrote: post #82
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.

To solve connect to a connection pool service instead of a RDBMS directly. E.g. Pgbouncer for Postgres

I think that a big part of Aurora Serverless being different from regular RDS, is something like this has been implemented in front of RDS. Havent used Aurora Serverless yet, but I think you can only talk to it by HTTPS, right?

Re: Serverless Best Practices

#86

Post by collyw »

a_silly_name wrote: post #75
manigandham wrote: post #24

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

I'd appreciate it if others could chime in on this one. I'm mystified by the word 'serverless'. Why are we using this word? There are clearly, _quite clearly_ servers involved. The wacky bugs involved in these 'server-less' services... are going to come down to what's happening on the servers involved. EDIT: my question seems to have offended. Unfortunate, and unintentional!

The pricing model is the only thing that seems to be serverless as far as I can tell.

Re: Serverless Best Practices

#87

Post by zbentley »

Agebor wrote: post #6
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…

Connecting a DB might be a bad idea only currently, until cloud providers implement some sort of RPC SQL layer. We are successfully running Lambda functions connecting to AWS Aurora MySQL using IAM authentication. It has some quirks but after figuring it out, works well. Just run a connection pool with only 1 connection and expect some additional latency on cold start, though it's negligible compared to loading libra…

> implement some sort of RPC SQL layer

> Just run a connection pool

You just described the high-level architecture of what I believe is the majority of web application servers and the applications they run: an RPC layer over database accesses that run on persistent connections.

Re: Serverless Best Practices

#89

Post by lostcolony »

krn wrote: post #80
lostcolony wrote: post #61

Earlier quoted context omitted.

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

A public cloud only requires three things: compute instances, block storage, and object storage. Everything else is just an additional service built on top of these. If you use a cloud platform as an infrastructure provider, not as a software provider, there is no vendor lock-in. There are enough mature open-source tools even to build your own cloud on bare metal[1]. [1] https://maas.io/

How do you plan on accessing object storage in AWS (S3) from your code without also using IAM to authenticate/authorize requests to it?

Re: Serverless Best Practices

#90

Post by krn »

lostcolony wrote: post #89
krn wrote: post #80

Earlier quoted context omitted.

A public cloud only requires three things: compute instances, block storage, and object storage. Everything else is just an additional service built on top of these. If you use a cloud platform as an infrastructure provider, not as a software provider, there is no vendor lock-in. There are enough mature open-source tools even to build your own cloud on bare metal[1]. [1] https://maas.io/

How do you plan on accessing object storage in AWS (S3) from your code without also using IAM to authenticate/authorize requests to it?

I prefer to use object storage powered by OpenStack Swift[1], which makes my application not attached to any proprietary API.

[1] https://www.ovh.com/world/public-cloud/storage/object-storag...

Post reply on HN