FRANCESC: Hi, and welcome to episode number 16 of the weekly Google Cloud Platform podcast. I am Francesc Campoy, and I'm here with my colleague, Mark. Hey, Mark Mandel.

MARK: Hey.

FRANCESC: Mark Mandel.

MARK: Yes, yes, that's my name. Hi.

FRANCESC: How are you doing?

MARK: I'm good. How are you doing?

FRANCESC: Pretty good, happy to be back to work on a Monday morning.

MARK: Oh, yeah.

FRANCESC: Yeah, but actually, very excited about the episode today. We're gonna have a lot of Kubernetes, Kubernetes, and more Kubernetes.

MARK: And a little bit of Kubernetes.

FRANCESC: Yup, and we actually have one of the Kubernetes people that everybody associates with Kubernetes, really, Kelsey Hightower.

MARK: Yes, very exciting.

FRANCESC: Yeah, he's actually one of our teammates in the developer advocacy group for Google Cloud Platform.

MARK: Yup.

FRANCESC: And he's gonna be talking about Kubernetes and especially about Kubernetes 1.2, the next version, so we're gonna be discussing what is it, what is coming, yeah.

MARK: And it has some super cool features that I get really excited about.

FRANCESC: Yup, I know. I--we normally--what we do is normally we record the intro afterwards, so we've just done the interview, and at some point Mark actually was basically jumping of happiness, so yeah, it's gonna be a very good interview.

MARK: Yup.

FRANCESC: And after that we're also gonna be talking about Kubernetes.

MARK: Yup.

FRANCESC: Actually, not only Kubernetes, but maybe you can explain a little bit?

MARK: Yeah, so we had a person who sent us a message on Reddit talking about having an app on App Engine and possibly migrating it to Kubernetes and Google Container Engine and sort of some pros and cons there, so we'll have a little discussion about that.

FRANCESC: Cool, so we'll discuss that at the end, but before that we have the cool thing of the week.

MARK: Yes, we do.

FRANCESC: And the cool thing of the week is something that you're going to be explaining 'cause you're very involved with this project, but apparently we have a Slack channel. We have Slack community, actually, for Google Cloud Platform.

MARK: Yes, we do. So--

FRANCESC: Tell us a little bit about it.

MARK: Excellent. So yeah, I was quite involved in getting this set up with a few other of our teammates, Sandeep and Ray and Julia. So if you're not familiar with Slack, Slack is a very popular chat for work application. It has all the usual chat features of channels and rooms and direct messaging and stuff, but it's become very, very popular. What we also noticed was that a lot of open source projects and language communities were already setting up sort of Slack teams for people to participate in. I know you're on the Gophers one.

FRANCESC: Yup.

MARK: I myself is also there.

FRANCESC: I'm in two Slack communities, Gophers and Google Cloud Platform.

MARK: I'm in eight.

FRANCESC: Oh, wow.

MARK: But yeah, we wanted a place for sort of--a chat place for people who use Google Cloud Platform to use it, and everyone was on Slack. It's a low barrier to entry. It's a really nice platform, looks very pretty too, so we created a Google Cloud Platform Slack community, so yeah, if you're interested in joining, it's bit.ly/gcp-slack. Link will be in the show notes.

FRANCESC: Exactly.

MARK: Please definitely come on down. We've got, obviously--like, we've got a general chat room, and we've got, you know, product-specific chat rooms. It's a mix of people, all right? So it's a community platform. It's public. Who knows? We have some Googlers, but we have a lot of, like, Google developer experts in there as well and just general users, and it really is just, like, a place for community to get together to help each other and really sort of get to know each other as well.

FRANCESC: Yeah, I've been part of the community for quite a while now, and I really like it 'cause it's one of the most welcoming communities I've seen in a very long time. Like, people really ask, like, beginner questions like, "Hey, I want to understand how the Datastore works," and people are really nice. Like, they point you to documentation. They will ask--they will answer any questions you have, so it's really, really cool.

MARK: Yup.

FRANCESC: And there's also one of the channels we have that are part of the community which I take very personally and I like very personally, which is the podcast channel.

MARK: Yes, we have a podcast channel there, so if you want to talk to Francesc and I directly, that is very true.

