Knative 101: Kubernetes and Serverless Explained with Jacques Chester

What is Knative and how does it simplify Kubernetes-related processes through seamless extension? Jacques Chester (Software Engineer, VMware) is publishing a book called “Knative in Action” that walks through the problems Knative is trying to solve. You don’t need to be an expert to fully understand Knative, so start getting hands on and see what you can do with it! You also don't need to be an expert on Kubernetes to read the book, but some experience with the tool can help you get it working with your software more quickly. This episode will help you understand the relationship between Knative and serverless and simplify your Kubernetes cluster.

EPISODE LINKS

• Learn more about Knative
• Factory Physics by Hopp and Spearman
• Business Dynamics: Systems Thinking and Modeling for a Complex World  by John D. Sterman
• Matt Stine's tweet
• Join the Confluent Community Slack
• Get 30% off Kafka Summit London registration with the code KSL20Audio
• Get 40% off Knative in Action with the code podcon19

SEASON 2
Hosted by Tim Berglund, Adi Polak and Viktor Gamov
Produced and Edited by Noelle Gallagher, Peter Furia and Nurie Mohamed
Music by Coastal Kites 
Artwork by Phil Vo 

•  🎧 Subscribe to Confluent Developer wherever you listen to podcasts. 
• ▶️ Subscribe on YouTube, and hit the 🔔 to catch new episodes.
• 👍 If you enjoyed this, please leave us a rating. 
• 🎧 Confluent also has a podcast for tech leaders: "Life Is But A Stream" hosted by our friend, Joseph Morais.

Transcript

SPEAKER_01 0:00

Now, what is Knative? If you played Family Feud with this one right now, you'd probably get answers ranging from a service mesh to that Google Pivotal thing to the one you use with Kubernetes when you're doing microservices. Well, Jacques Chester, author of the upcoming K-native in action, is going to tell us what it is and what it has to do with Apache Kafka on today's episode of Streaming Audio, a podcast about Kafka, Confluent, and the cloud. Hello and welcome back to another episode of Streaming Audio. I am, as ever, your host, Tim Berglund, joined in the virtual studio today by Jacques Chester. Jacques is a software engineer with uh VMware via the Pivotal acquisition, and he is the author of Manning's upcoming Knative in Action. Jacques, welcome to Streaming Audio.

SPEAKER_00 0:54

Thank you. This is a very lovely virtual studio. I particularly like the Neon uh lights in the grid.

SPEAKER_01 1:00

Yes. It's uh we uh only only the finest for our guests here at Streaming Audio. That cyberpunk chic, I like it. Exactly, exactly. Um Hey, tell us a little bit about yourself. How did you um like what's what's your background as an engineer and uh what caused you to make the decision to write a technical book and a book on Knative?

SPEAKER_00 1:23

Sure. Um you know, I I've been sort of engineering in various capacities for a while now. Uh Pivotal's been where I really, I think, found my feet as an engineer uh over the last six years or so. Um the the thing that sort of brought me to K-native was I was at the time that Google approached us about it working for the Pivotal Function Service team, and we were asked to take a look at it and work out how it might fit into our strategy. And our advice was sort of like, let's go into it hard, let's let's get involved. Um later on, uh I was approached by Manning to write the book. Um and uh here I am.

SPEAKER_01 2:03

I love it. Um We're gonna really talk about Knative today. So get us started. Um, what is K-native? Uh maybe give us its superhero origin story, some idea of problems it solves. Uh walk us through that.

SPEAKER_00 2:20

Yeah, I always like superhero origin stories. I use that analogy in the book at least once. Um in in the sense that usually there's something horrible going on or something something toxic or radioactive or something bites you. Right, right. And and in this case, if we're going for the superhero origin story, then then we'd be talking about you know, Kubernetes being amazing, right? It's an incredible sort of like uh I guess like uh a symbiote to to go with the Spider-Man not Spider-Man, the other black analogy. Yes. I can already hear the people the lynch mob forming outside my call.

SPEAKER_01 2:51

Symbiote would be Venom. Thank you. Or the in the eighties there was the the black costume that he got from during the Secret Wars of the Beyond's Planet. And that's right.

SPEAKER_00 3:01

There was also Carnage, who was like the Venom of Venom.

SPEAKER_01 3:04

Yeah.

SPEAKER_00 3:05

Um Yeah.

SPEAKER_01 3:05

So there are definitely several Spider-Man symbiotes are possible here, right?

SPEAKER_00 3:08

We could we could use any of them. So I'm redeemed. Thank goodness. So anyway, you you've got you've got Kubernetes. It has incredible powers that it grants you. But one of the difficulties with Kubernetes historically, and it's funny to say historically for a five-year-old system, that it it never really distinguished between what do developers do and what do operators do. Uh it sort of mixes those concerns all together. Uh and that can be a hassle some of the time. Kinative basically sort of says, you know, let's let's create a firm contract between those two different roles. Let's make it so that it's easy for developers to get on and just run some software in a sensible way, sensible defaults that fit together easily, um, without necessarily sort of having to learn all the different nooks and crannies uh of Kubernetes. Got it.

