Services, Architecture and Channels

Transcript

1. 1.

   Andrew Godwin @andrewgodwin

2. 2.

   Andrew Godwin Hi, I'm Django core developer Senior Software Engineer

   at Apparently now does software architecture
3. 3.

   The Monolith

4. 4.

   The Monolith Only one version of any dependency Everything can

   import everything Deployed all at once No separation Side-effects from other code
5. 5.

   None
6. 6.

   Services Code split up by purpose/team Defined cross-boundary API Deployed

   separately Can use different versions of dependencies Isolated from each other
7. 7.

   Why services?

8. 8.

   Easier to manage Smaller, self-contained problems

9. 9.

   Independent Scaling And easier performance analysis

10. 10.

    Faster Individual Deployment Less to deploy at once

11. 11.

    Complex Interdependencies Harder to deploy & track bugs

12. 12.

    Requires great communication Teams need calling contracts and APIs

13. 13.

    More points of failure Not just one set of homogenous

    servers
14. 14.

    No more quick hacks Separation forces a level of code

    design
15. 15.

    Switching To Services Or: How I Learned To Stop Worrying

    And Love The Monolith
16. 16.

    Identify the "cut points" You might need to make some

17. 17.

    Allocate inventory Calculate Price & Charge card Finalise order Make

    Order Row &
18. 18.

    Make Order Row Allocate inventory Calculate Price Charge card Finalise

    inventory Finalise order
19. 19.

    Make Order Row Allocate inventory Calculate Price Charge card Finalise

    inventory Finalise order
20. 20.

    Define APIs between services Behave like all other teams are

    third-party
21. 21.

    Separate Datastores & Servers Make them as separate as possible

22. 22.

    Communication & Transport

23. 23.

    Service 2 Service 3 Service 1

24. 24.

    Service 2 Service 3 Service 1 Direct Communication (20 services?

    190 connections!)
25. 25.

    Service 2 Service 3 Service 1 Direct with discovery Orchestrator

26. 26.

    Service 2 Service 3 Service 1 Centralised Routing Router

27. 27.

    Service 2 Service 3 Service 1 Message Bus

28. 28.

    Centralised Comms Tradeoffs Distributed Comms Single point of failure Nasty

    partial failures
29. 29.

    At-least-once delivery Tradeoffs At-most-once delivery Some messages duplicated Some messages

    lost
30. 30.

    First-In-First-Out Tradeoffs First-In-Last-Out Easily backlogged Wide range of latencies

31. 31.

    Channels & ASGI

32. 32.

    Channel Layer Interface Server Worker Server Process 1 ASGI ASGI

    Asynchronous socket handling Synchronous Django project Interface Server Worker Server ASGI ASGI Worker Server ASGI Process 2 Process 3 Process 4
33. 33.

    Service 2 Service 3 Service 1 Channel Layer

34. 34.

    Service Client inventory.request response.aF53Vds21

35. 35.

    At-most-once delivery ASGI's Tradeoffs You have to design for potential

    loss Low-latency but non-persistent Good for protocols, bad for important task queues Capacity, Backpressure and FIFO Informs producers quickly about pileups in the queue
36. 36.

    Top Service-Oriented Architecture Tips

37. 37.

    Per-request "correlation IDs" Track a set of service calls through

    the stack
38. 38.

    Feature Flag message headers Bundle them in, don't have every

    service query them
39. 39.

    Source Of Truth Each data model has a service that

    owns (& caches) it
40. 40.

    Metrics. Metrics everywhere. Both performance and network health

41. 41.

    Design for failure Don't assume two things will both succeed

42. 42.

    DO NOT START OFF WITH SERVICES Write separate Python libraries

    instead
43. 43.

    Thanks. Andrew Godwin @andrewgodwin