Spotify has been doing microservices for quite some years at large scale. Kevin Goldsmith, Vice President of Engineering at Spotify, talked about how Spotify uses microservices to break down architectures and be innovative at the GOTO Berlin 2015 conference. He argues that Microservices are easier to test, deploy and monitor than monolithic applications. Spotify also aims to have as few as possible dependencies in their product, and microservices are very helpful for that.
You have to build your system in a way that you can scale independently said Goldsmith. For instance by structuring your application in loosely coupled parts. Spotify works with autonomous full-stack teams: teams that have the freedom to act independently. Building microservices helps Spotify to have autonomous teams, since the team can own the service themselves.
Microservices make it easier to scale your product as you can solve the real world bottlenecks. They are also easier to test, deploy and monitor than monolithic applications.
One additional advantage of microservices is that you can have servers running older versions of a service until they are phased out. This way the old code doesn’t have to be in newer versions of the software which eases development.
Another advantage of microservices is that each service is not doing so much. Because each service does a specific, smaller role in the application, if it is unavailable for some reason, the user impact is minimized.
To work with microservices you need good documentation and discovery tools. Spotify uses a system overview tool which is a service discovery and documentation tool that they have built themselves which shows all available microservices.
One disadvantages of microservices is that as services are calling many other services you can get big latency. One thing that Spotify has done to improve the latency issues is to build "view aggregation" services which handle gathering the data needed to populate a client view on the server side. This reduces the number of calls that the client has to make to the server and improves latency significantly.
A risk of using microservices is that autonomous teams might be repeating work and doing the same thing. Spotify prevents this by making very clear what teams should be working at. Teams have their own mission which do not overlap. Guilds are used for people in multiple teams to learn from each other.
Developers deploy microservices themselves at Spotify, they are responsible for their own operations. They are supported with tools which make it easy to provisions and deploy.
Goldsmith stated that Spotify collects a "ridiculous amount of data" to analyze performance of the client side and has teams dedicated to that. The server performance is measured in the traditional ways. This helps them to monitor the performance
Somebody from the audience asked how Spotify keeps teams in sync. Goldsmith answered that teams are autonomous: "we don’t sync them". The aim is to have as few as possible dependencies and microservices are very helpful for that. If a system is doing multiple, unrelated things; the suggestion is to refactor it into multiple independant specific-purpose systems.
You have to balance team autonomy with general requirements on what services should do. Teams get the tools which makes it as easy as possible. At Spotify we don’t enforce rules, but sometimes we make it painful to not do obvious things said Goldsmith. We let teams try to find the best solutions to their problems. We make it very easy to follow our evolved best practices. If teams want to challenge those ways of working, they can, but they will have to do a lot more work to make that happen.