A beginner’s introduction to Microservices Architecture.

These days, whenever I read articles about architecture of various applications I see that a lot of them use microservices architecture. It seems to be a tech trend now to follow microservices architecture. This might be because the huge advantages which following this architecture provide us with, the biggest of them being easy error detection, solution and maintenance of each service your application uses. All of this lead me to trying to understand what exactly is microservices architecture in the first place.

Lets first look at the 2 main things which make up Microservices in the first place.

Domain driven design

When we are solving problems of people who are working in a particular domain, domain driven design plays a very specific and strategic role in development of the required product/solution, there are three main steps involved in domain driven design :

1. We interact and understand the language which is being spoken/used by the experts of the subject domain , understand the problems faced by them from their point of view which helps us develop the product in such a way that the solution works best for the people who are eventually going to use it. ( Ubiquitous language, which is being used by both the technical and non-technical team )
2. Since we understand the language which is being used by the experts of the subject domain, we impart the same in our code in terms of naming classes, variables, methods etc, which helps create a better understanding of the role played by each component.
3. The language of the subject domain must be protected from corruption from the technical domain, such mix up must not be allowed to happen and a well defined partition must be created.

Polyglot Programming

In addition to DDD we use polyglot programming, in which we use domain specific languages to program certain aspects of the product, polyglot programming is an approach in which we program every domain with a language which is best suited for that domain and then later integrate all the different domains together later.

Main Topic

Now finally I want to talk about the elephant in the room, Microservices. Microservices is a cloud native architecture in which a single application is divided into smaller components which are loosely coupled, and each of these component is called a 'microservice'. Each microservice is independently deployable, which makes it easier for them to be updated/maintained independently.

It is an evolution of DDD and polyglot programming , continuous delivery and scalable systems. Additionally all those things which change together are grouped together and those which don’t change together are separated from each other.

Things which change together, stay together.

One of the big advantages of using microservices is that making changes to the application becomes easy because when a change is performed only the parts which are associated with that change need to be updated, and since the application is divided into smaller services the parts which get affected are very less.

All of this also makes it easier for the architects in choosing a tech stack since separation of services provide us with the ability to use polyglot programming.

Some things to remember

Before you get excited and decide to shift your application's architecture into a microservice architecture, you must remember a few things:

• First we must be able to decompose the application into several smaller microservices to develop a microservice, we can perform decomposition in several ways  . But one of the best ways is to decompose according to business capabilities. i.e. Decomposition on the basis of tasks performed in the business in real world. Due to the presence of clear boundaries we can define each microservice in their own way. This is where DDD plays a very important role.
• While developing the service, only necessary parts must be exposed, not the unnecessary parts, so that there is less complexity while updating the system/services.
• Data handling is a major part of any application, due to which giving 2 or more services direct access to the database might prove to be an inefficient option since updating the schema becomes very difficult, it also becomes difficult to understand who is accessing the data which is present in database, hence it is essential to have least number of resources to have direct access to the database.

Case Study : Amazon

I would like to follow up all of those theoretical concepts with a bit of real world application of it. Let's see how Amazon shifted to a microservices architecture.

1. In my initial statements I said 'Things which change together, stay together' , that's what Amazon's engineers did as well, they pulled and grouped together all of the source code which served a single purpose.
2. Now, the next thing is to make these groups of source codes able enough to communicate each other over the web. So they followed up with adding a layer of web service interface to each group.
3. Now comes the part where they talk to each other, for this, Amazon decided that every other kind of API which exists is too mainstream and doesn't exactly serve their purpose, so they ended up making their own Web Service API. This made it easier for them to add functionalities to it over a period of time.

By moving their own e-commerce website to microservice architecture (previously known as Service Oriented Architecture) Amazon smartly ended up providing it as a paid service to its clients via Apollo and later introduced various services in its CSP platform AWS for its customers to make use of which makes it convenient for everyone to develop and deploy applications on the cloud now.

Conclusion

I would call the format of this article as 'loosely coupled' as well (since there is not much connecting various sections of it but some references here and there) but I hope this was a good read and helped you understand microservice architecture on an extremely basic level.