>> Live from the Julia Morgan Ballroom in San Francisco. Extracting the signal from the noise, it's TheCUBE. Covering Structure 2015. Now your host, George Gilbert. >> This is George Gilbert, we're at Structure 2015. Reborn and really healthy from the old GigaOM, and we're pleased to welcome Alex Polvi from CoreOS, everyone seems to want to talk to Alex these days. So we've got first dibs. 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 'cause 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 could 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. >> Yeah. >> Is this like a cut down version of Linux that gives it a small attack surface and a sort of easier deployment and patching? >> Exactly, so in our quest to run the world servers to secure the internet we start at the lowest level component possible. There's the OS, then there's the distributed system side. 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, 'cause 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 application model. As well as just stripping everything else out. I mean the last 20 years of Linux distributions have created lots of cruft so it was time to kind of rebirth a new lightweight Linux OS. >> Sticking to CoreOS >> Yeah. >> 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 on 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, >> GIFFY. >> Okay. What other products did you have to fill out to make that possible? >> Sure, great question. So the next major piece that we released is a tool called ETCD. It's meant for doing shared configuration amongst 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". Consensus algorithms is an area of computing, actually speaking about here in a little bit with Eric Brewer, who is a huge academic, a very well respected engineer in the area of consenus and distributed systems. And so we built ETCD, 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. >> It's simplified. >> It's a simplified Zookeeper and make it accessible. Areas 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 toward 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 adopted. And so we released ETCD around the same time we released CoreOS Linux and this point, there's been over a thousand projects if you go on GitHub that have built things around ETCD, so our bet was right. Even things like Kubernetes, itself has a hard dependency on ETCD. Without ETCD, Kupernetes will not run. So our hypothesis there was let's make the hardest part of distributed systems easier, and then we will see distributed systems overall accelerate. And that is definitely what's happened with ETCD. >> 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 the security. Keeping things up to date, and when we mean up to date, we don't just mean like patch a vulnerability. Of which we've fixed many of those. But it's also about company's 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 kind of the safety net that distributed systems give you. >> Does this require the sort of micro-service approach where 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. It requires a container, it also requires the distributed systems components of it. So we first built CoreOS Linux, then we built ETCD, 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 reinventing all of this stuff let's partner up with the guys from the Google" if we're 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, ETCD, CoreOS 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 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 weed for a sec. Derek Collison calls, I'm sorry I'm having a senior moment. And I hope it's not early onset Alzheimer's. The Docker, he calls sort of this generation's Tarball, you know, like to distribute you know, just a sort of I guess equivalent of an executable. Are you providing something that's compatible or does what's inside the container have to change to take advantage of the additional services that's sort of Google-centric. >> Sure. So the packaging, that Tarball piece, we're compatible with. And will always remain compatible with. To even further the compatibility, we've put together standards around what that container should be so many vendors can inter-operate more widely. We've done that first through the app container project and 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, does the Google compute engine folks, or the passgroup, 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? Because I'm trying to understand, you know Azure sort of has its own way of looking at the world, 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'd have to talk to them about it. My understanding is that they see that as a way to have a very consistent environment between different cloud providers and so on. It is a next-generation way of running infrastructure as well, and its just better than the previous way of running infrastructure. >> That's sort of the answer I was looking for which is, they don't have to either give away their stuff or manage their infrastructure elsewhere. But you're sort of the channel to deliver Google style infrastructure in other environments. >> Sure, I mean Google Cloud's motivation at the end of the day is selling cores of memory. They put all these other services on top of it to make it, to make it more attractive to use, but the end of the day anything that drives more usage of these products is how they run their business. At least that's my perception of it. I'm obviously not speaking on behalf of Google. >> So where are you in attracting showcase customers? Guys who've sort of said "okay we'll bet", if not the entire business, "we'll bet the success of this application or these set of applications on this". >> Right, so first the technology's been very, very exciting. I mean the past two years we've seen this whole space explode in interest, but the discussion around "how does this solve business problems, how does this actually get adopted to 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 and in fact in about two weeks here in early December in New York we're hosting that discussion at an event called the Tectonic Summit. The Tectonic Summit is where we're bringing together all the enterprise early adopters that are using containers, using distributed systems, and talking about why did their management and their leadership decide to make investments in 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 businesses need to be now because of mobile, just modern product offerings. And so we're hearing from these large guys and how they're using our technologies and other companies' technologies today to do this, and it's just two weeks at our event. >> Would it be fair to say, I'm listening to this and what seems to becoming across is that your technology makes it easier to abstract not just the machine, which would be CoreOS, but hybrid infrastructure. And it doesn't even have to be hybrid, it could be this data center and that data center. >> Right. >> Or your own data center and a public cloud. >> Exactly. One of the biggest value props of all this is the consistency between environments. We just give this 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 an extremely consistent way. Not just between your data centers but also between development and production, and that's a really important part of all of this. >> Do you need a point of view built into the infrastructure to make it palatable to developers 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. Platform is typically, platform is a service, this very prescriptive way of running your server infrastructure. 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", but it does hide all the sort of, the different types of hardware and their location pretty much. >> Right, it gives you a prescriptive way to how you package and deploy that, but 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 developers didn't want a straightjacket for how they should build the app, and infrastructures, our service was too raw. You're giving them a middle ground. >> Exactly. It's still infrastructure, 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 an infinitely growing operations team as they scale their infrastructure. You need to have consistency, but at the same time you need to be able to have a wide array of 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're 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, 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 they haven't had to do elastic infrastructure before and like you said the Zookeeper is not that easy, and there's 22 other projects by the way that also have to get stood up. Can you help someone who is perhaps flailing in that or if not flailing, finding the skills overhead really, really tough? >> So, Hadoop. Let's remember Hadoop's roots. Where did that come from? >> Well Yahoo!. >> Well but where did Yahoo! get the idea? >> Oh yeah, Google, sorry. >> Exactly. Yahoo! gets all the credit for it. Even though it was a Google paper that was modeled after. And so again, if Kubernetes and containers and everything is the 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. >> 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, it's its own set of servers to manage their Hadoop cluster. If you combine it with this application infrastructure, we just treat Hadoop as another application that runs on the platform. It's not its own distinct, special thing. It's 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 or managed 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. >> Well this is a very similar message to Mesos. Mesos is also building Google-like infrastructure for everyone else. 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 around Kubernetes which is what the Google efforts are behind. So we're all modeling Google's infrastructure. >> Okay. >> Mesos took their own spin on it with Kubernetes, and CoreOS and ETCD, 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. 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. 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, that 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. And that's what 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. >> Okay. >> And that's the things that we're investing in as a company. >> Okay, great. We're going to break at that, this is George Gilbert, at Structure '15, with Alex Polvi of CoreOS. And we'll be back in just a few minutes. (light music)