SPEAKER_01 3:54

So give me give me an idea what some of those are. It's it's true. That's a good insight. It's funny. I've never thought those words, but uh you say Kubernetes doesn't really distinguish between what developers and operators do. That's very true. That's probably regarded as a feature, right? If you're supposed to DevOps, you're not supposed to have these totally distinct roles, but it doesn't always work out that way. Um give us an idea of what some of those problems are.

SPEAKER_00 4:19

Sure. It's interesting you should sort of say that. I'll I'll I'll poke on that a second. I think a good example is uh routing. For example, I deploy a piece of software, it needs traffic to come to it. Now, if I am in Kubernetes land, there's a whole there are actually multiple ways to achieve that. Um and they've all got pros and cons. And I have to learn all of them to understand what I'm doing. You know, not long ago I was working on a product where you know the next story that came up was add HTTPS support. I thought this will be this will be easy. And then a week and a half later I sort of you know crawled out of the pit of misery covered in covered in scars, you know, and I'd learnt all sorts of amazing stuff. And I was like, and why did I have to learn any of this stuff? And the the thing that for me eliminates that division of roles is that Pivotal for a very long time has been the driving force behind Cloud Foundry, which uh is a platform as a service uh that does draw that that distinction quite sharply between what is there to make life easier for developers, what is there to make life easier for operators. And my radio has just now decided to make a lot of noise. Um just imagine that it's angry operators banging.

SPEAKER_01 5:31

Exactly. No, that's angry operators banging because they have been asked to do things that developers should have done. No, they wouldn't be angry about that.

SPEAKER_00 5:37

They're used to it. Right, and vice versa. So that's the thing. So that this goes back to the DevOps question. I feel that DevOps was right in the sense that it was like, let's break down the barriers and and recognize each other as humans, and that the ancient models are not quite as exact as they seem. But there's always a but.

SPEAKER_02 6:00

Yes.

SPEAKER_00 6:00

I think the thing that DevOps addressed itself really to was that the costs of uh how we did things fell uh unfairly. So what do I mean by that? So for example, in a classical, you know, dev and ops world, never the twain shall meet. If I'm a developer and I make something buggy and I throw it over the wall and it crashes, it's the operator who carries the cost, right? They're the ones who feel the pain. Yeah. They get paged. Exactly, they get paged. And then uh vice versa. If I'm a developer and I need something provisioned and the operator takes their time, then I'm the one who feels the pain. I'm being held up, my work is being held up, and DevOps was supposed to sort of help us with that, and in a lot of places it was very successful. But what I would submit is that the difficulty there was not so much just the personal relationships, it was that we were missing the understanding that it was it was a problem of making sure that the costs fell fairly. Um, so for example, in something like Cloud Foundry or Knative, uh, and to a lesser degree in Kubernetes, like vanilla Kubernetes, the way it's architected means that when a developer does something that causes a heroic breakage, the system can constrain that or contain it to them. And so the cost of it, the the pain of it falls back onto the developer who rightfully should should carry it. And similarly, if the platform makes it very easy to obtain services and resources and have them injected and provides logging and routing and ingress and all these other facilities automatically, uh, then that cost of getting those things set up doesn't fall onto the developer. Uh it falls onto the operator, but it's it's industrialized and automated. And so in that sense, it's not a bad thing to have those distinctions between the roles. It's not a bad thing to have a firm but fair contract between the roles. And most of the pain that comes about is that there is an inevitable tension between the costs that arise because of complexity, like the the many people having to coordinate their actions versus the costs that arise from a lack of specialization. You know, uh DevOps, you know, moved away from specialization, but you lose something when you do that. Um and I come from you know one of the high priesthoods of generalists at Pivotal Labs, and and I still see the value of specialization. Um, it's all about working out how to work together effectively.

SPEAKER_01 8:32

In your book, which is at the time of this recording and publication in a few weeks, uh publication of this podcast, you this book is still upcoming. I was gonna say, geez, in the current weeks. Yeah, I'm sorry, you have to finish it now. Who who finished it? You're thinking it was for darn sure not me. Um and and you know, as as an aside, of course, I I know the enormous undertaking that writing a technical book is, and uh it's I I appreciate that you are undertaking that effort for the benefit of the Knative community. It's it's gonna be a very helpful thing. Um and I actually don't know uh how far along you are uh when it's due, and you don't need to commit to any of those things on air. But my question is uh when you get started explaining Knative, now in the typical Manning in action book, um in action is uh I said that quickly, I should clarify. You know, technology name in action is a Manning brand. That's not in action like passivity. Yeah. Right. It's it's yeah, it's not just turn. K-native in action, uh, how do you begin explaining it? Um what what what's the what's your path there for the newcomer? Because uh the in-action series assumes that you may in fact be a newcomer.

SPEAKER_00 9:49

