Microservices

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.

SOA

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 datastore. It can also have its own platform.

  • 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.

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.

References and further reading:

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s