24

Mar

Windows Azure – SQL Azure pt.1 – Panoramica

Spesso mi trovo a parlarne in giro nei seminari e la quasi totalità delle domande che mi arrivano sono concentrate su questi due punti:

  • C’è uno sforzo di conversione della nostra applicazione esistente per l’utilizzo di SQL Azure?
  • “Come va” con la latenza e la velocità?

Per quanto riguarda il primo punto, intanto bisogna avere ben chiaro che l’applicazione al 90% non andrà modificata. I casi in cui dovesse venire modificata è quando, dall’interno dell’applicazione, si implementano porzioni specifiche per alcune funzionalità del backend database (pattern tra l’altro sconsigliato e da non perseguire) in tale modo che poi, migrando, risulta necessario rimettere le mani al codice.

Se invece il nostro programma utilizza il database nella sua “normalità” la migrazione è indolore. E i casi come questi sono la maggior parte dei casi.

Per la velocità di SQL Azure, inutile dire che lui di per se è una scheggia; il problema banale è legato alla connettività internet lato client, con le più ovvie considerazioni (anche di upstream, di fondamentale importanza).

Ma partiamo dall’inizio

SQL Azure nasce dalla necessità di cloudizzare il database server MS per offrire un sistema di costi più flessibile e per dare la possibilità di scalare prestazionalmente. Inoltre per l’area IT di qualsiasi azienda, la gestione dei database server è sempre un argomento delicato che ha bisogno di strumenti, risorse materiali ed economiche.

Dato che i benefici teorici sono di immediata comprensione, vediamo quali potrebbero essere le topologie di sistemi in cui si renda utile l’inserimento di SQL Azure.

image

  • Code Near: il codice (ovvero l’applicazione fruitrice) è vicina a SQL Azure. Questo avviene solo con Windows Azure al momento ed è l’accoppiata ideale per mantenere applicazioni web sviluppate in ASP.NET + SQL Server, senza teoricamente cambiare una riga di codice. Essendo SQL e Azure negli stessi datacenter o comunque in una WAN geografica ad altà connettività e bassa latenza, le prestazioni sono ideali.
  • Code Far: mi è capitato un paio di volte di implementare questa soluzione che è la più intrinsecamente di valore aggiunto. Infatti con questa soluzione si può far girare qualsiasi applicazione fat sulle macchine client, facendo puntare il database all’istanza di SQL Azure remota. Le considerazioni qui sono molteplici:
    • La latenza? è un problema da considerare.
    • La banda? pure.
    • L’upstream? Assolutamente, essendo un punto non considerato da molti che pensano di migrare a SQL Azure con una ADSL. Sicuramente è fattibile, bisogna però chiedersi quanta banda serva per le operazioni dell’applicazione.
  • Hybrid: nel sistema ibrido ci sono sia l’istanza on-premise che quella Cloud, con la possibilità di sincronizzarle per tenerle aggiornate. Il tutto è ancora in beta quindi ne parleremo con la dovute cautele in un post dedicato.

Ultime considerazioni sul sistema code far: benchè sia opinione di tutti che il codice debba essere scritto bene e gli accessi al database debbano essere ben studiati e ponderati, c’è comunque una stragrande maggioranza di prodotti presenti sul mercato che non si fanno scrupoli a farsi tornare dal DB interi resultset di dati, filtrando la porzione utile via codice. Inutile dire che questo esempio, più tutti gli altri esempi di non-ottimizzazione sul DB, con SQL Azure portano a situazioni fallimentari, dove il timeout di rete farà da padrone anche sulle linee più evolute/veloci.

by Roberto Freato on 3/24/2011
Post archive