Microservices with ASP.NET Core: A Next Gen. Technology (Geek to Geek)

Microservice is an application architectural style to build an application that best suits a large complex system. The microservice-based application contains loosely-coupled small independent deployable projects.

Components of Microservice

1) Service Fabric

• Azure Service Fabric is Microsoft’s microservices platform and includes container orchestration as well as developer programming models to build highly scalable microservice applications.
• We can deploy the service fabric platform to Azure, AWS, or on-premise (on Windows or Linux machines)
• 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 locations to the service fabric cluster by ‘Powershell’ CLI or through the service fabric manifest file.
• Service fabric then automatically balances the nodes, if any node goes down it will up another node and host the 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 a 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 the 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 are stored 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 the 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 techniques 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 we need to implement other behavior for a specific event then that case service just needs to subscribe to 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 the Azure service bus to perform asynchronous message-based communication between services there are other tools also available i.e. RabbitMQ, ActiveMQ, etc.

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 the service.
• For instance, if ‘Service A’ publish an event named ‘OrderCreated’ and this event is subscribed by ‘Service B’ then whenever the ‘OrderCreated’ event is 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 the ‘Event Sourcing’ and ‘CQRS (Command Query Responsibility segregation)’ pattern.
• The event bus enabled us to implement an asynchronous messaging pattern thus system can be choreographed properly and we can reduce coupling between services.
• Azure Service Bus can be used to implement this

5) Circuit Breaker

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

• Both techniques are responsible to find the physical location of a particular service in the cluster.
• Whenever any service is up in the cluster it will register its IP address with the service registry. after a particular timespan, a heartbeat signal will be sent to know whether the 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 the service, this mechanism is implemented on top of a load balancer. once the 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, can aggregate responses from various services and send them back 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 a separate gateway for different types of consumers i.e. Web clients, Mobile clients, etc.

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 and Linux machines.

Advantage of having a Microservice-based application

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

Disadvantages

• Limited tooling support is 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

Organizations can streamline development, deployment, and maintenance processes by decomposing complex systems into more minor, loosely coupled services while enhancing flexibility and scalability.

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 eagerly await the opportunity to hear about your project and are delighted to offer our assistance through our expert .Net Core Developers for hire.