Il presente articolo è stato tradotto automaticamente.

Previsioni: Nuvoloso

Analisi dell'architettura cloud

Joseph Fultz

 

Ho deciso un po ' indietro che almeno uno dei miei articoli coprirebbe considerazioni di carattere architettonici generale e alcuni disegni ad alto livello per la creazione di soluzioni basate su cloud di base. So da tutte le sessioni ho presentato al o frequentato che se un pubblico tecnico non arriva a giocare con qualche codice, non le sessioni sono di solito ben accolta. Ma sto sperando che questo articolo trarranno beneficio gente almeno aiutando a inquadrare e dare alcuni obiettivi fondamentali per il loro pensiero sull'architettura della soluzione.

Sarò con piattaforma come servizio (PaaS) — in particolare, Windows Azure — come la bacheca contestuale su cui appendere le idee e considerazioni, ma le idee desidera comunicare, dovrebbe valere anche per infrastrutture come un servizio (IaaS) e il Software come servizio (SaaS) con la traduzione poco. Mi sottolineare alcune delle considerazioni fondamentali di progettazione, quando si crea una soluzione nube, categorizzare gli strumenti della piattaforma che Windows Azure fornisce, illustrare alcuni disegni base e fornire una matrice di decisione per la selezione del vostro stile di progettazione.

Considerazioni di nube

Gli architetti e gli sviluppatori stagionati potrebbero entrare in un'abitudine di identificare alcune caratteristiche del problema, corrispondente a un criterio e pronunciare un disegno. Ho intenzione di evidenziare alcuni disegni tipici per le soluzioni di cloud, ma io incoraggiare altamente prendendo un approccio attivo per risolvere i problemi contro usando solo una taglierina del biscotto della partita precedente di soluzioni che sono state cotte fino di. L'approccio migliore è quello di progettare una soluzione ideale e quindi avviare la sovrapposizione di condizioni che aggiunge la nuvola e condizioni dell'ecosistema aziendale. Aggiungerli uno alla volta e risolvere eventuali problemi associati, perché proprio come matematica o il debug corretta, se si aggiungono troppe variabili, si ' ll introdurre errori la cui origine non può essere facilmente accertata.

Che cosa significa per la progettazione di una soluzione"nube?" Voglio iniziare con una forte enfasi che un ruolo Web Accodamento messaggi a un ruolo del lavoratore e poi raccogliendo il risultato fuori una coda di ritorno non è lo stile di definizione della nube. In realtà, per quanto riguarda molti, usando tale architettura come base da cui partire per lanciare un disegno potrebbe infatti ridurre il beneficio complessivo di un'implementazione di nube. Come infrastruttura cloud privato diventano facilmente disponibile, offusca la linea tra nube e nube non perché il fattore delineating non è la posizione. Dunque la messa a fuoco per la differenziazione deve essere su ciò che si fa piuttosto che quello che è o dove è.

Qui ci sono le cose che utilizzando Windows Azure come mezzo di ospitare il mio Web o applicazioni di servizio non fa per me:

• Mi libera dalla acquisizione di infrastrutture, installazione o gestione
• Mi libera dalla limitata capacità; capacità di calcolo e di archiviazione sono disponibili su richiesta
• Mi libera dal costo del capitale ripida e libera me per regolare il costo basato sul consumo

Non voglio banalizzare esso, ma questo è tutto; nessuna necessità di complicare. In effetti, ci sono un sacco di funzioni non banale all'interno della piattaforma nube, ma quelli non sono che cosa differenziare la nube da una soluzione ospitata più tradizionale. Singole funzionalità (Accodamento messaggi, memorizzazione, archiviazione strutturata e così via) che vengono aggiunti per una piattaforma, come ad esempio Windows Azure — po ' nuovo per la piattaforma — non sono fondamentalmente nuova capacità di software che non erano disponibili prima. Le sfide affrontate direttamente con lo spostamento della nube sono elasticità di elaborazione e archiviazione e spese di capitale, insieme con cura in corso e l'alimentazione dell'infrastruttura hardware. Questa è una buona notizia per chi progetta software perché significa disegni e modelli per lo più rimangono gli stessi, con un piccolo extra enfasi su due considerazioni: costo e latenza. Certamente questi due preoccupazioni erano importanti prima, ma la nube cambia l'equazione abbastanza da richiedere un'attenzione speciale.

Il fattore di costo

