Jump to section

Cos'è un'architettura applicativa?

Copia URL

Con architettura applicativa si intendono i modelli e le tecniche utilizzate per progettare e realizzare un'applicazione. Il piano d'azione e le best practice che l'architettura offre sono necessari per riuscire a ottenere un'applicazione ben strutturata.

I modelli di progettazione software possono agevolare la realizzazione di un'applicazione. Un modello descrive una soluzione ripetibile a un problema.

Collegando insieme i modelli, è possibile ottenere architetture applicative generiche. Anziché creare un'architettura completamente nuova, puoi avvalerti dei modelli esistenti, che forniscono inoltre un'ulteriore garanzia rispetto al corretto funzionamento del sistema.

Un'architettura applicativa prevede servizi front-end e servizi back-end. Lo sviluppo front-end si occupa dell'esperienza dell'utente dell'app, mentre lo sviluppo back-end si incentra sull'accesso ai dati, ai servizi e agli altri sistemi esistenti che consentono il funzionamento dell'app.

L'architettura costituisce il punto di partenza o la strategia per la realizzazione di un'applicazione; occorre però effettuare alcune scelte di implementazione che prescindono dall'architettura stessa. Una delle prime scelte è ad esempio quella del linguaggio di programmazione con il quale scrivere l'applicazione.

Nello sviluppo software sono impiegati numerosi linguaggi di programmazione, alcuni utilizzati per realizzare tipologie specifiche di applicazione, ad esempio Swift per le app mobile o JavaScript per lo sviluppo front-end. 

Usato insieme ad HTML e CSS, JavaScript è uno dei linguaggi di programmazione più diffusi per lo sviluppo di applicazioni web. 

Altri linguaggi comunemente utilizzati sono Ruby, Python, Swift, TypeScript, Java, PHP ed SQL. Il tipo di applicazione, le risorse di sviluppo disponibili e i requisiti sono tutti elementi che determinano la scelta del linguaggio di programmazione da impiegare. 

Convenzionalmente, le applicazioni sono state scritte con un'unica unità di codice, in cui i componenti condividono le stesse risorse e lo spazio di memoria. Questo stile di architettura viene definito monolite.

Le architetture applicative moderne sono spesso a basso livello di associazione, utilizzano microserviziinterfacce di programmazione delle applicazioni (API) per connettere i servizi, fornendo così la base per creare applicazioni cloud native. 

Lo sviluppo cloud native consente di accelerare la realizzazione di nuove applicazioni, ottimizzare quelle esistenti e offrire un'esperienza uniforme e automatizzata di sviluppo e gestione nei cloud pubblici, privati e ibridi.

Per decidere il tipo di architettura applicativa da utilizzare per una nuova applicazione, o quando si valuta quella in uso, il primo passo da compiere è stabilire gli obiettivi strategici.

Solo seguendo questo piano d'azione è possibile progettare un'architettura in grado di supportare gli obiettivi, evitando di sceglierne prima una e poi cercare di realizzare un'applicazione che si adatti alla struttura di arrivo. 

Sono aspetti da considerare la frequenza di rilascio degli aggiornamenti finalizzati a soddisfare le esigenze operative o dei clienti, e le funzionalità richieste dagli obiettivi di business o dalle esigenze di sviluppo. 

La capacità di fornire con rapidità nuovi servizi e nuove funzionalità ai clienti è uno dei principali elementi di differenziazione dalla concorrenza che un'azienda può offrire. L'accelerazione dello sviluppo consente alle aziende di rilasciare con maggiore frequenza le nuove funzionalità, e di installare gli aggiornamenti non appena vengono rilevate nuove vulnerabilità.

Oggi esistono diversi tipi di architetture applicative, ma quelle più diffuse e basate sui rapporti tra i servizi sono oggi monolitiche e a più livelli (ad alto grado di accoppiamento), i microservizi (disaccoppiati), le architetture guidate dagli eventi e le Service Oriented Architecture (a basso grado di accoppiamento).