FRANCESC: Exactly, that's a very good way of doing it other than our many other ways of doing it which maybe we'll say at the end. Maybe not. Who knows? Yeah, so if you want to join, again, go to the show notes, and we're gonna have a link. It's bit.ly/gcp-slack.

MARK: Definitely, yeah, so I'd love to see you there.

FRANCESC: Yeah, and I guess that now it's time to welcome our teammate Kelsey.

MARK: Let's do it. Today I am very pleased to announce we have yet another special guest to the podcast. I'm very pleased to announce that we have Kelsey Hightower joining us to talk to us about Kubernetes today. How you doing today, Kelsey?

KELSEY: I'm doing fantastic. Any day's a good day if I get to talk about Kubernetes.

MARK: Excellent, excellent. Before we get stuck into Kubernetes, though, let's have a little bit of a conversation about you. I'm sure there are very few people who know who you are--who don't know who you are, I should say. That was--that was a terrible faux pas.

FRANCESC: [inaudible].

MARK: I'm sure there are very few people who don't know who you are, but do you want to give us a little background on you and who you are and what you do here at Google?

KELSEY: Yes, I'm Kelsey Hightower, as you guys mentioned, and I'm a very pragmatic technologist. I like things that work, less about the buzz and more about the practicality of doing things, so my background is mainly as a sysadmin. Maybe the last six years I kind of made the transition to being a developer. I've managed development teams, managed ops teams, and part of my career has grown into doing a lot of public speaking and advocating for things that work, which has me now here at Google pretty much doing the best of what I do around Google Cloud Platform and related technologies such as Kubernetes.

FRANCESC: Great, yeah, I remember the first time I saw you. That was--I think it was two years ago at GopherCon.

KELSEY: Ah, yes, that was the most epic talk of my life. You know, you're s--you're trying to do a Go talk in front of the Go team, and they're looking at all your slides for syntax errors. That is--that's not the funnest thing in the world.

FRANCESC: Yeah, that was an amazing talk though, really, really fun times.

MARK: Excellent, excellent. Okay, well, why don't we sort of dive right in? We're talking about Kubernetes. We have had Brian Dorsey on to talk about Kubernetes as well, but I'd love to get your take on it. Like, what is Kubernetes. What does it mean to you, you know, especially for the people who haven't listened to it or just want sort of an alternate perspective.

KELSEY: Yeah, so when I look at Kubernetes or when it first came out, the way I viewed Kubernetes was more of a collection of ideas that had been brewing from various angles in the industry in general, so outside of Google the perspective was everyone should be doing some form of automation, right? Whether it was Puppet, Chef, or Ansible, and all of those tools got a lot of people very far. I would claim that the abstractions were wrong. You know, we were basically wrapping, you know, automation tools around low-level things that were never designed to work together like SSH and package managers. You can script those things, but there were just so many abstractions we were dealing with, and then when you look at Kubernetes, it looks like over time some of the best practices that people have been doing on the outside world, of course, mixed with a lot of things that Google has been doing internally really just streamlines all of that stuff, so if you look at it, Kubernetes, to me, just looks like a checkpoint in where we are with automation today, right? It's becoming the--I think it will become the new baseline for how people do things going forward, and I think it's going to be a new set of abstractions, so I don't see Kubernetes as the end game. I kind of see it as the next level that people will be automating against, a new set of primitives, new set of abstractions.

MARK: Cool. All right, so let's maybe even take it to a higher level. If I'm a new user, I've never heard of Kubernetes, I don't know what it is, I don't know what it does, how would you--how would you give me the 30,000-foot view of what that looks like?

KELSEY: I think when you talk about Kubernetes you start with the application, right? So with config management and other tools, you start with the server and you kind of build it up from there. I think with Kubernetes we assume that Kubernetes is installed and that you have a set of APIs for deploying your app, so once you focus on your app, then we start to push some barriers like, hey, how do you package that app? The abstraction we use is containers, so you're gonna wrap your app in a container. Once you have it in a container, then you're just going to express how you need it to run. How many copies does it need to do? You know, what zones does it need to run in? And some basic high-level networking things, how do people hit your application? That's the goal of Kubernetes. Start with the app, end with the app.

