Microservices architecture is a flavor of service oriented architecture, where you decompose a big application into multiple small services. It’s opposite to Monolithic architecture, where you have a single repository/team working on the same application.
What differentiates it is that it gives more emphasis on:
- Hard boundaries between services
- Different teams maintain each service, with different deployment timelines that are not coordinated
- They don’t share the same choice of technology or database
- Suitable for large teams and large projects
- The team working on a single service is a small agile team that should be 5–10 including all roles (can be fed with 2 pizzas :)
- Each team is autonomous, can provide new features and deploy them on their own without coordinating multiple services deployment at a time
- When a new technology or database needs to be adopted it can be done on the scale of one service, without having to re-engineer the whole application
- Gives much control over scalability where each service can be scaled separately
- Not suitable for a small project or a small team
- Hard to define boundaries between services where they shouldn’t be too dependent or chatty
- Introduces more complexity in the design, implementations, monitoring so a team should be ready to tackle a lot of new challenges as they progress
Why is it trending now?
Being used and promoted by big names like Amazon, Netflix, Uber… It allowed them to reach the right balance between agility and high service level objectives which puts every other competitor behind. So it’s embrace it or disappear. Also advances in Docker containers and orchestrators, allowed the number of services to increase reaching thousands to hundred thousands instances.
Let’s get started
To get started from here, we need to go step by step. Here is a high level overview of how to build microservices architecture for your product.
- Build a single microservice: for me I use .NET Core as the run-time, ASP.NET Boilerplate to provide a framework for domain driven design and swagger to expose API documentations.
- Docker containers: to ship each service, I push it to a container registry.
- Kubernetes: to host these individual services, making sure they scale according to needs and maintain their provisioning when a server goes down. Kubernetes takes care of service discover-ability, network and rolling updates. It provides the operating system that gives me flexibility to run my product on any cloud or on any data center.
- Use managed databases: like SQL Azure or Cosmos DB in case of hosting on Azure.
- Istio or Linkerd: as a service mesh, which handles ingress, routing, resiliency, circuit breaker and monitoring capabilities to the traffic going through the whole setup.
- gRPC: for high performance inter-service communication.
I bet this is too much to take at once. So I’ll start by explaining Kubernetes the most important piece of it all, from installation to deploying your first app and then running DevOps.
A good read
This is a very good online read from Microsoft that talks about designing, building and operating microservices on Azure with Kubernetes. If you read it before continuing this series, as it highlights the challenges facing a microservices architecture and gives recommendation on how to handle them.