New Era Microservices Architecture

Microservice architecture, or simply microservices, is a distinctive method of developing software systems that have grown in popularity in recent years. In fact, for many developers it has become a preferred way of creating enterprise applications.

Microservices is a software architecture style in which complex applications are composed of small, independent processes that communicate with each other using web services. These services are small, highly decoupled and focus on doing a small tasks perfectly. The philosophy of microservices architecture essentially equals the Unix philosophy of “Do one thing and do it well”. 

While there is no standard, formal definition of microservices, there are certain characteristics that help us identify the style.  Essentially, microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services, in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.

Thanks to its scalability, this architectural method is considered particularly ideal when you have to enable support for a range of platforms and devices spanning web, mobile, IOT and wearables—or simply when you’re not sure what kind of devices you’ll need to support in an increasingly cloudy future all over.

How the services communicate with each other depends on your application’s requirements, but many developers use HTTP/REST with JSON or XML for communication between the micro services as a standard protocol.

To begin to understand microservices architecture, let us first understand the opposite architecture; i.e. the monolithic architectural style. Unlike microservices, a monolithic application is always built as a single, autonomous unit. In a client-server model, the server-side application is a monolith that handles the HTTP requests, executes logic, and retrieves/updates the data in the underlying database. The problem with a monolithic architecture, though, is that all change cycles usually end up being tied to one another. A modification made to a small section of an application might require building and deploying an entirely new version. If you need to scale specific functions of an application, you may have to scale the entire application instead of just the desired components. This is where microservices can come to the rescue.

Examples of Microservices:

Netflix, eBay, Twitter, PayPal, Gilt, Bluemix, Soundcloud, The Guardian, and many other large-scale websites and applications have all evolved from monolithic to microservices architecture.


  • Microservice architecture gives developers the freedom to independently develop and deploy services.
  • A microservice can be developed by a fairly small team.
  • Code for different services can be written in different languages.
  • It is easy to understand and modification is simple. Hence learning is fast.
  • When change is required in a certain part of the application, only the related services need be modified and redeployed—no need to modify and redeploy the entire application.
  • Better fault isolation: if one microservice fails, the other will continue to work (although one problematic area of a monolith application can jeopardize the entire system).
  • Easy to scale and integrate with third-party services.


  • Due to distributed deployment, testing can become complicated and tedious.
  • Increasing number of services can result in information barriers.
  • The architecture brings additional complexity as the developers have to mitigate fault tolerance, network latency, and deal with a variety of message formats as well as load balancing.
  • Being a distributed system, it can result in duplication of effort.
  • When number of services increases, integration and managing whole products can become complicated.
  • Handling use cases that span more than one service without using distributed transactions is not only tough but also requires communication and cooperation between different teams.
  • The architecture usually results in increased memory consumption.



By : Nataraj Srikantaiah