I’ve just got that question from a good friend, and though that I would write up my answer.
The short answer is, use Azure SQL !
If you haven’t heard about Azure SQL, let me explain it. Azure SQL is “SQL as a service”, you’ll get databases deployed in any Microsoft Azure data center that works, looks and feels just like databases deployed on a good old fashion SQL Server(*). But you get the database without having to pay for or install:
- Hardware for Server, storage, backup network..
- Server maintenance
- SQL Server license
- 3rd party backup software license
- Redundancy setup
Paying for Azure SQL is also very simple, you select a performance level, measured in Database Transaction Unit (DTU) and you get the performance. If you need to double your performance for a limited time, you can just select (and pay for) a higher DTU level, and when the need is over, go back to the old level.
A Database Transaction Unit is a artificial measurement composed of CPU, Memory, input and output. If you want to double the performance of your SQL database, you simply upgrade to the double DTU level. Visit this page for more information, and if you want to get the DTU level from your own server, go here.
I start a NAV database out on level S1 (20 DTU), around $40 pr. month. Can you run SQL Server on a physical or virtual server with redundancy and real time backup for $40 pr. month? SQL Server is a very expensive piece of software, and the correct hardware to run it is just as expensive.
And if you want geo replication of your database to a different data center, its just a few click away, and the cost is just another database.
When it comes to backups, Azure SQL has a “down-to-the-minute” 14 days automated backup available – So you can restore a copy of your database from almost anytime going 14 days back. It is possible to transfer backups to and from Azure using a file format called Bakpac (In SQL Management Studio it is know as a import or export a “Data-tier application” – don’t let that fool you, its just a fancy name for backup and restore).
When you have your SQL database in Azure, you have to place the NAV service tier in Azure also – and in the same data center as the database. The service tier must be deployed on a virtual machine. When dealing with modern NAV, network performance between SQL and the service tier has to be high speed. The network performance between the service tier and the client can be lower without causing problems for users.
Installing the service tier in Azure will also ease the access to the system from the new tablet, phones and web clients.
Each vm in azure gets a myname.cloudapp.net DNS name. To run the other client with NAV you will need a HTTPS connection with a valid certificate. The way I usually setup this up, is to create a CNAME dns entry on the customers domains and have that point to the cloudapp.net name. Then you can use IIS on the vm to create a certificate request and install a valid certificate.
Security is also quite simple, you control what IP addresses that can have access to the Azure SQL server/database, in this case, its usually only “Azure Services” (other machines in Azure) plus your local gateway (for admin tasks).
You can control access to the service tier with either a azure virtual network plus VPN or classic firewall setup. If this is a standalone machine in Azure, remember to create it as “Classic vm” to have the simplified endpoints and security model.
“But a server in my basement is much more secure than in the cloud!”
No, it’s not. It may seem that way, but both physical and virtual security is much better in a cloud environment like Azure than a self maintained old-fashion server room. You have state-of-the-art security setup, equipment and 24/7 staff monitoring the entire thing and everything is sitting inside military grade buildings with redundant power and connectivity.
Throw questions at me on Twitter @eHougaard if you feel I’ve left something out.
Small Update
This is in reality the exact same building block Microsoft uses for its new managed Dynamics NAV service.
- Authentication cannot be Windows since the Azure SQL service does not run in your AD (This might chance)
- A database has no concept of “files” and filegroups
- Tables much always have a primary key
