CRAIG BOX: Hi, and welcome to the Kubernetes podcast from Google. I'm Craig Box.

ADAM GLICK: And I'm Adam Glick.

[MUSIC PLAYING]

Hey, Craig, how was Next last week?

CRAIG BOX: It was a lot. There was a lot going on and over 20,000 people, I believe, at the event.

ADAM GLICK: Yep.

CRAIG BOX: It felt like every single one came through and played with our GKE Hybrid Orchestra demo, which was fantastic. I only got a chance to see one session, which was the Spotlight on Cloud Services Platform by Aparna Sinha and Chen Goldberg. But it was fantastic, and I've been watching a number of the videos, and I've got a lot more queued up to watch. How about you?

ADAM GLICK: Oh, it was great. I enjoyed the Hybrid Orchestra piece as well. It's also nice to run into our podcasting friends from the GCP Podcast and see they actually had a booth there on the show floor, which was really great for anyone who got a chance to stop by that.

I met a whole bunch of folks doing a lot of interesting stuff with Kubernetes, some of which we will have on later on the show, talking about what they're doing with Kubernetes in the community, which is really great. And besides meeting a lot of great people and having a great time, I also kind of enjoyed the concert. So it's always nice to have a little fun at these conferences as well.

CRAIG BOX: Great. Let's get to this week's news.

[MUSIC PLAYING]

ADAM GLICK: The big news of the past week was Google's announcements around Kubernetes Engine, especially GKE On-Prem and Knative. We won't rehash the coverage that we had. But if you didn't catch last week's interview with Aparna Sinha, we recommend that you check that out. There's also been some interesting analysis from people such as our recent guest, Joe Beda, who looked at Knative in his TGI committees last Friday, and Paul Czarkowski, who posted how you can use the Knative build system by itself.

CRAIG BOX: By the time you hear this, Istio should be at version 1.0, with our congratulations to everyone in the Istio community. We have a great interview with Dan Ciruli and Jasmine Jaksic, which you can hear on this podcast next week.

ADAM GLICK: If you're new to Kubernetes, and you're a visual thinker, you'll love Kubernetes, the Theme Park Analogy. Dan Lebrero explains Kubernetes' concepts in an accessible way, and there's a link to his post, as well as the aptly-named Scott McCloud's Excellent Kubernetes Comic, in the show notes.

CRAIG BOX: If you're interested in extending Kubernetes, you'll know that two common approaches are running your own API server while using custom resource definitions. The KubeVirt project for running virtual machine instances on Kubernetes have considered both, and actually have settled on a combination of the two. A blog post from Red Hat's David Vossell on the Kubernetes blog this week spells out the pros and cons of both, and suggests that there are only a small number of advances needed for CRDs to close the gap.

ADAM GLICK: Another blog post on Kubernetes.io this week is by Intel, and digs into the allocations of Kubernetes workloads to CPUs. CPU Manager, a beta feature introduced in Kubernetes 1.10, can help you assign your pods to the appropriate CPUs in a machine, and thus lower execution time.

CRAIG BOX: And that's the news.

[MUSIC PLAYING]

ADAM GLICK: Oren Teich is a director of product management for Google Cloud and leads the Knative project. Oren previously was the general manager of Heroku. Welcome, Oren.

OREN TEICH: Hi. It's so great to be here with both of you.

CRAIG BOX: Can you start off by telling us what Knative is?

OREN TEICH: Knative is an open source project that provides the building blocks for serverless. It's actually really important to note what it isn't as well. It is not a serverless solution that I expect everyone out there in the world to use.

What we realized as we were both talking to customers and partners is that people are super excited about serverless, but they're also afraid of what it means. They don't know how to move forward. They're seeing a huge explosion of different products out there, and they were getting confused.

And so what we wanted to do with Knative is offer a set of building blocks that we, as well as other companies, can build off of. It's explicitly not for developers. What I'd hope is, if we get to the stage that Knative is successful with a bunch of partners and with ourselves as well, that developers will ask for Knative compliant, Knative compatible, built on Knative platforms. But at the end of the day, it's infrastructure.

ADAM GLICK: Gotcha. So if developers aren't the key audience for this but more developers who are partners, who are those partners and what are they building that they would use this for?

OREN TEICH: There's a lot of cloud providers out there, right? It's not just a Google world, of course. There's a ton of companies that are out there. And so many of them have their own serverless platforms that they're creating. And some of them are very specialized and vertical. Some of them are sort of broad.

And what we hear from customers time and time again is they want the ability to adopt these, and then they want to be able to have portability. Often, it's frankly FUD, right? I mean, how often do people really need portability? I don't know.

ADAM GLICK: It's an insurance policy.

OREN TEICH: It's an insurance policy. That's right. And we've all learned from things that have happened in the past 20 years in tech, that it's really important to know that you're not trapped. So we've heard that loud and clear, not to mention there are some real use cases. You know, the real use cases that come up a lot are there's always China. There's always situations where you're in truly disconnected environments so retail is a great example.

Oil rigs come up a surprising amount. Maybe that's just us. Turns out a ton of computing running on oil rigs. And so a lot of the companies that make software for there don't want to have to tell their developers, OK, so normally write your software this way. But if that software's going to run on the oil rig, run it this way, right? They just want to be able to say, no, just write your software one way, and we'll run it anywhere. So that general need-- write your software one way, and you can run it anywhere-- is exactly why we created Knative.

And we've been working with a number of partners to ensure that there's products created on top of that. So Google has a product created on top of that called the Google Kubernetes Engine Serverless Add-On. There's other partners-- for example, SAP announced at GCP Next their new product built on Knative, called Kyma. It's a super cool product.

If you haven't seen it, what it does is it-- you know, everyone's familiar with SAP's products. And they realized that you want to build and extend SAP's products. If you have an ERP, let's be blunt-- no one is rewriting ERPs to be on a serverless platform today. But what you are doing is extending and customizing and adding and integrating. And all of that work that people are doing, they want to be able to do in a serverless model. And so that's exactly what Kyma is designed to do. And by building it on top of Knative, they both got them a huge acceleration boost in their ability to bring that to market as well as ensuring the portability for the developers.

CRAIG BOX: Kubernetes has a number of implementations by hosted providers. But it also feels like Kubernetes itself is a reference implementation of the Kubernetes API. And the way that other cloud providers choose to implement that API in order to be conformant so far has basically been running the open source pieces.

Is there a reference implementation of Knative? You've said that it's building blocks. But it doesn't feel to me like you've said this is a product. You've said these are the building blocks. And I'm interested as to why there's no product.

OREN TEICH: You asked a few questions there. Let's take those apart. So yes, there is a reference implementation. And the reference implementation of Knative is on the GitHub repo, github.com/knative.

CRAIG BOX: OK.

OREN TEICH: The distinction that I'm making about not being a product is it doesn't have a UI. It doesn't have a CLI. You know, the documentation is-- it's good for a new project, but it's not great. And I'm trying to acknowledge the reality of where we are today.

CRAIG BOX: OK

OREN TEICH: Right, because there's always the evolution of how things change. And of course, we want to make this product and this project more successful. But you know, I think it's important to note this is early. It just got out. And so where things are today versus six months versus a year versus six years is really going to evolve.

ADAM GLICK: When you say it doesn't have a UI or a CLI, are you basically saying it has an API, that this is more like a plugin that you would put within your code if you're doing an include, say, for instance?

OREN TEICH: What Knative really is is it's three Kubernetes custom resource definitions. The first one is build. So really common thing, you know. I'm a developer. Although we talk about Docker containers a lot, I consider them just a tool. They're an incredibly important tool, but I personally never want to have to worry about or think about them. So how do you take source code and build it and package into a Docker container. So that is something that we're exposing as a CRD in Kubernetes.

The second piece is the serving. So if you're familiar with Kubernetes, you know that sometimes getting a service actually up and running, there's a lot of YAML involved. There's a lot of configurations. There's a lot of things you have to think about. This simplifies that. It simplifies it, though, in Native way-- yes, I'm purposely using that word twice here-- in a Native way to Kubernetes, right. And that's kind of where this name comes from. The whole point is we're trying to make the particular use cases of serverless feel native-- and I'm not saying Knative-- feeling native to serverless, to Kubernetes, for developers.

So we have the build. We have the serving piece, which takes your container and gets it running and serving and all those pieces. And then the third one is event binding. That's where we are today. The goal, like I said, is to ensure portability. So I have no doubt that there's more work that we're going to have to do. You know, you start somewhere and build from there.

