🧠Knowledge Series #13: What is a microservice?
Everything you need to know about the architectural pattern
🔒The Knowledge Series is a series of easy to read guides designed to help you plug the gaps in your tech knowledge so that you feel more confident when chatting to colleagues. Clearly explained in plain English. One topic at a time.
If you’re a free subscriber and you’d like to upgrade to unlock them you can do so below. Or you can find out more about paid access here.
Hi product people 👋,
For non-engineering members of a product team, getting an understanding of your product’s architecture can be difficult. It’s often a case of treading a fine line between understanding enough to make some informed decisions and digging so deeply that you’ve forgotten about the value your product offers in the first place.
In this Knowledge Series, we’ll focus on one particular part of the tech stack that gets referenced a lot in technical architectural discussions: microservices.
There are folks with strong opinions on microservices and service oriented architecture - and we’ll come on to some of the reasons why. But it’s safe to say that regardless of which camp you fall under, having a basic understanding of what microservices are will certainly help you in conversations with engineering teams.
Coming up:
What are microservices?
Some practical examples
Potential downsides
How to transition from monolith to service oriented architecture
Key terminology to know
Introducing microservices
Microservices are an architectural pattern in which an application is built using a collection of small, independent ‘services’ that communicate with each other over APIs. If you’re not familiar with REST APIs and how APIs communicate with each other, you can check out this previous Knowledge Series guide on APIs.
The idea behind using a microservice is that a product’s codebase is split up into distinct areas, each independently responsible for a specific function or business capability. These services can then be developed, tested, and deployed independently of the other services in the application.
An insurance company, for example, might have a bunch of services that lead to a sale: