Knate-ive

Episode 106 · 40:46 · SRT · archive.org · all Tanzu Talk

Well, here we are at the last SpringOne platform tour. SpringOne tour platform. That's right. SpringOne tour. Spring tour. Spring tour. Let's just call it that. That sounds almost French. Up here in Toronto, the last one of the year. I think we're going to be back in Toronto in December. We need to start coming here in, like, June. Nothing against, you know, December in Toronto. I'm a Minnesotan, so this is normal for me. I'm actually north of, I live north of where we are right now. Yeah. Which I always find rather ironic. Thank you, Curve of the Earth. Yeah, it's fun coming here. You realize that the cold could kill you. It can. Yes. If you weren't protecting yourself. If you're not careful. Well, at least, now, as a former Texan, because now, you know, you're not a Texan really anymore. Are you once a Texan, always a Texan? I guess so. I'm not sure. But in Minnesota, and places where we get that kind of snow and cold, you have to, or you're supposed to, when you go on a road trip, you have to put warm stuff in your car. Oh, in case you get a wrecked. Because you might get stranded, you have a wrecked, you might be there. Yeah. For a little while. So you put a couple sleeping bags, you know, some boots, some hats, mittens, you know, maybe even some kind of non-perishable food item. Yeah. And, of course, power bars. A little, you got to have a little something, a little something, something. Some people even put cat litter in their car, and that serves dual purpose. It gives you a little extra weight. And then, if you do get in a slippery situation, you can pour the cat litter down, and then you get traction. Oh, my first thought, which I realized was incorrect, is like, if you have your cats with you, they stay in your car. Right, if you bring your cat, well, the cats will help keep you warm. See, you've heard of three-dog night. Uh-huh. There's like the five-cat road trip. Five-cat road trip. Right. Just in case. Just in case. One for each two, I guess. Exactly. Got to keep warm. And then you have a spare. Got to rotate them in and out. Yeah. Yeah, it's cold here. It's a little chilly. And it was snowing when I came in here. I'm so sorry. And I hadn't seen snow in a long time. I was thinking, I went skiing in New Mexico last year. Wow. But I think that was fake snow. Oh, could be. I mean, not fake snow, but, you know, generated snow. Generated, right. User-generated snow. Snow as a service? That's right. That's right. Well, so you just gave a talk, your talk, going over, like, how you architecturally think

through, like, choosing the various layers of the stack and the popular stuff nowadays of, you know, your Kubernetes and your serverless and your functions and even Knative. Absolutely. Which I'm excited to talk about. We'll see what your scoop on it is. And I was thinking, now we both travel a lot. We do. And I think, at least for me, it's always instructed to have, like, an example application that isn't just like a fortune-telling app, right? A travel app. Because that requires, it requires a little more imagination to figure out how this is related. But I thought of something that I think, was it this past year, probably both of us experienced. And that is, let's just say, theoretically, two giant hotel chains. They merge together. And they have different ways of tracking what your member number is, right? And so, somewhere in this process where you are in what seemed like, eventually became, but in this theoretic world. Hypothetical. That you would basically sign in, and you would sign into both accounts, and it would magically merge them together. All sorts of things were happening. But I was thinking of one little, maybe, serverless function thing. Is at some point in this theoretic architecture, there was this point where you had the old number and the new number, and it called out to something else that said, these are now the same number. Now, there's a footnote that, for whatever reason, in this theoretic example, some month later, they came up with the fix that you would get a brand new number. Of course. Even though, previously, you could choose to keep one of your numbers, which I thought was kind of a quaint thing. Like, are you that attached to a number? Who wouldn't be attached to a random, multi-digit number they were assigned by a large corporation? I guess if you had it memorized, it could be handy. And I know people who did. It's kind of weird. Anyway, so, let's pick this one thing that we've got. We're merging these two hotels together, and in their loyalty program, you, you know, Joe and Jane Hotel Stayer are going to now have one number. Yep. And you call out to a function that says, these two numbers used to exist, and now it's

this one number. Now, let's not get too wrapped up in what the logic of that is. Sure. But the after calling this thing, which is assume is simple, you now have one number, right? Yeah, yeah. And so, okay, so, then here we are. It's snowing on the ground. Now, you don't have to do this first part. We build a building, a data center. And then, also, we don't need to discuss this part. You call up our good friends at Dell, and they bring in a bunch of racks and hardware. And then, and then, and then it's just sitting there. Someone's plugged it in. Now, what happens? Right. Well, so, one of the things that I was thinking of as we were walking through this completely hypothetical example, one of the things one might need to do in that is to figure out, is our data really the same? Are we really talking about the same person? Right. Because you could have multiple people living at the same address that are not, in fact, the same instance of using the same number, even. Sometimes, one of the things that I hypothetically learned during this experience was that in one system, my first name was Nate. And in another system, my first name was Nathaniel. Oh, right, right, right. And so, I went in and linked my accounts. I said, these two accounts are linked. Yeah. And then, at some point, and who knows how they did this, I'm sure some batch run went through and actually did a comparison between these and said, whoa, mismatch, kick this out. And my guess is, you know, if we're thinking about this architecturally, a function could then have been called to say, here's a list of name mismatches, please go retrieve from their account information, their preference for contact, and contact them in their preferred way to tell them that. See, that's an even simpler one. Your accounts do not, in fact, match. And now we have unlinked your accounts. Yeah. Do they want a phone call, an email, a singing courier? Yes. And so, you probably have a function that says, well, go tell me what their contact preference is. Right, right. And then, that tells another function, okay, Mr. Coté, his preference is this. Now, please go send Coté an email or a text message or a phone call to say, there's something we can't discern here.

