Introduction to Microservices

The microservice architecture is an approach that promotes the use of small services that can be developed, changed and deployed independently.
I have been working in a product that uses the microservice architecture for about 1.5-2 years now. And this has led me to start reading books like Building Microservices by Sam Newman. This is my attempt at trying to give a brief introduction to microservices.

Key Concepts

To understand the microservice architecture, there are some key concepts that need to be explained first. Let's have a look at a few of them, one by one.

Independent Deployability

One of the key benefits that you get out of the microservice architecture is that you can deploy each service independently without having to deploy any other service.

Imagine you have the above three services in your application. After making some changes in, say, chat service, you can deploy the chat service alone without having to worry about accounts or upload services.

Loosely Coupled

Before I explain what it is to be loosely coupled, let me tell you what coupling means. Coupling is the degree of interdependence between two modules. It is a measure of how closely connected two services are.

Now, to ensure independent deployability, we need to make sure our services are loosely coupled. From the above diagram, lets assume that the chat service is tightly coupled to the upload service.

Firstly, every time a change is made to the chat service, we need to change the upload service as well. And secondly, they both need to be deployed together.
This goes against the design of microservices and hence we need to make sure our services are loosely coupled.

Owning their own state

In a microservice architecture, each service has its own database. If a microservice wants to access data held by another microservice, it should go ask that second service for the data. This gives the service the ability to decide what is shared and what is hidden to other services.

By hiding the database that is used in the service, we also ensure loose coupling between the services.

Organizational Alignment

If you have a look at the above diagram, this is the standard three-tier architecture that every company probably starts out with. You'll have teams divided based on the technology they work on.

Melvin Conway had this to say about organisational structure which is now being famously called Conway's Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

Now let's say that we want to introduce a change. We would like to show a notification settings to the users allowing them to customise in-app notifications for themselves.

Our small change in business functionality spreads across all three tiers and requires communication between all three of them. If we want to make this change more effective, we need to instead change how we group code, choosing business cohesion more than technology.

Now let's look at a revised structure for our example organization below.

If you look at the structure above, you can see that the scope of change is minimised to a single team that should only have a few people working on it. This in turn speeds up the development process and can be deployed to the customers much sooner.

Microservice architecture lets your organization align itself to its business functionality. This helps us minimise the number of people working on any one codebase to prevent knowledge silos and faster communication. It also allows us to change ownership of services as the organization changes.

Hopefully, you have learnt something new after reading this. This is just part 1 of the microservices topic. There are still a lot more to talk about the architecture and whether it is the right one for your product use case.

Until then, keep learning!