In the spirit of keeping my blogs light and fun (?), the title was an attempt at that. In these interesting times (COVID-19 pandemic) and the need to stay home, I have been doing my share of yard work. It is the time of the year with lots of pollen in the air. As a result, I have been sneezing…a lot. So, for fun, I will say something as I sneeze (doesn’t everyone do that?) Lately, I’ve been saying “Azure” (yes, full-on nerd).
OK, then. I feel better for sharing that.
Before diving in, there’s a similar and associated topic that needs addressing….the pronunciation of Azure.
< A zhr >
Have a listen -> https://youtu.be/YhE-Hm63USY
Here’s another option allowing you to hear both the ’American’ and the ‘British’ pronunciation.
It even provides you the ability to practice!
Follow the link then click on the mouth! -> https://bit.ly/34wltYe
(Click on images to enlarge)
Are you still with me? Are you questioning your decision to read this blog?
Part 1 of this blog series reviewed the different ‘as-a-Service’ models.
In this Part 2, Microsoft Azure SQL Database deployment options are discussed.
What is Azure SQL Database?
Azure SQL Database is a cloud-computing database service provided by Microsoft and its Azure platform. It is a PaaS/DBaaS offering. As discussed in Part 1 of this blog series, DBaaS has its advantages and disadvantages. Those who choose to invest in Azure SQL Database need not install or manage any software or associated hardware. Database patching and version updates are managed for you. Azure SQL Database benefits can also include automated backups, backup retention for up to 10 years, high availability (or, at least, that’s what you pay for), and even offers AI-based tuning to stay ahead of many performance issues. Many people are wary of cloud technology security vulnerabilities. Azure SQL Database can include advanced threat detection and vulnerability assessments.
Since Azure SQL Database was released, it has evolved into a few ‘flavors’.
After all, not everyone wants vanilla…so there are a few deployment options with particular benefits.
Managed Instance – This is a shared set of resources for system and user databases. This deployment option may be/become the most popular of the three. The reason I’m inclined to think this is because it offers the least amount of friction when converting/migrating from on-prem. Microsoft claims that the Managed Instance model is a near 100% compatibility with SQL Server’s Enterprise (on-prem) edition. The enormous benefit of this is that application and database development and configuration changes are kept to a minimum. Microsoft even offers DMS (Data Migration Service) that can automate this “lift and shift” process from on-prem and/or an IaaS implementation to the PaaS deployment. From there, environments can enjoy all of the PaaS benefits (described in Pt 1 of this blog series). Again, these provided services include up-to-date database engine support, patching, managed backups and more.
However, if the BI stack is heavily leveraged in the environment, consider that built-in SSIS, SSAS, and SSRS support requires separate PaaS services.
Single – With the single database deployment option, the database server manages the database with its own resources. This option is ideal for smaller and predictable usage patterns. Each database is isolated and therefore portable. Smaller compute tiers and/or serverless pricing models lend themselves well to Single database and allow for ease of managing costs.
Elastic Pool – When database usage patterns are difficult to predict and/or have larger swings in resource consumption, the elastic pool deployment is the best fit. With this model, resources are allocated to a pool thereby making databases in the pool ‘elastic’. Busy databases can grab resources while the idle databases consume none. Ideal for SaaS development and deployments, there is a decreased need to balance resource provisioning with costs.
In part 3 (of 3) of this blog series, some Amazon (AWS) deployment options will be reviewed.