>> (bright music) >> Narrator: The Cube, presents Kubecon and Cloudnativecon, year of 2022, brought to you by Red Hat, the cloud native computing foundation and its ecosystem partners. >> Now what we're opening. Welcome to Valencia, Spain in Kubecon Cloudnativecon, Europe, 2022. I'm Keith Townsend, along with my host, Paul Gillin, who is the senior editor for architecture at Silicon angle, Paul. >> Keith you've been asking me questions all these last two days. Let me ask you one. You're a traveling man. You go to a lot of conferences. What's different about this one. >> You know what, we're just talking about that pre-conference, open source conferences are usually pretty intimate. This is big. 7,500 people talking about complex topics, all in one big area. And then it's, I got to say it's overwhelming. It's way more. It's not focused on a single company's product or messaging. It is about a whole ecosystem, very different show. >> And certainly some of the best t-shirts I've ever seen. And our first guest, Jim has one of the better ones. >> I mean a bit cockroach come on, right. >> Jim Walker, principal product evangelist at CockroachDB and Christian Huning, tech director of cloud technologies at Finleap Connect, a financial services company that's based out of Germany, now offering services in four countries now. >> Basically all over Europe. >> Okay. >> But we are in three countries with offices. >> So you're CockroachDB customer and I got to ask the obvious question. Databases are hard and started the company in 2015 CockroachDB, been a customer since 2019, I understand. Why take the risk on a four year old database. I mean that just sounds like a world of risk and trouble. >> So it was in 2018 when we joined the company back then and we did this cloud native transformation, that was our task basically. We had very limited amount of time and we were faced with a legacy infrastructure and we needed something that would run in a cloud native way and just blend in with everything else we had. And the idea was to go all in with Kubernetes. Though early days, a lot of things were alpha beta, and we were running on mySQL back then. >> Yeah. >> On a VM, kind of small setup. And then we were looking for something that we could just deploy in Kubernetes, alongside with everything else. And we had to stack and we had to duplicate it many times. So also to maintain that we wanted to do it all the same like with GitOps and everything and Cockroach delivered that proposition. So that was why we evaluate the risk of relatively early adopting that solution with the proposition of having something that's truly cloud native and really blends in with everything else we do in the same way was something we considered, and then we jumped the leap of faith and >> The fin leap of faith >> The fin leap of faith. Exactly. And we were not dissatisfied. >> So talk to me a little bit about the challenges because when we think of MySQL, MySQL scales to amazing sizes, it is the de facto database for many cloud based architectures. What problems were you running into with MySQL? >> We were running into the problem that we essentially, as a finTech company, we are regulated and we have companies, customers that really value running things like on-prem, private cloud, on-prem is a bit of a bad word, maybe. So it's private cloud, hybrid cloud, private cloud in our own data centers in Frankfurt. And we needed to run it in there. So we wanted to somehow manage that and with, so all of the managed solution were off the table, so we couldn't use them. So we needed something that ran in Kubernetes because we only wanted to maintain Kubernetes. We're a small team, didn't want to use also like full blown VM solution, of sorts. So that was that. And the other thing was, we needed something that was HA distributable somehow. So we also looked into other solutions back at the time, like Vitis, which is also prominent for having a MySQL compliant interface and great solution. We also got into work, but we figured, this is from the scale, and from the sheer amount of maintenance it would need, we couldn't deliver that, we were too small for that. So that's where then Cockroach just fitted in nicely by being able to distribute BHA, be resilient against failure, but also be able to scale out because we had this problem with a single MySQL deployment to not really, as it grew, as the data amounts grew, we had trouble to operatively keep that under control. >> So Jim, every time someone comes to me and says, I have a new database, I think we don't need it, yet another database. >> Right. >> What problem, or how does CockroachDB go about solving the types of problems that Christian had? >> Yeah. I mean, Christian laid out why it exists. I mean, look guys, building a database isn't easy. If it was easy, we'd have a database for every application, but you know, Michael Stonebraker, kind of godfather of all database says it himself, it takes seven, eight years for a database to fully gestate to be something that's like enterprise ready and kind of, be relied upon. We've been billing for about seven, eight years. I mean, I'm thankful for people like Christian to join us early on to help us kind of like troubleshoot and go through some things. We're building a database, it's not easy. You're right. But building a distributor system is also not easy. And so for us, if you look at what's going on in just infrastructure in general, what's happening in Kubernetes, like this whole space is Kubernetes. It's all about automation. How do I automate scale? How do I automate resilience out of the entire equation of what we're actually doing? I don't want to have to think about active passive systems. I don't want to think about sharding a database. Sure you can scale MySQL. You know, how many people it takes to run three or four shards of MySQL database. That's not automation. And I tell you what, this world right now with the advances in data how hard it is to find people who actually understand infrastructure to hire them. This is why this automation is happening, because our systems are more complex. So we started from the very beginning to be something that was very different. This is a cloud native database. This is built with the same exact principles that are in Kubernetes. In fact, like Kubernetes it's kind of a spawn of borg, the back end of Google. We are inspired by Spanner. I mean, this started by three engineers that worked at Google, are frustrated, they didn't have the tools, they had at Google. So they built something that was, outside of Google. And how do we give that kind of Google like infrastructure for everybody. And that's, the advent of Cockroach and kind of why we're doing, what we're doing. >> As your database has matured, you're now beginning a transition or you're in a transition to a serverless version. How are you doing that without disrupting the experience for existing customers? And why go serverless at all? >> Yeah, it's interesting. So, you know, serverless was, it was kind of a an R&D project for us. And when we first started on a path, because I think you know, ultimately what we would love to do for the database is let's not even think about database, Keith. Like, I don't want to think about the database. What we're building too is, we want a SQL API in the cloud. That's it. I don't want to think about scale. I don't want to think about upgrades. I literally like. that stuff should just go away. That's what we need, right. As developers, I don't want to think about isolation levels or like, you know, give me DML and I want to be able to communicate. And for us the realization of that vision is like, if we're going to put a database on the planet for everybody to actually use it, we have to be really, really efficient. And serverless, which I believe really should be infrastructure less because I don't think we should be thinking of just about service. We got to think about, how do I take the context of regions out of this thing? How do I take the context of cloud providers out of what we're talking about? Let's just not think about that. Let's just code against something. Serverless was the answer. Now we've been building for about a year and a half. We launched a serverless version of Cockroach last October and we did it so that everybody in the public could have a free version of a database. And that's what serverless allows us to do. It's all consumption based up to certain limits and then you pay. But I think ultimately, and we spoke a little bit about this at the very beginning. I think as ISVs, people who are building software today the serverless vision gets really interesting because I think what's on the mind of the CTO is, how do I drive down my cost to the cloud provider? And if we can basically, drive down costs through either making things multi-tenant and super efficient, and then optimizing how much compute we use, spinning things down to zero and back up and auto scaling these sort of things in our software. We can start to make changes in the way that people are thinking about spend with the cloud provider. And ultimately we did that, so we could do things for free. >> So, Jim, I think I disagree Christian, I'm sorry, Jim. I think I disagree with you just a little bit. Christian, I think the biggest challenge facing CTOs are people. >> True. >> Getting the people to worry about cost and spend and implementation. So as you hear the concepts of CoachDB moving to a serverless model, and you're a large customer how does that make you think or react to your people side of your resources? >> Well, I can say that from the people side of resources luckily Cockroach is our least problem. So it just kind of, we always said, it's an operator stream because that was the part that just worked for us, so. >> And it's worked as you have scaled it? without you having ... >> Yeah. I mean, we use it in a bit of a, we do not really scale out like the Cockroach, like really large. It's like, more that we use it with the enterprise features of encryption in the stack and our customers then demand. If they do so, we have the Zas offering and we also do like dedicated stacks. So by having a fully cloud native solution on top of Kubernetes, as the foundational layer we can just use that and stamp it out and deploy it. >> How does that translate into services you can provide your customers? Are there services you can provide customers that you couldn't have, if you were running, say, MySQL? >> No, what we do is, we run this, so the SAS offering runs in our hybrid private cloud. And the other thing that we offer is that we run the entire stack at a cloud provider of their choosing. So if they are an AWS, they give us an AWS account, we put it in there. Theoretically, we could then also talk about using the serverless variant, if they like so, but it's not strictly required for us. >> So Christian, talk to me about that provisioning process because if I had a MySQL deployment before I can imagine how putting that into a cloud native type of repeatable CICD pipeline or Ansible script that could be difficult. Talk to me about that. How CockroachDB enables you to create new onboarding experiences for your customers? >> So what we do is, we use helm charts all over the place as probably everybody else. And then each application team has their parts of services, they've packaged them to helm charts, they've wrapped us in a super chart that gets wrapped into the super, super chart for the entire stack. And then at the right place, somewhere in between Cockroach is added, where it's a dependency. And as they just offer a helm chart that's as easy as it gets. And then what the teams do is they have an inner job, that once you deploy all that, it would spin up. And as soon as Cockroach is ready it's just the same reconcile loop as everything. It will then provision users, set up database schema, do all that. And initialize, initial data sets that might be required for a new setup. So with that setup, we can spin up a new cluster and then deploy that stack chart in there. And it takes some time. And then it's done. >> So talk to me about life cycle management. Because when I have one database, I have one schema. When I have a lot of databases I have a lot of different schemas. How do you keep your stack consistent across customers? >> That is basically part of the same story. We have get offs all over the place. So we have this repository, we see the super helm chart versions and we maintain like minus three versions and ensure that we update the customers and keep them up to date. It's part of the contract sometimes, down to the schedule of the customer at times. And Cockroach nicely supports also, these updates with these migrations in the background, the schema migrations in the background. So we use in our case, in that integration SQL alchemy, which is also nicely supported. So there was also part of the story from MySQL to Postgres, was supported by the ORM, these kind of things. So the skill approach together with the ease of helm charts and the background migrations of the schema is a very seamless upgrade operations. Before that we had to have downtime. >> That's right, you could have online schema changes. Upgrading the database uses the same concept of rolling upgrades that you have in Kubernetes. It's just cloud native. It just fits that same context, I think. >> Christian: It became a no-brainer. >> Yeah. >> Yeah. >> Jim, you mentioned the idea of a SQL API in the cloud, that's really interesting. Why does such a thing not exist? >> Because it's really difficult to build. You know, SQL API, what does that mean? Like, okay. What I'm going to, where does that endpoint live? Is there one in California one on the east coast, one in Europe, one in Asia? Okay. And I'm asking that endpoint for data. Where does that data live? Can you control where data lives on the planet? Because ultimately what we're fighting in software today in a lot of these situations is the speed of light. And so how do you intelligently place data on this planet? So that, you know, when you're asking for data, when you're maybe home, it's a different latency than when you're here in Valencia. Does that data follow and move you? These are really, really difficult problems to solve. And I think that we're at that layer of, we're at this moment in time in software engineering, we're solving some really interesting, interesting things cause we are budding against this speed of light problem. And ultimately that's one of the biggest challenges. But underneath, it has to have all this automation like the ease at which we can scale this database like the always on resilient, the way that we can upgrade the entire thing with just rolling upgrades. The cloud native concepts is really what's enabling us to do things at global scale it's automation. >> Let's alk about that speed of light in global scale. There's no better conference for speed of light, for scale, than Kubecon. Any predictions coming out of the show? >> It's less a prediction for me and more of an observation, you guys. Like look at two years ago, when we were here in Barcelona at QCon EU, it was a lot of hype. It's a lot of hype, a lot of people walking around, curious, fascinated, this is reality. The conversations that I'm having with people today, there's a reality. There's people really doing, they're becoming cloud native. And to me, I think what we're going to see over the next two to three years is people start to adopt this kind of distributed mindset. And it permeates not just within infrastructure but it goes up into the stack. We'll start to see much more developers using, Go and these kind of the threaded languages, because I think that distributed mindset, if it starts at the chip all the way to the fingertip of the person clicking and you're distributed everywhere in between. It is extremely powerful. And I think that's what Finleap, I mean, that's exactly what the team is doing. And I think there's a lot of value and a lot of power in that. >> Jim, Christian, thank you so much for coming on the Cube and sharing your story. You know what we're past the hype cycle of Kubernetes, I agree. I was a nonbeliever in Kubernetes two, three years ago. It was mostly hype. We're looking at customers from Microsoft, Finleap and competitors doing amazing things with this platform and cloud native in general. Stay tuned for more coverage of Kubecon from Valencia, Spain. I'm Keith Townsend, along with Paul Gillin and you're watching the Cube, the leader in high tech coverage. (bright music)