Yeah, and and so I sort of break that down into a couple of different ways uh of addressing it. One of them is that that role separation or that addressing itself to developers thing I just talked about. Another way to talk about it is that it is a collection of components that extend Kubernetes seamlessly using sort of Kubernetes uh facilities to create a you know a seamless extension process. Uh another way of looking at it is that it is two major components serving and eventing that address themselves to different parts of the problem of building cloud native applications and functions and systems. Um It's difficult, like many such things. You you know, I in the book I I have exactly this uh discussion where I try to sort of introduce it in multiple different ways because it's such a tough question. Um but like a lot of things, it becomes clearer when you start chewing it what it tastes like. Um I had that experience with Kubernetes. I was like, what is Kubernetes really? No, really, what is it? You know, and you you could read the blog articles and you know there were there were tweets at 20 paces going on and all that sort of stuff. But you know, it wasn't until I sort of sat down with a book and and went through it and did some exercises that I started to go, okay, okay. There's there's no deep mystery here, he says right after you know making fun of Kubernetes 10 minutes ago. But which was true at that point. Uh well to to excuse myself. Um Yeah, the the very basic primitives were pretty pretty straightforward. It's just that there are many, many knobs and dials.

unknown 11:22

Right.

SPEAKER_01 11:24

And so uh you're saying, in a sense, it's like the matrix, no one can tell you what Knative is. You have to see it for yourself. It sounds like a cop-out. I know. It is a little um it is and it's you're writing the book on this, so you have to tell me. Yes. Um, yes. Well, I mean I don't have to. I mean my advice is like, well, you should read the reason. That's true. That's true. You so you should give me a tantalizing but still incomplete uh you know paragraph summary of the I'll I'll say this.

SPEAKER_00 11:50

My focus in the book is on a reader who doesn't know K-native, obviously, but also doesn't have to know Kubernetes. I don't want you to have to be a Kubernetes expert before you read the book. What I want you to be, as you come into this book, is a developer with some experience. You know, you you've you've seen some stuff. Um you don't have necessarily Kubernetes experience or functions as a service experience. You you might have heard of them. You you might not have read very deeply into them. And I want you to be able to like hit the ground running and start to be able to do things with your software. I want you as a developer to be able to say, okay, Knative solves these kinds of key problems for me. How does the traffic actually get to and from my software? How do I uh update the software reliably? Um, these sorts of questions are are the ones that Knative sets out to solve for developers, and that's the audience I'm addressing myself to. Awesome.

SPEAKER_01 12:46

What's the relationship between K-native and serverless? Oh, serverless, good old serverless. Um, you're welcome to provide your account of what serverless means in the answer.

SPEAKER_00 12:58

I've d I've discovered that there are two definitions of serverless in circulation. Uh the one I like is that you don't care about the existence or non-existence of servers. Um that's familiar to me. I knew that for a long time as platform as a service. Um it it's been around forever. Like when I do a uh if I'm using Cloud Foundry as an example, when I do a CF push, you know, it ships off source code. I I don't care that there are servers, I don't care where it runs. It was the same with Heroku, Heroku Pine, this, and an app engine as well. You know, you you don't think about servers when you send something to Heroku until the bill shows up, anyway. Um generally speaking, that was that was the sort of the thing. Um so that's one definition of serverless. The other definition of serverless is uh by pure coincidence, this suits Amazon. Amazon's definition of serverless, which happens to me, all of those things, comma, but uh the servers belong to Amazon. Um call me a cynic if you like. Well, Amazon Amazon's to be fairer to them, the the argument that they're making is more subtle, is that they believe serverless extends to not only that the developer does not care about the servers, but also that at some level the operators don't care about the servers. And for them, that means that there needs to be an economic boundary between the entity which owns and operates the servers and the developers and operators who you know consume that serverless capability. But it just so happens that definition means Lambda to them. What a coincidence. Right. Right.

SPEAKER_01 14:32

Which um as the term evolves, um, I'm I'm trying to bring that up as often as possible. Uh serverless entered our collective consciousness as a development community through AWS Lambda. Um that's that's when they started using that word, and everybody made jokes, and uh, you know, it's been a few years, but uh it functions as a service, I think, is let's just let's just say there's one account of serverless that means functions as a service, which means uh there's you know the way you normally tell that story is there's this um continuum of deployment artifacts where on one end there is this bespoke carefully crafted server where you've got root access and you do all these things to it, uh, and then there's a VM and then there's a container, and now we're just gonna have a function, you know, and that's our unit of deployment. Um so that's serverless, that's the one kind of serverless. But the other one, um, I don't I don't think this is the other definition you gave. So let me propose a third. That is the good old scales to zero uh definition, where regardless, you know, this lets us talk about serverless Kafka. I've occasionally described Confluent Cloud that way, and I I don't think that's any part of Confluence official go-to-market or or approved phrasing or everything. But here I am on the podcast saying it anyway. Um, just happening it'll be our secret. That's right. No one else, only a few thousand other people will know. Um just just you and me and a few thousand of our places to find. No, but it's it's uh just by way of analogy and illustration. Um, you know, you've got this fully managed Kafka service where if you don't if you're not storing anything in a topic and you're not doing any pub sub on a topic you're not producing or consuming from it, it doesn't cost you anything. And what you pay for is writing and reading and storing. Um and if you don't do any of those things, there's no residual cost. So that scale to zero or no residual cost is what serverless that's that's my favorite definition of serverless.

SPEAKER_00 16:30

I think I think that's a better definition. And and I'll I'll I'll sort of like expand on it, if I may. Um the definition I gave was mostly around mostly around engineering sort of centric things and the experience of a developer. And I sort of touched on the economic side of it with you know making fun of Amazon. And I think you did a better job. You know, and now that I'm thinking about it, it's like when I when I buy electricity, I'm not calling it generatorless. No, you're not. No. And and what I'm seeing now is that there's sort of two different kinds of ways that you buy stuff from a vendor, and and one of them is you buy capacity. So you buy your virtual machine, you buy your container, you're running instances of whatever, you know, your your Kafka partitions. The other one is you buy consumption. Uh and that's where, for example, generator list technology becomes a thing. You know, I don't buy you know 600 megawatts of capacity. Well, I don't want to do 600 megawatts. I don't I don't buy like a megawatt or two of capacity to run my house. I just take watts off the wire and use them. Uh and then I pay for the consumption. And it's up to uh the electricity company to work out how they're gonna do that.

SPEAKER_01 17:38

Aaron Powell Good analogy. Yeah, thanks. So uh does Knative have anything to do with serverless? It does in the the sort of difficult speak of it as marketing, but you know, the um the the site uh when you know knative telling it's telling the world about itself uses the S-word. So why is that?

SPEAKER_00 17:54

Aaron Ross Powell, Jr. It does. That's right. Um yes, it does put on the cape with an S in it, and no nobody shows up with uh an affidavit. Um the thing this this is where that economic boundary thing comes in. This is why I think Amazon is so keen to define it the way they define it as essentially like different economic owners of of the infrastructure is what makes it serverless. Um because they argue that installable functions as a service or what have you are not quote unquote truly serverless because you still own and operate something inside your economic boundary. And so by their definition, Knative, for example, wouldn't count. But the thing is that uh all of these things are in some respects relative, and you are drawing a boundary, which happens in this case to be the boundary of uh legal ownership, right? Amazon LLC versus uh your company LLC. But within a large company, those organizations have independent identity from each other. And so the developer who works in the such and such line of business might as well be buying that service from Amazon as much as from their central IT service. It's still serverless to them. You would have no doubt work with some of the same customers as Pivotal and VMware work with, where the organization is so large that independent units of it are Fortune 500 companies in their own right. And you can feel like a flea clambering over an elephant, or actually, more fairly, like a small bird, you know, picking the knits off an elephant. Uh, but every time you land in a different spot, it it's all new. Uh, it's like a different company. So, in that respect, yes, it is serverless. I I disagree with the Amazon characterization. I I see Kenative as serverless. Somebody somewhere is is gonna stop caring about servers, it's serverless.

SPEAKER_01 19:35

And this may be um this may be a uh a little bit too deep of a drill down, but I I like that big company picture you just painted there and the things that happen coordinating different parts of a big company. Uh it I think matters a little bit less whether the Securities Exchange Commission wants to see an integrated, you know, comprehensive financial statement from all parts of an organization, and whether there's a legal entity that they all roll up to or they're separate legal entities, you know, who cares? That's not really the point. The point is, and this gets into well, a concept in economics. There was a uh 20th century economics or economist, British guy named Kose, who uh is famous for a number of things, but one was his theory of the firm, like why are there companies so and the Kosian theory of the firm is that there are companies because uh accessing the market, like we normally coordinate access to goods and services through the market, but accessing the market costs something. There's a transaction cost. Like um, if I have to go buy a light bulb, I have to go to the store and pick one out, and that's actually really hard now because there's all these cool LED bulbs. Um, so it costs me something to go to go access the market. Firms exist because they're these little communities of like-minded people with a common purpose who don't use market mechanisms, who use something more like command and control, central planning, uh, inside the firm. Like I have a team, they have to do what I say, and and you know, another team will agree to serve me and they don't charge me back for it. They just do it because we're all you know, so that's this this co-sing idea. Is yeah, at some point there's this transaction cost boundary where it's just a pain in the butt to use market mechanisms to coordinate, and so you just get together and use central planning and it works better. Uh well, in a gigantic company, guess what? Um it yeah, those it is actually better to treat it like a marketplace. And uh Yeah.

SPEAKER_00 21:29

You you wind up with a kind of a fractal problem and and the size of firms has uh a strong relationship between the ever-shifting balance of of like market coordination and and command coordination.

SPEAKER_01 21:40

Aaron Powell Which is why private cloud is a thing. Um that's why private private cloud is a meaningful phrase.

SPEAKER_00 21:46

