Dime.Scheduler on Azure
Hosting Dime.Scheduler on Azure basically contains the same caveats as hosting Dime.Scheduler on-premise, so there's not a whole lot to tell. In essence, all you really need is an Azure Virtual Machine where you can deploy the web applications and databases.
However, this does not necessarily comply with the best practices of software development. For example, it is recommended to use Azure SQL databases rather than to manage your own database servers and databases. This has many advantages:
- You can scale up and down easily.
- Microsoft automatically maintains, updates and patches the databases for you.
- Performance and availability is almost guaranteed.
- It is cost-effective.
Unless performance is of utmost concern, all nodes can be hosted on a single virtual machine. Obviously, this machine should run a Windows Server image and have some flavor or SQL Server installed. From then on, the installation procedure is exactly the same as on-premise deployments.
To facilitate these deployments, the Dime.Scheduler installer can be used to create Azure resources and install Dime.Scheduler subsequently. By default, the following resources are deployed:
Resource group:
- Azure Virtual Machine
- Network Interface Card
- Public IP Address
- Disk
- Network security group
- Virtual network
- SQL Server (Azure SQL)
- Dime.Scheduler database
- Dime.Scheduler back office
Some of these resources are deployed automatically because other resources depend on it. For example, a virtual machine needs a network interface card, public IP address and disk. If you decide to deploy an Azure Virtual Machine, these are included automatically.
Size recommendations
The recommended size and computing power of the resources may vary a great deal. Some organizations only have one planner, who uses Dime.Scheduler occasionally, whereas other organizations have multiple planners who use Dime.Scheduler quite intensively.
It is therefore difficult to recommend a 'one size fits all' setup. Nonetheless, we will recommend a few common scenarios even though they are merely indicative. One of the most important advantages of the cloud is the ability to scale up and down. It only requires a few clicks to change the size and performance of the resources.
It gets even more complicated when it comes to pricing. Here are a few examples:
- One factor is the subscription type. Pricing may vary if you have a 'Pay-As-You-Go' subscription or an 'Enterprise Agreement'.
- Another factor is whether you bring your own license (BYOL) and can benefit from Azure Hybrid Benefit. Also, if you reserve a virtual machine for a year or three years, prices may drop significantly.
- Azure has 58 regions worldwide. Where you deploy the resources also has an impact on the pricing.
- Each resource type has its own billing mechanism. For example, virtual machines are charged per hour. If you don't turn off the virtual machine; you will be charged. There are ways to handle this and they may reduce the costs significantly.
Azure has a formidable documentation platform. Everything we will write in the next sections has been retrieved from azure.microsoft.com. For more information about virtual machines, click here. For more information about SQL machines, click here.
Development and test
For development and test environments, an A series virtual machine is sufficient 1.
| Resource | Minimum recommended | Maximum recommended |
|---|---|---|
| Virtual machine | A2 | A4 |
| SQL databases | 10 DTUs Basic | 20 DTUs Standard |
For the plugin databases, the requirements regarding the database are slightly lower: a database with 5 to 10 DTUs should suffice.
Lightweight instances
There are many configurations available in the B-series 2. Any configuration between 8 GB RAM and 16 GB RAM should be sufficient.
| Resource | Minimum recommended | Maximum recommended |
|---|---|---|
| Virtual machine | B2S | B4MS |
| SQL databases | 20 DTUs Standard | 100 DTUs Standard |
For the plugin databases, the requirements regarding the database are slightly lower: a database with 10 to 20 DTUs should suffice.
Heavy workloads
There are many configurations in the D series. Any configuration between 8 GB RAM and 16 GB RAM should be sufficient.
| Resource | Minimum recommended | Maximum recommended |
|---|---|---|
| Virtual machine | D*: 8GB RAM / 2 vCPUs | D*: 16GB RAM / 4 vCPUs |
| SQL databases | 20 DTUs Standard | 100 DTUs Standard |
For the plugin databases, the requirements regarding the database are slightly lower: a database with 10 to 20 DTUs should suffice.
SQL Server
To reduce any further hosting and licensing costs, you could opt to run SQL Server on the virtual machine. While we don't exactly endorse it, we understand this decision. The free SQL Server Express can be used to store the data of Dime.Scheduler instead of Azure SQL databases.
Security considerations
Due to the great variety of customer preferences, Dime Software cannot provide an out-of-the-box and watertight Azure setup. While the resources deployed by Dime.Scheduler follow the best practices, they are not necessarily complete or comply with the standards set by the customer. For example, the web server is deployed on a VM that is open to the entire Internet. Understandably, this may be considered as a security risk. Microsoft Azure provides an array of tools and services to secure resources on its platform. In what follows are some considerations that could help you protect Dime.Scheduler on Azure.
Non-cloud-native recommendations
The traditional recommendations obviously still apply. Here are just a few examples that may tighten the protection of your resources on Azure:
- Install a TLS/SSL certificate
- Keep your antivirus software up to date
- Disable anonymous access
- Remove the RDP port (3389) from the VM's firewall rule
- Configure the VM's firewall
- Create and store backups of the SQL server
Azure services and recommendations
Azure Security Center gives a great amount of useful and personalized recommendations. Azure also has a range of services which can be adopted to your needs. Here's a non-exhaustive list of security features which can be considered:
- Azure VPN
- Azure ExpressRoute
- Azure Disk Encryption (for VM)
- Azure Bastion (for VM)
- Azure Backup
- Azure DDoS Protection
- Azure Applicatoin Gateway
- Azure Monitor
- Azure Firewall
- Azure Advanced Threat Protection
- Azure AD Multi-Factor Authentication
Other recommendations
Automatically start and stop virtual machines
To reduce the cost of virtual machines, which usually incur the highest cost, we recommend you use the Start/Stop VM feature. This is a service Azure provides and it automatically starts and stops the virtual machine according to your specifications. For example, you could turn off the machine between 7 PM and 7 AM: that's a whopping 12 hour time span in which you don't pay anything for this virtual machine. However, you will still be charged for resources like the disk, although it is negligible compared to Azure Virtual Machines.
Total cost of ownership
If you want to compare the costs to run Dime.Scheduler on Azure vs running it on-premise, you can do a simulation on the total cost of ownership calculator.
Read more
- As quoted from the Azure docs:"Av2 Standard is the latest generation of A-series virtual machines with similar CPU performance and faster disk. These virtual machines are suitable for development workloads, build servers, code repositories, low-traffic websites and web applications, micro services, early product experiments, and small databases. Like the prior A Standard generation, Av2 virtual machines will include load balancing and auto-scaling at no additional charge."↩
- As quoted from the Azure docs: "Bs-series are economical virtual machines that provide a low-cost option for workloads that typically run at a low to moderate baseline CPU performance, but sometimes need to burst to significantly higher CPU performance when the demand rises. These workloads don’t require the use of the full CPU all the time, but occasionally will need to burst to finish some tasks more quickly. Many applications such as development and test servers, low traffic web servers, small databases, micro services, servers for proof-of-concepts, build servers, and code repositories fit into this model."↩