La tappa di Bari dei Community Days è ormai alle porte, manca poco meno di una settimana a quello che sarà sicuramente un evento da ricordare. Due giorni con quattro track e diversi speaker e autori di libri riconosciuti a livello nazionale ed internazionale come non si era mai visto dalle “nostre parti” 
.
L’agenda è bella ricca e densa di sessioni interessanti. Parleremo non solo di Windows Phone e di Azure, ma anche dell’imminente Windows 8 e di come cambierà il nostro approccio allo sviluppo di applicazioni. A completare il tutto ci saranno anche i lab in parallelo.
Se non vi siete ancora iscritti, fatelo perchè ne varrà senz’altro la pena.
…di Bill Laing e del team di Windows Azure. In questo post viene riportato un dettagliato report di quanto è successo, con spiegazioni tecniche del perchè è successo e di quelli che sono stati i passaggi fatti per risolvere il problema (anche gli errori).
Ad ogni modo, questa frase descrive la natura del bug:
The leap day bug is that the GA calculated the valid-to date by simply taking the current date and adding one to its year.
Chiaramente il 2013 non è bisestile e il 29 febbraio non esiste…
Il post si conclude con “abbiamo imparato la lezione, ora miglioriamo il servizio così…”. Davvero interessante anche dal punto di vista tecnico ed operativo.
Dopo i tagli ai prezzi dello Storage dello scorso ottobre, passati da $ 0,15/GB a $ 0,14/GB, e la recente rivisitazione della politica dei prezzi di SQL Azure, da ieri 8 Marzo sono stati annunciati, e subito attuati, tagli per circa il 12%.
Si passa quindi da $ 0,14/GB a $ 0,125/GB che in euro è € 0,0887/GB, con un risparmio quindi importante. In realtà la revisione è ben più articolata e, seguendo uno schema simile a quello di SQL Azure, è inversamente proporzionale rispetto alla quantità di dati utilizzata.
Ma non basta. Un altro taglio del 50% riguarda la Extra-Small Instance che passa ora a € 0,0142.
A questa pagina trovate tutti i prezzi in euro aggiornati.
"Rimbalzo" la notizia dal blog di Nino Crudele che segnala l'uscita della nuova release del Service Bus Explorer, il tool scritto da Paolo Salvatori che permette di gestire e testare il proprio Service Namespace.
A questo link potete trovare l'articolo completo che ne spiega ampiamente le funzionalità.
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.
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
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:
-
Miglioramento delle performance perchè il dato è geograficamente più vicino;
-
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 
Per approfondimenti: https://www.windowsazure.com/en-us/home/tour/cdn/
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
Non è molto pubblicizzato, ma leggere che l’Access Control Service è in promozione a costo zero fino al 30 Novembre 2012 (un anno!) è davvero una grande notizia. Dal primo dicembre il prezzo sarà di circa 1,44 € per 100.000 transazioni, quindi non una cifra esorbitante 
.
Per chi non lo sa, l’Access Control Service è un servizio che permette di realizzare meccanismi di autorizzazione e di Single Sign-On in maniera molto semplice, immediata e facilmente integrabile in applicazioni claim-based.
Maggiori info qui.
Sono giorni di fermento per la piattaforma Windows Azure. Sono infatti state rilasciate ieri importanti novità. Finalmente qualcosa si muove sul fronte "limiti di utilizzo". E' stato infatti introdotto lo Spending Cap, un limite che permette, a chi sottoscrive un abbonamento trial o attiva il benefit all’interno di MSDN, di definire un tetto di spesa massimo. Se impostato a zero, valore di default, il servizio verrà immediatamente "spento" al suo raggiungimento. Chiaramente si tratta di una feature utile a chi vuole provare Windows Azure senza rischiare di trovarsi addebitate spese che possiamo definire... "non previste" :).
Le novità riguardano anche una maggiore integrazione con l'OSS, tramite il rilascio di nuovi SDK per Java e Node.js, nonchè il supporto per Hadoop, Memcached, Solr/Lucene e MongoDB.
Non entro nel dettaglio di ogni singola feature, Fabio ha già scritto un post ben dettagliato, ma ancora una volta si conferma come la piattaforma Windows Azure sia davvero in continuo movimento ed in perenne evoluzione. Il suo largo utilizzo consente di abbatterne i costi. Come già avvenuto per lo storage qualche mese fa, ora anche SQL Azure beneficia di un ulteriore abbassamento del pricing.
Questo il post ufficiale.
Riprendiamo gli appuntamenti DotNetSide con un workshop tutto dedicato alle novità su HTML5, Kinect SDK e soprattutto Windows 8.
http://dotnetside.org/content/FutureDevelopmentDay.aspx
Vi consiglio di non mancare perchè ne vedremo davvero delle belle.
Ci vediamo il 14 ottobre al Rondò Hotel.
Sabato prossimo, 24 settembre, avrò il piacere di partecipare come ospite ad un evento un po’ particolare:
l’History Tech Day - Comunicando, da strumenti di calcolo a strumenti di comunicazione. Organizzato dalla community DotNetCampania e da Microsoft, all’interno di un percorso più ampio che terminerà il 2 ottobre, ha come tema principale la storia dell’informatica.
Ovviamente io parlerò di Cloud Computing e in generale del mondo delle applicazioni distribuite, del modo in cui l’evoluzione informatica ci
ha condotti ad avere piattaforme, ad esempio, basate su Windows Azure. Non mancheranno, quindi, cenni storici e case history.
Il “parterre” è d’eccezione dato che interverranno, dopo l’introduzione del prof. Michele DI SANTO, Michele Aponte, Massimo Bonanni, Roberto Freato e Giorgio Garcia-Agreda.
L’evento si terrà ad Avellino a partire dalle 09:00. Per partecipare potete registrarvi qui.
Vi aspettiamo 
What’s New in SQL Azure Management Portal? (Part II of II)
E’ stata rilasciata ieri una nuova versione di SQL Azure che condivide molte caratteristiche con la nuova versione di SQL Server codename “Denali”. Molti di questi “improvements” sono disponibili attraverso il Management Portal, che è stato in parte rivisitato per consentire una interfaccia più user-friendly.
Tra le novità presenti, che potete leggere qui e qui, quella a mio parere più rilevante riguarda la possibilità di eseguire l’esportazione dei dati direttamente dal Management Portal utilizzando il Blob Storage. La modalità illustrata nel mio libro su Windows Azure da Andrea Benedetti è comunque sempre valida, ma qui si affianca una maggiore semplicità grazie all’interfaccia grafica.
Potete leggere tutte le novità qui:
Dopo aver aggiornato il mio SDK alla versione 1.4, quasi ogni aggiornamento di un package su Azure mi provoca questo errore:
Role instances recycled for a certain amount of times during an update or upgrade operation. This indicates that the new version of your service or the configuration settings you provided when configuring the service prevent role instances from running. The most likely reason for this is that your code throws an unhandled exception. Please consider fixing your service or changing your configuration settings so that role instances do not throw unhandled exceptions. Then start another update or upgrade operation. Until you start another update or upgrade operation, Windows Azure will continue trying to update your service to the new version or configuration you provided.
Sostanzialmente il kernel di Windows Azure tenta di eseguire l’upgrade diverse volte senza successo. Dal portale non è possibile eseguire più nessun upgrade (i pulsanti sono disabilitati) e quindi abbiamo apperentemente le mani legate.
In realtà l’unica possibilità è quella di provare un Reimage. Ed è proprio quello che ho fatto (con una istanza bloccata…peggio di così 
). A quel punto, magicamente, il processo di upgrade è terminato correttamente.
Consultandomi con il supporto Windows Azure, mi hanno comunicato che sono al lavoro sull’anomalia ed effettivamente il problema si risolve solo con un re-image. Sarà comunque risolto con la versione 1.5 dell’SDK, attualmente in CTP.
Attenderò impaziente… 
I tempi di Windows 8 sembrano….IMPRESSIONANTI!
Fast boot times in Windows 8
Sul blog “Building Windows 8”, Steven Sinofsky illustra cosa è stato fatto e come possiamo intervenire per per modificare il meccanismo di startup.
A quanto pare, si tratta di un sistema ibrido che, differentemente dall’avvio “a freddo”, sfrutta l’ibernazione per quello che riguarda la sola sessione del kernel (session 0), decisamente più piccola rispetto all’intero processo di ibernazione e quindi con conseguenti tempi molto più rapidi.
Si tratta sicuramente di un miglioramento decisamente importante, ma mi sembra di vedere un modo per “aggirare” i problemi di lentezza dell’avvio. Sostanzialmente mi sembra, ma forse mi sbaglio, che siano intervenuti sulle modalità di avvio semplicemente ibernando una fase critica, invece di risolvere i problemi di performance derivanti da un uso intensivo.
Ad ogni modo… la BUILD si avvicina e ne sapremo sicuramente di più!
More Posts
Next page »