Dai monoliti ai microservizi alle Packaged Business Capability (PBC)

• Evoluzione architetturale: l’architettura applicativa si è evoluta da un approccio rigido e monolitico ad uno più agile (microservizi), per l’esigenza di più agilità e scalabilità.
• L’ascesa dei framework componibili: le aziende cercano di adottare sempre più framework componibili per affrontare le complessità e i disallineamenti talvolta riscontrati con i microservizi.
• Packaged Business Capability (PBC): le aziende componibili sfruttano le PBC, componenti software incapsulate che rappresentano funzionalità aziendali distinte e consentono una maggiore agilità aziendale.

L’architettura applicativa ha intrapreso un percorso di continua e rapida evoluzione, guidato dalla necessità di maggiore agilità, scalabilità e allineamento aziendale. Abbiamo assistito a un passaggio significativo dalle architetture monolitiche, in cui tutte le funzionalità sono strettamente integrate in una singola applicazione, verso approcci modulari più distribuiti.

L’ascesa dell’architettura a microservizi nell’ultimo decennio ha portato con sé la promessa di una migliore distribuzione delle applicazioni attraverso la riduzione dell’accoppiamento e la creazione di team indipendenti più efficienti. Tuttavia, molte aziende hanno dovuto affrontare complessità e sfide dovute a incomprensioni e aspettative non in linea che ruotano intorno ai microservizi.

Per questo motivo, molte più aziende hanno cominciato a sfruttare framework componibili che potessero essere più personalizzati e allineati alle esigenze aziendali, piuttosto che sistemare semplici problematiche tecniche, e che potessero anche fornire livelli di astrazione molto più elevati rispetto ai singoli microservizi. In sostanza, un framework componibile sfrutta le Packaged Business Capability (PBC).

Le PBC sono sul gradino successivo in questa scala evolutiva dell’architettura applicativa. Si tratta di componenti software incapsulati che rappresentano funzionalità aziendali ben definite. Una PBC raggruppa schemi di dati, servizi, API ed eventi, offrendo un approccio componibile alla creazione di applicazioni più incentrato sul business.

In questo articolo esploreremo la transizione dai monoliti ai microservizi e analizzeremo cosa sono le PBC e come stanno plasmando il futuro dell’architettura applicativa, consentendo la nascita di aziende componibili caratterizzate da una maggiore agilità.

Architettura monolitica: unità all-in-one

Nell’ambito dell’architettura software, le applicazioni monolitiche rappresentano un approccio tradizionale in cui tutte le funzionalità di un’applicazione, tra cui l’interfaccia utente, la logica di business e il livello di accesso ai dati, sono saldamente integrate in un’unica, ampia base di codice e distribuite come un’unica unità. Questi sistemi in genere funzionano con diversi moduli all’interno della stessa applicazione che interagiscono direttamente tra loro, spesso condividendo lo stesso spazio di memoria e le stesse risorse.

Sebbene questa soluzione possa offrire semplicità nello sviluppo e nell’implementazione iniziali per le applicazioni più piccole, la gestione dei monoliti diventa sempre più complessa con l’aumentare delle dimensioni e della complessità. Questo perché qualsiasi modifica, anche piccola, richiede la ridistribuzione dell’intera applicazione, aumentando il rischio di introdurre effetti collaterali indesiderati.

Esaminiamo alcune delle principali difficoltà e limitazioni riscontrate nelle applicazioni basate su architetture monolitiche:

• Manutenibilità: basi di codice di grandi dimensioni e strettamente interconnesse diventano sempre più difficili da comprendere, sottoporre a debug, modificare e aggiornare. Più sono grandi, più è difficile apportare modifiche senza modificare l’intero sistema.
• Velocità: apportare e distribuire anche piccole modifiche richiede la ridistribuzione dell’intera applicazione da zero, rallentando il ritmo di rilascio. Inoltre, alcuni elementi potrebbero essere compromessi, scoraggiando rilasci di aggiornamenti più frequenti.
• Scalabilità: è difficile scalare i singoli componenti di un monolite in modo indipendente, poiché tutti i servizi sono enormemente interdipendenti. Pertanto, è necessario scalare l’intera applicazione, anche se solo una parte è sottoposta a un carico elevato.
• Affidabilità: un errore in un modulo può potenzialmente causare il crash dell’intera applicazione a causa del forte accoppiamento.
• Adozione di tecnologie: introdurre nuove tecnologie o framework per funzionalità specifiche può essere difficile e rischioso, poiché potrebbe avere un impatto sull’intero sistema.
• Indipendenza del team: un forte accoppiamento può ostacolare il lavoro indipendente dei diversi team di sviluppo. 

Di fronte a queste limitazioni, le aziende hanno iniziato a esplorare nuovi modelli architetturali in grado di affrontare le sfide intrinseche dei sistemi monolitici. La necessità di maggiore agilità, cicli di distribuzione più rapidi e la possibilità di scalare in modo indipendente le singole parti di un’applicazione hanno spianato la strada per l’adozione di un nuovo approccio più distribuito: l’architettura a microservizi. Questo cambio di paradigma mirava a scomporre applicazioni complesse di grandi dimensioni in servizi più piccoli e autonomi, che potessero essere sviluppati, distribuiti e scalati in modo indipendente.

Microservizi: il primo passo evolutivo

