OK, let’s talk. Here’s how I think about it.
First – start at the start.
Like most things – this doesn’t “start” at the infrastructure or technology space, but rather at the “problem statement” and then that leads to the app domain, then the infra domain.
There’s a world of applications and workloads that are event-driven – these are often called “reactive systems”.
If any of you with IoT stuff at home use IFTTT (If this then that) you understand the idea of “events” triggering “action”.
Reactive systems have led to creating a new way of tackling those problem spaces – with event storming sessions as the framework for how teams tackle them and Reactive Programming or Functional Programming models as the tools that developers use to solve the problems.
I’ve linked to base google searches to help you – if you’re like me, you like to understand thoroughly, and there’s a TON of fascinating reading in there. I would encourage you to carve out some time, follow the threads, read and learn. These are not new ideas (functional languages have existed since the 1950’s and LISP was one I learned a long, long time ago)… but these are important ideas that have recently “broken out” and are having a bigger impact and on the world.
Second – travel from the start to the implications.
Those event/reactive programming models have different platform needs, and create new platform needs – namely developer constructs (ergo runtimes not infra) but platform needs that have underlying infra capabilities to scale up and down as functions are used, scale to zero (don’t have any events = don’t use any functions = don’t use any infra), and spin up VERY quickly (needs to have a very short “startup tax”). This is sometimes called “serverless” which is a strange name (there are servers after all) – but to the user, since FaaS models scale to zero, and they are developer abstractions (not infra) – the name makes sense.
This is the world of Functions as a Service or FaaS.
Now FaaS and PaaS are kissing cousins – they are both app-dev driven ideas, not “infra up” ideas (like containers per se – although all PaaS/FaaS models build on container/cluster managers). The core difference between PaaS and FaaS is really in this idea of “spin up fast, and scale to zero” – but I would resist the temptation I’ve talked about many times in other posts to conclude “one replaces the other” (the human instinct to view “A,B,C,D,E” as a multiple choice “OR” question versus an “AND” question). There are long-running processes, there are short running event driven processes. That’s why there are multiple abstractions needed in the universe we live in.
A popular examples of things in the Function ecosystem is Pivotal’s own Spring Riff (“Riff is for Functions” – a polyglot function as a service runtime, and also recursive acronym). OpenWhisk, Azure Functions are another.
Another is Amazon Lambda which has perhaps the broadest “beyond the developer” industry awareness – which a runtime (that includes infra spin-up/down underneath the runtime) on AWS.
I think, particularly for infrastructure readers, it’s super-useful to reframe your thinking about the developer, and this Riff demo does this well using an example that shows a Riff with a Kafka trigger event:
Today’s news is something I was hinting about in this post here.
Third – go from early implications to broadening the aperture.
Today, most FaaS platforms are bound to one cloud or another, or are linked to one specific framework. This is ok, but not great.
In a nutshell, Knative is about trying to create a open ecosystem, extensible OSS model for Function as a Service that couple be built on top of Kubernetes. It could be the basis for a multi-cloud, polyglot FaaS – and that’s something we deeply believe in.
You can see this pattern of “platforms must be open, must be multi-cloud, must be polyglot” thinking in how Pivotal continues to evolve Pivotal Cloud Foundry from a single abstraction to multi-abstraction. It’s also one of the reasons Project KUBO (now the CFCR) was born together with Google, and formed the core of what is now PKS.
We think that whether the abstraction is lower-level developer-friendly infrastructure (Container = Kubernetes = PKS) or higher-level developer-friendly app platforms for long-running processes (App Services = Cloud Foundry = PAS) or higher-level developer-friendly app platforms for short-running event-driven processes (Functions = Knative + Riff = PFS) – there are things platforms have in common:
- Platforms need to be multi-cloud. Why? People will want to run workloads all over the place, and nature abhors monopolies. You can see this playing out in realtime. It’s not that people won’t make choices to bind themselves to one cloud or another – it’s just that needs to be a very conscious choice. Hint – use the Open Service Broker (another project where Google and Pivotal are material contributors) wherever you can to insulate you.
- Platforms are something you consume, you do not construct. Why? Customers need to be enterprise-ready platforms that they don’t spend their lives building/maintaining the platform itself. This focuses their time above the “value line”. If you are constantly building/maintaining the platform vs. someone else doing it for you – you simply cannot move up the abstraction/value ladder. This world view commonly why sometimes “builder” persona types below the platform layer just absolutely do not like Pivotal, and tend to prefer vendors that provide “erector set” operational models. Follow some of the thread in this post, and you can see the “platform builders” vs. “platform users” live from a customer’s eyes. I’m not saying we’re perfect (we’re not) – but we strive for the standard where customers’ platforms auto-update constantly via CI pipelines from Pivnet – and they don’t spend time constructing the platform. On our most mature platforms (PAS) we do this really well. It’s also why we will continue to refine HOW we build PAS, but that is not the headline for customers using PAS. To them, it’s a platform, they consume it, and it works. Over time we’ll get to the same point with PKS and PFS.
- Platforms need a healthy ecosystem – below them, beside them, on top of them. Why? This isn’t for the ecosystem’s own sake or because I’m an OSS hippy-dippy, but rather this is a pre-requistite for the platform to sustain in a good way. There are such things as a vibrant, but unhealthy ecosystem (those projects have serious “trough of disillusionment” periods that sometimes never transition). Platforms need to be built on things that have enough of an open ecosystem rally that they can sustain – that most often have a “benevolent center”. It’s not about open source per se, but about what OSS can create (see this post).
Now – I don’t want to over-sell this (as exciting as it is). KUBO started a year and a half ago, and we’re just now getting to the point where we have a Pivotal and VMware PKS platform that one can consume vs. construct (and it’s still early days). Knative + Riff as OSS projects turning into a platform one can consume as PFS will take time. But – you can see where we are going.
Some of the “story behind the story” of how we got here on Knative is fascinating – head on over here for a read.
For those of you at Google.Next – there’s a great session if you want to dig in. It’s TODAY, from 4:35-5:25pm PT: Kubernetes, Serverless, and You and includes Ryan Morgan (@ryanmorgan – one of the early Knative contributors at VP App Platform from Pivotal) along with DeWitt Clinton, Ryan Gregg (both product managers at Google), and Ramprakash Gopinathan from T-Mobile.
There’s another breakout session on Wednesday with more technical deep dives and demos – same bat-time, same bat-channel 4:35-5:25pm: One Platform for Your Functions, Applications, and Containers
There is also a keynote session being streamed on Wednesday at 9which you can tune into here.
Knative is pronounced
“native” “kay-native” (grr – the inconsistent pronunciation in Kubernetes land is a pet peeve). You can find the github repo here. We have contributed parts of Riff to the Knative effort to accelerate it – and you can see Pivotal contributions throughout (details on what has been contributed, what has not can be found here). Words are just words, powerpoints are nearly worthless – code speaks and customers sing 🙂
Congrats to the Knative, Riff teams and the ecosystem!
… And just like PKS is maturing into a platform people can build on (like they do with PAS today) – expect PFS to mature in the years to come (and build on PKS, leveraging Knative and Riff – more here)