1.
Open DevSecOps 2019
Un caso di studio

2.
Marco Pantano
ALM Specialist, Emerasoft
Principali competenze:
• Release Management
• Configuration Management
• Build&Deploy Automation
PRESENTAZIONE

3.
Cliente
Login al portale nel 201830M ● 15M di richieste di servizi online
Team di sviluppo
100
+
● Diversi fornitori
● Evoluzioni in parallelo
● 10000 Build propedeutiche al collaudo all’anno
Applicazioni
700
+
● 90% Java
● 5% .NET
● 5% Angular
Login al portale nel 2018
150
M
● 46% in evoluzioni
● 48% in manutenzione e servizi
● 6% altri servizi
Budget a consuntivo 2018

4.
● Cliente: Primario Ente pubblico contesto Enterprise
● Progetto: DevOps Adoption Roadmap
● Stato Progetto: in corso
Contesto

5.
Anno 2011 - Importante ente pubblico italiano individua le seguenti criticità:
➢ Assenza di processi condivisi per lo sviluppo e il rilascio del software
➢ Mancata tracciatura delle attività di sviluppo e rilascio
➢ Comunicazioni tra il mondo Dev e Ops a mezzo email
➢ Assenza di un repository condiviso del codice sorgente
➢ Assenza di procedure automatizzate di build, test e deploy
SCENARIO

6.
➢ Il cliente ha la necessità di modificare le proprie modalità operative senza subire
rallentamenti sulle attività correnti
➢ Il cliente ritiene prioritaria la creazione di propri repository del codice sorgente e
degli artefatti buildati per aver modo di governare al meglio i propri Asset
software
➢ Il cliente ritiene prioritaria l’implementazione dei processi di pianificazione, rilascio
in collaudo, certificazione e produzione
➢ Il cliente vuole consentire l’esecuzione delle attività di deploy solo se
esplicitamente richieste attraverso un’opportuna richiesta di deploy
Linee guida - 1

7.
➢ Il cliente vuole costruire una propria Build Automation toolchain
➢ Il cliente vorrebbe automatizzare i test
➢ Il cliente vorrebbe dotarsi di strumenti di virtualizzazione di servizi per
automatizzare il provisioning degli ambienti di Integrazione e Q&A
➢ Il cliente vuole arrivare a lavorare in modalità DevOps
Linee guida - 2

8.
DevOps roadmap adoption - 1

9.
DevOps roadmap adoption - 2

10.
Conclusione?
Nuove criticità
➢ Automatizzazione vista come un pericolo
integrità di funzionalità e dati
➢ Decomposizione in microservizi rende complessa la messa in sicurezza degli
applicativi
nostalgia della sicurezza perimetrale sull’intero monolite
➢ Difficoltà nel superamento dell’organizzazione a silos
responsabilità Vs collaborazione
Resistenza al cambiamento

11.
Conclusione?
Nuove criticità
➢ Elevata complessità della nuova architettura a microservizi
➢ Nuove modalità di ripartizione dei costi in tema di controllo di gestione
➢ Difficoltà di natura contrattuale con i fornitori
Necessità di nuove competenze

12.
Nuovo approccio
Tavolo DevOps
➢ Condivisione genera cultura
➢ Definizione delle nuove modalità operative basate su un progetto reale
➢ Scelte basate sul livello di maturità
Competence Center DevOps
➢ Definizione di standard architetturali e di processo
➢ Diffusione delle best practices
➢ Supporto metodologico

13.
Dal monolite ai microservizi

14.
Mediated API Pattern

15.
Mediated API Pattern
➢ OUTER APIs
○ Interfacce esposte ad applicazioni e servizi esterni al proprio dominio
○ Gestite dall’Api Gateway
○ Pubblicate come RESTful APIs
➢ INNER APIs
○ Interfacce esposte e fruite dai microservizi stessi
○ Definiscono la modalità di invocazione del microservizio da parte del gateway
○ Definiscono come i microservizi comunicano tra loro
○ Possono essere:
■ sincrone: tipicamente RESTful, si aspetta la risposta a fronte della richiesta
■ asincrone: event driven, modello publisher-subscribe

16.
DevSecOps toolchain
Sorgenti
Swagger
Build binari
Build docker
image
Risolve dipendenze
Pubblica binari
Reperisce base image
Push del binario nell’immagine
Pubblica immagine
Build time Deploy time
Reperisce immagine
Orchestrazione
Pubblicazione
swagger
Reperisce artetatti npm
angula
Pubblicazione
SPA

17.
SEC
➢ Unico punto di accesso alle librerie di terze parti open
➢ Utilizzo delle funzionalità Lifecycle
○ ricerca vulnerabilità di sicurezza a tempo di build
○ generazione ACR
○ gestione dello stato delle vulnerabilità
○ continuous monitoring delle applicazioni in produzione
➢ Utilizzo degli staging per i binari e le immagini docker
○ Build->Sviluppo>Collaudo->Certificazione-Produzione
○ Release su Hosted Repository
➢ Utilizzo firewall

18.
Conclusione
➢ Nel settore pubblico esistono realtà che puntano sull’innovazione
➢ E’ necessario individuare il proprio livello di maturità
➢ Le decisioni strategiche vanno prese in funzione del proprio livello di
maturità
➢ E’ necessario lavorare costantemente al miglioramento delle proprie
competenze
➢ L’eliminazione delle logiche organizzative a silos deve portare alla
collaborazione concreta tra diversi fornitori

19.
Open DevSecOps 2019
Un caso di studio