Come molti di voi già condito da implementazioni nube so, esso non è sempre più conveniente. Fortunatamente, l'efficienza di costi non equivale a buon mercato o anche gratis. È possibile determinare il costo per essere efficiente quando l'equazione non può essere modificato per ridurre i costi senza ridurre anche la funzionalità o servizi — che significa che non non c'è nessun costo di sopra e di là di ciò che necessariamente è consumato. Non c'è dubbio che ci sono dei costi le ottimizzazioni per un'impresa che il passaggio da un datacenter privato a un insieme delle soluzioni basate su cloud, ma per davvero vedere quel beneficio, ci deve essere un'affinità verso principi guida: uno spostamento verso soluzioni prima nube e design per l'ottimizzazione dei costi.

Ci deve essere uno spostamento verso la nube di calcolo e lontano dallo scenario di hosting privato. È difficile capire i costi benefici di hosting nella nube, mentre c'è inutilizzata o sottoutilizzate infrastrutture disponibili a consumare che è già stata acquistata ed è a posto. Così, come sistemi età o nuovo software arriva a bordo, dovrebbe guardare a nuvola prima invece di comprare più larghezza di banda delle infrastrutture. Ci sono momenti quando possedere il datacenter è infatti più conveniente, ma per la maggior parte delle aziende che non è la realtà. Tassi di contratto e di massa da parte, in genere il più vicino si arriva a costo basate sui consumi, più vicino si arriva a un modello di costo efficiente.

Con il primo passo, il passo successivo è garantire che non sei un mangione nube. Ogni applicazione deve essere progettato intorno ottimizzazione per costo. Mentre il primo punto è spesso difficile dal punto di vista aziendale, il secondo punto può essere una dolorosa pillola di inghiottire in un disegno tecnico. Ecco perché ci saranno momenti quando progettazione per ottimizzare il costo significa metterlo di fronte le prestazioni o l'eleganza. Di solito trovo che creazione equilibrio tra prestazioni ed eleganza è dove trascorrere un bel po ' del mio sforzo, ma buttare l'ottimizzazione dei costi nella foto e diventa ulteriormente complicata trasformando il mio problema 2D in un 3D uno.

Ottimizzazione costi significa essere minuziosamente conoscenza di quanto segue:

• Entrata e l'uscita, fino al consumatore finale e alla colonna vertebrale aziendale
• Il criterio di conservazione per i dati in archiviazione in modo da non utilizzare spazio non necessario
• Come responsabilmente scalabilità verticale e giù le risorse di calcolo

Se un disegno prende in considerazione queste tre considerazioni, è sicuramente muovendo nella giusta direzione.

Il fattore di latenza

Tradizionalmente, latenza diventa un problema quando le informazioni che devono essere notificate all'utente finale è presente in uno o più dei seguenti stati:

• Esso è in un sistema legacy o altrimenti vincolato
• Esiste tra sistemi e devono essere aggregato in primo luogo
• Esso richiede uno o più trasformazioni prima di essere consegnata all'interfaccia utente
• Esiste di fuori dell'impresa e deve essere recuperato in remoto

Per una soluzione basata su cloud, tutti questi elementi potrebbe essere vero, ma è l'ultimo elemento che si applica senza eccezione per la progettazione di soluzioni enterprise per la nube. Certamente le altre voci sarà probabilmente fattori pure, ma una verità universale per le imprese è oggi che dati dovranno essere in qualche modo sincronizzate tra le soluzioni di nube e gli archivi di dati aziendali nel datacenter casa.

Occuperò di alcuni modi di integrazione di dati nei disegni base ho impostato avanti qui, ma si tratta davvero di due strategie principali: sincronizzazione dati e chiamate di servizio in tempo reale ritorno a casa.

Struttura di alto livello

Pensando alla generalizzazione del design per soluzioni enterprise, uno può di solito grumo ciascuno degli ingranaggi grandi in una di queste categorie:

• Calcolare
• Memoria
• Integrazione

Questo è come io sarò categorizzare le funzionalità della piattaforma Windows Azure in questo contesto. Griglia in Figura 1 mostra un sottoinsieme delle funzionalità di piattaforma Windows Azure.

Figura 1 piattaforma Toolbox categorie

Windows Azure	Calcolare	Memoria	Integrazione & Servizi
Calcolare	Ruoli Web
	Ruoli del lavoratore
	Ruolo di VM
