I COOKIE CI PERMETTONO DI MIGLIORARE LA TUA ESPERIENZA UTENTE CONTINUANDO A NAVIGARE SU QUESTO SITO ACCETTI IL LORO IMPIEGO 

Martedì, 22 Novembre 2011 18:32

Il servizio di elaborazione in dettaglio

Scritto da

Come la maggior parte delle tecnologie, il servizio di elaborazione di Windows Azure ha fatto progressi dal suo primo rilascio. Originariamente, ad esempio, il codice nei ruoli Web e di lavoro poteva essere eseguito solo in modalità utente. Oggi, invece, entrambi i ruoli forniscono un'opzione di esecuzione con privilegi elevati, consentendo di eseguire le applicazioni in modalità di amministrazione. Questa opzione può essere utile, ad esempio, con le applicazioni per le quali è necessario installare un componente COM, operazione che presentava diversi problemi nella prima versione di Windows Azure.

Tuttavia, ogni istanza in esecuzione di un ruolo Web o di lavoro viene avviata da zero: il sistema operativo sottostante nella macchina virtuale è un'immagine standard definita da Windows Azure. Questo significa che qualsiasi installazione software eseguita dal ruolo deve essere ripetuta ogni volta che viene creata una nuova istanza. Ciò non costituisce un problema per le installazioni semplici, come l'aggiunta di un componente COM. Se invece è necessario installare una varietà di componenti software per supportare le funzioni dell'istanza, farlo ogni volta che viene creata una nuova istanza del ruolo è una perdita di tempo inaccettabile.

Evitare questa perdita di tempo è lo scopo principale dei ruoli VM. Invece di ripetere l'installazione ad ogni creazione di istanze, è possibile includere tutto il software necessario in un VHD, utilizzandolo quindi per creare un'istanza di ruolo VM. Questa procedura può essere notevolmente più rapida rispetto all'utilizzo di ruoli Web o di lavoro con privilegi elevati. Può rappresentare inoltre la soluzione ideale quando il processo di installazione richiede un intervento manuale, non consentito da Windows Azure.

Un altro progresso rispetto alla versione originale di Windows Azure è il supporto dell'accesso tramite Remote Desktop Protocol (RDP). Questo tipo di accesso è utile ad esempio per il debug, in quanto consente agli sviluppatori di accedere direttamente a un'istanza specifica. Non può essere tuttavia utilizzato per l'infrastruttura desktop virtuale (VDI), tecnologia attualmente non supportata da Windows Azure.

Altri importanti aspetti del servizio di elaborazione di Windows Azure sono disponibili fin dal primo rilascio della tecnologia. Ad esempio, Windows Azure permette agli sviluppatori di indicare in quale data center debba essere eseguita un'applicazione e dove debbano essere archiviati i dati, nonché di riunire in uno stesso data center un determinato gruppo di applicazioni e dati, compresi i dati di SQL Azure. Oggi, Microsoft fornisce data center Windows Azure negli Stati Uniti, in Europa e in Asia e altri data center si aggiungeranno prossimamente.

Per far comprendere il funzionamento di Windows Azure, nelle sezioni precedenti sono state illustrate le funzioni fondamentali della piattaforma insieme ad alcuni scenari di utilizzo. Questa tecnologia offre tuttavia molto di più. In questa sezione verranno esaminati in dettaglio alcuni degli aspetti più interessanti.

Creazione di applicazioni Windows Azure

Dal punto di vista dello sviluppatore, realizzare un'applicazione in Windows Azure non è molto diverso dal realizzare un'applicazione Windows tradizionale. Poiché la piattaforma supporta sia applicazioni .NET che applicazioni realizzate con codice non gestito, uno sviluppatore può scegliere in base alle esigenze. Per semplificare il lavoro degli sviluppatori, Visual Studio offre modelli di progetto per la creazione di applicazioni Windows Azure. È anche possibile caricare direttamente le applicazioni da Visual Studio a Windows Azure.

