Skip to main content

Che il futuro IT sia Cloud Native non è una novità: ne abbiamo parlato in diversi articoli e c’è una consapevolezza crescente nel settore. Questa transizione è già in atto da parte di moltissime aziende che, però, si ritrovano ad affrontare non pochi problemi come la convivenza tra architetture monolite – di vecchia generazione – e architetture cloud native – di nuova generazione –, e la scelta di prodotti leggeri che riescano a gestire in modo ottimale questa infrastruttura ibrida.

Leggi l’articolo se vuoi approfondire questo tema: il nostro esperto Denis Signoretto risponderà alle principali domande in merito alla gestione delle infrastrutture ibride, dando possibili soluzioni e consigli sugli API Gateway e sui Kubernetes Ingress Controller.

Q: Il passaggio verso un’architettura Cloud Native: quali sono i principali problemi da affrontare?

A: I problemi non sorgono quando parliamo di una start-up che in fase di costituzione adotta direttamente un’architettura IT di nuova generazione: sorgono nel momento in cui un’azienda già costituita – che ha sempre basato il proprio ambiente IT su una architettura tradizionale e monolitica – si trova nell’attuale panorama a dover fare i conti con nuove tecnologie e nuovi paradigmi, indispensabili per garantire adeguate performance, stabilità e continuità del business.

L’evoluzione verso architetture di nuova generazione richiede spesso un approccio nuovo e indipendente che va a generare un overhead sul reparto IT, il quale mal si coniuga con la necessità di Time To Market che già il business richiede per continuare a erogare nuove funzionalità; per di più, il modo di operare è cambiato: si è passati dal lavorare su un progetto per alcuni mesi a dover apportare piccoli cambiamenti in maniera costante, e per questo è necessaria un’architettura che rifletta queste nuove esigenze. I team IT soffrono quindi non solo la velocità richiesta per rilasciare nuove funzionalità, ma anche la convivenza tra architetture nuove e vecchie.

Non a caso, i limiti nascono spesso dalla impossibilità di coniugare prodotti e know-how di “vecchia generazione” con l’introduzione dell’automazione, della qualità e velocità di rilascio, della gestione sistemica dell’infrastruttura nonché dell’esecuzione di test nei vari stadi che le procedure di rilascio richiedono.

Q: C’è una possibile soluzione per gestire questo problema?

A: È importante scegliere prodotti innovativi e leggeri che spesso caratterizzano le architetture Cloud Native e che siano applicabili sia ai contesti tradizionali che a quelli cloud. Questa scelta può essere un fattore abilitante e facilitante nel gestire la transizione.

Scegliere prodotti di nuova generazione, che si integrano con l’infrastruttura in essere ma che nascono nativamente con funzionalità richieste dalle applicazioni Cloud Native – prodotti leggeri, orientati al DevOps e a una gestione IaC (Infrastructure as a Code) –, consente sia di impattare positivamente sull’esistente, sia di andare nella direzione di impadronirsi e sfruttare al meglio i “linguaggi nativi” che le applicazioni Cloud Native richiedono. Insomma, dei prodotti che sappiano gestire un’infrastruttura ibrida.  

API date

Evolvere e governare
le architetture IT

GUARDA L'EVENTO ON DEMAND

Q: Cosa si intende per infrastruttura ibrida? E quali possono essere alcune soluzioni per gestirla?

A: In ambito API, una infrastruttura ibrida significa avere una soluzione che combina sia componenti tradizionali (gli API Gateway) e sia componenti di nuova generazione (i Kubernetes Ingress Controller). In grado cioè di offrire una visione e una modalità di gestione unificata delle API, astraendole dall’infrastruttura tecnologica su cui sono implementate.

Ci ritroviamo in una situazione in cui le aziende non possono abbandonare totalmente la vecchia architettura, ma devono far convivere quella tradizionale con la nuova. Ciò significa riprendere le tematiche di API in sicurezza e dell’API Gateway utilizzando soluzioni che consentano di realizzare un’architettura ibrida e in un’ottica GitSecOps.

Clicca sull’immagine per ingrandire

Da questa immagine si può capire come un prodotto di nuova generazione – che sposa anche il vecchio – consenta di avere i vantaggi di un unico control plane dal quale amministrare tutto: i tool di monitoring, di alerting e il know-how sono riuniti in un prodotto solo piuttosto che dover gestire un insieme di prodotti; il tutto con un approccio volto all’automatizzazione sia sul sistema nuovo che su quello tradizionale.

Q: API Gateway e Kubernetes Ingress Controller: quali sono i loro punti di forza?

A: API Gateway e i tool di API Management centralizzano la gestione delle policy, dell’autenticazione e autorizzazione, disaccoppiano i client con l’implementazione dei servizi sottostanti, combinano soluzioni di API Portal per fruire la documentazione e gestiscono il ciclo di sviluppo con alcune importanti funzioni come ad esempio l’API mocking.

Dall’altro lato i Kubernetes Ingress Controller gestiscono l’accesso ai container, applicando dinamicamente regole di routing che consentono di indirizzare una chiamata esterna a Kubernetes e al rispettivo (micro)servizio/API, gestendo nativamente e in modo semplificato il load balancing e l’applicazione di policy.

Q: API Gateway e Kubernetes Ingress Controller possono convivere nella gestione di un’infrastruttura ibrida?

A: Nelle applicazioni e nelle API Cloud Native di nuova generazione, la scelta di prodotti che combinano sia funzioni di API Gateway tradizionali sia estensioni standard dei Kubernetes Ingress Controller, consente di ottenere il meglio dei due mondi, integrando in un’unica soluzione le funzionalità tipiche di load balancing e routing con l’applicazione di policy, rate limit e throttling – a salvaguardia dell’infrastruttura –, in congiunzione con i sistemi di traffic monitoring e alerting.

Quindi la risposta è sì, API Gateway e Kubernetes Ingress Controller possono convivere, allargando alla possibilità di realizzare una infrastruttura che offra una visione unificata di tutte le API indipendentemente dall’implementazione e dai sistemi che le eseguono, avvantaggiandosi del riutilizzo di una stessa infrastruttura di API Portal, di strumenti di API Management e di monitoraggio delle performance.

Questo significa avere riflessi che impattano positivamente anche sulle persone che gestiscono l’infrastruttura IT (sia per le figure DevOps che Operations) in quanto condividono know-how su un’unica soluzione tecnologica.

I vantaggi di una soluzione ibrida, dunque, non solo producono effetti sul piano tecnologico-architetturale, ma anche sul piano organizzativo gestionale del reparto IT.

Scopri di più sugli API Gateway durante lo speech dedicato del nostro evento API date: trovi on demand tutte le videoregistrazioni!

SCOPRI I CONTENUTI ON DEMAND
4.0/5.0 Article rating
5 Reviews
Cosa ne pensi dell'articolo?
  1. Amazing
  2. Good
  3. Bad
  4. Meh
  5. Pff
Denis Signoretto
IT Architect & Senior Project Manager

Esperto da oltre 20 anni di soluzioni software open source e sviluppatore certificato Liferay, Denis in Intesys è specializzato di API Design per lo sviluppo di architetture Headless.

NEWSLETTER