Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Services, Architecture and Channels
Search
Andrew Godwin
April 03, 2017
Programming
4
680
Services, Architecture and Channels
A talk I gave at DjangoCon Europe 2017 in Florence, Italy
Andrew Godwin
April 03, 2017
Tweet
Share
More Decks by Andrew Godwin
See All by Andrew Godwin
Reconciling Everything
andrewgodwin
1
310
Django Through The Years
andrewgodwin
0
200
Writing Maintainable Software At Scale
andrewgodwin
0
440
A Newcomer's Guide To Airflow's Architecture
andrewgodwin
0
350
Async, Python, and the Future
andrewgodwin
2
660
How To Break Django: With Async
andrewgodwin
1
730
Taking Django's ORM Async
andrewgodwin
0
720
The Long Road To Asynchrony
andrewgodwin
0
660
The Scientist & The Engineer
andrewgodwin
1
760
Other Decks in Programming
See All in Programming
『自分のデータだけ見せたい!』を叶える──Laravel × Casbin で複雑権限をスッキリ解きほぐす 25 分
akitotsukahara
2
640
システム成長を止めない!本番無停止テーブル移行の全貌
sakawe_ee
1
210
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
800
AI コーディングエージェントの時代へ:JetBrains が描く開発の未来
masaruhr
1
190
ふつうの技術スタックでアート作品を作ってみる
akira888
1
900
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
790
VS Code Update for GitHub Copilot
74th
2
660
dbt民主化とLLMによる開発ブースト ~ AI Readyな分析サイクルを目指して ~
yoshyum
3
1.1k
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
240
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
7.7k
オンコール⼊⾨〜ページャーが鳴る前に、あなたが備えられること〜 / Before The Pager Rings
yktakaha4
1
180
What's new in AppKit on macOS 26
1024jp
0
120
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Raft: Consensus for Rubyists
vanstee
140
7k
Why Our Code Smells
bkeepers
PRO
336
57k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
4 Signs Your Business is Dying
shpigford
184
22k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
830
Transcript
Andrew Godwin @andrewgodwin
Andrew Godwin Hi, I'm Django core developer Senior Software Engineer
at Apparently now does software architecture
The Monolith
The Monolith Only one version of any dependency Everything can
import everything Deployed all at once No separation Side-effects from other code
None
Services Code split up by purpose/team Defined cross-boundary API Deployed
separately Can use different versions of dependencies Isolated from each other
Why services?
Easier to manage Smaller, self-contained problems
Independent Scaling And easier performance analysis
Faster Individual Deployment Less to deploy at once
Complex Interdependencies Harder to deploy & track bugs
Requires great communication Teams need calling contracts and APIs
More points of failure Not just one set of homogenous
servers
No more quick hacks Separation forces a level of code
design
Switching To Services Or: How I Learned To Stop Worrying
And Love The Monolith
Identify the "cut points" You might need to make some
Allocate inventory Calculate Price & Charge card Finalise order Make
Order Row &
Make Order Row Allocate inventory Calculate Price Charge card Finalise
inventory Finalise order
Make Order Row Allocate inventory Calculate Price Charge card Finalise
inventory Finalise order
Define APIs between services Behave like all other teams are
third-party
Separate Datastores & Servers Make them as separate as possible
Communication & Transport
Service 2 Service 3 Service 1
Service 2 Service 3 Service 1 Direct Communication (20 services?
190 connections!)
Service 2 Service 3 Service 1 Direct with discovery Orchestrator
Service 2 Service 3 Service 1 Centralised Routing Router
Service 2 Service 3 Service 1 Message Bus
Centralised Comms Tradeoffs Distributed Comms Single point of failure Nasty
partial failures
At-least-once delivery Tradeoffs At-most-once delivery Some messages duplicated Some messages
lost
First-In-First-Out Tradeoffs First-In-Last-Out Easily backlogged Wide range of latencies
Channels & ASGI
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
Service 2 Service 3 Service 1 Channel Layer
Service Client inventory.request response.aF53Vds21
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
Top Service-Oriented Architecture Tips
Per-request "correlation IDs" Track a set of service calls through
the stack
Feature Flag message headers Bundle them in, don't have every
service query them
Source Of Truth Each data model has a service that
owns (& caches) it
Metrics. Metrics everywhere. Both performance and network health
Design for failure Don't assume two things will both succeed
DO NOT START OFF WITH SERVICES Write separate Python libraries
instead
Thanks. Andrew Godwin @andrewgodwin