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

Design factors for decentralised edge applications

Design factors for decentralised edge applications

Andrew Betts

October 09, 2020
Tweet

More Decks by Andrew Betts

Other Decks in Programming

Transcript

  1. 1

    View Slide

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

    View Slide

  3. 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. 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. 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. 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. 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. 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
    [email protected]
    View these slides at:
    fastly.us/design-factors

    View Slide