MILANO MuleSoft Meetup Group CloudHub 2.0, storia di una migrazione. Agenda Cos’è CloudHub 2.0 Business Case Technical Case Q&A

1. Germano Capoccia, Open Fiber
Stefano Bernardini, Engineering
Serena Galassi, Engineering
08/02/2024
MILANO MuleSoft Meetup Group
CloudHub 2.0, storia di una migrazione.

2. 2
• Cos’è CloudHub 2.0
• Business Case
• Technical Case
• Q&A
Agenda

3. All contents © MuleSoft, LLC
Cos’è CloudHub 2.0
… e soprattutto perchè

4. All contents © MuleSoft, LLC
On-premises
Cloud IaaS
Fully Managed PaaS
MuleSoft CloudHub 2.0 Anypoint Runtime Fabric Standalone Runtime
Comprehensive deployment options for all
Available
Available

5. All contents © MuleSoft, LLC
Positioning and Messaging
#1 Choice for deployment
Get started fast Grow with
efficiency
Streamline your
operations
Implement tighter
security controls
Fully Managed PaaS
MuleSoft CloudHub 2.0
CloudHub 2.0 - The Platform for the Future
5
Available

6. All contents © MuleSoft, LLC
Get started fast: Set up environments quickly
with simplified config for private spaces and
network connectivity
Lightweight Isolation: Taking advantage of the
new container based architecture for lightweight
application isolation
Implement tighter security controls: Simplify
static IP management and customize outbound
firewall rules at the private space level
Streamline your operations: Reduce
management overhead for dedicated load
balancer and ingress
CloudHub 2.0 - Why
Available
Ensure consistent security and quality without sacrificing development speed
Watch the Italian CloudHub 2.0 Webinar

7. © Engineering
Business Case
Febbraio 2024
ENGINEERING / THE DIGITAL TRANSFORMATION
COMPANY

8. © Engineering
Open Fiber nasce per realizzare un’infrastruttura di rete a banda ultra larga (BUL) in fibra ottica FTTH (Fiber To The Home) in
tutte le regioni italiane. Per realizzare il nostro progetto abbiamo scelto il modello di business “wholesale only” così da
garantire un libero accesso a tutti gli Operatori interessati, a parità di condizioni, fornendo agli utenti finali una vasta
possibilità di scelta.
La nostra missione persegue gli obiettivi previsti dall’Agenda Digitale Europea, dalla Strategia Italiana per la banda ultra larga
e dalla Gigabit Society. Un piano che permette di stabilire i livelli minimi di connettività in tutti i Paesi europei per cittadini,
Istituzioni e aziende.
Come player infrastrutturale, Open Fiber si occupa della realizzazione, gestione e manutenzione della rete in fibra ottica con
tecnologia FTTH, con livelli di efficienza e affidabilità elevatissimi.
8
Introduzione
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Chi è Open Fiber

9. © Engineering
9
Progetto migrazione ORG 1/2
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY

10. © Engineering
10
Progetto migrazione ORG 2/2
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Cosa si è rivelato fondamentale
• Coinvolgimento del team di Customer Success
• Team infrastruttura a bordo progetto
• Migration strategy
• …. Un pizzico di coraggio

11. © Engineering
Technical Case
Febbraio 2024
ENGINEERING / THE DIGITAL TRANSFORMATION
COMPANY

12. © Engineering
12
Analisi Iniziale e Percorso Strategico:
Obiettivi e Passi Chiave
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Obiettivo
• Completare la migrazione dell’intero anypoint platform su nuova Org
utilizzando CloudHub2.0 nella nuova org
• Elapsed massimo del Progetto: 4 mesi
Analisi iniziale
• Individuazione dei GAP tecnici per il passaggio a CH2.0
• Indiduazione delle attività e di possibili parallelismi o sequenzialità
per un’organizzazione più rapida ed efficace
• Definizione della strategia di migrazione e test nei tre ambienti di
rilascio
Analisi
iniziale
SetUp
Infrastruttura
Risoluzione dei
GAP per CH2.0
Rilasci e test

13. © Engineering
13
Analisi Iniziale delle Azioni e Organizzazione del Lavoro
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY

14. © Engineering
14
Analisi Iniziale delle Azioni e Organizzazione del Lavoro
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY

15. © Engineering
15
Analisi Iniziale delle Azioni e Organizzazione del Lavoro
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
• nomi API Spec modificati per creazione asset
su exchange
• Aggiornamento nomi API Spec su Anypoint
Studio
creazione API nel nuovo ambiente e
modifica properties e configurazioni
lato sviluppo
ridefinire ruoli, permessi ecc…
inserimento properties a runtime
per ripristinare il visualizer
creazione MQ, client apps e
modifica properties lato sviluppo
deployare mule apps su nuova org
con deployment target = CH2.0
Cambio Org Passaggio a CH2.0
• download e import API Spec
• Aggiornamento OrgId su
Anypoint Studio
IP Statici non più necessari perché intrinsechi nei
PrivateSpace
VM Persistent Queues not supported
• Cloudhub Connector not supported
• DLB non più utilizzati 🡪 public and private endpoint
nella sezione di Ingress

