There are a lot of benefits to keeping an entire instance of a service in one DC. BW is plentiful, latency is low, and a whole host of tools are at your disposal. Of course, there are downsides too, mainly latency to users and sensitivity to DC outages.
On the other hand, running things at the edge basically has the opposite tradeoffs. Good latency to users and tolerance to DC outages, but hard to rely on everything "behind" the service to be running in the same cluster. And fewer tools support this deployment environment.
For their past compute/storage offerings, Cloudflare seemed to be pursuing the latter while trying to minimize the downsides. I think this is a good strategy since it offers value without directly competing with the major clouds.
But this seems to combine the downsides of both approaches (localize to a DC and run on the edge) while offering none of the advantages. It seems better (in this case) to use the edge as a proxy and just run the code in the DC.
I'm curious, what's the intent here? To transition people from AWS Lambda to CF Workers?
The data center model relies on a glob of services that you manage yourself, and manage infrastructure & networking for. That's how a lot of the early AWS services were built. AWS still offers that paradigm, especially for bigger enterprises that want or need that level of control.
But Cloudflare fast-forwards all that by a few generations, which makes their edge computing MUCH easier, faster, and cheaper to use than Lambda or similar services. Instead of worrying about specific data centers, interconnect, firewalls, bandwidth, etc., on Cloudflare the topology is mostly invisible (unless you have to deal with the Chinese Firewall). You just upload your stateless Javascript code into a worker, and it gets replicated everywhere nearly instantly. Replication and caching are handled invisibly by Cloudflare and you never really have to think about it. If you need state or durable storage, their edge storage products (Workers KV, Durable Objects) function similarly... a few lines of code and you've got a globally scaled auto-replicating data store that you never have to manage the infrastructure for.
The benefit is that it's way easier than having to manage network infrastructure, and Cloudflare's offering is far superior to anything a small business could easily set up or maintain on their own. If you're a huge enterprise, maybe there's more concern about how much control you have over the topology, caching details, etc.
But for simpler websites and apps, the Cloudflare stack is tremendously easier to work with than anything AWS offers, waaaaaaay faster (especially for cold starts), and usually much cheaper.
Workers isn't a 1:1 replacement for Lambda, but it's probably the better choice for simpler functions.
As for this database connector, it goes against their edge-native offerings, but it's probably just there as a compatibility layer for people who aren't able to rearchitect their whole stack yet. Like their other CDN products, this lets you connect legacy stacks (single host or single data center) to a global CDN with little work.
you're right that the ideal application would run fully on the edge (which is why we try to offer things like KV, Durable Objects, and more options in the future for you to have your data where your logic is running).
however — moving your data to the edge is unlikely to happen overnight. and it's going to take us a bit to offer you all the data options for all the different use cases that you need (after all, there are many types of databases for a reason), so this gives users greater optionality. secondly, if your data is already somewhere but you want to build new features on top of it, now you can. (say, i already have a database with all my apartment listings in it, but i want to add a new feature where i let my users add photos of the apts). i can now build that feature in workers, without having to undergo an otherwise massive migration.
one last thing, this is just the beginning of what even database connectors mean. in the future, we can cache data, and actually improve performance and reliability even if the dc is far (as you said, make it easier to have best of both worlds).
My reasoning is that all their offerings are geared toward the edge, and while it's nice to support relational databases as they currently are, it seems to counter why you'd build on Cloudflare's edge to begin with.
This seems more to be suggesting that I should not pursue an edge-based architecture and stick with containers instead.
If I'm going to be using workers, I'm already giving up a ton of capabilities possible on a native OS. In return, I'd hope for something wild, like a fire and forget global relational database.
If my original ask was too tall an order, I think a global GraphQL service would fit nicer with their current stack and offer most of the same benefits as direct database access (i.e. schema as a service accessed over http).
If they are going to push edge computing, they need to have a first-party answer to the major application needs. Having a third-party ecosystem of offerings is extremely welcome, but I don't think Cloudflare should be banking on these. They need to develop an in-house solution - why should I be confident that edge solutions are better when they cannot offer me a competitive storage solution?
Durable Objects is awesome, but it's complementary. They need to offer a datastore.
In this case you may as well run an HTTP server next to your database and incur the high http request latency once, and have < 1ms latency for each of the 10 queries.
Is this correct?
You can get similar caching by making a bunch of distributed read-only database shards and/or caching your HTTP proxy output, but in this case Cloudflare manages all that for you. You do have to set up a tunnel and apparently some sort of daemon, though, so I guess you're just running Cloudflare's proxy to their edge.
It's not as clean as an edge-native key-value store (like their Durable Objects or Workers KV), but if your existing code requires a relational DB at scale, this might be one way to tackle it rather than dealing with DB sharding and clustering yourself -- which can get real ugly, real fast.
