Services, Architecture and Channels

A talk I gave at DjangoCon Europe 2017 in Florence, Italy

Transcript

1. Andrew Godwin @andrewgodwin
2. Andrew Godwin Hi, I'm Django core developer Senior Software Engineer at Apparently now does software architecture
3. The Monolith
4. The Monolith Only one version of any dependency Everything can import everything Deployed all at once No separation Side-effects from other code
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. Why services?
8. Easier to manage Smaller, self-contained problems
9. Independent Scaling And easier performance analysis
10. Faster Individual Deployment Less to deploy at once
11. Complex Interdependencies Harder to deploy & track bugs
12. Requires great communication Teams need calling contracts and APIs
13. More points of failure Not just one set of homogenous servers
14. No more quick hacks Separation forces a level of code design
15. Switching To Services Or: How I Learned To Stop Worrying And Love The Monolith
16. Identify the "cut points" You might need to make some
17. Allocate inventory Calculate Price & Charge card Finalise order Make Order Row &
18. Make Order Row Allocate inventory Calculate Price Charge card Finalise inventory Finalise order
19. Make Order Row Allocate inventory Calculate Price Charge card Finalise inventory Finalise order
20. Define APIs between services Behave like all other teams are third-party
21. Separate Datastores & Servers Make them as separate as possible
22. Communication & Transport
23. Service 2 Service 3 Service 1
24. Service 2 Service 3 Service 1 Direct Communication (20 services? 190 connections!)
25. Service 2 Service 3 Service 1 Direct with discovery Orchestrator
26. Service 2 Service 3 Service 1 Centralised Routing Router
27. Service 2 Service 3 Service 1 Message Bus
28. Centralised Comms Tradeoffs Distributed Comms Single point of failure Nasty partial failures
29. At-least-once delivery Tradeoffs At-most-once delivery Some messages duplicated Some messages lost
30. First-In-First-Out Tradeoffs First-In-Last-Out Easily backlogged Wide range of latencies
31. Channels & ASGI
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. Service 2 Service 3 Service 1 Channel Layer
34. Service Client inventory.request response.aF53Vds21
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. Top Service-Oriented Architecture Tips
37. Per-request "correlation IDs" Track a set of service calls through the stack
38. Feature Flag message headers Bundle them in, don't have every service query them
39. Source Of Truth Each data model has a service that owns (& caches) it
40. Metrics. Metrics everywhere. Both performance and network health
41. Design for failure Don't assume two things will both succeed
42. DO NOT START OFF WITH SERVICES Write separate Python libraries instead
43. Thanks. Andrew Godwin @andrewgodwin