Questo documento descrive la popolare metodologia delle app a 12 fattori e come applicarla quando si sviluppano app in esecuzione su Google Cloud. Con questa metodologia puoi creare app scalabili e resilienti il cui deployment continuo può essere eseguito con la massima agilità.
Questo documento è rivolto agli sviluppatori che hanno familiarità con Google Cloud, il controllo delle versioni, l'integrazione continua e la tecnologia dei container.
Introduzione
Gli sviluppatori stanno spostando le app nel cloud e, in questo modo, acquisiscono maggiore esperienza nella progettazione e nel deployment di app cloud-native. Da questa esperienza è emersa una serie di best practice, comunemente note come dodici fattori, Progettare un'app tenendo presenti questi fattori ti consente di eseguire il deployment nel cloud di app più portabili e resilienti rispetto ad app distribuite in ambienti on-premise in cui il provisioning di nuove risorse richiede più tempo.
Tuttavia, la progettazione di app cloud-native moderne richiede un cambiamento di approccio alla progettazione, alla configurazione e al deployment del software rispetto alla progettazione di app per ambienti on-premise. Questo documento ti aiuta a capire come applicare i dodici fattori al design della tua app.
Vantaggi delle app a 12 fattori
La progettazione a 12 fattori aiuta anche a disaccoppiare i componenti dell'app, in modo da poter sostituire o fare lo scale up o lo scale down di ogni componente con facilità. Dato che i fattori sono indipendenti dal linguaggio di programmazione o dallo stack software, la progettazione a 12 fattori può essere applicata a un'ampia gamma di app.
I dodici fattori
1. Codebase
Devi monitorare il codice della tua app in un sistema di controllo della versione come Git o Mercurial. Per lavorare sull'app, devi controllare il codice nell'ambiente di sviluppo locale. L'archiviazione del codice in un sistema di controllo della versione consente al team di collaborare fornendo un audit trail delle modifiche al codice, un metodo sistematico per risolvere i conflitti di unione e la possibilità di eseguire il rollback del codice a una versione precedente. Fornisce inoltre il punto di partenza per l'integrazione continua (CI) e il deployment continuo (CD).
Anche se gli sviluppatori possono lavorare su diverse versioni del codice nei rispettivi ambienti di sviluppo, in qualsiasi momento la fonte attendibile è il codice nel sistema di controllo delle versioni. Il codice nel repository è ciò che viene creato, testato e distribuito. Il numero di repository è indipendente dal numero di ambienti. Il codice nel repository viene utilizzato per produrre una singola build, che viene combinata con la configurazione specifica dell'ambiente per produrre una release immutabile, una release in cui non è possibile apportare modifiche, anche alla configurazione, di cui può essere eseguito il deployment in un ambiente. Eventuali modifiche richieste per la release dovrebbero comportare una nuova release.
2. Dipendenze
Due aspetti da considerare riguardo alle dipendenze per le app a 12 fattori sono la dichiarazione e l'isolamento delle dipendenze.
Le app a 12 fattori non dovrebbero mai avere dipendenze implicite. Devi dichiarare esplicitamente tutte le dipendenze e controllarle nel controllo della versione. Ciò consente di iniziare a utilizzare il codice rapidamente e in modo ripetibile, semplificando il monitoraggio delle modifiche alle dipendenze. Molti linguaggi di programmazione offrono un modo per dichiarare esplicitamente le dipendenze, ad esempio pip per Python e Bundler per Ruby.
Dovresti anche isolare un'app e le sue dipendenze pacchettizzandole in un container. I container consentono di isolare un'app e le sue dipendenze dal relativo ambiente e di garantire che l'app funzioni in modo uniforme nonostante eventuali differenze tra gli ambienti di sviluppo e gestione temporanea.
Artifact Registry è un servizio di gestione privato degli artefatti completamente gestito che supporta vari tipi di artefatti come immagini container, pacchetti di linguaggio (come Maven e npm) e pacchetti di sistema operativo (come RPM). Per gestire i risultati delle build CI/CD e le rispettive dipendenze, puoi utilizzare Cloud IAM con Artifact Registry con controllo dell'accesso granulare. Artifact Analysis rileva le vulnerabilità nelle immagini container di cui è stato eseguito il push su Artifact Registry per garantire che il deployment delle immagini container sia sicuro.
Le integrazioni CI/CD esistenti ti consentono anche di configurare pipeline completamente automatizzate per ricevere feedback rapidi. Puoi eseguire il push delle immagini nel registro e, successivamente, eseguire il pull delle immagini utilizzando un endpoint HTTP da qualsiasi macchina, che si tratti di un'istanza di Compute Engine o del tuo hardware.
3. Configurazione
Ogni app moderna richiede una qualche forma di configurazione. In genere, disponi di configurazioni diverse per ogni ambiente, ad esempio sviluppo, test e produzione. Queste configurazioni di solito includono le credenziali degli account di servizio e gli handle delle risorse ai servizi di supporto come i database.
Le configurazioni di ogni ambiente devono essere esterne al codice e non devono essere controllate nel controllo della versione. Tutti funzionano su una sola versione del codice, ma tu hai più configurazioni. L'ambiente di deployment determina la configurazione da utilizzare. In questo modo, viene eseguito il deployment di una versione del programma binario in ciascun ambiente, dove l'unica differenza è la configurazione del runtime. Un modo semplice per verificare se la configurazione è stata esternalizzata correttamente è vedere se il codice può essere reso pubblico senza rivelare alcuna credenziale.
Un modo per esternalizzare la configurazione consiste nel creare i file di configurazione. Tuttavia, i file di configurazione sono in genere specifici di un linguaggio o framework di sviluppo.
Un approccio migliore consiste nel memorizzare la configurazione nelle variabili di ambiente. Questi valori sono facili da modificare per ciascun ambiente in fase di runtime, è improbabile che vengano inseriti nel controllo della versione e sono indipendenti dal linguaggio di programmazione e dal framework di sviluppo. In Google Kubernetes Engine (GKE), puoi utilizzare ConfigMaps. In questo modo puoi associare variabili di ambiente, numeri di porta, file di configurazione, argomenti della riga di comando e altri artefatti di configurazione ai container dei pod e ai componenti di sistema in fase di runtime.
Cloud Functions e Cloud Run supportano l'uso delle variabili di ambiente. Puoi esternalizzare le configurazioni e modificarle dalla console Google Cloud o utilizzando Google Cloud SDK.
4. Servizi di supporto
Ogni servizio utilizzato dall'app nell'ambito del suo normale funzionamento, ad esempio file system, database, sistemi di memorizzazione nella cache e code di messaggi, deve essere accessibile come servizio ed esternalizzare nella configurazione. Questi servizi di supporto sono da considerarsi come astrazioni per la risorsa sottostante. Ad esempio, quando l'app scrive dati nello spazio di archiviazione, trattare lo spazio di archiviazione come un servizio di supporto consente di modificare senza problemi il tipo di archiviazione sottostante, in quanto disaccoppiato dall'app. Puoi quindi eseguire una modifica come il passaggio da un database PostgreSQL locale a Cloud SQL per PostgreSQL senza modificare il codice dell'app.
5. Build, release, esecuzione
È importante suddividere il processo di deployment del software in tre fasi distinte: build, rilascio ed esecuzione. Ogni fase deve generare un artefatto identificabile in modo univoco. Ogni deployment deve essere collegato a una specifica release risultante dalla combinazione della configurazione di un ambiente con una build. Ciò consente rollback semplici e un audit trail visibile della cronologia di ogni deployment di produzione.
Puoi attivare manualmente la fase di build, ma di solito viene attivata automaticamente quando esegui il commit di codice che ha superato tutti i test richiesti. La fase di creazione prende il codice, recupera le librerie e gli asset richiesti e li pacchettizza in un programma binario o container autonomo. Il risultato della fase di build è un artefatto della build.
Una volta completata la fase di build, la fase di rilascio combina l'artefatto della build con la configurazione di un ambiente specifico. Questo produce una release. È possibile eseguire il deployment della release nell'ambiente tramite un'app di deployment continuo. In alternativa, puoi attivare la release tramite la stessa app di deployment continuo.
Infine, la fase di esecuzione avvia la release. Ad esempio, se stai eseguendo il deployment in GKE, Cloud Build può chiamare il passaggio di build gke-deploy per eseguire il deployment nel tuo cluster GKE. Cloud Build può gestire e automatizzare le fasi di build, rilascio ed esecuzione in più linguaggi e ambienti utilizzando file di configurazione di compilazione in formato YAML o JSON.
Inoltre, puoi utilizzare Cloud Deploy, un servizio completamente gestito, che offre la distribuzione continua in GKE, Cloud Run e GKE Enterprise. Con Cloud Deploy puoi creare una pipeline di distribuzione che include passaggi di approvazione e promozione immediata in più ambienti. Cloud Deploy supporta inoltre il rollback in un'unica fase di un'applicazione di cui è stato eseguito il deployment in qualsiasi destinazione.
6. Processi
Esegui app a 12 fattori nell'ambiente come uno o più processi. Questi processi devono essere stateless e non devono condividere dati tra loro. Ciò consente alle app di fare lo scale up attraverso la replica dei loro processi. La creazione di app stateless rende inoltre i processi portatili nell'infrastruttura di computing.
Se sei abituato al concetto di sessioni "fisse", devi cambiare il modo in cui pensi di gestire e conservare i dati. Poiché i processi possono scomparire in qualsiasi momento, non puoi fare affidamento sul fatto che i contenuti dello spazio di archiviazione locale siano disponibili o che eventuali richieste successive verranno gestite dallo stesso processo. Pertanto, devi rendere permanentemente tutti i dati che devono essere riutilizzati in un servizio di supporto esterno come un database.
Se devi mantenere i dati, puoi utilizzare Memorystore e Filestore come servizio di supporto per memorizzare nella cache lo stato per le tue app e condividere dati comuni tra i processi per favorire il basso accoppiamento.
7. Associazione di porte
In ambienti non cloud, le app web vengono spesso scritte per essere eseguite in container di app come GlassFish, Apache Tomcat e Apache HTTP Server. Al contrario, le app a 12 fattori non si basano su container di app esterni. Raggruppano la libreria dei server web come parte dell'app stessa.
Si tratta di una best practice sull'architettura che consente ai servizi di esporre un numero di porta,
specificato dalla
variabile di ambiente
PORT.
Le app che esportano l'associazione di porte possono utilizzare esternamente le informazioni sull'associazione di porte (come variabili di ambiente) quando si utilizza il modello Platform as a Service. In Google Cloud puoi eseguire il deployment di app su servizi di piattaforma come Compute Engine, GKE, App Engine o Cloud Run.
In questi servizi, un livello di routing instrada le richieste da un nome host visibile al pubblico ai processi web associati alla porta. Ad esempio, quando esegui il deployment delle tue app in App Engine, dichiari le dipendenze per aggiungere una libreria di server web all'app, ad esempio Express (per Node.js), Flask e Gunicorn (per Python) o Jetty (per Java).
Non inserire numeri di porta hardcoded nel codice. Devi invece fornire i numeri di porta nell'ambiente, ad esempio in una variabile di ambiente. In questo modo le tue app diventano portatili quando le esegui su Google Cloud.
Poiché Kubernetes ha Service Discovery integrato, in Kubernetes puoi astrarre le associazioni di porte mappando le porte di servizio ai container. Il Service Discovery si esegue utilizzando i nomi DNS interni.
Invece di impostare come hardcoded la porta su cui il server web rimane in ascolto, la configurazione utilizza una variabile di ambiente. Il seguente snippet di codice di un'app App Engine mostra come accettare un valore di porta passato in una variabile di ambiente.
const express = require('express')
const request = require('got')
const app = express()
app.enable('trust proxy')
const PORT = process.env.PORT || 8080
app.listen(PORT, () => {
console.log('App listening on port ${PORT}')
console.log('Press Ctrl+C to quit.')
})
8. Contemporaneità
Dovresti scomporre l'app in processi indipendenti in base ai tipi di processi come i processi in background, web e worker. Ciò consente di fare lo scale up e lo scale down dell'app in base ai requisiti dei singoli carichi di lavoro. Gran parte delle app cloud-native consente di scalare on demand. Dovresti progettare l'app come più processi distribuiti in grado di eseguire in modo indipendente blocchi di lavoro e fare lo scale out aggiungendo altri processi.
Le sezioni seguenti descrivono alcuni costrutti per consentire la scalabilità delle app. Le app basate sui principi di rilasciabilità e statelessness sono le più adatte a sfruttare questi concetti di scalabilità orizzontale.
Utilizzo di Cloud Run
Cloud Run
è una piattaforma di computing che consente di eseguire i container direttamente sull'infrastruttura gestita da Google. Cloud Run supporta due modi di
esecuzione del codice. Cloud Run services viene eseguito continuamente come servizio. Di solito viene usato per rispondere
a richieste o eventi web. Cloud Run jobs esegue un codice che esegue un lavoro specifico
e si chiude al termine del lavoro. Cloud Run offre inoltre Cloud Scheduler
per eseguire job batch. Questa struttura è ideale per implementare
la contemporaneità e scalare le architetture di servizio possibili.
Per ulteriori informazioni su Cloud Run, consulta Che cos'è Cloud Run.
Utilizzo di Cloud Functions
Cloud Functions sono funzioni stateless a uso specifico eseguite su Google Cloud, dove l'architettura sottostante su cui vengono eseguite viene gestita per te da Google. Cloud Functions risponde ai trigger di eventi, come un caricamento in un bucket Cloud Storage o un messaggio Pub/Sub. Ogni chiamata di funzione risponde a un singolo evento o richiesta.
Cloud Functions gestisce le richieste in entrata assegnandole alle istanze della funzione. Quando il volume di richieste in entrata supera il numero di istanze esistenti, Cloud Functions potrebbe avviare nuove istanze per gestire le richieste. Questo comportamento di scalabilità automatica e completamente gestito consente a Cloud Functions di gestire molte richieste in parallelo, ognuna utilizzando un'istanza diversa della funzione.
Utilizzo di App Engine
Puoi ospitare le tue app nell'infrastruttura gestita di Google Cloud utilizzando App Engine. Le istanze sono le unità di calcolo utilizzate da App Engine per scalare automaticamente la tua app. In qualsiasi momento, la tua app può essere in esecuzione su un'istanza o su più istanze e le richieste vengono distribuite su tutte.
Lo scheduler di App Engine decide come gestire ogni nuova richiesta. Lo scheduler potrebbe utilizzare un'istanza esistente (una inattiva o una che accetta richieste simultanee), mettere la richiesta in una coda di richieste in attesa o avviare una nuova istanza per quella richiesta. La decisione prende in considerazione il numero di istanze disponibili, la velocità con cui l'app gestisce le richieste (la latenza) e il tempo necessario per avviare una nuova istanza.
Se utilizzi la scalabilità automatica, puoi creare un equilibrio tra prestazioni e costi impostando l'utilizzo target della CPU, la velocità effettiva target e il numero massimo di richieste in parallelo.
Puoi specificare il tipo di scalabilità nel file app.yaml, che carichi per
la versione del servizio. In base a questo input di configurazione, l'infrastruttura
di App Engine utilizza istanze dinamiche o residenti. Per ulteriori informazioni sui tipi di scalabilità, consulta la documentazione di App Engine.
Utilizzo della scalabilità automatica di GKE
Ci sono alcuni concetti chiave di Kubernetes che si applicano ai processi di scalabilità:
Scalabilità automatica orizzontale dei pod (HPA). Kubernetes può essere configurato per fare lo scale up o lo scale down del numero di pod in esecuzione nel cluster in base a metriche standard o personalizzate. Ciò è utile quando devi rispondere a un carico variabile sul tuo cluster GKE.
Scalabilità automatica dei nodi. Nei periodi di maggiore domanda, potrebbe essere necessario scalare il cluster per ospitare più pod. Con GKE puoi configurare in modo dichiarativo il cluster per la scalabilità. Con la scalabilità automatica abilitata, GKE scala automaticamente i nodi quando è necessario pianificare pod aggiuntivi e quando i nodi esistenti non sono in grado di ospitarli. Inoltre, GKE fa lo scale down dei nodi quando il carico sul cluster diminuisce, in base alle soglie configurate.
Job. GKE supporta i job Kubernetes. Per job si intende in generale un'attività che richiede l'esecuzione di uno o più pod. Il job potrebbe essere eseguito una volta o in base a una pianificazione. I pod in cui viene eseguito il job vengono eliminati al completamento del job. Il file YAML che configura il job specifica i dettagli su gestione degli errori, parallelismo, come vengono gestiti i riavvii e così via.
Utilizzo di Compute Engine
In alternativa, puoi eseguire il deployment delle app e gestirle su Compute Engine. In questo caso, puoi scalare la tua app per rispondere ai carichi variabili utilizzando gruppi di istanze gestite in base all'utilizzo della CPU, alle richieste gestite o ad altri indicatori di telemetria della tua app.
La figura seguente illustra le funzionalità principali fornite dai gruppi di istanze gestite.
L'utilizzo dei gruppi di istanze gestite consente alla tua app di adattarsi alla domanda in entrata e di essere ad alta disponibilità. Questo concetto funziona intrinsecamente bene per le app stateless come i front-end web e per i carichi di lavoro ad alte prestazioni basati su batch.
9. Rilasciabilità
Per le app eseguite sull'infrastruttura cloud, dovresti trattare queste app e l'infrastruttura sottostante come risorse disponibili. Le app devono essere in grado di gestire la perdita temporanea dell'infrastruttura sottostante ed essere in grado di arrestarsi e riavviarsi in modo corretto.
I principi chiave da prendere in considerazione includono:
- Disaccoppia funzionalità quali la gestione dello stato e l'archiviazione dei dati transazionali utilizzando i servizi di supporto. Per ulteriori informazioni, consulta la sezione Servizi di supporto precedente in questo documento.
- Gestisci le variabili di ambiente al di fuori dell'app in modo da poter essere utilizzate in fase di runtime.
- Assicurati che il tempo di avvio sia minimo. Ciò significa che devi decidere la quantità di livelli da integrare nelle immagini quando utilizzi le macchine virtuali, ad esempio immagini pubbliche e personalizzate. Questa decisione è specifica per ciascuna app e dovrebbe basarsi sulle attività eseguite dagli script di avvio. Ad esempio, se scarichi diversi pacchetti o programmi binari e li inizializzavi durante l'avvio, una parte considerevole del tempo di avvio sarà dedicata al completamento di queste attività.
- Usa le funzionalità native di Google Cloud per eseguire attività relative all'infrastruttura. Ad esempio, puoi utilizzare gli aggiornamenti in sequenza in GKE e gestire i token di sicurezza utilizzando Cloud Key Management Service (Cloud KMS).
Utilizza il segnale SIGTERM (quando disponibile) per avviare un arresto anomalo. Ad esempio, quando App Engine Flex arresta un'istanza, normalmente invia un segnale STOP (SIGTERM) al container dell'app. L'app può utilizzare questo indicatore per eseguire qualsiasi azione di pulizia prima dell'arresto del container. L'app non deve rispondere all'evento SIGTERM. In condizioni normali, il sistema attende fino a 30 secondi per l'arresto dell'app, quindi invia un segnale KILL (SIGKILL).
Lo snippet seguente in un'app di App Engine mostra come intercettare l'indicatore SIGTERM per chiudere le connessioni di database aperte.
const express = require('express') const dbConnection = require('./db') // Other business logic related code app.listen(PORT, () => { console.log('App listening on port ${PORT}') console.log('Press Ctrl+C to quit.') }) process.on('SIGTERM', () => { console.log('App Shutting down') dbConnection.close() // Other closing of database connection })
10. Parità ambientale
Le app aziendali si muovono in diversi ambienti durante il loro ciclo di vita di sviluppo. In genere questi ambienti sono di sviluppo, test, gestione temporanea e produzione. È buona norma mantenere questi ambienti il più simili possibile.
La parità ambientale è una funzionalità che la maggior parte degli sviluppatori considera un determinato. Tuttavia, man mano che le aziende crescono e i loro ecosistemi IT si evolvono, la parità ambientale diventa più difficile da mantenere.
Mantenere la parità ambientale negli ultimi anni è diventato più semplice negli ultimi anni perché gli sviluppatori hanno adottato il controllo del codice sorgente, la gestione della configurazione e i file di configurazione basati su modelli. Ciò semplifica il deployment coerente di un'app in più ambienti. Ad esempio, utilizzando Docker e Docker Compose, puoi assicurarti che lo stack di app mantenga la propria forma e la propria strumentazione in tutti gli ambienti.
La tabella seguente elenca i servizi e gli strumenti di Google Cloud che puoi utilizzare quando progetti le app da eseguire su Google Cloud. Questi componenti servono a diversi scopi e collettivamente ti aiutano a creare flussi di lavoro che rendono gli ambienti più coerenti.
| Componente Google Cloud | Purpose |
|---|---|
| Artifact Registry | Un gestore di pacchetti universale per tutti gli artefatti e le dipendenze della build. |
| Cloud Build | Un servizio completamente gestito che esegue le tue build sull'infrastruttura di Google Cloud. |
| Cloud KMS | Archivia le chiavi di crittografia in un servizio cloud centrale per l'utilizzo diretto da parte di altre risorse e applicazioni cloud. |
| Cloud Storage | Archivia le immagini personalizzate create a partire da dischi di origine, immagini, snapshot o immagini archiviate in Cloud Storage. Puoi utilizzare queste immagini per creare istanze di macchine virtuali (VM) su misura per le tue app. |
| Cloud Deploy | Fornisci la distribuzione automatica delle tue applicazioni in una serie di più ambienti di destinazione in una sequenza definita. |
11. Log
I log ti offrono consapevolezza circa lo stato delle tue app. È importante disaccoppiare la raccolta, l'elaborazione e l'analisi dei log dalla logica principale delle app. Il disaccoppiamento del logging è particolarmente utile quando le app richiedono la scalabilità dinamica e sono in esecuzione su cloud pubblici, perché elimina l'overhead associato alla gestione della posizione di archiviazione per i log e l'aggregazione dalle VM distribuite (e spesso temporanee).
Google Cloud offre una suite di strumenti utili per la raccolta, l'elaborazione e l'analisi strutturata dei log. È buona norma installare l'agente Cloud Logging nelle VM di Compute Engine. L'agente è preinstallato nelle immagini VM di App Engine e GKE per impostazione predefinita. L'agente monitora un insieme preconfigurato di località di logging. I log generati dalle app in esecuzione nella VM vengono raccolti e trasmessi in flusso su Cloud Logging.
Se il logging è abilitato per un cluster GKE, viene eseguito il deployment di un agente Logging su ogni nodo che fa parte del cluster. L'agente raccoglie i log, li arricchisce con metadati pertinenti e li rende persistenti in un datastore. Questi log possono essere esaminati utilizzando Cloud Logging. Se hai bisogno di un maggiore controllo su ciò che viene registrato, puoi utilizzare i daemonset Fluentd.
Per ulteriori informazioni, consulta Configurare l'agente Logging.
12. Processi di amministrazione
I processi amministrativi consistono in genere di attività una tantum o attività a tempo e ripetibili, come la generazione di report, l'esecuzione di script batch, l'avvio di backup dei database e la migrazione di schemi. Il fattore dei processi di amministrazione nel manifest dei 12 fattori è stato scritto pensando ad attività una tantum. Per le app cloud-native, questo fattore diventa più pertinente quando si creano attività ripetibili e le indicazioni in questa sezione sono orientate ad attività come queste.
I trigger a tempo vengono spesso creati come cron job e gestiti intrinsecamente dalle app stesse. Questo modello funziona, ma introduce una logica strettamente associata all'app e che richiede manutenzione e coordinamento, soprattutto se le app sono distribuite in fusi orari diversi.
Pertanto, quando progetti per i processi di amministrazione, devi disaccoppiare la gestione di queste attività dall'app stessa. A seconda degli strumenti e dell'infrastruttura su cui viene eseguita la tua app, utilizza i seguenti suggerimenti:
- Per l'esecuzione di app su GKE, avvia container separati per le attività di amministrazione. Puoi sfruttare i CronJobs in GKE. I CronJob vengono eseguiti in container temporanei e consentono di controllare le tempistiche, la frequenza di esecuzione e i nuovi tentativi in caso di esito negativo o se il loro completamento richiede troppo tempo.
- Per l'hosting di app su App Engine o Compute Engine, puoi esternalizzare il meccanismo di attivazione e creare un endpoint da richiamare. Questo approccio consente di definire un confine attorno a ciò di cui sono responsabili le app, in contrasto con l'obiettivo specifico dell'endpoint. Cloud Tasks è un servizio di esecuzione di attività completamente gestito e asincrono che puoi utilizzare per implementare questo pattern con App Engine. Puoi anche utilizzare Cloud Scheduler, uno scheduler di livello aziendale completamente gestito su Google Cloud, per attivare operazioni a tempo.
Oltre i dodici fattori
I dodici fattori descritti in questo documento forniscono indicazioni su come affrontare la creazione di app cloud-native. Queste app sono gli elementi costitutivi fondamentali di un'azienda.
Una tipica impresa ha molte app come queste, spesso sviluppate da diversi team in collaborazione per offrire funzionalità aziendali. È importante stabilire alcuni principi aggiuntivi durante il ciclo di vita di sviluppo dell'app, e non come un ripensamento, per capire come le app comunicano tra loro, come sono protette e con controllo dell'accesso.
Le sezioni seguenti descrivono alcune di queste considerazioni aggiuntive da fare durante la progettazione e lo sviluppo dell'app.
Pensare incentrato sulle API
Le app comunicano tramite API. Quando crei le app, pensa a come queste verranno utilizzate dall'ecosistema della tua app e inizia progettando una strategia API. Una buona progettazione dell'API ne semplifica l'utilizzo da parte degli sviluppatori di app e degli stakeholder esterni. È buona prassi iniziare documentando l'API utilizzando la specifica OpenAPI prima di implementare qualsiasi codice.
Le API astraggono la funzionalità di base dell'app. Un endpoint API ben progettato deve isolare e disaccoppiare le applicazioni che utilizzano l'infrastruttura dall'infrastruttura delle app che fornisce il servizio. Questo disaccoppiamento ti offre la possibilità di modificare in modo indipendente il servizio sottostante e la relativa infrastruttura, senza influire sui consumatori dell'app.
È importante catalogare, documentare e pubblicare le API che sviluppi in modo che i consumatori delle API siano in grado di scoprirle e utilizzarle. L'ideale sarebbe che i consumer delle API si pubblichino in autonomia. Puoi farlo configurando un portale per gli sviluppatori. Un portale per sviluppatori funge da punto di ingresso per tutti i consumer delle API, interno per l'azienda o esterno per i consumatori, ad esempio gli sviluppatori del tuo ecosistema di partner.
Apigee, la suite di prodotti per la gestione delle API di Google, ti aiuta a gestire l'intero ciclo di vita delle API, dalla progettazione alla creazione fino alla pubblicazione.
Sicurezza
Il regno della sicurezza è ampio e include sistemi operativi, reti e firewall, sicurezza di dati e database, sicurezza delle app e gestione di identità e accessi. È di fondamentale importanza risolvere tutte le dimensioni della sicurezza nell'ecosistema di un'azienda.
Dal punto di vista di un'app, le API forniscono accesso alle app nel tuo ecosistema aziendale. Devi quindi assicurarti che questi componenti di base rispondano alle considerazioni di sicurezza durante il processo di progettazione e creazione dell'app. Ecco alcune considerazioni per contribuire a proteggere l'accesso alla tua app:
- TLS (Transport Layer Security). Utilizza il protocollo TLS per proteggere i dati in transito. Ti consigliamo di utilizzare TLS reciproco per le app aziendali; questo risulta più semplice se utilizzi mesh di servizi come Istio su Google Kubernetes Engine. In alcuni casi d'uso, è inoltre comune creare liste consentite e bloccate basate sugli indirizzi IP come livello di sicurezza aggiuntivo. La sicurezza dei trasporti implica anche la protezione dei tuoi servizi da attacchi DDoS e bot.
- Sicurezza delle app e dell'utente finale. La sicurezza dei trasporti contribuisce a garantire la sicurezza dei dati in transito Tuttavia, una best practice consiste nell'aggiungere la sicurezza a livello di app per controllare l'accesso all'app in base al consumatore dell'app. I consumatori possono essere altre app, dipendenti, partner o clienti finali della tua azienda. Puoi applicare la sicurezza utilizzando chiavi API (per il consumo di app), autenticazione e autorizzazione basate su certificazione, scambio di token web JSON (JWT) o SAML (Security Assertion Markup Language).
Il panorama della sicurezza si evolve costantemente all'interno di un'azienda, rendendo più difficile la programmazione dei costrutti di sicurezza nelle tue app. I prodotti per la gestione delle API, come Apigee, aiutano a proteggere le API in tutti i livelli menzionati in questa sezione.
La sicurezza della catena di fornitura del software è un problema difficile da risolvere. È importante prendere precauzioni. Software Delivery Shield è una soluzione end-to-end completamente gestita che aiuta a migliorare la sicurezza della catena di fornitura del software durante l'intero ciclo di vita dello sviluppo del software. Offre i seguenti servizi e non solo:
Cloud Build. Supporta le build SLSA di livello 3 per le immagini container e genera la provenienza delle build autenticata e non falsificabile per le applicazioni containerizzate.
Software open source di Assured. Contribuisce a ridurre i rischi per la catena di fornitura del software utilizzando gli stessi pacchetti OSS utilizzati da Google.
Inoltre, sono disponibili vari servizi e funzioni per contribuire a migliorare la sicurezza della catena di fornitura del software.
Per ulteriori informazioni sulla sicurezza della catena di fornitura del software, consulta Sicurezza della catena di fornitura del software. Per ulteriori informazioni su Software Delivery Shield, consulta la panoramica di Software Delivery Shield.
Passaggi successivi
- Consulta l'app demo di microservizi che utilizza i principi delle app a 12 fattori ed è creata utilizzando i prodotti e i servizi Google Cloud.
- Visita il Centro architetture Cloud e scopri architetture di riferimento, indicazioni e best practice per la creazione o la migrazione dei carichi di lavoro su Google Cloud.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.