Memoria		Archiviazione BLOB	Archiviazione di coda
		Tabella di archiviazione
Ex AppFabric			Servizio Bus
			Connetti
			Controllo di accesso
			Cache
SQL Azure		Database di
	Creazione rapporti
			Sincronizzazione dati azzurro SQL

Concentrarsi sui grandi mattoni di elaborazione, archiviazione e integrazione, si possono facilmente mettere insieme alcuni disegni base da cui partire per iniziare ed espandere o addirittura ricombinare, come mostrato nella Figura 2.

Figura 2 disegni di alto livello base**

Mentre i disegni mostrati in Figura 2 non sono rappresentante di tutte le permutazioni possibili sono più grandi blocchi di design che hanno il loro scopo:

• Diretto accesso ai dati: Questo è di solito l'implementazione più elementare dove l'interfaccia Web front-end non solo accede ai dati direttamente ma porta anche l'onere di tutto il lavoro.
• Riferimento indiretto di servizi: Questo è un disegno di architettura orientata ai servizi (SOA) che è il prossimo livello di riferimento indiretto e bilanciamento del carico di lavoro, accesso e business logica dei dati fuori dei ruoli che serve l'interfaccia utente in movimento. Un buon disegno SOA può non solo ridurre la fragilità della soluzione, ma anche di ridurre il carico sul back-end e ottimizzare le risposte dei dati al client.
• Riferimento indiretto di coda: Lavoro è scaricata ai lavoratori di sfondo tramite Windows Azure archiviazione delle code. Questo è un primo passo a ottimizzare il carico di lavoro, ma è generalmente indicato quando il risultato del lavoro scaricato è accettato come non richiedono tempo quasi risposta al client.
• Servizio Bus integrazione: Aggiunta in un impianto pub/sub all'infrastruttura di servizi può aumentare realmente un design SOA spostando il livello di riferimento indiretto lontano dagli endpoint e muovendo verso argomenti di interesse. Questo disegno può fornire l'implementazione più flessibile.

Corporate Design Backplane

I disegni base non affrontano il backplane azienda appositamente. Due dei pezzi più importanti di una soluzione Windows Azure sono come si collega ai sistemi aziendali che contengono la logica di business proprietarie e come accede ai dati aziendali. Ci sono alcuni disegni base per il backplane aziendale utilizzati da soli o in combinazione, come i disegni precedenti, come mostrato nella Figura 3.

Figura 3 disegni aziendali Backplane Basic

Un modo base per collegare le soluzioni nube al vostro ecosistema azienda è semplicemente utilizzare Windows Azure Connect come discusso da Anna Skobodzinski, uno dei miei colleghi da Microsoft Technology Center (MTC) a bit.ly/wnyqj9. Questo è raffigurato nel disegno in stile VPN Figura 3. Il sistema può essere utilizzato come è, ma con una tassa di circa un secondo. Inoltre, sarà la pena fare qualche lavoro prima del tempo per assicurarsi che i sistemi di essere esposti alle applicazioni nube sono pronti per il carico aggiuntivo. Se ne avete bisogno in fretta, la nube è una grande soluzione; Se avete bisogno in fretta e deve integrare con interfacce esistenti, integrazione VPN stile potrebbe essere il modo più semplice e rapido per mitigare il rischio per la tua timeline.

Il tipo più comune di integrazione che mi imbatto in è il tipo raffigurato sotto Style di integrazione dei dati. Ciò richiede alcuni mezzi di sincronizzazione dati in entrambe le direzioni. Ci sono numerosi modi per fare questo, ciascuno con una propria serie di Pro e contro. Utilizzando un estratto, trasformazione e caricamento (ETL) strumento come SQL Server Integration Services (SSIS) è probabilmente la più bassa barriera all'ingresso per la maggior parte. SSIS come mezzo per sincronizzare i dati dispone anche di un ecosistema molto maturo per il monitoraggio e la gestione. Il meccanismo più semplice successivo è quello di utilizzare SQL Azure dati Sync, che è attualmente disponibile in anteprima (bit.ly/p14qC6). Esso è basato sulla tecnologia Sync Framework che ho ricoperto nel mio gennaio 2011 (msdn.microsoft.com/magazine/gg535668) e il febbraio 2011 (msdn.microsoft.com/magazine/gg598920) colonne. Ciò richiederà alcune modifiche alle tabelle di sincronizzazione. Metodi Sync Framework sia SSIS, è una buona idea per fare in modo di muoversi solo i campi di dati che sono necessari tra nube e locali aziendali. Non muovendosi dati inutilmente, il costo di ingresso, uscita e l'utilizzo di archiviazione nube globale può essere mantenuto.

