Microservices at Spotify

 

The numbers at Spotify are insane, specifically:

– Over 90 teams
– Over 600 developers
– Over 800 microservices
– 75 million active users
– 2 billion user generated playlists

That’s great proof that microservices work at scale (as if Netflix weren’t proving it enough).  There are some key takeaways from this video which I think need highlighting:

 

Multiple versions, simultaneously

Spotify keeps old versions of the API alive as long as they’re needed. This is needed to support legacy systems, such as embedded systems. If you have a lamp which supports Spotify then you need to support that API for a long time.  They do this using microservices- they keep the old service alive, and put the new versions of the new service on a new box.  They can then use statistics to measure when the old version of the API is no longer needed, then they can kill it off.  This is so incredibly powerful for anyone doing enterprise development.

If you are depended on by any other team for an API (a pretty common use case) then you’ve no doubt had this versioning hell.  You want to upgrade your API but you need to do it in lockstep with all upstream services. Something goes wrong and you all have to rollback. It’s such a pain.  Using microservices you can completely eradicate this.  It’s a gamechanger.

 

Mandatory Java in production

I found this particularly interesting as Netflix allows anything that runs on the JVM.  Spotify’s argument is that with people switching teams regularly it’s better to have one language. It also means you only need one set of tools for one language.  Personally I’m a big fan of this approach.  There’s a lot of pressure to use newer languages from developers (because developers love new shiney languages) and so to make this as a hard and fast rule makes things a lot simpler. No more struggling because some other team has decided to use scala/clojure/go/other language.

 

This is going to be a pretty controversial view. People love polyglot programming.

 

If you write rubbish code microservices won’t save you

Microservices aren’t a silver bullet. If you write bad code, if you don’t write tests, your microservices will still be terrible. In fact, they may be even worse than your monolith. With great power comes great responsibility- microservices require proper deployment and monitoring tools, and if you don’t have them already you will end up in a mess without them.

 

Services should be quick to rewrite

I’ve said before that a microservice should be possible to rewrite in about 2 weeks.  Spotify sound like they’ve got a very similar spec as they’ve gone through 4, 5 or 6 iterations of some services.  This is a great way to avoid legacy code.  When you write code you’re also discovering the problem space- once you’ve written it once the second time you write it the code should be better, faster, stronger etc.

 

 

2 Comments

Join the Discussion

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>