Serverless, Knative, & Project riff, with Mark Fisher

Episode 97 · 50:13 · SRT · archive.org · all Tanzu Talk

Well, this is not a tremendous amount of news this week. Thankfully, we have a guest who I think can fill the void of interesting factoids. Do you want to introduce yourself, guest? Sure. So my name is Mark Fisher, and I am the technical lead for Project Riff at Pivotal. And prior to that, I've spent the last decade, more than a decade now, on the spring team. And started with the spring team in 2006, and then worked on a number of projects there, including spring integration, and then spring cloud stream, spring cloud data flow, and spring cloud function as well, before shifting over to Riff and serverless and functions as a service and all those fun things about a year ago. And so a decade, what's that like? It's all been a blur. Yeah, I guess that happens. I mean, that's, let's see, if you get a laptop for three years, that means you've gotten three different machines from work? Is that right? Or is it different? That sounds about right, yes. Yeah? Maybe on its fourth. Yeah. Yeah. You got the one with the touchpad on it now? I do, and that I find annoying. And I'm just waiting for my chance to get the 32 gig of RAM on the 15-inch MacBook. Okay. Yeah, that would be crazy. Yeah. My wife has an older laptop, and I'd forgotten how nice those old buttons are. I guess you would call them keys in the modern era. But the keys are nice. They're not all like, I don't know. I mean, this keyboard's fine. It's very functional. But I feel like it's sort of like, it's like, I don't know about your grandparents, but you would go into their house, and they would have this formal living room that no one, it was, you know, I always thought it was funny. It's a living room that no one lives in, and you couldn't touch anything. And these keyboards feel kind of like you're not supposed to touch them. They're just... Do you, Coté, do you have one of the newer MacBooks?

Because I have an older one, so I still have like HDMI and USB. I don't have to carry around the 50 dongles. Do you have to carry around tons of things? I'm on dongle style here. Full dongle mode. Okay. I got the four out. Yeah, makes sense. Oof. What a problem. What a world. Yeah, yeah. The dongles now have their own firmware, so. Yeah, your dongles have dongles. There's too much going on here. I can't get it. Yeah, you know, when Pivotal sent me this, they sent me one of those. It's a very popular dongle for the USB-C that's got like three USB hubs and an HDMI internet port. And it also has a micro SD card. And it actually is... I enjoy the functionality of it, right? Because you can put in like a little USB, SD card and, you know, have storage on there. And it's fun to have the internet. But the problem is you get the 15 inch one. And I think the power pass through doesn't work, right? So, because that would be awesome if I actually just had one thing to plug in. Sure. But I don't. So, you know, it doesn't really pay off there. Anyhow. Well, there is no weather this week. But I did want to do one small update from Amsterdam. I finally ate some herring. Traditional Amsterdam food. Now, I didn't realize that it was raw herring, which is fine. It's no big deal. But, you know, you get this herring and they've deheaded or beheaded. I don't know what the proper fish and gutted it and taken off the skin. And then, but they leave the tail on and you just kind of like drop it in your mouth and eat it. You don't actually just like put it, you know, you chew it. And you kind of like put it in a bed of onions to have it attached there and eat it. And it was good. It's delicious. It's basically like sushi. Like it's not really that much of a different thing. So I think, and then it's quite affordable too. You can make a little lunch out of it without vegetables.

I guess, does onion count as a vegetable? That's like a root, isn't it? No, that seems fair. Yeah, that'll get your vegetable. That picture of you that you're including here is probably, we have to turn that into a Slack emoji or my new profile picture or something. But it's good. It is. I do have a small video, so maybe I can load Giphy up. Get ready. Yeah, I like it. It's good. And that was from the local grocery store. Imagine if you got it fresh. And, you know, another just before we get started with serious stuff that we get paid for. Another fun factoid about herring is that was, I think, the first way back, you know, way back when, way, way back when, that Amsterdam got wealthy is they invented a new technology, some new kind of boat, so they could go out into the North Sea for like three weeks. And then they also figured out that if you behead and gut and prepare the herring and salt it and stick it in barrels at sea, it would last a long time. So they could make a lot of, they could bring a lot of herring in and that made them lots of money. And what I like about that little factoid is it makes you realize that like even back in like the 1400s, there was just trade of barrels of herring just being sent around. People would, I mean, can you imagine eating some raw fish out of a barrel that was four weeks old? Man, I can't even come up with some stupid quip about that. I don't know if I could. Yeah. So times have improved. This is the golden age. That's right. Well, speaking of the golden age, it's been a quiet week for infrastructure software news. I think there was some relevant to our guest here. There was some coverage of like native or native or whatever, just some kind of follow-up and analysis, which, which also brought in some, some serverless things. And I don't know, I'll put, there's some links in there for people who in the show notes, if you want to look at it, but they're just, we've kind of talked about those things,

