Microservices

There has been a great deal of talks about Microservice these days. So how exactly is it different from the traditional/monolith architectural design? How is it different from SOA or the Service Oriented Architecture? Here is how I ventured into finding answers to these questions.

Microservices in simple words is a way of decentralizing an application into smaller, well defined chunks, each performing an important task independently. Also, there needs to be a way these can talk to one another and solve the problem. A good example is the Microservice architecture built by Netflix.

We can assertively say that microservices are quite similar to SOA. We can imagine microservices to be a small portion of a much larger entity called the SOA. Microservices can be deployed independently whereas SOA is deployed as a single monolith. SOA is majorly focused on re-use of services unlike microservices which is all about decoupling.

There are quite a few perks that come with the Miroservices:

Exploring advantages of a variety of data stores.

A monolith architecture is restricted to choose a single database/datastore. This prevents the application from leveraging the advantages of other datastores simultaneously. However, each microservice can connect to its own database. It can also have its own platform. For example, a graph database can be used along with a relational database in a single application.

Enables partial deployments and Agility.

Generally, the waiting time is a major overhead when deploying products in production. This is because the development time for each feature varies widely. Microservice preserves modularity and offers the benefit of deploying each feature separately. This hence suits Agile development environments

Decentralized Infrastructure. High Availability.

Traditional architecture has a dependency on a single database. This causes a ‘single point of failure’. A single corruption/bug is sufficient to destabilize the entire application. Decentralization ensures infrastructure failure remains confined to a single entity without affecting the entire application. Downtime is also significantly reduced.

This also ensures deploying a single service rather than deploying the entire application.

Transactions are distributed

Not all transactions are intended for a single Database. For example, transactions with frequent reads for analytical purposes can be isolated from transactions with frequent writes.

Easier Scaling

Servers can be added to a service that has high load rather than scaling up the entire application. For example, say, Twitter’s tweets engine needs to scale up rather than Twitter Analytics.

Challenges

Designing an architecture with completely independent services along with language agnostic APIs to communicate between the services can be complex.
Organization embracing the change is a challenge. Provisioning of Infrastructure, seamless communication between application and Devops team, Rapid Application deployment can prove to be tough.
Testing a microservice application is much more cumbersome compared to a traditional application.
Multiple replication of data/redundancy can lead to low consistency.

Microservices Scaling

A microservice can be scaled by one of the following ways:

Horizontal Scaling – by running duplicate copies of the application on different servers. This will help in load balancing
Functional Decomposition – by decomposing the service further and creating smaller services
Data Partitioning – Adding servers and distributing the data among them using a partition key.

Remote Process Communication

Remote Process Communication or RPC can enable a program to cause a procedure to execute in a different Address space within a distributed system. Microservices