Microsoft Ignite post mortem: la convergenza ibrida sottostante

hybrid-architecture.png

Come ha notato la mia collega Mary Jo Foley durante un’intervista dal vivo a Microsoft Ignite, l’IoT e l’elaborazione intelligente dei bordi hanno prevalso nelle parole di apertura di Satya Nadella all’evento aziendale di Microsoft tenutosi questa settimana a Orlando. Al di là del keynote, l’IA era in primo piano. Come abbiamo notato dai nostri dispacci su Build la scorsa primavera, l’intelligenza artificiale sta guidando le suite di front e back office aziendali di Microsoft, per non parlare di come gestisce il cloud di Azure.

Ma poiché Microsoft sta concentrando sempre più la propria attività su Azure, c’è un messaggio altrettanto importante che viene soffocato dal rumore che, a lungo termine, potrebbe distinguere Microsoft dal gruppo. A differenza di Amazon e Google, Microsoft ha una presenza on-premise e, a suo merito, non ha lasciato che la sua eredità in loco la trascinasse come una palla al piede. Aspira a offrire un’esperienza coerente on-premise e nel cloud. In tutta onestà, questa è anche la posizione a cui puntano tutti i marchi familiari nell’IT aziendale. Il vantaggio di Microsoft è che Azure ha avuto un vantaggio nella costruzione della sua impronta sui cloud IBM e Oracle risalenti al suo punto d’appoggio Office 365.

Gli ultimi annunci provenienti da Microsoft a Ignite su SQL Server 2019 e il database SQL di Azure mostrano quanto sia vicino e quanto lontano sia l’anello di ottone dell’esperienza coerente tra on premise e cloud. Un indizio forte è l’unificazione delle basi di codice tra SQL Server e il database SQL di Azure fornite con le versioni dell’anno scorso. Entrambi erano gemelli separati alla nascita: il database SQL di Azure è stato modellato su SQL Server, ma fino all’anno scorso ha seguito il proprio ramo di codice per supportare un’architettura cloud-native.

Convergenza significa che SQL Server e il database SQL di Azure condivideranno alcune funzionalità identiche, forniranno un’esperienza coerente su funzionalità simili, pur mantenendo le differenze operative relative alla natura fissa dei data center in sede rispetto all’elasticità e alla scalabilità quasi illimitata del cloud.

Entrambi hanno messo insieme storage e calcolo. Ora le differenze si attenuano con il supporto del cluster Big Data di SQL Server 2019 e la nuova funzionalità Hyperscale del database SQL di Azure.

In precedenza, SQL Server richiedeva Hadoop tramite la modalità pushdown di PolyBase. Con la versione 2019, SQL Server ha aggiunto una nuova modalità oltre al tradizionale layout di tabella relazionale: una modalità di scalabilità orizzontale simile al cloud per collocare il motore di database di SQL Server sugli stessi nodi di calcolo di Spark, che a loro volta sono aggiunti ai dati HDFS di Hadoop nodi. Ciò consente a SQL Server di eseguire query T-SQL su HDFS e fornirà supporto Spark nativo come bonus.

Nei cluster di big data, SQL Server 2019 separa il motore di database dai dati, con il motore che si trova nel nodo di calcolo, insieme a Spark. È una topologia molto simile a quella di Impala, il motore SQL-on-Hadoop interattivo open source di Cloudera che posiziona i demoni su ogni nodo di calcolo Hadoop. Il vantaggio di questo approccio è che SQL Server può eseguire query T-SQL su terabyte o petabyte di dati molto più velocemente di PolyBase. Inoltre, avvicina SQL Server a ciò che è possibile in Azure.

Sebbene questa non sia una copia per conoscenza dell’architettura cloud, si potrebbe immaginare un servizio cloud-native complementare dal database SQL di Azure che esegua SQL, o Spark, sui dati archiviati nell’archiviazione BLOB di Azure o ADLS. Si può sempre sognare.

I paralleli cloud per il supporto Hadoop di SQL Server 2019 si estendono ulteriormente alla containerizzazione. Le prime trappole del supporto del contenitore (e di Kubernetes) sono arrivate in SQL Server 2017, ma era limitato alle sandbox TestDev a causa della mancanza di funzionalità di elevata disponibilità/ripristino di emergenza. Con questa lacuna affrontata nella versione 2019, SQL Server 2019 può operare in contenitori Docker orchestrati da scenari Kubernetes High Availability Disaster Recovery (HADR). Si potrebbero immaginare i paralleli con il cloud in cui viene usato Azure Service Fabric per HADR.

C’è un altro elemento che rende l’esperienza di esecuzione di SQL Server come se fosse in esecuzione nel cloud: Azure Data Studio. Conosciuto come SQL Operations Studio mentre era in anteprima, Azure Data Studio questa settimana è entrato nella versione generale. Fornisce un IDE per sviluppatori di database per la codifica di T-SQL o Spark che può essere utilizzato con SQL Server, Azure SQL DB e Azure SQL Data Warehouse da Windows, macOS e Linux. Sviluppi T-SQL o Spark, ma non importa se lavori in SQL Server o nel database SQL di Azure.

Sul lato cloud, il database SQL di Azure introduce una nuova funzionalità di iperscalabilità che enfatizza le differenze tra i database cloud e quelli locali. Come suggerisce il nome, l’iperscala ridimensiona il database, con Microsoft che attualmente rivendica il supporto fino a 100 TByte, almeno per ora. Velocità di rete cloud più elevate in combinazione con il disaccoppiamento di elaborazione, archiviazione e scritture di log rendono possibile l’iperscala.

Hyperscale funziona utilizzando un’infrastruttura di servizi che si basa su un approccio di consenso Paxos per la coerenza ACID. Le transazioni vengono elaborate con il nodo di calcolo primario che scrive i log su un livello di log, recuperando separatamente le pagine di dati dalla cache locale (per i dati più frequenti) o dai server di pagina (per i dati più freddi). Ciò significa che l’iperscala può supportare il tiering dei dati, sfruttando la varietà di opzioni di archiviazione disponibili nel cloud. Il database si partiziona automaticamente per la scalabilità orizzontale, mentre gli snapshot affrontano uno dei grandi ostacoli per i database di transazioni di grandi dimensioni: velocizzare le operazioni di ripristino del database da ore o giorni a minuti. A sua volta, l’elasticità consente di aumentare o diminuire il calcolo per database multi-terabyte in pochi minuti.

La capacità di iperscalabilità del database SQL di Azure fornisce un esempio di come i database cloud e locali possono differenziarsi e imitarsi a vicenda. Nel cloud, l’architettura astratta che separa elaborazione, log e archiviazione è utile per fornire elasticità. Nei locali in cui la capacità di elaborazione e archiviazione è più limitata, le stesse funzionalità potrebbero essere utilizzate per accelerare la manutenzione, i backup e i commit del database se Microsoft dovesse estendere tali funzionalità a SQL Server.

E mentre siamo in tema di estensibilità per l’iperscala, il modo modulare in cui Microsoft ha implementato questa funzionalità potrebbe anche aprire la strada all’estensione ad altri servizi di database relazionali di Azure come MySQL, MariaDB e PostgreSQL. Sebbene Microsoft non stia dicendo cosa farà con l’iperscala in futuro, la nostra opinione è mai dire mai.

Leave a Reply