Unikernels with John Feminella

MARK: Hey, Francesc. How are you doing?

FRANCESC: Pretty good. Pretty good. Enjoying GOTO in Chicago.

MARK: Ooh, fancy. How's that going?

FRANCESC: It's surprisingly hot, but the conference is amazing. Very good talks. I just came out from a talk by Sam Newman on microservices and why--he basically had a slide saying that Go is the best language you can use. So I'm pretty happy.

MARK: That would make you happy, yes.

FRANCESC: Yep. So today we're gonna be talking about something slightly related to microservices.

MARK: Yeah, we're gonna have an interesting conversation with John Feminella. There we go. That's fun. We're gonna talk about unikernels.

FRANCESC: Yep, so basically, what are unikernels? Why could you even care about them? How do you use them? What are the current solutions, technical solutions, that are available already to run unikernels? And also how to run them on Google Cloud Platform.

MARK: Yeah, so that's a pretty cool and interesting thing. And then, towards the end, it's back to my little pet project, Deployment Manager. We have a really interesting question around that as well.

FRANCESC: Yeah, I like it 'cause it's basically how to do Deployment Manager without doing Deployment Manager which is perfect. I really like it.

MARK: Excellent. Well, before we get into those two things, why don't we have a quick chat about the cool thing of the week, and we've got a few things given that, you know, Google I/O was last week.

FRANCESC: Yeah, there were a lot of very interesting announcements at Google I/O, but out of all the ones related to Google Cloud, by far my favorite one is the new version of Firebase.

MARK: Yeah, this is pretty awesome. We've gone from having a few really interesting services with Firebase to having lots of really interesting services with Firebase. It's pretty amazing.

FRANCESC: Yeah, and [inaudible] keep on having that free tier after 100 concurrent users which is actually more than any of my [inaudible] have ever got. So I'm very, very, very happy with that. But on top of that, I don't have the list in front of me, but there was analytics. There was storage. What else?

MARK: So there's analytics. There's storage. So with Google--integration with Google Cloud Storage. It's just a really nice veneer over the top. We've got remote config for doing, like, experiments. Being able to do, like, like, sort of, key value pairs. What other stuff have we got in there? There's so many good things. There's even, like, little things like handy little tweaks to how you can update data within the real-time database. All sorts of good stuff.

FRANCESC: Nice. So, yeah. We'll have a link on the show notes to the communication of the new Firebase so you can check it out.

MARK: Absolutely, and we'll have links to all the Firebase sessions that are available currently from I/O. There's a whole bunch, and most of them will be up currently. Although, I know there's still a few coming in as late stragglers.

FRANCESC: Actually, not only the ones related to Firebase, but all the Google Cloud Platform talks that were there at Google I/O. 'Cause I know that you spoke about Firebase, but I spoke about something else. I spoke about Google Cloud Spin, and we'll also have a link to that talk.

MARK: Yep. Yep, yep, yep. Yeah, mine's a little delayed due to some minor technical issues, but hopefully it should be up there fairly soon.

FRANCESC: Well, and also something that I really enjoyed was if anyone had the chance to go to Google I/O, they might have seen that there was some really cool demos in the Cloud tent. There was the same two demos that we had at GCP Next, so Query It! and the GCP Emotobooth, which are both really, really cool, developed by Instrument.

MARK: Yeah, so if you're interested in seeing some applications of BigQuery, or possibly some applications of Cloud Vision API, you can dig into that code and see what it is that they did to make the magic happen.

FRANCESC: Yeah, so we had those demos at GCP Next and Google I/O, and now, those demos are open sourced. All the code, you can find it on GitHub. So github.com/instrument, but we'll have the two links to the repos on the show notes too.

MARK: Absolutely. So if you want to build Emotobooth in your house for, like, your next party. You can totally do that now.

FRANCESC: That is actually totally a good idea, and I'm seriously--

MARK: You totally thought about it, didn't you?

FRANCESC: I'm seriously considering doing that for my--for my next party. Cool. So I think it's time to go talk with our friend John Feminella about unikernels.

MARK: Yeah, let's go talk about unikernels.

FRANCESC: So I'm very happy to welcome John Feminella to the Google Cloud Platform podcast. Hey, John. How are you doing?

JOHN: Pretty good. How 'bout you guys?

