If your organization has been considering a move to the cloud, you’ve likely come across diagrams similar to the one below that show who is responsible for managing what in each scenario of Infrastructure as a Service, Platform as a Service, and Software as a Service. This specific diagram is tailored to SQL Server and may give you a better understanding of how management responsibility concepts apply to your on-premises SQL Server infrastructure.
Option 1: Infrastructure as a Service (IaaS)
The decision to simply move SQL Server to an Azure VM (IaaS) may be the most straightforward, but it’s also the option that yields the least benefits from moving to the cloud. Most companies already utilize virtual machines, and a large majority host those in some datacenter where the power, cabinets, cabling, etc., are managed by a vendor. So this type of migration is basically just a move from one datacenter to another with the added benefit of using Microsoft’s Azure Portal to manage the infrastructure going forward. Not to downplay the related benefits, but cloud vendors like Microsoft, Amazon, and Google offer much more in reducing the cost and effort in maintaining IT and data infrastructures.
Option 2: Platform as a Service (PaaS) – Managed Instance
Azure SQL Managed Instance is much like SQL Server installed on a server that you don’t have to maintain. It gives you the ability to scale compute (4-80 vCores with 5GB of memory per) and storage (8TB max) up or down quickly with the click of a button. Because it’s more of a SQL Server Instance than a SQL Server Database like Azure SQL Database, Azure SQL Managed Instance supports common features that resolve issues with migrating to Azure SQL Database, like cross-database queries, linked servers, SQL Server Agent for job scheduling, DB Mail, etc. .
Linked servers are a much-maligned feature that can and should be rectified rather than shifted to the cloud and there are many options in Azure for scheduling jobs, such as Azure Data Factory. But cross-database queries are commonly used for reporting, data integration, and even in the backend processing of many applications that have a multiple database architecture. Elastic Query in Azure SQL DB is not yet a suitable alternative to this capability, in my opinion. There are already vendors like Tibco and Denodo that offer data virtualization tools to overcome this issue, so the hope is that Elastic Query will evolve to something more manageable and efficient.
Option #3: Platform as a Service – Azure SQL Database (Database as a Service)
What you lose by not choosing a true Database as a Service (DBaaS) is the built-in redundancy (including georedundancy or active geo-replication), faster scaling (including autoscaling), automated tuning, and possible cost savings. The Hyperscale tier of Azure SQL Database is actually an entirely different architecture from core Azure SQL, truly designed for the cloud with completely independent compute, storage, and log processing. This allows for storage to scale automatically and the compute to be scaled very quickly. As well, log size and throughput do not impact the SQL engine.
Azure SQL Hyperscale also allows you to create many read-only replicas with no impact on the primary database, which accommodates large, high-speed applications and large, high concurrency analytics. The hyperscale tier can scale up 100TB in size, so it’s a viable platform for many data warehouses that don’t have the true big data attributes of the 3 Vs: Volume in the petabytes, Velocity in sub-second streaming, and Variety of data formats that don’t fit into a relational database.
Determining what works best for you
Microsoft provides a very good toolset for determining which target platforms are compatible with your SQL Server environment. Azure Migrate incorporates several tools for assessing your current environment and providing valuable feedback for planning your migration.
The Azure Migrate hub includes integrated tools:
[wptb id=3124]
Of these, Data Migration Assistant is your best choice to get key information on which Azure SQL platform (Database or Managed Instance) will support a direct migration from your current environment. It will also provide a detailed list of the functionality currently in use that would prevent a direct migration. It’s important to carefully evaluate the output and not take the high-level result of ‘Compatibility Issues’ as a solid indicator that a target platform is not an option. Often, you can have features turned on in your SQL Server environment that you don’t use, or shouldn’t be using.
Movere is a tool that’s used to collect performance data from existing servers over a period of time to determine if right-sizing of servers or databases could achieve cost savings or indicate the need for a target platform that supports autoscaling or higher concurrency levels. The information it provides is helpful in determining the right compute tier to choose for Azure SQL, as well.
Contact Inviso’s cloud migration experts
Inviso has experts in the Azure Migrate toolset who can guide you through installing and running it, evaluating the output, and then building and executing a plan to get you to the right Azure services to fit your current and future needs. Get in touch, we’re here to help! Contact our team at info@invisocorp.com.
