Serverless computing has come a long way since its humble origins with programming simple function services that typically are implemented in lightweight web or mobile apps. In a recent briefing with analysts, IBM reviewed its plans for serverless services in its cloud, and the future points to almost the exact opposite of simple functions: applications for complex supercomputing.
It’s part of an ongoing expansion of IBM Cloud Code Engine, first rolled out earlier this year, to become a broad-based platform for automating deployment and running code across a broad spectrum of use cases, from functions to PaaS, batch jobs, and containers-as-a-service. As we’ll note below, extending this up to supercomputing is a marked shift from the far humbler origins of serverless computing. But also, part of the roadmap is having the engine encompass a full spectrum of services, starting with functions as a service that IBM has offered for a number of years.
Serverless has always been about simplicity. Initially it pinpointed eliminating the need for developers to provision or scale infrastructure. The guiding assumption is that developers need to be proficient in the computing languages of choice – principally Java, JavaScript, Python – but they should not have to worry about setting up or managing distributed infrastructure, not to mentions the internals of Kubernetes (K8s).
As noted above, IBM already offers the basics: functions as a service. So do all the other major cloud providers. That’s where serverless started: at the time, the state of the art was the ability to auto-provision and autoscale relatively simple, short-lived workloads on commodity compute instances. IBM’s plans for Code Engine go beyond auto-provisioning and autoscaling to automatically containerizing your application. And there’s more. IBM’s roadmap for Cloud Code Engine also encompasses a Platform-as-a-Service (PaaS) that will containerize, deploy, scale, and run code. Under the same umbrella service, Code Engine will also support batch jobs, where customers bring the job, and it will deploy, scale, and run it. The same goes for containers, either that customers develop or source from third parties.
And, IBM is looking to serverless Code Engine to simplify the onramp to popular open source frameworks such as Ray, CodeFlare, Spark, TensorFlow, and so on. IBM’s Project CodeFlare is an open source project designed to simplify the integration of complex ML and AI pipelines through a common API; it is built atop the Ray project coming out of UC Berkeley’s RISELab, which provides an API for marshaling distributed computing sat scale. We provided background on Ray’s trajectory in a piece that appeared in these pages a few weeks ago. This post lays out the steps for setting up Ray in Code Engine; we would love to see the next phase, where Code engine provides the means to automate many of these steps and doing away with the need for command line interfaces.
Another piece of the puzzle is building new middleware that would allow AI workloads to run in hybrid cloud, with IBM Cloud Satellite as the intended delivery vehicle. Running training and inference (production) workloads for AI will require the orchestration of multiple tools and runtimes.
This is not your father’s serverless. Getting to batch jobs, applications, containers, and supercomputing raises the complexity of the task for serverless. No longer is it a matter of automatically apportioning off the same commodity compute for compact functions because now the workloads are as diverse as the normal IT estate. There’s worlds of differences for the compute instances that are automatically provisioned for batch jobs vs. simple functions, not to mention to neural networks and massively parallel compute that can be associated with supercomputing and deep learning workloads. One size won’t fit all.
IBM has been hardly alone in expanding the reach of serverless beyond functions. the services offered by each of the major cloud providers have also expanded beyond functions. For instance, AWS supports running containers, event-driven apps and workflows, and syncing GraphQL APIs (for mobile apps). On Azure, there are serverless services for compute, workflow orchestration, containerized AI services. Google Cloud offers services for running containerized and web app hosting.
Serverless has also created a major presence in the data space, where many operational and analytic data platforms are offered as serverless, either as option or by default. For instance, Amazon DynamoDB and Aurora; Azure SQL Database and Cosmos DB; and Google Cloud BigQuery and Firestore are offered serverless, either by default or as options. The same goes for MongoDB and DataStax, that have in recent months rolled out serverless. The same goes for data-related services such as AWS Glue and Azure Data Factory for data transformation and Amazon Kinesis and Google Cloud Dataflow for data streaming.
However, nothing is a further cry from the origins of serverless (for functions) as the notion of bringing serverless to supercomputing, a.k.a., high performance computing or HPC, or in the vernacular, embarrassingly parallel compute workloads. This is much more challenging terrain because the data pipelines and compute are far more complex, and more challenging to model. While some forms of supercomputing can simply chain together masses of commodity hardware, other workloads (especially with deep learning) may require more specialized instances, or a mix of commodity and specialized silicon, memory, and storage, and so on.
Now we’ll top it off: Ultimately, IBM’s stretch goal is making quantum computing available as a serverless service. IBM may not be the only cloud provider taking serverless beyond its modest roots with deploying functions, but it is certainly ambitious in taking serverless to extreme compute.
Disclosure: IBM is a dbInsight client.
