Introduction

In this blog, will have walk through about Microservices Architecture pattern, which is now a days more populate than Monolithic application

Background

Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers. 

Suppose we are developing a server-side application/web application. It must support a variety of different clients/devices and there requirements like desktop browsers,mobile browsers , native mobile applications ,different resolution etc. 

We might need to expose WEB API ( REST Service) for third parties to consume. This might be used by internal application as well. 

This WEB API could be responsible to executing business logic; accessing a database; exchanging messages with other systems; and returning a HTML/JSON/XML response. 

The application should having below layered architecture to support the requirements. 

Presentation Layer - Responsible for handling HTTP requests and responding with either HTML or JSON/XML (for web services APIS) 

Application Layer- Responsible for processing the data from Business Layer and pass the response to presentation layer. 

Business logic - The application’s business logic 

Database Layer - Responsible for access the database.

 Problems

1. Team is working on big application, can slowdown the development.
   
2. Adding new Team members would take a while understand application flow and start development.
   
3. Being a single application would be bit difficult to understand and modify
   
4. We must have to run multiple copies of the application on multiple machines in order to satisfy scalability and availability requirements.
   
5. Limitation to go with taking advantage of emerging technologies (frameworks, programming languages, etc)
   

What are Microservices

Architect the application by applying the Scale Cube (specifically y-axis scaling) and functionally decompose the application into a set of collaborating services. Each service implements a set of narrowly, related functions. 

For example, an application might consist of services such as the order management service, the customer management service etc. 

Service communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP. 

Services are developed and deployed independently of one another. 

Each service has its own/common database in order to be decoupled from other services. When necessary, consistency is between databases is maintained using either database replication mechanisms or application-level events.

Benefits

• Each microservice is relatively small

1.  Easier for a developer to understand
2. The IDE is faster making developers more productive
3. The web container starts faster, which makes developers more productive, and speeds up deployments

•  Each service can be deployed independently of other services - easier to deploy new versions of services frequently.
  
  
  1. Simple and lightweight.
     
     
  
  
  2. Independent Process.
     
     
  
  
  3. Independent databases
     
     


• Easier to scale development. It enables you to organize the development effort around multiple teams. Each team is responsible for a single service. Each team can develop, deploy and scale their service independently of all of the other teams
  
  


• Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests. In comparison, one misbehaving component of a monolithic architecture can bring down the entire system.


• Each service can be developed and deployed independently

Drawbacks

• Developers must deal with the additional complexity of creating a distributed system.

1. Developer tools/IDEs are oriented on building monolithic applications and don't provide explicit support for developing distributed applications.
2. Testing is more difficult
3. Developers must implement the inter-service communication mechanism.
4. Implementing use cases that span multiple services without using distributed transactions is difficult.
5. Implementing use cases that span multiple services requires careful coordination between the teams

• Deployment complexity In production, there is also the operational complexity of deploying and managing a system comprised of many different service types

Challenges

One challenge with using this approach is deciding when it makes sense to use it. When developing the first version of an application, you often do not have the problems that this approach solves. Moreover, using an elaborate, distributed architecture will slow down development. This can be a major problem for startups whose biggest challenge is often how to rapidly evolve the business model and accompanying application. Using Y-axis is splits might make it much more difficult to iterate rapidly. Later on, however, when the challenge is how to scale and you need to use functional decomposition then tangled dependencies might make it difficult to decompose your monolithic application into a set of services. 

Another challenge is deciding how to partition the system into microservices. This is very much an art but there are number of strategies that can help. One approach is to partition services by verb or use case. For example, later on you will see that the partitioned e-commerce application has a Shipping service that’s responsible for shipping complete orders. Another common example of partitioning by verb is a login service that implements the login use case. 

Another partitioning approach is to partition the system by nouns or resources. This kind of service is responsible for all operations that operate on entities/resources of a given type. For example, later on you will see how it makes sense for the e-commerce system to have an Inventory service that keeps tracks whether products are in stock. 

Ideally, each service should have only a small set of responsibilities. Designing classes using the Single Responsible Principle (SRP). The SRP defines a responsibility of class as a reason to change, and that a class should only have one reason to change. It make sense to apply the SRP to service design as well.

Microservices Architecture best fits

Architecture support Desktop, web , mobile applications etc...

Which companies are using Microservices architecture

Most large scale web sites including Twitter, Netflix, Amazon and eBay have evolved from a monolithic architecture to a microservices architecture.

Why it’s popular

It’s been nearly decade since the concept of Service Oriented Architecture really took hold. With the improvement of RESTful web service and JSON as a data interchange format has made it easier than ever to build easily interconnectable services simply and quickly. 

It's depend upon requirement, normally developers use HTTP/REST with JSON but are free to use any communication protocol. 

Apart from this have flexibility to build services on different languages.

Summary

Hope this post will be help to quick understanding of Microservice architecture.