BlogServiceHost.Create()

WCF & Azure - Il blog di Fabio Cozzolino

Recent Posts

Tags

My

Twitter

Community

Archives

Email Notifications

Social Bar Widget

February 2012 - Posts

Dalle WCF Web API alle ASP.NET Web API

Seguo da un po’ di tempo le evoluzioni delle WCF Web API, un framework che si poggia sull’infrastruttura di WCF per renderla meno ostica e facilmente estendibile, ma soprattutto adatta all’utilizzo di REST.

Quando sembrava che le WCF Web API sarebbero finalmente confluite all’interno di WCF 4.5, c’è stato un cambio di rotta: ASP.NET Web API. Le Web API, infatti, si sono sempre trovate in mezzo a due mondi: quello dei servizi (WCF) e quello web (ASP.NET). Il motivo per cui è stato infine scelto di far confluire il tutto in ASP.NET è riassunto nelle parole del comunicato comparso sul sito WCF di codeplex:

Web APIs have a foot in two worlds: the world of service orientation and the World Wide Web. We decided to align ASP.NET Web API with the rest of the Microsoft web platform, so we went with the brand that communicates this alignment. From a technical perspective we also decided to go with a new HTTP specific dispatcher instead of trying to carry forward the WCF dispatcher, so there is virtually no WCF code in the new stack.

Dal mio punto di vista, devo dire che non mi sembra la scelta migliore. Legare il concetto di Web API ad ASP.NET non mi sembra la strada corretta. Che significa? Che devo necessariamente utilizzare IIS? No, in realtà no, perchè posso utilizzare, in quel caso, il canale HTTP di WCF. Questo sembra generare già da ora confusione e i primi discorsi con qualche collega non fanno altro che confermarlo.

WCF ASP.NET Web API, al di là di queste discussioni, sembra promettere diverse cose interessanti e nei prossimi giorni tornerò sicuramente su questo argomento.

Maggiori info le potete trovare qui e ovviamente anche qui.

Nuovi prezzi di SQL Azure

Qualche giorno fa è stata annunciato un nuovo taglio ai prezzi di SQL Azure. Questa la tabella di confronto:

GB

Previous Pricing

New Pricing

New Price/GB

Total % Decrease

5

€35,40

€18,43

€3,686

48%

10

€70,84

€32,66

€3,266

54%

25

€162,94

€53,85

€2,154

75%

50

€318,80*

€89,27

€1,785

75%

100

€318,80*

€124,70

€1,247

65%

150

€318,80*

€160,12

€1,067

55%

Oltre ai tagli, è stata annunciato anche un nuovo database size “entry-level” di 100MB, con un costo fisso di 3,5425 euro al mese. Occhio, però, che il sistema di calcolo non è proprio rigido. Se il nostro DB occupa mediamente 3GB al mese, pagheremo la cifra parziale di 12,753.

Il tutto è ben spiegato nella relativa sezione in questa pagina e che riporto per comodità e completezza:

Database, in base alle dimensioni del database:

Prezzo

Il database di SQL Azure è fatturato in base a una tariffa progressiva basata sulle dimensioni del database. È disponibile in due edizioni: Web e Business. Il database Web Edition supporta fino a un massimo di 5 GB di database relazionale basato su T-SQL. Il database Business Edition supporta fino a una dimensione massima pari a 150 GB di database relazionale basato su T-SQL.


Dimensioni del database Prezzo per database al mese
da 0 a 100 MB Fisso € 3,5425
Maggiore di 100 MB fino a 1 GB Fisso € 7,085
Maggiore di 1 GB fino a 10 GB € 7,085 per il primo GB, € 2,834 per ogni GB aggiuntivo
Maggiore di 10 GB fino a 50 GB € 32,5906 per i primi 10 GB, € 1,417 per ogni GB aggiuntivo
Maggiore di 50 GB fino a 150 GB € 89,2699 per i primi 50 GB, € 0,7085 per ogni GB aggiuntivo
Dettagli fatturazione

Per l'utilizzo di ogni database SQL Azure viene addebitata una tariffa mensile, la quale viene tuttavia ammortizzata sul mese e calcolata su base giornaliera. Per database maggiori di un 1 GB, i costi verranno addebitati nel successivo incremento da un gigabyte. Se ad esempio sono stati utilizzati due database Business Edition, uno da 4,4 GB e uno da 14,4 GB per 1 giorno in un mese di fatturazione, si verrà addebitati per 5 GB e 15 GB di database per tale giorno per un totale di € 1,8745. Di seguito sono riportati i calcoli:

  • 5 GB: (€ 7,085 per il primo GB + € 2,834 per GB per i 4 GB successivi) / 31 giorni = € 0,5944
  • 15 GB: (€ 32,5906 per i primi 10 GB + € 1,417 per GB per i 5 GB successivi) / 31 giorni = € 1,2802