(bright upbeat music) >> Hello, and welcome back to the DockerCon 2021 virtual coverage. I'm John Furrie host of theCUBE here in Palo Alto with a remote interview with a great guest Cuban alumni, Jim Walker VP of Product Marketing at Cockroach Labs. Jim, great to see you remotely coming into theCUBE normally we're in person, soon we'll be back in real life. Great to see you. >> Great to see you as well John, I miss you. I miss senior live and in person. So this has got to do, I guess right? >> We we had the first multi-cloud event in New York city. You guys had was I think one of the last events that was going on towards the end of the year before the pandemic hit. So a lot's happened with Cockroach Labs over the past few years, accelerated growth, funding, amazing stuff here at DockerCon containerization of the world, containers everywhere and all places hybrid, pure cloud, edge everywhere. Give us the update what's going on with Cockroach Labs and then we'll get into what's going on at DockerCon. >> Yeah Cockroach Labs, this has been a pretty fun ride. I mean, I think about two and a half years now and John it's been phenomenal as the world kind of wakes up to a distributed systems and the containerization of everything. I'm happy we're at DockerCon talking about containerization 'cause I think it has radically changed the way we think about software, but more importantly it's starting to take hold. I think a lot of people would say, oh, it's already taken hold but if you start to think about like just, these kind of modern applications that are depending on data and what does containerization mean for the database? Well, Cockroach has got a pretty good story. I mean, gosh, before Escape I think the last time I talked to you, I was at CoreOS and we were playing the whole Kubernetes game and I remember Alex Povi talking about GIFEE Google infrastructure for everyone or for everyone else I should say. And I think that's what we've seen that kind of happened with the infrastructure layer but I think that last layer of infrastructure is the database. Like I really feel like the database is that dividing line between the business logic and infrastructure. And it's really exciting to see, just massive huge customers come to Cockroach to rethink what the database means in cloud, right? What does the database mean when we moved to distributed systems and that sort of thing, and so, momentum has been building here, we are, upwards of, oh gosh, over 300 paying customers now, thousands of Cockroach customers in the wild out there but we're seeing this huge massive attraction to CockroachCloud which is a great name. Come on, Johnny, you got to say, right? And our database as a service. So getting that out there and seeing the uptake there has just been, it's been phenomenal over the past couple of years. >> Yeah and you've got to love the Cockroach name, love it, survive nuclear war and winter all that good stuff as they say, but really the reality is that it's kind of an interesting play on words because one of the trends that we've been talking about, I mean, you and I've been telling this for years with our CUBE coverage around Amazon Web Services early on was very clear about a decade ago that there wasn't going to be one database to rule the world. They're going to many, many databases. And as you started getting into these cloud native deployments at scale, use your database of choice was the developer ethos just whatever it takes to get the job done. Now you start integrating this in a horizontally scalable way with the cloud, you have now new kinds of scale, cloud scale. And it kind of changed the game on the always on availability question which is how do I get high availability? How do I keep things running? And that is the number one developer challenge whether it's infrastructure as code, whether it's security shifting left, it all comes down to making sure stuff's running at scale and secure. Talk about that. >> Yeah, absolutely and it's interesting it's been, like I said, this journey in this arc towards distributed systems and truly like delivery of what people want in the cloud, it's been a long arc and it's been a long journey and I think we're getting to the point where people, they are starting to kind of bake resilience and scale into their applications and I think that's kind of this modern approach. Look we're taking legacy databases today. There are people are kind of lift and shift, move them into the cloud, try to run them there but they aren't just built for that infrastructure like the there's a fundamentally different approach and infrastructure when it talks, when you talk about cloud it's one of the reasons why John early on your conversations with the AWS Team and what they did, it's like, yeah, how do we give resilient and ubiquitous and always on scalable kind of infrastructure people. Well, that's great for those layers but when you start to get into the software that's running on these things, it isn't lift and shift and it's not even move and improve. You can't like just take a legacy system and change one piece of it to make it kind of take advantage of the scale and the resilience and the ubiquity of the cloud, because there's very very explicit challenges. For us, it's about re-architect and rebuild. Let's tear the database down and let's rethink it and build from the ground up to be cloud native. And I think the technologies that have done that, that have kind of built from scratch, to be cloud native are the ones that are I believe, three years from now that's what we're going to be talking about. I mean, this comes back to again, like the Genesis of what we did is Google Cloud Spanner. Spanner white paper and what Google did, they didn't build, they didn't use an existing database because they needed something for a transactional relational database. They hire a bunch of really incredible engineers, right? And I got like Jeff Dean and Sanjay Ghemawat over there, like designing and doing all these cool things, they build and I think that's what we're seeing and I think that's, to me the exciting part about data in the cloud as we move forward. >> Yeah, and I think the Google cloud infrastructure, everyone I think that's the same mindset for Amazon is that I want all the scale, but I don't want to do it like over 10 years I to do it now, which I love I want to get back to in a second, but I want to ask you specifically this definition of containerization of the database. I've heard that kicked around, love the concept. I kind of understand what it means but I want you to define it for us. What does it mean when someone says containerizing the database? >> Yeah, I mean, simply put the database in container and run it and that's all that I can think that's like, maybe step one I think that's kind of lift and shift. Let's put it in a container and run it somewhere. And that's not that hard to do. I think I could do that. I mean, I haven't coded in a long time but I think I could figure that out. It's when you start to actually have multiple instances of a container, right? And that's where things get really, really tricky. Now we're talking about true distributed systems. We're talking about how do you coordinate data? How do you balance data across multiple instances of a database, right? How do you actually have fail over so that if one node goes down, a bunch of them are still available. How do you guarantee transactional consistency? You can't just have four instances of a database, all with the same information in it John without any sort of coordination, right? Like you hit one node and you hit another one in the same account which transaction wins. And so the concepts in distributed systems around there's this thing called the cap theorem, there's consistency, availability, and partition tolerance and actually understanding how these things work especially for data in distributed systems, to make sure that it's going to be consistent and available and you're going to scale those things are not simple to solve. And again, it comes back to this. I don't think you can do it with legacy database. You kind of have to re-architect and it comes down to where data is stored, it comes down to how it's replicated, it comes down to really ultimately where it's physically located. I think when you deploy a database you think about the logical model, right? You think about tables, and normalization and referential integrity. The physical location is extremely important as we kind of moved to that kind of containerized and distributed systems, especially around data. >> Well, you guys are here at DockerCon 2021 Cockroach Labs good success, love the architectural flexibility that you guys offer. And again, bringing that scale, like you mentioned it's awesome value proposition, especially if people want to just program the infrastructure. What's going on with with DockerCon specifically a lot of talk about developer productivity, a lot of talk about collaboration and trust with containers, big story around security. What's your angle here at DockerCon this year? What's the big reveal? What's the discussion? What's the top conversation? >> Yeah, I mean look at where we are a containerized database and we are an incredibly great choice for developers. For us, it's look at there's certain developer communities that are important on this planet, John, and this is one of them, right? This is I don't know a developer doesn't have that little whale up in their status bar, right? And for us, you know me man, I believe in this tech and I believe that this is something that's driven and greatly simplify our lives over the next two to three to 10 to 15 years. And for us, it's about awareness. And I think once people see Cockroach, they're like oh my God, how did I ever even think differently? And so for us, it's kind of moving in that direction. But ultimately our vision where we want to be, is we want to abstract the database to a SQL API in the cloud. We want to make it so simple that I just have this rest interface, there's end points all over the planet. And as a developer, I never have to worry about scale. I never have to worry about DR right? It's always going to be on. And most importantly, I don't have to worry about low latency access to data no matter where I'm at on the planet, right? I can give every user this kind of sub 50 millisecond access to data or sub 20 millisecond access to data. And that is the true delivery of the cloud, right? Like I think that's what the developer wants out of the cloud. They want to code against a service like, and it's got to be consumption-based and you secure and I don't want to have to pay for stuff I'm not using and that all those things. And so, for us, that's what we're building to, and interacting in this environment is critical for us because I think that's where audiences. >> I want to get your thoughts on you guys do have success with a couple of different personas and developers out there, groups, classic developers, software developers which is this show is that DockerCon full of developers KubeCon a lot of operators cool, and some dads, but mostly cloud native operations. Here's a developer shops. So you guys got to hit the developers which really care about building fast and building the scale and last with security. Architects you had success with, which is the classic, cloud architecture, which now distributed computing, we get that. But the third area I would call the kind of the role that both the architects and the developers had to take on which is being the DevOps person or then becomes the SRE in the group, right? So most startups have the DevOps team developers. They do DevOps natively and within every role. So they're the same people provisioning. But as you get larger and an enterprise, the DevOps role, whether it's in a team or group takes on this SRE site reliability engineer. This is a new dynamic that brings engineering and coding together. It's like not so much an ops person. It's much more of like an engineering developer. Why is that role so important? And we're seeing more of it in dev teams, right? Seeing an SRE person or a DevOps person inside teams, not a department. >> Yeah, look, John, we, yeah, I mean, we employ an army of SREs that manage and maintain our CockroachCloud, which is CockroachDB as a service, right? How do you deliver kind of a world-class experience for somebody to adopt a managed service a database such as ours, right? And so for us, yeah I mean, SREs are extremely important. So we have personal kind of an opinion on this but more importantly, I think, look at if you look at Cockroach and the architecture of what we built, I think Kelsey Hightower at one point said, I am going to probably mess this up but there was a tweet that he wrote. It's something like, CockroachDB is the Spanner as Kubernetes is the board. And if you think about that, I mean that's exactly what this is and we built a database that was actually amenable to the SRE, right? This is exactly what they want. They want it to scale up and down. They want it to just survive things. They want to be able to script this thing and basically script the world. They want to actually, that's how they want to manage and maintain. And so for us, I think our initial audience was definitely architects and operators and it's theCUBE con crowd and they're like, wow, this is cool. This is architected just like Kubernetes. In fact, like at etcd, which is a key piece of Kubernetes but we contribute back up to NCD our raft implementation. So there's a lot of the same tech here. What we've realized though John, with database is interesting. The architect is choosing a database sometimes but more often than not, a developer is choosing that database. And it's like they go out, they find a database, they just start building and that's what happens. So, for us, we made a very critical decision early on, this database is wire compatible with Postgres and it speaks to SQL syntax which if you look at some of the other solutions that are trying to do these things, those things are really difficult to do at the end. So like a critical decision to make sure that it's amenable so that now we can build the ORMs and all the tools that people would use and expect that of Postgres from a developer point of view, but let's simplify and automate and give the right kind of like the platform that the SREs need as well. And so for us the last year and a half is really about how do we actually build the right tooling for the developer crowd too. And we've really pushed really far in that world as well. >> Talk about the aspect of the scale of like, say startup for instance, 'cause you made this a great example borg to Kubernetes 'cause borg was Google's internal Kubernetes, like thing. So you guys have Spanner which everyone knows is a great product at Google had. You guys with almost the commercial version of that for the world. Is there, I mean, some people will say and I'll just want to challenge you on this and we'll get your thoughts. I'm not Google, I'll never be Google, I don't need that scale. Or so how do you address that point because some people say, well this might dismiss the notion of using it. How do you respond to that? >> Yeah, John, we get this all the time. Like, I'm not global. My application's not global. I don't need this. I don't need a tank, right? I just need, like, I just need to walk down the road. You know what I mean? And so, the funny thing is, even if you're in a single region and you're building a simple application, does it need to be always on does it need to be available. Can it survive the failure of a server or a rack or an AZ it doesn't have to survive the failure of a region but I tell you what, if you're successful, you're going to want to start actually deploying this thing across multiple regions. So you can survive a backhoe hit in a cable and the entire east coast going out, right? Like, and so with Cockroach, it's real easy to do that. So it's four little SQL commands and I have a database that's going to span all those regions, right? And I think that's important but more importantly, think about scale, when a developer wants to scale, typically it's like, okay, I'm going to spin up Postgres and I'm going to keep increasing my instance size. So I'm going to scale vertically until I run out of room. And then I'm going to have to start sharding this database. And when you start doing that, it adds this kind of application complexity that nobody really wants to deal with. And so forget it, just let the database deal with all that. So we find this thing extremely useful for the single developer in a very small application but the beauty thing is, if you want to go global, great just keep that in notes. Like when that application does take off and it's the next breakthrough thing, this database going to grow with you. So it's good enough to kind of start small but it's the scale fast, it'll go global if you want to, you have that option, I guess, right? >> I mean, why wouldn't you want optionality on this at all? So clearly a good point. Let me ask you a question, take me through a use case where with Cockroach, some scenario develops nicely, you can point to the visibility of the use case for the developer and then kind of how it played out and then compare that and contrast that to a scenario that doesn't go well, like where where we're at plays out well, for an example, and then if they didn't deploy it they got hung up and went sideways. >> Yeah like Cockroach was built for transactional workloads. That that's what we are like, we are optimized for the speed of light and consistent transactions. That's what we do, and we do it very well. At least I think so, right. But I think, like my favorite customer of all of ours is DoorDash and about a year ago DoorDash came to us and said, look at we have a transactional database that can't handle the right volume that we're getting and falls over. And they they'd significant challenges and if you think about DoorDash and DoorDash is business they're looking at an IPO in the summer and going through these, you can't have any issues. So like system's got to be up and running, right? And so for them, it was like we need something that's reliable. We need something that's not going to come down. We need something that's going to scale and handle burst and these sort of things and their business is big, their businesses not just let me deliver food all the time. It's deliver anything, like be that intermediary between a good and somebody's front door. That's what DoorDash wants to be. And for us, yeah, their transactions and that backend transactional system is built on Cockroach. And that's one year ago, they needed to get experienced. And once they did, they started to see that this was like very, very valuable and lots of different workloads they had. So anywhere there's any sort of transactional workload be it metadata, be it any sort of like inventory, or transaction stuff that we see in companies, that's where people are coming to us. And it's these traditional relational workloads that have been wrapped up in these transactional relational databases what built for the cloud. So I think what you're seeing is that's the other shoe to drop. We've seen this happen, you're watching Databricks, you're watching Snowflake kind of do this whole data cloud and then the analytical side John that's been around for a long time and there's that move to the cloud. That same thing that happened for OLAP, is got to happen for OLTP. Where we don't do well is when somebody thinks that we're an analytic database. That's not what we're built for, right? We're optimized for transactions and I think you're going to continue to see these two sides of the world, especially in cloud especially because I think that the way that our global systems are going to work you don't want to do analytics across multiple regions, it doesn't make sense, right? And so that's why you're going to see this, the continued kind of two markets OLAP and OLTP going on and we're just, we're squaring that OLTP side of the world. >> Yeah talking about the transaction processing side of it when you start to change a distributed architecture that goes from core edge, core on premises to edge. Edge being intelligent edge, industrial edge, whatever you're going to have more action happening. And you're seeing, Kubernetes already kind of talking about this and with the containers you got, so you've got kind of two dynamics. How does that change the nature of, and the level of volume of transactions? >> Well, it's interesting, John. I mean, if you look at something like Kubernetes it's still really difficult to do multi-region or multicloud Kubernetes, right? This is one of those things that like you start to move Kubernetes to the edge, you're still kind of managing all these different things. And I think it's not the volumes, it's the operational nightmare of that. For us, that's federate at the data layer. Like I could deploy Cockroach across multiple Kubernetes clusters today and you're going to have one single logical database running across those. In fact you can deploy Cockroach today on top of three public cloud providers, I can have nodes in AWS, I could have nodes in GCP, I could have nodes running on VMs in my data center. Any one of those nodes can service requests and it's going to look like a single logical database. Now that to me, when we talked about multicloud a year and a half ago or whatever that was John, that's an actual multicloud application and delivering data so that you don't have to actually deal with that in your application layer, right? You can do that down in the guts of the database itself. And so I think it's going to be interesting the way that these things gets consumed and the way that we think about where data lives and where our compute lives. I think that's part of what you're thinking about too. >> Yeah, so let me, well, I got you here. One of the things on my mind I think people want to maybe get clarification on is real quick while you're here. Take a minute to explain that you're seeing a CockroachDB and CockroachCloud. There are different products, you mentioned you've brought them both up. What's the difference for the developers watching? What's the difference of the two and when do I need to know the difference between the two? >> So to me, they're really one because CockroachCloud is CockroachDB as a service. It's our offering that makes it a world-class easy to consume experience of working with CockroachDB, where we take on all the hardware we take on the SRE role, we make sure it's up and running, right? You're getting connection, stringing your code against it. And I think, that's side of our world is really all about this kind of highly evolved database and delivering that as a service and you can actually use it's CockroachDB. I think it was just gets really interesting John is the next generation of what we're building. This serverless version of our database, where this is just an API in the cloud. We're going to have one instance of Cockroach with multi-tenant database in there and any developer can actually spin up on that. And to me, that gets to be a really interesting world when the world turns serverless, and we have, we're running our compute in Lambda and we're doing all these great things, right? Or we're using cloud run and Google, right? But what's the corresponding database to actually deal with that? And that to me is a fundamentally different database 'cause what is scale in the serverless world? It's autonomous, right? What scale in the current, like Cockroach world but you kind of keep adding nodes to it, you manage, you deal with that, right? What does resilience mean in a serverless world? It's just, yeah, its there all the time. What's important is latency when you get to kind of serverless like where are these things deployed? And I think to me, the interesting part of like the two sides of our world is what we're doing with serverless and kind of this and how we actually expose the core value of CockroachDB in that way. >> Yeah and I think that's one of the things that is the Nirvana or the holy grail of infrastructure as code is making it, I won't say irrelevant, but invisible if you're really dealing with a database thing, hey I'm just scaling and coding and the database stuff is just working with compute, just whatever, how that's serverless and you mentioned Lambda that's the action because you don't want the file name and deciding what the database is just having it happen is more productivity for the developers that kind of circles back to the whole productivity message for the developers. So I totally get that I think that's a great vision. The question I have for you Jim, is the big story here is developer simplicity. How you guys making it easier to just deploy. >> John is just an extension of the last part of the conversation. I don't want to developer to ever have to worry about a database. That's what Spencer and Peter and Ben have in their vision. It's how do I make the database so simple? It's simple, it's a SQL API in the cloud. Like it's a rest interface, I code against it, I run queries against it, I never have to worry about scaling the thing. I never have to worry about creating active, passive, and primary and secondary. All these like the DevOps side of it, all this operation stuff, it's just kind of done in the background dude. And if we can build it, and it's actually there now where we have it in beta, what's the role of the cost-based optimizer in this new world that we've had in databases? How are you actually ensuring data is located close to users and we're automating that so that, when John's in Australia doing a show, his data is going to follow him there. So he has fast access to that, right? And that's the kind of stuff that, we're talking about the next generation of infrastructure John, not like we're not building for today. Like, look at Cockroach Labs is not building for like 2021. Sure, do we have something that's great. We're building something that's 22 and 23 and 24, right? Like what do we need to be as a extremely productive set of engineers? And that's what we think about all day. How do we make data easy for the developer? >> Well, Jim, great to have you on VP of Product Marketing at Cockroach Labs, we've known each other for a long time. I got to ask you while I had got you here final question is, you and I have chatted about the many waves of in open source and in the computer industry, what's your take on where we are now. And I see you're looking at it from the Cockroach Labs perspective which is large scale distributed computing kind of you're on the new side of history, the right side of history, cloud native. Where are we right now? Compare and contrast for the folks watching who we're trying to understand the importance of where we are in the industry, where are we in and what's your take? >> Yeah John I feel fortunate to be in a company such as this one and the past couple that I've like been around and I feel like we are in the middle of a transformation. And it's just like the early days of this next generation. And I think we're seeing it in a lot of ways in infrastructure, for sure but we're starting to see it creep up into the application layer. And for me, it is so incredibly exciting to see the cloud was, remember when cloud was like this thing that people were like, oh boy maybe I'll do it. Now it's like, it's anything net new is going to be on cloud, right? Like we don't even think twice about it and the coming nature of cloud native and actually these technologies that are coming are going to be really interesting. I think the other piece that's really interesting John is the changing role of open source in this whole game, because I think of open source as code consumption and community, right? I think about those and then there's license of course, I think people were always there. A lot of people wrapped around the licensing. Consumption has changed, John. Back when we were talking to Dupe, consumption was like, oh, it's free, I get this thing I could just download it use it. Well consumption over the past three years, everybody wants everything as a service. And so we're ready to pay. For us, how do we bring free back to the service? And that's what we're doing. That's what I find like I am so incredibly excited to go through this kind of bringing back free beer to open source. I think that's going to be great 'cause if I can give you a database free up to five gig or 10 gig, man and it's available all over the planet has fully featured, that's coming, that's bringing our community and our code which is all open source and this consumption model back. And I'm super excited about that. >> Yeah, free beer who doesn't like free beer of course, developers love free beer and a great t-shirt too that's soft. Make sure you get that, get the soft >> You just don't want free puppy, you know what I mean? It was just like, yeah, that sounds painful. >> Well Jim, great to see you remotely. Can't wait to see you in person at the next event. And we've got the fall window coming up. We'll see some events. I think KubeCon in LA is going to be in-person re-invent a data breast for sure we'll be in person. I know that for a fact we'll be there. So we'll see you in person and congratulations on the work at Cockroach Labs. >> Thanks, John, great to see you again. All right, this keep coverage of DockerCon 2021. I'm John Furrie your host of theCUBE. Thanks for watching.

