Sessione su Microservice architecture e Service Fabric tenuta durante l'evento Cloud@Work 2017 tenuto a Roma il 23/06/2017

2. Architettura a Microservizi &
Service Fabric
Massimo Bonanni
SR Consultant - ModernApps EMEA Domain - Microsoft
@massimobonanni
massimo.bonanni@microsoft.com

3. Agenda
Concetti di architettura a Microservizi
Approccio Microsoft ai Microservizi – Service Fabric
Modello di programmazione di Service Fabric
Conclusioni

4. Concetti di architettura a
Microservizi

5. Perchè un approccio Microservice?
Realizzare e gestire servizi scalabili
Applicazioni in continua evoluzione
Maggiore velocità di distribuzione delle nuove
funzionalità per rispondere ai requisiti del cliente
Miglior utilizzo delle risorse per abbattere
i costi di gestione

6. Definizione di Microservizi
Fanno una cosa sola in maniera efficiente ed efficace, sviluppati da un piccolo team di
progettazione.
Scritti in qualsiasi linguaggio di programmazione e con qualsiasi framework.
Costituiti da codice, configurazione e risorse, sottoposti al controllo delle versioni,
distribuiti e ridimensionati in maniera indipendente.
Interagiscono con altri microservizi tramite interfacce e protocolli ben definiti.
Hanno nomi univoci (URL) usati per risolvere la propria posizione.
Rimangono coerenti e disponibili in caso di errori.

7. Eliminazione di singoli punti di guasto: un bug in un microservizio rimane
isolato all’interno dello stesso;
Iterazioni più veloci: codice più semplice con modifiche che non impattano
tutta l’applicazione;
Scalabilità: on-demand, elastica, densità dei servizi;
Versionamento: versioning sul singolo servizio in maniera semplice;
Flessibilità del linguaggio di sviluppo: minimizza l’impegno a lungo termine
sullo stack tecnologico. Quando si sviluppa un nuovo servizio, si è liberi di
scegliere qualsiasi linguaggio di programmazione e framework (i servizi
sono disaccoppiati tra loro)
Benefici dell’architettura basata su Microservizi

8. Automazione spinta: mantenere più flussi di distribuzione corretti e coerenti per
tutto il ciclo di vita dell’applicazione;
Comunicazione tra i servizi: i servizi disaccoppiati hanno bisogno di un modo
efficace per comunicare senza rallentare l’intera applicazione;
Coerenza dei dati: garantire la coerenza dei dati è una sfida, sia per lo store dei
dati che per i dati in transito sulla rete;
Alta disponibilità: il tempo di attività di ogni servizio contribuisce alla disponibilità
complessiva dell’intera applicazione. Ogni servizio deve quindi avere un proprio
sistema di misure distribuite per garantire all’applicazione un ampia disponibilità;
Test: non è semplice implementare i test di integrazione. E’ necessario
automatizzare il più possibile.
Svantaggi dell’architettura basata su Microservizi

9. Approccio “Monolitico” Approccio Microservizi
Una applicazione a microservizi
separa le funzionalità in servizi distinti
Questo approccio consente di scalare
indipendentemente ogni servizio,
creando istanze di ognuno su
Server/VM/Container.
Una applicazione monolitica
raggruppa insieme funzionalità di un
dominio ed è normalmente separata in
layer, come web, business e data.
Viene scalata clonandola su più
Server/VM/Container.
App 1 App 2App 1

10. • Singolo database
• Livelli con tecnologie specifiche
I dati nelle architetture n-layer I dati nell’approccio Microservizi
• Grafo di Microservizi interconnessi
• Lo stato è all’interno del singolo Microservice
• Differenti tecnologie utilizzate
• Database per i dati «cold»
Stateful
services
Web presentation
services
Stateless
servicesSQL DB
or
No-SQL
Mobile
apps
Web Tier
Services Tier
Data Tier
Il database è condiviso
tra tutti i servizi
Stateless services with
separate stores
Ogni microservizio
possiede il proprio
modello dati!
SQL
[…]
La connessione al
database è un collo di
bottiglia
Cache Tier
L’utilizzo di una Cache
non è di aiuto
nell’ingestion di
massicce quantità di
dati (Events, IoT, etc.)

11. Approccio Microsoft ai
Microservizi – Service Fabric

12. Azure Service Fabric
Microservices
Azure
Windows
Server
Linux
Hosted Clouds
Windows
Server
Linux
Service Fabric
Private Clouds
Windows
Server
Linux
High Availability
Hyper-Scale
Hybrid Operations
High Density Rolling Upgrades
Stateful services
Low Latency
Fast startup &
shutdown
Container Orchestration
& lifecycle management
Replication &
Failover
Simple
programming
models
Load balancing
Self-healingData Partitioning
Automated Rollback
Health
Monitoring
Placement
Constraints

13. Il cluster
Un cluster è un insieme di macchine (virtuali o fisiche)
connesse in rete e in cui è presente il runtime di Service Fabric.
Il cluster è composto da nodi e configurabile tramite un
manifest.
Ogni nodo può avere caratteristiche
custom che permettono di
posizionare nel migliore dei modi
i servizi (constraint).
Pensato per limitare l’impatto
dei singoli guasti hardware.
Un cluster è suddiviso in
Upgrade Domain e Fault
Domain.
https://aka.ms/sfcluster

