Il Consorzio dei Comuni Trentini, in collaborazione con l’unità multiEnte creata nell’ambito del Gruppo di Lavoro per il Data Center unico Territoriale costituito e coordinato da Trentino Network su mandato della PAT (Gdl DCUT http://www.trentinonetwork.it/progetti/dcut) è pronto per erogare i servizi di Comunweb in modalità Cloud su piattaforma Amazon Web Services

1. Migrazione di ComunWeb al Cloud
Amazon Web Services (AWS)
La PA verso il Cloud
27/11/2017 - Consorzio dei Comuni Trentini

2. Migrazione di ComunWeb ad Amazon Web Services (AWS)
DCUT: Obiettivi del POC
• ampliare la conoscenza su strumenti, metodologie e linee guida che
permettano di migrareservizilegacy e tendenzialmente monolitici al Cloud
computing
• saper individuare e valutare il peso delle variabili che determinano
opportunità o meno dell’erogazione di servizi secondo il paradigma PaaS,
con una comprensione del binomio costo/servizi;
• saper individuare e valutare le implicazioninormative e modalità per
adempiere agli obblighi necessari a termini di legge

3. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Servizi offerti da ComunWeb

4. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Servizi offerti da ComunWeb
• Sito istituzionale di comunicazione con il cittadino (1.150redattoricreano
contenuto)

5. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Servizi offerti da ComunWeb
• Sito istituzionale di comunicazione con il cittadino (1.150redattoricreano
contenuto)
• API (Open Data; 4.000 dataset), dati strutturati (modello di riferimento: OntoPA)

6. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Servizi offerti da ComunWeb
• Sito istituzionale di comunicazione con il cittadino (1.150redattoricreano
contenuto)
• API (Open Data; 4.000 dataset), dati strutturati (modello di riferimento: OntoPA)
• Open services (interoperabilità con applicazioni comunali; 200 web services)

7. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Servizi offerti da ComunWeb
• Sito istituzionale di comunicazione con il cittadino (1.150redattoricreano
contenuto)
• API (Open Data; 4.000 dataset), dati strutturati (modello di riferimento: OntoPA)
• Open services (interoperabilità con applicazioni comunali; 200 web services)
• Micro-servizi e servizi on-line (cittadinocreacontenuto):
• Dimmi 2.0 (consultazioni pubbliche)
• SensorCivico (segnalazioni dei cittadini)
• OpenAgenda (eventi delle associazioni)
• SpaziComuni (prenotazione sale ed attrezzature)
• Servizi on-line di nuova generazione

8. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Infrastruttura attuale

9. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Ottimizzazione dell’architettura
Esempio: impiego di cache per usare meno risorse del sistema
Cittadini
Contenuti
web
Cache efficace
Redattori
2015

10. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Ottimizzazione dell’architettura
Esempio: impiego di cache per usare meno risorse del sistema
Cittadini
Contenuti
web
Cache efficace
Redattori
2015
Contenuti
web
Cache poco efficace
2017

11. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Fattori esterni che rendono necessaria
la revisione dell’architettura

12. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Fattori esterni che rendono necessaria
la revisione dell’architettura
• Aumento dei volumi del progetto:
• redattori (1.150)
• visite al sito
• incremento dell’uso delle applicazioni
• contenuti generati dai cittadini (decine di migliaia di istanze)

13. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Fattori esterni che rendono necessaria
la revisione dell’architettura
• Aumento dei volumi del progetto:
• redattori (1.150)
• visite al sito
• incremento dell’uso delle applicazioni
• contenuti generati dai cittadini (decine di migliaia di istanze)
• I micro-servizi introducono nuove modalità di utilizzo del web da parte del
cittadino; cambiano le aspettative degli utenti rispetto ai servizi:
• sempre attivi, 24x7 (sportello on-line)
• rapidi e performanti (competitivi rispetto a quelli del mondo privato)
• da smartphone (mobile first design)
• picchi di traffico non prevedibili (social)
• attenzione a nuovi contenuti e nuovi servizi

14. 2015
feb-nov
Necessità di maggiori performance
Aumento di visite, nuovi contenuti, nuovi servizi

15. 2015
feb-nov
Necessità di maggiori performance
Aumento di visite, nuovi contenuti, nuovi servizi
2017
feb-nov (OpenAgenda)

16. 2015
feb-nov
Necessità di maggiori performance
Aumento di visite, nuovi contenuti, nuovi servizi
2017
feb-nov (OpenAgenda)

17. Imprevedibilità delle decisioni degli EELL:
organizzazione di eventi partecipativi di successo
Visitealsitoistituzionale:+500%in10giorni

18. Continuità di servizio Orario sportelli : sette giorni su sette, 24h/7

19. Continuità di servizio Orario sportelli : sette giorni su sette, 24h/7

20. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Fattori interni che rendono necessaria la
revisione dell’architettura

21. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Fattori interni che rendono necessaria la
revisione dell’architettura
• Aumento dei volumi del progetto:
• istallazioni (230)
• micro-servizi in crescita
• operazioni automatiche di allineamento dati (200 web services)

22. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Fattori interni che rendono necessaria la
revisione dell’architettura
• Aumento dei volumi del progetto:
• istallazioni (230)
• micro-servizi in crescita
• operazioni automatiche di allineamento dati (200 web services)
• Rilasci più frequenti (attualmente 1 volta a settimana; obiettivo: 3 volte al
giorno)

23. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Fattori interni che rendono necessaria la
revisione dell’architettura
• Aumento dei volumi del progetto:
• istallazioni (230)
• micro-servizi in crescita
• operazioni automatiche di allineamento dati (200 web services)
• Rilasci più frequenti (attualmente 1 volta a settimana; obiettivo: 3 volte al
giorno)
• Tempi di ripristino (attualmente diverse ore / 1 giorno; obiettivo: 20 minuti)

24. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Fattori interni che rendono necessaria la
revisione dell’architettura
• Aumento dei volumi del progetto:
• istallazioni (230)
• micro-servizi in crescita
• operazioni automatiche di allineamento dati (200 web services)
• Rilasci più frequenti (attualmente 1 volta a settimana; obiettivo: 3 volte al
giorno)
• Tempi di ripristino (attualmente diverse ore / 1 giorno; obiettivo: 20 minuti)
• Modalità di erogazione dei servizi da parte del CCT (PaaS, SaaS); nel 2015, 64
istanze in 3 mesi

25. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Fattori interni che rendono necessaria la
revisione dell’architettura
• Aumento dei volumi del progetto:
• istallazioni (230)
• micro-servizi in crescita
• operazioni automatiche di allineamento dati (200 web services)
• Rilasci più frequenti (attualmente 1 volta a settimana; obiettivo: 3 volte al
giorno)
• Tempi di ripristino (attualmente diverse ore / 1 giorno; obiettivo: 20 minuti)
• Modalità di erogazione dei servizi da parte del CCT (PaaS, SaaS); nel 2015, 64
istanze in 3 mesi
• Necessità: miglioriperformance, continuitàdiservizio, ripristino, velocitàdi
erogazionenuoviservizi

26. Modalità di erogazione dei micro-servizi
Sito Design Italia
Acquista400€
SensorCivico (segnalazioni)
Acquista300€
Dimmi (consultazioni civiche)
Acquista600€
SpaziComuni
Acquista600€
OpenAgenda
Acquista1.100€
Amministrazione Trasparente
Acquista150€
“Software as a Service” per gli enti locali

27. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Infrastruttura cloud a regime, su AWS
(Elastic load balancing)
Autoscaling
Autoscaling
hot-standby
(Postgresql RDS)

28. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Infrastruttura cloud a regime, su AWS
Route53
gestione DNS
(ridondanza su più regioni)
Continuità di servizio
e disaster recovery (Elastic load balancing)
Autoscaling
Autoscaling
hot-standby
(Postgresql RDS)

29. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Infrastruttura cloud a regime, su AWS
Route53
gestione DNS
(ridondanza su più regioni)
Continuità di servizio
e disaster recovery
Risorse statiche
e backup
(Elastic load balancing)
Autoscaling
Autoscaling
hot-standby
(Postgresql RDS)

30. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Infrastruttura cloud a regime, su AWS
Route53
gestione DNS
(ridondanza su più regioni)
Continuità di servizio
e disaster recovery
Risorse statiche
e backup
(Elastic load balancing)
Autoscaling
Autoscaling
hot-standby
Monitoraggio
parametri e log
(CloudWatch)
(Postgresql RDS)

31. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Infrastruttura cloud a regime, su AWS
Route53
gestione DNS
(ridondanza su più regioni)
Continuità di servizio
e disaster recovery
Risorse statiche
e backup
(Elastic load balancing)
Autoscaling
Autoscaling
Gestione infrastruttura
(CloudFormation)
Creazione automatica di nuove macchine
(configuration management, source control,
continuous integration, continuous delivery,
continuous deployment)
hot-standby
Monitoraggio
parametri e log
(CloudWatch)
(Postgresql RDS)

32. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Infrastruttura cloud a regime, su AWS
Route53
gestione DNS
(ridondanza su più regioni)
Continuità di servizio
e disaster recovery
Risorse statiche
e backup
(Elastic load balancing)
Autoscaling
Autoscaling
Deploy:
Codice da Github
Compilazione Composer
(Ansible)
Gestione infrastruttura
(CloudFormation)
Creazione automatica di nuove macchine
(configuration management, source control,
continuous integration, continuous delivery,
continuous deployment)
hot-standby
Monitoraggio
parametri e log
(CloudWatch)
(Postgresql RDS)

33. Necessità Tempidiattivazioneesoluzioni Costiebenefici
1
Picchi di carico: aumento di risorse
Auto-provisioning
Dopo configurazione iniziale: risparmio di oltre 50%
rispetto ad adeguare l’attuale soluzione
Creazione automatica nuove macchine: 10minutiTerminato il picco: rilascio di risorse
2
Automazione dei rilasci applicativo
(test e deploy), deplori più
frequenti e non programmati
Preparazione ricette Ansible e
CloudFormation: automazione di
gestione dell’infrastruttura
Dopo configurazione iniziale: contenimentodeicosti di
rilascio (nessun intervento manuale sui sistemi)
Non servirà più interrompereilservizio per “Server in
manutenzione”
3 Alta disponibilità
Predisposizione iniziale su zone /
regioni geografiche diverse
Comporta costoaggiuntivo (da 50% a 100% in più), ma
garantisce la totale disponibilità del servizio, riducendo
la necessità di ricorrere al disasterrecovery
Tempi di ripristino: 20minuti
4 Attivare servizi in modalità PaaS
Utilizzo dei servizi predisposti
(Postgresql RDS, e-mail service,
Route53, CloudWatch, S3
Storage)
Costa 30%inpiù della soluzione attuale che va comunque
migliorata, ma 50%inmeno rispetto a infrastruttura
gestita “in casa”
Garantisce la continuità di servizio effettiva
5
Cluster eZ Publish e architettura
componenti orientata ai micro-
servizi
Affinamento estensioni
(1 mese di lavoro)
Dopo un intervento correttivo, eliminatotalmenteicollidi
bottiglia dall’architettura software
Migrazione di ComunWeb su Amazon (semplificato)

34. Migrazione di ComunWeb ad Amazon Web Services (AWS)
Attenzioniparticolari
• Sono facilitate le applicazioni “moderne”, con un’ architetturacluster e
orientata ai micro-servizi; l’approccio monolitico tende a ridurre
notevolmente i benefici economici del cloud ed aumenta la
complessità di gestione
• Lelicenzesoftware legate al numero di core/installazioni ostacolano
l’avvio automatico di nuove macchine
• L’ automazionedeideploy responsabilizza maggiormente il teamdi
sviluppo; maggior collaborazione tra sviluppatori ed amministratori
di sistema