Un'evidente differenza tra la cloud e le soluzioni on-premises è che le applicazioni Windows Azure non vengono eseguite in locale. Questa differenza costituisce una potenziale fonte di problemi da affrontare in fase di sviluppo. Microsoft ha quindi creato allo scopo l'infrastruttura di sviluppo, una versione dell'ambiente Windows Azure eseguibile nel computer dello sviluppatore.

L'infrastruttura di sviluppo viene eseguita in un solo computer desktop o server ed emula le funzionalità che Windows Azure fornisce nella cloud, inclusi i ruoli Web, di lavoro e VM e tutte le tre opzioni di archiviazione di Windows Azure. Uno sviluppatore può realizzare un'applicazione Windows Azure, distribuirla nell'infrastruttura di sviluppo ed eseguirla come farebbe con una normale applicazione in locale. È possibile stabilire quante istanze di ciascun ruolo eseguire, utilizzare code per la comunicazione tra le istanze e svolgere pressoché qualsiasi operazione possibile con Windows Azure. Dopo che l'applicazione è stata sviluppata e testata in locale, lo sviluppatore può caricare il codice e le relative informazioni di configurazione e quindi eseguirla.

In qualunque modo sia stata creata, un'applicazione Windows Azure viene in genere resa disponibile nella cloud attraverso un processo in due fasi. Innanzitutto, lo sviluppatore carica l'applicazione nell'area di gestione temporanea della piattaforma. Quando è pronto a introdurre l'applicazione in ambiente di produzione, utilizza quindi il portale Windows Azure per farne richiesta. Questo passaggio dall'ambiente di gestione temporanea a quello di produzione può essere completato senza tempi di inattività, consentendo l'aggiornamento di un'applicazione in esecuzione a una nuova versione senza alcun disagio per gli utenti.

L'applicazione in fase di gestione temporanea è caratterizzata da un nome DNS in formato <GUID>cloudapp.net, dove <GUID> rappresenta un identificatore univoco globale assegnato da Windows Azure. Per l'ambiente di produzione, lo sviluppatore sceglie un nome DNS nello stesso dominio, ad esempio servizioazure.cloudapp.net. Per utilizzare un dominio personale anziché il dominio cloudapp.net di Microsoft, il proprietario dell'applicazione può creare un alias DNS utilizzando un CNAME standard.

Una volta che l'applicazione è pubblicata e accessibile, gli utenti avranno bisogno di un modo per identificare se stessi. A tale scopo, Windows Azure consente agli sviluppatori di utilizzare qualsiasi meccanismo di autenticazione basato su HTTP. Ad esempio, un'applicazione ASP.NET può avvalersi di un provider di appartenenze per memorizzare il proprio ID utente e la password oppure utilizzare altri metodi, come il servizio Microsoft Windows Live ID. Le applicazioni Windows Azure possono inoltre utilizzare liberamente Windows Identity Foundation (WIF) per implementare l'identità basata sulle attestazioni. La scelta spetta interamente al creatore dell'applicazione.




Anche se le funzionalità di Windows Azure sono molte, un'applicazione potrebbe richiederne solo una. Pensiamo ad esempio a un'applicazione on-premises oppure ospitata che necessiti di archiviare una grande quantità di dati. Un'azienda potrebbe ad esempio desiderare di archiviare i vecchi messaggi di posta elettronica e risparmiare sull'archiviazione senza rinunciare all'accessibilità dei dati archiviati. Un sito Web di news ospitato da un provider potrebbe avere bisogno di una soluzione scalabile e accessibile globalmente per archiviare grandi quantità di testo, immagini, video e profili degli utenti. Un sito dedicato alla condivisione di foto, infine, potrebbe desiderare di affidare a terzi l'archiviazione dei propri contenuti. Tutte queste situazioni sono risolvibili con il servizio di archiviazione di Windows Azure, come illustrato nella figura 13.

 

