Introduction
More and more businesses use cloud as a platform for their e-businesses due to its super performance. Microsoft Azure Cloud Active Directory provides perfect identity management platform for web application based information system. Resource groups in Azure cloud can ideally categorize the assets of the business such as the structured and unstructured data which can be stored in Azure cloud and be used for whole business applications.
Azure cloud can hoop the applications from on-premises into cloud. Azure cloud can provide containerization of .NET technology for the next generations of web technology which drive a big change from the traditional web technology. One good example is the ability to scale up the resource backend for high density of client access requests such as over ten millions of users who will login into the system at the same time without impacting the performance.
Azure ASP.NET microservice and service fabric distributed applications are such as new technologies to be used for the future business requirement.
Development
Create a new service fabric project from Visual Studio 2019, select stateful ASP.NET Core web service and API, then click create button as below:
Add a new API controller into the project and update the get and put codes as below:
Build and deploy the solution to the local cluster, see image shown below:
Due to the self-host capability of the ASP.NET core web services, local cluster can work as an IIS web server to manage the web application as IIS web server normally does. Open the cloud explorer as below to browse the cluster.
Click instance in the left pane to get the micro service URL link, see below:
Due to the dynamic URL and port number that changes all the time when the backend service is called, it cannot be called by the frontend microservice which needs a static URL. However, we can copy this dynamic URL to postman and test get and put inside the postman, see below:
In order to enable this backend service to be called by the API client, we need to create proxy URL in API client, this proxy URL can map the URL to this backend service.
We can add many other projects to this web solution such as the frontend stateless ASP.NET Core MVC microservice. This MVC controller can use the proxy URL of stateful backend micro service to consume the data from backend.
So, the method in the stateless MVC controller is the one to pass the request from UI to stateful backend microservice and wait for the response from back end and then parse the response into UI.
The stateful microservice is the replica service that can be copied as a new instance for new front end request. This can allow us to scale up the back end service when the front end needs to handle huge requests.
Front end stateless microservice could trigger a new service in cluster that is copied from the primary backend service. After being copied, this service is taken as a primary for a new client request. Client service therefore can use the new proxy URL to connect to this new backend service.
Service fabric application is composed of stateless frontend and stateful backend microservices. One front end microservice can communicate with many stateful backend microservices, one stateful backend microservice can be communicated with many stateless frontend microservice.
Each microservice is hosted in a docker container inside the node. For example, three docker containers in the example above are created to host two frontend microservices and one dynamic backend microservice. This is the charmed new feature of service fabric application which will allow us to scale up the backend service for the heavy requests from frontend. FOr example, 10000 login users who want to login into the same login page at the same time, the traditional web application only has one or small numbers of backend endpoints to handle such a login, heavy requests so normally can crash those backend. This is not the good practice for the business which needs login page works transparently. Therefore, what we can do is to scale up the backends such as creating more and more backend microservices for this heavy request. If the traffic is changing to low, the backend can be scaled down as necessary. Definitely, the service fabric is the solution.
The local cloud is the Azure Cloud development and test environment. We can register, debug, test, and deploy the developed local application in this local cloud as we did in the real Azure cloud before publishing the application to the production environment. This can save us a lot of resources for Azure cloud programming.
The local cloud actually is a container in which many pods can be created. The default pod contains the seed node which is actually a docker container, this seed docker container can be replicated as required. Inside this pod, each node represents a VM with sharing OS. Each node is used to store stand alone microservice artifacts, see example below:
Here, we can create three docker containers inside default Node0. Those three docker containers exist independently to work with their own domain functions. It means three applications in those three docker containers do not interfere with each other unless we make them work together. This is called the microservice communication, it is the normal case in the real applications we need to handle.
Stateful ASP.NET Core microservice can be created dynamically. The example above has a test7 ASP.NET core microservice replication which is created from the code, see below:
Copying this endpoint URL to postman, we can easily test its get/put functions as example below:
It means this stateful backend ASP.NET Core API microservice can be used to do the CRUD for API client. However, this endpoint URL is dynamic generated, so we cannot use it for API client call. We can create a proxy in API client to map the proxy URL to this dynamic URL via naming server and DNS server in azure/local cloud.
We can create ASP.NET Core MVC as API client as example below:
This client is hosted in another docker container. It has a static endpoint URL. We can call it from the browser as below:
Microservice communication in service fabric can allow frontend communication backend for data manipulation. Stateless ASP.NET Core MVC is a microservice hosted in a docker container as API client which will call the stateful ASP.NET Core API microservice in another docker container. API service endpoint URL is created dynamically so API client will not use it to call it. The proxy URL in API client is used for such a communication, see below.
Stateful ASP.NET Core backend microservice can be scaled up as required. If the “/poll/test7” API does not respond to the requests quickly due to its bandwidth, we need to scale up this backend bottleneck so the requests can be assigned to the replica backend, see the following example:
Here, we create a new method in home controller of API client, when a new query string is passed in, a replica API is created in the backend, see below:
Therefore, thousands of backend microservices can be replicated easily and quickly which is very difficult to do in VM machines for high traffic web applications. It is time for us to show our interests in this area.
History
- 29th May, 2019: Initial version
