Negli ultimi due anni si sente sempre pi\u00f9 parlare di architetture a microservizi<\/a> e della necessit\u00e0 di introdurre sistemi di API. Le API e l\u2019API Management esistevano in realt\u00e0 anche prima dell\u2019era dei microservizi e rispondevano all\u2019esigenza di realizzare integrazioni basate su web services non-micro<\/strong>, tipicamente REST e SOAP.<\/p>\n Che i microservizi ora stiano dando un\u2019ulteriore spinta verso la diffusione di architetture IT sempre pi\u00f9 orientate alle API<\/a> \u00e8 un dato di fatto. Non si possono per\u00f2 trascurare gli impatti organizzativi<\/strong> e le necessit\u00e0 di governance delle API\u00a0<\/strong>che emergono quando questi servizi diventano decine se non centinaia, quando rispondono a diversi layer e diverse funzioni aziendali, quando vengono sviluppati da team indipendenti e quando gli utilizzatori appartengono a tipologie diverse (interni, partner, esterni). Sono casi in cui la governance delle API diventa un passaggio necessario.<\/p>\n Possono sorgere quindi diversi tipi di sfide da gestire:<\/p>\n L\u2019API Gateway, oltre che essere un pattern architetturale, \u00e8 anche il componente di piattaforma principale a offrire funzionalit\u00e0 e supporto ai problemi di gestione delle API<\/a> come quelli di cui abbiamo appena parlato.<\/p>\n Quando una soluzione di questo tipo diventa necessaria per un\u2019organizzazione?<\/strong><\/p>\n Nel momento in cui le API diventano per l\u2019organizzazione uno strumento e un prodotto aziendale<\/strong>, non \u00e8 pi\u00f9 possibile pensare di non avere la governance del sistema<\/strong>: diventa chiara la necessit\u00e0 di adottare una soluzione di API Management <\/a>da introdurre all\u2019interno del proprio sistema IT.<\/p>\n Vediamo assieme alcune delle principali componenti o funzionalit\u00e0 che una piattaforma di API Management assolve<\/strong> a supporto della governance:<\/p>\n\n
Supportare la crescita con un API Gateway<\/h2>\n
\n
Gli strumenti di API Management a servizio della governance<\/h2>\n
\n
\n<\/strong>Come faccio a gestire un\u2019API deprecata? Oppure come gestisco API che evolvono e hanno bisogno di supportare vecchi e nuovi client? In che modo il nostro API Architect<\/strong> favorisce la prototipazione e la gestione di API in disuso o da dismettere? I componenti di API LifeCycle Management<\/strong> danno la possibilit\u00e0 di gestire tutto il ciclo di vita di un\u2019API e supportare sviluppi in ottica API first<\/strong> creando mock efficaci per la fase prototipale.<\/li>\n
\n<\/strong>In che modo posso garantire un accesso autenticato e autorizzato alle API? Come posso controllare chi ha accesso a determinate API, da un punto di vista di auditing ma anche per capire se un\u2019API \u00e8 ancora in uso? L\u2019API Architect deve garantire autenticazione, accessi autorizzati e flussi di autenticazione standard<\/strong> quali OAuth2 e OpenIDConnect attraverso componenti preposti a questa funzione come l\u2019API Gateway.<\/li>\n
\n<\/strong>In che modo garantisco una facile interoperabilit\u00e0<\/strong> con il mondo degli sviluppatori che possono ricoprire ruoli diversi (interni, partner, esterni) e avere accesso a API diverse a seconda dei vari layer architetturali<\/a>? L\u2019API Business Owner ha interesse che gli stakeholder reperiscano esempi funzionanti, documentazione, ambienti sandbox dove testare le implementazioni con velocit\u00e0 e facilit\u00e0 cos\u00ec da rendere costo-efficace e promuovere al tempo stesso l\u2019utilizzo delle API<\/strong>. Il developer portal<\/strong> \u00e8 un componente che affianca l\u2019API Gateway e che gioca un ruolo importante per censire gli utenti e le applicazioni che utilizzano le API e favorire la loro adozione.<\/li>\n
\n<\/strong>Come posso assicurare che le API rispondano con un adeguato livello di performance<\/strong>, che l\u2019infrastruttura sottostante sia resiliente e capace di sopportare picchi di carico<\/strong>? L\u2019API Architect definisce diversi livelli di servizio e ha l\u2019onere di mantenere sotto controllo l\u2019utilizzo dei sistemi sottostanti. Necessita quindi di strumenti di monitoraggio real time per agire tempestivamente al verificarsi di condizioni critiche e di componenti di monitoring<\/strong>, di alerting<\/strong> e di caching<\/strong> a supporto della IT governance operativa.<\/li>\n
\n<\/strong>Quale utente e quante App chiamano le API? e con quale frequenza? \u00c8 molto importante avere delle statistiche<\/strong> per capire come stanno funzionando le API, cos\u00ec come sapere quante API hanno generato disservizi<\/strong> e perch\u00e9. I componenti di API Analytics sono indispensabili all\u2019API Product Owner per tenere sotto controllo la qualit\u00e0 del servizio erogato, i livelli di utilizzo e la loro evoluzione nel tempo. Diventa necessario definire report e metriche utili a orientare la governance strategica nei confronti di un\u2019infrastruttura che deve adeguarsi alle esigenze di business dell\u2019azienda.<\/li>\n<\/ol>\n