Services, Architecture and Channels

Services, Architecture and Channels

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

077e9a0cb34fa3eba2699240c9509717?s=128

Andrew Godwin

April 03, 2017
Tweet

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
  5. None
  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