Avanzare un po' ago e prendendo alcuni dei lavori dal back-end database è lo stile di servizi diretti mostrato in Figura 3, dove i dati necessari da sistemi aziendali viene recuperati attraverso un insieme di servizi esposti. I due grandi pregi qui sono che il costo del trasporto dei dati viene rimosso e i dati siano sempre correnti. Meno positivamente, e introdurre la latenza e mettere sforzo supplementare su sistemi che potrebbero non essere pronta ad essere incorporati in una soluzione di nuvola. Esso implica anche che la maggior parte di intelligenza deve vivere nei sistemi aziendali e servizi, come avrà la maggior parte dei dati da analizzare.

L'ultimo dei quattro modelli in Figura 3 viene illustrato l'utilizzo di un servizio di bus per integrare la nuvola e dei sistemi aziendali. Questo servizio Bus stile comporterebbe che entrambi i ruoli di nuvola in esecuzione e i sistemi aziendali pubblicano e sottoscrivere dati ed eventi che sono rilevanti per ciascuna di esse. Questo ha circa lo stessi Pro e contro, come lo stile di servizi diretti di architettura, con l'ulteriore vantaggio di massima flessibilità per la creazione di nuovi editori e consumatori di informazione.

La matrice di decisione è uno strumento per aiutare a identificare potenziali aree problematiche quando si considera l'uso di uno degli stili di progettazione di base rispetto ad un altro. La matrice di decisione in Figura 4 non è un assoluto, ma piuttosto riflette la mia esperienza di lavoro con la gente sull'architettura della nube. Ci non è necessariamente un chiaro vincitore, e in molti casi una vera e propria progettazione includeranno alcuni mix di questi elementi. Ad esempio, uno potrebbe distribuire una nuova applicazione Web che include un set di servizi REST lavorando contro un database back-end che è sincronizzato tramite un ETL eseguire due volte al giorno. Figura 5 mostra un esempio di tale progetto combinato.

Figura 4 decisione Matrix

Esempio di figura 5 combinato Design

Inoltre, c'è un insieme di risorse basato su file in Windows Azure Storage utilizzata dal sito e viene mantenuto in sincronia con un'implementazione personalizzata di Sync Framework. Questa struttura di alto livello è il risultato finale di raccolta di informazioni e di fare alcuni informato congetture, ma è solo l'inizio dei lavori. Esso fornisce la destinazione per il design di fine e implementazione ma lascia un sacco di dettagli da destinarsi (ad esempio la memorizzazione nella cache, controllo accessi e così via).

Design e l'efficienza di costi

Ho provato a prendere in giro e identificare le considerazioni più importanti durante la progettazione di una soluzione di nuvola — in particolare, uno ad essere incorporati in un'impresa esistente. Speriamo che, bollendo fuori la pletora di caratteristiche e funzionalità un po', aiuta per cancellare il percorso per il design. Il vero trucco per progettare una soluzione nube è di prendere una soluzione ideale e rendere efficiente il design mentre ancora compreso l'efficienza di costi. Come il movimento nube mette a livello enterprise computing portata di chiunque abbia voglia di appoggiarsi sopra e capovolgere l'interruttore, l'eleganza nel design rappresenteranno per costo a consumo.

Toccato un Web design base e un disegno di integrazione aziendale della base, ma ha lasciato tutti i dettagli per un futuro DrillDown; semplicemente ci vorrebbe troppo spazio a coprire in una sola volta. Perché questa è l'unica colonna ho scritto che si concentra esclusivamente sulla progettazione e non ha alcuna implementazione associato con esso, spero che sarà utile. Se voi voleste drill-down in alcuni dei pezzi di progettazione di dettaglio, per favore commento su questo articolo su msdn.microsoft.com/magazine.

Joseph Fultz è un software architect in Hewlett-Packard Co., lavorando come parte del gruppo HP.com Global IT. In precedenza è stato un progettista software per Microsoft, lavorando con la sua impresa di alto livello e i clienti ISV definizione di architettura e soluzioni di progettazione.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: George Huey