Architettura a Microservizi & Service FabricMassimo Bonanni

SR Consultant - ModernApps EMEA Domain - Microsoft

@massimobonannimassimo.bonanni@microsoft.com

Agenda

Concetti di architettura a Microservizi

Approccio Microsoft ai Microservizi – Service Fabric

Modello di programmazione di Service Fabric

Conclusioni

Concetti di architettura a Microservizi

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 abbatterei costi di gestione

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.

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

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

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

• 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 DBor

No-SQL

Mobileapps

Web Tier

Services Tier

Data Tier

Il database è condivisotra tutti i servizi

Stateless services with separate stores

Ogni microserviziopossiede 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.)

Approccio Microsoft ai Microservizi – Service Fabric

Azure Service Fabric

Microservices

Azure

WindowsServer

Linux

Hosted Clouds

WindowsServer

Linux

Service Fabric

Private Clouds

WindowsServer

Linux

High Availability

Hyper-Scale

Hybrid Operations

High Density Rolling Upgrades

Stateful services

Low LatencyFast startup &

shutdown

Container Orchestration

& lifecycle management

Replication &

Failover

Simple

programming

modelsLoad balancing

Self-healingData Partitioning

Automated Rollback

Health

Monitoring

Placement

Constraints

Il clusterUn 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

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

Application Model

Un Application Type è un insieme di

Service Type e definisce la struttura

dell’applicazione.

Un Application è un’istanza di un

Application TypeIl codice delle differenti application viene eseguito in differenti processianche se le applicazioni girano nellostesso nodo.

https://aka.ms/sfappmodel

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 garantisconol’alta disponibilità: se un’istanza o replicadi un servizio primaria non risponde, Service Fabric promuove a primaria unadelle secondarie garantendo continuità al servizio.

Le partizioni

https://aka.ms/sfpartitions

Development

Cluster

Modello di programmazione di Service Fabric

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

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

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

Reliable Actor

Basato su un pattern architetturale (Actor Model) pensato per realizzare un’architetturacostruita da processi indipendenti.

Ogni attore è individuato da un identificatore univoco attraverso il quale può essereistanziato (ActorId).

Ogni attore fornisce azioni che possono essere invocate dall’esterno. Le azioni sonoprocessate 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

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

Reliable Actors & Services

https://github.com/massimobonanni/ServiceFabricSamples

Service Fabric nel cloud

CosmosDB

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.

RiferimentiDocumentazione ufficiale

https://docs.microsoft.com/en-us/azure/service-fabric/

Blog ufficialehttps://blogs.msdn.microsoft.com/azureservicefabric/

Githubhttps://github.com/Azure/service-fabric

Build2017 - Azure Service Fabric, microservices, containers, and the road aheadhttps://channel9.msdn.com/Events/Build/2017/B8106

Build2017 - Managing secure, scalable Azure Service Fabric clusters and applicationshttps://channel9.msdn.com/events/Build/2017/T6084

MVA - Service Fabric Patterns and Practiceshttps://mva.microsoft.com/en-US/training-courses/16925

MVA - Building Microservices Applications on Azure Service Fabrichttps://mva.microsoft.com/en-US/training-courses/16747

Feedback Form

Aiutateci a migliorare la qualità dei nostri eventicompilando il feedback form:

https://1drv.ms/xs/s!Au9T1EY0TwHfn6RdsXBllmc3qTesWA

Thanks to our Sponsor