Figura13: un'applicazione on-premises o ospitata può utilizzare blob o tabelle di Windows Azure per archiviare i propri dati nella cloud.

 

Come accennato in precedenza, un'applicazione on-premises o ospitata può accedere direttamente all'archivio di Windows Azure. Sebbene questo tipo di accesso risulti in genere più lento rispetto all'archiviazione on-premises, è tuttavia più economico, scalabile e affidabile. Per alcune applicazioni si tratta di un compromesso del tutto vantaggioso. Inoltre, anche se non viene mostrato nella figura, le applicazioni possono utilizzare SQL Azure nello stesso modo.

Immaginiamo che, anziché creare una nuova applicazione Web per Windows Azure, un'organizzazione intenda migrare un'applicazione Windows Server esistente su questa piattaforma cloud. Un modo per raggiungere lo scopo è offerto dal ruolo VM di Windows Azure. Questo scenario presenta molte analogie con il caso precedente, come illustrato nella figura 12.

 

Figura12: è possibile eseguire la migrazione di alcune applicazioni on-premises a Windows Azure utilizzando il ruolo VM e SQL Azure.

Per utilizzare un ruolo VM, l'azienda dovrà innanzitutto creare un disco rigido virtuale (VHD) da un computer on-premises in cui viene eseguito Windows Server 2008 R2. L'immagine creata potrà quindi essere caricata in Windows Azure ed essere eseguita all'interno di un ruolo VM. Come illustrato nella figura, l'applicazione può accedere a dati relazionali in SQL Azure. Un'altra opzione consiste nel lasciare i dati on-premises, accedendovi direttamente tramite il servizio di connessione di Windows Azure, come descritto in precedenza.

Il ruolo VM può essere utile, tuttavia è importante comprendere che per eseguire la migrazione di un'applicazione Windows Server in Windows Azure non è sufficiente creare un pacchetto dell'applicazione in un VHD ed eseguirlo in un ruolo VM. Innanzitutto, è bene ricordare che il controller di infrastruttura di Windows Azure presuppone che siano sempre in esecuzione almeno due istanze di ogni ruolo, come previsto dal contratto di servizio (SLA) di Windows Azure, e che Windows Azure esegue il bilanciamento del carico delle richieste degli utenti tra le varie istanze di un ruolo. Se l'applicazione da migrare è stata sviluppata con questi requisiti e, ad esempio, viene già eseguita in una Web farm con bilanciamento del carico, potrà funzionare anche in Windows Azure senza richiedere modifiche significative. Se invece l'applicazione è progettata per eseguire una sola istanza, dovrà probabilmente essere riprogettata per poter funzionare correttamente in Windows Azure.

Martedì, 22 Novembre 2011 18:19

Creazione di un'applicazione Web con dati relazionali

Scritto da

I blob e le tabelle di Windows Azure rappresentano la scelta ideale per alcune situazioni. In molti altri casi sono invece più consigliati i dati relazionali. Supponiamo che un'azienda decida di sviluppare

ruoloWebIstanzadiSQL AzureUtentiNuova applicazione Web con dati relazionali

un'applicazione per i propri dipendenti da eseguire su Windows Azure. L'applicazione avrà probabilmente un ciclo di vita breve o imprevedibile, pertanto non vale la pena di allocare un server nel data center aziendale. Se invece l'applicazione deve essere disponibile nel più breve tempo possibile, attendere che il reparto IT interno effettui il provisioning di un server è una soluzione inaccettabile. O ancora, la scelta di Windows Azure può essere dettata dalla convenienza e dalla maggiore semplicità che, secondo l'organizzazione, questa piattaforma è in grado di offrire.

Qualunque sia il motivo, l'applicazione probabilmente non ha bisogno delle capacità di scalabilità fornite dalle tabelle di Windows Azure. I suoi sviluppatori potrebbero anzi preferire l'approccio relazionale che già conoscono, con strumenti di reporting già noti e utilizzati. In un caso come questo, Windows Azure può essere utilizzato in combinazione con SQL Azure, come illustrato nella figura 11.

 

Figura11: un'applicazione Windows Azure può utilizzare SQL Azure per elaborare i dati relazionali.

 SQL Azure fornisce gran parte delle funzionalità di SQL Server, inclusi gli strumenti di reporting, come servizio cloud gestito. Le applicazioni possono creare database, eseguire query SQL e altro ancora, ma senza alcun bisogno di amministrare il sistema di database, né l'hardware in cui vengono eseguite. Di questo se ne occupa Microsoft. Per accedere a un database SQL Azure è possibile utilizzare il protocollo TDS (Tabular Data Stream), proprio come nella versione on-premises di SQL Server. Ciò consente alle applicazioni Windows Azure di accedere ai dati relazionali tramite meccanismi familiari come Entity Framework e ADO.NET. Inoltre, poiché SQL Azure è un servizio cloud, il costo si basa sull'effettivo utilizzo.

Dal momento che Windows Azure e SQL Azure forniscono equivalenti cloud delle loro controparti on-premises, spostare le code e i dati per queste applicazioni tra i due ambienti può rivelarsi un'operazione semplice e immediata. L'ambiente cloud e l'ambiente on-premises non sono esattamente corrispondenti, in quanto, per fare un esempio, un'applicazione Windows Azure deve essere in grado di eseguire più istanze, ma sono tuttavia simili. Questa portabilità si rivela utile nelle situazioni in cui è necessario creare un'applicazione in cui il codice e i dati possono esistere sia on-premises che nella cloud.

È senz'altro possibile affermare che la grande maggioranza delle applicazioni realizzate oggi offre un'interfaccia browser. Tuttavia, per quanto utili, le applicazioni che non fanno altro che accettare e rispondere a richieste browser sono anche limitate. Esistono molte situazioni in cui il software accessibile dal Web deve avviare attività eseguite in background, indipendentemente dalle richieste/risposte relative all'applicazione.

Applicazione Web scalabile con elaborazione in backgroundBlobCodeTabelleUtentiruolodilavoroIstanzadiruoloWebIstanzadi

Consideriamo ad esempio un'applicazione Web per la condivisione di video. Tale applicazione deve poter accettare richieste dal browser, magari da un gran numero di utenti nello stesso istante. Alcune di tali richieste comporteranno il caricamento di nuovi video, ciascuno dei quali dovrà essere elaborato e archiviato per l'accesso in futuro. Far aspettare l'utente mentre si provvede all'elaborazione del video non sarebbe opportuno. Al contrario, la parte dell'applicazione che accetta le richieste dal browser dovrebbe poter avviare un'attività in background che esegua l'elaborazione.

I ruoli Web e di lavoro possono essere utilizzati insieme in questo scenario. Nella figura 10 viene illustrato un esempio di questo tipo di applicazione.

Figura10: un'applicazione Web scalabile con elaborazione in background può utilizzare numerose funzionalità di Windows Azure.

Come l'applicazione Web scalabile descritta in precedenza, questa applicazione utilizza un certo numero di istanze di ruolo Web per gestire le richieste degli utenti. Per supportare un gran numero di utenti simultanei, utilizza tabelle per archiviare le informazioni sui relativi profili. Per l'elaborazione in background si affida invece alle istanze di ruolo di lavoro, passando loro le attività tramite le code. In questo esempio, le istanze di ruolo di lavoro utilizzano i dati nei blob, ma sono possibili anche altre situazioni.

L'esempio mostra come un'applicazione può utilizzare in combinazione molte delle funzionalità di base di Windows Azure: istanze di ruolo Web e di lavoro, blob, tabelle e code. Inoltre, sebbene non sia illustrato nella figura, un'applicazione di condivisione video può utilizzare la rete CDN di Windows Azure per velocizzare l'accesso. Non tutte le applicazioni necessitano di tutte le funzionalità, ma averle a disposizione è essenziale in scenari complessi come questo.

Pagina 2 di 19