but have you, have you caught anything else there and your, your nets and your Dutch cog ships? I don't know how I do that kind of lead in. So a few minutes before we recorded, we actually announced that steel toe 2.1 ship. So if you're a .NET developer and you're using the latest .NET framework, .NET core, and trying to build these more observable systems, so you're doing distributed tracing, or you're trying to have better actuator support for .NET devs, that's great. That's fully available now. So that was nice news. And then I included one in here about that new-ish Intel chip foreshadow, the name of the flaw. That was another one of these things that had to quickly get patched. And another one of these that you can either run around with your, you know, kind of head cut off, trying to figure out how to patch systems and contact your OS vendor and roll out updates and figure out what breaks. We didn't really make a big deal of it because Ubuntu patched it. We rolled it out to customers and many of them are already updated because of Bosch and Comfort. So again, we like to talk about the operating system doesn't necessarily matter a lot to the end person who just wants to run software. It matters a ton as a baseline for what you're running. But when it's embedded in platforms, this stuff becomes boring even when they're critical updates. So it was kind of neat to see that get rolled out again and keeping you safe if you're running Cloud Foundry. I wonder if there's a committee where they name viruses. I'd like to be on that committee. Maybe they're less ominous, just like, you know, happy time. It's the happy time. Yeah, I mean, I'm not super worried about the Intel daisy problem or something like that. It really just makes me a buttercup, something that kind of makes me smile. The sunflower exploit. Yeah, that can't be too bad. That would be nice. Now, the other question, I don't want to ask this every week, but maybe every now and then. How's the book going? Almost done? Oh, me? Yeah, I'm more than halfway done. I'm feeling pretty good about that. I have had the obligatory one contact with the editor to tell them it will not be on the original schedule. I think it'll only be one time. I think I'll finish it when I'm supposed to now.

So it's going pretty well. Well, I figure book deadlines. Any kind of deadline is kind of like, you know, a serving suggestion. It's sort of, you know, add salt to taste. That's kind of what the deadline is, as I recall. Yeah, plus or minus three months. Three day time. Exactly. You might want a pinch of salt or a tablespoon. It depends. Yeah. Excellent. Well, so I'm always trying to finish up a little booklet that I have. And I published an excerpt. I've gotten a lot of, I wouldn't call it faint praise, but it's sort of, some people have told me that I have too many links. And so it takes a long time to read things. So I tried to post a smaller excerpt that maybe still has a lot of links. But anyways, it's basically this part on like, if you're doing your, we should work on phrases for this. If you're digital transformation, something, you know, and you're trying to be the sort of leaders of it. It's probably a good idea not to go it alone because that doesn't really work out very well. So you got to take a page from some classic change management or just really corporate life and build up some alliances and friendships and things like that. So it's very brief, but it's just a little, little write up of doing that and how some other people in the, I don't know, the pivotal world have done that. And also it gave me the chance over in medium, they have these things, you know, everyone is, has like snap clone things where they make these story cards. And wow, they're, they're doing something over there. Love it. I'm using those. It's unfortunate because it's, it's done for a mobile form factor, which renders perfectly in your browser on the desktop. But if you open it on the actual mobile device, uh, you have to install the medium app. So I don't know if that really works out well, but it doesn't know, no, I don't like it. Well, no, you're, you're, uh, your progress has been good though. I've liked following the last couple you've done. There's, I think you did one recently around even some measurement of things, right?

Of kind of progress and things like that. So I really liked that one. I'll probably use some of that for an upcoming talk. So a nice one. Measurements. Well, that's good to hear. I, I, I love a little measurements. Measurements are, are mysterious. I, as, as I've joked about, I think I might even mention this here. Like whenever you're a, I don't know if you've had this, if you two have had this experience when you write something, but measurements or metrics are one of those things where you ask people, uh, and you know that they know the answer and you're like, well, tell me what metrics that they use. And then they like go on poetically about like, well, what is a pudding? You've got a Yorkshire pudding and like a pudding cup. What is a pudding? And they get all philosophic. And then you're like, okay, I gotta, I got, you know, I got stuff to do my life. And then, and then you write something and you put it in front of them. And they're like, let me write you 50 pages on exactly what metrics are. And you're like, come on, how come you didn't just tell me about this in the beginning instead of putting talk. So hopefully that will lick some of that there. So, uh, I was gonna, I was gonna say, speaking of putting talk. Yeah. So, so why not, you know, first of all, I was, uh, I was, I was emceeing, uh, which happens to me, uh, some of my initials. Uh, I think the spring, uh, the spring tour, uh, let's see Dallas some time ago and spring platform tour, I think we call it. And the number one, the, the, the, thank you. The number one thing that people were asking, wanted to ask about that we didn't get to discuss with them was, uh, was project riff. They were all like, what is riff? And so, I mean, I mean, I'm putting the clock a little bit back, but back then, let's say this was in the spring, what, what would, how would you have answered them and told them what that was? Sure. Um, well, riff is a, uh, it's basically a function as a service platform that can run on any Kubernetes installation. So it can run on prem. It can run in, in a public cloud. And, um, we, I think that one of the key differentiators for riff is that we have focused on, um, an event