FRANCESC: Doing great.

MARK: Pretty well.

FRANCESC: So yeah, I'm actually very excited to have you here 'cause I saw your talk at Container Camp a couple weeks ago on unikernels. And I thought it was a very good introduction into unikernels, explaining why and how and all of those things. So I decided that it was--it was a very good idea to have you here. But before we start talking about unikernels, why don't you tell us a little bit about yourself.

JOHN: Sure. So you already know my name. I'm John Feminella. Most of what I do on a day-to-day basis is to work with a wonderful company called Pivotal, and most of what I do at Pivotal is to work with a product called Pivotal Cloud Foundry where I serve as sort of a technical advisor for companies that are interested in taking a look at how they modernize the way they do enterprise software development. So, you know, there's a lot of really big banks and hospitals and other major institutions, large and small, that have an idea of how they build software but maybe that idea hasn't necessarily kept pace with the best practices of how you deploy software in a modern, cloud-based environment. So we try to help them with that, with Pivotal Cloud Foundry, and my job is to, kind of, go from, you know, this idealized version of the way that software gets built and help them apply that to their own--their own enterprises and make them better and more efficient at developing software and delivering it.

FRANCESC: Cool, and how did you get involved with unikernels? Could you tell us a little bit about the story of how you doing this kind of software, Cloud software, ends up doing a talk about unikernels at Container Camp?

JOHN: Sure. Yeah, so I--you'll often see me giving talks about things that I have basically no affiliation with but I find incredibly interesting in some way, and unikernels is one of the topics that's very squarely in that category. So I'm--I certainly haven't done any academic research in the unikernel space, which a lot of where the genesis of where we're seeing the interest in unikernels come from, is very much a academic idea to start with that, kind of, got gradually evolved into a industry exploration that's now going on. So we're--there haven't been many--there haven't been many practical examples of unikernels until, I would say, relatively recently in computing history, and that, sort of, is what drew my attention to it first, was the academic side of the thing. In January 2014, there was a publication made in a magazine called Communications of the ACM, and CACM is, sort of, a--it's halfway between a formal journal and, like, a gossip magazine for computer scientists. And [inaudible] probably--I hope there are no CACM board members on here 'cause they'd be very mad at that description. But it's basically a--it's kind of a way to get really interesting ideas out in front of a large audience without necessarily requiring the rigor of a--of a formal academic paper that you might submit to a more--a larger journal. And I love CACM for that reason. 'Cause it's a great bridge from academia to, kind of, describe what they're working on, and for industry folks to, kind of, hear about what's happening and up and coming, and so there was a paper published in January 2014 called "Unikernels: The rise of the virtual library operating system." Written by an--David J. Scott is one of the authors, and I'm probably gonna mispronounce his name, but the other author is Anil Madhavapeddy, and both of them were talking about how this new way of consolidating machine images and computing resources, and to, sort of, this discrete single thing, in a very specific tailored way, could yield enormous benefits. And that was very interesting to me because that's almost the same claim that was made for the advantages for containers, and when containers were announced--or, not announced. When containers were being developed over the last decade or couple of decades, as a technology, that was one of the claims that the proponents of containers often pointed to was, like, there's this, sort of, advantages to consolidating and minimizing the surface area of what you're actually delivering to a production system. And unikernels seems to be something of an extension of that idea, at least on the surface. And that's very interesting to me because as someone who works a lot with Cloud computing, and working with these enterprises who deliver software in the Cloud, I'm very interested in what the correct or what the interesting new ways of deploying software in large-scale environments, in a reliable, consistent, and repeatable way. What that looks like in different--through different strategies, and unikernels definitely represents a new point in the spectrum that I don't think is really--has really existed before. So it's a new, sort of, tool in our toolbox that's evolving over time.

FRANCESC: Cool. So before we start talking about the advantages or disadvantages of unikernels, why don't you tell us a little bit about what is a unikernel, specifically from the point of view of someone that, like me, knows Docker but that's pretty much it.

