Containerized Microservice Utilizing Azure Storage, Azure SQL, App Services, Application Insights, Container Registry

Background

In many industries it necessary for a company to store and log documentation submitted from customers for example insurance claims often require documentation associated with a claim.  Other industries with similar requirements include Healthcare and Mortgage/Banking.   

The document storage microservice presented here leverages several Azure platform technologies, Azure App Services and Azure Container Register, Azure Storage for document storage,  and Azure SQL for structured data storage.  Code for the service can be found here. 

System Architecture

The diagram below shows the major components of the service.  

The microservice utilizes several design patterns in order to facilitate code maintainability and reuse.  The repository pattern is used to form the backbone of our data persistence layer.   

The factory pattern is used in the microservice to further decouple the data layer model from the business layer model.   Utilizing this approach allows the business layer logic to be optimized without being tied to the data persistence layer.    This well-known pattern decouples the business logic and the data access layers of the microservice. 

Advantages of Microservices

There are a lot of advantages (and a few disadvantages) to microservices.  On balance for most applications the benefits outweigh the complexities.   Microservices are rapidly becoming the defacto standard for applications in the cloud enabled era.  This is due to the need to be able to efficiently create new business capabilities that are technology stack independent that can be independently deployed and scaled in an always on cloud centric world.    

If you’d like a further backgrounder this is a pretty concise resource.  

https://skelia.com/articles/5-major-benefits-microservice-architecture/

Microservice Controller Layer

The microservice http layer is simply request pass through that contains only request validation.  All business logic is contained in the iDocumentStorageService implementation.  This separation of concerns allows consumption of the business logic by any client.

Configuration of Service Dependencies 

Normally, I would store the configuration securely in a Azure Key Vault, but to keep the demo simpler to setup I have put the environment settings in the docker file.   The configuration settings for the SQL instance and the storage vault or shown below.

For purposes of our demo we will use a single instance container.   Azure provides a native repository that allows storage of docker containers.  

DocumentStorageService

The implementation of this interface coordinates the heavy lifting for our microservice.   This class performs all the business logic for the microservice. 

 The AddCustomerReference method is used to store a new blob in our storage account container and update the datastore with the new customer record. 

An important aspect of utilizing cloud computing is maximizing cost savings.  Our microservice facilitates cost effective document storage by allowing documents to be moved to the archive tier.  This would be used for example when a insurance claim has been paid and all workflows have been completed.  The documents can then be moved to long term storage for regulatory compliance.

BlobClient

Defined by our interface this client abstracts all the operations for accessing data in our Azure Storage Account.   This includes uploading new documents and also moving documents to the archive tier once they are no longer needed.  Utilizing the archive access tier allows us to cost effectively store documents in the cloud.  

DataStorageRepository

Defined by the interface this client abstracts all data access to the Azure SQL Instance.  With this abstraction layer in place we are free to use any data persistence layer that we choose.  For example, we could choose to switch our data persistence layer to Cosmos dB without having any appreciable affect on the other components of the application.

Setting up Service Dependencies

Visual Studio has great support tools for Azure.  This includes support for creating resources in the Azure Cloud.  Now I would not recommend using these functions for managing any production system they are useful for allocating resources for prototyping.   Below shows the dialog for allocating Application Insights.  This capability allows you to create required resources without leaving Visual Studio.  

Once the dependencies are configured and provisioned in the cloud we can finish our deployment process and test our deployment.   The project once deployed will by default bring up Swagger.  This setup is to facilitate demoing the API and should not be the behavior in a production system.