Il computing serverless ha fatto molta strada dalle sue umili origini con la programmazione di semplici servizi di funzioni che in genere vengono implementati in app Web o mobili leggere. In un recente briefing con gli analisti, IBM ha rivisto i suoi piani per i servizi serverless nel suo cloud e il futuro indica quasi l'esatto opposto delle funzioni semplici: applicazioni per supercalcoli complessi.
Fa parte di un'espansione in corso di IBM Cloud Code Engine, lanciata per la prima volta all'inizio di quest'anno, per diventare un'ampia piattaforma per automatizzare la distribuzione e l'esecuzione del codice in un'ampia gamma di casi d'uso, dalle funzioni a PaaS, lavori batch e contenitori -come-servizio. Come noteremo di seguito, estendere questo fino al supercalcolo è un netto cambiamento rispetto alle origini molto più umili dell'elaborazione serverless. Ma anche parte della tabella di marcia prevede che il motore comprenda una gamma completa di servizi, a partire dalle funzioni come servizio che IBM offre da diversi anni.
Il serverless è sempre stato sinonimo di semplicità. Inizialmente ha individuato l'eliminazione della necessità per gli sviluppatori di fornire o ridimensionare l'infrastruttura. L'assunto guida è che gli sviluppatori devono essere competenti nei linguaggi di elaborazione preferiti – principalmente Java, JavaScript, Python – ma non dovrebbero preoccuparsi di configurare o gestire un'infrastruttura distribuita, per non parlare degli interni di Kubernetes (K8).
Come notato sopra, IBM offre già le basi: funzioni come servizio. Così fanno tutti gli altri principali fornitori di servizi cloud. È qui che è iniziato il serverless: all'epoca, lo stato dell'arte era la capacità di eseguire il provisioning automatico e il ridimensionamento automatico di carichi di lavoro relativamente semplici e di breve durata su istanze di elaborazione delle materie prime. I piani di IBM per Code Engine vanno oltre il provisioning automatico e la scalabilità automatica per containerizzare automaticamente la tua applicazione. E c'è di più. La roadmap di IBM per Cloud Code Engine comprende anche una Platform-as-a-Service (PaaS) che containerizza, distribuisce, ridimensiona ed esegue il codice. Sotto lo stesso servizio ombrello, Code Engine supporterà anche i lavori batch, in cui i clienti portano il lavoro, e lo distribuirà, scalerà ed eseguirà. Lo stesso vale per i contenitori, sviluppati dai clienti o forniti da terze parti.
Inoltre, IBM sta cercando un motore di codice serverless per semplificare l'accesso a framework open source popolari come Ray, CodeFlare, Spark, TensorFlow e così via. Il progetto CodeFlare di IBM è un progetto open source progettato per semplificare l'integrazione di pipeline complesse di ML e AI attraverso un'API comune; è costruito sulla base del progetto Ray che deriva da RISELab di UC Berkeley, che fornisce un'API per il marshalling su scala satellitare di calcolo distribuito. Abbiamo fornito informazioni sulla traiettoria di Ray in un pezzo apparso su queste pagine qualche settimana fa. Questo post illustra i passaggi per la configurazione di Ray in Code Engine; ci piacerebbe vedere la fase successiva, in cui il motore di codice fornisce i mezzi per automatizzare molti di questi passaggi e eliminare la necessità di interfacce a riga di comando.
Un altro pezzo del puzzle è la creazione di un nuovo middleware che sarebbe consentire l'esecuzione dei carichi di lavoro AI nel cloud ibrido, con IBM Cloud Satellite come veicolo di consegna previsto. L'esecuzione di carichi di lavoro di formazione e inferenza (produzione) per l'intelligenza artificiale richiederà l'orchestrazione di più strumenti e runtime.
Questo non è il serverless di tuo padre. Arrivare a processi batch, applicazioni, contenitori e supercalcolo aumenta la complessità dell'attività per il serverless. Non si tratta più di ripartire automaticamente lo stesso calcolo di base per funzioni compatte, perché ora i carichi di lavoro sono diversi come il normale ambiente IT. Esistono moltissime differenze per le istanze di calcolo che vengono automaticamente fornite per i processi batch rispetto alle funzioni semplici, per non parlare delle reti neurali e dell'elaborazione massicciamente parallela che possono essere associate a carichi di lavoro di supercalcolo e deep learning. Una taglia non va bene per tutti.
IBM non è stata l'unica ad ampliare la portata delle funzioni serverless oltre. anche i servizi offerti da ciascuno dei principali cloud provider si sono estesi al di là delle funzioni. Ad esempio, AWS supporta l'esecuzione di container, app e flussi di lavoro basati su eventi e la sincronizzazione delle API GraphQL (per app mobili). In Azure sono disponibili servizi serverless per il calcolo, l'orchestrazione del flusso di lavoro e servizi di intelligenza artificiale in contenitori. Google Cloud offre servizi per l'esecuzione di container e hosting di app web.
Serverless ha anche creato una presenza importante nello spazio dati, dove molte piattaforme dati operative e analitiche sono offerte come serverless, come opzione o per impostazione predefinita. Ad esempio, Amazon DynamoDB e Aurora; Database SQL di Azure e Cosmos DB; e Google Cloud BigQuery e Firestore sono offerti serverless, per impostazione predefinita o come opzioni. Lo stesso vale per MongoDB e DataStax, che negli ultimi mesi hanno implementato il serverless. Lo stesso vale per i servizi relativi ai dati come AWS Glue e Azure Data Factory per la trasformazione dei dati e Amazon Kinesis e Google Cloud Dataflow per lo streaming dei dati.
Tuttavia, nulla è un ulteriore grido dalle origini del serverless (per le funzioni) come l'idea di portare il serverless al supercalcolo, ovvero l'elaborazione ad alte prestazioni o HPC, o in vernacolo, carichi di lavoro di calcolo imbarazzanti paralleli. Questo è un terreno molto più impegnativo perché le pipeline di dati e il calcolo sono molto più complessi e più difficili da modellare. Mentre alcune forme di supercalcolo possono semplicemente concatenare insieme masse di hardware di base, altri carichi di lavoro (specialmente con il deep learning) possono richiedere istanze più specializzate o un mix di silicio, memoria e storage di base e specializzati e così via.
Ora lo completeremo: in definitiva, l'obiettivo prioritario di IBM è rendere disponibile il calcolo quantistico come servizio serverless. IBM potrebbe non essere l'unico fornitore di servizi cloud a portare il serverless oltre le sue modeste radici con l'implementazione di funzioni, ma è certamente ambizioso nel portare il serverless a un'elaborazione estrema.
Divulgazione: IBM è un client dbInsight.
< h3 class="heading"> Big Data
Dov'è il launchpad del cloud ibrido di IBM? Sette modi per rendere la tecnologia in tempo reale reale per la tua organizzazione Machine learning all'edge: TinyML sta diventando grande Quali sono le prospettive di Cloudera? McDonald's vuole “democratizzare” l'apprendimento automatico per tutti gli utenti nelle sue operazioni
Argomenti correlati:
Cloud Digital Transformation Robotica Internet of Things Innovation Software aziendale 