4 ms·

I don't think latency is actually the most important feature of edge computing. Sure, it's great that if you use Cloudflare Workers you get very close to end us

I don't think latency is actually the most important feature of edge computing. Sure, it's great that if you use Cloudflare Workers you get very close to end users and have low latency. I think the real advantages will be: 1. Set-it-and-forget-it scalability 2. Compliance with data locality laws #2 is going to be the absolute wave of the future. Not just in Europe, but everywhere. Every country is going to introduce laws that mean their citizens' data needs to stay in region or in country. A widely distributed edge will make that easy to handle because it can be a configuration option.

anonymousDan 6y ago
What exactly do you mean by #1?
- jgrahamc 6y ago
  I mean that the promise of edge computing is that you write some code, deploy it and don't worry about scaling it, regions, availability zones and the like. It's just code that gets run.
  - jeswin 6y ago
    > It's just code that gets run. I agree. But it also means that it's mostly unrelated to the edge, or edge computing; with the same constraints the code can run anywhere. To me the promise of edge is that it could work quite well with decentralized apps (not limited to blockchain-based). The work you guys are doing with IPFS is a great start. Add: When you think about it, most current apps are centralized and it's unsurprising that they can work well with the cloud (AWS/Azure/Google); edge is just mostly CDN for now. Decentralized is when those models become incompatible, and where edge can show strength.
    - zekrioca 6y ago
      CDN is mostly related to "content" (i.e., data) delivery. Edge is more generic, and relates not only to "content", but also to "processing" and "networking" to reduce the response time multiple clients experience. Decentralized apps is not really related, though one can really employ edge datacenters to achieve so..
      - jeswin 6y ago
        The point I'm making is that edge can't do much now in terms of "processing". Most data is centralized and you'll need to hit a centralized system to access it. Facilities needing lower latency are more likely to keep it on-prem. As of now, it's mostly dealing with CDNish workloads. However, that changes with decentralized apps since they place a different set of architectural demands, and don't have centralized datasources. For instance, a search in p2p space might involve connecting to a lot of peers - latency matters. Data (often signed chains) might need to be fetched from dozens of different sources, combined and queried locally - again latency matters. Clusters of people who you talk to are often co-located, edge wins again. Latency doesn't matter when it's a hand countable number of simultaneous queries (as in current apps). We can even work around it with approaches like batching, as with GraphQL.
        zekrioca 6y ago
        Sure, most apps still follow the client x server architecture. To properly take advantage of edge computing, one needs to rearchitect current applications, and microservices is one example of how to do it. The point of edge computing is exactly to incentivize facilities/companies to not keep data on premises, or at least to ship some data (i.e. non sensitive) out of it. It doesn’t scale the way most companies need it to. Latency is key for some important applications like self-driving cars and industrial automation, not really to make some queries in GraphQL..
        jeswin 6y ago
        > ... and microservices is one example of how to do it. The fundamental problem is where the data resides. Microservices are well understood today, but taking them to the edge isn't; there isn't a path to do that for typical apps. So most microservices which are being used at the edge are doing caching/transcoding/resizing etc. > Latency is key for some important applications like self-driving cars and industrial automation They keep compute on-vehicle or on-prem. For data services (not media delivery), latency is: a) either supremely important to be fully local (vehicles, automation) b) or it doesn't matter enough to be on a 3rd party edge network. The diminishing returns in typical apps is what the article is alluding to. > not really to make some queries in GraphQL You're misrepresenting what I said - and it seems deliberate. I mentioned GraphQL as one of the attempts to solve latency issues in typical apps. For example, some apps use graphql/dataloader[1] because it can "coalesce all individual loads which occur within a single frame of execution before calling your batch function with all requested keys. This ensures no additional latency while capturing many related requests into a single batch." So in typical apps, there isn't a big benefit to putting general compute on the edge - because the network calls are chunky and not chatty, and their data is centralized. GraphQL (along with libs/frameworks) being one way to turn chatty into chunky. [1]: https://github.com/graphql/dataloader https://github.com/graphql/dataloader