In risposta ai vincoli delle architetture monolitiche, i microservizi hanno guadagnato terreno come nuovo modello architettonico, in gran parte alimentato dall’ascesa delle tecnologie cloud-native. I microservizi sono servizi di piccole dimensioni, indipendenti e debolmente accoppiati che cooperano per fornire funzionalità applicative, basandosi su un sistema distribuito per il loro funzionamento. La possibilità di sviluppare, implementare e scalare ogni servizio in modo indipendente, comunicando tramite API (Application Programming Interface), ha offerto vantaggi significativi rispetto ai sistemi monolitici.

L’adozione diffusa di piattaforme e tecnologie cloud come Kubernetes ha fornito una solida base per i microservizi. Kubernetes, in quanto sistema di orchestrazione dei container, ha semplificato l’implementazione, la gestione e la scalabilità di questi servizi distribuiti. Questa sinergia tra lo stile architetturale dei microservizi e le piattaforme cloud-native ha permesso alle aziende di ottenere maggiore agilità e cadenze di distribuzione più rapide.

Le piattaforme basate su Kubernetes offrono numerosi strumenti per semplificare lo sviluppo e l’orchestrazione dei microservizi in un ambiente cloud-native. La capacità di Kubernetes di orchestrare i microservizi containerizzati si traduce in un utilizzo più efficiente delle risorse e in un migliore isolamento degli errori, poiché i team possono gestire i propri servizi in modo indipendente, a differenza delle applicazioni monolitiche. Questo è fondamentale per i processi di sviluppo software, accelerando notevolmente il time-to-market delle applicazioni.

Benefici principali di un’architettura a microservizi

Vediamo alcuni dei vantaggi più evidenti dell’utilizzo di un’architettura basata sui microservizi:

• Agilità di sviluppo e flessibilità di distribuzione: i singoli microservizi possono cambiare più rapidamente perché sono distribuibili in modo indipendente, sono più piccoli e più facili da comprendere per gli sviluppatori. Ciò significa che gli sviluppatori possono lavorare simultaneamente su singoli componenti, consentendo un ritmo più ampio e flessibile di distribuzione di nuove funzionalità.
• Facilità di modifica: i microservizi traggono grandi vantaggi da solide pratiche di Continuous Improvement e Continuous Delivery (CI/CD). L’automazione operativa facilita distribuzioni sicure e ripetibili, il che a sua volta riduce la paura del cambiamento. Quindi, i microservizi sono più adatti per applicazioni che richiedono cambiamenti continui e un adattamento rapido ad esigenze aziendali in continua evoluzione.
• Autonomia del team: team più piccoli e autonomi possono gestire servizi specifici, consentendo loro di lavorare e rilasciare software secondo i propri tempi.
• Agilità aziendale: consentendo uno sviluppo e una distribuzione più rapidi e indipendenti, i microservizi possono contribuire a una maggiore agilità aziendale complessiva e alla reattività ai cambiamenti del mercato.
• Allocazione precisa delle risorse: ogni microservizio ha un ambito chiaramente definito, consentendo di allocare la capacità di elaborazione con precisione a funzioni specifiche.
• Migliore isolamento dell’elaborazione dei dati: i requisiti normativi e di protezione dei dati possono essere supportati implementando service boundary più rigorosi in un’architettura a microservizi.
• Scalabilità: i microservizi possono essere scalati in modo indipendente in base alla domanda e distribuiti su più server e infrastrutture, garantendo un utilizzo più efficiente delle risorse rispetto al ridimensionamento di un intero monolite.
• Affidabilità: il debole accoppiamento dei microservizi garantisce che un errore in uno di essi abbia un impatto minimo sull’applicazione complessiva e che sia quindi improbabile un’interruzione totale del sistema.

I microservizi sembrano la soluzione definitiva per lo sviluppo di applicazioni. Quindi, come siamo arrivati ​​alle PBC? Continuate a leggere per saperne di più sull’evoluzione delle architetture applicative.

Ripensare la distribuzione delle applicazioni moderne: Packaged Business Capability (PBC)

Numerose complessità sono emerse da incomprensioni e applicazioni errate dei microservizi. Sebbene il loro scopo principale fosse quello di migliorare l’agilità e la velocità del cambiamento, molti hanno iniziato a considerarli un catalizzatore di riutilizzabilità, etichettando impropriamente qualsiasi servizio o API come microservizio. Ciò ha spesso portato a numerose sfide architetturali e ad aspettative contrastanti da parte degli stakeholder, al punto che l’uso diffuso, spesso indiscriminato, dei microservizi è stato sempre più messo in discussione.

Complessità, utilizzo eccessivo e altre sfide hanno spinto molte aziende a tornare a modelli monolitici, più gestibili e adatti a determinate situazioni. Ma la verità è che non esiste una verità universale: la necessità e l’implementazione di un’architettura specifica dovrebbero sempre essere il risultato di una valutazione critica approfondita.

Per affrontare queste problematiche sono emerse le Packaged Business Capability (PBC). Ma cosa sono essenzialmente le PBC? In sostanza, si tratta di componenti software incapsulate che rappresentano funzionalità aziendali distinte, in modo da essere facilmente riconoscibili dall’azienda stessa e dagli utenti. Questo passaggio alle PBC rappresenta un passo fondamentale verso un approccio componibile più incentrato sul business.

Una PBC in genere consiste in una funzionalità aziendale principale con dati e metadati incapsulati, ruoli/persone, API necessarie e canali evento associati. Questi moduli rilevabili si allineano alle funzioni aziendali, includono alcuni microservizi e sono più piccoli di applicazioni complete.