Il computing serverless non è, nonostante il nome, l’eliminazione dei server dalle applicazioni distribuite. L’architettura senza server si riferisce a una sorta di illusione, originariamente realizzata per il vantaggio degli sviluppatori il cui software sarà ospitato nel cloud pubblico, ma che si estende al modo in cui le persone utilizzano il software. Il suo obiettivo principale è quello di rendere più facile per uno sviluppatore di software comporre codice, progettato per funzionare su una piattaforma cloud, che esegue un lavoro ben definito.
Se tutti i lavori sul cloud fossero, in un certo senso, “consapevoli” l’uno dell’altro e potessero sfruttare l’aiuto reciproco quando ne avevano bisogno, l’intera attività di cui i server li ospitano potrebbe diventare banale, forse irrilevante. E non dover conoscere quei dettagli potrebbe rendere questi lavori più facili da programmare per gli sviluppatori. È plausibile che gran parte del lavoro richiesto per raggiungere un risultato desiderato, potrebbe già essere stato fatto.
“Che cosa significa serverless per noi di Amazon AWS? “, Ha chiesto Chris Munns, senior developer advocate per serverless presso AWS, durante una sessione alla conferenza re: Invent 2017 . “Non ci sono server da gestire o provisioning del tutto, inclusi niente che sia bare metal, niente di virtuale, niente che sia un contenitore – tutto ciò che comporta la gestione di un host, l’installazione di patch su un host o la gestione di qualsiasi cosa su un sistema operativo livello, non è qualcosa che dovresti fare nel mondo senza server. “
Il modello di servizio funzionale senza server di AWS si chiama Lambda . Il suo nome deriva da un codice matematico di lunga data in cui un simbolo astratto rappresenta una funzione simbolicamente.
I pro e i contro
Il computing senza server è stato proposto agli sviluppatori come mezzo per produrre codice più simile a quello che è stato fatto negli anni ’70 e persino negli anni ’60, quando tutto era cucito insieme in un unico sistema. Ma questo non è un punto di forza per cui le aziende si preoccupano molto. Per il CIO, il messaggio è che serverless cambia il modello economico del cloud computing, con la speranza di introdurre efficienza e risparmi sui costi.
Benefici
Migliore utilizzo – Il tipico modello di business del cloud, che AWS ha sostenuto sin da subito, riguarda il noleggio di macchine (macchine virtuali (VM) o server bare metal o contenitori (come i contenitori Docker o OCI) che sono ragionevolmente autonome entità.
Virtualmente parlando, dato che hanno tutti gli indirizzi di rete, possono anche essere server. Il cliente paga per il periodo di tempo in cui questi server esistono, oltre alle risorse che consumano. Con il modello Lambda, ciò che l’affitto del cliente è invece una funzione – un’unità di codice che esegue un lavoro e produce un risultato, di solito per conto di un altro codice (che può essere una tipica macchina virtuale o un contenitore, o in teoria un’applicazione web ). Il cliente prende in affitto quel codice solo per il periodo di tempo in cui è “vivo”, solo per le piccole fasce di tempo in cui è presente s operativo. Addebiti AWS in base alla dimensione dello spazio di memoria riservato per la funzione, per la quantità di tempo in cui lo spazio è attivo, che chiama “gigabyte-secondi”.
Separazione dei poteri – Uno degli obiettivi di questo modello è aumentare la produttività dello sviluppatore occupandosi delle questioni relative alla pulizia, al bootstrap e all’ambiente (le dipendenze) in background.
In questo modo, almeno teoricamente, lo sviluppatore è più libero di concentrarsi sulla specifica funzione che sta cercando di fornire. Ciò lo costringe anche a pensare a questa funzione in modo molto più oggettivo, producendo così un codice nello stile orientato agli oggetti che la piattaforma cloud sottostante troverà più facile compartimentare, suddividere in più funzioni discrete e scalare su e giù.
Sicurezza migliorata – Limitando lo sviluppatore all’utilizzo di soli costrutti di codice che funzionano all’interno del contesto serverless, è più probabile che lo sviluppatore produca codice conforme alle best practice e con protocolli di sicurezza e governance.
Tempo di produzione: il modello di sviluppo senza server mira a ridurre radicalmente il numero di passaggi necessari per concepire, testare e implementare il codice, con l’obiettivo di spostare la funzionalità dalla fase idea alla fase di produzione in pochi giorni anziché mesi.
Svantaggi del computing serverless
Livelli di servizio incerti – Gli SLA (Service Level Agreement) che normalmente caratterizzano i servizi di cloud pubblico, devono ancora essere risolti per FaaS e serverless. Sebbene altri servizi Amazon Compute abbiano SLA chiari ed espliciti , AWS è addirittura arrivato a definire la mancanza di uno SLA per funzioni Lambda come funzionalità o “libertà”. In pratica, i modelli di prestazioni delle funzioni FaaS sono talmente indeterminati che è difficile per l’azienda o per i suoi concorrenti decidere cosa è sicuro che prometta.
Il codice non testato può essere costoso – Poiché i clienti di solito pagano con la funzione invocazione (per AWS, il massimo arbitrario standard è 100), è concepibile che il codice di qualcun altro, collegato al tuo tramite API, possa generare un processo in cui l’intero il numero massimo è invocato in un singolo ciclo, invece di uno solo.
Tendenza monolitica – Lambda e altre funzioni sono spesso introdotte nella conversazione come un esempio di creazione di piccoli servizi, o persino di microservizi, senza troppo sforzo per imparare o sapere cosa siano. (Pensa al codice che è suddiviso in unità separate, separate, ognuna delle quali ha un solo lavoro, e ottieni l’idea di base.) In pratica, dato che ogni organizzazione tende a schierare tutte le sue funzioni FaaS su una piattaforma, condividono tutte naturalmente lo stesso contesto. Ma questo rende difficile per loro aumentare o diminuire come i microservizi erano destinati a fare. Alcuni sviluppatori hanno intrapreso il passo inaspettato di unire il loro codice FaaS in un’unica funzione, al fine di ottimizzare il modo in cui viene eseguito. Eppure quella scelta di progettazione monolitica funziona in realtà contro l’intero punto del principio senza server:Amazon’s Elastic Container Service per Kubernetes , o una qualsiasi delle sue crescenti piattaforme di piattaforme basate su cloud come CaaS ( container-as-a-service ).
Scontro con DevOps – Liberando attivamente lo sviluppatore del software dalla responsabilità di comprendere i requisiti dei sistemi che ospitano il suo codice, uno dei thread necessari per raggiungere gli obiettivi di DevOps – la comprensione reciproca da parte degli sviluppatori e degli operatori delle reciproche esigenze – potrebbe essere tagliato
Il crescente mercato delle funzioni-come-servizio
Più di ogni altra organizzazione commerciale o open source, AWS ha assunto un ruolo guida nella definizione dell’assenza di server rispetto ai consumatori e al modello di business senza server. Ma la sua entrata in campo ha immediatamente attivato l’altro importante fornitore di servizi cloud per entrare nel mercato FaaS (indipendentemente dal fatto che adottino o meno il motivo serverless nella sua interezza): Azure Functions è l’approccio di Microsoft al modello event-driven. Google Cloud Functions è la piattaforma senza server di quel provider. E IBM Cloud Functions è l’approccio di IBM al framework serverless open source OpenWhisk .
Il tipico modello di business del cloud, che AWS ha sostenuto sin da subito, prevede il leasing di macchine – macchine virtuali (VM) o server bare metal – o container (come i contenitori Docker o OCI) che sono entità ragionevolmente autonome. Virtualmente parlando, dato che hanno tutti gli indirizzi di rete, possono anche essere server. Il cliente paga per il periodo di tempo in cui questi server esistono, oltre alle risorse che consumano.
Il modello di servizio funzionale senza server di AWS si chiama Lambda . Il suo nome deriva da un codice matematico di lunga data in cui un simbolo astratto rappresenta una funzione simbolicamente.
Il modello di business di Lambda computing serverless
Con il modello Lambda, ciò che l’affitto del cliente è invece una funzione – un’unità di codice che esegue un lavoro e produce un risultato, di solito per conto di un altro codice (che può essere una tipica macchina virtuale o un contenitore, o in teoria un’applicazione web ). Il cliente prende in affitto quel codice solo per il periodo di tempo in cui è “vivo” – solo per le piccole fasce di tempo in cui è operativo. Addebiti AWS in base alla dimensione dello spazio di memoria riservato per la funzione, per la quantità di tempo in cui lo spazio è attivo, che chiama “gigabyte-secondi”.
Il calcolo Lambda
Un’altra frase utilizzata da Amazon e altri nel marketing dei suoi servizi senza server è function-as-a-service (FaaS) . Dal punto di vista dello sviluppatore, è una frase pessima, dal momento che le funzioni nel codice sorgente sono sempre state e saranno sempre i servizi. Ma il “servizio” che è il soggetto della “S” maiuscola in “FaaS” è il servizio aziendale, come nel cloud “fornitore” di servizi. Il servizio lì è l’unità di consumo. Non stai pagando per il server ma per la cosa che ospita, ed è qui che AWS ha nascosto il server in computing serverless.
Amazon utilizza i termini “serverless” e “FaaS” in modo intercambiabile, e per gli scopi dei clienti che fanno affari nel regno di AWS, è giusto. Ma nel mondo più ampio dello sviluppo del software, non sono sinonimi. I framework senza server possono, e più spesso negli ultimi giorni, estendere i confini dei fornitori di servizi FaaS. L’ideale è che, se davvero non ti interessa chi o cosa fornisce il servizio, non dovresti essere vincolato dalle regole e dalle restrizioni del cloud di AWS, vero?
“L’idea è che è senza server, ma non è possibile definire qualcosa dicendo ciò che non è”, ha spiegato David Schmitz, uno sviluppatore della società di consulenza IT con sede in Germania, Senacor Technologies, parlando in una recente conferenza open source a Zurigo.
Citando la definizione AWS di serverless dal suo sito Web del cliente , Schmitz ha dichiarato: “Dicono che puoi fare cose senza pensare ai server: ci sono server, ma non li pensi e non sei obbligato a fornirli manualmente, per ridimensionarli, per gestirli, per correggerli e puoi concentrarti su qualsiasi cosa tu stia realmente facendo, il che significa che puoi concentrarti su ciò che conta, puoi ignorare tutto il resto.
Distinguere tra computing serverless da FaaS
Nel suo recente libro O’Reilly Designing Distributed Systems , Microsoft Distinguished Engineer e il co-creatore di Kubernetes Brendan Burns avverte i lettori di non confondere serverless per FaaS. Mentre è vero che le implementazioni FaaS oscurano l’identità e la configurazione del server host dal cliente, non è solo possibile ma, in determinate circostanze, è auspicabile che un’organizzazione esegua un servizio FaaS su server che non solo gestisce esplicitamente, ma ottimizza soprattutto per FaaS. FaaS può apparire senza server da un angolo.
Un modello di programmazione senza server e un modello di distribuzione senza server, dicono alcuni sostenitori, non sarebbero vincolati a un singolo server o a un singolo fornitore di servizi.
Ti chiedi dove è andato il server
Serverless dovrebbe essere un seminario cloud a tempo indeterminato. Ottimisticamente, dovrebbe incoraggiare gli sviluppatori a costruire, ad esempio, servizi che rispondano ai comandi, come “Richiama il mio negozio di alimentari e chiedi loro di tenere due bistecche di strisce KC per me”. Il processo di costruzione di un tale servizio farebbe leva sul codice già scritto che gestisce alcuni dei passaggi coinvolti.
L’ideale senza server orientato allo sviluppatore dipinge un’immagine di un mondo in cui uno sviluppatore di software specifica gli elementi necessari per rappresentare un’attività, e la rete risponde fornendo alcuni di questi elementi. All’improvviso il data center si trasforma in qualcosa di più simile a una cucina. Mentre uno chef può avere una ricchezza di risorse a sua disposizione, la maggior parte della gente di tutti i giorni cucina con verdure che provengono dai frigoriferi, non dai loro giardini. Ciò non rende i giardini in qualche modo cattivi o sbagliati, ma significa che molte più persone possono cucinare.
In pratica, “serverlessness” (un termine che ho inventato) è più di una variabile. Alcune metodologie sono più senza server di altre.
Il ruolo della programmazione basata sugli eventi
Potresti aver già supposto che un’applicazione distribuita ospitata nel cloud sia ospitata da server. Ma i server in questo contesto sono posti in una rete. Pertanto un’applicazione distribuita può fare affidamento su risorse software esistenti in luoghi diversi dall’host da cui è stato effettuato l’accesso. Immagina un sistema in cui “luogo” è irrilevante – dove ogni funzione e ogni risorsa utilizzata dal codice sorgente sembra “qui”. Immaginate invece di un Internet molto disperso, un grande luogo in cui tutto era ugualmente accessibile.
Al recente evento CloudNativeCon Europe a Copenhagen , Kelsey Hightower, promotore degli sviluppatori di Google Cloud Platform, ha presentato un modello comune di attività FaaS: uno che tradurrebbe un file di testo dall’inglese al danese, magari tramite un’API di apprendimento automatico. Affinché l’attività si adatti al modello, l’utente non dovrebbe mai vedere il file in lingua inglese. Una volta che il file di testo è diventato disponibile nell’archivio oggetti del server, i traduttori collegati a quell’archivio attiverebbero una funzione interna, che a sua volta avrebbe impostato il processo di traduzione.
Il modello FaaS di Hightower è un esempio di programmazione basata sugli eventi . Anche se non sei un programmatore, è probabile che tu abbia sentito parlare di questo concetto: è il principio fondamentale di ogni tipo di applicazione con finestre, incluso per Windows, Mac OS e applicazioni Web basate su JavaScript. In un sistema basato sugli eventi, i blocchi di codice sono attivati da eventi discreti, che giacciono dormienti e aspettano che accadano.
Una procedura evento non deve essere chiamata esplicitamente, il che significa che non deve essere indirizzata – un processo che spesso implica l’identificazione della sua posizione, che include il suo server. Se è impostato per rispondere a un evento, può essere lasciato incustodito come una trappola per topi o un DVR computing serverless.
Nelle applicazioni distribuite, i servizi vengono in genere identificati dalla loro posizione, in particolare da un URI che inizia con http: // o https: //. Naturalmente, la parte dell’URI che segue l’identificatore del protocollo HTTP è il dominio principale, che è essenzialmente l’indirizzo del server. Poiché un programma basato sugli eventi viene attivato passivamente, tale indirizzo non deve mai essere passato, quindi il server non deve mai essere controllato. E in questo senso, il codice diventa “senza server”.
Computing serverless Pubblico in cattività senza server
“Questo è bello – è come se il sogno diventasse realtà!” ha detto Google Hightower. Ha presentato il suo pubblico con tre scelte: “Puoi distruggere tutto il tuo codice, non puoi fare alcun codice, ma è un po ‘estremo, oppure potresti fare questa cosa senza server: è così che viene venduto Qualcuno vede il problema con questo?”
Dopo alcuni suggerimenti, Hightower ha rivelato ciò che caratterizza come un difetto nel modello: la sua dipendenza da un singolo framework FaaS, operante all’interno di un singolo contesto, entro i vincoli di un singolo provider cloud. La ragione per cui non vedi così tanti server in un contesto di questo tipo è perché sei dentro, dal suo punto di vista, l’unico che ci sia.
In altre parole, sei bloccato nella casa di Amazon.
Leggi anche: IBM presenta un nuovo modello di programmazione per la creazione di app senza server
Hightower è un sostenitore di un framework emergente, sviluppato sotto gli auspici della Cloud Native Computing Foundation (CNCF, anch’essa responsabile di Kubernetes), dal titolo CloudEvents . Il suo obiettivo è quello di creare un metodo comune per la registrazione di un evento, un’occorrenza che gli host dovrebbero osservare, anche se emerge da altri sistemi o piattaforme. In questo modo, un’attività o un metodo su una piattaforma cloud può attivare un processo su un’altra. Ad esempio, un documento memorizzato nell’archivio S3 di Amazon può attivare un processo di traduzione in danese su Google Cloud.
“L’obiettivo qui è definire alcune cose”, ha detto al pubblico. “Numero uno, il produttore possiede il tipo di evento, non tenteremo di standardizzare tutti gli eventi che possono essere emessi da tutti i sistemi.” Questa è una scappatoia, ma quello che vogliamo fare è forse standardizzare il busta in cui catturiamo quell’evento – un tipo di contenuto, [e] cosa c’è nel corpo. E poi abbiamo bisogno di prendere una decisione, e una di quelle decisioni finora è, forse possiamo usare HTTP per trasportarlo tra diversi sistemi “.
Precedente storico
Un po ‘di retroscena su ciò di cui parla Hightower: i primi tentativi di sistemi distribuiti – tra cui DCOM e CORBA – hanno imposto un tipo di regime centralizzato in cui il contesto dei lavori in corso di elaborazione è stato risolto ad un livello elevato da alcuni concordati -un’autorità. Qualcosa era in carica. Questo sarebbe l’opposto dell’ideale senza server; questo garantirebbe che ci sia sempre un ospite principale nella parte superiore della catena alimentare.
Questo concetto non funziona su larga scala, perché quell’host avrebbe bisogno di una sorta di directory di contesti onnicomprensiva, come il Registro di sistema di Windows, per specificare cosa significasse ciascun tipo di dati ea chi sarebbe appartenuto. Quel tipo di autorità va bene, se ti capita di essere il creatore di una piattaforma che vuole essere l’unica nuvola in città.
Leggi anche: Stressato sul lock-in senza server? Non essere – TechRepublic
I sistemi distribuiti di maggior successo che sono venuti alla luce da quando i giorni CORBA e DCOM hanno riconosciuto che ci sono modi per risolvere il problema del contesto reciproco in prossimità del runtime, attraverso una sorta di protocollo di negoziazione. Ecco cosa vorrebbe essere CloudEvents: un modo per utilizzare il Web che già abbiamo (HTTP) e i metodi che già utilizziamo (JavaScript e, per estensione, JSON) per avviare un dialogo tra sistemi che attraversano i confini della piattaforma cloud – che siano tra AWS, Google e Azure o tra un cloud pubblico e il cloud ibrido di un’azienda su VMware o OpenStack.
Vendetta dei server
Ma questo potrebbe non essere il tipo di quadro che gli sviluppatori del settore, come lo Schmitz di Senacor, vorrebbero vedere. Dalla sua prospettiva ed esperienza, uno dei principali vantaggi del computing serverless mentre lo pratica è la promessa della mancanza di un framework o di un protocollo per questi tipi di comunicazioni inter-cloud. In effetti, la presenza stessa di una tale struttura implicherebbe che ci fossero entità che hanno bisogno di comunicare a tutti – in effetti, server.
“Tutti noi amiamo framework, runtime e strumenti, e ce ne sono molti”, ha detto Schmitz al suo pubblico. “Ci sono cose come Serverless [Framework] che estraggono Lambda. Ci sono cose come Chalice che fa qualcosa in un modo simile. C’è Serverless Express dove puoi racchiudere un’applicazione esistente.
“Ye-uu-gh”, pronunciò, in una sola sillaba, come un orso bruno che scopre un cassonetto vuoto. “Non ne abbiamo bisogno: in realtà, non hai bisogno di un framework per lavorare con AWS, hanno un SDK, applicano pratiche sensate e starai bene.”
Schmitz ha ammesso che restare nel paradigma di AWS Lambda si traduce nella produzione di un codice un po ‘monolitico e inflessibile, difficile se non impossibile da scalare e un orso da proteggere adeguatamente. In cambio di queste concessioni, ha detto, Lambda fornisce allo sviluppatore una distribuzione istantanea, un codice che è abbastanza semplice da produrre e una curva di apprendimento che non è affatto eccessiva.
Schmitz e Hightower si trovano su lati opposti del percorso evolutivo del computing serverless nel data center. Nel corso della storia di questo settore, la semplificazione e la distribuzione si sono fissate l’un l’altra attraverso questa barricata in movimento.
La bolla pura
È stato l’obiettivo del movimento DevOps di rompere impasse come questo, e di incitare il coordinamento tra gli sviluppatori di software e gli operatori di rete a lavorare insieme verso una soluzione reciproca. Uno degli obiettivi dichiarati dei sostenitori senza server è stato quello di escogitare i mezzi per automatizzare processi come la conformità, handshake, sicurezza e scalabilità senza tutte quelle ingombranti interazioni umane. Il risultato finale dovrebbe essere che i processi manuali delle risorse di provisioning in altre parti del cloud – i processi che sono suscettibili di errore umano – vengono sostituiti con routine che si svolgono in background, così discretamente che lo sviluppatore può ignorare il server pur essendo lì . E poiché l’utente finale non dovrebbe preoccuparsi di nessuno, potrebbe anche essere veramente senza server.
Le architetture senza server, insistono, dovrebbero liberare lo sviluppatore dal doversi occupare dei dettagli dei sistemi che ospitano il suo software – per rendere irrilevante la parte Ops di DevOps nella parte Dev. Quindi non lavora senza server contro DevOps?
“Non vi è dubbio che, mentre ci si sposta verso livelli più elevati di astrazione delle piattaforme, ci sono oneri operativi che vanno via”, ha risposto Nigel Kersten, capo stratega tecnico per il fornitore di risorse CI / CD Puppet . “Adotti la virtualizzazione, [e] molti dei tuoi dipendenti non devono preoccuparsi tanto del loro metallo. Adotti l’infrastruttura come servizio nel cloud, [e] non devi preoccuparti del altri hypervisor. Adotti un PaaS, e ci sono altre cose che sostanzialmente vanno via. Tutti diventano problemi di “squadre minori”.
“Adotti senza server e affinché gli sviluppatori abbiano successo nello sviluppo e nella progettazione di applicazioni che funzionano su queste piattaforme”, ha proseguito Kersten, “devono anche imparare di più sul carico operativo e potrebbero essere diversi dal tuo amministratore di sistema tradizionale che si sta sottoponendo a racking e impilando l’hardware, e dovendo capire la velocità del disco e cose del genere, ma l’idea che gli sviluppatori possano operare in una bolla pura e non pensare affatto al carico operativo, è completamente delusa. Sto assistendo al successo delle distribuzioni serverless di successo, quelle di successo sono sviluppatori che hanno una certa esperienza operativa, hanno qualche idea di cosa significhi effettivamente gestire le cose in produzione, perché devono ancora fare le cose “.
Connettersi all’integrazione continua
I modelli di sviluppo che Kersten vede emergere nel campo senza server, ha detto a ZDNet, stanno emergendo solo ora come risultato di percorsi evolutivi che si ammucchiano contro i bordi di questa bolla proverbiale. È necessaria una nuova logica per risolvere i problemi di adattabilità affrontando il codice ottimizzato per FaaS, una volta che diventa ingombrato dallo stress della domanda dei clienti su larga scala. I sistemi di gestione della configurazione sul back-end non possono che andare così lontano. Il semplice atto di aggiornare una funzione richiede il tipo stesso di confronti A / B rispetto alle versioni precedenti che un contesto senza server, con la sua mancanza di confini contestuali, cercherebbe di abolire.
C’è anche il problema della pipeline di implementazione. Nelle organizzazioni che praticano l’ integrazione continua e la consegna continua (CI / CD) , la pipeline è il sistema di test e controllo di qualità che ogni componente del codice riceve, prima di essere rilasciato alla produzione per l’uso da parte dei consumatori. La stessa nozione di messa in scena implica compartimentalizzazione – di nuovo, contro l’ideale senza server dell’omogeneità.
Leggi anche: Ecco le 12 tendenze tecnologiche che domineranno il 2018 – TechRepublic
“Continuo a pensare che ci debbano essere ambienti di test, ci devono ancora essere ambienti di staging”, ha affermato JP Morgenthal, CTO per i servizi applicativi presso DXC Technology . “E sono ancora fermamente convinto che qualcuno dovrebbe essere responsabile per la convalida di qualcosa che si sposta nella produzione.
“So che ci sono alcune scuole di pensiero che dicono, va bene che lo sviluppatore spinga direttamente nella produzione. Netflix lo fa”, ha detto Morgenthal a ZDNet. “Qualcuno non ottiene i suoi film, certo, è una cosa negativa perché vuoi che i clienti siano felici, ma è molto diverso quando si lascia che qualcuno rilasci una nuova funzione all’interno di un’applicazione bancaria senza un’adeguata convalida a più livelli – sicurezza, etica , governance – prima che il codice venga rilasciato.Questo è ancora DevOps, perché deve ancora passare dallo sviluppatore che sviluppa, distribuisce, in un ambiente di test, a qualcuno che lo testa e che assicura che quelle cose rimangano, prima che possa fare il resto del modo in cui il gasdotto sarà inserito nella produzione “.
Riconciliazione
Dare agli sviluppatori l’aspetto di operare in una “bolla pura” – un rifugio ammortizzato, comodo e sicuro in cui tutto è previsto per loro – e dare a queste stesse persone un modo per integrare se stessi e i loro ruoli con tutti gli altri nell’IT, sembra essere due regali per le vacanze in competizione.
Certo, potremmo ancora ideare nuovi metodi automatizzati per raggiungere la conformità e la sicurezza che gli sviluppatori possono tranquillamente ignorare. Ma anche allora, la pura bolla di assenza di server potrebbe finire per servire come una sorta di rifugio temporaneo, un ufficio virtuale a porte chiuse per alcuni sviluppatori di evocare il loro codice senza interferenze dal mondo in rete al di fuori. Potrebbe funzionare per alcuni. Tuttavia, in tali circostanze, sarà difficile per i datori di lavoro e coloro che devono valutare il lavoro degli sviluppatori, percepire il modello architettonico senza server come qualcosa di diverso da un meccanismo di coping computing serverless.