They don't match. Yeah, yeah, yeah. Now, where it gets kind of frustrating from a consumer experience standpoint is then you get that email or text message or phone call, and you're like, great, what doesn't match? Oh, we don't know. Yeah. We can't actually tell you that because I can't actually look at both systems because I work for this side of the house, not that side of the house. In this theoretic example, it sounds like you and I had to deal with a lot of crap. Theoretically, I may have had that exact scenario happen to me, and I got not one but two pings, one from each side saying it didn't match. But, of course, neither of them could tell me what didn't actually match. That was interesting. But I've long since learned that the worst, if you think integration is easy, you should try these kinds of projects. Yeah, yeah, yeah. Because even though you would think like hotel is hotel is hotel, it must all be the same information. Don't we all have the same business object model? Oh, no. No, we do not. In this hypothetical example, perhaps one hotel chain had a concept of stays in addition to nights, whereas the other one only cared about nights. And now, all of a sudden, we have a very different way of discerning what your status level might be. And, you know, I think it's handy to have like a software background in an instance like this. It does. Because while it may be frustrating, you can understand it very well. We're more forgiving. Yeah, yeah. Because it is like an almost, I remember, well, in my theoretical life, I remember going through that and just having more compassion than anything else. Correct. This is a difficult problem. They are. And I bet until it catastrophically fails, it's not like you get support for solving it, right? Right, right. It just seems like it'll be easy. But it is a hard problem. And, yeah, it's too bad. I see it a lot with airlines, too. I'm sure you've had this experience. This actually recently happened to me a few weeks ago. I was flying on what, from my standpoint, was my mainline carrier, Delta. Unfortunately, well, it happened to be a KLM branded flight. So, Delta can't change my seats because they don't have access to KLMs. Oh, yeah. Seating system. Yeah, yeah, yeah. And then I had another flight on another KLM subsidiary. And, again, KLM doesn't have access to those systems, so they can't change my seats.

You have to go talk to their desk. Yeah. And it's like, but from my standpoint, I just booked a ticket on my mainline airline, but not really because partners. Yeah, yeah, yeah. And you're like, can't someone please integrate your systems? Yeah, that is weird. There should at least be a human, like a meatware integration, where they have a secret phone number they call. Wouldn't that be nice? And it's like, hey, it's so-and-so at this desk. Can you type something for me? I did have an experience kind of like that once. I was trying to get on an airplane on some international trip several years ago, and I gave the counter my passport, and they typed in a bunch of stuff. And they always seem to type in a lot of things, which I'm always amazed at. Every time you ever interact with a travel system, there's a lot of typing going on. If you ever glance behind the screen, they're almost always using some kind of a mainframe system. There's some emulator that they're dealing with. It's like an old BBS. Totally. It's stunning, honestly. And a lot of typing, a lot of typing. Couldn't give me my ticket. You know, picked up the phone. Three other agents come over me. There's all sorts of clickety-clickety-clacking. And I'm like watching my watch going, hey, I got to go through security here. You know, we're getting closer and closer and closer to takeoff. And so finally, she like takes my passport and like walks away. I'm like, well, this doesn't sound good. I didn't get her name. I didn't know where she was going. And eventually, she comes back. And she called like Ryan. I'm making up a name. But she called a person. And like literally, a minute and a half later, out comes my ticket. I assume Ryan like literally went into the database and like flipped a bit or something. Yeah, that's right. And that like, Ryan must be the guy they call when nothing else works. Yeah, yeah, yeah. And then Ryan probably has like never bought lunch in his life because everyone's like, thank God for Ryan because, you know, he knows how to write a SQL query, you know, that he probably shouldn't even be able to do. But he did. Yeah. I've seen that before where customers actually had access to the production databases and made changes directly against the production databases. That's a perfect return to our exercise. We always come back around in tools. Now, let me. I'm an architect. I'll de-obsertify it a little bit. Please. You know, like you don't necessarily need to worry about the bare metal stuff. But let's and like, let's look at that whole application.

