We use the Thinkwise Platform to build massive administrative systems that support companies in their core processes. Not all of these companies have the required expertise when it comes to the management and maintenance of hosting a database and web server. This makes sense, every man to his trade. Yet many companies deploy their software on-premise.

In this blog, we explore various facets of a different approaches on deploying applications on Azure. Managing applications on Azure is relatively easy, as there is no need to worry about the underlying infrastructure or services.

Both database and web servers are easily scalable and exposing the application world-wide is relatively easy. Depending on the scenario, deploying the application on Azure is cheaper than on-premise.

To be clear, we are not talking about Azure Virtual Machines in this blog. Azure VM is an IaaS solution, not much different from hosting at a datacenter. While it does remove the need to worry about the infrastructure and hardware, you still have to keep your web servers running and your database servers healthy.
This blog focuses around deploying the Thinkwise Platform product using the Azure PaaS solutions to deploy the various components:

• App Services
• Azure SQL Databases
• Azure File Storage

A real-life scenario using a more advanced, globally scaled solution will also be highlighted.
 

Azure App Service

Azure App Service is a PaaS solution where you can deploy web applications in the cloud. Think static websites, dynamic websites or an API. There is no need to worry about the underlying infrastructure or web services hosting the web application.

While it is possible to link an Azure App Service to the Active Directory and allow for Windows user logins, IAM users are recommended as this requires no further setup.

We can deploy the Web GUI and Indicium as an Azure App Service.

App Services in Azure

Deployment
To deploy a web application as an App Service, the web application needs to be packaged for deployment. The package will tell Azure on which Azure subscription to run it and how to run it properly.

Any files that would be on disk will have to be deployed together with the package. This process is a bit like how mobile applications are deployed and how it is currently done by the Web GUI or Indicium developers.

Currently, all files in the application model are files on disk and must be packaged. This would be background pictures, icons and report files. For application data, we can use a different strategy. See the section about Azure File Storage.

Applications that require installation of any 3rd party components with the web application cannot be packaged. Because of this, using Crystal Reports as reporting tool is not an option as it requires the installation of merge modules. The same counts for DB2 drivers.
It is possible to deploy Indicium or the Web GUI with installed 3rd party components as an App Service but we’d have to deploy the web application using a Docker container. This is a different approach and deserves a dedicated blog.

Keep in mind that the packaging and deployment process needs to be repeated when a new version of the GUI or Indicium needs to be deployed or when icons or reports are changed.

Azure SQL Database

Azure SQL Database is the PaaS version of a SQL Server database. While there were many limitations in the past, the current version of Azure DB (v12 at the time of writing) supports most features present in the most modern version of SQL Server.

Databases in Azure

Single databases versus managed instances
There are various ways of deploying of Azure SQL Databases.

The most simple option is a single database. Single databases can be deployed together using an elastic pool to share their CPU power and costs. Single databases and databases deployed on an elastic pool can be grouped with a logical server to allow for easier administration.

An alternative with actual functional impact is to host the databases using a managed instance. A managed instance is comparable to a database server. For more information about the difference between single databases and managed instances, see the official documentation.

Single Azure SQL Databases have more limitations compared to a managed instance. The most important thing to keep in mind for these databases is that the database should be as isolated as possible. The database may not reach out to other databases or data sources. You will have to keep this in mind when designing the application.

Deployment
An Azure SQL Database can be deployed various ways. It is important to note that the creation of an empty database is done in Azure. Connecting to the database using the Software Factory is possible to further set up the database.

Alternatively, you can right-click an existing database in SQL Server Management Studio to deploy the database to Azure.

Connecting to a database, logical server or a managed instance is possible via SQL Server Management Studio. IP firewalling can be configured in Azure to ensure the database (server) can only be reached by Indicium, the Web GUI and developers or administrators.

Scaling and pricing
The databases can be scaled when it comes to cpu power, storage and back-up retention. This directly ties into the pricing model.

Customizing the database service level, DTUs and data size in Microsoft Azure Portal. Changes can be made without any downtime.

