So why microservices? Many blog posts have been written about the pro’s and con’s of microservices in general, so we’re not going into that.

Instead, we’ll dive a bit deeper into what we as a team like about microservices in particular.

Microservices are designed for change

We’re building a web platform, and the web is complex and changing rapidly. We’re assuming from the start that parts of our platform will eventually be scrapped. Microservices make that easier.

Microservices also require us to design our systems for failure. Certain services might be unavailable at times and our systems needs to deal with that gracefully.

The latter could be seen as a downside, because designing systems in this way requires extra thought, introducing additional overhead. However, it also means that our teams have to constantly reflect on how service failures have an impact on the user experience. We encourage our teams to take that kind of ownership, so we see that as a pro rather than a con.

Microservices empower small, cross-functional teams to take ownership of our product

Microservices are standalone services that can be built, deployed and maintained in isolation from other services and systems. Because of their small scope and separated nature, teams are enabled to take full responsibility for services and thus our product.

Amazon coined the “You build it, you run it” phrase to describe this ethos:

The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service. — Werner Vogels (CTO @ Amazon)

This type of ownership could technically also be achieved within a monolith, but because monoliths aren’t as strict on modularity, it’s a lot harder to keep clear modular lines between product domains. Microservices explicitly require separation, which makes it easier to keep team boundaries and responsibilities clear.

One additional benefit of their isolated nature, is that microservices don’t force you to use a single programming language. Even though we like Go — it’s fast and it works well for us — we believe in using the best tool for the job, so we’re not ruling out the use of other languages in the future.

Microservices support the way we envision our organizational culture

Conway’s Law tells us that “any organisation that designs a system, will produce a design whose structure is a copy of the organization’s communication structure”.

Like our systems, we want our teams to be tightly aligned, and loosely coupled. We believe in the effectiveness of interdisciplinary product teams of developers, designers and data scientists that understand and tackle business problems from different angles.

Spotify did a great job implementing these principles in their engineering culture.

Microservices are going to help us scale

Microservices allow you to scale just the part of the application that needs extra resources, rather than the entire monolith.

For us this makes a lot of sense, because there’s a big difference between services that get a large amount of requests (say, an analytics service that gets hit many times for each user) and lightweight components (e.g. an image cropping service that only gets used a couple of times per day).

These scaling benefits of microservices will have a positive impact on speed, ease of deployment, and the costs of our infrastructure.