Le applicazioni cloud-native possono fornire una serie di vantaggi. Offrono scalabilità granulare, portabilità e uso efficiente delle risorse. Tuttavia, possono risultare difficili da gestire e da proteggere. La sfida, per gli sviluppatori, è quella di ridurre al minimo gli svantaggi e massimizzare i benefici. Per vincerla, spesso basta seguire alcune best practice che vanno dalla scelta dei giusti modelli di progettazione alla sicurezza by design per non riscontrare problemi quando potrebbe essere troppo tardi. Evitando il vendor lock-in e utilizzando strategicamente l’opzione serverless, gli sviluppatori possono ottenere alta qualità e lunga durata.
Migliore è il processo di sviluppo cloud-native, più efficiente e affidabile sarà l’applicazione ottenuta.
Evitare il vendor lock-in
Idealmente, un’applicazione cloud-native funzionerà in qualsiasi ambiente IT e non dipenderà da un particolare cloud o tipo di piattaforma. Per ottenere realmente questo vantaggio di portabilità del cloud-native, è necessario assicurarsi che il funzionamento dell’applicazione nel suo ambiente non dipenda da un servizio o da una caratteristica di un provider particolare. Allo stesso modo, meglio evitare prodotti PaaS che permettono agli sviluppatori di costruire e distribuire un’app solo su un particolare cloud o tipo di ambiente host.
Se si sceglie per esempio di eseguire un’app cloud-native utilizzando l’orchestrazione dei container Kubernetes, è necessario progettarla in modo che possa funzionare in qualsiasi ambiente Kubernetes. Mai limitarsi alla distribuzione Kubernetes di uno specifico fornitore.
Scegliere il giusto design pattern
Gli sviluppatori hanno molte opzioni per eseguire la progettazione di un’applicazione cloud-native. La lista di Microsoft, ad esempio, include non meno di 39 pattern diversi. I più noti a livello globale sono:
- Sidecar. L’applicazione principale opera come un insieme di servizi. Le funzionalità ausiliarie, come quelle per gli strumenti di monitoraggio, vengono eseguite accanto a essa come in un sidecar.
- Data driven. Un design pattern in cui l’applicazione esegue funzioni in risposta a specifici eventi, invece di operare continuamente.
- CQRS. La segregazione della responsabilità di comando e di query separa le operazioni di scrittura dalle operazioni di lettura.
- Gatekeeper. Una singola istanza dell’applicazione rivolta al pubblico funge da gateway che inoltra le richieste ad altre istanze ospitate privatamente.
È possibile usare simultaneamente più design pattern, a priori non si escludono a vicenda. Quelli scelti dovrebbero essere coerenti con gli obiettivi d’uso dell’applicazione e le priorità dell’azienda.
Se la sicurezza fosse una priorità assoluta, un design pattern gatekeeper potrebbe funzionare: riduce l’esposizione dell’applicazione a Internet. CQRS è vantaggioso per le applicazioni che richiedono un’alta disponibilità dei dati. Questo perché il pattern CQRS, permettendo solo a parti specifiche di un’applicazione di modificare i dati, riduce il rischio di sovrascrittura accidentale o di corruzione dei dati causata da un’applicazione difettosa.
Usare strategicamente l‘opzione serverless
Ci sono molte buone ragioni per utilizzare il serverless computing per distribuire app cloud-native.
- Riduce i costi complessivi per il cloud
- Permette alle applicazioni di scalare rapidamente.
- Riduce lo sforzo richiesto dagli ingegneri per distribuire e gestire le applicazioni: non serve infatti fornire un server completo per ospitare l’applicazione.
Ci sono, però, anche degli evidenti svantaggi:
- Minore portabilità. In generale, è difficile migrare un’applicazione da un motore di calcolo serverless basato sul cloud a un altro.
- Limiti sui linguaggi. Le piattaforme di calcolo serverless supportano solo applicazioni scritte in determinati linguaggi o framework, almeno nativamente. Gli sviluppatori a volte usano dei wrapper, permettendo loro di eseguire funzioni serverless che non sono supportate nativamente su una data piattaforma. Questo richiede uno sforzo extra, però, e può ridurre le prestazioni.
Gli sviluppatori cloud-native dovrebbero valutare con attenzione quando vale la pena di progettare applicazioni come funzioni serverless. Ha senso farlo se fattori come la facilità di distribuzione e la scalabilità sono prioritari. Non ha senso, invece, se si dà la priorità alla portabilità e non è inoltre adatto ad applicazioni scritte in linguaggi meno comuni.
Integrare la sicurezza fin dall’inizio
La sicurezza non può che essere al centro dei pensieri dei developer quando sviluppano applicazioni cloud-native. Le organizzazioni hanno bisogno di policy per garantire la sicurezza dello sviluppo. Queste possono includere una guida per pianificare e implementare l’autenticazione sicura dell’applicazione e l’autorizzazione all’interno del processo di sviluppo dell’applicazione. Spesso si cerca di evitare che gli sviluppatori costruiscano qualsiasi funzionalità di business e aggiungano l’autenticazione in seguito.
Gli sviluppatori dovrebbero anche mettere in conto di dover massimizzare la sicurezza dei dati dell’applicazione. Questo riguarda quelli memorizzati all’interno dell’applicazione, così come i dati ospitati esternamente, ad esempio in un servizio di storage a oggetti. È indispensabile, infine, implementare la crittografia dei dati e le funzioni di controllo degli accessi in tutte le posizioni di archiviazione.
Non escludere l’implementazione on-premise
Il termine cloud-native, in realtà, è fuorviante. Le app cloud-native non vengono necessariamente eseguite nel cloud, possono anche funzionare on premise. Si può prendere un’applicazione containerizzata basata su microservizi e distribuirla in un cluster Kubernetes on-premise.
A volte, le implementazioni on-premise sono preferibili, soprattutto se offrono un costo totale di proprietà inferiore rispetto all’hosting di un’applicazione nel cloud. Per particolari casi d’uso, gli ambienti on-premise, rispetto al cloud, possono anche offrire migliori controlli sulla sicurezza e sulla privacy dei dati.
Gli sviluppatori, di conseguenza, non dovrebbero dare per scontato che le loro applicazioni cloud-native siano eseguite sempre nel cloud, ma progettarle in modo che possano funzionare ovunque. Per questo è meglio evitare la dipendenza da servizi che sono disponibili solo nel cloud pubblico. L’alternativa per cui optare è l’integrazione con piattaforme, come Kubernetes, che rendono facile eseguire il software cloud-native sia nel cloud che in locale.
Infine, è bene tenere presente che non esiste un modo giusto o sbagliato per sviluppare un’applicazione cloud-native. Ottenere il massimo richiede un processo di sviluppo ben pianificato, da adattare ogni volta ai singoli casi d’uso e alle priorità dell’applicazione.