16. © Engineering
16
Analisi Iniziale delle Azioni e Organizzazione del Lavoro
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY

17. © Engineering
17
SetUp dell’infrastruttura
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
In ogni Private Space viene definito:
• Una private network
• Una o più connessioni dalla private network alla rete esterna
• TLS Context
• Firewal rules
• Gli ambienti e i gruppi aziendali

18. © Engineering
18
Test di connettività
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Ping not
supported in
CloudHub 2.0
Guida: link1
Link GitHub:
link2
Link download
diretto: link3.jar

19. © Engineering
19
Analisi Iniziale delle Azioni e Organizzazione del Lavoro
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY

20. © Engineering
20
Strategia di migrazione
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
❑ API-Led Connectivity
⮚ Modalità big bang
⮚ Modalità a pacchetti con logiche orizzontali
⮚ Modalità a pacchetti con logiche verticali
Pro:
- Zero downtime
- Possibilità di testare i flussi E2E
- Possibilità di testare in maniera anticipata anche la
comunicazione intra-app
- Facile gestione dei rilasci e test nei diversi ambienti
Contro:
- Ci sarà una fase in cui bisogna fare attenzione a tenere
stoppati alcuni endpoint di exp-api1 che ricadono
nell’ultima fase di rilascio

21. © Engineering
21
Strategia di migrazione – Fase 1
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Experience (3):
❑ exp-api 2
❑ exp-api 1
❑ Utilities
Process (2):
❑ prc-api 1
❑ prc-api 2
System (10):
❑ sys-api 2
❑ sys-api 1
❑ sys-api 5
❑ sys-api 6
❑ sys-api 3
❑ sys-api 10
❑ sys-api 7
❑ sys-api 8
❑ sys-api 4
❑ sys-api 9
Out Of The API-Led (2):
❑ Of-net-tools
❑ Out of api led

22. © Engineering
22
Strategia di migrazione – Fase 2
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Experience (3):
❑ exp-api 2
❑ exp-api 1
❑ Utilities
Process (2):
❑ prc-api 1
❑ prc-api 2
System (10):
❑ sys-api 2
❑ sys-api 1
❑ sys-api 5
❑ sys-api 6
❑ sys-api 3
❑ sys-api 10
❑ sys-api 7
❑ sys-api 8
❑ sys-api 4
❑ sys-api 9
Out Of The API-Led (2):
❑ Of-net-tools
❑ Out of api led

23. © Engineering
23
Strategia di migrazione – Fase 3
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Experience (3):
❑ exp-api 2
❑ exp-api 1
❑ Utilities
Process (2):
❑ prc-api 1
❑ prc-api 2
System (10):
❑ sys-api 2
❑ sys-api 1
❑ sys-api 5
❑ sys-api 6
❑ sys-api 3
❑ sys-api 10
❑ sys-api 7
❑ sys-api 8
❑ sys-api 4
❑ sys-api 9
Out Of The API-Led (2):
❑ Of-net-tools
❑ Out of api led

24. © Engineering
24
Strategia di migrazione – Gestione del CNAME
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
24
Focal point
• Strategia di separazione
funzionalità tra fase 2 e 3
• Gestione del CNAME da
DLB a PrivateSpace
CNAME
https://api.cliente.it
DLB
Vecchia Org
Private Space
Nuova Org
Fase 1 Fase 2 Fase 3

25. © Engineering
25
Strategia di migrazione – Gestione del CNAME
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
25
Focal point
• Strategia di separazione
funzionalità tra fase 2 e 3
• Gestione del CNAME da
DLB a PrivateSpace
DLB
Vecchia Org
Private Space
Nuova Org
Fase 1 Fase 2 Fase 3
https://myapp-envId-
PrivateSpaceId
CNAME
https://api.cliente.it

26. © Engineering
26
Strategia di migrazione – Gestione del CNAME
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
26
Focal point
• Strategia di separazione
funzionalità tra fase 2 e 3
• Gestione del CNAME da
DLB a PrivateSpace
DLB
Vecchia Org
Private Space
Nuova Org
Fase 1 Fase 2 Fase 3
https://myapp-envId-
PrivateSpaceId
CNAME
https://api.cliente.it

27. © Engineering
27
Strategia di migrazione – Gestione del CNAME
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
27
Focal point
• Strategia di separazione
funzionalità tra fase 2 e 3
• Gestione del CNAME da
DLB a PrivateSpace
DLB
Vecchia Org
Private Space
Nuova Org
Fase 1 Fase 2 Fase 3
https://myapp-envId-
PrivateSpaceId
CNAME
https://api.cliente.it

28. © Engineering
28
Strategia di migrazione – Gestione del CNAME
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
28
Focal point
• Strategia di separazione
funzionalità tra fase 2 e 3
• Gestione del CNAME da
DLB a PrivateSpace
DLB
Vecchia Org
Private Space
Nuova Org
Fase 1 Fase 2 Fase 3
CNAME
https://api.cliente.it

