Hacker News Reader

Comment by Strom | Hacker News Reader

> do you have compute, do you have load balancing, do you have rbac, do you have DB? do you have storage?

Yes, they have all of those things. They have a pretty decent webpage that goes into more detail. https://www.cloudflare.com/

View on HN

They have workers which are serverless which only work for a specific kind of application, how do I connect that app to a database? what do I do to get metrics / logs out of it, monitoring / alerts? as I said they have nothing even close to what cloud providers have.

That doesn’t answer the question at all? Cloudflare workers are just a glorified rule engine running on the nearest cache server, I still fail to see how a rule engine is supposed to be disrupting anything more than a static or a very simple web app.

No, it's not. It allows you to run arbitrary code. It's not a rule engine.

So what? Whats the perceived benefit? How many apps can you run on a key value store? All use cases I came across are just glorified rule engines. If you say you can connect it to a DB, and your DB is still hosted on cloud somewhere else, what benefit does it provide in terms of speed?

Durable Objects[0] let you store data on the edge and provide a lot more than a key/value store. This is a primitive you could build arbitrary databases on top of.

The edge chat demo[1] is a working, scalable real-time chat service hosted entirely on the edge using Workers + Durable Objects, even featuring per-user cross-room rate limiting. As written, it can support millions of chat rooms and users, and it's about 500 lines of code.[2]

The benefit here is that it's much easier to build scalable distributed systems on Workers and Durable Objects than on other platforms. The fact that they run on the edge as close to end users as possible is just a bonus.

[0] https://blog.cloudflare.com/introducing-workers-durable-obje...

[1] https://edge-chat-demo.cloudflareworkers.com/

[2] https://github.com/cloudflare/workers-chat-demo/blob/master/...

(Disclosure: I'm the tech lead for Cloudflare Workers.)

Glad to hear from you, Not to simplify it too much but, So instead of user <-> server <-> user2 Its user <-> cache 1 <-> cache2 <-> user2 Instead of one layer, we now add two/multiple layers and with eventual consistency. I understand this is how distributed systems are supposed to work. But, I wonder why should anyone build a Database on top of a propriety storage engine. Until there is much more it can do, its mostly a key value store. I don’t mean to say cloud workers are useless, but they have a niche, its not something that would disrupt how apps are built at-least in the state it is. Also on a side note LoC mean nothing, it may be a good MVP metric. You could implement twitter MVP in 1000 LoC, but there is lot running behind the scenes. There are edge cases.

The chat demo I mentioned is strongly consistent and does not use cache at all.

Either im missing something here or something doesn’t make sense. How can something be a distributed system but be a strongly consistent system? Unless may be they lock all the instances of that object, in that case there is a performance penalty. But reading into the docs, They say that all clients subscribe to an object which is globally unique, and has only one instance. And cloudflare migrates it between regions intelligently. If thats the case, lets say there is User A (in US) and User B(in UK). Where is that globally unique object instance (chat) stored. It cant be edge here nor distributed, if its a single instance. If its distributed then there is no strong consistency, unless locks(there is a penalty to it)along with latency to sync data.

Each individual chat room is backed by a Durable Object, which is located in one location at a time, and strongly consistent. If the users of the chat room are all in one region, the chat room object can be expected to be located there. If users of a particular room are distributed around the world, Cloudflare will have to do its best to choose a location for the object "somewhere in the middle" -- but that's still better than just putting everything in us-east-1 or whatever.

So instead of me choosing how and where data is stored cloudflare decides whats best, cool. But its not edge anymore. Instead of may be, cloud flare may choose to store either EU or US because it can’t store in the Atlantic for now. So its no better that us-east-1 or eu-west-2. Its not like Cloudlare can transmit data faster than GCP or AWS. It all turns down to If you need edge and distributed you get it, but its eventually consistent, which is cloudflare KV. If you need strong consistency, you don’t have edge and is not distributed, which is durable objects. The general push here seems to imply, its distributed, edge and also strongly consistent which is wrong. Also worth saying that durable objects doesn’t implement any rdbms/nosql db but rather expects us to build a db on top of it. I don’t know how if its better to maintain an inhouse DB monster and outsource server configuration or maintain a server config but have a good DB. If you are using a hosted Postgres/mongo DB, at best you moved your server near to the user but DB is still far away, which would not improve a thing. Workers are a good fit for stateless or async apps, tho.

You started out saying you can't build complicated applications entirely on Workers. That's the point I was debating. It sounds like you're now saying that, yes, it is possible to build complex apps but they don't really count as "edge" in your mind.

That's fine, "edge" isn't the point. The point is that we make it really easy to deploy an app globally. No need to think about multi-homing, no need to maintain multiple "regions", there's just one global network and the code runs everywhere.

On the database point, to be clear, we're not expecting everyone to build their own database. We're saying that many applications don't actually need a monolithic globe-spanning database and may find that durable objects are a good fit as-is. For apps that do need a globe-spanning database, the expectation is that one or more of those will be built on top of Durable Objects in due time, and can then be reused by many apps. This is an ongoing process, we're certainly a long way from done.

There’s a reason why people chose RDBMS or NoSqL DBs right? At the end of the day durable object is a simple kv which is the api it provides right? How to build complex apps, without Indexes, or any other basic features existing DBs provide. Not every company can afford to build a new DB from basics, and you don’t expect to which is good. I agree workers shine for MVPs or even stateless functions. Or something with simple state. But once you start needing some basic features, we have to end up implementing complex loops/map-reduce to search, sort etc. Which is literally more code and maintenance. The benefit provided with server-less is quickly overcast by dev cost. Thats why I said at its current state Workers have a niche. And coming to edge I made a point to dig deep is because, Durable objects are not edge but global. Thats a huge difference. When the clients are far enough. Proponents of this feature here seem to imply they’re edge, distributed and strongly consistent, which is not exactly correct.

Reply on news.ycombinator.com