driven model at the core. So every function is invoked based on, um, an event. And back in the spring, that would have meant an event, um, being sent over Kafka. We were basically coupled to Kafka at the time, but, um, building on Kubernetes and, and running that Kafka code in a sidecar so that what the developer needs to provide is just a function that basically acts as a callback and the sidecar then, um, invokes that. So it was kind of the ideas behind some of the spring projects that we had built in the years leading up to that, um, such as, especially like spring cloud stream, where you would have a binder to Kafka or rabbit or some other event driven messaging middleware. And then the user just writes a function, just writes a callback to be invoked. Um, but we took that model into, um, Kubernetes and therefore made it polyglot. With, um, an extensible model for the actual invokers that, that handle that inversion of control. So, so I, I have a, I have a slightly, uh, off topic question cause you reminded me of something I'm always, I'm always wondering, and especially since you, you, you know, uh, been, been working on this for like 10 years or in this area when, when, when you're, when you're working on, I mean, let's, let's, let's say spring is, well, I guess it's called the spring framework. Spring is a framework that, that you use to build other things. Uh, it's sort of like, I, I guess you could just run spring on its own. That would be sort of fun. Be sort of like running an air conditioner with no one in the room. It'd be an interesting experiment. But, uh, so when you're building that and you decide to have like, um, a dependency, I guess, on something like Kafka, like, how do you think through that architecturally? Like, cause you can't, you can't build everything in it.

Like you, you have to use some other things and like, what, I don't know, like, how do you think through to do that or not do it? And, uh, the sort of compromises you made or make or the benefits, like what's the, uh, the decision tree for that kind of thing? Well, it's, it's tough because I think usually it involves defining an abstraction and getting that abstraction to be the right level where you're not creating the lowest common denominator, but you're actually, um, allowing people to choose what they plug in behind that abstraction for certain reasons and be able to expose the value of the reason they chose that thing, but in a way that is still, uh, pluggable. And so that usually in a, in a spring based application for something like the binders and spring cloud stream, that means that you can plug in Kafka, you can plug in rabbit, you can plug in, um, say Redis streams or, or, uh, if you're in a public cloud, you can plug in Kinesis, uh, on Amazon, for example. Um, and they're similar enough that an abstraction can define the common model there. And so that's what makes it pluggable, but then whichever one you choose, um, there may be certain parameters that you could specify in the declarative configuration that allow you to take advantage of some of its core features. So, so essentially like the, what you want to go for is, uh, you can swap out as, as they say the, the implementation underneath there, or, or you want to get as close to that as possible so that you're not sort of stuck with just the one thing that you, you would need to run. Right. Yeah. Yeah. I asked that cause I think the, uh, the first time I encountered this was way, way back when, when I was working, uh, on a systems management piece of software and, uh, you know, there's, there's, there's, uh, there's, there's, uh, there's, there's a joke about like, you know, the, the first thing you need to do is invent the world is sort of like how you set up any system. Uh, but, but the, the first thing you'd have to do for this system is install.

I forget which, which, uh, which TIBCO thing it was. I don't think they even owned it back then, but it was just like this. I, I think it was a Corbra thing. You had to set up this orb. And I remember when we went to the training, about two hours was spent setting up the orb before you even installed the software. So it's sort of stuck in my mind. So let me ask you, Mark, what you quick mentioned there kind of in passing was the event driven sort of foundation of riff and why you felt like that was something that was important. Do you see it as different than how kind of traditional FAS has been up till this point? So what is that, you know, what is that difference? Why do you, why do you call that out uniquely? Well, I, I do think, um, there's a difference in the, uh, extent to which it can support messaging patterns, right? So like in riff, um, we, by, by having the sidecar communicate with Kafka, one of the things that we could do between the sidecar and the container that hosted the developer's function is to manage that incoming, um, stream of events as a, an actual stream, um, through a gRPC, um, service binding, right? So then that means that the developer's code can actually handle streaming input. If you're using Java, you could, you could depend on a reactor flux. And if you're using JavaScript, you can depend on a node stream. Um, so there are some use cases that where that's valuable because then the, the, the function developer can, can perform windowing operations and map reduce type operations on the stream of data, as opposed to just single input, single output, which we also support, but that's, that's almost like the degenerate case, even if it's, even if it's the, uh, 80% case. So being able to support both of those, it's, it's very hard to build a model that takes the

other direction. I think where it assumes from day one, everything is just a single HTTP request. And then somehow we're going to add streaming on top of those. Right. I mean, that architecture, which is, as you say, it's kind of been, I don't know if to me, it's been, that's the dominant one, right? I mean, functions get spun up via mostly HTTP requests and there's not much state sharing or any sort of messaging paradigm there. So if you were doing this in a typical FAS today, would you be using an event stream processor and then bolting functions on so that you're still passing the data through something that has some of those primitives? Yeah. Well, I think, I mean, I'm thinking, for example, I'd have to use Kinesis with Lambda, right? Or something like that. Is that how I would stitch things together today? Well, okay, so that's an interesting one because in the Lambda example, if you choose to use Kinesis as your trigger, then you really end up with a different input type as opposed to if you're connecting your function directly to the API gateway to handle HTTP requests. And so that's the kind of consistent model that we're aiming for to where you can take a function and either write it for single input, single output, or streaming in, streaming out, and be able to plug that in to any, you know, independently of the upstream source of events, right? Right. That makes sense. So tell me a little bit about how we got to Knative. So, you know, if we were, we launched Riff at SpringOne Platform next year, kind of took the wraps off of you, did a great keynote presentation. You and Dave Sire did a fun breakout. People can go back and watch, which is well worth their time. But, you know, as we were going through the spring and all of a sudden, you know, the team wasn't doing as much Riff stuff and this other work was emerging, what was kind of the, you know, I guess we don't have to get the whole backstory, but more

importantly, why? Like, why did these efforts merge? What are you excited about with Knative that might have not happened if Riff had stayed on its current path? Right. So I think a big part of it is that, you know, at Pivotal, we talk a lot about the value line. And that's an important concept to our customers. And it's just as important when we're building things internally. So anytime that we discover that there's another effort where we could be part of a larger community that's building the foundation of something, then it's worth considering that as opposed to building it completely on our own. And so when we first heard about Knative, it seemed like there was a significant amount of overlap in the sense that they were adding custom resource definitions to create higher levels of abstraction on top of Kubernetes in order to support serverless workloads and functions. Now, to the extent that we looked at what, I mean, obviously, we were doing a lot of that in Riff ourselves. And it sort of triggered us to evaluate what extent of what we were doing in Riff was more generic and what was more specifically in our differentiation, like the event-driven paradigm. So a lot of the lower-level concerns are things that, like being able to scale automatically, scaling back to zero, providing metrics for the functions that are running, providing the observability of those functions. There are a lot of common concerns there. And so it made sense for us to at least consider that option. And then as we started collaborating with the team at the time, it was Google and then others also started to come on board.

And we shared some of our ideas around eventing. And our goal was basically to see if we could get enough of what we needed to support our model into Knative so that we could still build on top of it and then take advantage of what we hope becomes a larger ecosystem for the common foundation. So can you, like, throw a good illustrative or illustrative example of an application you might write in this style? Sure. I think, so with Knative, there's actually the idea that it's a unified model for scaling. Regardless of the type of workload. So they want to be able to support anything on the spectrum from applications to functions in a way that it can be auto-scaled and can be, the lifecycle can be managed from the developer's source code. So if you opt into having the build managed by the cluster, then that step is also in common. And, but for us on the Rift team, we were very focused on function-based runtime, the actual function-based use cases, right? So things like, I mean, there's the classic examples of something that runs relatively infrequently, so you don't want to have it consuming resources continuously, like the, when an image is uploaded to a directory, then you create thumbnails for it, or a video is uploaded and you create different formats for that video using a converter. But then there's also, in our world, many more kind of enterprise use cases where we see that

developers are breaking down these monolithic web applications into microservices and some of the most fine-grained pieces that fall out from that end up being good examples for running as functions. Maybe they're called infrequently or they're things that, that can take advantage of streams of events with the model that I was describing earlier. Yeah, it seems like, I mean, one of the, one of the examples, one sees a lot is like a, or I, I guess I should say, I, I see a lot as like a reservation system. And, uh, I don't know, even, even at least, uh, I assume from a, uh, a consumer, a person point of view, I don't know if there's someone who reserves things not on this model, but like even, even when I like go to, to kayak or whatever, and just search for flights, like that seems like a sort of one-time operation that might work well, like something just scurries off and looks for things and then returns it. And then, you know, crawls off to die somewhere until it's brought back to life again. But, uh, yeah, I, I mean, I mean all of those, those, uh, that, that kind of, you know, it's interesting, like, like you mentioned, uh, the idea of, as we said, whether it's like, you know, from, from zero to in or whatever, or scaling up or being bursty, like that seems to be like a primary characteristic of interest in, in doing serverless and K native stuff. I mean, is that, am I, am I, am I overemphasizing that? No, I think that's definitely true. I mean, on one end of the spectrum, you're, you're scaling to zero for, for applications where you don't, or at least specific functions within a larger application that, that don't need to be continuously serving traffic. Uh, some of those might be, there's always a trade-off. It might be that the latency requirements are not, um, very important, right? So it's like something that happens offline in reaction to something else, like updating

your, your, uh, flight miles or something after a flight, like it doesn't need to happen instantaneously. Um, other examples would be things that are very bursty. And so then you're, you're kind of on the, um, the scaling to inside, um, and that might be because there's irregular traffic or there might be something like, um, a sale for an online retailer. And so obviously they have, um, very inconsistent traffic and times when they need to scale much higher than the, than the steady state. Yeah. I think that more and more we see that, that even more traditional enterprise use cases start to fall into these categories because operations are running 24 seven and, um, things are, are moving online that didn't used to be. And you've got more and more fine grained ways of interacting with customers and chat bots and like there's more and more entry points into the system where, um, having, being able to break things up into more fine grained components is, is useful. Yeah. I mean, that definitely seems the, uh, it's, it's sort of like the issue, the issue, the, the fun mind problem I've always had around like, like, uh, serverless and functional programming stuff is to think about like, what are some types of applications that would be a poor fit for that? And, and as you're kind of saying that the reason why it's kind of a weird or a delightfully endless question is, well, if you can break things down into components, then almost anything can, I don't know, maybe not like video game playing or something like maybe, maybe if there's things that are like extremely real time and high latency, like you just have an ongoing process or whatever, but most of life isn't like this, this phone call. I don't know if this would work out serverless wise, but it's, it seems like a huge amount of things you could break down into a series of components that are linked together. Right. If you're starting from scratch though, I think what's always interesting there is if you were

building some of these systems from zero. Yeah. But I don't think Mark, have you seen much that migrates just natively to a function platform? It seems like that's often at least a refactor or rewrite. So, you know, sometimes I know, Coté, you're interested in also some of the legacy app story here. I guess there's that decision of, should you refactor an app into a series of interconnected functions? Or is this something you see for new types of use cases or kind of what's your take on serverless as a whole and how this is supposed to fit into somebody who probably already has a lot of investments in software? Yeah. I mean, I think that's, it's definitely more of a, it's, it's more appealing as a runtime model for a greenfield development. I think that on the just like pragmatically looking at the way people break down a monolith is often following patterns like the, the strangling the monolith pattern. Right. And usually there's a point where you reach diminishing returns. So you're not going to literally break that monolith down into a thousand functions and then, you know, you're done. It's a, it's often just some of the, the pieces get chipped off as, as functions where it's most obvious. And at some point you realize that the rest you can leave as it is, but the, the, some of the drivers for that are not only latency requirements or things that run offline or things that are called in frequently, but also once you do have these very fine grained kind of single responsibility endpoints that can be exposed independently as functions, then you know, that the scaling characteristics can be determined based on the traffic to that thing, because it's only called to do that one thing, as opposed to some giant web app that is called for a thousand different reasons. And it's not easy to, to determine, um, how to scale that. So once you get to that really fine grained function, then things like auto scaling become,