ADAM GLICK: Knative is now being released. And there are a number of other serverless platforms that are out there, even ones built specifically for Kubernetes. How do you think of those as different? You've talked a little bit about-- it sounds like this is more of like a meta-layer that sits underneath those. Can you tell me more about that?

OREN TEICH: Yeah. Our hope-- and this is a big goal, and I don't want to overreach. Maybe we'll get there, maybe we won't. But our hope is that we can work with as many of those as possible, and that they'll find that they can focus on the differentiated value as a platform that they're trying to provide by adopting Knative, and get velocity and speed themselves.

There's this turtles on turtles on turtles thing that's going on here, right? And we've certainly spoken already with-- we're partnering here with IBM, Cisco, SAP, Red Hat, Pivotal, of course, and all of them are already replatforming, be it OpenWhisk or RIF or others on top of Knative.

And what I hope, and we're very open to doing, is working with other partners, be them small or large, to do the same thing across the ecosystem. Because ultimately, if we can do that, then we're taking the material big step towards enabling that portability for the end developer.

CRAIG BOX: Given that goal, was there ever any question that this wouldn't be open source?

OREN TEICH: No. We knew this was going to be open source from day one. And in fact, one of the really delightful things about this project is, we started it in the GitHub repo. There was never code elsewhere. We, day one, started in the GitHub repo. You can look at the commit histories in there. We've been doing the development process from day one in GitHub.

So this isn't a case where we were doing internal Google processes and then had to switch over. For example, Google, of course, has their own internal bug processing and bug tracking systems. We actually didn't use those. We didn't use internal documentation. We were using GitHub. And as a new person to Google myself, I have to admit that I'm still pretty partial to the external tools, so I'm not complaining.

CRAIG BOX: So far, most people's experience of serverless has been through functions as a service, and generally those provided by a particular vendor. And the differences between them have been quite vast. Hopefully, there'll be some unification, especially in some of the pieces we've talked about here. But are the tools in Knative useful for people who want to run traditional workloads, and who care more about the infrastructure, like the idea of the build pieces that are in this? If I'm not running in a functioned environment, will the Knative pieces still be useful to me?

OREN TEICH: Oh, absolutely. Personally, I have a goal to help people understand that serverless is not simply a small snippets of code running in the cloud. My goal is to have great serverless platforms available for our customers that can run any code, functions, an app, a container.

The means by which you package up that code, I don't care. If it's a small piece of code, if it's a giant piece of code, if it's a binary piece of code, all of these you should still be able to run in a serverless environment. Because serverless, ultimately, for most customers, means the programming model. It means what you have to reason about. It means the maintenance. It means the management.

And then, if you're talking about an hosted environment, which of course is not Knative, but if you're talking about an hosted environment, that also means, of course, the billing model. So from all those perspectives, we want to let people run anything, and we're really aggressively trying to expand the scope of what can run.

And so to that point, when you look at the pieces in Knative, they are absolutely focused on that serverless experience, but they're also much, much broader. And there is absolutely-- I would strongly encourage anyone who's like, yeah. but I have a general need for this source build experience, great. Rip that out of Knative. Use it. That's why it's in the open source. That build CRD is in there. The same for each of those components.

ADAM GLICK: You mentioned portability before, and I think as a--

OREN TEICH: Once or twice, yeah.

ADAM GLICK: Maybe a couple times. And when I, as a developer, think about those kind of dockers, it's a lot in that category of it, but this is a different set of deals, but you mentioned that it runs Docker. What is it that this is providing of the portability that Docker doesn't provide?

OREN TEICH: When we talk about portability, there's a lot of different layers, of course, right? So as you mentioned, Docker's a great mechanism of packaging up software. And so that gives you portability of ensuring that your dependencies are there, but what you still have left are two major parts.

One is, what about the portability of the control tools you use? So if you write a tool to deploy something, if you write a tool to manage your systems of things, if you're writing anything-- because the reality is, no one uses anything off the shelf, right? Everyone's writing some scripts and tooling. Is that portable because sometimes more of your investment can go into that than it can actually go into the code you're writing.

Then there's the actual code execution paths. So build is not part of that, but the execution path, like what does a function signature look like, right? How does your code get called? So once it gets packaged into a container, now it's portable, but that build step helps define and ensure that there's alignment, like this is what a function looks like.

