Design factors for decentralised edge applications

by Andrew Betts

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

9 12 factors Adam Wiggins' twelve principles of application design 1. One codebase 2. Explicit dependencies 3. Store conﬁg 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-oﬀ processes

Slide 10

Slide 10 text

10 12 factors Adam Wiggins' twelve principles of application design 1. One codebase 2. Explicit dependencies 3. Store conﬁg 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-oﬀ processes

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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 ﬁlesystem

Slide 15

Slide 15 text

15 Beneﬁts of serverless / FAAS • No idling costs • Looser coupling between components • Just code to manage • Easier to iterate

Slide 16

Slide 16 text

Slide 17

Slide 17 text

17 You have to manage all of this

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

20 Server process Code Guest OS Cloud platform

Slide 21

Slide 21 text

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)

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

30 Let's manage everything ourselves! In one place! The world is big, maybe we should cache stuﬀ in replicas at the edge! By embracing serverless, we can do actual processing at the edge! Maybe we can do everything at the edge!

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

32 Same regulatory environment Divergent regulatory environments

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

34 Chat relay End user submits a message with a destination user identiﬁed. 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

Slide 35

Slide 35 text

35 12 factors Adam Wiggins' twelve principles of application design 1. One codebase 2. Explicit dependencies 3. Store conﬁg 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-oﬀ processes

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

40 Thank you! Andrew Betts Twitter: @triblondon [email protected] View these slides at: fastly.us/design-factors