Quattro scelte di architettura per lo sviluppo delle applicazioni nell'era digitale

Conosciamo tutti l'architettura delle applicazioni a 3 livelli: si tratta di un'architettura client-server con una struttura tipica costituita dal livello di presentazione, dal livello dell'applicazione e dal livello del database.

Dispone di un'interfaccia utente, di una logica di accesso aziendale ai dati e dell'accesso ai dati. Molte applicazioni aziendali sono state create utilizzando la semplice architettura delle applicazioni a 3 livelli.

In parole povere, il modello di applicazione a 3 livelli è obsoleto. È stato progettato per lo sviluppo di applicazioni prima della proliferazione del cloud pubblico e delle applicazioni mobili e ha avuto difficoltà ad adattarsi al cloud.

Nel tempo, un'applicazione può diventare troppo grande e complessa per apportare modifiche frequenti. Non solo, ma richiede anche la manutenzione di almeno tre livelli di hardware e software, il che può essere inefficiente per l'azienda. 

Il modello di applicazione a 3 livelli è spesso chiamato anche architettura monolitica. Al giorno d'oggi, abbiamo diversi nuovi modelli di architettura e, di seguito, ne esamineremo alcuni che sono ora disponibili nell'era del cloud.

In un modello cloud, le applicazioni complesse progettate come raccolta di servizi e dati sono completamente disaccoppiate dall'applicazione. I microservizi sono uno stile architettonico che struttura l'applicazione come una raccolta di servizi. Ogni servizio può essere scritto in un linguaggio di programmazione diverso e testato separatamente. Sono implementabili in modo indipendente e organizzati in base alle funzionalità aziendali.

Prendiamo l'esempio di un'applicazione di e-commerce sviluppata utilizzando l'architettura a microservizi. Ogni microservizio può concentrarsi su una singola funzionalità aziendale (ad esempio, carrello, ricerca, recensione dei clienti). Ognuno di questi può essere un servizio separato scritto in linguaggi di programmazione diversi, implementato in infrastrutture diverse e gestito da team diversi.

Ogni servizio comunica con gli altri utilizzando un protocollo leggero. Per quanto riguarda i livelli 3, conosciamo tutti il framework Model View Controller (MVC). Sidecar, Ambassador e Adapter sono alcuni dei framework che supportano le architetture di microservizi.

Architettura dei microservizi e architettura monolitica

In un'architettura monolitica, tutti questi componenti coesistono come un unico modulo gestito (principalmente) da un unico team: tutto è raggruppato insieme. Se è necessario eseguire l'aggiornamento, è necessario implementare l'intera applicazione e questo rallenta le modifiche per le applicazioni complesse più grandi. Per le applicazioni più piccole, l'architettura monolitica è spesso la soluzione migliore.

Microservizi, container e Kubernetes

Una delle scelte migliori per creare ed eseguire architetture applicative di microservizi è l'uso dei container. I container racchiudono un ambiente di tempo di esecuzione di virtualizzazione leggero per l'applicazione e consentono di spostare l'applicazione dal desktop dello sviluppatore fino alla distribuzione in produzione. Può eseguire i container su macchine virtuali o fisiche nella maggior parte dei sistemi operativi disponibili. I container presentano un ambiente software coerente ed è possibile incapsulare tutte le dipendenze dell'applicazione come unità distribuibile. I container possono essere eseguiti su un laptop, su un bare metal server o in un cloud pubblico.

Molte organizzazioni utilizzano Kubernetes per gestire i container e garantire che non ci siano tempi di inattività. Kubernetes fornisce l'orchestrazione dei container in più host e viene utilizzato per la gestione del ciclo di vita dei container. Con Kubernetes puoi automatizzare la distribuzione, auto-scalare la tua applicazione, costruire velocemente e spedire velocemente.

Per un approfondimento su Kubernetes, guarda il nostro video "Spiegazione di Kubernetes":

