17 May Navigating SQL server hosting options in Microsoft Azure
Long pending in my to-do list, but finally managed to squeeze-out some time to follow this passion. I always wanted to share my project-based learnings (I call them PBLs) out to the community for the benefit of others and myself. Sharing this does not mean that I’ve mastered the art, and it has dual purpose:
- Getting feedback (always welcome) to further improve.
- Make it simple for others – deciphering all this took hard work and sometimes I felt giving-up. I’m sure others might be in same boat and looking for similar information.
My first topic (as a topic of interest these days because I am working on it) is SQL Server and Azure SQL (I am by no means a SQL, but rather a Cloud Architect).
I’ll save the complete discovery process, Azure SQL design and migration process for another post as that will take away the focus. What I really want to discuss here is:
- Understanding the confusing number of options (IaaS and PaaS SQL options, service tiers, pricing tiers) – It took me quite some time to understand the overwhelming number of options at my disposal and what’s the best use of each.
- Feature limitations to keep in mind when planning SQL migrations.
- Alternatives to overcome those limitations.
IaaS and PaaS Options:
Azure SQL and Managed Instance Service Tiers (Architectural Models):
Azure SQL and Managed Instance Pricing Tiers:
Feature Limitations and Alternatives
Azure SQL and Managed Instance do not offer the following features out-of-the-box, but don’t worry, there are alternatives available to rescue:
Common language runtime (CLR) is not supported with single or pooled databases, but is supported for a SQL MI. Also, none of the PaaS deployment options support the use of trace flags.
Depending on the type of subscription, SQL managed instance has two default limits per Azure region. These limits are default settings, not technical limitations and can be increased on-demand by creating a special support request in the Azure portal:
*In planning deployments, please take into consideration that Business Critical (BC) service tier requires four (4) times more vCore capacity than General Purpose (GP) service tier. For example: 1 GP vCore = 1 vCore unit and 1 BC vCore = 4 vCore units. To simplify your consumption analysis against the default limits, summarize the vCore units across all subnets in the region where SQL Managed Instance is deployed and compare the results with the instance unit limits for your subscription type. Max number of vCore units limit applies to each subscription in a region. There is no limit per individual subnets except that the sum of all vCores deployed across multiple subnets must be lower or equal to max number of vCore units.
**Larger subnet and vCore limits are available in the following regions: Australia East, East US, East US 2, North Europe, South Central US, Southeast Asia, UK South, West Europe, West US 2.
So what is the right answer for you? That obviously depends on context and requirements. If you are an independent software vendor looking to bring new products and services to the market, you would probably want to utilize the PaaS options delivering infrastructural automation and development velocity. On the other hand, if you are a highly regulated financial institution or public sector entity, you would probably want to explore managed instance or even IaaS. Hope that was helpful to some of you. Please share your feedback / comments that will help me bring other great stuff in future posts.
At Eighty20 Solutions, our goal is to deliver technology transformations in a faster, simpler, and more collaborative manner working with our clients. If you are looking at a cloud journey and are looking at partners who get in the trenches, work shoulder to shoulder with your team, and stay the course, while you help your organisation to sustain long-term, strategic technology investments, embrace change, and realise benefits – as opposed to leaving the teams grappling with shiny new technical debt – reach out to us today!