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

8 thoughts on “New Era Microservices Architecture

  1. The topic sounds really interesting, I will definitely look for more information and explore it further.

    Have you implemented microservices in real time ?

    1. Suman,

      Please do explore the microservices, it’s really an interesting stuff.

      Refer to the for the reference. The website has tons and tons of information.

      And to answer you question, yeah microservices have been implemented in one of the on-going project. It’s a new learning and exciting stuff for me.


  2. Thanks Nataraj.

    Insight on microservices with pros and cons are really good.
    Hope to hear more from you and keep spreading the light.

  3. Nataraj,
    Very Good article on Microservices, as you said there are pros, cons and challenges on microservices, especially single ownership of specific functional service, the no.of owners will increases when business capabilities/functional services increases. Also increases Software, tools, infrastructure cost when services increases.
    Would like to comment on 2nd paragraph mentioned about web services only.. it can be any service like messaging, adapters, file, web services it can exchanges the information between the business components

    Also can you please post best practices, challenges if you have any.


    1. Damodar,

      Thanks for your idea and suggestions.

      As you’ve mentioned if the business/functional services increases it does results in increased infrastructure, ownership etc. But at the same time you need to see the advantages what you are getting from microservices. It allows you to scale up/down the required services based on the requirement.

      The challenge for infrastructure can be handled by setting up a bench mark based on the non-functional requirements from the business team. With the help of performance team we can identify the actual infrastructure required to support the bench mark with various kind of end to end performance test and tweak the infrastructures. It’s a bit of long process but definitely achievable.


  4. Nataraj,

    Great article!

    I have few queries for you:-
    1. Could you provide some details around how you implement monitoring and logging?
    2. Also am specifically wondering whether you do any kind of workflow/transaction tracing between the services?
    3. Have you found a solution for the testing challenge?

    1. Swaroop,

      Please find the responses for your queries.

      Query # 1
      We use Splunk for log aggregation and analysis and Graphana to do monitoring.

      Query # 2
      The request has to go through several micro services for a event or processing. What we do is tag each request with a requestId which is unique. The requestId is generated when the first request enters our system and the same will passed down to the micros services call. The requestId is a tag in our logs, so we can trace the entire flow in Splunk.

      Query # 3
      Testing is going to be a challenge in micro services architecture as end to end testing requires all the services available. As every service will be going through different sprints, it will be a tricky and challenging situations for QA always. The sign off should call out each and every service version against which the QA is signing off. Also the infrastructure cost will be on the higher side as we need to maintain different environments and for each environment all micro services has to be deployed. Getting the sanity test done for each of the micro services at different environments is another frequent tasks for QA, so it’s recommended to have automation suite built otherwise it will be a nightmare for QA folks.


Leave a Reply

Your email address will not be published. Required fields are marked *