zekrioca 6y ago
Performance wise putting things (i.e., data, compute power, networking, etc) nearer clients is the only way to somehow 'beat' mother-nature. That's why latency really is the main feature in edge computing. Point (1) is already realized by Cloud computing (or autonomic computing, see [1]). (2) has been more focused nowadays but it has also been a problem in Cloud, but it is not really a "feature" in either settings. [1] http://www.cs.cmu.edu/~15849g/readings/kephart03.pdf http://www.cs.cmu.edu/~15849g/readings/kephart03.pdf (2003)
vp8989 6y ago
For #2, how would you deal with the user moving to a different region?
pradn 6y ago
It looks like the term "edge computing" conflates the location of the services and the method of distributing the services (serverless apps). You could imagine writing servers that then get automatically distributed to the edge as containers or VMs.
908B64B197 6y ago
> #2 is going to be the absolute wave of the future. Not just in Europe, but everywhere. Every country is going to introduce laws that mean their citizens' data needs to stay in region or in country I can't wait for all these special snowflakes laws. And then the whining that locals players are all getting wiped out by foreign competitors that got their start in much larger unified markets where they could benefit from economies of scale.
forgotmypw17 6y ago
I think your #2 is actually #1, although I would phrase it as: #1 ownership and control over access to one's own data (privacy) #2 access to one's own data (accessibility and queryability)
fierro 6y ago
I think this is a bit hand wavey. Being able to run workloads on the edge does not solve the data storage problem.
_kp6z 6y ago
The author also drastically overestimates the capabilities of cloud vendors. CDN and edge have been and will continue to be great business (as you well know) despite pundits predicting their sublimation to cloud subsidiaries for over a decade. For one, capacity planning a public cloud is a lot different and a lot harder than cdn/edge. So the cloud vendor must then act a lot like a cdn/edge, which none have shown any competence in doing. There's a reason Amazon still uses Akamai, Level3, and others for their own Prime Video. CloudFront is a joke in comparison to any prime CDN in terms of network breadth, latency, and overall support from the vendor.
- 64d93b2a81 6y ago
  cloudfront is a joke. It doesn't even encrypt the traffic inside their network.
nsonha 6y ago
Arent both already the case with, say aws lambda?

anonymousDan 6y ago

What exactly do you mean by #1?

