Design factors for decentralised edge applications

Transcript

1. View Slide

2. 2
   Design factors for decentralised
   edge applications
   What does the new Edge app look like?
   Andrew Betts
   

   View Slide

3. View Slide

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

   View Slide

5. 5
   Traditional stack + virtualisation
   Hardware
   Host OS
   Server process
   Code
   Hypervisor / container engine
   Guest OS
   Server process
   Code
   Guest OS
   

   View Slide

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
   

   View Slide

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
   

   View Slide

8. View Slide

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
   

   View Slide

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
    

    View Slide

11. View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

15. 15
    Benefits of serverless / FAAS
    • No idling costs
    • Looser coupling between components
    • Just code to manage
    • Easier to iterate
    

    View Slide

16. View Slide

17. 17
    You have to
    manage all of this
    

    View Slide

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

    View Slide

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

    View Slide

20. 20
    Server process
    Code
    Guest OS
    Cloud platform
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

23. View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

27. View Slide

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
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

31. 31
    16:00 UTC
    NYC is primary
    05:00 UTC
    Tokyo is primary
    

    View Slide

32. 32
    Same regulatory
    environment
    Divergent regulatory
    environments
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

40. 40
    Thank you! Andrew Betts
    Twitter: @triblondon
    abetts@fastly.com
    View these slides at:
    fastly.us/design-factors
    

    View Slide