Per maggiori informazioni sui prezzi di Windows Azure:
https://www.windowsazure.com/it-it/pricing/details/#top

Utilizzare il Windows Azure Content Delivery Network

Windows Azure CDN è un sistema che consente di spostare i contenuti dei blobs in un nodo di “caching” geograficamente localizzato in prossimità dell’utente che consuma quell’informazione. In sostanza invece di accedere al datacenter in cui si trova il dato, ad esempio un’immagine, la richiesta viene servita da un altro datacenter.

Sono due i vantaggi che derivano da questo utilizzo:

  1. Miglioramento delle performance perchè il dato è geograficamente più vicino;
  2. Miglioramento della scalabilità, dato che il carico di richieste non grava più su un unico datacenter, ma viene distribuito sui diversi nodi della rete;

I nodi del CDN sono circa 24 sparsi nel mondo, mentre i datacenter di Azure sono 6. Dal punto di vista dei costi, sono identici a quelli degli Storage Services, il che non cambia nulla in termini di “spesa” mensile.

Ma come possiamo utilizzare il CDN? Dopo averlo attivato, se abbiamo scritto bene il codice per recuperare la stringa di connessione per l’accesso ai Blob Services, utilizzando questa sintassi:

   1: CloudStorageAccount account;
   2: account = CloudStorageAccount.FromConfigurationSetting("StorageConnection");
   3: var client = new CloudBlobClient(account.BlobEndpoint, account.Credentials);

praticamente non dobbiamo far altro che modificare la stringa di connessione, anche con la nostra applicazione in produzione, aggiungendo il BlobEndpoint (BlobEndpoint=http://cdn.mycustomdomain.it) che abbiamo assegnato al CDN:

   1: <?xml version="1.0" encoding="utf-16"?>
   2: <ServiceConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" serviceName="" osFamily="2" osVersion="*" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
   3:   <Role name="MyCloudApp">
   4:     <ConfigurationSettings>
   5:       <Setting name="Storage" value="DefaultEndpointsProtocol=http;AccountName=myaccount;AccountKey=ah7ym..z5u==;BlobEndpoint=http://cdn.mycustomdomain.it" />
   6:     </ConfigurationSettings>
   7:     <!-- other settings -->
   8:   </Role>
   9: </ServiceConfiguration>

Giusto il tempo di aggiornare gli le istanze ed il gioco è fatto Smile

Per approfondimenti: https://www.windowsazure.com/en-us/home/tour/cdn/

Windows Azure SDK e Compute Emulator: gestione degli indirizzi locali

Stimolato da un tweet di oggi del buon Giorgio, ho riesumato questo vecchio post che avevo in coda da un po’ di tempo.

Fino alla versione 1.4, il Compute Emulator, l’ambiente di simulazione locale dell’infrastruttura di Windows Azure, non aveva la gestione del Load Balancer e ogni istanza veniva allocata con lo stesso indirizzo IP (127.0.0.1) ma con porte differenti ed incrementali: 81, 82, 83, e così via…

Dalla versione 1.5, invece, al fine di replicare quanto più possibile l’ambiente di produzione cloud, al Load Balancer viene assegnato, se non diversamente configurato, l’IP 127.0.0.1 con la porta 81 (incrementale se già occupata), mentre ai vari nodi l’indirizzo assegnato sarà diverso, tipicamente l’IP 127.255.0.0, con la porta 82 che questa volta sarà sempre la stessa. Quattro istanze, ad esempio, saranno così suddivise:

  Indirizzo Porta
Load Balancer 127.0.0.1 81
Nodo 1 127.255.0.0 82
Nodo 2 127.255.0.1 82
Nodo 3 127.255.0.3 82
Nodo 4 127.255.0.4 82

Questa nuova modalità genera però alcune problematiche negli applicativi che recuperano l’indirizzo IP utilizzando l’HttpRequest e le proprietà come SERVER_PORT o LOCAL_ADDR. In questo caso, ovviamente, la porta e l’indirizzo sono quelle del nodo su cui l’applicativo è in esecuzione.

Per ovviare al problema è sufficiente recuperare utilizzare le proprietà host e port di Request.Uri per accedere ai relativi headers contenuti nella richiesta HTTP, che conterranno i valori corretti del load balancer proprio perchè è lì che viene inviata la richiesta:

   1: HttpRequest request = HttpContext.Current.Request;
   2: var builder = new UriBuilder(request.Url.Scheme, request.Url.Host, request.Url.Port);

Infine per comodità utilizzo un UriBuilder.

Fabio

Posted: Feb 09 2012, 07:48 PM by Fabio.Cozzolino | with no comments
Filed under: