Con l'adozione di DevOps, le organizzazioni hanno riconosciuto che spostando le decisioni e le attività alle prime fasi del ciclo di vita dello sviluppo, possono identificare e ridurre i rischi nei loro progetti di sviluppo. Questo processo è spesso definito "spostamento a sinistra". Di conseguenza, agli sviluppatori moderni viene chiesto di fare di più per fornire funzionalità ai propri clienti. Devono progettare architetture software scalabili, sviluppare codice sicuro ed efficiente, configurare l'infrastruttura, eseguire test, eseguire il deployment, monitorare le applicazioni e molto altro ancora. Sebbene questo approccio offra molti vantaggi, lascia anche agli sviluppatori meno tempo per concentrarsi sulla scrittura del codice, il che potrebbe causare effetti indesiderati sulla qualità del software o ritardi nel rilascio di nuove funzionalità.
Allo stesso modo in cui i DevOps Engineer si concentrano sull'ottimizzazione della distribuzione del software ai clienti esterni, in qualità di tecnico di piattaforma il tuo obiettivo è creare una piattaforma per offrire esperienze coerenti e fluide ai tuoi clienti interni (in altre parole, gli sviluppatori). Come si crea una piattaforma interna? Le tue attività quotidiane dovrebbero includere la creazione di esperienze standardizzate per i tuoi sviluppatori che consentano l'autonomia. In questo modo riduci il sovraccarico cognitivo per i tuoi clienti interni durante lo sviluppo e il deployment di nuovi servizi. Una piattaforma interna per sviluppatori incorpora determinati standard, decisioni e processi per creare percorsi aurei per gli sviluppatori. In questo modo possono concentrarsi sulla programmazione, creando esperienze software migliori per i clienti. In altre parole, oltre allo spostamento a sinistra, le organizzazioni dovrebbero anche eseguire lo "spostamento verso il basso" e trasferire un maggiore responsabilità verso il basso nella loro piattaforma:
Quando sviluppi API per consentire ai tuoi sviluppatori di sfruttare appieno le tue piattaforme, devi:
Un'ottima applicazione è efficace e coerente nella fornitura di beni e servizi. Nasconde la complessità ed è semplice e piacevole da usare. L'obiettivo finale dovrebbe essere sempre quello di offrire un'ottima esperienza all'utente, e le organizzazioni che creano prodotti di successo iniziano sempre da un approccio "outside-in", pensando principalmente agli utenti. Per offrire un'ottima esperienza è necessario consentire agli sviluppatori di creare applicazioni stimolanti e per ottenerlo è fondamentale fornire loro API di qualità. Le API efficaci eliminano le complessità dell'organizzazione, consentendo agli sviluppatori di concentrarsi sulla creazione dell'esperienza utente. Tuttavia, questo tipo di API non nasce dal nulla. Queste organizzazioni trattano anche le proprie API come prodotti digitali, dedicando interi team alla loro creazione e gestione come una funzionalità chiave delle proprie piattaforme.
Anche la piattaforma utilizzata da uno sviluppatore per creare prodotti digitali deve essere trattata come un prodotto e, in quanto tale, anche i team di platform engineering dovrebbero adottare un approccio "outside-in" con i propri utenti, gli sviluppatori, per comprenderne le esigenze e creare un'esperienza semplificata per loro. In qualità di platform engineer, è tua responsabilità creare, sviluppare e unificare gli strumenti e i modelli interni che i tuoi sviluppatori utilizzeranno durante la creazione del software, indipendentemente dal fatto che stiano sviluppando app frontend e servizi di backend o che producano e utilizzino API. Il ruolo del tuo team è stabilire in che modo il software che l'organizzazione sta creando deve essere testato, protetto, implementato e gestito. L'eliminazione dei silos consente di migliorare la creazione delle API.
Come per altri aspetti dello sviluppo del software, il tuo team dovrebbe scoraggiare gli sviluppatori dal ricreare singolarmente elementi di architetture API che rappresentano problemi trasversali. Offri loro una serie di semplici strumenti e opzioni di configurazione che possono sfruttare subito. Alcuni aspetti della gestione delle API che vengono gestiti al meglio dalla tua piattaforma includono, a titolo esemplificativo:
Apigee è una piattaforma di gestione delle API che fornisce ai team delle piattaforme e ai loro clienti interni una serie di funzionalità per creare, gestire e usare le API in modo più efficace:
Apigee aiuta i produttori di API a creare e gestire le API che espongono la loro logica di business fornendo ulteriori livelli di sicurezza, rilevamento e osservabilità agli sviluppatori. I team di prodotto possono raggruppare e pubblicare le proprie API come set flessibili di "prodotti", con comportamenti di consumo variabili. Apigee aiuta inoltre i consumatori delle API a scoprire facilmente quali prodotti API sono disponibili, sfogliare la documentazione e iniziare rapidamente a sviluppare applicazioni con il minimo sforzo. Ora, con l'aiuto dell'AI generativa, Apigee sta anche reimmaginando il modo in cui vengono sviluppate le API, semplificando per gli sviluppatori nuovi ed esperti la gestione delle comunicazioni tra i loro sistemi.
Il processo di gestione delle API in Apigee inizia con la creazione di proxy API. Un proxy API espone l'interfaccia utilizzata dagli sviluppatori per accedere ai servizi di backend. Anziché utilizzare direttamente questi servizi, accedono a un proxy API Apigee creato dal producer. Con un proxy puoi disaccoppiare il backend dall'API effettiva, offrendo al cliente un'esperienza più affidabile. In questo modo puoi aggiornare e apportare modifiche al backend senza influire sul cliente. I team API possono sfruttare le funzionalità fornite dal proxy per proteggere e controllare il comportamento delle proprie API. Affinché un programma API possa essere scalato correttamente man mano che il numero di team di produzione e consumo aumenta, la piattaforma deve abilitare percorsi aurei attraverso pipeline di automazione senza interruzioni e funzionalità riutilizzabili.
Supponiamo che la tua azienda voglia creare nuove API da monetizzare per generare entrate aggiuntive. Il tuo team si riunisce con gli sviluppatori per elaborare una strategia completa su come creare queste nuove API. Il compito del tuo team ora è di accettare questi requisiti e standardizzarli sotto forma di modelli API "guidati" contenenti criteri comuni, controlli di routing del traffico e convenzioni di gestione degli errori. A seconda del caso d'uso, potrebbero essere disponibili insiemi di modelli per ogni caso d'uso. Un caso d'uso comune potrebbe essere fornire criteri di memorizzazione nella cache o trasformazione per i backend legacy in esecuzione in ambienti on-prem. Il repository apigee-samples è ideale per iniziare, mentre il nostro repository DevRel contiene anche modelli di proxy di esempio come riferimento. Oltre ai modelli di criteri, i team delle piattaforme possono anche standardizzare le pipeline che gli sviluppatori utilizzeranno per creare ed eseguire il deployment dei proxy. Apigee offre strumenti e API di gestione che puoi sfruttare per creare pipeline CI/CD a supporto di questi percorsi aurei. Abbiamo pubblicato delle implementazioni di riferimento che puoi utilizzare come punto di partenza.
Una pipeline del proxy API MVP del codice sorgente potrebbe essere simile a questa:
Inoltre, la pipeline potrebbe registrare l'API in un catalogo interno, come l'hub API di Apigee. L'hub API è uno strumento che aiuta le organizzazioni a documentare, trovare e pubblicare informazioni sulle proprie API. Il registry integrato nell'hub contiene informazioni dettagliate su ogni versione di un'API nel corso del suo ciclo di vita, comprese le specifiche associate, i deployment attuali, la proprietà e i dati di contatto, le dipendenze e molto altro ancora. Oltre alle proprietà integrate, i clienti possono definire le tassonomie che gli utenti possono cercare e filtrare. Per contribuire a migliorare qualità e coerenza, l'hub API offre anche prospetti che consentono agli sviluppatori di comprendere meglio in che modo le progettazioni delle API si adattano agli standard previsti. Il registry dell'hub API può essere sincronizzato con portali interni per sviluppatori, come Backstage, o altri strumenti della piattaforma interna per sviluppatori.
Infine, per i consumatori esterni, la pipeline può pubblicare i prodotti API in un portale API pubblico insieme a documentazione e guide utente aggiuntive, il tutto con stili e branding personalizzati.
Quando si creano API su larga scala, una best practice consiste nel riutilizzare i criteri comuni per aumentare la velocità di sviluppo e ridurre i tempi di consegna. In Apigee, i flussi condivisi consentono di applicare la standardizzazione e la coerenza tra le tue API. Con i flussi condivisi puoi combinare criteri e risorse e condividerli tra più proxy API utilizzando un criterio FlowCallout o gli hook di flusso. I flussi condivisi vengono spesso sviluppati separatamente dai proxy API, in genere dal team della piattaforma o dagli esperti in materia responsabili di determinate aree. Ad esempio, potresti sviluppare un flusso condiviso che acquisisca un set standard di campi di richiesta e risposta e li scrive in Cloud Logging. Un altro esempio può essere un flusso di gestione degli errori che restituisce messaggi di errore e codici standardizzati o un flusso di autenticazione che si integra con un provider di identità di terze parti. Lo sviluppo di flussi condivisi può essere automatizzato, testato e implementato utilizzando gli stessi strumenti e concetti dei proxy API. Alcuni altri esempi di flussi condivisi comuni sono disponibili qui.
GitOps è diventato popolare durante l'ascesa di DevOps. Questo framework sfrutta best practice come l'utilizzo del controllo della versione tramite Git, le richieste di pull, le pipeline CI/CD, l'automazione e i criteri di conformità. Consulta questo blog per informazioni dettagliate sulle best practice per la distribuzione delle API. Queste pratiche possono essere integrate in percorsi aurei per gli sviluppatori. Ad esempio, uno sviluppatore potrebbe progettare un'API utilizzando Duet AI per creare una specifica OpenAPI prima di eseguirne il push a un ramo di funzionalità, attivando così una richiesta di pull. Dopo l'approvazione e l'unione della richiesta di pull, la pipeline CI/CD viene avviata automaticamente e il processo viene ripetuto per ogni ambiente. In Apigee, i team della tua piattaforma possono creare organizzazioni e ambienti separati per eseguire il deployment e testare i proxy man mano che progrediscono nel ciclo di vita dello sviluppo. Utilizzando una strategia GitOps, ogni ramo del repository Git può essere mappato a un ambiente Apigee.
I clienti che utilizzano il modello di pagamento a consumo di Apigee possono scegliere tra diversi tipi di ambiente con capacità differenti e possono creare una gamma di tipi di ambiente per diversi casi d'uso.
Ospitando il proxy e il codice di flusso condiviso nei repository di origine e utilizzando GitOps, puoi creare percorsi aurei "guidati" per gli sviluppatori di API, consentendo loro di concentrarsi sulla progettazione di API efficaci e sull'implementazione della logica di business sottostante. Per un'ulteriore semplificazione, gli sviluppatori possono anche sviluppare e testare localmente il plug-in Cloud Code per VS Code.
L'aumento della collaborazione tra lo sviluppatore e il team della piattaforma libera gli sviluppatori dal carico di occuparsi di tutto da soli. Riducendo la complessità, lo sviluppatore può concentrarsi su ciò che sa fare meglio e, di conseguenza, offrire un'esperienza migliore al cliente. Trattare le tue API e la tua piattaforma come prodotti della tua organizzazione aumenterà autonomia, velocità, qualità e innovazione. Seguendo le strategie descritte sopra, puoi ridurre il carico dei tuoi sviluppatori e aiutarli a creare API migliori. Iniziamo? Puoi registrarti gratuitamente e iniziare a creare contenuti nella tua sandbox gratuita. Vuoi informazioni più dettagliate sui prezzi? Scopri i nuovi prezzi di Apigee e utilizza le nostre risorse per iniziare a incorporare la gestione delle API nella tua piattaforma per sviluppatori.