A dynamic option can be used where you can scale the required performance, storage and back-up retention – the vCore model. Alternatively, fixed performance-packages called DTUs are available with various service levels. These are not available for managed instances.

At the time of writing here in the Netherlands, the lowest configuration you can have for a single database costs €4.21 per month. The highest possible configuration using DTU’s ends at well over €18.000 per month (source).

The price range is quite big — a good performance test is needed to determine the required performance. A minimal proper configuration in the region EU-West with elastic pooling starts at €62,08 per month.

Storage accounts

Azure Storage accounts can be used to store and retrieve various kinds of data. In our case, we need to store files. Storing files is only required if your application has file- or image upload controls.

Storage accounts in Azure. The Thinkwise Platform supports the Files service.

Azure File Storage is configurable in the Software Factory. Files used in products can be uploaded and download to a storage account.

Azure file storage in the Software Factory

To find the login settings to be used in the Software Factory, check the section Access Keys. The storage account name and key 1 values need to be set within the Software Factory as Username / Account name and Password / Access token respectively.

Global deployment

Both Azure App Services and Azure SQL Databases can be easily deployed on multiple geographical locations and linked together.

Using the Azure Traffic Manager, a Traffic Manager profile can be set up which routes incoming requests to a specific App Service. This can be used in various ways to balance load but can also be leveraged to route users based on their location. Users accessing the web application from Indonesia would be routed to the Azure App Service located in Asia.

Using the Azure Traffic Manager and multiple App Services will move the bottleneck from web traffic to database traffic. Having the databases in one geographical location is not ideal in this scenario. Duplicating the databases so they are always geographically close to the App Service is a good solution.

Azure Data Sync can be used to provide synchronization of changes across these databases. Azure Data Sync does not support managed instances at this time.

Global deployment using Azure Traffic manager and Azure Data Sync

Using Azure Data Sync, you can configure which databases need to be synchronized. There is always one main database called the hub. The other databases are members. All synchronization is configured from and to the hub, either one-way or bi-directional. When setting up Azure Data Sync, you can configure which database would win in case of a conflict.

The specific tables and columns that need to be synchronized can be marked. The interval, how often they should be synchronized, can also be configured. Keep in mind that faster synchronization will cause higher CPU usage.

Azure Data Sync requires an extra Azure SQL Database to be provisioned called the Sync Metadata Database. This database is used to store everything Azure Data Sync needs for synchronization. You can use an existing database but this would really mess with further upgrades of this database.
Azure Data Sync can synchronize the schema in addition to the tables. This is not required and very limited. Logic is not synchronized. It is recommended to create the databases yourself.

The hub and other member databases that are subject to synchronization receive a few extra tables in a specific synchronization schema. Tables marked to be synchronized are augmented with triggers that write information about changes to these extra tables. This is picked up by Azure Data Sync.

There are a few requirements and best practices when using Azure Data Sync

• Tables to be synchronized require a primary key
• Changing the values of primary key columns will cause issues
• User-defined datatypes are not supported.
  • This can be mitigated by disabling aliases for all datatypes.
• Upgrades generated by the platform assume the product database matches the previous version exactly.
  • ADS changes the product database, so before running the upgrade, ADS will have to to be removed.
• And a list of best practices

Cost of this set-up
The described set-up was built to work as a production environment.

• 1 App Service (~€65 per month)
• 2 Azure DB’s on an elastic pool with a logical server (~€130 per month)
• 1 Storage account (~€25 per month)

Azure Data Sync – no additional up-front cost. The load the synchronization causes on the databases has to be factored in.

Traffic Manager profile – The costs are based on number of requests. With only the traffic from the load tests, this ended up at a few cents per day.

Running 3 App Services, 6 Azure DB’s + 1 DB for Azure Data Sync, 1 storage account and a Traffic manager in a period with various load tests ended up around ~€800 per month.

Increasing requirements regarding performance, database size and traffic will naturally result in higher costs.

No rights can be derived from the cost estimates in this blog