Questo documento descrive la popolare metodologia twelve-factor app e come applicarla per sviluppare app eseguite su Google Cloud. Se utilizzi questa metodologia, puoi creare applicazioni scalabili e resilienti che possono essere implementate continuamente con la massima agilità.
Questo documento è rivolto agli sviluppatori che hanno familiarità con Google Cloud, il controllo della versione, l'integrazione continua e la tecnologia dei container.
Introduzione
Gli sviluppatori stanno spostando le app nel cloud e, così facendo, acquisiscono più esperienza nella progettazione e nel deployment di app cloud-native. Da questa esperienza è emerso un insieme di best practice, comunemente noto come dodici fattori. Progettare un'app tenendo presenti questi fattori consente di eseguire il deployment di app nel cloud più portatili e resilienti rispetto alle app di cui è stato eseguito il deployment in ambienti on-premise in cui è necessario più tempo per il provisioning di nuove risorse.
Tuttavia, la progettazione di app cloud-native moderne richiede un cambiamento nel modo di pensare 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 metodologia di 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 utilizzata in svariate app.
I 12 fattori
1. Codebase
Devi monitorare il codice della tua app in un sistema di controllo della versione come Git o Mercurial. Lavori all'app eseguendo il check-out del codice nell'ambiente di sviluppo locale. L'archiviazione del codice in un sistema di controllo della versione consente al tuo team di lavorare insieme fornendo un audit trail delle modifiche al codice, un modo sistematico per risolvere i conflitti di unione e la possibilità di eseguire il rollback del codice a una versione precedente. Fornisce inoltre un punto di partenza per l&#CI;integrazione e il deployment continui.
Sebbene gli sviluppatori possano lavorare su versioni diverse del codice nei propri ambienti di sviluppo, in qualsiasi momento la fonte attendibile è il codice nel sistema di controllo del codice sorgente. Il codice nel repository viene compilato, provato e implementato e il numero di repository è indipendente dal numero di ambienti. Il codice nel repository viene utilizzato per produrre una singola compilazione, che viene combinata con una configurazione specifica per l'ambiente per produrre una release immutabile, ovvero una release in cui non è possibile apportare modifiche, inclusa la configurazione, che può essere poi implementata in un ambiente. Eventuali modifiche necessarie per la release dovrebbero comportare una nuova release.
2. Dipendenze
Ci sono due aspetti importanti da tenere in considerazione per quanto riguarda le dipendenze per le app a 12 fattori: la dichiarazione delle dipendenze e l'isolamento delle dipendenze.
Le app a 12 fattori non devono mai avere dipendenze implicite. Devi dichiarare esplicitamente tutte le dipendenze e controllarle nel controllo della versione. In questo modo puoi iniziare a utilizzare il codice rapidamente e in modo ripetibile e facilitare 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 ti consentono di isolare un'app e le sue dipendenze dall'ambiente e di assicurarti che l'app funzioni in modo uniforme nonostante le differenze tra gli ambienti di sviluppo e di gestione temporanea.
Artifact Registry è un servizio di gestione degli elementi privati completamente gestito che supporta vari tipi di elementi, come immagini container, pacchetti di linguaggio (ad esempio Maven e npm) e pacchetti di sistemi operativi (ad esempio RPM). Per aiutarti a gestire i risultati delle compilazioni CI/CD e le relative dipendenze, puoi utilizzare Cloud IAM con Artifact Registry con controllo granulare degli accessi. Artifact Analysis rileva le vulnerabilità nelle immagini container di cui è stato eseguito il push in Artifact Registry per garantire che il loro deployment sia sicuro.
Le integrazioni CI/CD esistenti ti consentono anche di configurare pipeline completamente automatizzate per ricevere feedback rapidi. Puoi spingere le immagini nel registry e poi estrarle utilizzando un endpoint HTTP da qualsiasi macchina, che si tratti di un'istanza Compute Engine o del tuo hardware.
3. Configurazione
Ogni app moderna richiede una qualche forma di configurazione. In genere, hai configurazioni diverse per ogni ambiente, ad esempio sviluppo, test e produzione. Queste configurazioni in genere includono le credenziali degli account di servizio e gli handle delle risorse per i servizi di supporto come i database.
Le configurazioni per ogni ambiente devono essere esterne al codice e non devono essere sottoposte a controllo del codice sorgente. Tutti lavorano su una sola versione del codice, ma hai più configurazioni. L'ambiente di deployment determina la configurazione da utilizzare. In questo modo è possibile eseguire il deployment di una versione del file binario in ogni ambiente, l'unica differenza è la configurazione di runtime. Un modo semplice per verificare se la configurazione è stata externalizzata correttamente è vedere se il codice può essere reso pubblico senza rivelare alcuna credenziale.
Un modo per esternalizzare la configurazione è creare file di configurazione. Tuttavia, i file di configurazione sono in genere specifici per un linguaggio o un framework di sviluppo.
Un approccio migliore è memorizzare la configurazione nelle variabili di ambiente. Sono facili da modificare per ogni ambiente in fase di esecuzione, non è probabile che vengano controllati 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 elementi di configurazione ai container e ai componenti di sistema dei pod al runtime.
Cloud Run Functions e Cloud Run supportano l'utilizzo delle variabili di ambiente. Puoi esternalizzare le configurazioni e modificarle dalla console Google Cloud o utilizzando Google Cloud SDK.
4. Servizi di supporto
A ogni servizio utilizzato dall'app nell'ambito del normale funzionamento, come sistemi di file, database, sistemi di memorizzazione nella cache e code di messaggi, deve essere eseguito l'accesso come servizio ed essere esternalizzato nella configurazione. Devi considerare questi servizi di supporto come astrazioni per la risorsa sottostante. Ad esempio, quando l'app scrive i dati nello spazio di archiviazione, trattarlo come un servizio di supporto consente di modificare facilmente il tipo di archiviazione sottostante, poiché è disaccoppiato dall'app. Puoi quindi eseguire una modifica, ad esempio passare da un database PostgreSQL locale a Cloud SQL per PostgreSQL senza modificare il codice dell'app.
5. Build, release, esecuzione
È importante separare il processo di deployment del software in tre fasi distinte: build, release ed esecuzione. Ogni fase deve generare un artefatto identificabile in modo univoco. Ogni deployment deve essere collegato a una specifica release ottenuta combinando la configurazione di un ambiente con una build. Questo consente rollback semplici e un audit trail visibile della cronologia di ogni deployment di produzione.
Puoi attivare manualmente la fase di compilazione, ma in genere viene attivata automaticamente quando esegui il commit del codice che ha superato tutti i test richiesti. La fase di compilazione prende il codice, recupera le librerie e gli asset richiesti e li impacchetta in un file binario o un contenitore autonomo. Il risultato della fase di compilazione è un artefatto di compilazione.
Al termine della fase di compilazione, la fase di rilascio combina l'elemento della build con la configurazione di un ambiente specifico. Viene generata una release. La release può essere implementata automaticamente nell'ambiente da un'app di implementazione continua. In alternativa, puoi attivare la release tramite la stessa app di implementazione continua.
Infine, la fase di esecuzione avvia la release. Ad esempio, se stai eseguendo il deployment in GKE, Cloud Build può chiamare il passaggio di compilazione gke-deploy per eseguire il deployment nel tuo cluster GKE. Cloud Build può gestire e automatizzare le fasi di compilazione, rilascio ed esecuzione in più lingue e ambienti utilizzando file di configurazione di compilazione in formato YAML o JSON.
Inoltre, puoi utilizzare Cloud Deploy che, come servizio completamente gestito, fornisce la distribuzione continua in GKE, Cloud Run e GKE Enterprise. Con Cloud Deploy puoi creare una pipeline di distribuzione che includa i passaggi di approvazione e la promozione senza problemi a più ambienti. Inoltre, Cloud Deploy supporta un rollback in un solo passaggio di un'applicazione di cui è stato eseguito il deployment in qualsiasi target.
6. Processi
Nell'ambiente esegui le app twelve-factor come uno o più processi. Queste procedure devono essere stateless e non devono condividere dati tra loro. In questo modo, le app possono aumentare di dimensioni tramite la replica dei loro processi. La creazione di app senza stato rende inoltre le procedure portabili nell'infrastruttura di calcolo.
Se sei abituato al concetto di sessioni "permanenti", questo richiede un cambiamento nel modo in cui pensi alla gestione e alla persistenza dei dati. Poiché i processi possono essere eliminati in qualsiasi momento, non puoi fare affidamento sulla disponibilità dei contenuti dello spazio di archiviazione locale o sul fatto che qualsiasi richiesta successiva verrà gestita dallo stesso processo. Pertanto, devi memorizzare esplicitamente tutti i dati che devono essere riutilizzati in un servizio di supporto esterno, ad esempio un database.
Se devi mantenere i dati, puoi utilizzare Memorystore e Filestore come servizio di supporto per memorizzare nella cache lo stato delle tue app e condividere i dati comuni tra i processi per favorire il basso accoppiamento.
7. Associazione di porte
Negli ambienti non cloud, le app web vengono spesso scritte per essere eseguite in container per app come GlassFish, Apache Tomcat e Apache HTTP Server. Al contrario, le app con verifica in due passaggi non si basano su container di app esterni. ma includono la raccolta del server web come parte dell'app stessa.
È una best practice di architettura per i servizi esporre un numero di porta, specificato dalla variabile di ambiente PORT.
Le app che esportano la mappatura delle porte sono in grado di utilizzare le informazioni sulla mappatura delle porte esternamente (come variabili di ambiente) quando si utilizza il modello piattaforma-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 inoltra le richieste da un nome host rivolto al pubblico ai processi web associati alle porte. Ad esempio, quando esegui il deployment delle tue app su App Engine, dichiari le dipendenze per aggiungere una libreria del web server all'app, ad esempio Express (per Node.js), Flask e Gunicorn (per Python) o Jetty (per Java).
Non devi codificare in modo rigido i numeri di porta 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 portabili quando le esegui su Google Cloud.
Poiché Kubernetes ha la funzionalità di Service Discovery integrata, in Kubernetes puoi astrarre le associazioni delle porte mappando le porte dei servizi ai contenitori. Il Service Discovery viene eseguito utilizzando i nomi DNS interni.
Anziché codificare 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à
Devi decomporre l'app in processi indipendenti in base ai tipi di processo, come i processi in background, web e di lavoro. In questo modo, la tua app può eseguire lo scale up e lo scale down in base ai requisiti dei singoli carichi di lavoro. La maggior parte delle app cloud-native ti consente di eseguire il ridimensionamento in base alle esigenze. Devi progettare l'app come più processi distribuiti in grado di eseguire in modo indipendente blocchi di lavoro e di eseguire il ridimensionamento aggiungendo altri processi.
Le seguenti sezioni descrivono alcuni costrutti per consentire alle app di scalare. Le app basate sui principi di disponibilità e assenza di stato sono ben posizionate per trarre vantaggio da questi costrutti di scalabilità orizzontale.
Utilizzo di Cloud Run
Cloud Run
è una piattaforma di calcolo che ti consente di eseguire container direttamente sull'infrastruttura gestita da Google. Cloud Run supporta due modi per eseguire il codice. Cloud Run services viene eseguito continuamente come servizio. In genere viene utilizzato per rispondere a richieste o eventi web. Cloud Run jobs esegue codice che esegue attività specifiche del job e si arresta al termine del lavoro. Cloud Run offre anche Cloud Scheduler per eseguire job batch. Questa struttura è adatta per implementare la concorrenza e scalare le possibili architetture di servizio.
Per saperne di più su Cloud Run, consulta Che cos'è Cloud Run.
Utilizzo di Cloud Run Functions
Le funzioni Cloud Run sono funzioni stateless e monouso che vengono eseguite su Google Cloud, dove l'architettura di base su cui vengono eseguite è gestita da Google. Le funzioni Cloud Run rispondono agli attivatori di eventi, ad esempio un caricamento in un bucket Cloud Storage o un messaggio Pub/Sub. Ogni chiamata della funzione risponde a un singolo evento o richiesta.
Le funzioni Cloud Run gestiscono le richieste in entrata assegnandole alle istanze della funzione. Quando il volume delle richieste in entrata supera il numero di istanze esistenti, le funzioni Cloud Run potrebbero avviare nuove istanze per gestire le richieste. Questo comportamento di scalabilità automatico e completamente gestito consente alle funzioni Cloud Run di gestire molte richieste in parallelo, ciascuna utilizzando un'istanza diversa della funzione.
Utilizzo di App Engine
Puoi ospitare le tue app sull'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 una o più istanze, con le richieste distribuite su tutte.
Il programmatore di App Engine decide come gestire ogni nuova richiesta. Lo schedulatore potrebbe utilizzare un'istanza esistente (inattiva o che accetta richieste simultanee), inserire la richiesta in una coda di richieste in attesa o avviare una nuova istanza per la richiesta. La decisione prende in considerazione il numero di istanze disponibili, la velocità con cui la tua app sta soddisfacendo le richieste (la sua 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 della CPU target, il throughput target e il numero massimo di richieste simultanee.
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 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
Esistono alcuni costrutti Kubernetes chiave che si applicano ai processi di scalabilità:
Scalabilità automatica dei pod orizzontali (HPA). Kubernetes può essere configurato per aumentare o diminuire il numero di pod in esecuzione nel cluster in base a metriche standard o personalizzate. Questa funzionalità è utile quando devi rispondere a un carico variabile sul tuo cluster GKE.
Scalabilità automatica dei nodi. In periodi di maggiore domanda, potresti dover scalare il cluster per ospitare più pod. Con GKE, puoi configurare in modo dichiarativo il tuo cluster per scalare. Con la scalabilità automatica abilitata, GKE esegue automaticamente lo scale up dei nodi quando è necessario pianificare pod aggiuntivi e quando i nodi esistenti non sono in grado di accomodarli. GKE riduce anche i nodi quando il carico sul cluster diminuisce, in base alle soglie che hai configurato.
Job. GKE supporta i job Kubernetes. Un job può essere definito in termini generali come un'attività che richiede uno o più pod per essere eseguita. Il job può essere eseguito una volta sola o in base a una pianificazione. I pod in cui viene eseguito il job vengono eliminati al termine del job. Il file YAML che configura il job specifica i dettagli relativi alla gestione degli errori, al parallelismo, alla gestione dei riavvii e così via.
Utilizzo di Compute Engine
In alternativa, puoi eseguire il deployment e gestire le tue app su Compute Engine. In questo caso, puoi scalare l'app in modo che risponda a carichi variabili utilizzando gruppi di istanze gestite (MIG) 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 offerte dai gruppi di istanze gestite.
L'utilizzo dei gruppi di istanze gestite consente alla tua app di adattarsi alla domanda in arrivo ed essere altamente disponibile. Questo concetto funziona bene per impostazione predefinita per le app stateless come i front-end web e per carichi di lavoro ad alte prestazioni basati su batch.
9. Rilasciabilità
Per le app che vengono eseguite sull'infrastruttura cloud, devi trattarle e l'infrastruttura di base come risorse usa e getta. Le tue app dovrebbero essere in grado di gestire la perdita temporanea dell'infrastruttura sottostante e di eseguire un arresto e un riavvio graceful.
Ecco alcuni principi chiave da considerare:
- Scollega funzionalità come la gestione dello stato e l'archiviazione dei dati transazionali utilizzando i servizi di supporto. Per ulteriori informazioni, consulta Servizi di supporto all'inizio di questo documento.
- Gestisci le variabili di ambiente all'esterno dell'app in modo che possano essere utilizzate in fase di runtime.
- Assicurati che il tempo di avvio sia minimo. Ciò significa che devi decidere quanto stratificare le immagini quando utilizzi le macchine virtuali, ad esempio le immagini pubbliche rispetto a quelle personalizzate. Questa decisione è specifica per ogni app e deve basarsi sulle attività eseguite dagli script di avvio. Ad esempio, se stai scaricando diversi pacchetti o binari e li stai inizializzando durante l'avvio, una parte significativa del tempo di avvio sarà dedicata al completamento di queste attività.
- Utilizza le funzionalità native di Google Cloud per eseguire attività di infrastruttura. Ad esempio, puoi utilizzare gli aggiornamenti incrementali in GKE e gestire le tue chiavi di sicurezza utilizzando Cloud Key Management Service (Cloud KMS).
Utilizza l'indicatore SIGTERM (se disponibile) per avviare un arresto pulito. Ad esempio, quando l'ambiente flessibile di App Engine arresta un'istanza, normalmente invia un segnale di STOP (SIGTERM) al contenitore dell'app. L'app può utilizzare questo indicatore per eseguire eventuali azioni di pulizia prima dell'arresto del contenitore. L'app non deve rispondere all'evento SIGTERM. In condizioni normali, il sistema attende fino a 30 secondi che l'app si arresti e poi invia un segnale KILL (SIGKILL).
Il seguente snippet in un'app App Engine mostra come puoi intercettare l'indicatore SIGTERM per chiudere le connessioni a 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à dell'ambiente
Le app aziendali si spostano in ambienti diversi durante il loro ciclo di vita di sviluppo. In genere, questi ambienti sono di sviluppo, test, gestione temporanea e produzione. È buona prassi mantenere questi ambienti il più simili possibile.
La parità dell'ambiente è una funzionalità che la maggior parte degli sviluppatori dà per scontata. Tuttavia, con la crescita delle aziende e l'evoluzione dei loro ecosistemi IT, la parità dell'ambiente diventa più difficile da mantenere.
Negli ultimi anni è diventato più facile mantenere la parità dell'ambiente perché gli sviluppatori hanno adottato il controllo del codice sorgente, la gestione della configurazione e i file di configurazione basati su modelli. In questo modo è più facile eseguire il deployment di un'app in più ambienti in modo coerente. Ad esempio, utilizzando Docker e Docker Compose, puoi assicurarti che lo stack dell'app mantenga la sua forma e la sua strumentazione in tutti gli ambienti.
La tabella seguente elenca i servizi e gli strumenti Google Cloud che puoi utilizzare per progettare app da eseguire su Google Cloud. Questi componenti hanno scopi diversi e, nel loro insieme, ti aiutano a creare flussi di lavoro che rendono più coerenti i tuoi ambienti.
| 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 Google Cloud. |
| Cloud KMS | Memorizza le chiavi di crittografia in un unico servizio cloud centralizzato per l'utilizzo diretto da parte di altre risorse e applicazioni cloud. |
| Cloud Storage | Archivia le immagini personalizzate create da dischi di origine, immagini, snapshot o immagini archiviate in Cloud Storage. Puoi utilizzare queste immagini per creare istanze di macchine virtuali (VM) personalizzate per le tue app. |
| Cloud Deploy | Fornisci il deployment automatico delle tue applicazioni in una serie di più ambienti di destinazione in una sequenza definita. |
11. Log
I log offrono consapevolezza circa lo stato delle app. È importante disaccoppiare la raccolta, l'elaborazione e l'analisi dei log dalla logica principale delle app. Il disaccoppiamento del logging si rivela particolarmente utile quando le app richiedono la scalabilità dinamica e sono eseguite su cloud pubblici, poiché si elimina il problema della gestione della posizione di archiviazione dei log e dell'aggregazione da 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 prassi installare l'agente Cloud Logging nelle VM Compute Engine. L'agente è preinstallato nelle immagini VM di App Engine e GKE per impostazione predefinita. L'agente monitora un insieme preconfigurato di posizioni di logging. I log generati dalle tue app in esecuzione nella VM vengono raccolti e trasmessi in streaming a Cloud Logging.
Quando il logging è abilitato per un cluster GKE, un agente di logging viene eseguito su ogni nodo che fa parte del cluster. L'agente raccoglie i log, li arricchisce con metadati pertinenti e li rende permanenti in un datastore. Questi log sono disponibili per la revisione tramite Cloud Logging. Se hai bisogno di un maggiore controllo su ciò che viene registrato, puoi utilizzare i daemonset Fluentd.
Per ulteriori informazioni, vedi Configurare l'agente Logging.
12. Processi di amministrazione
Le procedure amministrative in genere consistono in attività una tantum o ripetibili programmate, come la generazione di report, l'esecuzione di script batch, l'avvio di backup del database e la migrazione degli schemi. Il fattore dei processi di amministrazione nel manifesto dei dodici fattori è stato scritto tenendo conto delle attività una tantum. Per le app native cloud, questo fattore diventa più pertinente quando crei attività ripetibili e le indicazioni riportate in questa sezione sono orientate a questo tipo di attività.
Gli attivatori 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 eseguire app su GKE, avvia contenitori separati per le attività di amministrazione. Puoi utilizzare i CronJobs in GKE. I CronJob vengono eseguiti in container effimeri e ti consentono di controllare la tempistica, la frequenza di esecuzione e i tentativi di nuovo se i job non riescono o se impiegano troppo tempo per essere completati.
- Per ospitare le app su App Engine o Compute Engine, puoi externalizzare il meccanismo di attivazione e creare un endpoint da invocare per l'attivatore. Questo approccio consente di definire un confine per le responsabilità delle app, a differenza dell'obiettivo a scopo unico dell'endpoint. Cloud Tasks è un servizio di esecuzione di attività asincrone completamente gestito che puoi utilizzare per implementare questo pattern con App Engine. Puoi anche utilizzare Cloud Scheduler, un programmatore completamente gestito di livello enterprise su Google Cloud, per attivare operazioni programmate.
Oltre i 12 fattori
I dodici fattori descritti in questo documento forniscono indicazioni su come approcciarsi alla creazione di app cloud-native. Queste app sono gli elementi di base di un'azienda.
Un'azienda tipica ha molte app come queste, spesso sviluppate da diversi team in collaborazione per fornire funzionalità aziendali. È importante stabilire alcuni principi aggiuntivi durante il ciclo di vita dello sviluppo delle app e non come ripensamento, per affrontare il modo in cui le app comunicano tra loro e come sono protette e controllate.
Le sezioni seguenti descrivono alcune di queste considerazioni aggiuntive che dovresti fare durante la progettazione e lo sviluppo dell'app.
Pensa in termini di API
Le app comunicano utilizzando le API. Quando sviluppi app, pensa a come verrà utilizzata dall'ecosistema della tua app e inizia a progettare una strategia API. Un buon design dell'API la rende facile da utilizzare per gli sviluppatori di app e per le parti interessate esterne. È buona prassi iniziare documentando l'API utilizzando la specifica OpenAPI prima di implementare qualsiasi codice.
Le API astraggono la funzionalità dell'app sottostante. Un endpoint API ben progettato deve isolare e disaccoppiare le applicazioni di consumo dall'infrastruttura dell'app che fornisce il servizio. Questo disaccoppiamento ti consente di modificare il servizio sottostante e la relativa infrastruttura in modo indipendente, senza influire sugli utenti dell'app.
È importante catalogare, documentare e pubblicare le API che sviluppi in modo che i relativi consumatori possano trovarle e utilizzarle. Idealmente, vorresti che i consumatori dell'API si servissero da soli. Puoi farlo impostando un portale per sviluppatori. Un portale per sviluppatori funge da punto di contatto per tutti i consumatori di API, interni per l'azienda o esterni per i consumatori come 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 tue API, dalla progettazione alla creazione fino alla pubblicazione.
Sicurezza
L'ambito della sicurezza è ampio e include sistemi operativi, reti e firewall, sicurezza dei dati e dei database, sicurezza delle app e gestione di identità e accessi. È di fondamentale importanza affrontare tutte le dimensioni della sicurezza nell'ecosistema di un'azienda.
Dal punto di vista di un'app, le API forniscono l'accesso alle app nell'ecosistema aziendale. Pertanto, devi assicurarti che questi componenti di base tengano conto delle considerazioni sulla sicurezza durante la progettazione e processo di compilazione dell'app. Di seguito sono riportate alcune considerazioni per contribuire a proteggere l'accesso alla tua app:
- Transport Layer Security (TLS). Utilizza TLS per proteggere i dati in transito. Ti consigliamo di utilizzare TLS reciproco per le tue app aziendali. Questa operazione è semplificata se utilizzi mesh di servizi come Istio su Google Kubernetes Engine. Inoltre, per alcuni casi d'uso è comune creare liste consentite e liste bloccate basate su indirizzi IP come ulteriore livello di sicurezza. La sicurezza del trasporto implica anche la protezione dei tuoi servizi da attacchi DDoS e tramite bot.
- Sicurezza delle app e degli utenti finali. La sicurezza del trasporto contribuisce a garantire la sicurezza dei dati in transito e a stabilire la fiducia. Tuttavia, è buona prassi aggiungere la sicurezza a livello di app per controllare l'accesso alla tua app in base a chi è il consumatore dell'app. I consumatori possono essere altre app, dipendenti, partner o clienti finali della tua azienda. Puoi applicare la sicurezza utilizzando le chiavi API (per le app di consumo), l'autenticazione e l'autorizzazione basate su certificazione, lo scambio di token web JSON (JWT) o Security Assertion Markup Language (SAML).
Il panorama della sicurezza si evolve costantemente all'interno di un'azienda, il che rende più difficile codificare i costrutti di sicurezza nelle app. I prodotti di gestione delle API come Apigee aiutano a proteggere le API a tutti i livelli menzionati in questa sezione.
La sicurezza della catena di fornitura del software è un problema difficile da risolvere. È importante che tu prenda delle precauzioni. Google Cloud fornisce prodotti e funzionalità che contribuiscono a migliorare la sicurezza della catena di fornitura del software durante l'intero ciclo di vita di sviluppo del software. Considera gli esempi seguenti:
Cloud Build. Supporta le build SLSA di livello 3 per le immagini container e genera la provenienza della build autenticata e non falsificabile per le applicazioni containerizzate.
Assured Open Source Software. Contribuisce a ridurre il rischio per la tua catena di fornitura software utilizzando gli stessi pacchetti OSS che utilizza Google.
Per ulteriori informazioni, consulta Sicurezza della catena di approvvigionamento del software.
Passaggi successivi
- Esamina la app di demo dei microservizi che utilizza i principi delle app a dodici fattori ed è creata con prodotti e servizi Google Cloud.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.