MARK: Awesome. So you seem to be involved with the Kubernetes project for quite a while now. I--from my history from seeing you speak, it seems like you've been doing it forever. How did you get involved with Kubernetes? What's the history there?

KELSEY: Ah, the history of Kubernetes is pretty interesting, actually. So at the time I was working at CoreOS, and at CoreOS we were building what we like to describe as Google's infrastructure for everyone else, and that's a tall order just because no one has Google infrastructure except for Google, but we did pretty good job of, like, delivering the whole OS that's focused on containers, and as we moved up the stack, we built a tool called Fleet, and Fleet used to talk to etcd, which etcd was a clone of another internal Google service, and Fleet was in its infancy at the time, I would say. It was definitely very high-level. You can get basic things done, and then one day we were all watching the DockerCon webcast where Brendan unveils Kubernetes basically to everyone, and at that point in time I just knew that was the way going forward, that things like Fleet and all the low-level kind of Docker scripty tools would be no match for that way of doing things, and I think that night I downloaded Kubernetes and no documentation and really figured out how to get it deployed and wrote one of the first, probably, outside of Google blog posts about Kubernetes. It was a full tutorial. You guys did a PR release which, you know, I think big companies do, and we did this nice little single-node Kubernetes how-to guide, and you guys got number two on Hacker News. We ended up at number one, so we were really--

MARK: Oh, nice.

FRANCESC: Nice.

KELSEY: We were really proud about that move. It was kind of a ninja move from the startups.

FRANCESC: I'm curious about--you mentioned that etcd was also part of this Google infrastructure for everyone else. What project could it be internally? Could you explain a little bit more about what etcd really is for people that has--have never heard about it?

KELSEY: Yeah, so etcd is basically a key-value pair storage server, and, you know, a lot of people kind of compare it to Redis, but, you know, I guess they were thinking about it the wrong way. Ideally, it's modeled after the Chubby paper, so it's an internal service Google uses that has stronger guarantees on consistency, so a lot of people do question, like, "Hey, why do I need such strong consistency when most applications don't really have that requirement?" but etcd provides, essentially, two things if you really think about it. It's a place to store your configurations, so ideally configurations would be a list of backends that a group of web servers need to know about, so ideally you want all of those web servers to agree on what the backends should be, right? Maybe they don't necessarily have the same list at the same time, but they should be guaranteed that if they all agree on a single point in time that they should have the same list of backends, right? So it's a configuration store, ideally for application configs, so etcd is not designed to store gigs and gigs of data, so I think early on people were storing image blobs in etcd, and--

MARK: Oh, no.

KELSEY: Yeah, they really--yeah, they really loved the high availability features of etcd which is rooted in a consensus algorithm called Raft. So Raft is really nice because it automates the membership, leader election, and failover, so this is very nice when you start to think in terms of data storage where it's really painful to set up a cluster of databases and then handle adding and removing nodes. Things like etcd that rely on Raft pretty much automate most of that process for you, so of course everyone wants to use it for everything.

FRANCESC: [inaudible] and I don't know. I might be wrong, but is Kubernetes based on etcd? Is it using it somewhere?

KELSEY: Yeah, so that was one nice thing about when Kubernetes came out. It relied on a couple of kind of leading projects, so it picked Docker for its container at runtime instead of Google shipping their own, and it also leveraged etcd, so all of those pressables we just talked about were a perfect fit for running a cluster manager like Kubernetes, and it really gave people that feel that they were getting something really close to what we have internally, Borg or--and Chubby, that combination just goes together, and now we have an open source combination as well.

FRANCESC: That is very cool. So you mentioned that--yeah, so Kubernetes, when it was created, it was built on top of etcd and Docker, but you were working on CoreOS, right? And CoreOS also had this different format for containers, Rocket?

