Uno dei principali motivi per adottare un approccio DevOps è di soddisfare le richieste di mercato nel minor tempo possibile: ciò è possibile se un nostro prodotto ha una architettura ben composta e flessibile. In questo contesto, i microservizi sono un'ottima scelta: per la loro natura rappresentano l'approccio architetturale migliore per adottare una cultura DevOps e mantenere la complessità bassa. In questa sessione parleremo sia di aspetti architetturali che pratici relativi alla fusione di questi due mondi.

2. Microservizi & DevOps
Antonio Liccardi
IT & Mobile Specialist in Blexin s.r.l.
antonio.liccardi@blexin.com
@turibbio
Microsoft MVP Developer Technologies

3. Cosa sono i microservizi?
Microservices are small, autonomous
services that work together

4. I principi alla base dei microservizi
Orientati al
business
domain
API
Technology
agnostic
Small (1…N)
Indipendently
releasable

5. I principi alla base dei microservizi
• Piccoli e con un solo compito
• Ogni microservizi si deve focalizzare su una singola cosa. La coesione deve
essere fondamentale!
• Gather together those things that change for the same reason, and separate
those things that change for different reasons (Uncle Bob)
• Avere dei contesti (boundaries) espliciti.
• Più piccolo è il servizio, maggiori sono i benefici ma anche i possibili problemi
• Collaborano fra loro
• Espongono APIs (ma facendo attenzione, maggiore è l’esposizione, più sono le
interconnessioni)

6. I principi alla base dei microservizi
• Autonomi
• Tutte le comunicazioni avvengono tramite network (indipendenza)
• Rilasciabili autonomamente
• Devono poter essere rilasciati senza richiedere intervento da parte dei
consumer

7. Benefici dei microservizi
• Tecnologie eterogenee
• Basati su servizi, possono utilizzare diverse tecnologie dietro le quinte
• Benefici dal punto di vista dell’architettura, delle performance, organizzazione
aziendale
• Adozione facile di nuove tecnologie

8. Benefici dei microservizi
• Resilienza
• Concetto di bulkhead applicato ai service boundaries
• Scalabilità
• Possibilità di essere scalabili solo sulle funzionalità che richiedono scalabilità
• Facilità di deploy
• Ogni microservizio deve essere rilasciato in maniera indipendente
• Gestione del rollback semplice

9. Benefici dei microservizi
• Organizzazione aziendale
• L’uso dei microservizi aiuta l’organizzazione aziendale minimizzando il numero
di persone concentrato su una singola codebase
• Composabilità
• Riutilizzabilità dei componenti
• Una buona scelta per i sistemi legacy

10. Microservices are
not a silver bullet!

11. Come modellare un microservizio?
• Domain Driven Design by Eric
Evans (2003)
• Questo libro ci ha aiutato a
capire l’importanza di saper
rappresentare bene il mondo
nel nostro codice

12. Come modellare un microservizio?
• Hexagonal Architecture
• Niente più layer e tante «porte»
aperte!

13. Come modellare un microservizio?
• Loose Coupling
• Quando i servizi sono loosely coupled, una modifica ad un servizio non
richiede la modifica agli altri.
• High Cohesion
• Boundaries con accoppiamento dei domini comuni

14. Bounded Context

15. Bounded Context
• Ogni dominio è costituito da più bounded context
• In ogni bounded context c’è un modello che condivide determinate
informazioni verso l’esterno
• Ogni bounded context espone una specifica interfaccia con i modelli
condivisi
• Può capitare di avere modelli condivisi con egual nome ma con
informazioni diverse e usati in diversi contesti (es. Customer)
• Questo evita il tight coupling
• Aiuta a creare i moduli e servizi

16. Context Mapping

18. Monolite vs Microservizi

23. DevOps & Microservizi

24. Cosa sono i containers?
• E’ un approccio nello sviluppo software in cui una applicazione o
servizio, le sue dipendenze e la sua configurazione viene
«impacchettata» come una container image
• L’app può essere testata in maniera indipendente
• L’immagine viene deployata come una istanza sul container host

25. Vantaggi
• Deploy in diversi ambienti con la garanzia di avere lo stesso ambiente
• Isolamento dei container
• Eseguibili su piattaforme differenti (Linux / Windows)
• Più leggeri delle VM
• Scalabili
• Facili da deployare

26. Meet the «Hypervisor»

27. Docker

28. Docker: terminologia
• Container image
• applicazione contenente tutte le dipendenze, configurazioni e runtime
• una immagine può ereditare da altre
• Container
• istanza di un container, può essere eseguita più volte contemporaneamente
anche con parametri di inizializzazione differenti
• Tag
• una etichetta che può applicare ad una immagine

29. Docker: terminologia
• DockerFile
• configurazioni di build dell’immagine
• Build
• creazione dell’immagine container tramite il dockerfile
• Repository
• una collezione di immagini docker legate fra loro, generalmente associate ad
un tag

30. Docker: terminologia
• Registry
• un servizio che prevede l’accesso a dei repository di immagini (DockerHub, Docker
Trusted Registry o Azure Container Registry)
• Compose
• configurazione contenente il deploy di più immagini docker legate fra loro
• Cluster
• una collezione di Docker Host visti come unico (Swarm, DC/OS, Kubernetes)
• Orchestrator
• gestisce cluster e le istanze delle immagini presenti al proprio interno che ne prevede
l’esecuzione, la distribuzione e scalabilità

32. Meet Kubernetes
• Nasce in Google, ora gestito da Cloud Native Computing Foundation
• Installazione
• Diverse distribuzioni (cloud, on-premise)
• Azure Kubernetes Service
• Minikube (dev)
• Infrastructure as code

33. Kubernetes architecture

34. Workflow con Kubernetes

35. DEMO
Deploy containers on AKS with AzureDevOps

36. Testare containers
• Unit testing
• Component testing
• Integration testing
• End-to-End testing
• Contract Testing
• Production Testing

37. Contract Testing
• Consumer driven contract testing

38. Production testing

39. Monitorare Containers
• Application insight
• Marathon
• cAdvisor
• Prometheus
• Sysdig
• Your custom solution

40. Application Insight

41. Da dove comincio?
• eShopOnContainers
• Azure DevOps labs & documentation