what has soundcloud learnt about microservices?
DESCRIPTION
Presentation: "What has SoundCloud learnt about Microservices?" Track: Monoliths & Microservices / Time: Friday 11:30 - 12:20 / Location: Hall 10 SoundCloud is the largest repository of audio on the web, used by more than 200 million people every month who upload more than 11 hours of audio every minute. Over the past few years we migrated from a typical monolithic architecture to microservices, and during this journey we found out what is real and what is hype about this buzzword. When does "the best tool for the job" break? What is available as open-source software and what will you have to build yourself? How to move from several deploys a day from dozens of deploys of dozens of different apps and keep sanity? How to deal with shared code bases? How does one even test all these moving parts? How big should a microservice be, anyway? In this talk, let's discuss the results of our discovery phase and what technologies, architecture patterns and processes we have adopted as our default toolbox. PHIL CALCADO, SOUNDCLOUD Phil Calcado Biography: Phil Calcado Phil Calçado is a Director of Engineering at SoundCloud, where he writes code and helps teams build a scalable and maintainable service. Before moving to Berlin, he spent four years as a Lead Consultant for ThoughtWorks, where he helped clients build systems in whatever crazy stack they had decided to use. Twitter: @pcalcado Blog: philcalcado.com http://gotocon.com/berlin-2014/presentation/What%20has%20SoundCloud%20learnt%20about%20Microservices?TRANSCRIPT
What has SoundCloud
microservices?
learnt about
Phil CalçadoSoundCloud
>11 hours ofaudio uploaded every minute
~300million peopleevery month
What we
2012-13did in
SoundCloud.com
Sounds ˝& Sets
Social Graph
Premium ˝Features Search
Activity Stream
API
Sounds ˝& Sets
Social Graph
Premium ˝Features Search
Activity Stream
API
api.soundcloud.com
iOS Android Desktop Widget 3rd Party
api-mobile
iOS Android Desktop Widget
api web api-partn
3rd Party
More details
http://bit.ly/dealing-with-the-monolith
minimise
fixed costyour
per app
#1
every new app answers
What language?
What I/O lib?What build system?
How do we deploy?What do we monitor?
typical agile project
iteration 0 iteration 1 iteration 2 iteration 3 iteration 4
technical tasksuser stories
typical microservices project
iteration 0 iteration 1 iteration 2 iteration 3 iteration 4
You will have lots of microservices
Consider having a “standard”, well-
supported and documented stack
outsource
as possibleas much
#2
micro service x-ray
infrastructure
app
Avoid building as much ˝infrastructure as possible
some good options
Only infrastructure we need to build is the glue between the lib and our
quirks
Avoid having quirks
acknowledge
complexitythe new
#3
user
likes
track
user
likes
track
unit test
single process
run inside an IDE
typical app
user
likes
track
integration test
multiple processes
stubs and fakes
microservice
+ +
must be easy to provision
make
visibleeverything
#4
make interactions visible
standardised dashboards
legacywrap your
stranglerswith
#5
api-mobile
iOS Android Desktop Widget
api web api-partn
3rd Party
not exactly true
iOS Android Desktop Widget 3rd Party
api.soundcloud.com
mothership still alive
api web api-partn
Client
api.soundcloud.com
Client
strangler
api.soundcloud.com
Client
strangler
api.soundcloud.com
Client
strangler
api.soundcloud.com
changedwhat changed
2013?since
babysitting
Rails
Stop
☑
Enable &
app devsempower☑
“Experience
api?based” ☒
comes
next?
What
devicesmore
based
RPC?
IDL
test
environments
ephemeral
