Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Uber-like CDN

medium.com

Post reply on HN
Print view View original

31–40 of 86 posts

Re: An Uber-like CDN

#31

Post by focusedone »

mranton wrote: post #10
focusedone wrote: post #3

Ignorant question - How well does this scale? Are peers all necessarily running in major cloud environments? Do you imagine seeing peers in the form of smaller players with beefy home setups?

>How well does this scale? Are peers all necessarily running in major cloud environments? The network scales very well. The network is divided into multiple GeoZones. We can add remove these zones easily. GeoZones are not connected to each other, so there is no single point of failure. Actually the major cloud envs are the most expensive possible variants for Peers. Bare metal servers are much cheaper in our case. >D…

So a small, regional ISP with a bunch of unused outbound bandwidth and spare rack space could be a good peer in this scheme, right?

Re: An Uber-like CDN

#32

Post by mranton »

todd3834 wrote: post #23

How does this compare to IPFS? I was playing around with IPFS and it seems like a lower risk higher node version of this. Performance wasn’t half bad either. I guess it depends on which node you end up downloading from and whether there was a nearby cache hit. P

IPFS is very slow. It's like a cold storage. Not good for web-cache at all. Though Cloudlare provides gateways for IPFS, and again, we have a CDN layer here. It would be nice to see IPFS performance numbers to compare.

Re: An Uber-like CDN

#33

Post by thayne »

amalcon wrote: post #4

Something doesn't add up here. They're actively telling third parties to lease cloud servers with large amounts of free bandwidth, and allocate them to this purpose. I see four possibilities: - They are paying the third party less than what it costs to rent the server, in which case the third party is losing money and shouldn't be doing this. - They are paying the third party at least what it costs to rent the server…

For the first bullet point, it could be worth it for the third party if they are using the server for something else, but have surplus resources that could be used for this CDN. And they might be paying higher rates initially to get enough peers to make the CDN worth using.

Re: An Uber-like CDN

#34

Post by mranton »

focusedone wrote: post #31
mranton wrote: post #10

Earlier quoted context omitted.

>How well does this scale? Are peers all necessarily running in major cloud environments? The network scales very well. The network is divided into multiple GeoZones. We can add remove these zones easily. GeoZones are not connected to each other, so there is no single point of failure. Actually the major cloud envs are the most expensive possible variants for Peers. Bare metal servers are much cheaper in our case. >D…

So a small, regional ISP with a bunch of unused outbound bandwidth and spare rack space could be a good peer in this scheme, right?

correct

Re: An Uber-like CDN

#35

Post by paxys »

jsnell wrote: post #7

There's a bunch of really obvious objections to this idea around performance, privacy, economics, UX, and reliability. Impressively, the post did not manage to address any of them up front. 1. Performance. In terms of latency, this is adding an extra round-trip to each page request (to get the metadata). It's also likely going to load different resources from different servers (hostname, IP) preventing connection reu…

1 is something every CDN in the world already deals with. The metadata system ultimately needs to be its own little CDN, and can achieve the same level of performance (e.g. by deploying at the edge) just without the bandwidth costs.

2 is definitely an issue.

3 is a maybe. There's definitely a model where people with access to cheap servers and bandwidth can get on board and not have to worry about the application-level details, finding customers, billing etc.

4 isn't an issue as long as you are selling the CDN specifically for website assets that don't need to have pretty URLs.

Re: An Uber-like CDN

#38

Post by uncertainrhymes »

mranton wrote: post #27
uncertainrhymes wrote: post #13

There are several red flags here, not the least of which is that a CDN isn't just about bandwidth, it is about disk . If a cache node doesn't have the object, it has to go to origin to get it. That has a cost at origin, which most CDN customers want to minimize. Cache management (eviction, invalidation, etc) is done where? By the look of that diagram, you are actually doubling your origin traffic just to push to the…

>a CDN isn't just about bandwidth, it is about _disk_ The disk performance - is the weakest part of the Peer. It is a part you can't guarantee any QoS on a cheap server. The idea is to keep popular cache on Peers in memory. Everything else we will host from a limited number of regular servers (belong to Farba), with high-performance disk subsystem. >Cache management (eviction, invalidation, etc) is done where? yes. Y…

Your example servers have 16-32 GB of memory, which is basically nothing. If you ever ramp to real world traffic the peer will be constantly evicting objects (if you use a normal LRU). Even if you backstop that with a mid-tier belonging to Farba to protect the origin, what kind of cache hit rate are you expecting at the peer?

Re: An Uber-like CDN

#39

Post by jedberg »

paxys wrote: post #35
jsnell wrote: post #7

There's a bunch of really obvious objections to this idea around performance, privacy, economics, UX, and reliability. Impressively, the post did not manage to address any of them up front. 1. Performance. In terms of latency, this is adding an extra round-trip to each page request (to get the metadata). It's also likely going to load different resources from different servers (hostname, IP) preventing connection reu…

1 is something every CDN in the world already deals with. The metadata system ultimately needs to be its own little CDN, and can achieve the same level of performance (e.g. by deploying at the edge) just without the bandwidth costs. 2 is definitely an issue. 3 is a maybe . There's definitely a model where people with access to cheap servers and bandwidth can get on board and not have to worry about the application-le…

> 1 is something every CDN in the world already deals with.

Not exactly. For a normal CDN, your webpage HTML directs the client directly to the CDN server, which in theory already has the object. Only if it doesn't have the object does it need to go get it, but there isn't an extra lookup. The CDN does it's direction magic via DNS or IP routing, not with double lookups.

Post reply on HN