Un'architettura su più livelli ha una struttura tradizionale ed è in genere utilizzata per realizzare applicazioni on premise e di livello enterprise; è spesso associata alle app già esistenti.

In un'architettura di questo tipo, l'applicazione è costituita da tre o più strati o livelli, ognuno dei quali ha ruoli specifici. 

I livelli agevolano la gestione delle dipendenze e l'esecuzione delle funzioni logiche. Essendo disposti orizzontalmente, sono in grado di far riferimento solo al livello inferiore. 

Un singolo livello può interagire con il livello immediatamente inferiore o con uno qualsiasi dei livelli sottostanti. 

Un monolite è un altro tipo di architettura correlata ai sistemi esistenti e consiste in un singolo stack applicativo che contiene tutte le funzionalità presenti all'interno di quell'applicazione. Presenta un elevato grado di associazione sia nell'interazione tra i servizi sia nel modo in cui questi ultimi sono sviluppati e distribuiti. 

Aggiornare o ottenere la scalabilità di un singolo aspetto di un'applicazione monolitica ha ripercussioni sull'intera applicazione e sulla sua infrastruttura di base. 

Apportare una singola modifica al codice dell'applicazione implica un nuovo rilascio dell'intera applicazione. Per questo motivo, gli aggiornamenti e le nuove release avvengono solo una o due volte l'anno, e possono includere solo modifiche di normale manutenzione e non nuove funzionalità. 

Al contrario, per offrire una maggiore agilità, le architetture più moderne cercano di suddividere i servizi per funzionalità o capacità aziendale.

I microservizi sono sia un'architettura sia un approccio alla programmazione di software. Con i microservizi, le applicazioni vengono scomposte nei loro elementi più piccoli, indipendenti gli uni dagli altri. Ciascun componente, o processo, costituisce un microservizio.

Essendo distribuiti e a basso accoppiamento i microservizi non hanno ripercussioni uno sull'altro. Ciò rappresenta un vantaggio sia per la scalabilità dinamica sia per la tolleranza degli errori: la scalabilità consente di adattare ogni servizio in base alle esigenze, senza la necessità di un'infrastruttura complessa, e la tolleranza degli errori permette il verificarsi del failover di un servizio senza comprometterne altri.

Un'architettura di microservizi è la più idonea a erogare software di qualità più rapidamente. Consente infatti di sviluppare più microservizi in contemporanea, E dal momento che il deployment dei singoli servizi avviene in modo indipendente, non devi rigenerare o ridistribuire l'intera app dopo aver apportato le modifiche. 

Più sviluppatori saranno al lavoro contemporaneamente sui singoli servizi, senza dover aggiornare l'intera applicazione; le attività di sviluppo richiedono quindi meno tempo ed è possibile distribuire le nuove funzioni più spesso.

In combinazione con le API e i team DevOps, i microservizi containerizzati rappresentano la base delle applicazioni cloud native.

 

 

 

In un sistema event driven, l'acquisizione, la comunicazione, l'elaborazione e la persistenza degli eventi costituiscono i pilastri portanti della soluzione. Questa è la principale differenza rispetto a un modello request driven.

Per evento si intende qualsiasi avvenimento, o variazione, significativo nello stato del sistema hardware o software. La fonte di un evento può essere interna o esterna.

L'architettura guidata dagli eventi consente un livello minimo di accoppiamento delle applicazioni, l'opzione ideale per le architetture moderne e distribuite.

Un'architettura guidata dagli eventi è composta da producer eventi e consumer eventi. Il producer rileva o percepisce un evento e lo rappresenta come messaggio. Non conosce il consumer né l'esito dell'evento stesso.

Dopo il suo rilevamento, l'evento viene trasmesso dal producer eventi al consumer eventi attraverso i canali di eventi, dove una piattaforma di elaborazione degli eventi lo elabora in modo asincrono.

Un'architettura guidata dagli eventi può essere basata su un modello pub/sub o di flusso di eventi.

Il modello pub/sub si basa su sottoscrizioni a un flusso di eventi. Con questo modello, al suo verificarsi o in seguito alla sua pubblicazione, l'evento viene inviato ai sottoscrittori che devono essere informati.

In questo si differenza da un modello di flusso eventi, dove i consumer di eventi non sottoscrivono alcun flusso, ma possono leggere ogni parte del flusso e parteciparvi in qualsiasi momento.

Gli eventi vengono acquisiti dalle rispettive fonti, tra cui i dispositivi, le applicazioni e le reti dell'Internet of Things (IoT), man mano che si verificano e ciò consente ai producer e ai consumer eventi di condividere lo stato e le informazioni della risposta in tempo reale.

L'architettura Service Oriented (SOA) è uno stile ormai diffuso di progettazione software, simile a quello dell'architettura basata sui microservizi. 

Nell'architettura SOA le app sono strutturate in servizi riutilizzabili che comunicano fra loro tramite un Enterprise Service Bus (ESB). 

In questa architettura i singoli servizi sono incentrati su uno specifico processo aziendale e seguono un protocollo di comunicazione, tra cui SOAP, ActiveMQ o Apache Thrift, per essere esposti attraverso l'ESB. Complessivamente, questa suite di servizi integrata tramite un ESB viene utilizzata da un'applicazione front-end per offrire maggiori vantaggi a un'azienda o a un cliente.

Scopri gli altri vantaggi delle app cloud native.

Con le soluzioni Red Hat puoi migliorare l'agilità aziendale suddividendo le applicazioni monolitiche in microservizi, che possono essere gestiti e orchestrati. I dati che questi generano possono essere utilizzati dai team per offrire ai clienti soluzioni di qualità più rapidamente.  

Tenendo conto delle necessità di mercato future, diventa quindi possibile realizzare nuove applicazioni enterprise, e creare applicazioni cloud native agili e facilmente scalabili, integrandole da subito con tutte le funzioni aziendali.

Guarda questa serie di webinar per conoscere le opinioni degli esperti su come realizzare, eseguire, distribuire e rinnovare le applicazioni con una piattaforma dati di livello enterprise su Red Hat® OpenShift®.

Non occorre trasformare completamente i sistemi esistenti per ottenere vantaggi significativi. Grazie all'open source, agli standard open e alla nostra esperienza pluriennale, possiamo aiutarti a trovare la soluzione più adatta per la tua azienda.

Con la sua vasta offerta open source, che include Red Hat® Enterprise Linux®Red Hat OpenShift e Red Hat Application Services, Red Hat è il partner d'eccellenza per le aziende che puntano alla trasformazione per poter competere nei mercati software driven.

Keep reading

ARTICOLO

Stateful e stateless

La condizione di stateful o stateless di un elemento dipende dalla durata della registrazione dell'interazione con l'elemento stesso e dalle modalità di memorizzazione di questa informazione.

ARTICOLO

Cos'è Quarkus?

Quarkus è uno stack Java Kubernetes native realizzato per le macchine virtuali Java (JVM) e per la compilazione nativa, che ottimizza Java specificamente per i container.

ARTICOLO

Cos'è il serverless computing?

Il serverless computing è un modello di sviluppo cloud native che consente agli sviluppatori di creare ed eseguire applicazioni senza gestire i server.

Scopri di più sulle applicazioni cloud native

Prodotti

Una piattaforma applicativa aziendale che offre servizi verificati per consentire la distribuzione delle app sulle infrastrutture preferite.

Risorse

White paper

Panoramica di Red Hat sullo sviluppo cloud native

Ebook

Il percorso verso le applicazioni cloud native

EBOOK

Cloud native e cloud ibrido: come definire la tua strategia.

Formazione

Formazione gratuita

Developing Cloud-Native Applications with Microservices Architectures