JOHN: Sure. So if you know about Docker, you probably know that the way that Docker is able to deliver some of the isolation advantages that it has is because there are specific hooks inside of your kernel that allow a machine that's running Docker to guarantee those isolation properties. So your kernel is, in some sense, aware of this, and it's providing those benefits for you. In older, more traditional style, isolation through virtual machines, the way that you get isolation is by running an entire new OS stack on top of your existing OS and existing services and libraries. So you're basically--you're repeating all the work of building an OS, and with something like Docker, or another containerization technology, you're removing the need to have, kind of, a big, heavy kernel in there, and you, kind of, just have lightweight hooks into your real running kernel, and then you get performance advantages by not having to make--by not having to virtualize those calls across as many layers as a virtual machine has to. And unikernels go one step farther. And unikernels are based on the observation that if you have--if you have a kernel and you have an OS in the form of additional services and libraries on top of the kernel that are made available to applications. If you have that, you--it's pretty--you pretty quickly reach the conclusion that, "Well, not every application running on top of that stack needs everything that's in the whole OS and in the whole kernel." Right? So your web browser probably doesn't need--it probably needs a lot of the kernel, but it probably doesn't necessarily need things like, you know, access to your serial port, or whatever. And so any--and that's true for many different kinds of applications. They don't need access to the entire kernel. So unikernels are a way of saying, "Well, what if we didn't need to have the whole kernel around, and the whole OS around, for an application? What if we could just take the pieces that are relevant to an application, and what if we could run it that way? What if we could, sort of, only expose, or make available to the application, the parts that it really depends on? And if we can do that, then maybe we can shift that entire dependency stack as a single, consolidated machine image. And then, just like we can run Docker containers containing images, we should be able to run a, sort of, a container around this consolidated machine image." But because that image is effectively an entire operating system in a bottle, you could run that on bare metal or on hypervisor, or whatever. So there's a lot--and also because it's so much smaller, there's, you know, we expect to see certain benefits around, like, maybe it's quicker to start those things up than it would be to start a container or a virtual machine and so on. So once you start thinking about, "How can we shrink the set of stuff you actually need to only the dependencies required by a process or an application?" It starts really motivating some interesting thought patterns around how we're gonna design those applications, what kinds of applications are really well suited for this and which ones aren't, and so on. So it really opens up a new space to think about how to deliver and deploy and maybe even design our applications to take advantage of that.

MARK: Cool. So that sounds really interesting. But from a practical point of view, how do I, like, run a unikernel? How do I build a unikernel? What--is there tooling available? Like, I'm obviously familiar with, sort of, containers. I can, sort of, put those in the Cloud. But if I want to--do I need to run each on an individual machine? How does that work?

JOHN: Sure. So there are--again, this is still very much an evolving space, but there are many different--right now, we're sort of in this meritocracy phase of--where everyone's trying to do a bunch of different projects, and we're trying to figure out, like, what are the best approaches. And that's still very much an evolving idea. So there have been a couple of attempts to consolidate these ideas into one location where people can play around with them, but there hasn't been much consolidation that I've seen in the way of projects. So people are still, kind of, independently exploring many different ideas. And to get a taste of the many different ways to get started with unikernels, I would recommend that folks check out a website called unikernel.org, and this is the work of a couple of people, including Amir Chaudhry, who is formerly at Unikernel Systems and is now with Docker, and he's done a great job of, kind of, collecting these different projects into a single place and giving you a really broad exposure to the many different kinds of ways that you could actually build a unikernel. I will say that, broadly speaking, there are two basic strategies. You either start with an application that is--that exists, or you're--or you're willing to start from scratch to build some service or whatever. If you're starting from an application that already exists, you probably have a POSIX-compatible application. And if that's true, then you can use something called RumpRun which is a way of taking your--basically, a Rump kernel is a special flavor of unikernel where basically, you can build the software stack you need for your application without having to build all the individual pieces yourself. So for example, if you--if you don't want all the overhead of an OS, you still may need drivers to actually run that OS. So for example, your web application probably needs access to TCP/IP, protocol stacks, and things like that. So you still need these pieces to run your application, and a Rump kernel lets you assemble those pieces in a way that's POSIX compliant. But your application will still probably work. And so you can run--that's one way of minimizing what comes along for the ride with your application. So you wind up with a very compact image that then you can run on top of raw hardware or a cloud hypervisor, so KVM or Xen. You take this image and you would run it on top of Xen, let's say. So that's one strategy. The second strategy is you are willing to, sort of, start from scratch. So maybe you're just experimenting, for example, and there are language--what I'm gonna call, broadly, language-specific kernels, unikernels. So there are operating system stacks that require your application to be written in a very specific language. So for example, MirageOS is the--is what I would say is the canonical unikernel OS for OCaml at this point. So MirageOS has a bunch of libraries. You have your application. You say, "Hey, I depend on, you know, I need a networking stack." Or whatever, and the MirageOS compiler determines that, you know, what the set of libraries you need is and then compiles that into a machine image that you can then run, just like you did with the Rump kernel. You can run that machine image on top of Xen. Now, the extent to which each project supports this, or the levels of documentation and how easy it is to get started, vary really widely. I consider myself a relative OCaml novice, but I really liked MirageOS. I liked getting started with OCaml, and I built a really small web service that talks to a few different--it's just like a quote service so you can talk to Yahoo and get, like, the, you know, the stock price of a particular quote and things like that. So--but it was really easy to build, and it was very straightforward. So I've been liking MirageOS the most. That's not to say that the others aren't also great, but, you know, I only had so much time, and I didn't want to learn, like, 37 languages to try 37 different flavors of unikernel OSs. But that's the basic idea, is you, kind of, have some mechanism that turns your application into a compact machine image. And then, you run that compact machine image on a hypervisor of some kind that sits on top of your bare metal. And then, you're running your--you're running your unikernel at that point. So then it can receive requests on the internet or, you know, write you a database or whatever else it's supposed to be doing.

