In questo articolo parleremo di un esempio di architettura in cui sono presenti elementi monolitici, SOA e microservizi.
TrinityCom: Provider di Telefonia Mobile Fittizio
TrinityCom, provider di telefonia mobile globale fittizio, ha acquisito alcune società per rimanere competitivo sul mercato ed entrare nel business dei beni digitali.
La società ha acquisito un servizio di streaming (TideView) e un fornitore di rete via cavo (NestorCon), che sebbene non sia un attore globale, ha ottenuto un discreto successo nell'Europa centrale.
Tutte e tre le società hanno le proprie piattaforme e-commerce e di servizi che sono supportate da diversi sistemi di backend. Diamo uno sguardo ad alcuni fatti e cifre:
- TrinityCom ha investito molto nella creazione di un innovativo sistema eCommerce headless. Tale sistema consente integrazioni complesse e una user experience ottimale, ma ha riscontrato delle problematiche durante l’ultima stagione natalizia. Nonostante il design headless consenta flessibilità aggiuntiva, la soluzione è progettata su un’architettura monolitica, difficilmente scalabile. Dopo una prima analisi, il collo di bottiglia è stato riscontrato nel motore di ricerca che è parte del sistema principale della piattaforma e-commerce.
- TrinityCom è in fase di migrazione del proprio CRM e service system verso Salesforce. Proprio perché la migrazione è appena iniziata, esistono processi che richiedono accesso a entrambi i sistemi. TideView e NestorCon hanno i propri sistemi. Il sistema di TideView è abbastanza semplice e sarà migrato fin da subito. Per NestorCon, data la complessità dell’azienda, la struttura esistente Siebel che è stata progettata e personalizzata per più di due decenni, non sarà facile da sostituire.
- Con l’acquisizione delle due società, TrinityCom vede del potenziale per la generazione di nuovo business. Uno dei progetti ha come focus la creazione di applicazioni che sfruttano tutte e tre le categorie di servizi. Tra i potenziali casi d’uso che TrinityCom sta considerando ci sono: home automation, provisioning dinamico della larghezza di banda, pay-per-view, preview degli aggiornamenti di servizi promotion-driven.
Tali progetti possono essere realizzati più rapidamente da un gruppo di sviluppatori cloud-native di TideView. Gli sviluppatori hanno creato diversi servizi REST consumabili, ma devono ancora introdurre una soluzione API-management/gateway applicabile.
NestorCon fornisce alcune interfacce per servizi Web basate su SOAP ampiamente adottate dai propri partner. La società ha in programma di sostituirli con versioni più recenti e migliorate basate su REST. Tuttavia, attualmente devono essere mantenuti così come sono, ma alla fine verrebbero inviati attraverso un proxy tramite una soluzione API gateaway per applicare le policy e gestire meglio il consumo.
L’immagine seguente mostra l’architettura finale proposta, costituita da elementi di architettura monolitica, SOA e microservizi. Vediamo cosa ha portato a questo tipo di decisioni e come MuleSoft può incrementare flessibilità e agilità supportando e completando questo approccio combinato.
Discutiamo l'architettura finale in modo più dettagliato. L'applicazione monolitica del sistema eCommerce, che ora contiene le unità di conservazione delle scorte digitali di TideView e TrinityCom, non è cambiata e rimane tale; questo per evitare eventuali rischi nello spostamento di tale applicazione personalizzata altamente complessa che funziona perfettamente ed è affidabile.
All’interno del Process Layer, MuleSoft ha introdotto il Mule API “Headless Commerce Service” che aggiunge una logica di orchestrazione per due motivazioni principali.
Innanzitutto, indirizza le performance di ricerca nel catalogo, delegando la logica a un cluster di microservizi separato.
Un altro aspetto importante legato all’ “Headless Commerce Service” è che può arricchire il servizio originale includendo nuovi servizi applicativi forniti dal nuovo team DevOps.
La potente e flessibile struttura “modern API” di Anypoint Platform supporta tutte le funzionalità richieste in tale contesto. L’architettura snella di un’API Mule soddisfa quasi tutte le caratteristiche di un microservizio, quindi è facile da utilizzare.
La “ricerca catalogo” implementata si basa su microservizi generici che sfruttano Anypoint per la gestione delle API e la logica di orchestrazione generale.
Il gruppo di componenti “UI Renderer” nell’Experience Layer sembra un po’ diverso. Data la complessità di un'attività di rendering, un componente dedicato dovrebbe essere in grado di scegliere il proprio modello di implementazione, scalabilità e distribuzione indipendente.
Mentre uno dei componenti utilizza un approccio simile al componente "Ricerca catalogo", altri si basano su un'App Mule e CloudHub autoScaling. Il gruppo “app” sul lato destro del “Process Layer” è simile. A seconda del tipo di funzionalità fornita da una determinata app, è possibile scegliere un modello diverso.
È probabile che un'implementazione di microservizi "pura" sia la prima scelta, ma dato che tutte le interfacce dei componenti sono gestite in modo chiaro tramite la soluzione di gestione delle API Anypoint Platform, questo può essere modificato senza influire sui consumatori di servizi esistenti.
Ultimo ma non meno importante, diamo uno sguardo al centro dell'architettura. Questa è la parte più simile a una tipica architettura SOA. Questo è il motivo per cui TideView ha deciso di scegliere questo approccio:
- la funzionalità complessiva si ottiene utilizzando più sistemi esistenti di terze parti e COTS che introducono i propri cicli di vita e di servizio;
- alcuni sistemi saranno eliminati o alla fine saranno migrati, quindi l'introduzione di livelli di astrazione aggiuntivi dovrebbe rendere questo processo molto più semplice e flessibile;
- tutti i sistemi hanno forti elementi transazionali nel proprio elenco di funzioni e la coerenza ha una rilevanza importante;
- l'utilizzo di un approccio orchestrato è un vantaggio e non un limite poiché questa situazione richiede la gestione di più sistemi e la loro transizione. L’approccio fornisce un ulteriore livello di controllo su un solo microservizio.
Le API utilizzate per aggregare le diverse API SOA-style non fanno riferimento a nessun componente aggiuntivo di implementazione, ma utilizzano le applicazioni attraverso un’implementazione “Modern API”.
Questo è un altro vantaggio della piattaforma Anypoint di MuleSoft rispetto alle classiche soluzioni di gestione delle API. Tali soluzioni solitamente forniscono solo un livello API-proxy e delegano l'implementazione ad altri componenti.
La differenza tra l'implementazione personalizzata e l'utilizzo di Anypoint Platform è che quest'ultima consente un approccio all'implementazione basato sulla configurazione, che incrementa l'efficienza di gestione riducendo il rischio di errori.
MuleSoft Anypoint Platform supporta anche strutture di team eterogenee. L'esempio seguente mostra come i diversi servizi potrebbero essere assegnati a diversi team che lavorano in modo indipendente, visualizzando le varie opzioni per gli obiettivi di distribuzione.
Anypoint Platform supporta distribuzioni ibride altamente granulari. MuleSoft può gestire il processo di distribuzione (inclusi CI / CD) e persino alcuni SLA (ad esempio HA / DR) su tutte le destinazioni di distribuzione.
Anypoint Exchange non solo fornisce molteplici connettori, modelli ed API, ma offre anche ai diversi team un repository per salvare, pubblicare, condividere e riutilizzare documentazione, modelli e best practice interne, risolvendo un altro problema associato ai progetti SOA.
Un altro aspetto che viene spesso frainteso in questo contesto è la frase "centrale". Anypoint Platform fornisce servizi da un'istanza di servizio centrale. Il servizio stesso supporta la multi-tenancy in modo che ogni gruppo possa progettare, integrare, esporre e gestire i propri servizi in modo indipendente l'uno dall'altro senza la necessità del supporto e della proprietà di un IT centrale.
Sono poche le restrizioni relative a dove sia possibile distribuire una determinata app Mule o un API proxy service. I team possono agire in maniera indipendente.
Tuttavia, la collaborazione è consigliata per promuovere il riutilizzo delle API tra i team. È qui che il modello C4E (Center For Enablement) introduce uno o più team overlay incaricati di guidare e gestire questo approccio. Ciò massimizzerà il valore e i vantaggi offerti dalla piattaforma Anypoint di MuleSoft e dall'approccio API-led connectivity.
Per scoprire di più su MuleSoft Anypoint Platform, invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250.
In alternativa, puoi compilare il form sottostante con la tua domanda.