>> Announcer: From New York, it's theCube. Covering Escape/19. (techno music) >> Yeah, welcome back to theCube's coverage here in New York City for the first ever inaugural multicloud conference called Escape 2019, escape, we're in New York, we're not escaping from New York, we're escaping from the cloud. Jim Walker, Vice President of Product Marketing at Cockroach Labs, the custodian/founders of Cockroach Database. Welcome back, good to see you. >> Congratulations on your new role, new gig. Been there for a while? >> Yeah it's been a while since I've seen you, John, I've jumped out of the data space and into Kubernetes, and so, yeah, I landed at Cockroach Labs about a year ago. And having fun. >> It's interesting, the game is still the same, data is still the same as a value proposition, but software. >> Yeah. >> Data is now code, data is looking, interacting with software, data control planes, data layers, data lakes. All this is an evolution of stuff we were talking about back in the open source days at Hortonworks. The data is in motion, data in flight, data at rest, data is continuing to be critical in automation, security, every single app. >> Yeah, it's at the center of the big battle right now, right, there's this like... I just sense there's a larger battle going on for the platform right now, and the platform is being battled out by these large public cloud providers, and it's who can get compute, who can get actually, you know, people, residents in their cloud. Data has always been the centerpiece of that. Data is gravity, if it was on, before it was on-premise, so the battle was in-house at all these people and now it's like how do we get this stuff to move over. >> Yeah, we were talking before you came on camera, it helps we talk online a lot, and have a lot of connected friends in the cloud native space, but now that Cloud 2.0 has arrived, where it's enterprise hybrid, people are starting to get excited about that, you're seeing the re-platformization or refactoring or whatever word you want to use, a modern enterprise architecture, that has the best of cloud native, has the best of what the enterprise used to do with comput-- like mini-computers, whatnot, now packaged up an operating model. This modernization trend is hitting everything, note, developers, security, this is kind of where you're playing right now. Look what Google's done with Spanner database and where that's all come from in these kinds of large-scale data problems. Modernization's here, what's your take on this? >> Yeah, I know this is modernization, but it's stuff we've been doing for a long time. It's like, you know, I was talking to Steve Mulaney earlier, Steve's brilliant, right, and Steve's talking about 1992 we saw this transition to kind of client server. I've never seen anything like this trans... This transition and this modernization is much bigger than any of the other trends that we've been through. Back when we were talking before it was the Hadoop game, and we were talking modern data architecture, how do we actually transform the way we thought about data from these kind of single stovepipes of data into larger data lakes and this sort of thing. That was the beginning. What we're seeing this time though is a massive transformation up and down the stack of which data is one huge, massive piece of that. And as we know, man, data has gravity and it's at the center of this battle again. >> What's your definition of multicloud? We're at the first ever multicloud conference, what is multicloud? >> You know I get asked this a fair amount, so as I was looking for speakers it was like, "Well, what do you mean, a multicloud conference, what does that even mean?" There's a lot of people, multicloud unbelievers. I think we already live in a multicloud world. I think hybrid cloud is just multicloud. I talked to a lot of people through the CFP process for the conference. I had guys who were running edge computing platforms saying, "Talk to me about this", I'm like, "Well, if you look at it, it's just servers, they're just servers that are everywhere" and actually, how do we actually start to attach all this stuff. It's all multicloud, you know what is the cloud but a bunch of different servers that somebody else owns? You may own them, you may not. The challenge is going to be how do we tie all that together? >> Computer history has proven, if anything, heterogeneous environments, multi-vendor. You can go back and talk about, the comment about the client server, I mean, that was a real threat to the mainframe. Internetworking completely changed the game. At that time PCs were exploding in growth, and multi-vendor was a big buzzword. And that was the reality, you had to compete and service multiple vendors in an environment. >> Yeah, and-- >> Multiple cloud is just multiple vendors. >> John, it's called the multicloud conference, and you know my friend Joseph Jacks, I mean Joseph and I have a lot of conversations about things, you know, and he's brilliant in terms of how he thinks about commercial open source and how these things are, and you know I really played around with changing the name of this to the open and independent cloud conference, because that's really what this is about, it's about how do we have a conversation, in the open, about how we open up the cloud? I just thought, I was a little frustrated with some of the conferences I went to because, I think people are talking about this, but it's not lip service, it's just difficult to talk about it in a broader sense. >> Well, I'm really glad you did this because I've been calling multicloud bullshit on theCube for over a year, Stu and I have debates about this, and you know, putting-- >> I watched. >> Okay, of course, but people who know what I mean know that I believe that multicloud reality of "I have Amazon, I got Azure, I mean, hell, if you upgrade Office 365, you have Azure, so that's another cloud. So yes, people have multiple clouds in their environment, but the foundational work is being done now, you guys are doing it, and that's what I was getting at. There's no multiclouding going on, meaning sense of the seamless workload, what HashiCorp is doing, so this is the foundational, what you guys are getting at, in my mind, at least from my perspective, is a foundational conversation around what is the foundation of multicloud look like. >> And John, there is a technical equation here. I think a lot of people will argue the technical merits of what is multicloud, is it even possible to combine networking and security and all, those are really difficult problems to solve. At Cockroach Labs, to solve the database problem, to solve the data problem, to actually have, you know I could spin up a node at Cockroach on this laptop that's sitting next to you and have that participate in a database that spans multiple clouds, that's awesome. But there's a whole other side of this conversation, John, around what does it mean for my skills in my organization, what does it mean for the financial side of things, the legal, and so I think we're all dealing with a lot of these multicloud concepts, we're just not addressing them yet, and so, it's complex. >> Well, first of all, it's fun too, I mean it's complex, but innovation is complex. But here's the thing, Dave and I were joking around Cloud 2.0 and we picked that term, talking about Cloud 2.0, mainly because I remember during Web 2.0, it was just, everyone was just, "What is Web"..., and to create such a debate, so to goof on Web 2.0 we said Cloud 2.0, but what we mean is that it's changing, right? I'll give you an example, I mean to me Cloud 2.0 or multicloud is having a fully horizontal scalable infrastructure, that on-demand, elastic resource with domain specialty application development that takes advantage of data and machine learning for domain-specific context. And then having an addressable data layer on top of that. That to me is multicloud. >> And being able to service your customers no matter where they are. And unfortunately the public copywriters don't have full coverage across the whole planet so we inherently live in this multicloud world. If you wanted to pull an application today, I'm sorry but the world is your audience, there's no segmenting your app to just New York, right? And so how you actually service customers when they're coming at you from all over the planet. It's another challenge that we have. Fortunately I want to add to your Cloud Two conversation, I'm sorry the Cloud 2.0 conversation, that it is a world of hybrid and multi and multi region and single region and it's the evolution between these different kind of flavors of this situation, I feel is the emerging trend that's happening and we're-- >> Well categories are changing, network management becomes observability, configuration management becomes automation, the old database becomes a different kind of database for you, data protection is cyber protection. There's redefining moments here where white spaces are becoming larger categories. I mean, look at observability, probably going public, getting bought. >> John, look at what Google did over the past, like, 10, 12 years and look at the startups that are now out there that are kind of doing this really innovative stuff. We have LightStep here, you know Cockroach is another great example, what the Upbound team is doing, so people have been through this. From a data point of view we couldn't agree more. I can spin up an instance of RDS, Postgres and it's going to be a single instance, it's going to live in one region and that's going to service one bit of a cloud in one corner of the world. The cloud, and this massive distribution of stuff, it changed, you have to inherently start over when you're building these technologies, and that's why the CNCF has come about, right, is there's a fundamentally different approach-- >> CNCF, I love those guys and we're going to go to do CubeCon, but one of the things that I was talking with hashCode co-founder earlier today, he was talking about workflows. I was talking about workloads, and so I think the conversation is still technical and geeky but if you just abstract out all of the nerd talk and geek talk and say, "What's the workflow and what's the workload?", you go, okay, no other buzzwords should be talked. You've got to go onstage, so you've got to go. Jim Walker, Vice President of Product Marketing, Cockroach Labs, good friend of theCube, and our producer of this show, Mike Harold and the team, Escape/19, first inaugural multicloud conference. Be back with more after this short break. (techno music)

