4 ms·
> A key feature of these environments is that state is not generally persisted from one request to the next. That means we can’t use standard client-side databa
by kccqzy 4y ago
> A key feature of these environments is that state is not generally persisted from one request to the next. That means we can’t use standard client-side database connection pooling.
So we introduced so many optimizations just because we can't persist state. I can't help but think this is being penny wise pound foolish; the problems this article is solving wouldn't have been problems in the first place if you choose a boring architecture.
- nikita 4y agoServerless environments are a matter of fact. They exist, they are super convenient, and people want to use Postgres in them. This is a bridge for such people. Yes, it requires some sophisticated engineering, but it also enables to have less boilerplate code for a lot of people.
- Cthulhu_ 4y agoI think if this particular logic is hidden away behind a server, it doesn't really matter - people want convenience, and for someone else to hide the complexity. Serverless postgres-as-a-service isn't a stretch at all. This thread does remind me of a previous thread, I believe it was something like optimizing a basic string operation (concatenation?) by going down to assembly and SIMD. Few people have a need to know the details of that particular implementation, and mere mortals cannot comprehend the wizardry going on there either, but that's just fine because if it gets incorporated into standard libraries or the underlying implementations that said standard libraries use, everybody benefits without ever having to understand the inner workings.
- interstice 4y agoUnless it breaks one day and no one knows why
- hot_gril 4y agoSomeone knows why, but that someone is not me. And if it had to be me, I'd go figure it out given some time. Point is, I don't need SIMD knowledge hot-loaded in my head.
- manigandham 4y agoAlso known as layers of abstractions. The entirety of (software) technology is built on that concept.
- hot_gril 4y agoSure, you want the easiest thing possible that fulfills the common use cases. But right now serverless isn't there quite yet. Having persistent Postgres connections is a really basic requirement that the serverless platforms should've implemented already. Heroku and similar things are the sweet spot right now for me. I don't have to deal with much, and I get exactly the amount of flexibility that I need. Sure it'd be a little nicer not to deal with Express on my own in a NodeJS environment, but right now it's easier to deal with than it is to avoid. Some day I'll happily go serverless.
- jrsj 4y agoThings are getting more serverlesss too. With Deno Deploy, Cloudflare Workers, etc I see myself eventually wanting to run most of my application on platforms like this, and a serverless & distributed database makes that much easier and I expect it’ll probably perform better in many cases too.
- nikita 4y ago100%
- agrippanux 4y agoDeno Deploy doesn’t yet support npm (it’s coming), which I found out the hard way last week. Overall tho I agree with your statement, and I now build most of my apps using serverless and databases like Neon.
- stickfigure 4y agoI've been doing "serverless" on app engine for more than a decade and it handles postgres connections fine without any heroics. There's always instances with state somewhere; it's just a question of how smart your serverless infrastructure is about pooling the instances.
- jeremyjacob 4y agoThe “serverless” being referred to in the article is run using V8 isolates, whereas app engine runs full Node.js processes. Although they have limitations like not supporting raw TCP, isolates can start within a couple milliseconds and are much more CPU efficient than standalone processes.
- insanitybit 4y agoAs if boring architectures don't have their own problems.
- Cthulhu_ 4y agoSuch as? Besides of course not being able to find people that want to work on it.
- endisneigh 4y agoBoring architectures generally don’t scale well
- manigandham 4y agoBeing boring has nothing to do with scale. Some of the biggest applications run on incredibly simple architectures, and often are able to scale so well because of that (boring) simplicity.
- SebJansen 4y agoCassandra is probably in the realm 'boring and scalable'
- manigandham 4y agoDefinitely not. I'd much rather scale Postgres manually through layers of sharding and proxies than handle Cassandra. There is ScyllaDB for a much better reimplementation of Cassandra/Dynamo, but wide-column databases are still best for niche scenarios, especially as RDBMS are rapidly evolving into natively distributed architectures.
- endisneigh 4y agoWhat are the biggest apps on the simplest architectures and what are the architectures?
- chmod600 4y agoBoring architectures already exist. Why reimplement what's already done?
- streblo 4y agoBound to be controversial hot take: serverless is the boring architecture you were looking for in the first place
- icedchai 4y agoI think serverless is fine as long as you don't lock yourself in to proprietary, vendor-specific APIs. For example, with AWS Lambda and Python, you could use Mangum (see https://mangum.io/ https://mangum.io/ ) so you're deploying an ASGI app, based on say FastAPI or Starlette. For databases, stick with Postgres.
- hot_gril 4y agoAlmost. It'd be boring if it'd handle these Postgres connections efficiently for me instead of making me rely on workarounds.
- hot_gril 4y ago(As cool as Neon is. If you're already serverless for other reasons, they're providing a nice solution for Postgres.)