1️⃣ Die naheliegendste Idee: Lift-and-Shift

Man wähle eines der vorgefertigten SQL VMs auf Azure aus, Backup und Restore der Datenbanken, Änderung des Kompatibilitätslevels – und fertig. In der Realität ist es jedoch nicht ganz so einfach. Netzwerkthemen, Performanceanforderungen und Securityfragen stehen oft einer schnellen Migration im Weg. Dazu muss der Betrieb der VMs, die Hochverfügbarkeit geklärt und auf den Weg gebracht werden. Vorteil dieser Variante: Der SQL Server 2012 kann für weitere drei Jahre mit den sogenannten Extended Security Updates betrieben werden.

Es gibt jedoch auch noch andere Möglichkeiten, die sich mit dem Thema PaaS beschäftigen und sich nicht auf die Infrastruktur konzentrieren:

2️⃣ SQL Server Managed Instance

Aus meiner persönlichen Sicht heraus gesprochen: Oftmals eine sehr gute Wahl, um die Workloads in Azure abzubilden und gleichzeitig von den Vorteilen der Cloud zu profitieren. Mit der SQL MI bekommt man eine komplette SQL-Server-Instanz in der Cloud, die es einem erlaubt, bis zu 100 Datenbanken anzulegen. Ein häufiges Szenario, das man on-prem sieht und somit realisiert werden kann, wären die Cross Database Queries. In den neuesten Service Levels kann man aus bis zu 64 vCores und fast 900 GB RAM wählen – genug für die meisten Anforderungen. Auch der Speicherplatz stellt bei der SQL MI keine Hürde dar: Hier gibt es bis zu 16 TB – ausreichend Platz für eine kleine Datenbank.

3️⃣ Azure SQL DBs

Wenn eine einzelne Datenbank migriert werden soll oder viele kleine Datenbanken, die unabhängig von einer sind, dann lohnt sich ein Blick auf die Azure SQL DBs. Diese sind sowohl als einzelne Datenbanken als auch als Elastic Pools verfügbar. Die Elastic Pools haben den Vorteil, dass sich Spitzen in dem jeweiligen Workload gut abfangen lassen, da der Pool eine gewisse Kapazität für alle Datenbanken in dem jeweiligen Pool bereitstellt. Somit muss vorab nicht stark überprovisioniert werden, um für Sicherheit in den Leistungsspitzen zu sorgen. Eine spannende Variante bei der einzelnen Azure SQL DB ist das Server-Level: Serverless. Sollte die Applikation nur zu gewissen Zeiten ein Datenbank-Backend benötigen, dann ist die Serverless-Variante betrachtenswert. Mit Hilfe der „Auto-Pause“-Funktionalität fallen nur noch Speicherkosten und keine vCore-Kosten mehr an. Optimal geeignet, wenn es sich nicht um ein 24/7-Szenario handelt.

4️⃣ Azure Synapse Analytics

Sollte der SQL Server einem BI-Workload folgen, wäre es zu überlegen, ob nicht die vierte Variante in Frage kommt: Azure Synapse Analytics, ein Analysedienst, der Datenintegration, Data Warehousing und Big Data miteinander verbindet. Gleichzeitig ist Synapse gerüstet für zukünftige Themen wie AI und Machine Learning. Synapse stellt sowohl eine SPARK-Engine als auch 2 SQL-Engines bereit. In der Serverless-Engine ist es möglich, Ad-hoc-Abfragen auf den Data Lake durchzuführen. Dabei fallen lediglich für die einzelne Abfrage Kosten an und nicht pro CPU oder Server oder Ähnliches. Dies ist vor allem für die erste Exploration von Daten interessant. Für den eigentlichen Data-Warehouse-Teil stehen die mächtigen Dedicated SQL Pools bereit, die technisch eine MPP-Datenbank (Massively Parallel Processing) darstellen. Je mehr Daten vorliegen und je besser diese Daten verteilt werden können, umso mehr profitiert man bei Abfragen von derartigen Architekturen.