Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ExEC: Elastic Extensible Edge Cloud

45 views

Published on

ExEC: Elastic Extensible Edge Cloud presented at 2nd ACM Workshop on Edge Systems, Analytics and Networking (EdgeSys) 2019 co-located with EUROSYS 2019 in Dresden, Germany.

Slides owned and prepared by Aleksandr Zavodovski

Published in: Science
  • Be the first to comment

  • Be the first to like this

ExEC: Elastic Extensible Edge Cloud

  1. 1. ExEC: Elastic Extensible Edge Cloud A. Zavodovski, N. Mohan, S. Bayhan, W. Wong and J. Kangasharju
  2. 2. Motivation: Edge Computing 2 Latency-critical services are predeployed to edge facilities How to discover local edge servers? Are there any? Using app without edge is slow, users are not quite content
  3. 3. NO! 3 CDN for Edge Services? Something like the Internet! Open Standards
  4. 4. Motivation • Growing demand for edge computing, making edge pervasive • Applications should unfold towards the edge autonomously • Autonomous adaptation to the changing environment • Towards common standards of self-organized service provisioning on global scale • Not only about the edge! 4
  5. 5. ExEC: Elastic Extensible Edge Cloud 5
  6. 6. Independent Edge Providers (IEPs) • Facility where the orchestrator can deploy an edge service • Can be: • Facility operated by a cloud provider (e.g., Cloudfront, Azure Stack) • Telco edge server (MEC) • Crowdsourced: iExec, Golem, etc.? • Runs container yard application • Built on top of e.g., Kubernetes, Mesos or Docker Swarm • Orchestrator negotiates with the yard on deployment timeslot, hardware resources, price, etc. • Contractual agreements and transactions • Smart contracts are possible option 6 Anyone can establish an IEP
  7. 7. ExEC System Building Blocks 7 • Discovery • IEPs on the path • Contractual agreement • Smart contracts (Ethereum, EOS, etc) • Virtualization • Containerization standardized: https://www.opencontainers.org/ • Unikernels are also an option • Trusted Execution Environments • Supported by Intel, AMD, ARM • Particularly when data is sensitive
  8. 8. Operation of ExEC • Initially, edge service is in the cloud • One or multiple deployments 8
  9. 9. Operation of ExEC • Initially, edge service is in the cloud • One or multiple deployments • Orchestrator monitors incoming flows • Where requests are coming from? 9
  10. 10. Operation of ExEC • Initially, edge service is in the cloud • One or multiple deployments • Orchestrator monitors incoming flows • Where requests are coming from? • Orchestrator discovers deployment locations • In the domain of end-users or on a path to it 10
  11. 11. Operation of ExEC • Initially, edge service is in the cloud • One or multiple deployments • Orchestrator monitors incoming flows • Where requests are coming from? • Orchestrator discovers deployment locations • In the domain of end-users or on a path to it • Edge service is onloaded to IEP 11
  12. 12. The Operation of ExEC • Initially, edge service is in the cloud • One or multiple deployments • Orchestrator monitors incoming flows • Where requests are coming from? • Orchestrator discovers deployment locations • In the domain of end-users or on a path to it • Edge service is onloaded to IEP • Users are redirected to edge 12
  13. 13. Unfolding of ExEC Application 13 Tokyo Orchestrator
  14. 14. Unfolding of ExEC Application 14 Tokyo Wellington LisbonNew York Orchestrator
  15. 15. ExEC: Elastic Extensible Edge Cloud 15
  16. 16. Discovery of IEPs • Assumption: IEPs add edge SRV records to authoritative DNS servers of their domains 16
  17. 17. Discovery of IEPs • Assumption: IEPs add edge SRV records to authoritative DNS servers of their domains • Perform tomography • Traceroute to end-users 17
  18. 18. Discovery of IEPs • Assumption: IEPs add edge SRV records to authoritative DNS servers of their domains • Perform tomography • Traceroute to end-users • Identify on-path domains 18
  19. 19. Discovery of IEPs • Assumption: IEPs add edge SRV records to authoritative DNS servers of their domains • Perform tomography • Traceroute to end-users • Identify on-path domains • Perform SRV query 19
  20. 20. ExEC: Elastic Extensible Edge Cloud 20
  21. 21. Contractual Agreement • Orchestrator must compensate IEPs for running services • Smart contracts are interesting option • No formalities are required to obtain an address on a public distributed ledger • Escrow capability is important • There is a danger that (crowdsourced) IEP will not deliver its service as promised • Orchestrator’s payment is transferred to IEP only if service delivered appropriately • How to resolve conflicts? • Is reputation system the best (and only) option? 21
  22. 22. Contractual Agreement • Ethereum has been the leading platform so far • Problems • High energy consumption (proof-of-work), low performance, high costs • Security: notorious The DAO hack • Second generation of platforms • EOS, Stellar, Cardano, etc • Use delegated proof-of-stake, green and fast • Some charge zero fee • SLA must be defined • The Ricardian contract to help? 22
  23. 23. Eval setup • Amazon US East 23
  24. 24. Service Placement: Betweenness Centrality 24
  25. 25. Service Placement: Betweenness Centrality 25
  26. 26. Handling Clients • Existing clients are redirected to the new deployments of service HTTP • What about new clients? • Naïve approach: orchestrator redirects them to the closest instance • Mimicking CDN usage of DNS • Using DNS of the cloud if possible (Amazon Route 53, Azure DNS) • Anycast (IPv6) for some scenarios 26
  27. 27. Open Questions • What kind of strategy orchestrator needs? • Would proactive deployment be beneficial? • How new clients will discover the closest service instance? • How the competition between multiple ExEC applications will affect the market? (IEP has limited resources) • Will smart contracts redeem their promise? 27
  28. 28. Why ExEC? • Discovery!! • IEPs to tackle growing demand for edge computing • Less cloud monopoly • Open infrastructure standards to enable ad hoc deployment of services on global scale • Reducing administrative overhead: application unfolds towards the edge autonomously 28
  29. 29. Anyone should be able to become an edge provider and be discovered 29 Anyone today can establish own AS and connect it to the Internet
  30. 30. Thank you! aleksandr.zavodovski@helsinki.fi
  31. 31. Takeaways • IEPs to tackle growing demand for edge computing • Less cloud monopoly • Open infrastructure standards to enable ad hoc deployment of services on global scale • Reducing administrative overhead: application unfolds towards the edge autonomously 31

×