Like, so first of all, I'm going to install Kubernetes, right? Sure. Like what and then what, what do I need to figure out to do that? Like as, as the, the person in charge of which one do we choose? I want to figure out how, how to contact you to reconcile your account. Sure, sure. Well, so again, this, that might be far too fine grained for an abstraction like Kubernetes. You know, because as soon as we start to talk Kubernetes, well, okay, we've got some kind of a container we're running on top of that. Right, right. Do we really even need a container? Do we want to maintain a container for what might be a 12 line bit of code to go up to a database and pull back some information? You know, so again, that might be where we think about, well, how would we run that function? Right. Now we have lots of different options today, both on-prem and in the cloud. I mean, everybody's got an abstraction around functions. You know, you mentioned Knative earlier, you know, that's a very new sort of agnostic fuzz, you know, coming out of Google and, you know, we've contributed to others. Yeah, yeah. You know, and of course we've got Riff layered on top of that as well. And, you know, the goals are all fundamentally the same. How do we give you a higher level of abstraction over that? Yeah, yeah. Giving you more control over some of the interesting bits that go into functions. Well, let me ask you this one along those lines, sort of fundamental or something. It's like, so our system that looks up how to contact you, how do we decide not to put that into just like the reconciling code somewhere? Like, how are we going to decide to separate it or not separate it? Yeah, well, a lot of that's the art of what we do. You know, it's kind of looking at it and saying, does this stand alone on its own? Is it its own little piece? Is it something we want to reuse in other places? You know, when I think about contacting you, that seems like something I might have to do in multiple different contexts. You know, it might just be there's a problem with your reservation. It might be to tell you your key is ready or to tell you you've got an upgrade or whatever. And so I probably want to use that in more than just one, just this reconciliation of accounts. Right, right. What your preferred contact information is. Right. So I might want to have that be a more standalone piece that I can leverage and use and then

make it simpler for me to reuse it in other contexts. Right. So that's a huge part of it. Is this a nugget that I can easily plug in somewhere else to be valuable to me or not? And do you think with reuse, people value, maybe they value them the same, but like are they valuing the economic efficiency of not repeating yourself, as they used to say, or is it the value of having a consistent way of doing something? I hope it's both because we like consistency. Nothing's quite as irritating as, well, when you call this function, you have to give it these three bits. And the same function that does the same thing needs four bits. I mean, I can't remember the order, but they're different. And even worse if they return different things. Of course. Yeah, one gives you back this, one gives you back that. That's no fun. And then obviously there's the economic side of it is I don't have to rewrite your logic if somebody already wrote that logic once. And then test the code and all that kind of stuff. Right. And then that's the other part of this we don't always appreciate is the fact that, well, if this is something we've reused tens of millions of times, we've probably worked out a lot of the bugs, I would hope. Yeah, yeah, yeah. And so now we know we have this very stable, repeatable thing that does exactly what we think it does, and it is tested, battle-hardened, as you will. Right. So then, let's see. So we have a simple preferred contact information thing. Right. And just for our purpose, we'll assume it's going to be containerized. Sure. I don't know what else it would be. I guess you could run it in a VM or on physical Linux somewhere. I mean, you could. Right, right. I'm just kind of eliminating things. But nowadays, one would probably write it in a container. Chances are. Right. And so, I guess the first thing would be, like, I'm going to build a container that has, you know, whatever baseline OS I have, and it has this, I don't know, what would it be inside of there? Well, your technology stack. Yeah, yeah. So presumably, I mean, I'm a long-time Java guy. That's where I've written most of my code, so I'd probably reach for something in the Java space. I'm kind of a fan of Spring Boot these days because it takes away a lot of the boilerplate that I've had to do throughout my career, and so you're probably going to start with some kind of an image that has a base level of Java, it's got your Spring Boot bits, and then

here's my application bits, and now here you go. Everything's sitting in that box, and away we go. Now, the interesting challenge in a lot of organizations is, how do we govern what goes in that box? Right. How do we get to an agreement on, this is the level of Java we want to be at, this is the, you know, we all want to be at Spring Boot level this, we want to be on this operating system with this patch. That's where a lot of the challenge, I think, comes in in many organizations, is trying to govern that, and make sure that we don't have 19 different ways of doing the same thing. Yeah, yeah, yeah. It seems like in a lot of companies that Docker image growth explodes, you know, talk about a, may a thousand flowers bloom, you know, may there be a thousand Docker containers that are all just slightly different from one another, you know, and oh, hey, now we have to try to rev some of that, what does that look like? Right, right, and then the basic mechanisms, all good points, and then the basic mechanism of getting to that is, I guess, is going to be through basically ports on your image when it's running, the container when it's running, right? And you're going to tell your Spring Boot app in there, whatever app, like, listen to this port, and this is going to send in a number, or not, it's going to send in a number, let's just say that's your ID. And then what you're going to do is, and we'll just ignore this for now, you're going to somehow look up in a database or something what they're preferred. Yeah, those databases are pesky. Yeah, yeah, yeah. There's always data somewhere, dang it. And that'll be another thing that if you're doing this all on your own, you'll have to figure out when your container boots up or whatever, how does it get a handle, I don't mean that literally, how does it get connected to the database? How do I connect to the database, what does that look like? Right, right. And then, so then the third thing will be like, and I guess depending on how you do it, but you're going to need to return what this value is, and whether it's synchronous or asynchronous will be another annoyance layer. There's probably Kafka in here somewhere just because of that. That's right. But you've got at least like two things going on. Like there's the thing that comes in and asks you a question, and then it has to wait around if it's synchronous and blocking or whatever the kids call it nowadays. And then the second thing, you're going to talk to a database to find that, hey, you like email. And then that thing's like sitting around in the waiting room like Beetlejuice waiting, and then finally you reply back to it, and you're like, boom, this email, and then it runs

off, and then that container's done with its job at the moment, right? So, you know, the beauty to me of what functions give us is the fact is the fact that they can spin up and spin down, and because something like this might be sporadic, you know, it might not have a real predictable curve to it. You know, if you're a retail business, you know that you're going to get a lot of sales around the holidays. I spent a bunch of my career in insurance, and so you've got very predictable times a year where there's going to be renewals. And so you can kind of build around that. And you look at something like this, it's probably a lot more spiky when it comes to when do we need to contact you, you know? And so you think about, well, let's say you went in and updated your address. Let's say you moved, and so you went in and changed your address. Well, you're going to get a contact about that as well. And so that's another one of those things that will happen sporadically. And so to me, again, another nice use of a function that we can scale it up when you move, you go in, you change your account, some number of seconds or minutes later, you get that ping. Right. And it doesn't require an immediate response. Right. And so if there's one, if so, just as a spoiler alert, eventually we'll get to it, it should be a function. There's always a function in there somewhere. Or, you know, it should be a serverless. It just functions all the way down. But if we weren't doing that, basically, you would have created this container with the code that does the two things. Right. Right. That connects to the two things. And it's probably going to be sitting around idle a lot. Right, right. And then you need to figure out, like, so when does that run? How many of them do I need running? And then how am I going to tell it how to connect to a database? And then how do I tell other things how to get to this thing? Right. I guess you're sort of registering and finding stuff. Sure. And so are those things that, like, are defined for you in most infrastructure things? Or do most people, like, whether it's a good idea or not, do most people, like, bring all of that stuff and set it up on their own? How do you manage all that stuff? It depends on how we're trying to do this. You know, and so this is where we start getting, again, these different levels of abstraction. You know, if we're coarser grain, you know, if we're at that IaaS level, I've got to manage all this. And I'm responsible for figuring all these things out, putting all these moving parts in.

You know, and as we keep kind of moving up the hierarchy, fewer and fewer of those things become my responsibility. You know, we go all the way up to a serverless environment. The serverless platform I'm using, whether that's on a public cloud provider, whether that's an open source thing like Knative, Riff, et cetera, that's managing the, oh, there's a lot of lag here. Let me create more instances of the container. But me, it knows how to talk to your service bus, your queue, whatever it is you're talking to. As I slide back down to your example, if I try to do this as an application, well, I have to talk to the queue. I have to figure out how to do that. I probably have to manually say I want three of these to be in existence at all time. And, you know, with some of our platforms that are good enough to say, hey, there's lag here. Let's add two more. But, again, it's more for me to manage, more for me to worry about than, you know, if we keep trying to go up the curve. Yeah, yeah, yeah. So then, I mean, just to state, as I'm doing here, just to state the obvious absurd thing, if you have, let's say, a distributed application driven by microservices, like these little functions. That's what all the kids want. Like, normally, if you have a single process, traditional application, you basically don't need to worry about, like, routing things around or finding things. It's all just sort of, like, connected together in your code. And you might have some configuration, but basically, you're not sort of, like, looking for that other object instance. Right. It's just, like, there. Whereas, once you introduce a microservices thing, you, I guess, maybe reintroduce? I don't know. You introduce this new notion of, like, how do I find all my friends? Yep. Right? And once I find all my friends, how do I connect to them? Right. And what do I do with them? Right. And so, one, if you just were relying on, like, something like a Kubernetes, like, it doesn't really do that stuff for you, right? There's other things that you layer on top of Kubernetes to handle, I don't know, what do people call it nowadays? Service registry, service discovery. Service mesh? Or do people say that anymore? Yeah, I don't know. Yeah, service mesh. Yeah, fabric. Fabric. I haven't heard fabric in a long time. Well, I think they're now mesh now. Oh, they're mesh. Right? I don't know. 5G. I do, having been in this industry longer than I'll admit, it is amazing to me how often

we rename an existing thing and call it something new and then try to pretend that no one's ever done anything like this ever before. Yeah, yeah. And it's like, yeah, but it's just like this other thing. We just call it this now instead. Right. And then so the reason you would go through this suffering in our example, or not suffering, this additional stuff is, as you were kind of saying, you have this service that tells you your preferred way to be contacted, and there's more than one piece of software that wants to use it. Right. Right. And then, I guess, I mean, we won't go down this path too much. You wouldn't put your entire piece of hotel running software in one piece of software. I hope not. I hope not. So you do need it to be a separate service somewhere. That's going to be the best way of running it. So you have that set up. So, okay, so let's say that you don't want to, I mean, how do you, what would you do so you don't have to worry about all of this, like, service registry routing stuff? Like, is that, do I go, like, download the Knative and I build something for that? Or is that the wrong thing I'm looking at? Well, so again, this is where we start getting into, do we have good platforms that let us do this? You know, this is where we get into some of the service discovery things. And some of the stuff's built in the spring. Some of the stuff we can get from providers and get it from PCF, various places. And, you know, so that's part of it is understanding, like, what are all these pieces? What goes together? How do I want to make this as easy to operate and as easy for my app developers? Yeah, yeah. And what does that look like for us? Right. You know, but I think what, you know, the message that I'm really always trying to get across to people is we've got all these common concerns and issues that we need to deal with. And what does that look like? How do we do that in a way that's as simple as possible? We don't want to have a million different ways of finding our services. Right, right. We don't want to be as consistent as possible, you know, so that we can get people to use the same thing. And again, we have confidence in it. We know it works. It's reliable. You know, but the other part of this that I'm always a little cautious on is we're so quick. And you brought up this good point that we used to have the monolith and then now we're moving to these more distributed systems. And we do that for good reasons. You know, we can scale it independently. We can employ them independently.

But we pay some tax to get that. There's added complexity because, to your point, we have to go find them. Where are they? They're going to move because they get destroyed and recreated or we scale up, scale down. So it's not always going to be in the same place. Now it's harder to log. I've got to push that out to a stream and then deal with it later. If we're not getting the benefits out of that distributed system, we shouldn't be paying the complexity price to get them. Right. And yet a lot of people are just like, nope, I'm going to do everything as microservices and functions because I read a white paper or I hear that such and such a company is doing it and ergo I need to do it. It's like, no, no, they're just tools. Use the right tools to solve the problems. Right, right, right. You know, I mean, I had someone say to me a month or so ago, I'm going to refactor my entire application as a set of functions. That's probably not a good idea. Right, right. Are there things within your application that might be fantastic as functions? Absolutely. Probably not literally your entire application. You know, that seems fairly unlikely. There is a small set of apps that that would apply to. Again, statistically, probably not yours. Yeah. Yeah. So which of these tools is the right one to solve the problem? So then speaking of tools, to move my thing out of the Columbo-esque way of putting it, like, so what is Knative? How would that start to fit into here? Because that's a serverless building framework thing. It's like an agnostic FAS layer so that you don't have to worry about, okay, I want to run it on-prem, I want to run it on my laptop, I want to run it in a public cloud provider and not be stuck with their abstraction. So if you're going to use the raw public cloud provider, you have to write it the way they want it. You're kind of stuck in their model. And like Lambda or whatever Microsoft. And they're great. I'm not trying to bash on them. You know, I've done a bit with Lambda. It's good stuff. You know, there's cool things there. And you can tie into a lot of other things very easily because of that. It's very integrated with other offerings from the public cloud providers. But either tactically or strategically, we might not want to be so tightly tied to one provider.

Right. We might want to have the flexibility to say, you know what, we're renegotiating our deal, so we're going to start moving some of those workloads to another provider. as leverage in that negotiation. Or we may decide, hey, they have a better XYZ. We're going to go use theirs instead of this one. And so we probably don't really want to be tied in. Yeah, yeah, yeah. The reality. Someone was explaining, like I always get all, I don't know, persnickety about lock-in or something. Sure. Because I always wonder, like, when does that actually, how often does that actually come into play? And then usually it seems to mean, I just want to stop paying this vendor. Which is totally fine. And that does happen, let's be honest. Yeah, but someone was going over something interesting on this point, which I'll make an analogy for. It's like, well, it's not necessarily, you're locking into yourself, but like you're given the opportunity when you add a layer of abstraction to customize it how you want to use it, including limiting the use of stuff you don't want. Right. And, you know, I think analogously is the whole, like, Spring framework of like, well, why do you need this whole other framework, right? And, you know, on the one hand, historically Spring people could be like, because then you're not locked into the implementation, which I'm waving my hands here, which is fine. But I think more of what's interesting about layering that on top of the default Java is like, I just like it this way better, right? And I can customize how these things hook together. So you might similarly build your own sort of like, for your organization, your own sort of like serverless-y function thing on top of what they have available. Yeah. I mean, so to your point, I always remember building apps with like that database layer. And we always said, well, this way we can change our database later if we want to. Exactly. Right. To which no one has ever actually changed their database, right? That's like the least likely thing to do. But there's still good reasons to have that there, though, you know, because to your point, it gives you a different abstraction to work with. You're not tied down to some of the things that that particular database might ask you to do, you know, and it is good to have that layer of indirection. Now, I've seen that a lot with I'm calling a third-party thing. You put that layer there.

Sometimes it's to adapt the interface because you don't want to call it their way. You want to call it your way. You want to pass a different set of information. Maybe there's something that gets passed in every time you call it. You don't want every single consumer to have to know that. You can sort of add that in. Yeah, yeah, yeah. So there's a lot of good reasons to do that kind of work. And so it's the same kind of thing here where you may not want to be stuck with the abstraction that a given public cloud provider provides you. Yeah. Well, go ahead here. Use this one. And then you have the option to move it to wherever it makes sense for you. So that makes sense. So then to summarize, basically Knative is a framework for building a serverless layer. Sure. And the serverless layer being basically like I have these little functions, these little components. Yep. And they do something. Super mini microservices or something. Yeah, like whatever granularity you think you should be doing according to your council of elders or whatever. The enterprise architects. That's right. But then you need to basically, I'm hesitating because I'm trying not to use certain words like orchestration and things. But you need a way of each of these components being able to find each other and work with each other and basically operate with the same ease that they would if it was all a monolith in-process, in-memory thing. Or you were using one of the public cloud providers abstractions. Right. So that's a lot of what's being then provided with these layers like Knative and RIF. And then so I assume because it's Knative instead of whatever else native, basically it runs on top of Kubernetes. Of course it does. Right. So it's basically a framework for if you're running on Kubernetes and you want to create a serverless framework. Right. Now, so is that if I... Run your function on top of Kubernetes. If I'm this theoretic hotel chain, like does that mean I, some development team is going to take Knative and build a thing on top and build my serverless framework? So your Kubernetes Knative environment is probably going to be run by your operations people. Ah, right. And it's going to be your developers writing the function. And then however you want to get that into that environment, probably through your CICD pipeline, fingers crossed, I hope,

that actually gets it into that environment that's maintained by your operators. Right. So that would be the way I'd look at it. And so part of the beauty of Knative, RIF, et cetera, is the idea that, okay, you've got Kubernetes. You've decided that's your baseline. So if you've got some stuff running in containers on top of Kubernetes that they're orchestrating, you want to add some functions into the mix, well, now you can run that on that same base platform and call them and talk to each other and life is good and gives your developers another abstraction. So I can write that as a function if that makes sense. I don't have to shove it into a Docker container or whatever you're using for this 15-line thing to look up your preferred contact information. Right, right, right. So now I can write that as it should be, just this simple little baby function, and run it and not worry about it. Now, so is Knative, because I've discovered over the years that many of these wondrous layers of abstraction are actually just a series of APIs and interfaces. Yeah. And then eventually, like, there's some code that actually does something. Right. And so, like, where does Knative fit on that spectrum of, like, this is just an API versus, like, oh, you actually wanted to do something that's over here in the VIP room. Yeah. And so, like... I like that, the VIP room. There's bottle service, I guess. How much, I mean, is Knative, like, something I can just, like, download and install, or is it more of, like, a thing I need to, like, implement or buy from a vendor, or, like, where does it all... Well, I mean, I think all of the above, right? I mean, you could do it in multiple ways. So, I mean, I spun up a GKE cluster for this demo I did this morning, and Knative is installed on top of that, and then RIF is installed on top of that. You know, and so from my standpoint, I installed that on a Kubernetes cluster. Certainly you can buy that if you wish. But basically, if I get Knative, and I have a Kubernetes cluster, I can install that thing that I got on, I don't know what they call it, vanilla Knative? I can install the Knative, the most recent... Very new. The most recent blessed version on top of... Very new. Oh, sure, sure. Let me stress that. This is Alpha Software. Yeah, yeah, yeah. Well, let's not go down to what version it is.

I mean, let's just assume it's... This is the vision. Sure. It's like, I can just... I download it from, I guess, GitHub, right? I pull it down from there... Whole worlds on GitHub. And I build it. And then I'm like, all right, Kubernetes install. So here's your environment. And then, boom, I'm done. And I don't mean this in a facetious way, but I have a serverless setup that I could start using. You have an environment within which you can run your functions. Right. And then, so what are the core things? So now I'm back to the developer. So what's Knative giving you? Yeah, yeah, yeah. Now I'm back to that developer who, like, I have this code. I've got a Spring Boot application. Yes. Now what do I do? So a huge part of what Knative's trying to give you is, like, that build step. What does it mean to go from my code to the environment? And that might be a build pack. That might be a Docker image. And, again, we're trying to get abstracted away from that because I don't necessarily want every one of my developers building their own Docker image. You know, again, we get to that point where may 1,000 Docker images bloom. Well, that's probably not what I want as if I put on my Enterprise Architect hat. You know, I may want more consistency, some governance around what we're doing. Are we all at similar levels? You know, you don't want 1,000 different ways to run a, you know, a Java function, for instance. Sure. So what we're trying to get to is a point where my developer, again, is just focused on writing the code. How do I go look up your preference? And then getting that in an image, all that stuff, Knative can help me do that. So it's got a build step to actually build that, take my code, put it into the environment. There's the eventing part, which is how it actually talks to the underlying system. You know, I need to, you know, I'm listening to this bus. I'm looking for certain things to come in. I'm on this channel. Okay, great. Here's another message, another message. I go respond to it. You know, and then how do we scale that up and down? You know, that's the other part that it gives us. Right. And then I would assume, I'm kind of rushing you so we can get lunch before they put it in. No worries. But I would assume, so you've got the Knative, so you've got, we've got our DIRT, we've got our data center, we've got our servers. We're running, let's just, because we work here, let's say some VMware stuff. Some VMware, absolutely. That's being used to run your Kubernetes entrance, so you've got PKS going there.

And then you installed your Knative thing. Now, on top of the Knative thing, you put the, like, Pivotal functional thing. Yeah. Which is basically rewritten RIF, if I remember. Yeah, RIF is the open source. And then, so what that does is, in Knative, there are probably some constructs as you went over, right? Here's your registry, here's a venting. But, like, here is not exactly a Spring Boot handler, right? And so, what Pivotal, what's the Pivotal service? PFS. What PFS does is it basically knows how to talk to Knative and then says, like, all right, Spring Boot people, never mind about Knative, you talk to PFS. And in the same way that Spring wraps around Java and all sorts of other services, you just talk to the Spring thing. Yeah. I mean, you don't have to worry about all this Knative business. Yeah, I mean, the moral of the story is in all these things, like, how do we get you focused on the stuff that matters to you? Right. Yeah, and so that's really what the goal would be there is to, again, let you get back to that model of, I need to write a little bit of code to solve this business problem. So, then, backing up a little bit, what would it look like if I didn't have a PFS? Like, does that even work? Like, would the development team have something to do, or would it just be like, I don't know what's going on? Well, but then, again, you're much more exposed to those underlying layers. Like, what would you be using? Like, would you be calling directly? So, if you built your container, would there be, like, OS-level stuff that you call out to, or? You could. Yeah. You could be writing. I mean, again, you would have to then be responsible for how do I interact with Knative? How do I use the Knative build system? You know, you're just, you're closer to it. Because, in theory, I guess, so you're in that, I mean, the secret is there's an operating system inside every container. So, there's an operating system in the container. The container boots up. I forget what it is. It executes some command that's your magic, right? It calls main and whatever you have. And then, you would be responsible for saying, like, all right, I know I'm a Knative thing, which means I've been passed in this configuration of an IP address or a URL to go to. That is my Knative thing. I'm going to be like, hey, I'm alive. And then, the Knative thing is like, you're part of this Knative community. Here's all your information.

And then, however you wrote that, all it knows how to do is HTTP. Unless there's some other magic stuff going on, networking. And so, then, whatever your program is has to know how to call out to that Knative thing, how to interpret whatever payload came back. And then, you also have to implement, now there's these five other methods that I call on Knative off through a network connection that does stuff. And then, one of them will be, I say, I need a database, I need a handle to a database or something, hand that back to me. And so, instead of having to invent that whole mechanism inside your container of how to talk to the Knative world, basically, something like PFS is like, we do all, we have a way of doing that. And then, we add this thin veneer of PFS that expresses all of that in a Spring Boot friendly way. Well, and I'd say the other part of this that's so important is we all realize that your application isn't just a set of functions. Your application isn't just something you shoved in a Docker container. Right, right, right. It's all of these things. It's all the day two stuff, as we would say. Exactly. Knowing how to scale up and scale down. Right. And realizing that today's problem is best solved in this way. Tomorrow's problems are best solved using that way. But we still got to talk to each other. Yeah. How do we do that in a way that's consistent across all of that so people aren't learning seven or eight different abstraction layers trying to figure out how do I make this all talk to each other? How do I make it all work? Right. Like, well, let's give you a consistent experience and give you a runtime that can handle all of those things. Yeah. As opposed to having to manage three or four or five different runtimes. And, oh, guess what? It's just like our instance we talked about at the beginning of it's a ticket from one airline, but it turns out it's actually three separate airlines that can't talk to one another. Yeah, yeah, yeah, yeah. You know, I had, and then I'll wrap up here. I had the weirdest, what do they call it, cross-code share thing recently. Yeah. Is I booked on China Eastern. Okay. Which was actually Korea Air. Oh, yeah. And then I got KLM credit because I used my KLM thing. But the weirdness was that China. All Sky Team. Well, no, no. Maybe it wasn't China Eastern. There was one that was not Sky Team.

