Earlier quoted context omitted.
Yes. We are exploring adding data storage at the edge. We would love people’s feedback in the product and what features we need to add.
It sounds like you're slowly working towards becoming some sort of insane hosting company
Code Everywhere: Why We Built Cloudflare Workers
11–20 of 28 posts
Re: Code Everywhere: Why We Built Cloudflare Workers
#12Re: Code Everywhere: Why We Built Cloudflare Workers
#13Earlier quoted context omitted.
Yes. We are that big. https://bgp.he.net/report/exchanges#_participants
Who is hurricane electric?
Re: Code Everywhere: Why We Built Cloudflare Workers
#14Trade offs I see
* Cloudflare is probably slightly closer to customers, but cloudfront is still very close
* lambda@edge should be cheaper with amazons scale and ecosystem
* cloudfront itself is very expensive compared to Cloudflare, almost every project can integrate Cloudflare and use this, where small projects don’t really make sense for cloudfront
Re: Code Everywhere: Why We Built Cloudflare Workers
#15This is pretty interesting, especially if one get some kind og local storage where one can cache the data from the users and also keep some extra data one need to handle the requests. One can also imagine some kind of MQ solution that distribute to the edges and then updates the clients (for games and such scenarios)
Yes. We are exploring adding data storage at the edge. We would love people’s feedback in the product and what features we need to add.
Maybe different tariffs based on the percentage of reads that you can serve locally, the average latency or something similar, in order to avoid having to replicate every piece of data to every edge?
Re: Code Everywhere: Why We Built Cloudflare Workers
#16> the most peered network on the planet That's a bold claim. I'd expect Akamai, Google and Amazon to be peered at more locations, maybe even more. Or have they become that big?
Yes. We are that big. https://bgp.he.net/report/exchanges#_participants
Another day another dubious Cloudflare marketing claim.
Participating in the most IXs does not mean you have the most BGP peers. Simply participating in an IX does not mean that every other participating network at that IX automatically agrees to peer with you. Using AMS-IX as an example:
"Every member or customer at AMS-IX is in the position to peer with any or all other connected ISP's although they are not required to"[1]
And this is pretty standard across all IXs.
For instance Facebook might be far down that chart regarding the number of IX fabrics they peer at but if 99% of of the participants at those agree to peer with them there then they are likely "more peered" than you.
Re: Code Everywhere: Why We Built Cloudflare Workers
#17Earlier quoted context omitted.
It sounds like you're slowly working towards becoming some sort of insane hosting company
I don’t see us going into hosting. I do see us doing everything that makes sense when you are a few ms from everyone on the planet.
> We are exploring adding data storage at the edge.
> I don’t see us going into hosting.
You must have your eyes closed then, because that's clearly pushing the camel nose into the Amazon lambda tent.
Re: Code Everywhere: Why We Built Cloudflare Workers
#18Very similar to lambda@edge Trade offs I see * Cloudflare is probably slightly closer to customers, but cloudfront is still very close * lambda@edge should be cheaper with amazons scale and ecosystem * cloudfront itself is very expensive compared to Cloudflare, almost every project can integrate Cloudflare and use this, where small projects don’t really make sense for cloudfront
I suspect price will have more to do with the tech's underlying ability to scale to lots of (separately-sandboxed) customers at lots of edge locations. Our tech is pretty different from Amazon's so it will be interesting to see how that shakes out.
Re: Code Everywhere: Why We Built Cloudflare Workers
#19Re: Code Everywhere: Why We Built Cloudflare Workers
#20As an example, I would assume worker is making requests with the internal view of the site, but can not have an internal view of other sites or security problems would ensue.. So what happens when two of my sites have service workers fetching something from each other on each request?