Aaron Powell Yeah, absolutely. Yeah. And and you know, it I'm so glad you brought up coes because if I have amongst my thousands of rants about my profession, one of them is god damn it, we need to read more economics. Of sort of interminable debates that turn out to have been taught in, you know, Economics 102 or 201 is very frustrating. So, for example, Cosian theory, you know, one of the classic debates is, oh, should I pull in a dependency or should I write my own? And there'll be a great deal of beard stroking on Hacker News about, you know, you must always pull it in, or no, pulling in is wasteful, and I'm smart enough to write the simple one that I need right now and all this kind of stuff and say, no, this is this is literally the Cosian problem. It is literally the Cousin problem. There's a transaction cost for pulling in dependency. There's a different cost for taking direct action. Uh, and and there's going to be a balance between those two. There isn't a hard and fast universal principle. It's it's an economic decision. They all are in disguise.

SPEAKER_01 22:49

Aaron Powell And when we see something like, say, Kafka streams, that kind of complexity, um, it's very much worth paying the transaction cost of taking pulling in the dependency. If, for example, maybe you're left aligning strings, as we found out a few years ago, maybe that's not the time for that. And that could be a bad thing. So Yes.

SPEAKER_00 23:08

Well, I don't think I don't think all of us sort of had to start doing value-at-risk uh estimates. Uh if you'll excuse me, that's a great idea. I'm gonna be right back. We're gonna go see a VC.

SPEAKER_01 23:21

That's a friend of mine said back then. Uh it was Matt Stein. I'll just I'll just name him. He uh he tweeted like Uber, but for left-aligned strings. So um and I should put a link in the show notes uh to that whole episode in case there's anybody who doesn't remember that from a few years ago. But let's get back to uh let's get back to Knative. Uh so there's this there's this relationship to serverless, kind of. I mean it it certainly makes uh proposes that that relationship. Um also Istio and just the general notion of service meshes. Now, knative does not uh does not exist in that category, correct? You'd never you'd never call it a service mesh.

SPEAKER_00 24:00

No. And and uh interestingly, that there's been an evolution with the relationship to service meshes. Early on, Istio is a hard dependency for K-native. You go back to the early slides, and it's like we're taking the best of Kubernetes and Istio and you know making making a delicious pie. It turns out a lot of the things Stio provides were not strictly necessary for the mission uh that Knative sets out to solve. And there are alternatives for the parts that it does try to solve, primarily around the business of having a piece of traffic come off the wire and who gets to do something with it, you know, your ingress and your routing and so on and so forth. So there are a lot of alternatives there. You can use the Istio gateway, uh, you can use ambassador, glue, contour. Almost all of these are basically uh using Envoy in some form or fashion as they run time. Whereas the second big thing that Istio does for you in terms of container-to-container traffic management turns out to be less of a thing in Knative. And some might argue uh that it's become less of a thing in the general Kubernetes world. Bear with me again, uh mob outside the door with with pitchforks, because that'll be.

SPEAKER_01 25:12

You have my interest and attention.

SPEAKER_00 25:15

Sure. I I would say basically there are things that that model help a lot with. Termination is a really big one. But a lot of the security, like the what would you call it, the threat model for a service mesh is that you have a very large shared cluster and you want zero trust between the tenants of that cluster. The thing is that Kubernetes itself does not have a strong or hard tenancy model. And so at some level, that security is great. You've got like the padlock on the network door, and then somebody just goes through the drywall on the side for the rest of it, and it doesn't really matter. So, what you see now is everybody is skating very hard towards multi-cluster systems where you have many, many Kubernetes clusters dedicated to many, many purposes. And then the security problem becomes, like the network trust problem becomes a lot easier because you've instead of trying to partition the tenants at the network traffic level, you're more or less partitioning them at the cluster level. It's like the boundaries of each cluster become where that policy has to be applied. And that's much simpler and you don't need quite as much overhead, uh, quite much as much sophistication. I think Sidestio continues to evolve. We're all still, you know, feeling out the the stones, you know, feeling our way across the river with our feet, that sort of thing. Um and that will continue to evolve. I mean, I sound very smart and wise and all-knowing, and uh these are all things that are not obvious until we've done them. Um I'm sure there was somebody somewhere who like wandered in from the desert and told us that you know judgment was upon us and Istio would be bad for something, and congratulations to that person. Um but generally speaking, we we often find that our deep assumptions are wrong only after we've banged on them for a while. And the single cluster thing is is a deep assumption that's turned out to be wrong.

SPEAKER_01 27:10

Okay, okay. Does that imply that containers within the clusters trust each other and it's it's zero trust between clusters? Or what you started with within the Yeah.

SPEAKER_00 27:20

Yeah, yeah. As as it as it's just as it exists now, Knative is um you know fairly all or nothing. It does want to cluster more or less to itself, or or or it's best set up that way. Um so what I mean by that is like if you have you you could run multiple applications on your Knative, but if you have, for example, top-level settings of your Knative that are not suitable for different applications, you're gonna need another cluster uh to do that properly. And while that's being improved, and I'm sure somebody will correct me in the comments, uh hi-Mat, Scott, Vilay, uh whoever else listens to this and goes, what is he doing? Um by by and large, that that's been sort of the starting point. And I think part of that actually came out of the design pressure that came bubbles upwards from Istia. Got it. Uh I I've lost my train of thought.