KELSEY: Yeah, so actually, Kubernetes came out before Rocket was released, actually, so when Kubernetes came out, you know, it was all built around Docker, and I would say at that time, you know, I think a lot of people were rallying behind Docker, and it definitely fit the bill. At CoreOS the drive for alternative container format probably started the--what we now call the container wars, but there's this idea that, you know, the container runtime should be super small and focused, and that container runtime that was built at CoreOS was definitely called Rocket, and Rocket was designed to pretty much work well with something like Kubernetes, right? So Rocket doesn't have a centralized daemon. We rely on something like Kubernetes for that. Rocket also has a concept of pods, so this was a new notion introduced by Kubernetes that in order to compose applications in a way that would be easy to schedule and manager, you would need to be able to put more than one container in a container that you could schedule atomically, so the idea is that many applications--I know sometimes I'll end up working with a Node.JS app, and it needs something like NGINX to sit on top, so pods could be kind of a easy way of putting those two things together and shipping them around, really gives people, like, that virtual machine feel, right? You can push these things out the same way you've been managing VMs in your infrastructure today.

FRANCESC: Very cool. So yeah, that gives a little bit of an idea of how Kubernetes came to be and what it really is, but if I wa--imagine that I'm creating my startup and I'm considering using Kubernetes or maybe other tools. What could be the other tools that I might consider, and why should I use Kubernetes and not something else?

KELSEY: Yeah, this comes up quite a bit, right? So I think--when I usually talk about Kubernetes, it's like, if you think Heroku's a good idea but it's a little too restrictive and you want to walk one step back so maybe you can have a little bit more choice on where you host it, what type of things you can run--so if I look at Kubernetes, I'd say it's maybe one or two steps below a PaaS. So if you're a startup looking to deploy your application and you really are not trying to build out a full ops team or deal with a ton of infrastructure, then Kubernetes kind of gives you the right set of APIs to say, "Hey, look, I don't mind packaging my things in containers, but I do want some flexibility over the runtimes," so things like Heroku would probably have some restrictions on what runtimes you could run or what libraries you could use, right? And we have the--kind of the same set of restrictions on the side of App Engine, right? So the idea there is that, you know, in order for us to do all the auto-magic behind the scenes, we do had to ha--we have to introduce some constraints, and those are shared multitenant platforms, so with Kubernetes, since you kind of run that on your own cluster of machines, it kind of gives you the flexibility to run it where you want. Even though our competitors do have the ability to run Kubernetes, it's a design goal of Kubernetes that you can run it on your laptop, your datacenter, or inside the cloud, and if you're a startup, that might be interesting to you, right? Maybe you get started on a Mac Mini in the office and decide to push it to the cloud later, and you have the flexibility of packaging anything you want, so if you want to, you know, have a bunch of security vulnerabilities running on a old version of Java, you totally can do that in Kubernetes. We do not force you down any path, but yeah, I think people like that. It's the flexibility.

MARK: That makes sense. That makes sense, and as--this is a leading question, but as someone who has spent much of the last little while setting up clusters of Kubernetes, where is your favorite place to get started with Kubernetes or getting it set up?

KELSEY: Pe--I--honestly, at this point, I just tell people, "You need to just click the GKE button." You know, it sounds like we're copping out here, but, you know, what I'm starting to understand is that a lot of people love this idea that Kubernetes is this open source project. It is a rare case that a cloud provider providers the same thing that they run and charge customers for as a free thing that they can download and run on their own gear, right? That's pretty amazing, so of course the first thing people want to do is deploy it themselves, and it's like, "Well, you know, you have to make a lot of decisions here, right?" So I'm not--I don't want to talk too bad about OpenStack, but I could never get OpenStack deployed, so there were a lot of moving pieces in OpenStack. I think Kubernetes is far easier to deploy than OpenStack is, mainly because we don't have to deal with the physical world underneath. We assume we have a node abstraction in place, but there's a lot to managing a cluster, and I think a lot of people that are interested in Kubernetes want to manage applications, so this is why I say, "Hey, look, cut your teeth on GKE. Learn the Kubernetes API, and then have that sit-down discussion where you talk about topology, where you want to run Kubernetes, do you want to run it on your own gear, maybe a different cloud provider, but I don't think the right way to get started with Kubernetes, in my opinion, if you're interested in deploying applications, is to go through all of the work of deciding how you want to deploy Kubernetes." So with that said, we do have kube-up, so there is a script for those that do want a single command. You can use it.

MARK: And by GKE, I just want to be clear for those people who are listening, that's Google Container Engine.

FRANCESC: Yeah, and we use GKE for two reasons. One is the C was already taken.

MARK: Yup.

FRANCESC: GCE is already Compute Engine, and then the K also stands for Kubernetes.

MARK: There you go.

FRANCESC: So yeah. I wanted to add that--on the fact that you mentioned that you can run Kubernetes basically anywhere you want, and for those that have not seen it, one of our teammates, Ray Tsang, created this really cool demo with--collaborating with someone in J-Focus where they were running Kubernetes in a datacenter made of five Raspberry Pis on a table, so that was pretty cool.

KELSEY: Yeah, I mean, I think that's the biggest selling point for people with Kubernetes, that we finally have, I would probably say, like, the first cloud OS 'cause what I think about what Kubernetes does is more than just deploying applications, right? It provides that nice abstraction over storage. It normalizes the cloud providers where you don't have to deal with the individual API calls. Once you get Kubernetes up and running, you can almost target that going forward.

MARK: That makes a lot of sense. I like that a lot. It sort of then becomes--it levels the playing field to a degree. It's like, who's gonna give the best Kubernetes experience, and really, then, just the consumer wins out of everyone.

KELSEY: But you know what? Since we're on this podcast, I think the most thing that I think when people start to look at Kubernetes, I hope that they see this as an opportunity to pay back some of that technical debt, you know what I mean? So a lot of people that have issues with adopting a platform like Kubernetes, like, having a automated scheduler that can move your application around at any point in the day by far is the biggest barrier, but it's only a barrier because a lot of people have built up so much technical debt on assuming that applications only get deployed to specific machines. If that machine goes down, people are running around wearing pagers and all of this, and I think this is probably the right time to sit down and say, "Look, there's limit--there's small amounts of things we could do to make our apps fit really well in this world," and I think a lot of people use the word "legacy" as a barrier to say, "Hey, we can't use this new stuff because we have these legacy apps," and the truth is I think it's really simple for people to make small changes either to log the standard out, you know, retry database connections before segfaulting. Things like that you can easily do in these applications, regardless of when you wrote them, that will make them a much better fit for running in something like Kubernetes.

FRANCESC: Very cool. Before we move to the next topic, I wanted to know a little bit more about how does logging work? Like, you mentioned that rather than segfaulting or just logging your--like, just failing, your program should log something. Is there some specific library that people should use or it's just, like, logging to standard error and just hope for the best?

KELSEY: Yeah, so Kubernetes, like, you know--I guess, you know, Heroku probably set the stage for this as, you know, part of the team at Heroku wrote the 12-factor manifesto, and it was this idea that when you're dealing with a more capable platform, you don't necessarily need to write to your own log files mainly because the files--you know, there's no guarantee that you will even have access to write to the disks, and it also reduces where we can run containers and how we restrict them, so the idea with logging is that we follow some of the things that you see in the 12-factor manifesto. I think it's, like, 12factor.net. It talks about logging, and the simplest thing you can do and the best practice is just simply log to standard out, so pretty much no special libraries needed, no syslog libraries. You don't need to really deal with integrating with, like, elastic search or any of those things. All you really need to do is log to standard out and allow the platform to aggregate those logs and send them to a central source or provide the structuring required to query them later, so that's the nice thing about this new movement around 12-factor-style applications, standard out.

FRANCESC: Yeah, that is very cool. So I think that we should talk a little bit about one of the reasons why we have you in the podcast today, which is not only because you're awesome but also because the next version of Kubernetes, Kubernetes 1.2, it's gonna be released very soon, so could you tell us a little bit about it? What is coming on?

KELSEY: So I think Kubernetes really represents what happens when an open source project gets popular, right? You start to get a lot more contributors. You start to get people running it in production, and the details that come out of that is what 1.2 represents, right? So there's been a lot of work on improving the way we do deployments. So in Kubernetes everything is modeled with a object, so if you want to have a service, if you want to deploy a set of containers, they all have their own API object that describes them, so one of the patterns that we saw a lot of people really engaged in with Kubernetes was things like rolling updates and this idea of describing, you know, something that can be scaled easily using what we call a replication controller, which was a babysitter over a set of containers, so what we did with that particular pattern is we introduced this deployment object. So deployments become this first-class thing in Kubernetes 1.2 that will allow you to kind of describe your update policy, your scaling requirements all in a single object, and that single object will basically abstract a lot of lower-level things from people and be much easier to work with. So Kubernetes also introduces the config map. So a lot of things we saw a lot of people doing in Kubernetes 1.1 and 1.0 was using what we call secrets. So secrets was a way to store configuration key-values and present them to the application at runtime. They were designed for secrets, but since that was the only mechanism to do late binding of configuration in applications, we introduced this thing called config map, which was really designed to allow the application to be notified when there's changes, so if you use config maps instead of secrets, very similar APIs, you can store not only key-value pairs, but you can expose them as environment variables or files on disks and also notify the actual machine that the configuration has changed, so those are the kind of two big things that I like.

MARK: That's awesome! I haven't--I haven't been keeping as up-to-date with Kubernetes as I should be, and the fact that you can do config maps and environment variables was a huge pain point for me, so I'm super happy to hear that.

KELSEY: Oh, and also the tooling, so, you know, some of the small things a lot of people don’t talk about is the tooling has improved greatly, so now, you know, I'll walk you through what it took to create a secret before. You used to have to base 64 encode some file into a key-value, but now you can actually automate that on the command line, so you can run kubectl, create secrets, name the secret, and then dash-dash from file, and would do all those things for you and store them as the file name automatically, and all you have to do is reference that file name when you reference the secrets in your pod manifest, so that should just cut down just on a ton of work for end users.

FRANCESC: Nice.

MARK: That just made me so happy.

KELSEY: I think Mark ov--I think Mark over here's smiling big-time, and I think a lot of people…

FRANCESC: Yeah, yeah, yeah.

KELSEY: Will too because all these--a lot of these features are just straight-up removing friction.

MARK: Yup. That's phenomenal.

FRANCESC: Yeah, that is great. I was a little bit curious about how is Kubernetes managed, meaning that these features that have been added are, like, clearly something that the community wanted or at least Mark wanted. Is it really community management? What do I do if I want something to be added to the community--added to the--to Kubernetes? Do I file a bug?

KELSEY: Yeah, so the nice thing about Kubernetes, it's completely run on GitHub, so it's one of the rare projects where the issues and the code are all managed on GitHub, so we basically follow, you know, the standard workflow that most projects hosted on GitHub follow. If you want something changed, you can open a issue, and we're not very strict on how much detail you need to put in that issue. You know, people on the Kubernetes community will do a lot of work reproducing your issue or, you know, giving a response, but if you want to add a new feature, you start with an issue. You know, someone will either search the other issues that are open to see if that feature is already slated to go. We do keep a public roadmap of milestones, so, you know, we're already actively planning 1.3. I think some few issues have already been tagged, and then we collaborate with the user, so if you submitted something, we do solicit help, so we do welcome code contributions. There are people--help review your code. There's also lots of collaboration from companies like Huawei and Red Hat and CoreOS. You know, those three companies are doing a lot with their users to satisfy those requests, so it's very much a collaborative project. You pop over to GitHub, and, you know, we make things happen.

MARK: Awesome. That sounds--sounds pretty egalitarian. So we're slowly running out of time here a little bit. [inaudible] a couple of final questions for you. I want to ask what's the coolest thing you've seen somebody build on Kubernetes?

KELSEY: The coolest thing I've seen someone build on Kubernetes was probably about a year ago. I was giving a Kubernetes workshop in Portland, and there was a company locally in town, Jive Software, and they showed up, and they were like, "Let us show you our demo," and they showed me this dashboard, and the dashboard was pretty clean. I mean, they were using every single Kubernetes feature at the time including things like secrets, so what you could do on their platform was you could kick off a three-tier application, and when you deployed the database, it would automatically generate its own secret and store it in Kubernetes, and the web applications would wait for that secret to show up and then use that secret to connect to the database, so, you know, they basically built their own kind of platform that would automate the thing like creation of data stores and passwords without a human intervention. I thought that was really clever because, you know, they did that with very little--you know, no permission from the Kubernetes team, but the APIs were just awesome enough for them to pull it off, so, you know, it was a nice little web UI. I figured, "Man, I wish that was an open source project," so that was pretty--that was pretty cool.

MARK: That does sound pretty cool. Awesome, and as a final question, is there anything here you want to mention that we haven't had a chance to mention yet? I'm sure there's a lot we could talk about, but.

KELSEY: I think a lot of people--when it comes to Kubernetes, I want people to understand that it's not a PaaS. You know, it's not a platform as a service. It's very much a--I like to think of it as a scripting and an environment for developers and sysadmins, so if you want to have your perfect platform, I think Kubernetes is the perfect place to start. You should feel comfortable building your own tools, your own deployment workflows, your own schedulers. You know, Kubernetes is designed to have multiple schedulers. We do ship one out of the box, but you see a lot of robust schedulers coming from companies like Univa with their Grid Engine. You know, you'll see a lot more coming down the pike, but think of it as an open platform for the modern age. Anything you can think of automating, consider doing that on top of Kubernetes and our rich set of APIs.

FRANCESC: Very cool. Well, thank you so much for being here with us today. I learned a lot. I'm actually very excited about the new version. I've used Kubernetes a little bit but probably not enough to be as excited as Mark was about config maps, but I'm sure that lots of people are gonna be excited and gonna be--are gonna appreciate your help, so thank you so much.

KELSEY: Awesome.

MARK: Thanks a lot, Kelsey.

FRANCESC: So thank you so much, Kelsey, for an amazing interview. I learned, personally, a lot, and I know I'm very excited about most of the new features coming.

MARK: I totally can't wait to play with config maps.

FRANCESC: Yeah, you were--

MARK: I'm very excited.

FRANCESC: You were really excited about it. It's a pity we're not recording this 'cause he was literally jumping. So anyway, before we finish we have our question of the week, and I think that you saw that question first, so I'm gonna let you explain what the question is.

MARK: Sure, so it's--the user on Reddit is prebenl. Thank you so much for providing us this question, which is great. Thank you so much for that. I think it's actually quite interesting. So the question is, "Hi, I'm very excited about Google Container Engine and think it would suit some of my projects well. One thing stopping us from moving away from App Engine is that we depend on the search or indexing API, and as far as I can see there's no external API available for that yet. I can't find any information about it, but are there any plans to open this service up to applications residing outside of App Engine like you did with Cloud Datastore?"

FRANCESC: Cool, that's actually a very--a very good question.

MARK: Yup.

FRANCESC: Unfortunately, one of the things that--the first part of the answer is going to be we cannot really discuss roadmaps.

MARK: No.

FRANCESC: So we cannot say if it's--if it is coming or not, but regardless of that API being available or not in the future outside of App Engine, something that could be interesting to consider is, well, why do you really need to move from App Engine to Compute Engine--sorry, to Container Engine? And do you really need to? And if you need to, you know, it's not a 100% thing that you need to move completely, so what do you think?

MARK: So yeah, we were talking about this a bit before, and I think it's a completely valid point. It's not a--you don't have to lift and shift, which seems to be a very particular term that comes up a lot now, but you don't have to take your whole thing. There's a couple of ways you could kind of go about this. Like, for one instance, if you needed to, you could just expose the parts that use your search API through App Engine as a REST endpoint or something similar and access it that way, and then if you needed to access that from Container Engine, for example, that'd be pretty easy to do. It's all inside Google's network, super fast, yay. You could totally do that, but, you know, if you don't want to or don't really need to move your application off App Engine, it's working well, there's no real reason to but you need, say, maybe the power or the flexibility of Container Engine for something specific, again, you could just move that particular part to Container Engine, maybe expose that as a REST endpoint or something similar, leverage it that way.

FRANCESC: Yeah, I totally agree, and actually, my first reaction, if I had something that is already running and being successful on App Engine and I had something that for some reason like I want to use some specific library like FFmpeg or something that will not run on App Engine, my first move could be consider managed VMs.

MARK: Yeah.

FRANCESC: So if that's the reason why you're thinking about moving to Kubernetes, probably I could consider managed VMs first just because it's gonna be really easy for you to migrate.

MARK: Yup.

FRANCESC: If you actually want to move to Kubernetes for other reasons like because it's really cool, which it is, what I could consider is exactly what Mark said. What depends really on the search en--the search API, the search or indexing API could be kept as a simple REST API.

MARK: Yeah.

FRANCESC: So something really simple that you have just running there and it just being accessed as a external service from your Kubernetes cluster. So yeah, I think that that's actually a pretty good idea. Like, we are not--like, Container Engine and Compute Engine--no, yeah, Container Engine, Compute Engine, App Engine, managed VMs and so on, we talked about it during one of the first episodes, about how it's a continuum, and it's not only about the fact that you have to be in one of those ranges of how much freedom or how much management you want to have, but it's also you can just pick and choose for every single one of the parts of your system and just spread it all over that continuum.

MARK: Yeah, this is about finding the right tool for the right job, finding, you know, the thing that's gonna fit well for what you need to do.

FRANCESC: Yup. So yeah, and if we didn't answer your question correctly because you wanted to know something specifically, feel free to send another message. We love your messages.

MARK: We love receiving messages, and thank you to everyone who listens, and thank you, everyone who participates. We really do appreciate it.

FRANCESC: Yup. Okay, so I think that it's time to go again, so where you are be--where are you going to be next week, Mark?

MARK: Next week, oh, my God, I just started freaking out. So next week I will be at GDC. I'll be at the Game Developers Conference. Super excited about that. If you're gonna be there, we'll be doing a developer day on day one. I'll be hosting a roundtable or two there talking about how you can use Cloud--sort of in a discussion, how you can use Cloud to basically do interesting things with your game, how can it really change the game you're building? And also we'll be down at the Google booth, the Google Cloud Platform section of the Google booth. I'll be there probably most of the time, so please definitely drop by. Would love to talk to you about game development in the cloud.

FRANCESC: Nice.

MARK: And yourself?

FRANCESC: Well, yeah, if you're freaking out, I don't know how to describe how I feeling right now, but I will be in Austin at the beginning of the week until the end of South by Southwest. We're gonna be running a bunch of parties and events and lots of fun and lots of work also in the Fiber space, so if you're around Austin, come say hi. Very happy to share our demos. Actually, we're gonna have a couple really cool demos. Cloud Spin's gonna be there.

MARK: Nice. We'll have Cloud Spin too.

FRANCESC: Yeah, we're gonna also have a very cool demo that we have not spoken about it yet I think, which is the Vision bot.

MARK: Vision bot, ooh we should talk about that.

FRANCESC: We should talk about that. We should have--yeah, we should have Caz maybe and interview him about the demo.

MARK: Sounds good.

FRANCESC: And after that I will probably at GDC helping you.

MARK: Yup.

FRANCESC: But also I'll be at DroidCon, which is at the same time, also trying to help other people.

MARK: Oh, my God.

FRANCESC: And then on Saturday 19th we're actually running a training session on Google Cloud Platform, so it's CP 100, and it's gonna be down in Mountain View for the Silicon Valley iOS meetup.

MARK: Okay, you win.

FRANCESC: Yeah.

MARK: You win.

FRANCESC: So yeah, that's gonna be--yeah, that's gonna be so--oh, my God, that's gonna be fun.

MARK: Yeah, yeah. Did you want to sleep? I don’t think you're--you're not allowed to sleep.

FRANCESC: Nah, nah, nah. I don't need it. So yeah, anyway, I think it's gonna be--it's gonna be fun. It's gonna be a fun week next week. So again, thank you, Mark, for being here and helping with this episode.

MARK: Thank you to you as well.

FRANCESC: And thank you to our listeners to be so many of them. Apparently, yeah, we started to have a decent amount of listeners, but we're not getting enough messages in my opinion, so please send us more messages.

MARK: Definitely.

FRANCESC: What you like, what you don't like, what do you want us to talk about.

MARK: Yup, either via email, via Reddit, via Google+, or even by the Slack channel.

FRANCESC: Or Twitter or yeah, many, many ways to contact us. Anyway, thank you so much.

MARK: Thank you.

FRANCESC: And talk to you next week.

MARK: See you next week.