jgrahamc 6y ago
I mean that the promise of edge computing is that you write some code, deploy it and don't worry about scaling it, regions, availability zones and the like. It's just code that gets run.
- jeswin 6y ago
  > It's just code that gets run. I agree. But it also means that it's mostly unrelated to the edge, or edge computing; with the same constraints the code can run anywhere. To me the promise of edge is that it could work quite well with decentralized apps (not limited to blockchain-based). The work you guys are doing with IPFS is a great start. Add: When you think about it, most current apps are centralized and it's unsurprising that they can work well with the cloud (AWS/Azure/Google); edge is just mostly CDN for now. Decentralized is when those models become incompatible, and where edge can show strength.
  - zekrioca 6y ago
    CDN is mostly related to "content" (i.e., data) delivery. Edge is more generic, and relates not only to "content", but also to "processing" and "networking" to reduce the response time multiple clients experience. Decentralized apps is not really related, though one can really employ edge datacenters to achieve so..
    - jeswin 6y ago
      The point I'm making is that edge can't do much now in terms of "processing". Most data is centralized and you'll need to hit a centralized system to access it. Facilities needing lower latency are more likely to keep it on-prem. As of now, it's mostly dealing with CDNish workloads. However, that changes with decentralized apps since they place a different set of architectural demands, and don't have centralized datasources. For instance, a search in p2p space might involve connecting to a lot of peers - latency matters. Data (often signed chains) might need to be fetched from dozens of different sources, combined and queried locally - again latency matters. Clusters of people who you talk to are often co-located, edge wins again. Latency doesn't matter when it's a hand countable number of simultaneous queries (as in current apps). We can even work around it with approaches like batching, as with GraphQL.
      - zekrioca 6y ago
        Sure, most apps still follow the client x server architecture. To properly take advantage of edge computing, one needs to rearchitect current applications, and microservices is one example of how to do it. The point of edge computing is exactly to incentivize facilities/companies to not keep data on premises, or at least to ship some data (i.e. non sensitive) out of it. It doesn’t scale the way most companies need it to. Latency is key for some important applications like self-driving cars and industrial automation, not really to make some queries in GraphQL..
        jeswin 6y ago
        > ... and microservices is one example of how to do it. The fundamental problem is where the data resides. Microservices are well understood today, but taking them to the edge isn't; there isn't a path to do that for typical apps. So most microservices which are being used at the edge are doing caching/transcoding/resizing etc. > Latency is key for some important applications like self-driving cars and industrial automation They keep compute on-vehicle or on-prem. For data services (not media delivery), latency is: a) either supremely important to be fully local (vehicles, automation) b) or it doesn't matter enough to be on a 3rd party edge network. The diminishing returns in typical apps is what the article is alluding to. > not really to make some queries in GraphQL You're misrepresenting what I said - and it seems deliberate. I mentioned GraphQL as one of the attempts to solve latency issues in typical apps. For example, some apps use graphql/dataloader[1] because it can "coalesce all individual loads which occur within a single frame of execution before calling your batch function with all requested keys. This ensures no additional latency while capturing many related requests into a single batch." So in typical apps, there isn't a big benefit to putting general compute on the edge - because the network calls are chunky and not chatty, and their data is centralized. GraphQL (along with libs/frameworks) being one way to turn chatty into chunky. [1]: https://github.com/graphql/dataloader https://github.com/graphql/dataloader

zekrioca 6y ago

Performance wise putting things (i.e., data, compute power, networking, etc) nearer clients is the only way to somehow 'beat' mother-nature. That's why latency really is the main feature in edge computing. Point (1) is already realized by Cloud computing (or autonomic computing, see [1]). (2) has been more focused nowadays but it has also been a problem in Cloud, but it is not really a "feature" in either settings. [1] http://www.cs.cmu.edu/~15849g/readings/kephart03.pdf http://www.cs.cmu.edu/~15849g/readings/kephart03.pdf (2003)

vp8989 6y ago

For #2, how would you deal with the user moving to a different region?

pradn 6y ago

It looks like the term "edge computing" conflates the location of the services and the method of distributing the services (serverless apps). You could imagine writing servers that then get automatically distributed to the edge as containers or VMs.

908B64B197 6y ago

> #2 is going to be the absolute wave of the future. Not just in Europe, but everywhere. Every country is going to introduce laws that mean their citizens' data needs to stay in region or in country I can't wait for all these special snowflakes laws. And then the whining that locals players are all getting wiped out by foreign competitors that got their start in much larger unified markets where they could benefit from economies of scale.

forgotmypw17 6y ago

I think your #2 is actually #1, although I would phrase it as: #1 ownership and control over access to one's own data (privacy) #2 access to one's own data (accessibility and queryability)

fierro 6y ago

I think this is a bit hand wavey. Being able to run workloads on the edge does not solve the data storage problem.

_kp6z 6y ago

The author also drastically overestimates the capabilities of cloud vendors. CDN and edge have been and will continue to be great business (as you well know) despite pundits predicting their sublimation to cloud subsidiaries for over a decade. For one, capacity planning a public cloud is a lot different and a lot harder than cdn/edge. So the cloud vendor must then act a lot like a cdn/edge, which none have shown any competence in doing. There's a reason Amazon still uses Akamai, Level3, and others for their own Prime Video. CloudFront is a joke in comparison to any prime CDN in terms of network breadth, latency, and overall support from the vendor.

64d93b2a81 6y ago
cloudfront is a joke. It doesn't even encrypt the traffic inside their network.

nsonha 6y ago

Arent both already the case with, say aws lambda?