SPEAKER_01 28:10

No, but that uh we we were talking about uh just the security characteristics of of each individual cluster changes when you go to this multi-cluster. It does.

SPEAKER_00 28:20

And and that's an evolving situation. Um I think it took us a while to get to this point because the speaking of superhero origin stories, the origin story of Kubernetes is uh workload consolidation, you know, finish efficiently packing the compute resources you have with the workloads you have. Um and it and it's just sort of simple mathematics that the more things you have to pack into, and the more things you have to pack, the more efficiently you can pack. Um that that just that just turns out to be uh uh you know pooling variance. Um shows up all over the place. Right. The problem is, of course, that you have that security boundary problem, and the only way currently to solve that, to really solve it in Kubernetes is you have to have a different cluster, and then you lose some of those, those, um, some of those efficiencies. Uh people are working on ways around that, you know, much of this space. But um so that that's where we sort of wound up. So everyone was sort of like, okay, we really need to build a new cluster. And and full credit to Red Hat, they did an enormous amount of work in productionizing and enterprising, as it were, uh, Kubernetes. They they are responsible for RBAC, they're responsible for for a lot of things, and and now a lot of other enterprise companies are involved as well in in making these things better. But there is a certain level at which you absolutely have to have a physical separation between the clusters, or your security model is not suitable for certain things. Or your configurations, you know, stomp on each other uh in a way that's not very not very desirable. Right.

SPEAKER_01 29:56

Now, uh turning the page a little bit. Some of the language you have been using, and it was more the language you were using when you were talking about Istio, um but um uh some of the language you have been using uh sounds to me like the language of uh microservices that uh make uh uh synchronous calls to each other, whether some sort of RESTful or GRPC or you know, whatever, some sort of synchronous API between services. And I I realize that's um really the purpose of of a thing like Istio and the service meshes is to solve the problems that attend that uh uh architectural um opinion, that set of architectural opinions. Uh to what degree is Knative coupled to that same paradigm? This is of course a setup for the Kafka. Everybody, if you're wondering when we're gonna talk about Kafka, we're gonna get to Kafka in a minute.

SPEAKER_00 30:51

I'm getting there. So yeah. We're getting there. It's still in the stream, it's on its way. Uh you know, just a few offsets ago. Exactly. Um yeah, so there there's two answers to that question. Um the first answer is uh that it has a strongly request response centric design as it is now. Um especially the the sort of the two components there's serving and eventing. Um serving is definitely all about HTTP. Um and you know, that that's where Stio service mesh makes a lot of sense and so on and so forth. You know, the the conveniences they give you are suited for HTTP applications. There is a continuously still evolving effort in eventing. Um designs and eventing have at times looked very request-y response-y, if you like, uh, or been very HTTP centric, um, and at times less so. Uh this is one place where uh my colleagues at uh VMware now um have been working hard to uh develop what serverless streaming looks like. Um so the group I was in, the Pivotal Function Service group, uh responsible for a pro a uh open source effort called Project Riff excuse me. Uh Riff R I F F Project Rift. Uh Project Rift Riff. Yeah. Riff as in a small piece of music. And uh the the thing that's been a guiding light for the group working on Riff has been that streaming is different in kind, not just in quantity, from you know, one thing at a time. So if you you you look at them sort of superficially, you know, one request at a time and one message event, you know, whatever at a kind, you're like, oh, these are the same. Um but but you and I, you know, both both know the twist in this story, which is that they're not alike at all. The analogy I sometimes use is like, okay, if I want, you know, boxes delivered to my house, there's one one scenario where, you know, a truck drives up the street with one box in it, and then I go out to the box and I get the box and I come back in the house. And there's another scenario where I get a conveyor belt from the factory into my living room. And sure, both of those bring me what looks like a box at a time, but the dynamics of those two systems are wildly different. And the dynamics matter at scale. You know, when when you're running a uh a business, you know, uh operations management folks will tell you this. Like there's there's a difference between a job shop, and there's a difference between, you know, worker-paced lines and machine-paced lines and continuous process. Uh if you went to a mine site and said, you know, uh we're going to have the people pushing wheelbarrows, but lots and lots of people pushing wheelbarrows to get the iron ore from the pile to the ship, you would be looked at like a lunatic. Right. These things matter, right? So that's that's where the Rift team have been very, very active. And there are aspects of the Knative design that reflect that activity, and some that are still sort of looking at a more single event style, I guess if you could you could put it. Um, sort of high-level discrete event style. Like uh, here is a pull request, you know, here is uh a checkout, here is a hit on the web page. And these are still valuable, but those are different from example, for example, from here are 600,000 people doing stuff, and we want to come up with an aggregate of their behavior so that we can decide whether we need to change the banner today. Um you can achieve that one message at a time, but it's gonna kind of require a lot of uh state and overhead and a lot of cluster plumbing. You still need that true streaming capability.

SPEAKER_01 34:57

Yes. The confusion between you you gave the illustration of a conveyor belt going into my living room. Um we just had a wedding in the family a couple months ago, and it very much felt like there was an Amazon conveyor belt coming into the living room with all the things arriving. Um and the the the difference you gave that example as you know the streaming thing and then just a truck coming and giving you a box or uh as the synchronous thing. It's easy to see the confusion because like if if the the unit of work you perform on the package is you create an Instagram unboxing video for each one. Um well, you know, you're still making an unboxing video each time. Um but the you said the dynamics are different. The dynamics of the integration between the systems is is what's fundamentally different. You know, once the box once you've got a box, you do that work. And it's the same work. It's you go through your same unboxing flow as you would regardless of how it came to you. But um the the conveyor belt coming to you compared to you know, that conveyor belt is there and boxes get on it and you don't know how, but it's connected to you and they come into you. Uh, you know, you you're not worrying about how to discover, no nobody else is worrying about how to discover where you are. They just put things on that belt. Um versus, well, here's this truck, and it takes things from a distribution center, and it has to figure out a route, and it needs to know your, as it were, your name, your address. Um all of those, all of those kind of integration problems attend the truck delivering the package, uh, where those integration problems don't go to zero, right? Like people still need to know where the belt is, they want to put a box on the belt, um, but they they become more manageable. And so the the value, I guess where this is going is uh the value of a service mesh is less clear when you're doing asynchronous reactive microservices, such as one might do with Kafka.

SPEAKER_00 36:52

Yeah, yeah. So for example, if you're doing um a request response style, then fault injection is wonderful. All right, but of course, there's the business of like the request has traverse the network, it has to get to the Envoy sidecar that sits next to your process, it has to be unboxed and looked at by Envoy, and then it gets passed to your process, which unboxes it and does it all again, um, versus having a you know the pipeline that goes directly into the process and is only demultiplexed at that point. Uh you know, there's there's fewer hops, there are fewer places for things to pile up, waiting for a turn. You know, somebody somewhere is gonna batch it because it's more efficient, and suddenly your variance blows out. Um It's interesting. So I was originally gonna write essentially a very different book with the same title. Uh what the first part was gonna be called mechanics, which is what I'm writing now. Essentially, like, how do you use Knative as a as a practical concern? What are the the pieces you put together? How do you use them? How do I do X, Y, and Z? What are the knobs and dials? And there was gonna be a second half of the book called Dynamics, which was to discuss these issues. Uh and my contention was that as you build these systems, at one level they look the same. You know, I still have methods or functions which receive arguments and then return something or have an error. And that part hasn't changed. But the ratio of stuff that happens inside any given process to the amount of connective tissue, if you like, is very different now. The surface to area ratio is very different. Uh I beg your pardon, the surface to volume ratio is very different now. And what we know from from you know analogy by from from physics in allometric scaling of of of living things is that uh those don't scale at the same rate. You know, uh uh an area scales as a as a a quadratic function, and a volume scales as a cubic function, and that's why elephants can't get any bigger. That's why their bones are so thick. You can't make something king hong-sized, it will snap.

SPEAKER_01 38:50

Aaron Ross Powell And uh that is why it hurts much more to learn to snowboard as an adult than as a child. Well that's good to know because I'm gonna be learning the ski scene. Thank you. Aaron Powell Yeah, no, because your mass just has grown with the cube of your height and the surface area of your knees, which are gonna be involved in the process, only grows with the square. So this is the math is not in your favor.

SPEAKER_00 39:09

