3 ms·

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
        > 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. If an application follows a Microservice architecture, then it is possible to containerize it and enable its autonomic management through frameworks like Kubernetes and Docker Swarm, which is one way forward to improve performance efficiency of typical apps. Yes, the problem is where the data resides. Migrate portions of it nearer to clients to the Edge, and clients will have the illusion of lower latency. Maintaining data consistency and coherence are yet problems not properly tackled, but in edge computing it means computations happen in these migrated portions of data, and not "all the way" at the cloud (higher latency) anymore. > They keep compute on-vehicle or on-prem. For data services (not media delivery), latency is: Not always. They will use the Edge mostly for inference and for learning from others (transfer learning), but sometimes also for training and model updates. And in cases like this (known as Mobile Edge Cloud), the ability to obtain granular and immediate control by supporting custom logic at the edge of a network is particularly useful in routing traffic to the microservices that make up a service. I agree, GraphQL helps reducing latency, mostly because the amount of data is now "granular" and it is one way to overcome limitations in 'traditional' apps (e.g. Rest APIs). Coalescing may be useful in some cases, but perhaps not in situations where one needs to maintain 95th/99th percentiles up to certain threshold constraints. Together with Edge (as I guess you mentioned), it is a win-win performance-wise. But then again, maintaining consistency and coherence are yet problems to be tackled. And guess what, applications still need to be updated to use GraphQL and use its features. Just like people will do when developing for the Edge.

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
        > 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. If an application follows a Microservice architecture, then it is possible to containerize it and enable its autonomic management through frameworks like Kubernetes and Docker Swarm, which is one way forward to improve performance efficiency of typical apps. Yes, the problem is where the data resides. Migrate portions of it nearer to clients to the Edge, and clients will have the illusion of lower latency. Maintaining data consistency and coherence are yet problems not properly tackled, but in edge computing it means computations happen in these migrated portions of data, and not "all the way" at the cloud (higher latency) anymore. > They keep compute on-vehicle or on-prem. For data services (not media delivery), latency is: Not always. They will use the Edge mostly for inference and for learning from others (transfer learning), but sometimes also for training and model updates. And in cases like this (known as Mobile Edge Cloud), the ability to obtain granular and immediate control by supporting custom logic at the edge of a network is particularly useful in routing traffic to the microservices that make up a service. I agree, GraphQL helps reducing latency, mostly because the amount of data is now "granular" and it is one way to overcome limitations in 'traditional' apps (e.g. Rest APIs). Coalescing may be useful in some cases, but perhaps not in situations where one needs to maintain 95th/99th percentiles up to certain threshold constraints. Together with Edge (as I guess you mentioned), it is a win-win performance-wise. But then again, maintaining consistency and coherence are yet problems to be tackled. And guess what, applications still need to be updated to use GraphQL and use its features. Just like people will do when developing for the Edge.