uh, possible where with large web apps with larger surface areas, it's, um, it's not always a, something you can actually drive to reality. Auto scaling, right. Yeah. I mean, do you, uh, from, from talking to you and, and even your answers here, it sounds like you think that you can be quote unquote serverless anywhere, right? I mean, even the K native, I guess, lends itself to saying it's not just a public cloud only thing. On one hand, I see plenty of debate that, Hey, serverless is really something that can only happen in public cloud. Cause it's the only place you can literally hide the infrastructure and just up an API or an endpoint versus on-prem. You're going to have Kubernetes pods to deal with virtual physical infrastructure. So stop trying to bring that paradigm on-prem. We should be steering everybody, the public kind of fall on that discussion of, should we be investing in quote unquote serverless like tech that would run in a, in your own data center? Yeah. So, I mean, I think obviously there's, um, probably the only thing that, that, that people agree about serverless is that it's a very confusing term that nobody agrees on. Um, and I think part of that is how literally do you take it? Um, and another part of that is because there, there's definitely one viewpoint that you, you can't talk about serverless unless it's public cloud, because otherwise you have servers and, um, but then you can take that to the extreme and say, well, you know, Amazon also has servers. Uh, eventually there are servers and, um, you know, if someone at Amazon is using Lambda, does that mean it's not serverless? I don't know. Um, so I think that one, one way to look at it is that if, and this is especially relevant for, for us, because it's our primary focal point is that there's the developer experience that it's somewhat separate from the operator's experience. And so I think if you're running serverless on a public cloud, then it ends up, um, removing

responsibility, uh, not all of it. I don't think there's any such thing as no ops, but it does remove, or at least shift the responsibilities for operators as well as developers. But you can still have something that's called serverless, um, whether you like the term or not, that runs, uh, that provides a simplified experience for developers. And that's just meaning that they, something that they can focus on their code and focus on the smallest scope of the code that's, that's solving a business problem and be able to upload that in some way into the cloud without thinking about actual server processes that they need to manage. So it's very fuzzy, but, um, I think putting it between the developer and operation, uh, responsibilities is, is one way to help with that. Yeah. It's, it's, it's hard to nail a term like that because, uh, uh, I mean, I mean, it's because basically it's just like, there's less stuff developers need to worry about, but then, but then on the other hand, you don't want to make them all goofy and be like, you don't need to worry about anything. There's still lots of considerations that need to come into play, but I don't know. I think, I think it's like, like most terms is just like, it's, it's a little too late to come up with something, something new. And then, and then we would just debate that. Right. And, and I think, I mean, what's interesting about the points you make about, uh, overdoing it to where you don't have to worry about anything is that on the flip side, there are actually some things that become, uh, more of a concern or at least more of a challenge to, to worry about when you're running in this kind of a model, because, uh, for instance, if you're if your containers are going away, scaling to zero, then you need to be able to have access to logs for things that may be failed, but are now gone. Um, you need to be able to, once you've broken things up into such fine grained functions that all interact with each other in a number of different ways, you need to be able to see the trace of a, of a, uh, user transaction that spanned a dozen different functions.

Right. So things like logging and all the observability and, and, um, and metrics become a bigger challenge, um, at least for the developers of platforms that the developers are using. And one of the things I noticed when, uh, I kind of got into this a little more and followed your work on Knative is yes, there's those things you call out, which, Hey, now you have to think of new things and think of instrumentation differently and monitoring and all that. But there's things that I liked that we added to Knative for all of us to make it also easier for devs to do in general, two things you, you quick touched on earlier, but could you explain a little more about the build system, which I think is interesting and obviously the venting subsystem, which has a lot of, I guess, riffs heritage in. So to me, those are beyond just the serving component of just run apps, scale them to zero, have revisions, all really good stuff, but the build and event actually pretty neat things that are arguably trying to make the developer experience more powerful and more interesting. Could you, could you explain those a bit? Sure. Yeah. So with the build, um, the basic idea in Knative is that you, you enter the system, with a, uh, component that it's a custom resource in Kubernetes called configuration. And that's the thing that points to the source code or a source image. And so that's basically, those are the two options that you have. You can, you could have already built an image, whether you did it manually on your laptop and pushed it somewhere, or as part of, uh, some CI pipeline, right? There's already an image. Then you just point to the image and the configuration, uh, that you either create or update points to that image. And that triggers a deployment. And every time you make a change to a configuration, whether you've changed the image tag or something, then that will trigger a new revision to be deployed. And so that part is the serving core. Now, what's interesting is that if you choose to, then instead of pointing directly to an image in the configuration, you can point to a build, uh, process.