So anyway, go on. It it it's not, especially when when uh there are brownies easily available. So that's that's part of it. And a similar sort of thing that like, okay, if if events are spending much of their time traversing a graph, uh then it starts to look more like a a queuing problem. You have have a series of uh like a uh uh a cue graph. Those have dynamics um that are non-obvious. Uh so the habits of thought you may have developed in a world where everything was in a single process or even in a handful of processes, uh, where the queues did exist at like a CPU level or at an operating system level, but were so fast you never saw them except under extreme circumstances. Now those are the common case. You're gonna see those dynamics and problems constantly. And it's gonna be surprising unless you update your mental model. Uh and it's a similar thing with with streaming systems. And that this is this is where, you know, like I get to do your work for you and tell people that reactive systems have you know some pretty critical advantages in this respect. Uh they're much better at at robustly governing their own behavior uh as sort of self, self-driving or systems with emergent behavior. Um and none of this is original. Like, I'm not a genius who saw all of this. I just read books about how factories work, right? And and like again, you know, related to economics, it's sort of you know, like a kissing cousin with economics, is you know, people push stuff through factories, and there's been many attempts of how to do these things, but the same dynamics show up because it's stuff moving through queues or moving through buffers uh that takes time and has mass and location, and these properties are in common with data. A reactive system is very much like a pool-based manufacturing system. So it's something like Kanban, or uh there's another one that's often used called ConWhip Constant Work in Progress, uh, which is similar. And essentially, because of that nature, although you may not pick the configuration exactly, it's still a much more robust system. It's much more capable of dealing uh with misconfigurations or selections of poor configurations. Whereas something like a push-based system, like the classic MRP systems, uh, where you had a computer plan out the precise and perfect plan, that plan may be better on paper, but it's very uh non-robust. It's very sensitive to mistakes. Um, and it's very easy to suddenly discover that you have huge amounts of inventory piling up in funny places. Um and we've discovered this the hard way in computers. So, you know, we're like, oh, we'll connect everything with cues, and the cues will deal with the variation and it'll be awesome and it's really elegant, and it is. And then one day one of the cues blows up, you know, or we find that it's really, really slow and we can't understand why. Or sometimes it's really, really slow, and sometimes it's really, really fast. And there doesn't seem to be an obvious reason why. At least with a reactive system, it's pushing the pressure back up the line. And this is something that definitely the Riff team are very conversant with. Reactive programming is really a strong suit of uh folks working on Spring and around Spring, who constitute sort of the bulk of folks who work on Riff by origins. It's still evolving, I would say, in K-native. I think it is gonna make it in as a concept. And I think also systems built on Knative or around K-native will be able to entail this. Where I think K-native really shines right now is in taking an existing system and evolving it in that direction. Like it might not be great. Well, that's not fair. You can do a greenfield thing, but you're gonna start to run into these some these sort of software physics problems. But taking an existing system and starting to decompose it into parts that don't need to be synchronous, which can survive being asynchronous, you know, spinning off stuff that happens in the background. This is where K-native really shines.

SPEAKER_01 43:02

And I think uh reading between the lines here, you're saying that K-native, yes, was born in this request-response world, but through Riff and other things in progress and you know the overall contributions of from folks from many companies. The reactive culture of you know the of the entity formerly known as Pivotal, uh, really are bringing it more into a more native role in asynchronous systems.

SPEAKER_00 43:29

I think so. And obviously my view is biased because I'm a uh a Vima, a pivot. And uh but you know, in in fairness, you know, there are there are lots of smart people on this. Um there are some very smart people from uh from Google, and you've got to remember that Google implies uh some real luminaries in this space. Um there's there's some really great folks from Red Hat who are involved, and Red Hat has you know reactive religion now uh in a lot of ways. Um so I think I think it's it's evolving in that direction. The the tricky part is squaring the circle of uh you know reactive and what is the antonym of reactive in software design, by the way? Um reactive and pre.

SPEAKER_01 44:11

I'm not sure. I say synchronous, but that's not exactly the antonym, but you you it's you know it's kinda.

SPEAKER_00 44:16

Yeah. It's tricky, isn't it? Hmm. Non-reactive, I guess. Um push systems. That's evolving. I I still think that I'll put it this way. One of the things we were all really excited about with Lambda early on was that it lets you do essentially like shell scripting for AWS. You could just have little dabs of glue that tied things together or a bit like Perl, right? You could just write a bunch of little Perl scripts and they pulled this from here and connected it to that, and everybody was very happy until you know uh CodeGolf came along. But um by itself, that doesn't make it a streaming system. And a similar thing with with Knative. I can use Knative to integrate uh disparate systems that would otherwise struggle to talk to each other and to do it in a sensible way that's declarative and highly visible, uh, versus having a mystery endpoint on a web service somewhere or a shell script in the back of my repository that I run on Tuesdays with a cron job. You know, at least this way I have some YAML, it's checked in, I can see it, I can monitor it, I can manage it. Um but then of course, if you are building a system in which the momentum of data is your core consideration, uh, then you're still going to need specialized streaming systems, I think, at this stage in the evolution industry. Uh I think Knative will and and has a chance to become a general framework or a common language, if you like, for that for that uh use case. That's still evolving, though.

SPEAKER_01 45:46

My guest today has been Jacques Chester. Jacques, thanks for being a part of Streaming Audio. It has been a pleasure, thank you. And there you have it. If you're still listening, you get a special discount code for sticking with us all the way to the end. You can use the code podcon19, that's P-O-D-C-O-N-19, to get 40% off all Manning publications in all formats. Just enter PodCon19 during checkout on Manning.com, and that 40% off is all yours. Enjoy it. And I hope this podcast was helpful to you. If you want to discuss it more or ask a question, you can always reach out to me on Twitter at TLBergland, that's T-L-B-E-R-G-L-U-N-D, or you can leave a comment on a YouTube video or reach out to us in community Slack. There's a Slack signup link in the show notes if you'd like to join that group. And while you're at it, please subscribe to our YouTube channel and to this podcast wherever fine podcasts are sold. If you subscribe through iTunes, be sure to leave us a review there. That helps other people discover the podcast, which we think is a good thing. Thanks for your support, and we'll see you next time.