Red Hat OpenShift è una delle piattaforme di container aziendali di hybrid cloud più diffuse. Molti provider di cloud pubblico offrono Container-as-a-Service (CaaS). Alcuni degli altri motori Kubernetes disponibili sono IBM® Cloud Kubernetes Service, Kubernetes open source, AWS (EKS, ECS e Fargate), Google GKS e Azure AKS.

Di solito, ogni microservizio è creato da un piccolo team diverso che sceglie il linguaggio di programmazione e il programma di implementazione. Una service mesh come Istio viene utilizzata dalle aziende per governare la comunicazione tra i microservizi e la gestione. In una service mesh, le richieste vengono instradate tramite proxy (ad esempio Sidecar) tra microservizi.

L'architettura cloud-native è progettata specificamente per le applicazioni che pianificano di essere implementate nel cloud e i microservizi sono una parte critica.

Cloud-native è un approccio alla creazione e all'esecuzione di applicazioni che utilizza i vantaggi del modello di distribuzione del cloud computing. Cloud-native è un termine usato per descrivere gli ambienti basati su container e riguarda il modo in cui le applicazioni vengono create e implementate, non dove.

Le tecnologie cloud-native ci consentono di eseguire applicazioni in cloud pubblici, privati e hybrid cloud. Lo sviluppo cloud-native è essenziale per portare rapidamente le applicazioni sul mercato: aiuta le persone, i processi e le tecnologie a creare, distribuire e gestire app pronte per il cloud.

Il modello di architettura cloud-native usa DevOps, integrazione continua (CI), distribuzione continua (CD), microservizi e container. La maggior parte delle aziende utilizza la metodologia a dodici fattori per la progettazione di applicazioni cloud-native scalabili e robuste.

Nel cloud, le applicazioni devono essere in grado di essere eseguite contemporaneamente in più nodi, condividere uno stato di configurazione/sessione, avere un meccanismo di registrazione centralizzato e poter essere distribuite utilizzando DevOps e un processo CI/CD. Molti provider di cloud forniscono linee guida per lo sviluppo cloud-native: Amazon Web Services (AWS) ha il suo framework, Google ha varie guide su come creare applicazioni cloud-native, e Microsoft Azure ha la sua guida ai modelli cloud.

Di solito, le applicazioni cloud-native sono stateless per natura. I servizi comunicano tra loro utilizzando protocolli o messaggistica basati su REST. L'API Gateway, il container registry, il middleware orientato ai messaggi (MOM: Publish/Subscribe o Request/Response), la service mesh e le orchestrazioni potrebbero far parte dell'architettura cloud-native.

L'architettura basata sugli eventi (EDA) si basa su sistemi disaccoppiati che vengono eseguiti in risposta agli eventi. Un'architettura basata sugli eventi utilizza gli eventi per attivare e comunicare tra servizi disaccoppiati. L'EDA è qui da molto tempo, ma ora ha più rilevanza nel cloud.

Allora, cosa c'è di nuovo? Se utilizzato correttamente, può fornire un aumento significativo dell'agilità, dei risparmi sui costi e dei benefici operativi. L'EDA serverless distribuita può eseguire codice noto come funzioni che si ridimensionano automaticamente in risposta a un'API REST o a un trigger di eventi.

Per il modello serverless, non è necessaria la gestione del server. Il modello serverless è anche rapidamente scalabile (quindi sono possibili aggiornamenti e distribuzioni rapide) ed è stateless.

Ecco alcuni dei servizi cloud serverless attualmente disponibili da diversi provider di cloud:

Tipi di serverless

• Functions-as-a-Service (FaaS): carica pezzi di funzionalità nel cloud e lascia che questi pezzi vengano eseguiti in modo indipendente.
• Backend-as-a-Service (BaaS): utilizza servizi di terze parti, come la gestione delle applicazioni, la gestione dei database e l'archiviazione cloud.
• Mobile-Backend-as-a-Service (MBaaS): funzioni per applicazioni mobili.

Come possiamo far funzionare bene le applicazioni monolitiche in un ambiente cloud? L'architettura cloud è più adatta per la creazione di un'applicazione web moderna (siti web statici/dinamici), implementare un'applicazione web, la connessione a un database e l'analisi del comportamento degli utenti.

Un'architettura applicativa tradizionale basata su cloud prevede bilanciatori di carico, server web, server di applicazioni e database. Può trarre beneficio dalle caratteristiche del cloud, come l'elasticità delle risorse, il networking definito dal software, il provisioning automatico, l'alta disponibilità e la scalabilità.

Questo tipo di architettura è ideale per le organizzazioni che non devono preoccuparsi della manutenzione di un server. Le funzioni serverless supportano diversi linguaggi di programmazione, come PHP, Java, .NET, Node.js, Python, Ruby, Docker e Go.

API gateway è un servizio importante che facilita agli sviluppatori la creazione e la pubblicazione di API sicure. Le API fungeranno da porta d'ingresso per le applicazioni per accedere ai dati e alla logica di business. Si occupa anche dell'autorizzazione e del controllo degli accessi. Gli sviluppatori utilizzano API gateway per invocare diverse funzioni serverless per diverse chiamate API.

La decisione che prendi quando scegli un modello di architettura può influenzare il successo o il fallimento del tuo progetto. La scelta deve essere effettuata in base all'applicazione e ai requisiti non funzionali. Ad esempio, non sceglierai di prendere l'aereo per percorrere solo pochi chilometri.

Prima di scegliere un'architettura per il progetto dell'app, tieni presente quanto segue:

• È monolithic-first o microservice-first? (Per i progetti più piccoli con un requisito di applicazione semplice, la scelta giusta può essere quella del monolito).
• Il tuo team è pronto a utilizzare i microservizi?
• Il tuo team dispone di un processo esistente DevOps e CI/CD basato sul cloud?
• Qual è il tuo modello di hosting? Privato, pubblico, ibrido?
• In che modo l'architettura dell'applicazione influisce sul tuo progetto?
• La combinazione di più modelli architettonici funziona per te?
• Hai bisogno di persistenza e sessioni per le tue applicazioni?

L'architettura delle applicazioni Web continua a evolversi per soddisfare i requisiti del business digitale e l'ambiente dell'infrastruttura IT in evoluzione. Tecnologie come l'intelligenza artificiale, l'analytics, l'automazione, la robotica avanzata, l'edge computing, la blockchain, l'Internet of Things (IoT) e le API stanno ridefinendo ciò che è possibile in molti settori. L'aumento della complessità dell'infrastruttura, delle applicazioni e delle dimensioni dei dati richiede nuovi approcci all'architettura. La maggior parte delle aziende sta adottando un approccio multicloud utilizzando uno o più provider cloud. Le aziende consumano servizi cloud utilizzando modelli privati, pubblici o ibridi con modelli SaaS, PaaS o IaaS.

In passato, l'implementazione delle applicazioni era un processo difficile e non poteva essere eseguito durante il normale orario di lavoro. Tuttavia, diversi metodi di implementazione (come la distribuzione blue-green e canary) insieme a DevOps e CI/CD (integrazione e distribuzione continua) ora consentono la distribuzione in qualsiasi momento senza interruzioni dell'applicazione.

Le architetture monolitiche sono ancora valide per molte applicazioni, ma è necessario utilizzare l'architettura giusta per il caso d'uso digitale per ottenere agilità e time-to-market. Per un'applicazione semplice, scegli di un approccio monolitico tradizionale. I modelli cloud-native o microservizi funzionano benissimo per le applicazioni in evoluzione con complessità. L'architettura a microservizi ha senso quando ci sono più team esperti che usano più linguaggi e pianificazioni di implementazione. Di seguito viene fornito un confronto tra le applicazioni tradizionali a 3/N livelli e i modelli di architettura basati su cloud come riferimento.

Per iniziare, iscriviti a un IBMid e crea il tuo account IBM Cloud.