https://www.youtube.com/watch?v=7LGPeBgNFuU&ab_channel=GOTOConferences

Feature teams

Spotify run teams that cover the full stack of their application, excluding the upper and lower most boundaries.

On public APIs

Each major version runs on a set of dedicated servers, new major versions get a new set of servers. This means a completely uninterrupted service for consumers of old API versions.

Pros of microservices

Easier to scale based on real-world bottlenecks

• If you are building a monolith, and one small part of that monolith sees a disproportionate amount of traffic, you still have to scale the entire thing.
• If you are building in a microservices-based architecture, it becomes much easier to just scale out to have multiple instances of a service serving traffic

Easier to test

• Smaller codebases are often easier to test.
• Less reliance on heavy integration tests.

Easier to deploy

• Easier to do smaller, more frequent releases.
• Smaller footprint means faster build/release times.

Easier to monitor

• A service that is smaller just does less. It follows that there is less to monitor.

Can be versioned independently

• Versioned services can be run on their own dedicated servers.

Less susceptible to large failures

• Big services fail big, small services fail small.
• You can build in redundancy to your inter-service dependencies, reducing the customer impact when any one part of the experience blows up.

Easier plug and play

• A small service can feasibly be rewritten/replaced, if it makes sense to do so. Scenarios where you might reasonably want to rewrite a system:
  • If requirements change dramatically
    • Technical requirements, such as scaling needs. It might make more sense to rewrite a system to scale better with the knowledge you have in hindsight, than to try to refactor an existing system for scalability.
  • If it acumulates too much technical debt.

Cons of microservices

Harder to monitor

• Challenges in monitoring a greater number of distributed services, despite the size of each individual service.
  • Add to that, Spotify’s method of versioning, having multiple versions of a particular service running at any given time.

Need for high quality documentation and discovery tools

• If you are running hundreds, or even thousands of tiny services, a new developer can easily be overwhelmed by the sheer volume. The learning curve to begin building is much steeper.

Increased latency

• Instead of one service call handling large chunks of logic, you now are calling many distinct services, with each further call adding more latency to the call origin.

View aggregation services as a remedy for high latency.

Instead of presenting one big view needing many service calls before presenting any kind of UI, create multiple partial views making calls to a view aggregation service that retrieves only the data that view needs to render.

If you write sloppy monolith code, moving to microservices won’t magically make it better.

• Bad code can stick around longer, because there are less people looking at code for any individual service.

Q&A

Are your teams not silo’d by being autonomous? How do you make sure teams are not repeating what others are doing rather than reusing?

• Teams are purposefully silo’d in that they are very explicit about the mission of a new team when it is created. The team’s mission should not overlap with the mission of another.
  • Teams may dictate their own approach to development practises, but they don’t redefine development practises for the company.
• Guilds
  • Transcend the company
  • Provide a way for knowledge and best practises to propagate through the company
  • Anyone can create one on any topic
    • Backend developers
    • Java developers
    • C++
    • Craft brewers
    • Photography

How do you handle deployment of your microservices?

• Teams responsible for their own ops
• Provide nice tooling to make it easy for teams to provision resources and deploy new services

How do you handle multiple versions of services?

• Repo is forked, and the service is deployed with the new API off the new fork