14. Fault Domain e Upgrade Domain
Fault Domain: è un insieme di machine che possono avere problemi
contemporaneamente. Ad esempio una singola macchina o tutte le machine
alimentate dalla stessa presa.
Upgrade Domain: un upgrade domain definisce l’insieme dei nodi che vengono
aggiornati contemporaneamente.
https://aka.ms/sfdomains

15. Application Model
Un Application Type è un insieme di
Service Type e definisce la struttura
dell’applicazione.
Un Application è un’istanza di un
Application Type
Il codice delle differenti application
viene eseguito in differenti processi
anche se le applicazioni girano nello
stesso nodo.
https://aka.ms/sfappmodel

16. I microservizi memorizzano lo stato in partizioni in modo da consentire la
scalabilità.
Una partizione contiene:
• Istanze di servizi senza stato (primarie e secondarie)
• Repliche di servizi con stato (primarie e secondarie)
Le repliche di un servizio garantiscono
l’alta disponibilità: se un’istanza o replica
di un servizio primaria non risponde,
Service Fabric promuove a primaria una
delle secondarie garantendo continuità
al servizio.
Le partizioni
https://aka.ms/sfpartitions

17. Development
Cluster

18. Modello di programmazione di
Service Fabric

19. Tipologie di servizi
Guest executables & guest containers
• Permette di implementare e pubblicare servizi scritti con qualsiasi framework (win32, Java, …).
Stateless Services
• Servizi il cui stato è persistito esternamente (ad esempio in Azure DB)
• Applicazioni web (ASP.NET) esistenti e worker role
Stateful Services
• Affidabilità dello stato gestita attraverso repliche e persistenza locale
• Bassa latenza
• Riducono la complessità rispetto al tradizionale approccio n-layer

20. Modelli di programmazione Built-In
Reliable Service : insieme di API per l’implementazione di servizi con e senza
stato.
Stateful Service : memorizzano lo stato utilizzando delle reliable
collection e sfruttando le repliche per garantire la consistenza dello
stesso.
Stateless Service : non memorizzano lo stato in repliche. Consentono di
hostare service WCF o Web
Reliable Actor : insieme di API per l’implementazione di oggetti basati sul
concetto di Actor Model.
https://aka.ms/sfprogmodel

21. Reliable Service
Simili ai Web Service ma forniscono alcune caratteristiche out of the box come alta
disponibilità, affidabilità, resilienza.
Basano la scalabilità sul concetto di partizione dei dati.
Possono essere Stateless o Stateful.
Lo stato è gestito da uno State Manager che fornisce API per rendere i dati affidabili e
replicati nel cluster.
I Reliable Service comunicano tra loro (e con gli Attori) tramite messaggi asincroni.
https://aka.ms/sfreliableservices

22. Reliable Actor
Basato su un pattern architetturale (Actor Model) pensato per realizzare un’architettura
costruita da processi indipendenti.
Ogni attore è individuato da un identificatore univoco attraverso il quale può essere
istanziato (ActorId).
Ogni attore fornisce azioni che possono essere invocate dall’esterno. Le azioni sono
processate nell’ordine in cui vengono invocate.
Generalmente Stateful (ma lo stato può essere persistente o volatile). L’affidabilità dello stato
è gestita, in maniera trasparente, dal framework.
https://aka.ms/sfreliableactors

23. Reliable Actor
Ha un pattern di esecuzione Single Thread: un singolo attore non è in grado di
elaborare altre richieste in arrivo finché la richiesta corrente non è terminata.
L’Actor Model è un modello matematico per il calcolo concorrente teorizzato nel
1973 da Carl Hewitt (http://aka.ms/HewittCH9Actor).
Gli Attori comunicano tra loro (e con i Reliable Service) tramite messaggi asincroni.
https://aka.ms/sfreliableactors

24. Reliable Actors & Services
https://github.com/massimobonanni/ServiceFabricSamples

25. Service Fabric nel cloud
Cosmos
DB

26. Service Fabric Takeaways
Service Fabric fornisce “chiavi in mano” tutte le funzionalità di
orchestrazione necessarie per i nostri servizi.
Utilizzato per molti dei servizi offerti da Azure.
Può essere eseguito sia nel Cloud che on Premise.
Può lavorare con processi, container o una combinazione dei due.
Gira su Linux e Windows.
Possibilità di utilizzo di più linguaggi/framework.

28. Riferimenti
Documentazione ufficiale
https://docs.microsoft.com/en-us/azure/service-fabric/
Blog ufficiale
https://blogs.msdn.microsoft.com/azureservicefabric/
Github
https://github.com/Azure/service-fabric
Build2017 - Azure Service Fabric, microservices, containers, and the road ahead
https://channel9.msdn.com/Events/Build/2017/B8106
Build2017 - Managing secure, scalable Azure Service Fabric clusters and applications
https://channel9.msdn.com/events/Build/2017/T6084
MVA - Service Fabric Patterns and Practices
https://mva.microsoft.com/en-US/training-courses/16925
MVA - Building Microservices Applications on Azure Service Fabric
https://mva.microsoft.com/en-US/training-courses/16747

29. Feedback Form
Aiutateci a migliorare la qualità dei nostri eventi
compilando il feedback form:
https://1drv.ms/xs/s!Au9T1EY0TwHfn6RdsXBllmc3qTesWA

30. Thanks to our Sponsor