4 ms·

Sure, most apps still follow the client x server architecture. To properly take advantage of edge computing, one needs to rearchitect current applications, and

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.

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.