Tempo di lettura: 3 min
Continua da QUI
La maggior parte dei fornitori di cloud che forniscono una PaaS vogliono che si inizi con lo sviluppo di “green field”; questo significa che i progetti che non sono interessati dai vincoli del lavoro precedente. Il porting di applicazioni esistenti o legacy sulla piattaforma può essere una sfida, soprattutto perché i filesystem esistenti sono di natura effimera e non consentono di salvare lo stato dell’applicazione o le risorse sul filesystem.
Questa restrizione è il motivo per cui si potrebbe sentire la necessità di pensare ad applicazioni future come stateless. Per ricevere i benefici di un’infrastruttura che risiede nel cloud, è necessario impiegare nei vostri progetti un design di applicazioni stateless. Per raggiungere questo obiettivo, prendete in considerazione le seguenti pratiche per le nuove applicazioni:
- Consentire al server o al contenitore delle applicazioni di mantenere lo stato di sessione dell’utente attraverso il cluster invece di fare affidamento sul file system.
- Non memorizzate file o risorse dell’utente sul file system fisico del server in cui il vostro codice viene distribuito. Considerate invece di utilizzare un servizio di storage basato su cloud e di fornire le risorse attraverso l’API REST fornita per il servizio di storage.
- Utilizzare un database per l’archiviazione delle risorse relative a un utente se non si ha accesso all’utilizzo di un’API di archiviazione cloud.
Quale stato di applicazione dovreste scegliere?
Per le applicazioni “green field”, dovreste progettare applicazioni che siano stateless, il che significa che non memorizzano gli asset o le risorse dell’utente sul filesystem. Per le applicazioni legacy o esistenti, scegliete un fornitore PaaS che supporti sia le applicazioni stateful che quelle stateless.
Scegliere un database per le applicazioni cloud-enabled
Quasi tutte le applicazioni che vengono create oggi si basano su un database di qualche tipo per memorizzare e recuperare le informazioni da presentare all’utente. Quando si sviluppano applicazioni per il cloud, è necessario anche prendere in considerazione quali database si utilizzeranno e dove tali database dovrebbero essere collocati. Il database deve essere ospitato sugli stessi server dell’applicazione, o è meglio ospitare il database su un server o container separato?
In molti casi, un’applicazione si basa su informazioni memorizzate in un database che risiede dietro un firewall aziendale; il front end dell’applicazione, invece, viene distribuito sul cloud pubblico. In questo caso, avete un paio di opzioni per accedere efficacemente alle informazioni che dovrete presentare all’utente sul front end.
Opzione 1: Scegliete un provider che vi permetta di aprire una connessione VPC remota al vostro database.
Opzione 2: Comunicare al database attraverso una serie di servizi REST autenticati distribuiti sull’infrastruttura che ha accesso ai dati.
Entrambe queste opzioni presentano rischi intrinseci per la sicurezza che è necessario considerare quando ci si connette a un database dietro un firewall aziendale da un’applicazione cloud esterna. In questo caso, l’opzione migliore è quella di selezionare un fornitore PaaS cloud che consenta di distribuire le applicazioni su un ambiente non multi-tenant.
Se il codice della vostra applicazione non ha bisogno di connettersi a un database aziendale esistente, il numero di opzioni di cui disponete è quasi infinito. Vi suggerisco di distribuire il vostro database nella stessa geografia/datacenter/regione del vostro codice applicativo, ma su container o server diversi rispetto al vostro codice applicativo front-end. Utilizzate questa opzione per scalare il database indipendentemente dal livello web. Inoltre, assicuratevi di scegliere un database scalabile in modo semplice e veloce, indipendentemente dal fatto che si tratti di un database SQL o NOSQL.
Considerare più geografie
Uno dei grandi vantaggi del cloud computing è la possibilità di implementare la propria infrastruttura applicativa in tutto il mondo con un costo iniziale minimo o nullo. Ad esempio, la distribuzione di un’applicazione che ha server sia in Nord America che in EMEA ha tradizionalmente sostenuto un enorme costo iniziale per l’acquisto e la fornitura di hardware e data center. Con un’infrastruttura che risiede nel cloud, è possibile distribuire la vostra applicazione in tutte le aree geografiche che il vostro fornitore supporta. Per le applicazioni semplici che hanno solo un numero limitato di utenti, questo non è necessario. Tuttavia, avere accesso al codice di distribuzione in più aree geografiche è fondamentale per ottenere la soddisfazione del cliente, localizzando il codice dell’applicazione il più vicino possibile al vostro pubblico target.
Aggiungete la possibilità di scalare manualmente o automaticamente la vostra applicazione in diverse aree geografiche e avrete tra le mani una proposta di valore davvero interessante, sostenendo un costo inferiore rispetto all’implementazione di un’infrastruttura IT tradizionale.
Quale fornitore di cloud dovreste scegliere per più geografie?
Scegliete un fornitore di cloud che vi consenta sia di implementare e scalare la vostra infrastruttura applicativa su più geografie in tutto il mondo per garantire che il vostro pubblico abbia un’esperienza rapida e reattiva durante l’utilizzo della vostra applicazione.
[hubspot type=form portal=7275494 id=66eb3b55-d9e7-4c24-98e2-17630c198255]