 Live from the Julia Morgan ballroom in San Francisco, extracting the signal from the noise, it's the Cube, covering Structure 2015. Now your host, George Gilbert. This is George Gilbert, we're at Structure 2015, reborn and really healthy from the old gig on and we're pleased to welcome Alex Povey from CoreOS. Everyone seems to want to talk to Alex these days so we've got first aid. Alex, why don't you tell us a little bit about CoreOS and why it's of such relevance right now. Sure, so we started CoreOS a little over two years ago about two and a half years ago now and our mission is to fundamentally improve the security of the internet. And our approach in doing that is to help companies run infrastructure in this way that allows it to be much more serviceable and have much better security and so on. This way that we're modeling looks a lot like what we've seen from the hyperscale companies, folks like Google. So we often call it Google's infrastructure for everyone else. Giffy for short because that's kind of a mouthful. And that involves distributed systems, containers, and running on standard hardware which in 2015 can be a bare metal server or it can be an instance in AWS. Okay, so help us understand though that if CoreOS, it sounds like there's an operating system at the core. Is this like a cut-down version of Linux that gives it a small attack surface and sort of easier deployment and patching? Exactly. So in our quest to run the world servers to secure the internet, we started the lowest level component possible. There's the OS and then there's a distributed system aside. So CoreOS is our company name but it's also the name of the first product that we released, CoreOS Linux. CoreOS Linux is a lightweight container-based OS that automatically updates itself because we think that updates are the key to good security. So it's a combination of the updates, the container weight, the lightweight container-based sort of application model as well as just stripping everything else out. I mean the last 20 years of Linux distributions have created lots of crups so it was time to kind of reborn, you know, re-birth a new lightweight Linux OS. And now sticking to CoreOS for a moment, in an earlier era might we have called this like an embedded OS where you just sort of chopped out everything that was not necessary for the application? Yeah, it's very much inspired by embedded OSes. On servers, you know, you really want to get everything out of the way of the resources like the memory and CPU and so on so you get as much as you want out of it. So while it's a little bit counterintuitive, you have this really monster server. You still want as light and thin of an OS in there as you possibly can like an embedded OS so you can really maximize the performance. So something that abstracts the hardware but gets out of the way? Exactly. Just focus, get on the things that matter which is running your applications and managing the actual hardware and really nothing else. Okay, so presumably to provide Google's infrastructure for everyone else and I don't remember the acronym for that. Giffy. Okay. What other products did you have to fill out, you know, to make that possible? Sure, great question. So the next major piece that we released is a tool called EtsyD. It's meant for doing shared configuration among servers. Whenever you have a group of servers, the first thing you need to do is they all need to know about each other and tell each other about the configuration. This is load balancers knowing where the app servers are, the app servers knowing where the databases are and so on. And to do this in the most robust distributed systems way, you have to do this thing in computer science that's very difficult called consensus. Okay, consensus algorithms is an area of computing actually speaking about here a little bit with Eric Brewer who is a huge academic, a very well respected engineer in the area of consensus and distributed systems. And so we built EtsyD which solves this really hard distributed systems problem in a way that's usable by many operations teams. So let me just interrupt you for a second. Yeah. I mean, I've got this sound going off in my head that says ZooKeeper, ZooKeeper. Exactly. It's ZooKeeper for everyone else. ZooKeeper is really... To simplify. To simplify ZooKeeper and make it accessible. Our theory is that a lot of people wanted to use distributed systems but ZooKeeper is a little bit too difficult to use as well as really oriented towards the Java and Hadoop community and there's a whole wide array of other folks out there. So it couldn't make as many constraining assumptions as yours which would simplify. It just couldn't be as widely as adopted. And so we released EtsyD around the same time we released 4 of us Linux. At this point, there's been over a thousand projects if you go on GitHub that have built things around EtsyD. So our bet was right. Even things like Kubernetes itself has a hard dependency on EtsyD. Without EtsyD, Kubernetes will not run. So our hypothesis there was let's make the hardest parts of distributed systems easier and then we will see distributed systems overall accelerate and that is definitely what's happened with EtsyD. Okay so help us understand how you've built up the rest of the infrastructure and then where you'd like to see it go. Sure. So the thing that we're targeting is this distributed systems approach. And again we care about this a lot because we think that the ability to manage and service your applications is what is the key to security. Keeping things up to date. And when we meet up to date, we don't just mean like patch of the vulnerability of which we fix many of those but it's also about companies comfort rolling out a new version of their application that they won't break something. If you run your infrastructure in a distributed system, you can roll out a version. If it breaks a little bit of the application that's okay but you didn't take the whole thing down. And that's the kind of the safety net that distributed systems gives you. Does this require the sort of microservice approach where you know there's a clean separation between this new set of bits and the rest of the app? It really does. And that's why we've invested so heavily in containers. You know it requires a container. It also requires the distributed systems components of it. So we first built Corvus Linux, then we built EtsyD and then we started building some distributed systems work very early in the market. And then things like Kubernetes came along and we were like hey, instead of us going and reinventing all this stuff, let's partner up with the guys from Google for monitoring Google's infrastructure for everyone else. Let's partner up with the team at Google that built that and get their solution more widely adopted out in the world as well. So the whole platform comes together as this combination of Kubernetes, EtsyD, Corvus Linux. We have our own container runtime called Rocket, which we built primarily to address some security issues in Docker. And so all of these pieces come together. And what we call that that piece when they're all together is tectonic. Tectonic is our product that is that Google's infrastructure in a box. Okay, let me just drop down in the weeds for a sec. Derrick Collison calls... I'm sorry, I'm having a senior moment. And I hope it's not early onset Alzheimer's. But the Docker, he calls sort of this generation's car ball, you know, like to distribute, you know, just a sort of guess the equivalent of an execute ball. Are you providing something that's compatible? Or does the what's inside the container have to change to take advantage of the additional services, you know, that's sort of Google centric? Sure. So the packaging that tar ball piece, we're compatible with and will always remain compatible with. So even further the compatibility, we've put together standards around what that container should be. So many vendors can interoperate, you know, more, more widely done that first, the app container project, then more recently through the open container initiative, which is a joint effort between Docker and us and the rest of the ecosystem. And so we always, we always want the user to be able to package their application once and then choose whatever system they want to run it in. And the container is what really unlocks that portability. Okay. So then let me ask you, are just the Google Compute Engine folks, or the, where the past, the past group, do they view you as a way of priming the pump outside the Google ecosystem to get others using their sort of application model or their infrastructure model? Or because I'm trying to understand that, you know, Azure sort of has its own way of looking at the world. And, you know, Amazon has its own way of looking at the world. Are they looking at you as a way of sort of disseminating an approach to building applications or managing applications? Sure. So the Google team and their motivations behind Kubernetes, you know, you'd have to talk to them about it. My understanding is that, that they see that as a way to have a very consistent environment between different cloud providers and so on. It's, it is a next generation way of running infrastructure as well. This is just better than the previous way of running infrastructure. That's sort of the answer I was looking for, which is that they don't have to either give away their stuff or manage their infrastructure elsewhere. But you're, you're sort of the channel to deliver Google style infrastructure in other environments. So I think Google Cloud's motivation at the end of the day is selling cores and memory. They put all these other services on top of it to make it, you know, to make it more attractive to use. At the end of the day, anything that drives more usage of these products is how they, on their business. At least that's my perception of it. I am obviously not speaking on behalf of Google. So where are you in attracting, you know, showcase customers, guys who sort of said, okay, we'll bet, you know, it's not the entire business, we'll bet the success of this application or these set of applications on this. Right. So first, the technology has been very, very exciting. I mean, the past two years, we've seen, you know, this whole space explode in interest. But the discussion around how does this solve business problems? How does this actually get adopted in these companies? And what motivates them to actually do this outside of the tech being very cool? That's a discussion that is just getting started. In fact, in about two weeks here in early December in New York, we're hosting that discussion at an event called the Tech Tonic Summit. The Tech Tonic Summit is where we're bringing together all the enterprise early adopters that are using containers, using distributed systems, and talking about like, why did their management and their leadership decide to make investments on these technologies? And what we're seeing are use cases about multi data center between your physical data center and your cloud environments. We're seeing folks build their next generation web services. Many businesses that weren't traditionally in the web services business need to be now because of mobile, just modern product offerings. And so we're hearing, we're hearing from these large guys and how they're using our technologies and other companies technologies today to do this is just two weeks at our event. Would it be fair to say, I'm listening to this and what seems to be coming across is that your technology makes it easier to abstract, not just the machine which would be CoroS, but hybrid infrastructure. And it doesn't even have to be hybrid. It could be this data center and that data center or your own data center and a public, you know, cloud. That's one of the biggest value props of all this is the consistency between environments. We just give us compute CPUs, memory storage. We don't care if it's on cloud or if it's a physical data center. We can allow you to manage that in extremely consistent way. Okay. And not just between your data centers, but also between development and production. Right. And that's a really important part of all of us. Do you need a point of view built into the infrastructure to make it palatable to developers, you know, who want a platform as opposed to just infrastructure? Sure. So one of the things that's most exciting about this space is we're splitting the difference of platform and infrastructure. So platform is typically like platform as a service is very prescriptive way of running your server infrastructure. Yeah. And there's raw infrastructure which is a like here is a canvas go to town, but you need to bring all your own tools. What's happening right now in this distributed systems container space is a middle category. It's still infrastructure, but it's application focused. And at the end of the day that's what a developer is trying to do is deploy their application out into the server infrastructure. So it doesn't have an opinion that tells the developer we think you should build it this way. Right. But it does hide all the sort of the different types of hardware, you know, and their location. Right. It gives you a prescriptive way to how you package and deploy that. It doesn't put on any constraints of what you can package or deploy. Okay. Very interesting. It's sort of like a if platform as a service was constraining because it I guess because developers didn't want a straight jacket, you know, for how they should build the app. And infrastructure as a service was too raw. You're giving them a middle ground. Exactly. It's still infrastructure. Yeah. But it's a consistent way of running that infrastructure. And that's why companies like Google and Facebook and Twitter do this. They have millions of servers and data centers all over the world. And they can't prescribe. Well, they need to be able to have a consistent way of doing it so that they don't have to have a infinitely growing operations team as they scale their infrastructure. Right. You need to have consistency. But at the same time, you need to be able to have a wide array of applications and tools and things to deploy and interact with that infrastructure. So it's that middle ground. And that's why the hyperscale guys have adopted it because they are forced to because they have to have that consistency to have that scale. Okay. Let me ask you then, not on the separate from the hyperscale guys. They're, you know, the sort of newest distributed system that mainstream enterprises are struggling with and sort of off the record, maybe choking on, you know, is Hadoop because, you know, they haven't had to do elastic infrastructure before. And, you know, like you said, the zookeeper is, you know, not that easy. And there's 22 other projects by, you know, by the way, that also have to get stood up. Can you help someone who's perhaps flailing in that? Or if not flailing, finding the skills overhead really, really tough? Right. So Hadoop, let's remember Hadoop's roots. Where did that come from? Well, Yahoo. Yeah. Well, but where did Yahoo get the idea? Oh, yeah, Google. Right, exactly. Yahoo gets all the credit for it, even though it was a Google paper that was modeled after it. And so, again, if Kubernetes and containers and everything is equivalent of Google's Borg, which is that raw application infrastructure, Hadoop is a certain application that consumes the spare resources on that cluster in order to do these map-reducing computational jobs, right? So the next question is, how much can you simplify what mainstream enterprises do that don't have the Google infrastructure yet? Right. So they have to manage that as its own whole separate thing. It's its own set of infrastructure, its own set of servers to manage every new cluster. OK. If you combine it with this application infrastructure, what we just treat Hadoop as another application that runs on the platform. It's not its own distinct special thing. Just another application running out there along with your web servers and your databases and everything else. You have your Hadoop workload in the mix. So you have this consistent pool of infrastructure and Hadoop is just another application that's monitored and managed in the exact same way as everything else. So for folks who are a little more familiar with Mesos, which is the opposite of a virtual machine, it makes many machines look like a single one. I assume, you know, that's... Well, this is a very similar message to Mesos. Mesos is also building Google-like infrastructure for everyone. Right. The difference with what we're doing is really we just partnered up with the team that built that at Google and focusing our solution on Kubernetes, which is what the Google efforts are behind. So we're all modeling Google's infrastructure. OK. Mesos took their own spin on it with Kubernetes and CoroS and NCD. We're taking a different spin on it. So and what other products have you built out that we haven't touched on and what do you see the roadmap looking like? Sure. So really all these things we've talked about are open source projects. They're all components for building this Google-like infrastructure. Right. Tectonic is our platform for companies that want this style of infrastructure, but they don't want to have to figure out all the different pieces themselves. OK. And we think once companies adopt Tectonic, just this general style of infrastructure that we can give them all the benefits of this better utilization, the consistency, easier management of lots and lots of servers and so on. But we also think we can dramatically improve the security of their infrastructure as well. That's where we're investing in our roadmap is to leverage this kind of change. And then with that change, we can do some things to the infrastructure that was never possible before. OK. And that's the things that we're investing in as a company. OK. Great. We're going to break hit that. Ms. George Gilbert at Structure 15 with Alex Pauly of CoroS and we'll be back in just a few minutes.