You basically, um, choose a build template and then provide the parameters for that template. And so that could be anything ranging from, um, something that we've been working on. That's obviously, uh, in the, in the DNA at pivotal is build pack support, right? So we're working now on, uh, riff building on top of K native, being able to use build packs to create the, to ultimately create the image from just a developer's function code and the parameters that point to what base that needs to be added on top of and, and what other things you need to configure. And so that drives a build pack. You can also have something that delegates to say the Google cloud builder or something that runs, um, kind of in between approach, which is, uh, something like Kaneko, which can take, um, a Docker file and build an image in a container and then, and then push that. So there are a number of different options. And the whole idea behind the build template is that it's, it's, uh, configurable and extensible and can support this whole range of, of options, but you always have the ability to just come with an image as well, um, on the eventing side. So that's more about how request traffic, uh, makes its way to a route that is sitting in front of those revisions. And, um, um, the idea there is that, um, you can plug into event sources and those could be things like databases or cloud services or file systems, and those will be adapted so that the events that come off of those end up, um, passing through the, uh, route for, for different revisions that they target. And what we, uh, were most involved in on the riff team was, was helping to define a model around a pub sub system, basically. So there's a, there's a custom resource called channel, and then there's a custom resource called bus, which is an implementation that can back those channels.

And that's where we brought the Kafka implementation from riff as one example. But now there's also a Google cloud pub sub implementation of that. And, um, there will be others, uh, for that bus implementation to back a channel. And the other resource then is the subscription, which allows you to point to a given channel and then, uh, have, um, you can have a one to many relationship from a channel to various, uh, services. And those services are, are basically the end points, uh, typically for your revisions that were triggered by the creation of a, of a K native configuration. So you can create a model where you maybe are listening to say a GitHub web hook as an input source or a Google cloud storage bucket as an input source, or any of the number of adapters that we think will start to grow in a, in an ecosystem that's driven by the community. And then you, you point those to a channel and then downstream from that channel, you can add different subscribers. And that's the part that we needed to have at a level that we could replatform riff. And, um, and so we were able to do that. And now we're continuing to make those contributions there. Well, well, so, uh, you know, I think, I think as you're describing to use one of my favorite templates for things like, like any good technology, it can be as complicated as you don't want it to be. And, and, and to that end, like, like putting aside the legacy stuff, uh, cause I mean, you've kind of covered that in regards to the following questions or as much as is necessary. Like if, if you were sitting down to like, let's say you can pick something else, but make a reservation system, like what kind of planning do you start doing? Uh, you know, if you're going to do things in a serverless way and, and, and let's assume the old thing, you know, of like, you validate that this is the right technology to pick and, and, and all that kind of stuff. But like, what kind of pre planning architecture stuff do you do?

What, what, what do you think through of, we need these components and what's the big wall look like that you got a bunch of boxes and lines on? Well, I mean, I think to a large extent, it's, it's similar to any kind of greenfield microservices type approach where, um, most of the ideas from, uh, domain driven design apply. So you think about where are your bounded contexts, where does your state for each of those need to be stored and which things interact with each other and what makes up the aggregates that are being shared, uh, between those boundaries. And then you map those things themselves into functions and the, what, the state that they need would be mapped into services that, that those functions need to connect to. Well, that makes sense. I mean, it's a good question. I, I, it's, it seems like the key thing is always, uh, you know, where, where's your state? Right. I shouldn't say it's not the key thing, uh, but it's a, uh, it's a, what would you say? A necessary thing. You always have to have that involved somewhere. Right. Yeah. So one of those technologies that you may have chosen ahead of time that Coté just mentioned, but one that we didn't talk about here, but I've seen kind of get mixed up as we talk about Knative and Riff and things like that is Spring Cloud Function. I know you had some involvement in that. So that's not the same as Riff. It's not the same as Knative. Could you kind of talk about this other piece of the pivotal serverless universe and Spring Cloud Function and kind of summarize what that is? Sure. Um, yeah, I mean, I think from my, from my perspective, there's, there's a, um, an evolutionary aspect to this as well, because I started working on Spring Cloud Function when I was first looking at, um, what serverless could mean for Spring developers and taking the typical Spring

philosophy of things, which is basically all about inversion of control and letting developers focus on business logic and, uh, we usually refer to the Hollywood principle, right? Like don't call us, we'll call you. And so extending that framework up to the level where we'll call you with the smallest amount of code that you could possibly need to worry about. Um, so that was, um, so that was, that was the original idea behind Spring Cloud Function. And, and in some sense, it was just an evolution itself of Spring Cloud Stream where with Spring Cloud Stream, you would configure the binder through properties. Like I want to connect to Kafka or I want to connect to Rabbit. And then my code is in this one class annotated with Stream Listener. And so Spring Cloud Function basically just said, you don't need to annotate anything. You can just provide a function. And if you're building an app that exposes a single function, it was very easy to, to just provide the function and then let us provide the dependencies that wrapped that up into something runnable. And what that meant is then, uh, because in addition to inversion and control, we also want to have portability so that you can write the same code locally that you're running on some platform. And what I was noticing at the time is that even though fast platforms like Lambda are focused on the developer writing smaller amount of code, there was still something about the platform in the contract that you had to implement, especially for Java, I would say it's maybe not as much the case for, for JavaScript, but you would need to extend the framework classes or implement the frameworks interfaces. And so what we did with Spring Cloud Function is we provided just the thinnest possible layer that implemented or extended the target platform. And then that layer calls your code. And so you can swap out different dependencies for different of those adapter layers to run on different FaaS runtimes like Lambda and Azure and, um, and OpenWisk as well.

