Moving a Database into Azure: Are We in a Cloud yet?
For most of people moving into cloud means everything stays the same, but the physical server instead of being in the server room at the same building is located somewhere else. That’s why many organisations choose Azure virtual machine with good old SQL Server installed there. Apart for obvious advantage for organisation to be able to tell everybody “we are in the Cloud now”, it gives such benefits as quick and easy hardware growth when it’s needed, simplified business continuity solution and no actual change in human resource area. This is called an Infrastructure as a service (IaaS) solution. Developers and other SQL users won’t feel the difference in using local SQL Server and using SQL Server in Azure virtual machine. There is a small difference for database administrators.
However, Microsoft wants us to use Azure SQL database instead, a platform as a service (PaaS) solution. You can guess it from the amount of benefits and freebies you get. Azure SQL Database has flexible scalability and growth on demand; fantastic business continuity options, full audit at all time, query statistics and index advisor. The most important of that, it’s much cheaper than running a virtual machine (think of how much you are saving on Windows licence alone!). But to use it you need to forget what you have been doing for years and start doing it differently. SQL Server is a very smart box. It knows how to deal with the data, but also it could run a job in time, collect statistics, control user access to different sorts of data and did the data encryption. Instead of that Azure gives you a whole world of services which could be added or removed on demand. Instead of having everything in one basket, Microsoft found a use to old Unix philosophy rebranded under the name microservices. The reason for that is SQL Server as an all-in-one-box has reached its limits.
There is too much data these days. One should be skilled in performance tuning for SQL Server to process hundred gigabytes tables. The alternative is to add more disk space and computing power to the server, and it’s pricey. In Azure this could be resolved with the scheduled tier increase and decrease when needed or shared elastic pools of compute resources for servers that have different peak time. This could help in saving money by paying only for resources that are used. (Thanks Brent for your help in putting the cloudy things straight, see his comment below.)
Some data could not be treated within relational database. Big data platforms were developed to capture and store all of data in any format. Users may want to query and analyse this data alongside with the relational data. In Azure you can keep it all in one place, in your private cloud resource group, so it is easier to find a solution for mixing the data from different sources together.
Azure is full of other cool services and a list is growing. You can easily plug a new service and play with it on your data: parallel computing, machine learning and insights analysis; that’s the names I know.
Microsoft and other Cloud providers are forming the future right now. It all sounds attractive, but also scary as so many unknowns yet. Many of these services don’t have nice interfaces we used to have for years because they are still in development. The first rule of programming is, if it works don’t touch anything. So, while I don’t think there is an immediate need to rewrite perfectly working solutions in cloud services when there is a new project starting soon, there is absolutely no reason for starting it on the platform that very soon becomes a legacy – start your new project in the cloud.