Overview

Inforiver has been developed with a cloud-first architectural pattern, and it has been designed with cloud-native components itself. Below is an ideal architecture diagram.

Inforiver Ideal Architecture

Please note that all the components shown here won't be deployed. Only the required components will be deployed and others are optional or external.

Core Components

Only the following components will get created and configured in your Resource Group when you are deploying by using the marketplace app.

Azure Web App Service and Plan

This is the API server/backend server for the Inforiver application. This service handles all the APIs triggered from the visual or Add-on app. This instance contains all the business logic and acts as a back-end service and route handler to serve static files like HTML, JS, CSS, and all images for the Inforiver Add-On.

Azure SQL Server and Database

It's a fully managed database-as-a-service from Azure, which acts as an application database. Inforiver stores its data in its database. The data like users, logs, permissions, and visual and report information are some of the data that get stored inside this database. It is recommended not to touch this database or repurpose it for any other use.

Azure Managed Redis

It serves as both a caching server for our application and a queue for our background worker jobs.

Azure Blob Storage

It stores the static files that are uploaded or created from the Inforiver application. It will also act as temporary storage while writing the data to the writeback or scheduler destinations.

Azure Container Instances

It runs multiple containers, which act as background task workers to handle heavy or slow jobs. These containers handle tasks such as sending emails, writing data to final destinations, generating schedule-based reports, and performing data cleanups.

Virtual Network and Subnets

All the Inforiver components will be enclosed in different subnets in the same virtual network. For the management and complete isolation, four subnets have been designed.

Private Endpoints

A private endpoint is a network interface that uses a private IP address from a virtual network. This network interface connects privately and securely to a service that's powered by Azure Private Link. By using these private endpoints, the Inforiver app service can access the database, storage, and other resources securely.

Private DNS Zone

Private DNS zones are linked with private endpoints, and the app service would be able to exchange the private IP address for the provided private endpoint names.

External Dependencies

Azure Container Registry (External): All application code would be compiled and stored in this centralized registry, from where each component will pull its code.

Licensing Service (External): This service will help Inforiver to identify your license information and the features available to you. This will exchange only your license information.

Power BI Service (External): Power BI Service in which the Inforiver visual would be running.

Azure Active Directory Service (External): This service would help us retrieve information from your O365.

SMTP Service (External): This service will help us send emails from Inforiver.

Optional Components

Application Gateway (Optional): Application Gateway connects web applications to the cloud. It provides a web interface so that users can monitor traffic usage and block the unwanted traffic with the help of firewall policies.

Log Analytics Service (Optional): Log analytics will help you to collect logs and offer insights regarding the connected services.

Azure Key Vault (Optional): It helps teams to securely store and manage sensitive information such as keys, passwords, and certificates in centralized storage with industry-standard algorithms. It even has fine granular control for permissions over sensitive data.

You can read more about configuring these additional components from the How-To Guides.