>> Announcer: From New York, it's theCube. Covering Escape/19. (techno music) >> Yeah, welcome back to theCube's coverage here in New York City for the first ever inaugural multicloud conference called Escape 2019, escape, we're in New York, we're not escaping from New York, we're escaping from the cloud. Jim Walker, Vice President of Product Marketing at Cockroach Labs, the custodian/founders of Cockroach Database. Welcome back, good to see you. >> Congratulations on your new role, new gig. Been there for a while? >> Yeah it's been a while since I've seen you, John, I've jumped out of the data space and into Kubernetes, and so, yeah, I landed at Cockroach Labs about a year ago. And having fun. >> It's interesting, the game is still the same, data is still the same as a value proposition, but software. >> Yeah. >> Data is now code, data is looking, interacting with software, data control planes, data layers, data lakes. All this is an evolution of stuff we were talking about back in the open source days at Hortonworks. The data is in motion, data in flight, data at rest, data is continuing to be critical in automation, security, every single app. >> Yeah, it's at the center of the big battle right now, right, there's this like... I just sense there's a larger battle going on for the platform right now, and the platform is being battled out by these large public cloud providers, and it's who can get compute, who can get actually, you know, people, residents in their cloud. Data has always been the centerpiece of that. Data is gravity, if it was on, before it was on-premise, so the battle was in-house at all these people and now it's like how do we get this stuff to move over. >> Yeah, we were talking before you came on camera, it helps we talk online a lot, and have a lot of connected friends in the cloud native space, but now that Cloud 2.0 has arrived, where it's enterprise hybrid, people are starting to get excited about that, you're seeing the re-platformization or refactoring or whatever word you want to use, a modern enterprise architecture, that has the best of cloud native, has the best of what the enterprise used to do with comput-- like mini-computers, whatnot, now packaged up an operating model. This modernization trend is hitting everything, note, developers, security, this is kind of where you're playing right now. Look what Google's done with Spanner database and where that's all come from in these kinds of large-scale data problems. Modernization's here, what's your take on this? >> Yeah, I know this is modernization, but it's stuff we've been doing for a long time. It's like, you know, I was talking to Steve Mulaney earlier, Steve's brilliant, right, and Steve's talking about 1992 we saw this transition to kind of client server. I've never seen anything like this trans... This transition and this modernization is much bigger than any of the other trends that we've been through. Back when we were talking before it was the Hadoop game, and we were talking modern data architecture, how do we actually transform the way we thought about data from these kind of single stovepipes of data into larger data lakes and this sort of thing. That was the beginning. What we're seeing this time though is a massive transformation up and down the stack of which data is one huge, massive piece of that. And as we know, man, data has gravity and it's at the center of this battle again. >> What's your definition of multicloud? We're at the first ever multicloud conference, what is multicloud? >> You know I get asked this a fair amount, so as I was looking for speakers it was like, "Well, what do you mean, a multicloud conference, what does that even mean?" There's a lot of people, multicloud unbelievers. I think we already live in a multicloud world. I think hybrid cloud is just multicloud. I talked to a lot of people through the CFP process for the conference. I had guys who were running edge computing platforms saying, "Talk to me about this", I'm like, "Well, if you look at it, it's just servers, they're just servers that are everywhere" and actually, how do we actually start to attach all this stuff. It's all multicloud, you know what is the cloud but a bunch of different servers that somebody else owns? You may own them, you may not. The challenge is going to be how do we tie all that together? >> Computer history has proven, if anything, heterogeneous environments, multi-vendor. You can go back and talk about, the comment about the client server, I mean, that was a real threat to the mainframe. Internetworking completely changed the game. At that time PCs were exploding in growth, and multi-vendor was a big buzzword. And that was the reality, you had to compete and service multiple vendors in an environment. >> Yeah, and-- >> Multiple cloud is just multiple vendors. >> John, it's called the multicloud conference, and you know my friend Joseph Jacks, I mean Joseph and I have a lot of conversations about things, you know, and he's brilliant in terms of how he thinks about commercial open source and how these things are, and you know I really played around with changing the name of this to the open and independent cloud conference, because that's really what this is about, it's about how do we have a conversation, in the open, about how we open up the cloud? I just thought, I was a little frustrated with some of the conferences I went to because, I think people are talking about this, but it's not lip service, it's just difficult to talk about it in a broader sense. >> Well, I'm really glad you did this because I've been calling multicloud bullshit on theCube for over a year, Stu and I have debates about this, and you know, putting-- >> I watched. >> Okay, of course, but people who know what I mean know that I believe that multicloud reality of "I have Amazon, I got Azure, I mean, hell, if you upgrade Office 365, you have Azure, so that's another cloud. So yes, people have multiple clouds in their environment, but the foundational work is being done now, you guys are doing it, and that's what I was getting at. There's no multiclouding going on, meaning sense of the seamless workload, what HashiCorp is doing, so this is the foundational, what you guys are getting at, in my mind, at least from my perspective, is a foundational conversation around what is the foundation of multicloud look like. >> And John, there is a technical equation here. I think a lot of people will argue the technical merits of what is multicloud, is it even possible to combine networking and security and all, those are really difficult problems to solve. At Cockroach Labs, to solve the database problem, to solve the data problem, to actually have, you know I could spin up a node at Cockroach on this laptop that's sitting next to you and have that participate in a database that spans multiple clouds, that's awesome. But there's a whole other side of this conversation, John, around what does it mean for my skills in my organization, what does it mean for the financial side of things, the legal, and so I think we're all dealing with a lot of these multicloud concepts, we're just not addressing them yet, and so, it's complex. >> Well, first of all, it's fun too, I mean it's complex, but innovation is complex. But here's the thing, Dave and I were joking around Cloud 2.0 and we picked that term, talking about Cloud 2.0, mainly because I remember during Web 2.0, it was just, everyone was just, "What is Web"..., and to create such a debate, so to goof on Web 2.0 we said Cloud 2.0, but what we mean is that it's changing, right? I'll give you an example, I mean to me Cloud 2.0 or multicloud is having a fully horizontal scalable infrastructure, that on-demand, elastic resource with domain specialty application development that takes advantage of data and machine learning for domain-specific context. And then having an addressable data layer on top of that. That to me is multicloud. >> And being able to service your customers no matter where they are. And unfortunately the public copywriters don't have full coverage across the whole planet so we inherently live in this multicloud world. If you wanted to pull an application today, I'm sorry but the world is your audience, there's no segmenting your app to just New York, right? And so how you actually service customers when they're coming at you from all over the planet. It's another challenge that we have. Fortunately I want to add to your Cloud Two conversation, I'm sorry the Cloud 2.0 conversation, that it is a world of hybrid and multi and multi region and single region and it's the evolution between these different kind of flavors of this situation, I feel is the emerging trend that's happening and we're-- >> Well categories are changing, network management becomes observability, configuration management becomes automation, the old database becomes a different kind of database for you, data protection is cyber protection. There's redefining moments here where white spaces are becoming larger categories. I mean, look at observability, probably going public, getting bought. >> John, look at what Google did over the past, like, 10, 12 years and look at the startups that are now out there that are kind of doing this really innovative stuff. We have LightStep here, you know Cockroach is another great example, what the Upbound team is doing, so people have been through this. From a data point of view we couldn't agree more. I can spin up an instance of RDS, Postgres and it's going to be a single instance, it's going to live in one region and that's going to service one bit of a cloud in one corner of the world. The cloud, and this massive distribution of stuff, it changed, you have to inherently start over when you're building these technologies, and that's why the CNCF has come about, right, is there's a fundamentally different approach-- >> CNCF, I love those guys and we're going to go to do CubeCon, but one of the things that I was talking with hashCode co-founder earlier today, he was talking about workflows. I was talking about workloads, and so I think the conversation is still technical and geeky but if you just abstract out all of the nerd talk and geek talk and say, "What's the workflow and what's the workload?", you go, okay, no other buzzwords should be talked. You've got to go onstage, so you've got to go. Jim Walker, Vice President of Product Marketing, Cockroach Labs, good friend of theCube, and our producer of this show, Mike Harold and the team, Escape/19, first inaugural multicloud conference. Be back with more after this short break. (techno music)

