Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Architecture of Serverless Data Systems

jack-vanlightly.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: The Architecture of Serverless Data Systems

#31

Post by leetrout »

2mol wrote: post #29
lysecret wrote: post #28

Earlier quoted context omitted.

The serverless pitch is extremely appealing to many companies. Also, many serverless offerings seem like a great choice at the beginning. But at some point, you will want SQL features like joins, groups, secondary indexes, foreign keys etc. The missing link is really a serverless postgres (which many are working on but nothing has impressed me so far.

Sorry if this is ignorant, but I never understand what serverless Postgres means. What's different from a hosted Postgres instance? Some scaling characteristics or the fact you interact with it via an API instead of some library, ORM, or plain SQL?

A lot of "serverless" things are really on-demand timesharing.

One example of "serverless postgres" in my opinion would mean data is on a blob store and you only pay when running queries and for the static storage.

Basically snowflake's pricing model.

Re: The Architecture of Serverless Data Systems

#32

Post by javaunsafe2019 »

alternatex wrote: post #9
fergie wrote: post #6

Two observations: - "serverless" is a really bad name for these systems. As is often commented, some variation of "somebody-elses-server" would be better. - Cost wasn't mentioned in the article, but the cost of renting databases and search-indices is still really high, even though these technologies are no longer the new hotness.

All cloud hosting is "somebody-elses-server". Serverless is more like "pay-per-function-call" in which case Azure Functions has a pretty appropriate name. Also, the cost of renting databases has nothing to do with newness. Databases have evolved a lot in the past two decades. They do all sorts of stuff under the hood, which is why they can now often consume massive amounts of RAM. That doesn't come for free.

Did you knownthode functions are executed on containers which, in the end, are tiny server. It’s all just some marketing and printing out you don’t have to deal with the management of the containers just the configuration if you like to have some hot loaded lambdas etc

Re: The Architecture of Serverless Data Systems

#33

Post by ako »

2mol wrote: post #29
lysecret wrote: post #28

Earlier quoted context omitted.

The serverless pitch is extremely appealing to many companies. Also, many serverless offerings seem like a great choice at the beginning. But at some point, you will want SQL features like joins, groups, secondary indexes, foreign keys etc. The missing link is really a serverless postgres (which many are working on but nothing has impressed me so far.

Sorry if this is ignorant, but I never understand what serverless Postgres means. What's different from a hosted Postgres instance? Some scaling characteristics or the fact you interact with it via an API instead of some library, ORM, or plain SQL?

Serverless = not having to think of server size for running the database, it scales as needed.

Re: The Architecture of Serverless Data Systems

#34

Post by dspillett »

2mol wrote: post #29
lysecret wrote: post #28

Earlier quoted context omitted.

The serverless pitch is extremely appealing to many companies. Also, many serverless offerings seem like a great choice at the beginning. But at some point, you will want SQL features like joins, groups, secondary indexes, foreign keys etc. The missing link is really a serverless postgres (which many are working on but nothing has impressed me so far.

Sorry if this is ignorant, but I never understand what serverless Postgres means. What's different from a hosted Postgres instance? Some scaling characteristics or the fact you interact with it via an API instead of some library, ORM, or plain SQL?

Serverless in that context essentially means “somebody else's server(farm)”. It frees you from some of the infrastructure/admin involved in server sizing & upgrades, backups, availability management, and so on.

It can be very attractive to teams who don't want to have an internal expert for all that, or to buy huge hardware to deal with spikes in activity that only happen occasionally⁰. Just being able to spin up a large DB for some tests without worrying about available space, how much it will compete for this like CPU/IO with your other DBs¹, etc, can be very convenient.

It can work out quite expensive in terms of price/performance ratio, if those factors are not a benefit to you.

----

[0] or happen regularly but usually for only a short time

[1] usually these things are capped, or have a burstable cap, so “noisy neighbours”² are not the huge problem they can often be on cheap shared hosting

[2] unless you have explicitly pooled resources (like Elastic Pools for Azure SQL) without per-object limits, in which case your own activity could be harmful noise

Re: The Architecture of Serverless Data Systems

#35

Post by jchanimal »

ddorian43 wrote: post #22
Dave3of5 wrote: post #21

Earlier quoted context omitted.

You haven't given specific of this to be blunt no idea what you mean. I already said my points about the problems your follow-up comments have not addressed those. Also there is no such thing in s3 as a cold GET there is a cold startup for a lambda. The latency from s3 on a get is orders of magnitude poorer that EBS or LSSD and should be used "infrequently".

Imagine using rocksdb backed by S3. You store only sstables in S3. You append the WAL in EBS and archive it in S3. You cache blocks in local SSD. If you want faster WAL, you append the WAL in local-ssd and use multi-az replication in your db and fsync WAL to EBS less frequently than locally. > What about transactionality, partial updates, running multi document queries, consistency of the whole set of documents. You…

This is basically how Fireproof works: files to S3, reads from any cache, encryption metadata in your session store. All of this becomes “easy” if you write a storage engine from scratch for immutable content addressed data.

Re: The Architecture of Serverless Data Systems

#36

Post by pluto_modadic »

fergie wrote: post #6

Two observations: - "serverless" is a really bad name for these systems. As is often commented, some variation of "somebody-elses-server" would be better. - Cost wasn't mentioned in the article, but the cost of renting databases and search-indices is still really high, even though these technologies are no longer the new hotness.

it messes with googling "without servers" (when I mean peer to peer, non-scam systems),

or when I mean "without a public IPv4" (as in, without a server), like offline-first (which is still /eventually connected to a server/ smh)

FNaaS != "without servers" so much as "reducing the amount of the pizza shop you run yourself" like that diagram of homemade pizza at home, frozen pizza boxes, papa johns, pizza delivery, pizza shop owner...

It's kinda an overloaded term like how cryptography gets abused by web3 scams. There's an entire row of books on computer science at a college library, one book case is on security, one shelf in that case is on cryptography, most of those books are RSA, two are EC, and one is on essoteric cryptography like dining cryptographers, blind signing, ZKP, etc - and I worry the new books will be aaaaaaaaall blockchain and DAO instead of... Tor V3 papers, or Veilid, or Vuvuzella, or Cwtch/fuzzytokens,

Re: The Architecture of Serverless Data Systems

#37

Post by rowls66 »

dangoodmanUT wrote: post #23
ddorian43 wrote: post #17

Earlier quoted context omitted.

> You have to rewrite a whole DBMS on top of s3 itself or use redshift to get these things. No, you get a DBMS and only change the storage underneath. You can't use S3 for appending to WAL though. All those can be fixed besides the latency for a cold GET from S3 and appending WAL to S3.

You defintiely can use S3 for appending to a WAL (I've done it), they have read-after-write consistency

How about using Kafka for the WAL? Anybody tried that?

Re: The Architecture of Serverless Data Systems

#38

Post by Dave3of5 »

lysecret wrote: post #28
Dave3of5 wrote: post #16

A bit too waffling for me to read all but I would like to make a small comment. Why are more and more devs trying to use s3 as a general purpose DB? Working on a system right now where the architects have made this mistake it has insanely poor performance (High latency) and lack any proper ACID compliance. I've now been asked to "make it faster" and the answer is to switch back to an actual DBMS. > Top tier SaaS serv…

The serverless pitch is extremely appealing to many companies. Also, many serverless offerings seem like a great choice at the beginning. But at some point, you will want SQL features like joins, groups, secondary indexes, foreign keys etc. The missing link is really a serverless postgres (which many are working on but nothing has impressed me so far.

> The missing link is really a serverless postgres

Used AWS Aurora Serverless v2 (MySQL) and it worked pretty good actually never used the postgres version but it's now available.

Re: The Architecture of Serverless Data Systems

#40

Post by nathants »

serverless compute and storage are a great thing. the chronic silverbullitus that plagues industry since the dawn of time doesn’t change that. nonsensically bad systems will be built.

lambda is very reliable, more so than ec2. for serious systems, use it to manage servers.

s3 and dynamo are the same thing with different settings. yes dynamo also adds a kitchen sink, but the only feature you should use is CAS.

s3 is x10 cheaper for storage, x10 more expensive per request, x10 slower per request. dynamo is the opposite.

many great system designs can run properly serverless, ie without any ec2 or ec2-spot. they are simpler. serious systems require you to understand what lambda/s3/dynamo give you and what they do not.

more systems can be designed by adding ec2 and/or ec2-spot. the same understanding is required.

s3/dynamo are equidistant from every point within that region. there is no cross az bandwidth cost. there is no bottleneck. there is no contention. a lot of cool designs fall out of this.

lambda can burst to thousands of cpus in a second, for a second.

ec2-spot boots in 30s, and often has very large nvme physically attached.

there’s nothing fundamentally wrong with misusing all these tools and building inefficient systems. the builders will probably do better on their next system. if the owners wanted it done better initially, they could have hired more expensive builders.

Post reply on HN