Same time events, so you have to bind and listen to an event. That winds up being almost indistinguishable. Like what does it mean to run your code if you don't know how to bind to events because your code will never get executed, right? So we need to ensure that it's not just the pure-- does this line of code run with the right environment, but does it get called into? Do the hooks in the ecosystem that are around it exist properly? And that's really what we're trying to solve here.

CRAIG BOX: There are a lot of distributed tracing pieces and things that we have, and published papers on, to move the industry forward and that kind of thing. But is Knative, from day one, able to integrate with things like stackdriver tracing? Or like there's the Google serverless versions, or is there? Right?

OREN TEICH: Right, so from day one, right now, where Knative stands is, it's really heavily focused on taking advantage of the incredible advances that are happening in open source around a lot of the debugability and visibility and observability. So it bundles in and is built on top of Istio. It uses OpenCensus.

And what's great about that is that those become the building blocks for this entire ecosystem that happens. So Google announced, at Next, this whole service view in stack driver. You get that for free when you use Knative on GCP because it's built into the same hooks.

So it's not that we set out to say, how do we write a stackdriver integration? How do we write an X-integration? We said, what are the definitive APIs that are becoming the observability means today? And those are the things we built on top of.

CRAIG BOX: And so by building on top of Istio, effectively, you get all that for free.

OREN TEICH: That's correct. Yeah, there's Istio and OpenCensus, and those are the two big ones.

ADAM GLICK: Is there a reason that you decided to make this a separate project versus making this-- because it runs only on top of Kubernetes-- just making it part of Kubernetes?

OREN TEICH: Kubernetes is a very important piece, and what I see from the Kubernetes maintainers is, they're constantly trying to keep it focused on what it does well, and encouraging the ecosystem around it. And this seems to have fallen very squarely in that ecosystem around it.

At the end of the day, there's always this tension I think we have when we're building products of-- we're trying to solve end user problems. They don't care about the 20,000 pieces that it takes to build them, so we should bundle it. On the other hand, the more you bundle, the harder it is to work together, the slower things can happen.

So I think, in general, I've been very impressed with what I've seen in the Kubernetes community and CNCF and the leadership there. Kubernetes is not trying to expand its scope. As I see it, they're very clearly focused on what they're trying to do, and--

CRAIG BOX: They're almost actively trying to shrink their scope.

OREN TEICH: Yeah. That's right. Helm, I think, is a good example of that recently. And so I think this is just a natural place to be adjacent.

CRAIG BOX: One of the early user comments I saw, maybe in the hacker news thread, was installing Knative means that your code gets run with something like four sidecar containers. Now that feels like an odd thing to complain about. That's like saying, well, my C application needs to bundle the standard library in order to work, or something. But is there something you would say to people, is looking at the end user approach to this, as to why that's not a thing you shouldn't worry about?

OREN TEICH: So engineers love to think about extremes, right? And it is absolutely true that if you had a million QPS service, you probably don't want to put it on Knative today. And the optimization path of having four sidecars that everything has to go through is probably excessive.

But that's not the reality, right? The reality of what people actually do is, they're putting anything from almost no load to moderate load services, and the overhead that's involved in these sidecars is nothing compared to the benefit you get from observability, from, frankly, just speed of development.

So on top of which, last I checked, computers keep getting faster. We optimize our code. We figure out better paths. We do things like, for example, is this open source gVisor project, which makes it much cheaper and faster to execute code. So I think, overall, again, like you have to look at that point in time. Yes, today, there's always going to be warts and challenges and things. I think that we still have something that's super meaningful for customers and users today. And it's only going to get better.

ADAM GLICK: You've laid out the different partner pieces, and what this does. Your vision for the future, looking out a year, what does this become? What do you want it to be in its ideal state?

OREN TEICH: Personally, I want to be a little pointy here. Obviously, I love Knative, and it's in my team and we've had a huge group of people working on it. It is infrastructure. I don't care. What I care about is making developers successful, right? And this is a means by which we do that.

What we need to do as a entire ecosystem, ensure that our users are able to run the workloads they need in the way they're looking to do that, and ultimately, I happen to believe that's in managed services. I think we need to give customers and users the choice of where they run those things.

And if we do that correctly, they will choose to run as much as possible with us. But it's only through that open choice that that happens. So my vision is actually not about Knative. My vision is, we give incredible developer experiences with one simple command. You could have your staff running anywhere, on-prem, someone else's cloud, our cloud, and you're making the choices of how and where to run these things simply based on what you think works best for you.

Knative is an absolutely required infrastructure piece to making that happen. But I ultimately want it to disappear from the developers. I want it to be the oxygen we breathe, and I don't talk about the fact of what mix of nitrogen and oxygen is in the air. It just is the reality and the necessary conditions for us to live. And I want Knative to be the same.

CRAIG BOX: How long do you think it might take to get there?

OREN TEICH: Years. Years and years. I have no false assumptions here, and this is a separate interesting question, right, of what's the role of serverless, and what's the overall scope of how this is playing out? And what's the timelines? There's some really incredible visions that I've seen many people put out there of what this could be and how we can truly go to that beautiful service-oriented architecture that we've literally been talking about for 30 years, with reasonable components and a marketplaces of pieces.

And I think all that's true. I think we actually are potentially positioned to make that happen.

CRAIG BOX: As long as we can still connect our "Zed" series to it.

OREN TEICH: Oh, what?

CRAIG BOX: Sorry, "Zee" series.

OREN TEICH: What's a Zee series?

CRAIG BOX: IBM mainframes.

OREN TEICH: Oh, oh, the mainframes. Yeah, yeah, yeah, exactly. So there is this huge vision. And it could happen lightning fast, right? Sometimes what seems like it could take forever could happen lightning fast, and I'm open to that and I'm trying to push that to happen. And it could take a decade, and I'm also being realistic enough to say, if it happens to take that long, we're going to push forward. That's fine. So be it.

CRAIG BOX: As a developer who's starting work on a project today, should I be looking for a platform that's powered by Knative? There are still people who care very much about-- it's a great development trait to care about the tooling.

OREN TEICH: Absolutely. Shall we have the Vim versus Emacs conversation now or later?

CRAIG BOX: Whenever you like.

OREN TEICH: Yeah, of course. We care very deeply about tooling. All the developers do. And it's really early days. I think if you're really bleeding edge, by all means, you can be in a situation where you're asking for and looking for Knative and diving in yourself.

Obviously, Google has products. Other people do too. But let's be honest-- it is early, and I think if you're listening, if you're thinking about, look, I have a workload I want to run, go to the best place you have to run it, right? Go to a cloud provider. Of course I'd love it to be me, but go to any cloud provider and pick the hosted product. It's going to be the best place.

Separately, if you're in there and you're like, no, I have existing Kubernetes cluster-- especially if I'm an operator, I have an existing Kubernetes cluster. I'm trying to provide this service to my users which is a model we hear all the time. Yes, this is exactly the right piece for you. Take a look at it. Embrace it. Use it because you can start to get down that path of giving your users a better experience.

CRAIG BOX: What comes next for Knative?

OREN TEICH: We're really excited to work with a lot more providers, a lot more companies that are out there. It's a very open ecosystem, and now that we've been able to make it open source, that we've been able to release it, it's something that we can much more easily collaborate on. And that was, in fact, our goal. If you look at the code today, it's early, and we could have had the choice of waiting a year, making it perfect and polished, and then releasing it.

But the flip side of that, of course, is it's private and it's not something that we can collaborate. Now it's early. That means we can collect feedback. We can work with customers. We can work with partners. And we can do that in the open, quickly, and user focused.

So what comes next? It's finding out those needs, working with the partners, hopefully getting a dozen more in there, and really growing this ecosystem.

ADAM GLICK: So if some of those customers or partners are listening to this, and they want to know how they can get more involved in it, where should they go to get more involved in the Knative project?

OREN TEICH: Of course, there's the GitHub repo, right, which is GitHub.com/Knative, K-N-A-T-I-V-E. The second place I'd say is, there are some things, like there's a Slack board, discussion groups, and so I'd encourage you to go to cloud.Google.com/Knative, which has links to those resources.

CRAIG BOX: Oren, thank you very much for joining us today.

OREN TEICH: Yeah, it was my pleasure. Thank you so much.

ADAM GLICK: Great to have you.

CRAIG BOX: You can find links to Knative and Oren in our show notes. It's our pleasure to bring the show to you every week. Thank you to everyone who has rated our show or tweeted about it. Please send your thoughts on Knative-- and our show in general-- to us on Twitter, @KubernetesPod, or drop us an email at kubernetespodcast@google.com.

ADAM GLICK: You can find the links to our show and past episodes at kubernetespodcast.com. Until next time, take care.

CRAIG BOX: See you next week.

[MUSIC PLAYING]