FRANCESC: Cool. So if I understand that correctly, does that mean that if I am running, for instance, a web server in, let's say, Go, 'cause I like Go, I could eventually, rather than building a binary that runs on LINUX, I could run--I could build a Linux, like, a unikernel that contains my app and all the libraries that it needs like DNS and all that stuff that it could need for web servers?

JOHN: Mm-hmm.

FRANCESC: But it could not include things, like, I don't know, like USBC controller or floppy disk controller, stuff like that.

JOHN: Sure. Right.

FRANCESC: Is that correct?

JOHN: Yes, right. So when you--now, normally the container that, like--like, if you're running on Alpine Linux, it probably--it saves a lot of space by omitting a lot of those kinds of firmware things that you aren't gonna need for a web application. You're already probably saving some space there by using just a small base image for something like a Docker container. But for your Go web application example, what you'd save over the Docker container are all the parts. You would literally be removing everything in the kernel that your application doesn't actually depend on. Like, when you use a--when you use a base image from someone else's Docker layer, you're basically saying, "I'm gonna use that because I know it's minimal." But there's no guarantee, from a compiler, or from something else, that there isn't stuff in there that you don't need, right? Like, you're still--there's no--there's no tool that's taking your application, analyzing it in some way, and saying, "Okay, here's what you actually depend on. here's the system calls you're making or whatever." And then arriving--and then compiling that unikernel. So you have to, sort of, I think the goal is that effectively you'd have a stronger guarantee about that thing that's the output of the compilation process being minimal in some--for some definition of minimal. That is, it's smaller to run. It's quicker to start up, and so on. So that's what I would say is--I think you're essentially right, but I think there's the key difference in that a computer is--a computer program is making the decision about what's going into your image as opposed to a human being saying, "I want this, and I want that, and I want this other thing."

MARK: Cool.

JOHN: That's sort of the, I would say, the fundamental distinction.

FRANCESC: So I could--I could say that it's basically the different between having just a binary with all the possible symbols of all the libraries that you are actually important to actually stripping the binary down to the objects that you are actually using, that your program is actually using. Is that it?

JOHN: Right. And I would say--I would say it goes one step farther, which is that your Go binary, when you deploy that, you run that as a process on an operating system. The equivalent thing on a unikernel is that you run that and it is the operating system. The only thing it knows how to do is run your web server. It can't, you know, it can't start up MySQL. It can't connect to Redis, or whatever. The only thing it knows how to do is run your process. It's a single, consolidated machine image. So it's like the kernel--it would be as though the Linux kernel was explicitly written to run your Go web server, or your Go web application, and nothing else. So you're just starting that thing, and then you're making a million copies of it, or whatever.

FRANCESC: So it could be, like, the Linux--the Linux that I could start, it could be a distribution that only includes my banner and my banner could be run as, like, process id zero, or whatever.

JOHN: Right.

FRANCESC: But it could be main process. Oh, interesting.

JOHN: Exactly. It's kind of like, if you're familiar with the privilege levels in traditional kernels, you may have heard of things like ring zero, ring one, ring two, ring three. So userland code in--usually executes as unprivileged. It lives in the top ring, and then, there are basically contact switches that happen into privileged mode and then that's how your kernel is able to do things with device drivers and rights-protected areas of memory and so on. With a unikernel operating system, your application/machine image is executing everything in privileged mode. Everything happens at a ring zero. There's no contact switches. There's no--there's no handing back and forth to userland code because there is no userland code. Everything is inside the kernel itself.

MARK: Cool. So does that mean that if I'm building myself a unikernel app, I need to understand how, like, the Linux kernel works at a low level so that I can tell it what drivers to put in and pull out? Or how is that process managed?

JOHN: Yeah, I mean, that's part of where the usability efforts I think are coming in. So first of all, it's not necessarily the case that you need quote unquote, like, a Linux kernel understanding, because there's so much modification happening to these unikernel OSs that some of them, like, if you looked at what the kernel code looks like, it would be unrecognizable compared to the Linux kernel code. Like, there's probably some basic ideas that are gonna be in every modern operating system. Like, you know, maybe the idea of, like, memory allocation and virtual memory, or things like that. So those ideas will probably have familiar implementations. But in terms of, like, looking at the code and, like, needing to understand what some constant means, or something like that. No, you don't really have to do any of that to get started. So like, with the MirageOS, for instance, you--I will say their documentation is very good. But basically, you effectively just write a OCaml application. And from your application's perspective, nothing really looks different. Like, it can't tell that it's running on a unikernel environment. You know, the MirageOS compiler is taking care of all the details of how that application is actually doing things. Because it's, sort of, using its own stack and its own kernel, its own OS, its own kernel OS and services on top of that OS, to make it--to make your application work in this environment. And that's great because it means that all the stuff that your application doesn't rely on is not part of the kernel to begin with. So you, again, save the extra heavyweight steps, or extra heavyweight bits, of the kernel that you are not using.

FRANCESC: Cool. So we almost running out of time. But there's a topic that I could not be happy leaving out which is what about people that say that unikernels are not fit for production?

JOHN: Sure. I mean, I think that that's maybe a little premature given that it--it's still relatively new area of not only development but I think also thought about, like, philosophy of how we're gonna use this. And I think it's--I think we don't want to be too quick to set aside a tool just because there may be some valid objections to it to begin with. You know, I think that probably containers were not ready for production in 2013 when--or I should say, Docker wasn't really ready for production in 2013, and Solomon Hikes and all the Docker people, like, vociferously said this multiple times throughout 2013, that it's not ready for production. But, you know, if you're brave and you want to experiment with it, you certainly can. And I think that's kind of the phase we're in now with unikernels, where this is really just starting to catch the attention of people. And there are many implementations. They're all trying to demonstrate that their version is a good one. And we're still waiting for the dust to settle a lot before we start getting into these more specific details of, like, how does debugging work in a unikernel environment? How does--how does tracing work? What's the right way to do that? How do you--how do you deploy these things? Are the kinds of applications that are suitable for unikernels maybe different than what we're imagining or what we think might be suitable? So there's a whole range of, I think, questions we can ask about unikernels that don't have answers right now, or that we're working on trying to figure--that the community is working on trying to figure out the answers for. So it's definitely still early days, and I certainly wouldn't be, like, you know, running my fortune 100 bank enterprise stuff on it, but I think it's absolutely worth taking a look at, keeping an eye on. Because chances are good that in 2018, when you guys have me on for the two-year anniversary of this podcast, you can ask me where have unikernels been in the last two years. And I bet my answer will be something like--it probably took the same path that containers did where there was gradual adoption, we realized that there was a specialized use case for this technology, and then we exploited that specialized use case to really get the benefits of the technology. Just like containers aren't suitable for all possible applications, unikernels won't be suitable for all possible applications. There will be some specific set of things that's really well-suited for unikernels and some things that aren't. And that's okay.

FRANCESC: Very interesting, and since you mentioned--you actually mentioned Amir Chaudhry from Docker.

JOHN: Yes.

FRANCESC: You also mentioned Docker. So I got to meet him during Craft Conf. We'll have a link to the slides of his talk were really interesting. But I'd be curious to know your opinion on why do you think Amir is now working for Docker. Meaning, why did Docker buy that unikernels company?

JOHN: Yeah, so first of all, I'll just say that I've never actually met Amir in person, but we've chatted a bunch over Google Hangout. So thanks, Google. But he is just, you know, clearly doing amazing things and is a brilliant person. And I, you know, I think that even if the company had zero value, it would probably be worth it to hire Amir and his team because, like, you can just--there's a certain set of people that if you talk to them, you just realize that whatever they're working on is probably gonna be amazing. And so I don't want to set Amir up for too much pressure, but I'm sure that whatever he's working on is gonna be great, and I look forward to seeing it. So I think if Docker hired them, it's probably because they saw what Amir and his team were capable of and what they were building and they wanted a piece of that. And I think it's probably fair to say that if Docker bought a company called Unikernel Systems, and the word unikernel is right in the name, than they're certainly exploring and/or actively using unikernels in a way that's probably ahead of the rest of the industry at this point. So I expect that if we--as we start seeing industry best practices come out of the operation of things like unikernels, I expect to hear a lot about Docker and what they're doing with it and, kind of, look to them as a role model for how we use unikernels.

FRANCESC: Well, I guess--I guess we have to wait 'til the second anniversary of this podcast to interview again and see--and see how much of that was your.

MARK: Yeah, go back in time. So we are running out of time a little bit, John, but is there anything that you would like to mention that you haven't had a chance to mention yet or a topic you want to cover real quick?

JOHN: Well, I would say that if folks are--as I said, one of the things that I'm very interested in is how businesses use platforms in their--in their deployment pipeline. Like, where do they see platforms coming in to play? And we've gradually been, you know, we've been very excited about containers. Then people realize, "Okay, well the orchestration of containers is a problem." So we have things like Kubernetes and other technologies that help us, like, manage those containers. But I still feel like there's something that is--that we should be thinking about as an industry in the workflow with respect to, you know, if you had a developer, a container, or a unikernel, or a virtual a machine, or something that's not their application, then they're still responsible for a lot of the--a lot of the stack, right? Like, they have to do a lot more things before it's actually running. And that's something that I want to see us as an industry move towards better tooling around how we manage containers and how we turn applications into, "It's running somewhere and I can, like, you know, hit it with an http request." And that, I think, is an area that's--that we need to pay more attention to and that we are sort of slowly evolving. Platforms are playing a role in that, but I--but I know that we're gonna see awesome things come out of Kubernetes and other technologies. So I'm trying to--I'm encouraging the listeners of this podcast to think about when you deploy an application, is your--is your next step, like, put this in a container or do you want this to be, "Hey, do something that puts this in a container for me so I don't have to worry about the details?" Like, that I think is a really interesting proposition. When I can get back to writing code instead of, you know, like, operationally managing 37 containers and clustering technologies and whatnot.

FRANCESC: Very good. Very interesting. I totally agree with that, actually. Well, thank you so much for taking the time to talk to us today.

JOHN: Cool. Yeah, thanks for having me.

FRANCESC: And talk to you in two years.

JOHN: Yeah, I'll see you on May 12, 2018.

MARK: Excellent. We'll book it in now.

FRANCESC: See ya.

JOHN: All right. Thanks, guys.

MARK: Thanks so much, John, for joining us on the podcast today. That was a really interesting and enlightening talk about unikernels. Something to keep an eye on for sure.

FRANCESC: Yeah, and we'll definitely have the link to the--to his talk at Container Camp. I think it was--it was a very good talk. So if you're curious about more detail on unikernels, it's probably a good resource to check out.

MARK: Absolutely. But let's talk about the question of the week. Francesc, you had a really interesting question, there.

FRANCESC: Yeah, so the question is regarding your pet--your pet peeve, your favorite project.

MARK: My favorite project.

FRANCESC: Yeah, Deployment Manager. And it's basically about--okay so, Deployment Manager, basically, what it allows you to do is, given a file that contains some description, it will create all the resources on your Google Cloud Platform project. And that is--that is cool, but is there any way you can create that file from what you already have? Meaning that you--via either the CLI or the web interface you created a bunch of, I don't know, [inaudible] instances and Cloud Storage buckets and whatever. And you want to, basically, create the corresponding Deployment Manager so then you can replicate that same infrastructure somewhere else.

MARK: So as of about 15 days ago, there's a beginning of doing exactly that. I would say it's definitely not, like, 100% there, but it's an open source project that sits within the Google Cloud Platform Deployment Manager samples repository where there's a genconfig Python script where you're able to point it, I think, primarily, right now, at GCE instances. But hopefully that will, sort of, grow from there and as we get issues and pull requests. And be able to get back a basic, sort of, ginger template that's able to be used with Deployment Manager. I think you'll have to tweak it a little bit, but it definitely does a lot of that bulk work for you. So that if you want to get started with Deployment Manager, you've already got some infrastructure, and you want to, basically, be able to either replicate that somewhere else or maybe modify it using Deployment Manager. This is a really great place to start.

FRANCESC: Yeah, that sounds really, like, a very good place to get your files started. And then from there, you're gonna see all the things that you're missing. And there's two things that you can do. One is add them to the file. The other one is send a pull request.

MARK: Yeah, absolutely. Yeah, so this is on GitHub right now. Links are in the show notes. So if you start using it, you find issues, definitely submit it back. We'd love to have input from the community.

FRANCESC: And I'm curious about one thing. In what language is it written? Oh, Python.

MARK: It's Python. Still Python.

FRANCESC: It's Python. Oh, well. Oh, well. I might still--I might still contribute to it. Cool. So before we finish, why don't you tell us, Mark, where--what are you gonna be doing in the next couple weeks?

MARK: So next week, third of June, here in the SF Google office, there is the gaming event we're having here, Change the Game. I'll be here for that. I'll be doing possibly one, one and a half, presentations. I'm presenting possibly a couple of times, depending on how things pan out. But that should be a really fun event. We're gonna have Googlers there to talk to people. If you're interested in game dev and you want to hear from both customers and Googlers and talk to, like, Google people about products, absolutely come down. I'm gonna be around all over the place after that. I'll be visiting GDG Twin Cities. I'll be at Open Source North. After that, I'll be at a conference Dev Objective. And then I think I'll be in New York later in the month for another gaming event. I haven't got all the details for that, either.

FRANCESC: Wow.

MARK: So bouncing around a bit. How 'bout yourself. Where are you off to?

FRANCESC: Not much. Just biking from San Francisco to Los Angeles, like one does. But that's pretty much it. After that, I'm relaxing until July where I will speak at GopherCon.

MARK: Very nice. Very, very nice. What are you speaking on at GopherCon?

FRANCESC: I'm talking about nothing, literally. I'm gonna be presenting. The name of the talk is Understanding Nil.

MARK: So it's basically the Seinfeld episode of GopherCon.

FRANCESC: Exactly. I--yeah, and it's gonna be the opening keynote. So I don't know how that's gonna go. I think it's gonna be fun. I will have fun, that's for sure.

MARK: It'll be fantastic. I expect big things.

FRANCESC: So before we finish this episode, there's one more topic that you are actually not ready to discuss, but I would like to bring it up, which is...

MARK: Uh-oh.

FRANCESC: Which is that amazing match that we had playing Query It! at Google I/O.

MARK: Oh, yes. Oh, yes.

FRANCESC: Yeah, I just wanted to make everybody know that I--basically, I destroyed you.

MARK: You won by, like, a thin margin. Like, a thin margin, and--

FRANCESC: Yeah, yeah, yeah.

MARK: Like, a little bit of luck.

FRANCESC: Anyway. Yeah, luck, obviously that's what you will say.

MARK: Yeah, you've been standing in front of that for, like, the whole day. You knew all the questions I think.

FRANCESC: It--that might be true. That might be true. A little bit of an advantage there.

MARK: Yes, that's how we settle battles here at Google. We play Query It!

FRANCESC: Yep. Using the big--the power of big data to settle battles.

MARK: Yep, exactly. So thank you so much for joining me yet again this week, Francesc. Always appreciate you taking the time.

FRANCESC: Thank you, Mark.

MARK: And thanks very much to all our listeners out there too. We really appreciate you coming and listening to us speak. We love having you listen and provide comments and do all that sort of good stuff too.

FRANCESC: Yep, and talk to you all next week.

MARK: See you next week.