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
Locating and isolating a gene, FISH, GISH, Chromosome walking and jumping, te...
ExEC: Elastic Extensible Edge Cloud
1. ExEC: Elastic Extensible Edge
Cloud
A. Zavodovski, N. Mohan, S. Bayhan, W. Wong and J. Kangasharju
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
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
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. 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. Operation of ExEC
• Initially, edge service is in the cloud
• One or multiple deployments
8
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. 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. 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. 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
16. Discovery of IEPs
• Assumption: IEPs add edge SRV
records to authoritative DNS
servers of their domains
16
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. 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. 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
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. 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
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. 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. 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. 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
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
