Video del workshop: https://vimeo.com/album/2334363

1. CQRS ed Event Sourcing
su Windows Azure
Applicazioni Distribuite, Scalabilità e Security

2. …oh my god… <cit.>
Alessandro Melchiori Mauro Servienti
CodicePlastico Managed Designs
Architect & Partner Technical Advisor & Partner
alessandro.melchiori@codiceplastico.com mauro.servienti@manageddesigns.it
//blog.codiceplastico.com/melkio //milestone.topics.it
//blogs.ugidotnet.org/topics
@amelchiori @mauroservienti

3. Introduzione a Windows
Azure
…due parole…due..

4. Che cosa è

6. PaaS vs. IaaS
The big challenge

7. Boot
IaaS PaaS
• Build app • Build app
• Set up account • Set up PaaS account
• For each desired instance: • Click several configuration choices
• Install/configure OS • Click “Boot”
• Install desired Ruby version, runtime
• Install Rails and other libraries/gems
• Install/configure app server
• Install/configure HTTP server
• Install/configure load balancer
• Install/configure other components (DB, cache)
• Debug integration of stack
• Install/configure application on stack
• Get instances working together

8. Update
IaaS PaaS
• Repeat items as above, per instance • “Update Instances”
• Get instances working together

9. Scale
IaaS PaaS
• Do as install for new instances • Add instance(s)
• Reconfigure app servers, load balancers, DB, etc.
• Ensure consistent stacks
• Get instances working together

10. Scalabilità, Scalabilità…
…e ancora scalabilità

11. «orizzontale»
…is the word…

12. Tightly Coupled
Store Front End Shipping Service

13. Tightly Coupled
Store Front End Shipping Service

14. Loosely Coupled
Store Front End Order Queue Shipping Service

15. Loosely Coupled
Store Front End Order Queue Shipping Service

16. Loosely Coupled
Store Front End Order Queue Shipping Service

17. Loosely Coupled
Store Front End Order Queue Shipping Service

18. ma...questa cosa non mi è nuova...
• In «domain driven design» abbiamo dei concetti paralleli
• Bounded context
• Domain events

19. Le funzionalità erogate

20. Quello di cui parleremo oggi…
• Service bus:
• Notifcation Hubs;
• Worker Role;
• Web Role;
• Windows Azure ACS;
È importante capire anche cosa sono:
• Availability Set
• Virtual Network

21. Service Bus
• È un «message broker»;
• Altamente scalabile e performante;
• Può essere sfruttato anche da applicazioni on premise:
• con connettività verso Azure;
• Permette il disaccoppiamento totale tra i partecipanti:
• A patto che tutti conoscano il postino;
• A patto che tutti conoscano, o siano in grado di interpretare, la lingua parlata;

22. Lock-in…è un problema?

23. Lock-in
• È vero che se scegliamo come piattaforma Azure poi non possiamo, o
è molto difficile, cambiare?
• Quale è il «livello» di lock-in dei vari servizi?
• Web Role -> è un’applicazione MVC, punto;
• Worker Role -> l’entry point è strettamente legate ad Azure;
• Service Bus -> è un servizio di Azure, ma usando un toolkit, come
NServiceBus, è del tutto trasparente;
• Tutti: i settings, che però sono facilmente nascondibili dietro qualcosa di
rimpiazzabile a caldo;
• ACS: non c’è alternativa, ma nulla ci vieta, visto il costo irrisorio, di lasciare
quello su Azure;

24. Visual Studio: Windows Azure
SDK
Breve corso di sopravvivenza all’emulatore…

25. Demo
Worker Role, Web Role, l’emulatore e i tool

26. I dialetti del ServiceBus
scalare comunicando

27. Service Bus queue

28. Service Bus topic
Subs

29. Perché la comunicazione è un
problema…
Topologia di un data-center

30. I «data center» di Azure
• Siamo ospitati in una macchina virtuale, sempre;
• Non abbiamo controllo sulla topologia di rete in cui siamo deployati, se non
in minima parte con:
• AvailabilitySet: vogliamo che tutti i nostri servizi siano nello stesso Set;
• ha lo scopo di contenere costi e latenza;
• Virtual Network: reti virtuali che ci permettono di collegare qualsiasi cosa con
qualsiasi cosa a prescindere da dove stia;
• Davanti ad ogni servizio ci sono i Load Balancer di Azure, non è quindi detto
che i round trip siano concessi;
• Risulta quindi estremamente poco probabile che due o più servizi possano
comunicare tra loro come lo farebbero on premise dove abbiamo pieno
controllo della topologia di rete;

