Predictions for the direction of serverless platforms

While at JeffConf I had a particularly interesting conversation with Anne, James and Guy. Inspired by that, and the fact James is currently writing a blog post a day, I thought I’d have a go at writing up some of my thoughts.

I want to focus on a couple of things relevant to the evolution of Serverless as a platform and the resulting commercial ecosystem, namely the importance of Open Service Broker and a bet on OpenWhisk.

The above is a pretty high-level picture of how I think Serverless platforms are playing out. I’ve skipped a few things from the diagram that I’ll come back to, and I’m not trying to detail all options, just the majority by usage, but the main points are probably:

OpenWhisk

OpenWhisk is one of a number of run-your-own-serverless platforms vying for attention. My guess is it’s the one that will see actual market adoption over time.

One of the reasons for that is that Red Hat recently announced they are supporting OpenWhisk. Specifically they are working to run OpenWhisk on top of Kubernetes which I see as being something that will tap into the growing number of people and companies adopting Kubernetes in one form or another. Kubernetes provides a powerful platform to build higher-level user interfaces on, and I see it ending up as the default here.

There are a few things that could make this prediction much messier. One of those is that OpenWhisk is currently in the incubator for the Apache Foundation. CNCF has been building up a product portfolio across tools in this space, and has a Serverless working group. It would be a shame if this somehow ends up with a perceived need to bless something else. The other might be say an aquisition of Serverless Framework by Docker Inc, or a new entrant completely.

Open Service Broker

Without supporting services to bind to, Serverless computing doesn’t look as interesting. Although you’ll see some standalone Lambda usage it’s much more common to see it combined with API Gateway, DynamoDB, S3, Kinesis, etc. The catch is that these are AWS services. Azure (with Azure Functions) and Google Cloud (with Cloud Functions) are busy building similar ecosystems. This makes the barrier to entry for a pure technology play (like OpenWhisk or something else) incredibly high.

AWS Services work together because they are built by the same organisation, and integrated together via the shared AWS fabric. How can you build that sort of level of agreement between a large number of totally unconnected third parties? What about exposing internal services (for instance your large Oracle on-premise cluster) to your serverless functions? Enter Open Service Broker.

Open Service Broker has been around since the end of last year. It defines an API for provisioning, deprovisioning and binding services for use by other platforms, for instance by Cloud Foundry or Kubernetes or similar. Here’s a quick example broker. I think we’ll see Open Service Broker powering some powerful higher-level user interfaces in other platforms eventually which aim to compete directly with, for instance, the ease of binding an API Gateway to a Lambda function in AWS. Especially if you’re a service provider I’d get a march on the competition and start looking at this now. This is also a potential avenue for the other cloud providers to expand on there claims of openness. I’d wager on us seeing Azure services available over Open Service Broker for instance.

A few extra observations

Overall I’ll be interested to see how this plays out, and whether my guesses above turn out to be anywhere near right. There will be a lot of intermediary state, with companies large and small, existing and new, shipping software. And like anything else it will take time to stablise, whether to something like the above or something else entirely. I feel like the alternative to the above is simply near total domination by 1 or maybe 2 of the main cloud providers, which would be less interesting to guess about and made for a shorter blog post.