AWS, sviluppo database serverless con qualsiasi linguaggio, anche in Cobol

AWS Werner Vogels database erverless

Il più bel giorno da quando lavoro in AWS? Lo scorso 1 novembre, quando Amazon ha spento il suo datawarehouse Oracle ed è migrata su Redshift”.

Partendo da questa affermazione, che getta altra benzina sul fuoco nella diatriba tra le due aziende, il CTO di Amazon Web Services Werner Vogels ha tracciato una dettagliata panoramica di come sono evoluti i servizi di Amazon basati su database.

All’inizio a farla da padrona erano i database relazionali, ma con l’evoluzione della proposta di AWS si sono dimostrati presto poco adatti a operare al meglio con il cloud.

Non sono nati per il cloud ­– ha affermato Vogels – e nonostante tutti gli aggiornamenti apportati mostrano ancora molti limiti. Per il cloud serve un database pensato per il cloud e non portato sul cloud”.

Va da sé che le architetture a celle, Aurora con la sua la natura distribuita e scalabile o Dynamo DB con le sue ragguardevoli prestazioni siano oggi le soluzioni ideali per affidare al cloud i propri dati.

Un aspetto puntualizzato da Vogels è stato che oggi più che di MFBT ha senso parlare di recupero dai guasti. I guasti sono inevitabili, quello su cui invece si deve lavorare è l’impatto che hanno tali guasti (e che "le architetture a celle tendono a minimizzare"). Il tempo di recupero è quindi un elemento fondamentale delle più recenti architetture.

Dopo aver sottolineato come Redshift sia diventato 3,5 volte più veloce negli ultimi sei mesi, grazie a ottimizzazioni "under the cover", Vogels si è rivolto espressamente agli sviluppatori (AWS preferisce chiamarli “builder”) per spiegare perché oggi più che mai è facile realizzare applicazioni per l’ambiente database serverless.

Due sono gli aspetti che sostanzialmente motivano l’affermazione: in primo luogo perché le nuove API di Lambda offrono la possibilità di usare qualsiasi linguaggio si preferisca (PHP e Cobol compresi), secondariamente perché i nuovi Layer di Lambda consentono di centralizzare la gestione di codice e dati che è distribuita su molteplici funzioni.

Non solo. I nuovi Custom Runtime permettono di portare il proprio ambiente di esecuzione nel mondo serverless. Se poi si vuole sapere come AWS avrebbe sviluppato l’applicazione su cui s sta lavorando, si può ricorrere al nuovo Well-Architect Tool.

Si tratta di un insieme di risorse pensato per “calare” le best practice AWS all’intero del proprio ambiente di sviluppo, verificando quanto si sta facendo è coerente con quello che avrebbe fatto AWS nella stessa situazione. In pratica, è come avere un consulente Amazon sempre a disposizione.

Se questo articolo ti è piaciuto e vuoi rimanere sempre informato sulle novità tecnologiche iscriviti alla newsletter gratuita.

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome