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
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;
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;
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;
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;
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;
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
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;
• ….