[ad_1]

Il cloud computing è diverso da quello “tradizionale”. Proprio come lo snowboard è diverso dallo sci nautico, gli strumenti e le attrezzature hanno una forma diversa, le competenze di base sono simili ma abbastanza diverse da giustificare la loro definizione come disciplina separata … e faresti meglio a sapere se sei circondato dalla neve o acqua prima di iniziare.

È lo stesso con il cloud. Sebbene molte competenze, fondamenti e sistemi logici di base assomiglino al “vecchio” mondo dell’informatica non as-a-Service terrestre, ci sono abbastanza differenze per delimitare e distinguere lo sviluppo di software nativo nel cloud come un processo speciale e distinto per costruendo i sistemi IT contemporanei su cui stiamo costruendo le nostre vite.

Chi ha spostato il formaggio?

Quindi, cosa è diverso e cosa dobbiamo sapere?

Uno specialista in questo campo e incaricato di insegnare alle persone ciò che devono sapere sullo sviluppo del cloud Steve Bryen nel ruolo di senior developer advocate for UK and Ireland at Amazon Web Services.

Bryen ci ricorda che la verità centrale qui è che gli strumenti, le tecniche e i dati demografici associati allo sviluppo del software sono cambiati radicalmente negli ultimi anni. In effetti, il cloud ha molte nuove realtà e inizia a svegliarsi. Oltre il 47% degli sviluppatori in tutto il mondo ha meno di dieci anni di esperienza nella scrittura di codice e il 58% degli sviluppatori globali privilegia la capacità di lavorare con le nuove tecnologie come fattore nella ricerca del loro prossimo ruolo.

Dalle sue interazioni con i clienti, Bryen di AWS afferma di aver visto emergere diversi modelli principali di sviluppo software moderno che stanno guidando un ritmo più elevato di adozione della tecnologia e cambiando il modo in cui organizziamo i team per fornire in modo più efficace.

“Costruire nuovi prodotti e rimanere competitivi è estremamente difficile se non si utilizza il cloud. Molte organizzazioni stanno lottando per rimanere competitive insieme a start-up dirompenti che possono avviare nuove aziende con investimenti infrastrutturali iniziali scarsi o nulli. Che tu sia una nuova startup o una delle più grandi organizzazioni aziendali del mondo, ora tutti hanno accesso alle stesse risorse. Con il cloud, non è più necessario investire in risorse locali che potrebbero non soddisfare le tue esigenze oggi, avere cicli di approvvigionamento che ti rallenteranno o addirittura ti impediranno di iniziare. Il cloud consente la sperimentazione a basso rischio, la possibilità di provare cose nuove senza costi iniziali significativi “, ha affermato Bryen

La cassetta degli attrezzi del meccanico cloud

Il team di sviluppatori di cloud AWS spiega che quando si sviluppa sul cloud, i servizi sono generalmente disponibili a livello di programmazione tramite le API (Application Programming Interface), i Software Development Kit (SDK) e le Command Line Interfaces (CLI) – tutto ciò alla fine ci abilita (il utenti e clienti) per trarre vantaggio da un altro requisito fondamentale fondamentale che è Infrastruttura come codice (IaC).

Servizi come AWS CloudFormation o HashiCorp Terraform consentono ai clienti di definire le risorse dell’infrastruttura cloud come codice, insieme al codice dell’applicazione. Ciò consente alle organizzazioni aziendali di impacchettare sia le app tradizionali che le app moderne, in modo chiaro e dichiarativo. La società afferma che si tratta di un “acceleratore essenziale” per la standardizzazione che riduce il rischio di modifiche manuali alla configurazione.

Dato che ora miriamo a spostarci nel mondo del cloud componentizzato componibile più individualmente, dobbiamo pensare ai microservizi. Bryen ci ricorda che il termine “microservizi” esiste da un po ‘di tempo, ma afferma che vede ancora molti clienti non riuscire a realizzare vere architetture di microservizi. Spesso dice che le loro applicazioni possono essere descritte come un “monolite distribuito”, cioè simile a un grosso pezzo di software singolarmente centralizzato, ma costruito come un anacronismo nel cloud moderno.

“Sebbene sia importante utilizzare l’architettura giusta per ciascuno dei tuoi carichi di lavoro e i microservizi potrebbero non essere adatti a te, l’obiettivo di suddividere le applicazioni in componenti più piccoli è quello di avere parti che si scalano e si guastano indipendentemente l’una dall’altra. Le aziende che implementano microservizi in genere hanno un volume molto più elevato di versioni di funzionalità poiché il rischio associato a una versione è contenuto per il servizio specifico, piuttosto che per l’intera app “, ha affermato Bryen.

Tre pilastri per l’eccellenza dei microservizi

Quando i dipartimenti tecnologici aziendali pensano di progettare i loro microservizi, Bryen afferma che dovrebbero prendere in considerazione i seguenti tre pilastri dello sviluppo del software:

“Innanzitutto, considera l’accoppiamento libero. Per assicurarsi che un servizio non dipenda serialmente da un altro, ove possibile. In secondo luogo, i microservizi dovrebbero avere un punto di ingresso standardizzato e dovrebbero essere ben documentati. Un’API è un esempio ovvio qui, dove spesso usiamo HTTP. Sebbene spesso sia la scelta giusta, l’HTTP non è sempre necessario e può introdurre altre complessità, quindi pensa a come i servizi possono essere attivati ​​usando meccanismi diversi, come code o bus di eventi se sono più adatti. La terza considerazione è quella di pensare ai dati di cui ciascuno di questi servizi ha bisogno per accedere / gestire “, ha affermato Bryen.

Lavorando con una vasta gamma di clienti come fa la società, il team di AWS afferma di vedere spesso i clienti che dividono le app in microservizi, ma che usano ancora con un database monolitico. Bryen avverte che la condivisione di un database in questo modo non è un risultato ideale. Questo perché si perdono molti dei vantaggi dell’accoppiamento lento e si introducono potenzialmente singoli punti di errore. Dice che dovremmo sempre considerare l’uso del database giusto per il lavoro, ad esempio un microservizio potrebbe aver bisogno di un database relazionale, un altro NoSQL e un altro un database di contabilità e così via.

Vale la pena ricordare che quando si implementa un’architettura di microservizi si aggiunge ulteriore complessità, poiché l’applicazione ora ha molte parti mobili. Per alcune organizzazioni, dire una startup, costruire con un monolito può avere senso in primo luogo, ma queste organizzazioni dovrebbero considerare di costruirlo con chiare astrazioni in modo che possa essere suddiviso in servizi più piccoli man mano che si espandono.

Servire senza server, ad ogni (possibile) servizio

Come altro principio guida chiave qui, dobbiamo pensare al passaggio al computing senza server. Come discusso e spiegato prima qui, serverless consente ai programmatori (e ai team operativi con cui lavorano) di non perdere tempo a preoccuparsi di configurare, ottimizzare e ridimensionare le applicazioni affinché funzionino in un determinato modo: tutto ciò che viene gestito dal back-end viene gestito dal provider cloud.

Bryen spiega che il serverless è una questione di velocità e si concentra sulla logica di business, invece di costruire e gestire l’infrastruttura. Si tratta di costruire vs acquistare e lasciare che i fornitori di cloud (che probabilmente hanno molta più esperienza) si occupino della gestione e della gestione di questi servizi altamente disponibili e scalabili in modo che tu possa concentrarti sullo spostamento veloce e sull’introduzione di nuove funzionalità per i tuoi prodotti.

“Il termine serverless è nato nel 2014 quando AWS ha lanciato AWS Lambda, un servizio di elaborazione che esegue il codice degli sviluppatori in risposta agli eventi. Da allora il nome è spesso associato a servizi di calcolo, generalmente noti come funzioni senza server. Tuttavia, serverless è molto più di un semplice calcolo; le caratteristiche degli strumenti senza server si applicano anche a molti altri servizi basati su cloud. Queste caratteristiche includono mai il pagamento inattivo, il ridimensionamento automatico (incluso a zero), la disponibilità elevata integrata e la fatturazione pay-per-use. Queste caratteristiche indicano che serverless si applica non solo al calcolo ma a molti servizi cloud di database, notifiche, analisi, archiviazione, machine learning e integrazione delle applicazioni. Dovresti prendere in considerazione l’utilizzo di servizi con queste caratteristiche prima di adottare un approccio più tradizionale “, ha affermato Bryen.

Diversi strumenti, diversi “risultati” del software

È abbastanza chiaro da questa discussione e altri fattori chiave che il cloud computing è essenzialmente e profondamente diverso dall’informatica-computing (per così dire) all’interno, con i suoi metodi, strumenti, procedure e blocchi fondamentali (come i microservizi e la possibilità di passare senza server) essendo diversi dal punto di vista operativo e meccanico.

La promessa che dovremmo essere in grado di togliere da tutta quella nuova realtà è la possibilità di ottenere “risultati” diversi software da questo diverso software. Le organizzazioni possono calcolare con maggiore potenza, maggiore flessibilità e una capacità notevolmente accelerata di interconnettere e lavorare su nuovi canali.

Il cloud è cambiato, ma non tutti i software sono cambiati, tuttavia … ma queste sono alcune delle principali forze che influenzano il modo in cui le nostre dorsali IT vengono modellate per il prossimo decennio.



[ad_2]

Francesco Giuliani
Author: Francesco Giuliani

Italian Entrepreneur & King of Influencers.

Italian Entrepreneur & King of Influencers.

Leave a Reply

Your email address will not be published. Required fields are marked *