Okay. The first, some Chinese airline was not Sky Team, but they code shared to this other one so I could kind of like launder a non-Sky team. Nice. Which was like, back to having a programming background, I was like, wow, that's a crazy thing. I don't know how someone let that in. Right, right. Somebody shouldn't have, probably. Kudos to you. But, so anyways, we should have a part two, maybe next year as a cliffhanger for this season of Pivotal Conversations. But, so this is a good explanation of Knative. Now, I want to pull back to a broad scheme of things. So, in the serverless world, it started off just like Lambda or Lambda or however I want to mispronounce it. We've got functions. Got functions. We've got functions in the sky. Functions as a service. And then, and then somehow, and maybe this is all in my head, I think serverless kind of started to mean like all of how we would do programming in a cloud native world. But, what you've talked about has basically brought it down to more or less like erratically called short-lived functions that just get called. Instead of basically like serverless as everything. Right. Right. And so, is that, like, would you say how you have characterized it is the way people think about serverless? Or do you use the word function a lot because you're like serverless is meaningless. So, I want to be very clear that I'm talking about functions. Some people definitely use the terms interchangeably. Yeah. For right or wrong. Some people would say functions are a subset of serverless. Right. Which is confusing. Probably more accurate. But what does that even mean? So, you could potentially run other types of workloads in a quote-unquote serverless environment. Yeah. I think serverless has almost started to become abused and almost everybody has their own sort of flavor of what it means. And we've probably used it in too many ways at this point. And then it's also not, it doesn't purely have to be an event-driven architecture. Not necessarily. It doesn't have to only be event-driven. Correct. You could have, pardon my old fogey terms, you could have, like, those blocking calls. Right. Like, there's no need to, it doesn't have to be asynchronous. Some things have to be synchronous.

Right, right, right, right. Right, right. Okay. So, maybe that was also the original confusion, at least for me, is like, at some point, I think serverless meant only an event-driven thing, right? That you would tell something to execute and it might send an event when it's done, so you've got to listen to that event. Sure. But nowadays, functional stuff can mean, like, it doesn't have to be, it can be synchronous or asynchronous. It can be all sorts of stuff, depending on what you need to do. Right. I mean, I think it's generally going to be asynchronous. That's probably the most important thing. Right, right. Well, that's a whole other discussion. It is, isn't it, though? The kids like that. That's right. All right, great. Well, we're going to go eat some lunch before, because have you noticed that the catering people here, they're just like, boom, they're on time. They're done. They pull it out, they said stop lunch at, and they're gone. Yeah, it's great. Well, where should people follow you if they want to learn more? Well, you can follow me on Twitter, N-T-S-C-H-U-T-T-A. Can I spell my name? I don't know. It's been a long, it's been a long month and a half. It's probably not confusing to long-term, long-time listeners. I screw up my own name. Do you? If you think about how Michael is spelled, it's very weird. There are, yeah, right. Like the A and the E and the L and the C-H, basically all except the M-I. M-I, and then after that, it's like a jumble of letters. I guess because it's like French, right? But I know how to spell your last name. Oh, yeah, well, that's easy. I got that one nailed. I've known that for a long time, Coté. Yeah, I should look up the origin, not the cultural, but the spelling origin of Michael, because it is a strange. Because there are different ways of doing it. Yeah, yeah, yeah, yeah. You can follow me on Twitter. You can also go to my website to see where I'm going to be at. There's going to be a lot of events in 2019. I know that for a fact. I've already looked at my tab, and starting in, like, I guess it's the middle of February. I'm off the road for about six weeks. That's right. Trying to heal up. I've got to get a new hip next year. Oh, good. I'm going to be bionic. The next time I see you in person, Coté, I will be bionic. You'll officially be a hipster program. I'll be a hipster, yes. Not a ninja anymore, but I'll be a hipster. That's right. Well, as always, this has been Pivotal Conversations. Thanks for listening. Now, I think by the time you hear this, we probably will have merged together the Pivotal Insights and Pivotal Conversations podcast. Now, if you're shocked that you're hearing double the good content, lots of things about how pivotal customers, what they've been up to, and things like that, that's from the old Pivotal Insights.

And then if you're hearing about customers, and you're like, why am I hearing all this nerd stuff, then that's because we've merged the two podcasts together, like a bionic twin matrix. Sure, like it. I don't know. So with that, you know, we'll see you in 2019. Bye-bye. Cheers.

Tanzu Talk · 🍕 Get more pizza.