Several of my previous posts have documented some of the challenges and proposed solutions that I’ve encountered whilst migrating our ASP.NET Web API services over to Azure. Here is a summary of the entire journey thus far.
As part of the work involved in delivering the new version of a mobile app to the market, we decided that we wanted to migrate the underlying infrastructure to the Azure platform as it would provide newer, faster infrastructure. This involved two primary objectives.
- hosting the ASP.NET Web API services on Azure
- implementing a service bus architecture with Azure Service Bus
Hosting the ASP.NET Web API services on Azure involved creating an Azure Web Site which would host the services. I subsequently made the necessary changes to the Team Foundation Server 2015 deployments by creating a new release / deployment for Azure. Each time a build is triggered, we deploy the new version to our Azure endpoint. Using Azure for hosting our services ensures maximum levels of availability and scalability, ensuring we can meet not just current demand but future demand too.
Configuring Application Insights to monitor our services is simple. Although our services don’t need to be hosted on Azure to use Application Insights, it is easier if they are. So we have constant monitoring of our services, giving us regular metrics on the health and diagnostics of our services.
Implementing a service bus architecture using Azure Service Bus proved challenging as it requires a mental shift in how you think about services. In traditional service architecture, one service synchronously invokes another service. In a service bus arthitecture, services do not communicate directly with each other. Instead, all requests for services are added to a service bus queue, where they will be picked up and processed by a separate out-of-band service.
All data submitted from mobile devices through the app would be routed to an ASP.NET Web API service that would simply add the request onto the Azure Service Bus queue. This ensured all service requests would be highly responsive as the service was doing nothing more than adding a message to a queue and would be available to service further requests almost immediately. The actual processing of the request was fulfilled by a separate service.
Due to the disconnected nature of service bus architectures, whereby the recipient and client applications communicate via a service bus rather than directly with each other, it is impossible for the recipient application to know when a client application has submitted a request. What is needed is a polling mechanism that will constantly poll the Azure Service Bus looking for new messages. I achieved this using an Azure Function which is bound to the Azure Service Bus listening for incoming messages.
Upon receiving a new message from the Azure Service Bus, the message is processed by a routing service that routes the request to the appropriate ASP.NET Web API. The querystring parameter is used to indicate to the routing service what destination service it needs to be routed to. This ensures that the routing service forwards requests onto the appropriate service endpoints where the necessary business logic is implemented. The routing service also adds a high degree of flexibility for future development.
Using a combination of Azure’s web hosting, Service Bus and Functions I have successfully delivered an end-to-end solution for processing requests from a mobile app which adds significant levels of scalability, resilience and responsiveness. As the chief architect on the project, and deeply involved in the majority of the implementation, as well as all aspects that involved Azure, I feel proud and excited by the results of the project. It has forced me to learn new ideas and technologies and has been a lot of fun.