microservices

Microservice is application architectural style to build application which best suits for a large complex system. Microservice based application contains loosely-coupled small independent deployable projects.

Components of Microservice

1) Service Fabric

  • Azure Service Fabric is a Microsoft’s microservice platform and includes container orchestration as well as developer programming models to build highly scalable microservice applications.
  • We can deploy service fabric platform to Azure, AWS or on-premise (on Windows or Linux machine)
  • As of now, we can deploy a stateless containerized application to service fabric.
  • The service fabric platform provides features like Naming Service (Service Discovery and Service Registry), Monitoring, Logging, fault tolerance capability, etc.
  • We can add host/virtual machines from different geographic and network location to service fabric cluster by ‘Powershell’ cli or through service fabric manifest file.
  • Service fabric then automatically balance the nodes, if any node goes down it will up other node and host required application instance on the newly added node.

2) Service programming model

  • Stateless Services

    • When we need to persist data to external storage, we will build stateless service.
    • Most of the time we need to store data in external storage (MS SQL, NoSQL storage) so stateless services use most of the time.
    • We can containerize this type of service, as of now we can host this type of service to ‘Docker’ in service fabric.
  • Stateful Service

    • When we need to persist data to service itself, in that case, we can build a stateful service.
    • We can reduce the latency between business logic and data.
    • Stateful services stores through reliable collections to the node itself (In main memory, hard disk)
    • Data will be stored across different partitions to scale and replicate to several nodes to make sure data availability 24X7
    • As of now, we cannot host service to the container but in the future, this feature might be included

3) Communication between services

  • The client application will communicate with service through Rest APIs (HTTP Request/Response) protocol. This type of communication is synchronous in nature, the caller will wait till the response get back.
  • We can follow different technique to communicate between services (communication between services within a cluster)
  • We can communicate between services asynchronously (Using Event Bus – (Service can Publish-Subscribe to a specific event by another service)) wherever possible in case somehow we will not able to communicate asynchronously then we will synchronously communicate between services over Rest APIs.
  • So that way we can reduce the tight coupling between the system and in case if we need to implement other behavior for a specific event then in that case service just need to subscribe that specific event, so that’s the way we can choreograph the system and we can make the system more loosely coupled
  • We can use Azure service bus to perform asynchronous message-based communication between services there are other tools also available i.e. RabbitMQ, ActiveMQ, etc.
If you are not sure whether to choose Asp.Net for the shopping cart application development then read our blog here

4) Event bus

  • The event bus allowed the publish-subscribe style of communication between services.
  • Using an event bus we can establish an asynchronous style of communication between services.
  • Each service can subscribe particular event and whenever any event occurred specified method will be invoked in service.
  • For instance, if ‘Service A’ publish event named ‘OrderCreated’ and this event is subscribed by ‘Service B’ then whenever ‘OrderCreated’ event published by ‘Service A’ this event will be pushed to queue and later it will be processed by ‘Service B’.
  • We can further extend the ‘Event Bus’ to implement ‘Event Sourcing’ and ‘CQRS (Command Query Responsibility segregation)’ pattern.
  • The event bus is enabled us to implement an asynchronous messaging pattern thus system can be choreographed properly and we can reduce coupling between service.
  • Azure Service Bus can be used to implement this
For complete information on business use case application, benefits, and features, kindly refer to our post on “The Ultimate Guide on ASP.NET Core Development”.

Let’s Automate Your Business Process.

Get Started

5) Circuit Breaker

circuite-breaker

  • Many times due to the fault of downstream service the caller system might get collapsed due to all resource exhausted, due to this we might end up the whole system down because of cascade falls down, to prevent this we use Circuit Breaker pattern which works as a switch between caller service and downstream service. if downstream service get time out or return any exception occurred (i.e. HTTP 5XX errors) then switch will be set off
  • To apply the Circuit breaker pattern we use POLLY (http://thepollyproject.org) library.
  • Polly provides features like Circuit Breaker, Bulkhead isolation.

6) Load Balancer

  • The load balancer will route traffic to different nodes to distribute traffics over available nodes.
  • Load balancer first query to Service Registry (Naming Service) to get details of available online nodes. So that it can route traffic to nodes.
  • We can use the Azure Load Balancer service to implement this.

7) Service Discovery and Service Registry (Naming Service)

  • This both techniques are responsible to find the physical location of a particular service in the cluster.
  • Whenever any service up in cluster it will register its IP address with the service registry. after a particular timespan, a heartbeat signal will be sent to know whether service is still alive or not.
  • Whenever any service request comes to the network it will first send a request to the service registry to find out the location of service, this mechanism implemented on top of a load balancer. once load balancer gets the physical location of that node it will redirect a request to that specific node.
  • If we use Service Fabric as our microservice platform, then Service Discovery and Service Registry mechanism will be built in implemented (Naming Service in Service Fabric)

8) API Gateway

  • API Gateway consists of several small projects which act like an aggregator or a proxy to the inner service layer.
  • API Gateway acts as an entry point to the application.
  • There are several benefits of API Gateways like we can implement Authorization, HTTPS termination, we can aggregate responses from various services and send back it to the caller so that they do not need to call multiple services, this will very helpful for mobile clients.
  • We can use API gateway as a backend for the front-end. We do have separate gateway for different types of consumer i.e. Web client, Mobile client, etc.
Do you wish to create a web application for your business or company with Asp.Net? Check this post!

9) Authentication and Authorization

  • We can use ‘IdentityServer4’ or ‘auth0’ or ‘octa’ for authentication and authorization purpose.
  • IdentityServer4 is a community-driven project which offers features like Single Sign-on, Refresh token, token-based security, one can revoke generated token, Support External Identity provider (Google, Facebook), Admin UI (in beta version) for user management, etc.
  • Built on top of .NET Core so we can deploy it on both Windows or Linux machines.

Advantage of having Microservice-based application

  • Each service is relatively small, so it is easier to maintain code and reduced build time
  • We can add more feature in less time compare to monolith application
  • Each service can be deployed independently, we can do releases more aggressively
  • Easy to scale (Horizontal scaling)
  • Different technology stack can be used in different services

Disadvantages

  • Limited tooling support available to deal with complexity in microservice-based application
  • Difficult to create a testing environment
  • Memory/bandwidth consumption will be increased
  • There is no support for transaction
  • One should have the domain knowledge to break functionality into individual service
  • Must have a deal with problems of a distributed system
  • Performance might be reduced
  • Not suitable for small application

Conclusion:

Evince Development – a Full Stack Development Company feels grateful to have been attached to a diverse range of ASP.NET projects to which we have given our everything and attained a 97% project success ratio in delivering ASP.NET development services. We are always keen to listen to your project and glad to assist you with our Hire Expert .Net Core Developer.