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
Microservices are an antipattern
Search
Lindsay Holmwood
April 18, 2019
Technology
0
200
Microservices are an antipattern
Lindsay Holmwood
April 18, 2019
Tweet
Share
More Decks by Lindsay Holmwood
See All by Lindsay Holmwood
Your API ain't as secure as you think
auxesis
0
120
Footguns and factorisation: how to make users of your cryptographic library successful
auxesis
0
1.4k
Levelling up database security by thinking in APIs
auxesis
0
120
How to thwart your devops transformation with counterinsurgency doctrine
auxesis
1
74
Mirrors, networks, and boundaries
auxesis
0
110
Managing remotely, while remotely managing
auxesis
13
4.3k
Testing Conway’s Law in open source communities
auxesis
6
580
Building and scaling effective distributed teams
auxesis
4
210
Mirror, mirror, on the wall
auxesis
2
270
Other Decks in Technology
See All in Technology
Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)
legalontechnologies
PRO
0
690
AndroidデバイスにFTPサーバを建立する
e10dokup
0
250
速くて安いWebサイトを作る
nishiharatsubasa
10
12k
RSNA2024振り返り
nanachi
0
570
Cloud Spanner 導入で実現した快適な開発と運用について
colopl
1
560
Amazon S3 Tablesと外部分析基盤連携について / Amazon S3 Tables and External Data Analytics Platform
nttcom
0
130
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
1.4k
組織貢献をするフリーランスエンジニアという生き方
n_takehata
1
1.3k
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
740
『衛星データ利用の方々にとって近いようで触れる機会のなさそうな小話 ~ 衛星搭載ソフトウェアと衛星運用ソフトウェア (実物) を動かしながらわいわいする編 ~』 @日本衛星データコミニティ勉強会
meltingrabbit
0
140
レビューを増やしつつ 高評価維持するテクニック
tsuzuki817
1
690
Datadog APM におけるトレース収集の流れ及び Retention Filters のはなし / datadog-apm-trace-retention-filters
k6s4i53rx
0
330
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Producing Creativity
orderedlist
PRO
344
39k
Agile that works and the tools we love
rasmusluckow
328
21k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Gamification - CAS2011
davidbonilla
80
5.1k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
Making Projects Easy
brettharned
116
6k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Unsuck your backbone
ammeep
669
57k
Practical Orchestrator
shlominoach
186
10k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
330
Transcript
Microservices are an antipattern Lindsay Holmwood
Microservices are an antipattern Lindsay Holmwood
Why microservices?
Design strategy to manage complexity in our systems
Design strategy to manage complexity in our systems
If the system or team get too big, we: 1.
Split the system
If the system or team get too big, we: 1.
Split the system
If the system or team get too big, we: 2.
Split the team
Popularised by the devops movement
Popularised by the devops movement
CD + containers were the drivers
CD + containers were the drivers
In use at the big end of town
“It works for Google, so we’ll scale it down and
get the same benefits!”
We cargo culted a design strategy without understanding the tradeoffs
Real talk: The smallest microservice at Google probably does more
transactions than the largest service in your organisation.
Real talk: We took a pattern for managing huge systems,
extrapolated it down to our size, and hoped it worked.
Real talk: Hope is not a strategy.
Some downsides you should think about:
Some downsides you should think about:
You’re replacing function calls with network calls
Source: “Systems Performance: Enterprise and the Cloud” by Brendan Gregg
Is that latency worth it?
What hard limits are you imposing to control unpredictability?
Microservices are a systems multiplier for your shitty code
None
How is your ◦ modularity? ◦ isolation? ◦ encapsulation?
Refactor first
Then scale when the performance impacts users
1. Make it work 2. Make it right 3. Make
it fast
1. Make it work 2. Make it right 3. Make
it fast Refactor
1. Make it work 2. Make it right 3. Make
it fast Refactor Microservice
Microservices have a higher cost of ownership
Operational requirements: ◦ CD pipelines ◦ Network & compute &
storage ◦ Logging ◦ Monitoring ◦ Tracing & observability
Security requirements: ◦ Authentication ◦ Identity ◦ Monitoring
This costs more (both in systems bills and engineering time)
But what if we just… didn’t?
But what if we just… didn’t?
Problems are harder to debug
Incidents have > MTTD & MTTR
Delivery slows
Increased communication + coordination overhead between teams
Sequencing of changes across multiple services
Poor service boundaries? You have to get multiple teams moving
in the same direction to deliver a change.
Stakeholders for technical changes are rarely exclusively technical
Requires coordination across disciplines like product, design, marketing, analytics, …
You need established and understood communication paths
You need established and understood change coordination
You need established cultural norms for resolving conflict
Microservices are an effective way to separate concerns in complex
systems
Microservices are an inefficient way of organising people in organisations
< 1,000 people
The smaller the org, the smaller the return
You are not Google/Netflix/ AWS/Facebook/…
Do the job you have, not the job you want.
Thank you! (fight me)