Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Design factors for decentralised edge applications

Design factors for decentralised edge applications

Fd1af6cc88403788ae1e5710871bbf62?s=128

Andrew Betts

October 09, 2020
Tweet

Transcript

  1. 1

  2. 2 Design factors for decentralised edge applications What does the

    new Edge app look like? Andrew Betts
  3. 3

  4. 4 Traditional stack Hardware Operating System Server process Code Server

    process Code
  5. 5 Traditional stack + virtualisation Hardware Host OS Server process

    Code Hypervisor / container engine Guest OS Server process Code Guest OS
  6. 6 Moving to IAAS Hardware Host OS Server process Code

    Hypervisor / container engine Guest OS Server process Code Guest OS Cloud platform Infrastructure as a service
  7. 7 Moving to PAAS Hardware Host OS Server process Code

    Hypervisor / container engine Guest OS Server process Code Guest OS Cloud platform Platform as a service
  8. 8

  9. 9 12 factors Adam Wiggins' twelve principles of application design

    1. One codebase 2. Explicit dependencies 3. Store config in the environment 4. Other services as attached resources 5. Separate build and run stages 6. Stateless processes 7. Export services via port binding 8. Run processes concurrently 9. Allow for disposability 10. Maintain dev/prod parity 11. Treat logs as event streams 12. Run admin tasks as one-off processes
  10. 10 12 factors Adam Wiggins' twelve principles of application design

    1. One codebase 2. Explicit dependencies 3. Store config in the environment 4. Other services as attached resources 5. Separate build and run stages 6. Stateless processes 7. Export services via port binding 8. Run processes concurrently 9. Allow for disposability 10. Maintain dev/prod parity 11. Treat logs as event streams 12. Run admin tasks as one-off processes
  11. 11

  12. 12 Moving to PAAS Hardware Host OS Server process Code

    Hypervisor / container engine Guest OS Server process Code Guest OS Cloud platform Platform as a service
  13. 13 Moving to serverless / FAAS Hardware Host OS Server

    process Code Hypervisor / container engine Guest OS Server process Code Guest OS Cloud platform Functions as a service
  14. 14 Constraints of serverless / FAAS • Restricted memory per-invocation

    • Restricted CPU per-invocation • Restricted runtime per-invocation • No shared state between invocations • (Often) no access to filesystem
  15. 15 Benefits of serverless / FAAS • No idling costs

    • Looser coupling between components • Just code to manage • Easier to iterate
  16. 16

  17. 17 You have to manage all of this

  18. 18 Hardware Host OS Server process Code Hypervisor / container

    engine Guest OS Server process Code Guest OS
  19. 19 Hardware Host OS Server process Code Hypervisor / container

    engine Guest OS Server process Code Guest OS Cloud platform
  20. 20 Server process Code Guest OS Cloud platform

  21. 21 Server process Code Guest OS Cloud platform Server process

    Code Guest OS Edge platform Server process Code Guest OS 5G platform Server process Code Guest OS Browser (JS, Service Worker, WebAssembly)
  22. 22 Server process Code Guest OS Cloud platform Server process

    Code Guest OS Edge platform Server process Code Guest OS 5G platform Server process Code Guest OS Browser (JS, Service Worker, WebAssembly) Core Edge ISP User 1 instance 100s of instances 10,000s of instances Millions of instances 500ms away 20ms away 3ms away Local
  23. 23

  24. 24 Code Lightweight process Lightweight memory Small source code Input

    From client Conclusion: This should be a client-side process. Markdown example properties Where should this code be run? Output To client
  25. 25 CMS template rendering How about this? Conclusion: This should

    be an edge process. Code Lightweight process Lightweight memory Large source code Shared local state Input From client Output To client CMS Dependency API call to CMS
  26. 26 Use cases for compute at the edge It's easy

    to move existing bits of our applications to edge platforms • Personalisation, localisation, authentication, authorisation – Personalised app shell – Template rendering • Beacon termination – RUM? Analytics? IoT telemetry? • Facades – Transforms & migrations – API gateways • Event-driven cache invalidation
  27. 27

  28. 28 Accept writes at the edge Figure it out later.

    Code at the edge Accepts the write and persists to a local state representation. Input From client Output To client Edge platform reconciles asynchronously with datastores in other locations. Datastore Datastore Datastore Datastore Datastore More on state at the edge Go read my colleague and mega-brain Peter Bourgon on how we are building this at Fastly: fastly.com/blog/state-at-the-edge
  29. 29 Accept writes at the edge Data collection edition Code

    at the edge Accepts the write and persists to a local state representation. Input From client Output To client Collect data in multiple instances within core infrastructure and cross check. Aggregator Aggregator
  30. 30 Let's manage everything ourselves! In one place! The world

    is big, maybe we should cache stuff in replicas at the edge! By embracing serverless, we can do actual processing at the edge! Maybe we can do everything at the edge!
  31. 31 16:00 UTC NYC is primary 05:00 UTC Tokyo is

    primary
  32. 32 Same regulatory environment Divergent regulatory environments

  33. 33 LHR Count: 5 A global rate limiter? CDG Count:

    2 Requests 1-5 spread across 2 POPs do not trigger any thresholds and are counted locally CHI Count: 0 TYO Count: 0 The 4th request to arrive at LHR triggers this edge location to claim global control of counting for this IP Subsequent requests to any POP within the time window will forward the request to the counting location for this IP. ➊ ➋ ➌ If you need blocks to apply globally at the same moment
  34. 34 Chat relay End user submits a message with a

    destination user identified. Edge platform resolves the location of the destination user and forwards the request. Message streamed to the recipient ➊ ➋ ➌ Multiple users connected to different edge locations
  35. 35 12 factors Adam Wiggins' twelve principles of application design

    1. One codebase 2. Explicit dependencies 3. Store config in the environment 4. Other services as attached resources 5. Separate build and run stages 6. Stateless processes 7. Export services via port binding 8. Run processes concurrently 9. Allow for disposability 10. Maintain dev/prod parity 11. Treat logs as event streams 12. Run admin tasks as one-off processes
  36. 36 Edge app design factors Inherited from Heroku's 12 factors

    1. Stateless processes 2. Run processes concurrently 3. Allow for disposability 4. Other services as attached resources 5. Separate build and run stages
  37. 37 Edge app design factors Remote state An edge application

    assumes that persistent state is controlled remotely, but cached locally. It updates local representations of remote state, and makes use of mechanisms in the platform that reconcile updates to that state asynchronously.
  38. 38 Edge app design factors No single view An edge

    application does not need to have a complete and up to date understanding of the world, in order to operate correctly.
  39. 39 Edge app design factors The complete list 1. Stateless

    processes 2. Run processes concurrently 3. Allow for disposability 4. Other services as attached resources 5. Separate build and run stages 6. Remote state 7. No single view
  40. 40 Thank you! Andrew Betts Twitter: @triblondon abetts@fastly.com View these

    slides at: fastly.us/design-factors