31. Perché la comunicazione è un
problema…
Disponibilità dei servizi

32. Messaggi, messaggi e
messaggi
Il postino alla fine è sempre li a rompere…

33. Ale/mauro
• Introduzione al concetto di messaggistica;
• Che cosa è un broker

34. Tutto è asincrono
Un cambio radicale a partire dalla UX

35. Un cambio di paradigma radicale
• Siamo abituati troppo, sfruttiamo il «not responding» a nostro
vantaggio, o comunque ci aspettiamo che le operazioni siano sempre
sincrone;
• Introducendo un sistema basato su messaggi tutto diventa
inevitabilmente asincrono:
• Non sappiamo quando il messaggio arriva;
• Non sappiamo neanche se il messaggio arriverà mai;

36. Che cosa viene impattato di più?
• User Experience
• L’utente è abituato all’immediate feedback;
• I comandi devono dare un ack il più velocemente possibile;
• In certi scenari ha molto senso, nonostante la complessità, introdurre della logica
client side in stile «Facebook»:
• Ti faccio credere che l’ho fatto;
• Nella peggiore delle ipotesi fallisco tra un po’;
• Workflow
(se ci pensiamo ogni cosa è un workflow, mal che vada con solo due stati)
• I dati, intese come le «tabelle», non sono più la bibbia;
• Ogni step di uno workflow deve basarsi sull’output dello step precedente e la bibbia
diventano gli eventi;

37. Gestione delle sicurezza
in un sistema distribuito
Windows Azure ACS

38. Why?
Pecccchè…?

39. Autenticazione
• Il 100% delle “app” LOB deve «autenticare»;
• Gestire le credenziali in modo sicuro;
• Garantire la privacy;
• Offrire un sistema per cambiare le credenziali;
• Offrire un sistema per recuperare le credenziali;
• Offrire un sistema per creare/si un nuovo utente;
• Gestire il profilo dell’utente;

40. Ci serve veramente tutto ciò?
• Il 100% delle “app” LOB deve «autenticare» sapere chi è l’utente
connesso;
• Gestire le credenziali in modo sicuro;
• Garantire la privacy;
• Offrire un sistema per cambiare le credenziali;
• Offrire un sistema per recuperare le credenziali;
• Offrire un sistema per creare/si un nuovo utente;
• Gestire il profilo dell’utente;

41. la federazione
It’s a long way to the top if you wanna rock ‘n’ roll…

42. L’abitudine…
App Backend/FBA User
Store
Profiles

43. La possibilità…federata
App Backend/FBA Profiles
nameidentifier
Non è un problema nostro
Trusted
3rd party
STS
User
Store

44. Sembra più complesso…ma…
• L’STS (security token service) non è un problema nostro;
• Noi ci limitiamo alla fiducia;

45. Il cattivo :-)
• …se avessimo questi requisiti?
• «Dipendenti» con account AD;
• «Interni» con account FBA (e.g. agenti/consulenti);
• «Esterni» con account Google/Facebook/LiveID;

46. La realtà…federata
App Backend Profiles
nameidentifier
Non è un problema nostro
Trusted
ACS
Custom FBA LiveID
Active Directory Google Account Facebook

47. Azure ACS
Power to you…

48. Per che cosa
• Autenticazione degli utenti;
• Anche con account diversi dal Microsoft Account;
• Integrazione di servizi di terze parti che “comprendono” la lingua
dell’ACS;

49. Lo scenario
Unpacked info
App Backend Profiles
nameidentifier
STS Security Info/Token
Trusted
ACS
Some STS

50. Come
• Configurare il namespace sull’ACS di Azure;
• Predisporre un “return url” ad hoc per l’app in grado di spacchettare il
token;
• Recuperare la lista degli Identity Provider;
• Far scegliere all’utente il provider da usare;
• ….

51. Architettura di un’applicazione
Tutto bello ma «facce vedè»…

52. Demo