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

Windows

Windows (135)

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.

Martedì, 22 Novembre 2011 18:13

Creazione di un'applicazione di elaborazione parallela

Scritto da

Le applicazioni Web scalabili sono utili, ma non rappresentano l'unica situazione in cui ha senso utilizzare Windows Azure. Pensiamo a un'azienda che talvolta abbia bisogno di una grande potenza di elaborazione per un'applicazione di elaborazione parallela. Alcuni esempi di applicazioni di questo tipo sono la modellazione finanziaria presso una banca, il rendering di video presso un'azienda di effetti speciali, lo sviluppo di un nuovo farmaco in un'azienda farmaceutica e così via. Sebbene sia possibile mantenere un grande cluster di computer per soddisfare queste esigenze quando si presentano, questa soluzione è anche molto costosa. Windows Azure può invece fornire le medesime risorse quando necessario, offrendo un cluster di elaborazione su richiesta.

Per creare questo tipo di applicazione, gli sviluppatori possono utilizzare i ruoli di lavoro. Inoltre, benché non sia l'unica scelta, le applicazioni parallele normalmente utilizzano grandi set di dati, che è possibile archiviare nei blob di Windows Azure. Questo tipo di applicazione è illustrato nella figura 9.

 

Figura9: un'applicazione di elaborazione parallela può utilizzare un'istanza di ruolo Web, diverse istanze di ruolo di lavoro, code e blob.

Nello scenario illustrato in questo esempio, l'attività parallela viene eseguita da numerose istanze di ruolo Web simultanee, ciascuna delle quali utilizza dati contenuti in blob. Poiché Windows Azure non impone alcun limite di durata per le istanze, ciascuna istanza può eseguire una quantità illimitata di lavoro. Per interagire con l'applicazione, l'utente si affida a una singola istanza di ruolo Web. Attraverso l'interfaccia, l'utente può determinare quante istanze di ruolo di lavoro devono essere eseguite, avviarle e arrestarle, accedere ai risultati e altro ancora. La comunicazione tra le istanze di ruolo Web e di lavoro dipende dalle code di archiviazione di Windows Azure.

Considerato l'elevato livello di potenza di elaborazione disponibile nella cloud, questo nuovo approccio può trasformare le applicazioni HPC (High Performance Computing). Ad esempio, la nuova versione di Microsoft Windows HPC Server consente di creare un cluster di elaborazione utilizzando istanze di ruolo di lavoro Windows Azure in combinazione con o al posto dei server fisici on-premises. In ogni caso, sfruttare questa nuova fonte di potenza di elaborazione offre vantaggi in alcune situazioni.

Torna all'articolo principale

Articolo succassivo

Pagina 2 di 23