So we have adapters for all of those. And then since Spring Cloud Function could also be used as just a Spring boot app, which means it can be an executable jar. That's where things maybe start to seem blurry because I can take a Spring Cloud Function app and just run it, um, on its own. And so that's where it feels like it's not just a framework. It's also a runtime. Um, but we, we build on top of that actually for Rift. If you're building a Java application in Rift and you just provide the function, like the literal Java util function function implementation. And, um, and that gets laid on top of a base image that has the Java function invoker, which is actually a Spring Cloud Function, um, foundation. And it's a boot app that then spins up in the container in Rift on Knative. Lots of layers there, but. But I mean, well, well, well, as always, if you don't want like a, uh, we were talking about earlier, if you don't want a tremendous amount of dependency and lock-in, then you need layers. Like layers are the answer to that. I mean, you're, I mean, Spring Cloud Function, kind of you bring the FAS versus Rift as you bring the function. Is that at least coarsely fair? Yeah, I think that's, that's a good way to look at it. Yeah. And I mean, even taking your, the idea of inversion of control always, uh, with Spring, um, has always been that you, you build a jar from the dependencies, the framework dependencies. And then also your code, right? And with the difference really with Rift is that we cross over this line where you don't bring the, the framework dependencies in your jar. You just give us the jar that's the function. And so instead of, it's not only don't call us, we'll call you, but it's even don't depend on us, we'll depend on you. And so you just, the, the container that spins up has the user provided code as a dependency

that it then loads and invokes, um, and you, as a developer, you can write unit tests for that function, but you don't even, unless you choose to use a Spring library for something within the scope of your code, you don't even have the dependencies on the framework, um, in your artifact. Hmm. That makes sense. Well, uh, thanks for being on to go over this stuff. It was nice. We get to talk about fish and then, uh, you know, don't depend on us. We'll depend on you. It's, that was good. So, uh, I mean, I mean, finally, um, what, what do you think, like, like, what are, what are y'all planning on doing over the next year or so? Like, what's, what's the sense for the roadmap that you'll have? Well, I mean, there's quite a bit, it's still an early project. Um, and there's, uh, I, I think the Knative, uh, release right now is 0.11 and, um, same for project riff. So we, we, uh, when we sort of went into a quiet period where we were working on Knative, but before it was public, we stopped, um, somewhat intentionally on version 007. And, uh, we recently, after replatforming on Knative, released version 0.1. So, um, in both cases, there's a zero in the first digit. So that shows that we have, um, we still have some work to do. Um, we're also focused on the, on the pivotal side. On the, um, building the pivotal function service on top of riff as well. So that will be our commercial offering. And that's part of the pivotal cloud foundry umbrella. Um, so there's, there's quite a bit going on there as well, running riff as a replatformed on Knative component on top of Pivotal's container service and, um, and thinking more about what those commercial features are, uh, for that. And, um, and, and definitely all of those challenges that I mentioned earlier around

observability and tracing and metrics and things that really turn it into a full platform. As you say, there's 0.3 more percent work to do or not percent 0.3 more work to do. So, no, no, that makes sense. And then, and then, uh, I mean, if people want to find more, I'm sure they can, uh, you know, if they wanted to get ahold of it or like read through the docs or whatever, what would you point them to? So there's project riff.io for riff itself. Um, there's the, uh, PFS site on pivotal.io and for Knative, there's the, uh, GitHub org, which is Knative, um, and there is a, um, I guess that pretty much covers, uh, the entry points. Everything else is accessible from there. Well, good. Well, thanks again for being on and, uh, for the listeners as always. Thanks for listening. This has been Pivotal Conversations and you can find, uh, this episode and all the other ones listed at soundcloud.com slash Pivotal Conversations. And every Thursday or so, uh, we post the full show notes where you can see those things that we skipped over and, uh, maybe I'll put a picture of me eating a herring. That'll be fun, uh, over on pivotal.io slash podcast. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.