>> Live from Seattle, Washington, it's theCUBE On the Ground! Covering KubeCon 2016! Brought to you by The Linux Foundation and Red Hat. Here's your host, John Furrier. >> Okay, we are here in Seattle for a special CUBE On the Ground coverage of CloudNativeCon and KubeCon really born out of the KubeCon last year, now called CloudNativeCon. Really great event, dynamic, lot of developers here. This is where the players are. It's really one of those events that's really special and we've been here all day getting ready to get kicked out of the room. The party's going to kick off at 7 o'clock. There's an election going on, the numbers are crazy. And of course we have the CEO of CoreOS, Alex Polvi, who's here, he's been on theCUBE many times. CoreOS, one of the main players in what is the biggest trend of the past few years that has really catapulted cloud and the developers together, certainly in the enterprise and the cloud as containers, and now Kubernetes, great to see you. >> Great to see you as well, John. >> You guys have been in the heart of the battle and part of the growth and the journey. It's been a battle, it's been fun. Do you have scar tissue? You guys have, with Docker's been out there, you guys have been there, you've been at war, you've been friends, just frenemies. And so in the spirit of growth, this is what's happening in the industry. But more than ever, now you're starting to see an acceleration. Acceleration with Kubernetes as a catalyst. Your thoughts on this trend, because now the container mojo is out there, people get it, they see the value. Now they go, okay, with Kubernetes, this brings you in a primitive at an abstraction that I can work with. How is that changing the game right now? >> I think we're going through the biggest transformation we've seen in infrastructure since cloud was invented. So you know, you have it on these cycles, and cloud, while Amazon has been going for, what, 10 years now, almost? >> Ten years, yeah. >> Right, and so, naturally, you'll see things emerge, and what's happening now is a you know this kind of new layer popping out. And containers and distributed systems are I believe are the next major area of infrastructure investment and beyond cloud itself. >> So talking about the open source community role here, because now you're starting to see the open source community get on this. We had Jim Walker who was on, who works on your team. Ex-Hortonworks guy, kind of knows the big data space, seen that movie before, commenting that most of the people born after 2000 don't even know what loading Linux on a machine is. So they're born cloud native. And so, this is a new dynamic that cloud gives more options for invention, a theme we're hearing here, solving these unknown problems, creating value. So whoever can give me the best speed boat to that wins, right? I mean this is what we're seeing. Your thoughts on the community's role in propelling and keeping in check, by the way, any potentially bad behavior. >> Sure, I think the open source community that we have around Kubernetes and kind of all the cloud native work, it's great for number reasons. One, we've, kind of through Cloud Native Computing Foundation, and kind of just, as conscious effort to have really a kind of a company neutral open source ecosystem has caused adoption of all this stuff. It's becoming like a Linux, or becoming I think OpenStack is actually did a pretty good job of this of creating a very vendor neutral ecosystem around it and we're doing it again around Kubernetes and the associated projects around it. One of the big things that's going on here is it is driven out of the spirit of technical excellence as well. These open source projects are the real deal, they're great pieces of software that are being built, so I think the combination of this community as well as software actually being a great piece of technology coming out of it is really going to propel it forward. >> We had Dan Kohn earlier, who's the executive director, he talked about the IETF and how that was shaped, some of the early internet standards with that some of the architectural decisions. There's no dogma. I mean, dogma kills communities. And they don't want that, so they're going to create a separation. There's always going to be dogma at some levels, conflict, but conflict and discourse is good in communities, at some level. What is that vision for the technical excellence now because it certainly is a race. Your thoughts there, and certainly we've seen this playbook when Docker has trying to go for that management orchestration layer. You guys have a strategy. People have to make money. Right, at some point, the playbooks have to change from being we just do some service and support. We have an open core, I'm going to try and do some, you know, mangling of licensing. Your thoughts on, how are people going to make money? >> Yeah, so, on this open community side of things, I have a crazy theory for you, and I think this one's a little bit further out there. >> That's okay, it's still, things are happening on the election night, I blew my mind, I thought Hillary was going to win by a landslide, go crazy. >> So Amazon is actually become both one of the biggest proponents of open source software. It's one of the places where you can get open source databases and open source Linux and all this stuff as easily as possible. At the same time, if you're an open source company, they're one of your biggest threats, 'cause you're worried that Amazon is just going to like, go build your service! I mean, look, we've seen it across every open source company that has any reasonable amount of traction, Amazon will just go build a service that competes with it. Now, the tricky thing with Amazon is all their APIs and management are very Amazon specific. And there aren't ways to get it in other ways. And we've kind of seen this game before, similar to how, there's Microsoft and Windows with Linux, I believe that Amazon might be kind of becoming this such a powerhouse and so dominated in this space that you're going to almost see an open source backlash around it and I can see Kubernetes being a key part of that in the same way that we talk about Kubernetes as a Linux for distributed system! It's, in a way, like an open cloud. It allows you to build these cloud services in a similar way that Amazon has these higher level services that work in any environment that are built around open standards, that encourage the use of just upstream open source projects. And so far, Amazon has not really been villainized at all, and I don't think they should be-- >> And they're not grandstanding, so I think they're kind of bunkering in. Just-- >> Going for it. >> Squirreling away all this-- >> Just keep it going! (laughs) Keep ripping! >> Why even say anything, you kicking ass! Put the heat shield up and just drive fast, right? >> I feel like at some point, the community is going to be like, wait a minute! We have so many eggs in this basket! >> Yeah, we're feeling fleeced! The numbers are out there! >> And it's a proprietary-- >> Well, first of all, Dave Vellante pointed out that their 25% reporting of was GAAP, and the non-GAPP numbers are even higher. So that's real profit, that's real EB dep. So they, are they giving it back to the community? That's your question. >> Well-- >> So I think the backlash is not only giving back to the community, but either wealth creation and ecosystem flourishing, but you're talking about software. >> And it's a cycle. People want something new to emerge, but at the same time, you don't all your eggs in one basket. So, you know, it's cycles. >> Well, I think your thing is plausible. Let's just go down and play out your crazy scenario. So, Linux, was started because of the mini computer. Proprietary naus-is, and the expensive hardware. So if Amazon becomes that version of that 800 pound gorilla that's similar to the mini computer, proprietary operating systems and gear... So it's a scenario. >> Not too wild! >> Okay, so what's next for you guys? Give us the update on CoreOS, what are you guys doing, what are the hot area, what are you guys doing, what's the update real quick? >> Sure, so, the last 3, 3 1/2 years, we've been shepherding along this whole space. Containers, distributed system, Kubernetes, Docker, Rocker, CoreOS Linux, like all sorts of stuff. We finally got the point where our initial kind of groundwork of the distributed platform is all in place and we can start using it. It's like we got IOS or Android to boot and now can start building apps. And last week, we released our first set of apps, I think really paint the vision of where these things are going. As this concept called operators, and it's where we're encoding kind of the operational side of like the things a human sysadmin would do to run a piece of open source software. We're encoding that into an application and it's called an operator, and it can do things like upgrade a cluster, or back it up, or scale it up and down. Same things operate-- >> Like an agent! >> Like an agent, exactly. And it's these management components that we think are going to give companies a ton of leverage to be able to run lots and lots-- >> So when do you guys ship this recently? >> Yeah, we shipped our first couple one for Etcd, and one for Prometheus last week. It's just they're new open source projects. >> So it's like getting a new car and taking it around the track, right? You guys are getting excited. >> Well, in a way, we're calling this kind of whole concept self driving infrastructure, just like you would have a operator sitting there, driving your car, we can now put software in there to kind of help take care of the stuff, the functionality that an operator would do to give-- >> Well, I think that's great, great strategy. We were just at IBM's World of Watson and as they change their event, from Insight to Watson, that's the big hype. Customers are responding to it. They love this cognitive AI'd vision of self driving infrastructure or stuff taking care of itself and focusing on value. I mean there's a lot of stuff in the weeds right now that seems to be automatable. >> Yeah, look, two weeks ago, we had two huge vulnerabilities come out, one on the Linux kernel and one on Kubernetes. And every ops team in the world had to drop what they were doing and go fix that, and they stopped making progress on their business and whatever thing they were trying to deliver and had to go deal with this fire. We can write programs to fix that stuff and we should! And it'll lead to a more efficient business, and it'll also lead to more secure web, in general, if those things just get patched and updated automatically. >> Yeah, that's great, that's a good point, and the DDoS attack with the IOT was even more pedestrian and worse than-- >> Same issue, it's the updates! Update your software, IOT, like, updates, updates fix it. >> Yeah, I think it was probably some eight year old saying ooh, let's just take down, ooh, they left their passwords open, let's just game in. I mean, that's how bad, how easy that hack was, I mean, and it still penetrates, so tons of work to get done to your build. Alex, thanks for coming on theCUBE here On the Ground. That's a wrap here for today, it was a long day. Great to see you, and congratulations on your success. I'm John Furrier. You're watching theCUBE here On the Ground here for KubeCon and CloudNativeCon, thanks for watching. (techno music)