How Modern SQL Databases Are Changing Web Development: Part 1(blog.whimslab.io)
blog.whimslab.io
How Modern SQL Databases Are Changing Web Development: Part 1
https://blog.whimslab.io/how-modern-sql-databases-are-changing-web-development-4d1f15b0daea
137 comments
Yeah, the headline isn't great, but it's describing something real that database service providers are working on.
You're right that the question is whether you want the high-latency link to be between the web browser and the web backend, versus the web backend and the database.
Either way works; it's just a matter of where you're going to spend effort reducing round trips. For database driver developers, optimizing for minimizing round trips is new, but they're making progress. As an app developer, you can use stored procedures to reduce round trips, or even have app logic in both places.
As you say, serving a result from an edge cache is a way to avoid any database round trip. This brings up issues around cache invalidation that haven't really been tackled yet; with Postgres you could use listen/notify, but it assumes a persistent connection that isn't there for these new drivers.
An alternative would be to use read-only database replicas, but that seems relatively heavyweight compared to a bit of local caching.
You're right that the question is whether you want the high-latency link to be between the web browser and the web backend, versus the web backend and the database.
Either way works; it's just a matter of where you're going to spend effort reducing round trips. For database driver developers, optimizing for minimizing round trips is new, but they're making progress. As an app developer, you can use stored procedures to reduce round trips, or even have app logic in both places.
As you say, serving a result from an edge cache is a way to avoid any database round trip. This brings up issues around cache invalidation that haven't really been tackled yet; with Postgres you could use listen/notify, but it assumes a persistent connection that isn't there for these new drivers.
An alternative would be to use read-only database replicas, but that seems relatively heavyweight compared to a bit of local caching.
Yeah, DB replication and caching would be a pain in this scenario. Akamai cache busting is challenging enough in complex cases.
I can also imagine how you can have localized datasets with a centralized auth database, for instance. That way, you have something akin to sharding of the dataset to bring real-time functionality closer to a global user-base. For example, you can have an edge game server with a local state serving 20-30 players close to their physical location.
I wouldn't recommend this for 99% of web development tho.
I can also imagine how you can have localized datasets with a centralized auth database, for instance. That way, you have something akin to sharding of the dataset to bring real-time functionality closer to a global user-base. For example, you can have an edge game server with a local state serving 20-30 players close to their physical location.
I wouldn't recommend this for 99% of web development tho.
If your server is just fetching data, then it doesn't seem like much benefit to have the server close to the user unless the data is also close to the user at least some of the time (caching, distributed db, etc).
However, if your server is doing other work, it might be useful to be close to users even if the data isn't. This is why fly.io sponsors stuff like Phoenix Liveview or Laravel Livewire.
However, if your server is doing other work, it might be useful to be close to users even if the data isn't. This is why fly.io sponsors stuff like Phoenix Liveview or Laravel Livewire.
Totally agree that function locality is important, especially if latency reduction is your biggest opportunity. Edge compute feels like a niche problem for most businesses, and it comes with high overhead costs in setup and maintenance.
You mentioned Liveview and Livewire. Both are great and they would work equally well in any context, not exclusively a server less front-end.
I would propose that switching to a more efficient programming language (i.e. not using Elixir or PHP) and investing in better data structure optimization would result in equal if not better performance improvements than investing the same amount of time wrangling data replication issues and infrastructure maintenance caused by edge compute.
To the point of the original article, modern web development remains the same: start with a single server, server-side render your content, and expand when the need arises. What we're talking about in the comments is performance web development for geographically distributed audiences (for instance, if you're building a global social network).
You mentioned Liveview and Livewire. Both are great and they would work equally well in any context, not exclusively a server less front-end.
I would propose that switching to a more efficient programming language (i.e. not using Elixir or PHP) and investing in better data structure optimization would result in equal if not better performance improvements than investing the same amount of time wrangling data replication issues and infrastructure maintenance caused by edge compute.
To the point of the original article, modern web development remains the same: start with a single server, server-side render your content, and expand when the need arises. What we're talking about in the comments is performance web development for geographically distributed audiences (for instance, if you're building a global social network).
What about caching the database itself on the application server?
Is there some kind of SQL client library that can somehow cache records from the DB, and P2P cache with other application servers, but then make sure everything is synced with the main server?
Wouldn't it be ideal to have just the parts of the DB that each user needed kept close to that user?
Is there some kind of SQL client library that can somehow cache records from the DB, and P2P cache with other application servers, but then make sure everything is synced with the main server?
Wouldn't it be ideal to have just the parts of the DB that each user needed kept close to that user?
> Serverless databases are not a new thing. AWS launched Aurora back in 2017
App Engine (which was the first popular serverless platform, before the term was coined) included a datastore about 7 years prior.
App Engine (which was the first popular serverless platform, before the term was coined) included a datastore about 7 years prior.
[tl;dr: Serverless provisioning for data is far from a new concept, but it wasn't called "serverless" before serverless compute (functions) appeared. OP probably meant that Aurora was the first serverless SQL database, but even that statement is debatable.]
It probably avoids recognition because it was tied to App Engine, which wasn't serverless by itself, and predated the popularization of the term serverless. I can identify a few other serverless NoSQL databases that predated the serverless hype: Azure Storage Tables and CosmosDB (known as DocumentDB back when it was released in 2014) for one. I haven't used DynamoDB back then, but it seems like it was also serverless from day one[1].
I think the author really wanted to say "Serverless SQL databases are not a new thing. AWS launched Aurora back in 2017 [...]". That might check out if you don't count Cloud Spanner as "true" SQL[2], but I'm wouldn't be surprised if you'd find someone who has implemented a niche SQL database service that wasn't provisioned and kinda supported scaling up as needed.
[1] "Amazon DynamoDB lets you specify the request throughput you want your table to be able to achieve (your table’s “throughput capacity”). Behind the scenes, the service handles the provisioning of resources to achieve the requested throughput rate. Rather than asking you to think about instances, hardware, memory, and other factors that could affect your throughput rate, we simply ask you to provision the throughput level you want to achieve and we handle the rest."
[2] Amazon only launched Aurora on 2018, even though they announced it in late 2018. Cloud Spanner was released a full year before, and Spanner was running internally on Google datacenters, possibly with serverless provisioning, since 2012.
It probably avoids recognition because it was tied to App Engine, which wasn't serverless by itself, and predated the popularization of the term serverless. I can identify a few other serverless NoSQL databases that predated the serverless hype: Azure Storage Tables and CosmosDB (known as DocumentDB back when it was released in 2014) for one. I haven't used DynamoDB back then, but it seems like it was also serverless from day one[1].
I think the author really wanted to say "Serverless SQL databases are not a new thing. AWS launched Aurora back in 2017 [...]". That might check out if you don't count Cloud Spanner as "true" SQL[2], but I'm wouldn't be surprised if you'd find someone who has implemented a niche SQL database service that wasn't provisioned and kinda supported scaling up as needed.
[1] "Amazon DynamoDB lets you specify the request throughput you want your table to be able to achieve (your table’s “throughput capacity”). Behind the scenes, the service handles the provisioning of resources to achieve the requested throughput rate. Rather than asking you to think about instances, hardware, memory, and other factors that could affect your throughput rate, we simply ask you to provision the throughput level you want to achieve and we handle the rest."
[2] Amazon only launched Aurora on 2018, even though they announced it in late 2018. Cloud Spanner was released a full year before, and Spanner was running internally on Google datacenters, possibly with serverless provisioning, since 2012.
> it was tied to App Engine, which wasn't serverless by itself
Yes it was. I’m not sure how long you’ve been doing serverless for but App Engine’s entire concept was stateless functions.
Yes it was. I’m not sure how long you’ve been doing serverless for but App Engine’s entire concept was stateless functions.
Not necessarily stateless. You could cache things in global variables within the process, as well as using memcache.
Using App Engine's datastore could often be frustrating due to high latency. Hopefully these new database services will do better. At least you can write stored procedures.
Using App Engine's datastore could often be frustrating due to high latency. Hopefully these new database services will do better. At least you can write stored procedures.
> separation of “Compute” and “Storage”. Yes, I’m explicitly talking about Neon here since it was the first to pioneer the concept
Aurora certainly did that earlier, and there were probably other earlier examples also (funny, because author mentioned Aurora upthread).
> in edge environments because, for every incoming request, a new runtime is spawned to serve it
Said that way, it's hard not to think "CGI-bin on a server nearest the user (because webscale)". Coming soon: "the all new Persistent Edge, a runtime that actually stays up between requests, on a server nearest the user (because webscale) optimizing away startup costs!"
Aurora certainly did that earlier, and there were probably other earlier examples also (funny, because author mentioned Aurora upthread).
> in edge environments because, for every incoming request, a new runtime is spawned to serve it
Said that way, it's hard not to think "CGI-bin on a server nearest the user (because webscale)". Coming soon: "the all new Persistent Edge, a runtime that actually stays up between requests, on a server nearest the user (because webscale) optimizing away startup costs!"
Big Data systems (Spark / Hadoop over S3) really pioneered this, as the original MapReduce paradigm had fairly tight coupling between compute and data.
>"I hope you find the advances of these serverless and edge-ready databases as exciting as I do."
No I don't. They just have you pay 10 times the regular price while providing 10% of regular performance
No I don't. They just have you pay 10 times the regular price while providing 10% of regular performance
and I’m still using regular postgres just fine for over a decade and no plans to stop any time soon
serverless has mostly been hype and snake oil for me
Nothing beats a beefy box of metal
serverless has mostly been hype and snake oil for me
Nothing beats a beefy box of metal
what is your story for fault tolerance and replication (hopefully cross geo zone). Do you set and run everything yourself? How much effort(including learning curve) and expertise does it require?
Why wouldn't you use some cloud offering where you can get many of these for cheap if your data is not large?
Why wouldn't you use some cloud offering where you can get many of these for cheap if your data is not large?
What makes you think cloud is cheap, or reliable? AWS lambda does not provide any guarantees other than compensation if the uptime is less than 99.95 %. That is ~22 minutes/month. It's terrible. If it was reliable they would provide better guarantees. How long since a major outage? A couple of months.
Few people run everything themselves. Most use existing datacenters or rent the hardware. Then its basically the same as using a VPS from a cloud provider when it comes to difficulty and expertise.
Few people run everything themselves. Most use existing datacenters or rent the hardware. Then its basically the same as using a VPS from a cloud provider when it comes to difficulty and expertise.
> What makes you think cloud is cheap, or reliable?
"cheap" is relative, if your data is not large (gigabytes) then cost will likely be much smaller compared to expenses on engineer supporting custom solution.
> if the uptime is less than 99.95 %
It doesn't mean their services experience this downtime. They have their reputation supporting revenue on the line. Customers will go somewhere else if experience frequent downtime.
But the point is that with custom pgsql installation it is nontrivial to setup and support any kind of fault tolerance, plus you have a chance of all other kind of outages: network, your hosting provider, etc.
Buying cloud offering with one click looks like no brainer base line.
"cheap" is relative, if your data is not large (gigabytes) then cost will likely be much smaller compared to expenses on engineer supporting custom solution.
> if the uptime is less than 99.95 %
It doesn't mean their services experience this downtime. They have their reputation supporting revenue on the line. Customers will go somewhere else if experience frequent downtime.
But the point is that with custom pgsql installation it is nontrivial to setup and support any kind of fault tolerance, plus you have a chance of all other kind of outages: network, your hosting provider, etc.
Buying cloud offering with one click looks like no brainer base line.
The only thing that should require very strict uptime is the database. Lambda (for your backends) says 99.95% per region, which does seem kinda low, more what I'd expect for an AZ than an entire region. Can you easily add a second region for more 9s?
The only potential issue I've seen with cloud managed DBMSes is latency between application and DB, since they might be far apart. But that's something you check out day 1 and move away from if it's not tolerable. I would totally start there, not try to set it up myself.
[deleted]
I wish SQL DBs had some focus on implementing stateless protocols. Is there any reason the "connection pool" could not be built into the same service as the SQL database, and start a move to an RPC protocol instead of stateful protocol?
So instead of "set xact_abort on" being a command setting one of a hundred possible 100 stateful connection flags, such flags would be part of every network roundtrip (as it is with HTTP).
Of course long lived DB transactions, temporary connection scoped tables, etc would need to be adjusted a bit in approach. But a shift towards SQL over RPC is certainly not impossible.
And long lived, client managed database transactions are worse performance wise than doing the transaction in one roundtrip; SQL is powerful enough that stored procedure-style transactions with parameter tables can do anything -- and for cases they cannot, optimistic concurrency control should usually be chosen instead anyway.
The cases where a long lived/client managed SQL transaction is NEEDED is rather seldom.
So instead of "set xact_abort on" being a command setting one of a hundred possible 100 stateful connection flags, such flags would be part of every network roundtrip (as it is with HTTP).
Of course long lived DB transactions, temporary connection scoped tables, etc would need to be adjusted a bit in approach. But a shift towards SQL over RPC is certainly not impossible.
And long lived, client managed database transactions are worse performance wise than doing the transaction in one roundtrip; SQL is powerful enough that stored procedure-style transactions with parameter tables can do anything -- and for cases they cannot, optimistic concurrency control should usually be chosen instead anyway.
The cases where a long lived/client managed SQL transaction is NEEDED is rather seldom.
First off, a long-lived transaction is separate from a long-lived socket connection. They may correlate, but that's conflating two very different issues.
One could always use MySQL like HTTP; make a connection, authenticate, request a query, get the response, and close connection. On Postgres this is harder due to per-connection process overhead, but solutions like pgbouncer were made exactly for this.
But here's the fundamental difference: HTTP expects large numbers of disparate clients from literally anywhere with varying network quality/speed, and connection overhead would totally swamp your servers if they were stateful. Memory and file descriptors would quickly get in short supply.
Database access is inherently different. You shouldn't have random clients; you have a small, fixed set of client services and developers/admins connecting over a datacenter backplane, querying over and over and over again. The overhead of establishing/tearing down the sockets and re-authenticating becomes a performance bottleneck.
Folks don't create database connection pools because they're bored; they solve a very real and measurable architectural concern, just like HTTP pipelining did years ago and what HTTP/2 addresses through multiplexing: connection build up and tear down overhead. HTTP/3 goes further by avoiding TCP altogether in favor of custom connection handling over UDP.
But HTTP/3 just handles web assets. We regularly expect errors where we need to hit the reload button. SQL usage is markedly different. There is more of an emphasis on reliability at every step. Hitting a lock and retrying is very rare by comparison in the database world relative to the HTTP space. It happens (and it's a PITA), but it's nowhere near the norm.
As for transactions, you appear to regard them as a "sometimes" thing when if fact they're an "every time" thing. Every SELECT, INSERT, UPDATE, or DELETE, no matter how trivial involves a database transaction. They have to in order to enforce ACID.
I've written a few basic HTTP 1.x servers over the years in a few different languages. Fun exercise. I highly recommend it to get a better understanding of how the protocol works and common design tradeoffs. ACID databases are different. Very different. Mind bogglingly different. Orders of magnitude more complex even among the simplest. Compare the smallest, most lightweight web server you can find to SQLite or H2.
One could always use MySQL like HTTP; make a connection, authenticate, request a query, get the response, and close connection. On Postgres this is harder due to per-connection process overhead, but solutions like pgbouncer were made exactly for this.
But here's the fundamental difference: HTTP expects large numbers of disparate clients from literally anywhere with varying network quality/speed, and connection overhead would totally swamp your servers if they were stateful. Memory and file descriptors would quickly get in short supply.
Database access is inherently different. You shouldn't have random clients; you have a small, fixed set of client services and developers/admins connecting over a datacenter backplane, querying over and over and over again. The overhead of establishing/tearing down the sockets and re-authenticating becomes a performance bottleneck.
Folks don't create database connection pools because they're bored; they solve a very real and measurable architectural concern, just like HTTP pipelining did years ago and what HTTP/2 addresses through multiplexing: connection build up and tear down overhead. HTTP/3 goes further by avoiding TCP altogether in favor of custom connection handling over UDP.
But HTTP/3 just handles web assets. We regularly expect errors where we need to hit the reload button. SQL usage is markedly different. There is more of an emphasis on reliability at every step. Hitting a lock and retrying is very rare by comparison in the database world relative to the HTTP space. It happens (and it's a PITA), but it's nowhere near the norm.
As for transactions, you appear to regard them as a "sometimes" thing when if fact they're an "every time" thing. Every SELECT, INSERT, UPDATE, or DELETE, no matter how trivial involves a database transaction. They have to in order to enforce ACID.
I've written a few basic HTTP 1.x servers over the years in a few different languages. Fun exercise. I highly recommend it to get a better understanding of how the protocol works and common design tradeoffs. ACID databases are different. Very different. Mind bogglingly different. Orders of magnitude more complex even among the simplest. Compare the smallest, most lightweight web server you can find to SQLite or H2.
I understand all of this, I am not as ignorant as you seem to assume.
Well, you have a HTTP connection pool too, but they are not stateful in the way SQL connections are at all. You can send several requests after one another on the same HTTP connection, but the next request does not remember the previous one. Each request stands "on its own".
Which is very unlike SQL. And, client mamaged transactions build on this: They are stateful, each session can only hold one transaction at the time, and some buggy badly written code can thus easily go wild and fill up the connection pool and either a) take down that backend instance (if the size is capped) or b) use A LOT of connections and risk taking down the database.
With HTTP, the connection is held for as long as the network roundtrip then goes back to the pool.
With SQL, how long a piece of code holds on to a connection is unbounded. (If you use client managed transactions, or hold to a connection for temp tables or other reasons.)
Well, you have a HTTP connection pool too, but they are not stateful in the way SQL connections are at all. You can send several requests after one another on the same HTTP connection, but the next request does not remember the previous one. Each request stands "on its own".
Which is very unlike SQL. And, client mamaged transactions build on this: They are stateful, each session can only hold one transaction at the time, and some buggy badly written code can thus easily go wild and fill up the connection pool and either a) take down that backend instance (if the size is capped) or b) use A LOT of connections and risk taking down the database.
With HTTP, the connection is held for as long as the network roundtrip then goes back to the pool.
With SQL, how long a piece of code holds on to a connection is unbounded. (If you use client managed transactions, or hold to a connection for temp tables or other reasons.)
> With HTTP, the connection is held for as long as the network roundtrip then goes back to the pool.
• Keep-Alive has entered the chat • HTTP pipelining popped in • Connection multiplexing has entered the room • Web Sockets pokes head in • Server-Sent Events chimes in as well
And yes, again, the connection model for thousands or millions of disparate IPs from the Internet will obviously be different from resources acting on a network within a closely controlled datacenter. You claim to know all this but seem to gloss over these important points.
• Keep-Alive has entered the chat • HTTP pipelining popped in • Connection multiplexing has entered the room • Web Sockets pokes head in • Server-Sent Events chimes in as well
And yes, again, the connection model for thousands or millions of disparate IPs from the Internet will obviously be different from resources acting on a network within a closely controlled datacenter. You claim to know all this but seem to gloss over these important points.
In other words, you should cache and shard your data. I hate this industry.
Author of the article here. I'd like to clarify that the article is meant to be about SQL databases only, although I enjoy reading the comments comparing SQL/NoSQL.
Also, "edge" means edge deployment environment/runtime like CloudFlare workers, Vercel Edge Runtime, etc. Not sensors, etc.
Also, "edge" means edge deployment environment/runtime like CloudFlare workers, Vercel Edge Runtime, etc. Not sensors, etc.
The "serverless" angle is super compelling for us. We don't have a lot of time to think about this kind of thing. Being able to go from 0 to 100TB with compute/storage scaling automagically is simply bananas value. I don't really care what it costs anymore. I know the herd will mostly protect us with regard to pricing (our utilization is paltry compared to advertised use cases).
I totally get the HTAP argument now. I have absolutely zero anxiety about some rogue select causing trouble in a reporting context because of how trivial everything became. Things like adding read replicas for one-off reporting needs is a non-event now.
I totally get the HTAP argument now. I have absolutely zero anxiety about some rogue select causing trouble in a reporting context because of how trivial everything became. Things like adding read replicas for one-off reporting needs is a non-event now.
Though serverless is compelling, the few cases where I've actually seen someone need the sudden increase in compute with both Firestore and DynamoDB, it failed to deliver performantly. That being said this was in the 2010s, I'm sure things have improved by now.
Serverless is a footgun. The limit on response size means people who don’t build things with them in mind suddenly can’t scale when they get actual customers.
Ah, so this is web-scale, at long last
At PolyScale [1] we tackle many of the same challenges. Some of this article feels a little dated to me but the data distribution, connectivity and scaling challenges are valid.
We use caching to store data and run SQL compute at the edge. It is wire protocol compatible with various databases (Postgres, MySQL, MS SQL, MariaDB) and it dramatically reduces query execution times and lower latency. It also has a JS driver for SQL over HTTP, as well as connection pooling for both TCP and HTTP.
https://www.polyscale.ai/
We use caching to store data and run SQL compute at the edge. It is wire protocol compatible with various databases (Postgres, MySQL, MS SQL, MariaDB) and it dramatically reduces query execution times and lower latency. It also has a JS driver for SQL over HTTP, as well as connection pooling for both TCP and HTTP.
https://www.polyscale.ai/
This pitch is rather opaque to me. How does cache invalidation actually work?
I don't see how cache invalidation happens at all unless all changes go through PolyScale. What about making a change to the database directly?
I don't see how cache invalidation happens at all unless all changes go through PolyScale. What about making a change to the database directly?
Thanks for the questions. At a very high level, the AI uses statistical models that learn in real-time and estimate how frequently the data on the database is changing. The TTL's get set accordingly and are set per SQL query. The model looks at many inputs such as the payload sizes being returned from the database as well as arrival rates.
If PolyScale can see mutation queries (inserts, updates, deletes) it will automatically invalidate, just the effected data from the cache, globally.
If you make changes directly to the database out of band to PolyScale, you have a few options depending on the use case. Firstly, the AI, statistical based models will invalidate. Secondly, you can purge - for example after a scheduled import etc. Thirdly, you can plug in CDC streams to power the invalidations.
Feel free to ping me if you would like to dig in deeper (ben at) and this document provides more detail on the caching protocol: https://docs.polyscale.ai/how-does-it-work#caching-protocol
This blog also goes in to detail on how invalidation works: https://www.polyscale.ai/blog/approaching-cache-invalidation...
If PolyScale can see mutation queries (inserts, updates, deletes) it will automatically invalidate, just the effected data from the cache, globally.
If you make changes directly to the database out of band to PolyScale, you have a few options depending on the use case. Firstly, the AI, statistical based models will invalidate. Secondly, you can purge - for example after a scheduled import etc. Thirdly, you can plug in CDC streams to power the invalidations.
Feel free to ping me if you would like to dig in deeper (ben at) and this document provides more detail on the caching protocol: https://docs.polyscale.ai/how-does-it-work#caching-protocol
This blog also goes in to detail on how invalidation works: https://www.polyscale.ai/blog/approaching-cache-invalidation...
This is interesting! How does polyscale works, especially this part:
> PolyScale automatically and intelligently caches or invalidates data close to where it is being requested.
> PolyScale automatically and intelligently caches or invalidates data close to where it is being requested.
[deleted]
None of these things are new. Connection pooling (in particular) has been around for decades. Perhaps the author just recently discovered it?
The author also mentions Neon is the first "pioneer" to do disaggregated storage. It is mentioned in the 2006 Bigtable paper, and probably earlier than that too.
Databases like Oracle Parallel Server were doing disaggregated storage more than a decade before that.
Connection pooling is one area where NoSQL databases shine. Classic SQL is extremely stateful. It was designed was designed in a very different age when it was expected to mostly be used directly by programmers and non-technical users and be as friendly as possible. The SQL standard defines some state that must be stored along with each session, such as temporary tables, current schema, current timezone etc. This means that sessions have a pretty significant memory overhead and generally require a thread on the server side (and probably the client-side too).
NoSQL databases got rid of many useful things when they replaced SQL with JSON query languages and simplified SQL dialect, but I think they got a net positive when they did away with statefulness and replaced that with a simple request/response APIs. With this small you can easily multiplex many in-flight requests on a TCP single connection, and let both the server and the client handle requests on-demand, without having to allocate any memory and threads that serve most of their time idling away. The client (and supposedly the server, if it's using io_uring) can run all I/O asynchronously and increase available concurrency even more.
In short, you can get more concurrency and better scaling predictability for the same hardware since you don't have to optimize the way your connection pools are balanced across different clients. It's really one of these few things which is pure fun and joy and unicorns and rainbows when I'm designing a service with a NoSQL DB.
NoSQL databases got rid of many useful things when they replaced SQL with JSON query languages and simplified SQL dialect, but I think they got a net positive when they did away with statefulness and replaced that with a simple request/response APIs. With this small you can easily multiplex many in-flight requests on a TCP single connection, and let both the server and the client handle requests on-demand, without having to allocate any memory and threads that serve most of their time idling away. The client (and supposedly the server, if it's using io_uring) can run all I/O asynchronously and increase available concurrency even more.
In short, you can get more concurrency and better scaling predictability for the same hardware since you don't have to optimize the way your connection pools are balanced across different clients. It's really one of these few things which is pure fun and joy and unicorns and rainbows when I'm designing a service with a NoSQL DB.
Mongo, one of the largest NoSQL databases, uses a thread on the server per connection, and is known for using around 1mb per one of those connections.
Frankly speaking, Mongo is probably the worst NoSQL database out there, and it has given bad rep for other NoSQL database which do have their use cases, such Cassandra, DynamoDB, Couchbase and Redis (yes, let's not forget that Redis is also a NoSQL database, without the hype).
Redis is well-known (and sometimes criticized) for being single-threaded, but managing a connection pool on the client side is still necessary, so my statement is obviously not true for ALL NoSQL databases. But it is at least true for Cassandra and as far as I understand for DynamoDB and Couchbase to some degree.
Redis is well-known (and sometimes criticized) for being single-threaded, but managing a connection pool on the client side is still necessary, so my statement is obviously not true for ALL NoSQL databases. But it is at least true for Cassandra and as far as I understand for DynamoDB and Couchbase to some degree.
No statements will apply to all of anything, just thought I'd clarify since in ten years of working with nosql by large the largest deployments were with Mongo. Bad luck maybe :)
There are reactive and non-reactive based SQL dbs too. I know someone at Amazon working on one.
You can have state per connection and still use epoll or whatever. Even with NodeJS or Vertx you can open a connection against a worker pool, maintain state for that connection, and it doesn't require thread/process per connection. That's merely an implementation detail (and nice isolation for extensions etc).
There are reactive and non-reactive based SQL dbs too. I know someone at Amazon working on one.
You can have state per connection and still use epoll or whatever. Even with NodeJS or Vertx you can open a connection against a worker pool, maintain state for that connection, and it doesn't require thread/process per connection. That's merely an implementation detail (and nice isolation for extensions etc).
Everybody knows relational databases don't scale because they use joins and write to disk. Relational databases weren't built for Web Scale. MongoDB is Web Scale. You turn it on, and it scales right up. Shards are the secret ingredient in the Web Scale sauce.
Did I ever say that?
I said "one area where NoSQL databases shine", "NoSQL databases got rid of many useful things", and "one of these few things which is pure fun [... with] NoSQL databases".
Not sure how can you interpret this as me saying that Relational DBs are bad or that MongoDB is great.
I said "one area where NoSQL databases shine", "NoSQL databases got rid of many useful things", and "one of these few things which is pure fun [... with] NoSQL databases".
Not sure how can you interpret this as me saying that Relational DBs are bad or that MongoDB is great.
He’s referencing the infamous “mongodb is webscale” video from about a decade ago
For those too lazy to search:
"MongoDB is Web Scale" ~5.5mins https://www.youtube.com/watch?v=HdnDXsqiPYo
"MongoDB is Web Scale" ~5.5mins https://www.youtube.com/watch?v=HdnDXsqiPYo
I have used both SQL and NoSQL databases in the cloud. My sense of the situation at the moment is that some NoSQL databases have begun to focus on AI and LLM applications, apparently in order to provide scalable storage to these applications, which can be used for things like the persistence of state across many interactions.
However, there are always going to be legions of use cases for traditional database use, and the question continues to be, should everything that could need to scale massively use a NoSQL backend, or can some applications get by with something that looks like a traditional SQL architecture in 99+% of cases?
I think that many applications could be constructed with a NoSQL database as the backend for applications that are primarily reading content, while the applications that require the greatest access to CRUD functionality could interact with a SQL database using connection pooling to minimize resource utilization or latency at scale.
With this in mind, I could see applications where editing the backend is done in a SQL-based version of the database, while rendering content from the backend is done against a NoSQL version of the same database. There would probably be some momentary differences between the two, but the interface between the SQL and NoSQL version of the database could be a pipeline and therefore, could be optimized.
However, there are always going to be legions of use cases for traditional database use, and the question continues to be, should everything that could need to scale massively use a NoSQL backend, or can some applications get by with something that looks like a traditional SQL architecture in 99+% of cases?
I think that many applications could be constructed with a NoSQL database as the backend for applications that are primarily reading content, while the applications that require the greatest access to CRUD functionality could interact with a SQL database using connection pooling to minimize resource utilization or latency at scale.
With this in mind, I could see applications where editing the backend is done in a SQL-based version of the database, while rendering content from the backend is done against a NoSQL version of the same database. There would probably be some momentary differences between the two, but the interface between the SQL and NoSQL version of the database could be a pipeline and therefore, could be optimized.
Someone migrated from RDS to Neon (or similar service)?
Did you notice significant improvements in terms of perf, features and pricing?
Not being able to reduce the storage size on RDS is a major pain point for us.
Did you notice significant improvements in terms of perf, features and pricing?
Not being able to reduce the storage size on RDS is a major pain point for us.
Please email [email protected] we will share examples and help you out
Modern implies progress. Serverless isn't progress. It's not the rising tide that lifts all boats.
The development of things saddens me. (re: this whole thing about serverless and edge).
It should be that it's becoming easier to have a robust database (or job queue, or full text search, etc) on your premises, not have more and more go to the cloud.
Though it is true that managing your own infrastructure can be challenging, it is not inherently so. One can easily imagine self healing and self managing infrastructure, physical hardware deterioration and replacement aside.
EDIT: I want to clarify that I'm not denouncing the cloud. My point is simply that it should be easier to also manage your own fleet if you so choose. This could mean using VMs, bare metal or what have you. Even managing a fleet of VMs is nightmareish today.
It should be that it's becoming easier to have a robust database (or job queue, or full text search, etc) on your premises, not have more and more go to the cloud.
Though it is true that managing your own infrastructure can be challenging, it is not inherently so. One can easily imagine self healing and self managing infrastructure, physical hardware deterioration and replacement aside.
EDIT: I want to clarify that I'm not denouncing the cloud. My point is simply that it should be easier to also manage your own fleet if you so choose. This could mean using VMs, bare metal or what have you. Even managing a fleet of VMs is nightmareish today.
[deleted]
Can you explain how can physical hardware concerns be handwaved away?
It's not just about the hardware itself, that's the easiest part.
It's about building and maintaining the electrical/cooling/network infrastructure the servers require. It's about having multiple locations of that in case your building's power or network goes down/there's a flood/somebody steals all your stuff/whatever else.
Or you rent a rack in a colo (or five)... But that's just a step away from going full cloud, you just do a lot of work yourself and get no guarantees and no flexibility. At that point, why not just go full cloud?
It's not just about the hardware itself, that's the easiest part.
It's about building and maintaining the electrical/cooling/network infrastructure the servers require. It's about having multiple locations of that in case your building's power or network goes down/there's a flood/somebody steals all your stuff/whatever else.
Or you rent a rack in a colo (or five)... But that's just a step away from going full cloud, you just do a lot of work yourself and get no guarantees and no flexibility. At that point, why not just go full cloud?
> It's about building and maintaining the electrical/cooling/network infrastructure the servers require.
Except at the extreme high end of scale, you never do this yourself. Rent racks in a colocation. It's a very clean separation of duties. You handle all the tech work, they handle all the real estate upkeep.
> Or you rent a rack in a colo (or five)... But that's just a step away from going full cloud
What? Not even close. When you rent a rack in a colo you have 100% of the benefits of owning the hardware (much higher performance, much lower cost). Just because you let someone else do the A/C and generator maintenance (and other non-computer real estate logistics) doesn't make it anything at all like the cloud.
Except at the extreme high end of scale, you never do this yourself. Rent racks in a colocation. It's a very clean separation of duties. You handle all the tech work, they handle all the real estate upkeep.
> Or you rent a rack in a colo (or five)... But that's just a step away from going full cloud
What? Not even close. When you rent a rack in a colo you have 100% of the benefits of owning the hardware (much higher performance, much lower cost). Just because you let someone else do the A/C and generator maintenance (and other non-computer real estate logistics) doesn't make it anything at all like the cloud.
On GCP, they will live migrate your running VMs to new racks and you won't likely know unless you look for it in the logs, super nice feature, I once got bit by AWS and a disk physical failure, had to migrate myself (really a nuke and recreate since we couldn't do anything with the VM)
This is not the 90s - monitoring and alerting are far more robust, and supply chains far more just in time.
There’s no reason a modern fleet couldn’t detect failures in hardware and automatically order replacement from Amazon or whatever. This is not to say you won’t need personnel, but you would be surprised how much of the fleet management at AWS and GCP at least are brute forced (as opposed to being completely automatic). To their defense they have a far more complicated and diverse fleet than what I’m describing, which is sort of my point.
99% of customers just need a highly available setup for their stateful boxes (DBs) and some for their stateless services. And the great thing about this setup is you can extend the stateless bit (with the cost of latency) to the cloud more or less infinitely.
As far as the rest of your point about cooling and network - it's a good point, but for a workload that isn't a datacenter, in my experience the majority of outages aren't due to that - it's due to misconfiguration.
Take a personal house. How often does someone break into the average person's home? Pretty unlikely in a low crime area. Take internet. There are some areas in the United States where there are multiple 1Gbs or even 10Gbs internet providers, you could redundantly network. In any case it's not that the cloud shouldn't be used, it's just interesting the direction things are going.
Of course, if money isn't an issue by all means people should use serverless and cloud spanner and be done with it.
There’s no reason a modern fleet couldn’t detect failures in hardware and automatically order replacement from Amazon or whatever. This is not to say you won’t need personnel, but you would be surprised how much of the fleet management at AWS and GCP at least are brute forced (as opposed to being completely automatic). To their defense they have a far more complicated and diverse fleet than what I’m describing, which is sort of my point.
99% of customers just need a highly available setup for their stateful boxes (DBs) and some for their stateless services. And the great thing about this setup is you can extend the stateless bit (with the cost of latency) to the cloud more or less infinitely.
As far as the rest of your point about cooling and network - it's a good point, but for a workload that isn't a datacenter, in my experience the majority of outages aren't due to that - it's due to misconfiguration.
Take a personal house. How often does someone break into the average person's home? Pretty unlikely in a low crime area. Take internet. There are some areas in the United States where there are multiple 1Gbs or even 10Gbs internet providers, you could redundantly network. In any case it's not that the cloud shouldn't be used, it's just interesting the direction things are going.
Of course, if money isn't an issue by all means people should use serverless and cloud spanner and be done with it.
> This is not to say you won’t need personnel
Ding ding ding, we have a winner!
Paying premiums for BigCloud means not paying salaries, not worrying about an outage that could happen while your seniors are on vacation, not needing to set up resilient internal processes and controls for datacenter management, not worrying about datacenter management compliance, etc. etc.
Needing to hire datacenter personnel is a problem and it is a problem that BigCloud solved.
Ding ding ding, we have a winner!
Paying premiums for BigCloud means not paying salaries, not worrying about an outage that could happen while your seniors are on vacation, not needing to set up resilient internal processes and controls for datacenter management, not worrying about datacenter management compliance, etc. etc.
Needing to hire datacenter personnel is a problem and it is a problem that BigCloud solved.
You're thinking about it the wrong way. Sure you're not paying salaries, but now you're paying for experts who understand the cloud and you're paying more for those people compared to datacenter people. At Azure I was surprised how many data center people didn't even have a college degree and how little they were paid. Ultimately the only thing that matters is the total cost. To take true advantage of the cloud you need to use cloud specific technologies - serverless being the greatest example. Cloud VMs are neat and all, but in a sense it's the worst of both worlds.
I'm not saying there isn't value in the cloud. I'm saying most people are overpaying. BigCloud didn't solve this any more than paying employees in general to solve your problems. With the era of free money coming to the end, many companies will come to this realization themselves in any case. BigTech clouds have 50%+ margins - something will give eventually.
Any serious company is still going to have to pay oncallers, and admins with or without cloud. It's not like using the cloud absolves you from maintenance (pretty much every company with a valuation more than 100 million has an infrastructure team, and uses the cloud. So clearly the cloud doesn't mean you don't have to maintain your own infrastructure). And now we come back to my point - why isn't the fleet easier to maintain to begin with? I'm not even talking about bare-metal necessarily. Say you use VMs. Still a huge hassle.
I'm not saying there isn't value in the cloud. I'm saying most people are overpaying. BigCloud didn't solve this any more than paying employees in general to solve your problems. With the era of free money coming to the end, many companies will come to this realization themselves in any case. BigTech clouds have 50%+ margins - something will give eventually.
Any serious company is still going to have to pay oncallers, and admins with or without cloud. It's not like using the cloud absolves you from maintenance (pretty much every company with a valuation more than 100 million has an infrastructure team, and uses the cloud. So clearly the cloud doesn't mean you don't have to maintain your own infrastructure). And now we come back to my point - why isn't the fleet easier to maintain to begin with? I'm not even talking about bare-metal necessarily. Say you use VMs. Still a huge hassle.
[deleted]
> BigTech clouds have 50%+ margins - something will give eventually.
Yes, the oligopoly, and the vendor lock-in.
Certainly won't be expecting the "advantage" of being able to outsource your sysadmins to somewhere else at the drop of a hat to be the thing that gives.
Yes, the oligopoly, and the vendor lock-in.
Certainly won't be expecting the "advantage" of being able to outsource your sysadmins to somewhere else at the drop of a hat to be the thing that gives.
How often do people actually migrate clouds?
Vendor lock in at this level is not really an issue for most, trying to be agnostic will create more problems and time sinks
Vendor lock in at this level is not really an issue for most, trying to be agnostic will create more problems and time sinks
> Paying premiums for BigCloud means not paying salaries
You need all the same people to manage the same software stack, regardless of whether the VMs sit on hardware you own or at an AWS rack. Nearly all the work is on the software side.
The physical bit of maintaining the boxes is a minimal percentage of the work. At various startups we usually didn't have anyone hired to do this work because there wasn't enough to justify a person. Most simple changes (like pull and replace a hot-plug drive) can be done by the colo personnel and for larger work someone would drive to the colo maybe once a month. You only start to need dedicated hardware maintenance personnel at a very large scale.
The premium you're paying for cpu and bandwidth at your BigCloud is so enormous that it'll easily pay many more salaries than the people you need even if you reach the scale of needing dedicated hardware people.
You need all the same people to manage the same software stack, regardless of whether the VMs sit on hardware you own or at an AWS rack. Nearly all the work is on the software side.
The physical bit of maintaining the boxes is a minimal percentage of the work. At various startups we usually didn't have anyone hired to do this work because there wasn't enough to justify a person. Most simple changes (like pull and replace a hot-plug drive) can be done by the colo personnel and for larger work someone would drive to the colo maybe once a month. You only start to need dedicated hardware maintenance personnel at a very large scale.
The premium you're paying for cpu and bandwidth at your BigCloud is so enormous that it'll easily pay many more salaries than the people you need even if you reach the scale of needing dedicated hardware people.
Yep, in the old days (almost 20 years ago now), I worked at a startup with its own racks. We'd go up there once a month to swap some drives. In my 5 years there, I had to use remote hands exactly twice to reboot a machine. A few other times, one of the servers froze but we were able to reboot it with ILO. This was 3 racks, about 30 machines spread between them (definitely a bunch of empty space, too.)
Happy you, I was in the same situation but I was in the server room daily. Practically every day something went wrong.
I am genuinely curious about both the software and hardware stack if you were there every day due to something going wrong.
1. First of all, a good bare metal setup leaves much of the software fleet management able to be done remotely. So if you were there because of that then clearly this wasn't done right. I'm talking about SSH access at a bare minimum, and ideally out of band access as well.
2. I'd say the things that go wrong in a data center are plentiful, but should be predictable. Power, network or cooling related issues means you picked the wrong site or your vendor screwed you. That leaves us to the actual hardware. Sourcing good hardware is obviously critical. Modern Dell and HP enterprise machines should be giving you very, very reliable hardware assuming the beforementioned concerns are addressed. It is true that disks fail, and sometimes memory, but if you were there literally every day there is just a critical failure in your setup somewhere.
Even if you had a data center with literally a thousand machines. An uncorrelated failure happening every day is so unlikely that it's not really worth mentioning. Correlate failures could certainly happen. Bad batch of disks, etc, but still shouldn't result in you being there literally every day. I could imagine a series of bad days though, sure.
1. First of all, a good bare metal setup leaves much of the software fleet management able to be done remotely. So if you were there because of that then clearly this wasn't done right. I'm talking about SSH access at a bare minimum, and ideally out of band access as well.
2. I'd say the things that go wrong in a data center are plentiful, but should be predictable. Power, network or cooling related issues means you picked the wrong site or your vendor screwed you. That leaves us to the actual hardware. Sourcing good hardware is obviously critical. Modern Dell and HP enterprise machines should be giving you very, very reliable hardware assuming the beforementioned concerns are addressed. It is true that disks fail, and sometimes memory, but if you were there literally every day there is just a critical failure in your setup somewhere.
Even if you had a data center with literally a thousand machines. An uncorrelated failure happening every day is so unlikely that it's not really worth mentioning. Correlate failures could certainly happen. Bad batch of disks, etc, but still shouldn't result in you being there literally every day. I could imagine a series of bad days though, sure.
Either you had thousands of machines (at which point is totally makes sense to hire a dedicated person with all the money you're saving) or the site had environmental problems (dirty power, bad cooling, etc?) causing the issues.
Hardware is unbelievably reliable, systems normally run for many years without any attention.
Hardware is unbelievably reliable, systems normally run for many years without any attention.
How many systems did you have? What sorts of problems?
You are right, but this was also solved by "dedicated server" folks years before cloud was a thing.
There is some development on that front too. For postgres, check out CrunchyData's postgres operator (https://access.crunchydata.com/documentation/postgres-operat...) where with a single config file you get a HA database with read replica(s), connection pooling via pgbouncer and multiple backup targets via pgbackrest with cloning and point-in-time recovery
I personally like the Zalando operator better, you can add databases and users by updating the CRD, feature parity between the two on HA is pretty good
https://github.com/zalando/postgres-operator
https://github.com/zalando/postgres-operator
You can also use pgvector with langchain to create a weird version of search if so inclined.
> physical hardware deterioration and replacement aside.
I mean... if you ignore the hard parts of self managing then self managing is in deed easier lol
I mean... if you ignore the hard parts of self managing then self managing is in deed easier lol
Self managing isn’t hard just because of that. You could use VMs with your cloud provider of choice and my point stands.
I'd argue that has gotten hugely easier. The problem is we have gotten hugely more demanding as well, so it ends up still being difficult.
> This could mean using VMs, bare metal or what have you.
For bare metal would something like Equinix fit?
> Even managing a fleet of VMs is nightmareish today.
What about fly.io?
For bare metal would something like Equinix fit?
> Even managing a fleet of VMs is nightmareish today.
What about fly.io?
fly.io has had alot of reliability problems in the past, with lots of users on HN and elsewhere talking about a whole host of problems from disappearing VMs to bad backups to poor uptime.
I love their model, but execution lacks.
That said, if they can get a handle on reliability and uptime, its extremely compelling
I love their model, but execution lacks.
That said, if they can get a handle on reliability and uptime, its extremely compelling
> it is true that managing your own infrastructure can be challenging, it is not inherently so.
The biggest challenge when you have on-premise infrastructure is battling managers to get an additional server.
I have seen managers laughing at my team leader when he asked for a server to do some QA. We needed the server to perform some tests for a critical product. They even had the audacity to say "Hey Manager Bob, how long have you asked for a server?" Manager Bob answered "It's been month's now"
Granted I think that's an extreme example but I don't doubt it was a common occurrence back in the day. Now I also have worked on enterprises where asking fora server (Or RAM increment in a given server) is as easy as submitting a ticket and waiting for a FEW DAYS.
Cloud is more expense on the long run, but it sure gives you agility to do things.
The biggest challenge when you have on-premise infrastructure is battling managers to get an additional server.
I have seen managers laughing at my team leader when he asked for a server to do some QA. We needed the server to perform some tests for a critical product. They even had the audacity to say "Hey Manager Bob, how long have you asked for a server?" Manager Bob answered "It's been month's now"
Granted I think that's an extreme example but I don't doubt it was a common occurrence back in the day. Now I also have worked on enterprises where asking fora server (Or RAM increment in a given server) is as easy as submitting a ticket and waiting for a FEW DAYS.
Cloud is more expense on the long run, but it sure gives you agility to do things.
Yeah the cloud is a lovely weapon against the BOFH. They smarten right up when you shrug your shoulders and say "Oh, I guess I'll just buy some cloud."
oh, your luser account is 'letsdothisagain', great thannnnks. I'll take care of that right now.
There is a middle ground between the cloud and on premise. You can get a VPS or a dedicated server from a traditional host. If you have a running tab with them, which is common for operations like this, you get your servers in a few hours, sometimes minutes.
You don't have to go all in. You can have your own servers and rent when you need additional capacity. Best of both worlds.
While there are lots of cloud providers also trying to be edge providers, I would argue that "The Far Edge" is a great opportunity to improve and develop infrastructure that is easier to run on your own hardware.
What worked for cloud won't work for edge in most cases. Having to do processing locally means processing on your own hardware.
We've seen this as the reason a lot of companies are adopting tools like NATS.io to be more cloud agnostic and/or be able to practically run at the Edge.
What worked for cloud won't work for edge in most cases. Having to do processing locally means processing on your own hardware.
We've seen this as the reason a lot of companies are adopting tools like NATS.io to be more cloud agnostic and/or be able to practically run at the Edge.
I keep rejecting this definition of "serverless" in my head. There's just as much server, it's just that someone else owns and operates the server, and holds your data or application hostage when they want to. This thing currently called "serverless" is more like "server as a service", and creates more lock-in than what came before.
True serverless would mean a return to dumb interchangeable servers: static progressive web applications hosted by dumb static http servers (e.g. github pages), connecting to interchangeable data storage (e.g. W3C solid pods), with client-side peer to peer synchronization of data using CRDT algorithms (e.g. Automerge, YJS, ...). When I think of the word "serverless", that's what comes to mind.
True serverless would mean a return to dumb interchangeable servers: static progressive web applications hosted by dumb static http servers (e.g. github pages), connecting to interchangeable data storage (e.g. W3C solid pods), with client-side peer to peer synchronization of data using CRDT algorithms (e.g. Automerge, YJS, ...). When I think of the word "serverless", that's what comes to mind.
I always love this take as if AWS / GCP / Azure / literally any data center couldn't already do this to you.
As for more lock in, how? If I use aurora postgres serverless I am 100% free to migrate to a regular postgres server, even on another provider.
Nobody is thinking there is no server, except maybe my grandmother.
As for more lock in, how? If I use aurora postgres serverless I am 100% free to migrate to a regular postgres server, even on another provider.
Nobody is thinking there is no server, except maybe my grandmother.
I feel like Aurora might be a bad example for anti-lock-in. Perhaps vanilla RDS Postgres would be a better one?
Aurora does add bells and whistles on top of vanilla Postgres that you’d be hard-pressed to find from other DBaaS vendors.
Sure, you can pg_dump and pg_restore to another provider but you lose all the goodies that made you choose Aurora in the first place.
For clarity, I’m a long-time happy user of Aurora and spend $super_big_money on it. Worth every penny IMHO.
Aurora does add bells and whistles on top of vanilla Postgres that you’d be hard-pressed to find from other DBaaS vendors.
Sure, you can pg_dump and pg_restore to another provider but you lose all the goodies that made you choose Aurora in the first place.
For clarity, I’m a long-time happy user of Aurora and spend $super_big_money on it. Worth every penny IMHO.
Could you expand on this a bit? For context, I am also an Aurora user. I have on occasion used the functions to invoke lambdas and IAM auth, but 99.9% of the time, it's just stuff that comes with Postgres.
I'm honestly curious as to which features you find most compelling that can't be found in vanilla Postgres.
I'm honestly curious as to which features you find most compelling that can't be found in vanilla Postgres.
One single database cluster might not be an issue to migrate to another cloud provider.
But that single DB is just a piece of the business puzzle. Networking, web applications, even backups. That's hard to migrate (And hard here means it will take massive effort and time)
Good teams have plans in case they need to migrate. But I think not all teams are prepared for such scenario.
But that single DB is just a piece of the business puzzle. Networking, web applications, even backups. That's hard to migrate (And hard here means it will take massive effort and time)
Good teams have plans in case they need to migrate. But I think not all teams are prepared for such scenario.
Brb gonna start up my serverless MS Word.
[deleted]
Hear hear.
I'd be really interested in an open standard that would expose something like IndexedDB on the client-side while enabling sync and basic business logic. Maybe inspired by the firebase API.
I'd be really interested in an open standard that would expose something like IndexedDB on the client-side while enabling sync and basic business logic. Maybe inspired by the firebase API.
Not sure if you're thinking more of an official standard but PouchDB is open source and sounds similar to what you're talking about: https://pouchdb.com/
A strange take. If you’re going to be pedantic you might as well be correct - server less would mean literally that, no server required, e.g. Apple Notes or Microsoft Word 2010 and more similar to the end of your comment (a solid pod isn't serverless either btw) and CRDT is totally irrelevant here - you could use CRDTs and still not have an offline application.
A GitHub page is in no way serverless. It’s totally inaccessible without internet and requires literally a remote server to function. Ironically GitHub page is more similar to the marketing definition of serverless.
A GitHub page is in no way serverless. It’s totally inaccessible without internet and requires literally a remote server to function. Ironically GitHub page is more similar to the marketing definition of serverless.
If we’re going to be pedantic, let me point out that for a pwa a connection to the server is only required for initial install and successive data synchronization, so the operation of the web app I described is indeed literally serverless outside of those edge cases.
> for a pwa a connection to the server is only required for initial install and successive data synchronization, so the operation of the web app I described is indeed literally serverless outside of those edge cases.
Should be. But I'm yet to see a PWA like that; all I've been victim of experiencing had all meaningful operations involve a round-trip through the cloud.
Should be. But I'm yet to see a PWA like that; all I've been victim of experiencing had all meaningful operations involve a round-trip through the cloud.
[deleted]
I did the same for a long time, because it was obvously marketing BS, but when I looked into it a bit I realised that it was actually quite useful to have "programmable HTTP endpoints" og "Chron jobs in the cloud" where you don't have to worry about the details of running them. If they only run occasionally, they can be quite cheap too.
And since the major cloud providers have something like that, your are no more hostage with these than you are with any other cloud stuff.
And since the major cloud providers have something like that, your are no more hostage with these than you are with any other cloud stuff.
This seems to be getting pendantic about nomenclature.
There is no "true serverless", there is only the usage of the word that the majority of people use, which is to mean server-as-a-service. Nobody suggested it's a way to avoid lock-in. It's a way to avoiding managing servers.
I don't see the problem here.
There is no "true serverless", there is only the usage of the word that the majority of people use, which is to mean server-as-a-service. Nobody suggested it's a way to avoid lock-in. It's a way to avoiding managing servers.
I don't see the problem here.
When I saw serverless, my mind when right to ultra lightweight database-as-a-library like SQLlite. Not AWS or azure cloud.
Same here. In my formative years I was led to believe you had to use a “real” RDBMS for everything- MySQL or Postgres. Anything else was just a toy not suitable for use in the real world.
I succumbed to the SQLite hype train in 2020 when every other post on HN was about it. I started building things with it. First, small things. Then bigger things.
Now I’m at the point where I default to starting most things with SQLite unless there’s a really good reason. It’s incredible how far SQLite can take you. It feels almost like a cheat code. Wish I had jumped on the train years ago.
I succumbed to the SQLite hype train in 2020 when every other post on HN was about it. I started building things with it. First, small things. Then bigger things.
Now I’m at the point where I default to starting most things with SQLite unless there’s a really good reason. It’s incredible how far SQLite can take you. It feels almost like a cheat code. Wish I had jumped on the train years ago.
> I succumbed to the SQLite hype train in 2020 when every other post on HN was about it
Is it really a hype train when every 6-12 months since I joined this site there has been a ~1month period of sqlite on the front page every day? At some point a repeated and perennial "hype cycle" might just in fact be enthusiasm about a good product.
Is it really a hype train when every 6-12 months since I joined this site there has been a ~1month period of sqlite on the front page every day? At some point a repeated and perennial "hype cycle" might just in fact be enthusiasm about a good product.
When "serverless" just got started and mostly focused on running functions with infinite (and automatic) scalability, the term "Functions-as-a-Service" (FaaS) seemed like a good competitor for a while, but that ship has long sailed.
It's a confusing term, but it's not the first one. We survived "JavaScript", and complaining it's not related to Java at all stopped being fashionable along with flip phones and it's only ever done as a joke[1]. I foresee the same thing would happen for serverless in 10 years, and we'll get tired of complaining that this term sucks.
FWIW, we just have to internalize that serverless means "a service where you don't have to provision and manage your cloud servers and you don't even know how many of them are out there", just we collectively internalized that the HTTP Authorization header is the header responsible for Authentication.
[1] https://news.ycombinator.com/item?id=36782761
It's a confusing term, but it's not the first one. We survived "JavaScript", and complaining it's not related to Java at all stopped being fashionable along with flip phones and it's only ever done as a joke[1]. I foresee the same thing would happen for serverless in 10 years, and we'll get tired of complaining that this term sucks.
FWIW, we just have to internalize that serverless means "a service where you don't have to provision and manage your cloud servers and you don't even know how many of them are out there", just we collectively internalized that the HTTP Authorization header is the header responsible for Authentication.
[1] https://news.ycombinator.com/item?id=36782761
>This thing currently called "serverless" is more like "server as a service"
You can go ahead and call it "server as a service" (and have everyone look at you funny) while the rest of the development world cares zero about the pedantry and continues to build serverless applications without worrying about planning around or maintaining a server.
"Serverless uses servers!" can be added to the list of predictable comments, along with "The Economics Nobel isn't real!" and "Correlation isn't causation!". We get it, it doesn't need to be repeated every time an adjacent subject is discussed.
You can go ahead and call it "server as a service" (and have everyone look at you funny) while the rest of the development world cares zero about the pedantry and continues to build serverless applications without worrying about planning around or maintaining a server.
"Serverless uses servers!" can be added to the list of predictable comments, along with "The Economics Nobel isn't real!" and "Correlation isn't causation!". We get it, it doesn't need to be repeated every time an adjacent subject is discussed.
Sorry but this is just buzzword bingo. Why not call it cloud? Why throw around some ambiguous and meaningless term?
It used to be that the so called “Computer Scientists” would be naming these things, but now it seems that its just another marketing department and lots of susceptible developers buy into that.
It used to be that the so called “Computer Scientists” would be naming these things, but now it seems that its just another marketing department and lots of susceptible developers buy into that.
cloud vs. serverless:
You can install postgres in a AWS EC2, it's in the "cloud" but you still have to do all the sysadmin work yourself.
Or you can use a "serverless" postgres and let the provider do the sysadmin work for you. I guess you could call it "postgres as a service".
You can install postgres in a AWS EC2, it's in the "cloud" but you still have to do all the sysadmin work yourself.
Or you can use a "serverless" postgres and let the provider do the sysadmin work for you. I guess you could call it "postgres as a service".
How is that server “less”? Just because you didnt install it using apt-get? Its still a server. It still uses a bare metal machine running a VM in some datacenter that is accessible remotely.
I was just commenting about the difference between "cloud" and "serverless", because you said "Why not call it cloud?".
I prefer "as a service" or "managed" instead of "serverless". Not a big fan of the term for the reasons you mentioned.
I prefer "as a service" or "managed" instead of "serverless". Not a big fan of the term for the reasons you mentioned.
Yes i also prefer that. Thanks for clarifying.
I really don't get the semantic arguments against serverless. The name perfectly describes what it is: an abstraction where the developer doesn't have to worry about a server. It's really that simple.
If you have another model that you think is better, why don't you come up with a name for it, instead of trying to co-op a perfectly cromulent term that is already in wide usage?
If you have another model that you think is better, why don't you come up with a name for it, instead of trying to co-op a perfectly cromulent term that is already in wide usage?
> The name perfectly describes what it is: an abstraction where the developer doesn't have to worry about a server.
There is a difference between an abstraction that allows the user to ignore X, and the actual absence of X. Modern car engines, for example, are reliable enough that most drivers don't have to worry about them. But it's still a mistake to call a car with a reliable engine "engine-less".
There is a difference between an abstraction that allows the user to ignore X, and the actual absence of X. Modern car engines, for example, are reliable enough that most drivers don't have to worry about them. But it's still a mistake to call a car with a reliable engine "engine-less".
Since everything is a car analogy...
A driverless vehicle doesn't require me to add a driver to reach a destination. A serverless solution doesn't require me to add a server to achieve the goal. Something is still driving the car, something is still serving the data. But it's out of my hands.
A driverless vehicle doesn't require me to add a driver to reach a destination. A serverless solution doesn't require me to add a server to achieve the goal. Something is still driving the car, something is still serving the data. But it's out of my hands.
In the meantime i am learning my 12 year old one how to install a debian server. Install postgresql and some scripting languages. Then we proceed to make a simple website with a simple backend.
There is so much more joy into learning stuff from this level.
"I am teaching" :)
that sounds wonderful. my best childhood memories are learning physics from my bad (more than in school), and I'm a physicist now
that sounds wonderful. my best childhood memories are learning physics from my bad (more than in school), and I'm a physicist now
[deleted]
If I'd tried to start my kids on how to install software on an operating system, and how to write bash and SQL, they would have lost interest instantaneously.
I found the gateway drug was a robot that could do simple things, then modifying the code to make it do different things.
I found the gateway drug was a robot that could do simple things, then modifying the code to make it do different things.
Your kid is way too advanced! I am sticking with Code.org
The Grasshopper App is another good one
Is this the one Google shut down a couple months ago? =-\
https://chromeunboxed.com/google-shutting-down-grasshopper-c...
https://chromeunboxed.com/google-shutting-down-grasshopper-c...
dammit...
This is the way. Too many engineers are disconnected from the metal.
I wouldn't be against taking the next step to understanding and using Docker, then docker-compose for such a thing. One can get a lot of use out of a system this way.
You could branch out in a lot of directions from here. Compiling from source is another option, or messing around with config files. Depends on where you want to go in the education.
Docker is still helpful even when you want to compile for source. Something that's simple with containers but maddening on bare metal is build or runtime configs where different versions of packed/libraries are required. A container lets you have a super customized build environment for a single application that can spit out a binary that'll run on bare metal but might otherwise pollute the machine's build config.
Some languages make building harder than others but containers can obviate a lot of that difficulty even if the runtime target is bare metal.
Some languages make building harder than others but containers can obviate a lot of that difficulty even if the runtime target is bare metal.
There are simpler (maybe not easier) solutions for that.
If it's not easier what's the point? I could set up a chroot and do a bunch of scripting and debugging to isolate build environments or just write a dozen line Dockerfile. My time is valuable so the Dockerfile is effective and incredibly easy.
This repurposing of "edge" to mean "browser" continues to confuse me.
>This repurposing of "edge" to mean "browser" continues to confuse me.
I did Ctrl+F search for "edge" in this thread's article and all 23 instances of it seems to be talking about computing on an edge node such as a CDN. Example sentence: "Edge-Ready Drivers -- Regarding supporting connections from the edge, [...] Things have been changing fast. PlanetScale announced its “Fetch API-compatible” database driver a few months ago, making it fully useable from Vercel Edge Runtime and Cloudflare Workers."
Can you point to where you think he used "edge" to be synonymous with Chrome/Firefox?
I did Ctrl+F search for "edge" in this thread's article and all 23 instances of it seems to be talking about computing on an edge node such as a CDN. Example sentence: "Edge-Ready Drivers -- Regarding supporting connections from the edge, [...] Things have been changing fast. PlanetScale announced its “Fetch API-compatible” database driver a few months ago, making it fully useable from Vercel Edge Runtime and Cloudflare Workers."
Can you point to where you think he used "edge" to be synonymous with Chrome/Firefox?
[deleted]
It’s funny as servers locally or regionally, co-located close to users, was this stupid legacy thing a couple of years ago.
I remember being at a conference and everyone being amazed that Chick-Fil-A dared the impossible - putting K8S clusters at each store to run operations. Lol.
This business always makes me laugh.
I remember being at a conference and everyone being amazed that Chick-Fil-A dared the impossible - putting K8S clusters at each store to run operations. Lol.
This business always makes me laugh.
I kind of hate how this article did not once clearly explain what it meant by the nebulous term 'edge'.
I’m fairness his browser could be called edge too
Yea same. I was confused when the article said "edge environments can't connect to a database via TCP".
Yeah, “edge environment” threw me.
[deleted]
You could cache computed data closer to the user (on the edge) to avoid the longer round trip to your host, but putting your Node backed closer to the user just makes the trip from backend to the DB longer? Is the latency from edge to DB really that much better? Maybe what you're optimizing for is something like serving cached data behind auth which does require some business logic (hence the caching of part of the DB at the edge as well)?
Seems cool but back to the article which claims that it changes modern web development. Modern web development sounds for the most part the same. Maybe the article can be called "How Modern SQL Databases Are Enabling Distributed Web Development"?