For a little while I’ve been maintaining a FaaS on Kubernetes list to track the many implementations of Functions as a Service running on top of Kubernetes. Today brings CloudState as the first addition in a little while, and it’s quite an interesting one for a variety of reasons.

Knative

I became aware of CloudState via Google’s Mark Chmarny linking to news from my InfoQ colleague Diogo Caeleto in a tweet:

Exciting to see new project building on top of @KnativeProject. We should really start that “built on Knative” page

I’ve spent a little time over the past few weeks trying to get my head around Knative, as I found it pretty bewildering. There was even a suggestion that Knative should itself be added to the FaaSonK8s list, which I finally decided was a no. The journey began with Ian Miell asking:

Anyone interested in how to set up a working knative environment for dev spun up with one script in the cloud for $0.18 per hour?

and me wondering why? Ian’s reply (along with some rumblings from DXC colleagues) got me pulled back in:

Ahhh. Well, I know right? But I get it now, as we belatedly realised recently that we were re-implementing it ourselves at $CORP and that this would save us a lot of sweat…

The point that emerged is that Knative isn’t itself a serverless platform that runs on K8s, but rather a kit of parts for those wanting to build such a thing. Google have already built their own in the shape of Cloud Run (which I touched upon yesterday in ‘Kubernetes and the 3 stage tech maturity model‘). I guess if a bank or similar determined that they couldn’t just use Cloud Run then their platform team could build their own using Knative. But CloudState is interesting for other reasons…

Stateful (and actor based)

Every meaningful IT system manages state, but for the sake of simplicity it’s pretty common for us to push the state management off to another system (the database) and build stateless systems. This lies at the heart of The Twelve-Factor App approach, and many other architectures.

Stateless is simple, but it can also be horribly inefficient. When I worked on grid computing some 15yrs ago most of the apps were stateless, which meant that the grid spent roughly half of its time waiting for data with the CPUs idle. Often the data it was waiting for was exactly the same data that was used for the last set of calculations, so we were effectively throwing away good data, and wasting time loading it up again. Given the cost of running thousands of servers that wasn’t sustainable, and we moved to a model where data was cached by a ‘data grid’.

I’ve been reminded of this in recent L8ist Sh9y podcasts interviewing Simon Crosby about his work at Swim.ai:

• Simon Crosby on Revolutionary Architecture Requirements for Edge
• Simon Crosby on Building Stateful Real-Time Applications at the Edge

What I see in CloudState has a number of commonalities to Swim.ai:

• Stateful
• Actor model 

So I’d expect that the powerful arguments Simon makes for these things in the context of his own work also extend to CloudState.

The serverless world has previously dealt with state by putting it into serverless state management services, but this model of keeping it close to the functional code shows promise of hitting the trifecta of better, faster, cheaper.