29. © Engineering
29
Analisi Iniziale delle Azioni e Organizzazione del Lavoro
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY

30. © Engineering
30
Esplorando le Novità: Sviluppo e Passaggio a CH2.0
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
VM
persistent
MQ
CloudHub
Connector
Send
Cambio porte dei listener su 8081 (HTTP)
Listener
• Cambio porte delle request intra-app su 80 o
443 in base al protocollo
• Cambio host delle request per chiamare altre
mule application internamente
Request
Scheduler
Possibilità di settare il Time Zone
Possibilità di oscurare le properties a runtime senza dover settare
niente nel mule-artifact

31. © Engineering
31
DLB vs Ingress
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
• Mapping rules centralizzate
• http Listener di tutte le EXP-API configurati con porta
8092
• http Listener di tutte le PRC-API e SYS-API configurati
con porta 8091 o 8092
CloudHub 1.0 CloudHub 2.0
• Mapping rules localizzate a livello di mule apps
• http Listener di tutte le EXP/PRC/SYS-API configurati
con porta 8081

32. © Engineering
32
Connettività tra Mule Application
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
mule-worker-internal-myapp.region.cloudhub.io
• Indirizzo IP Interno dei Mule Worker: Riservato
all'interno dell'Anypoint VPC privato del cliente.
• Servizi HTTP interni esposti su porte predefinite
${http.private.port} (8091) e ${https.private.port} (8092),
non modificabili.
Myapp-EnvUniqId-internal-PrivateSpaceId.region.cloudhub.io
CloudHub 1.0 CloudHub 2.0

33. © Engineering
33
Rilasci in Produzione: Suggerimenti Chiave per Minimizzare il Disservizio.
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
⮚ Migrazione di processi sincroni avviati tramite:
schedulazione
http listener
trigger (eventi, on new or updated)
⮚ Migrazione di processi asincroni

34. © Engineering
34
Migrazione di processi sincroni
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
• Migrare quando si è lontani
dall’avvio della prossima
schedulazione
• Spegnere prima su CH1 e poi
deployare su CH2
• Possibilità di migrare in qualsiasi
momento
• Comunicare ai consumer i nuovi
endpoint, credenziali e definire la
data di migrazione
• Possibilità di disservizio
• Migrare fuori orario lavorativo o in
momenti della giornata in cui non si
prevedono innescamenti del flusso
• Spegnere prima su CH1 e poi
deployare su CH2
Scheduler Listener
Eventi, On New
or Updated

35. © Engineering
35
Migrazione di processi asincroni
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Publisher
Subscribers Subscribers
Publisher
Property a runtime:
Initialstate.publisher = stopped
Gestione di processi asincroni
che utilizzano MQ
Vecchia org Nuova org
Vecchia org
Nuova org

36. © Engineering
36
Migrazione di processi asincroni
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Publisher
Subscribers Subscribers
Publisher
Vecchia org Nuova org
Vecchia org
Nuova org
Strada chiusa
Gestione di processi asincroni
che utilizzano MQ

37. © Engineering
Results
Febbraio 2024
ENGINEERING / THE DIGITAL TRANSFORMATION
COMPANY

38. © Engineering
38
A success story: I 3 risultati chiave del progetto
ENGINEERING / THE DIGITAL TRANSFORMATION COMPANY
Migrazione conclusa con
successo e zero
downtime
Progetto concluso in 4 mesi per
circa 20 use case
PRO di CH2.0 verificati
• Maggiore granularità dei vCores
• Sezione di ingress specifica per ciascuna
mule application
• DLB non serve più la licenza
• IP statici intrinsechi nei private space
• Sezione di scheduler con timezone specifica

39. © Engineering
www.eng.it
Engineering Ingegneria Informatica SpA
@EngineeringSpa
gruppo.engineering
LifeAtEngineering

40. 40
Q&A
Gestione del CNAME
In base al vostro caso, anche voi avreste
chiesto un doppio cambio di puntamenti ai
consumer?
Quali altre strategie avreste adottato?
Altre domande?
Strategia di migrazione
• Modalità big bang
• Modalità a logiche orizzontali
• Modalità a logiche verticali
Voi che scelta avreste fatto in base al vostro
caso?

41. 41
Diventa il prossimo Meetup Speaker!
● Condividi un argomento che può essere interessante
all’indirizzo email meetup@florence-consulting.it
● Sceglieremo la proposta più originale
● Riceverai gadgets della MuleSoft community

42. Contattaci all’indirizzo meetup@florence-
consulting.it
Hai ancora domande e vuoi
approfondire in separata sede?
Invia il tuo feedback
Finito l’evento riceverai una e-mail per inviare il tuo
feedback: facci sapere con precisione quali sono i
topic che ti piacerebbe approfondire insieme!
We Are Hiring!

43. Thank you