(upbeat techno music) >> Hello, wonderful cloud community, and welcome to theCUBE's continuing coverage of AWS re:Invent. My name is Savannah Peterson, and I am very excited to be joined by two brilliant gentlemen today. Please welcome Keith from Cockroach Labs and Jeff from AMD. Thank you both for tuning in, coming in from the East coast. How you doing? >> Not too bad. A little cold, but we're going >> Doing great. >> Love that and I love the enthusiasm Keith, you're definitely bringing the heat in the green room before we got on, so I'm going to open this up with you. Cockroach Labs puts out a pretty infamous and useful cloud report each year. Can you tell us a little bit about that, the approach and the data that you report on? >> Yeah, so Cockroach Labs builds a distributed SQL database that we are able to run across multiple cloud regions, multiple sites, multiple data centers. Frequently is running a hybrid kind of a use case and it's important for our customers to be able to compare the performance of configurations when they don't have exact the same hardware available to them in every single location. So since we were already doing this internally for ourselves and for our customers, we decided to turn it into something we shared with the greater community. And it's been a great experience for us. A lot of people come and ask us every year, "Hey, when's the new cloud report coming out?" Because they want to read it. It's been a great win for us. >> How many different things are you looking at? I mean, when you're comparing configurations I imagine there's a lot of different complex variables there. Just how much are you taking into consideration when you publish this report? >> Yeah, so we look at micro benchmarks around CPU network and storage. And then our flagship benchmark is we use the database itself where we have the most expertise to create a real world benchmark on across all of these instances. This year I think we tested over 150 different discrete configurations and it's a bit of a labor of love for us because we then not only do we consume it for best practices for our own as a service offering, but we share it with our customers. We use it internally to make all kinds of different decisions. >> Yeah, 150 different comparisons is not a small number. And Jeff, I know that AMD's position in this cloud report is really important. Where do you fit into all of this and what does it mean for you? >> Right, so what it means for us and for our customers is, there's a good breath and depth of testing that has gone of from the lab. And you look at this cloud report and it helps them traverse this landscape of, why to go on instance A, B, or C on certain workloads. And it really is very meaningful because they now have the real data across all those dimensional kinds of tests. So this definitely helps not only the customers but also for ourselves. So we can now look at ourselves more independently for feedback loops and say, "Hey, here's where we're doing well, here's where we're doing okay, here's where we need to improve on." All those things are important for us. So love seeing the lab present out such a great report as I've seen, very comprehensive, so I very much appreciate it. >> And specifically I love that you're both fans of each other, obviously, specifically digging in there, what does it mean that AMD had the best performance ratio tested on AWS instances? >> Yeah, so when we're looking at instances, we're not just looking at how fast something is, we're also looking at how much it costs to get that level of performance because CockroachDB as a distributed system has the opportunity to scale up and out. And so rather than necessarily wanting the fastest single instance performance, which is an important metric for certain use cases for sure, the comparison of price for performance when you can add notes to get more performance can be a much more economical thing for a lot of our customers. And so AMD has had a great showing on the price performance ratio for I think two years now. And it makes it hard to justify other instance types in a lot of circumstances simply because it's cheaper to get, for each transaction per second that you need, it's cheaper to use an AMD instance than it would be a competitive instance from another vendor. >> I mean, everyone I think no matter their sector wants to do things faster and cheaper and you're able to achieve both, it's easy to see why it's a choice that many folks would like to make. So what do these results mean for CIOs and CTOs? I can imagine there's a lot of value here in the FinOps world. >> Yep. Oh, I'll start a few of 'em. So from the C-suite when they're really looking at the problem statement, think of it as less granular, but higher level. So they're really looking at CapEx, OpEx, sustainability, security, sort of ecosystem on there. And then as Keith pointed out, hey, there's this TCO conversation that has to happen. In other words, as they're moving from sort of this lift and shift from their on-prem into the cloud, what does that mean to them for spend? So now if you're looking at the consistency around sort of the performance and the total cost of running this to their insights, to the conclusions, less time, more money in their pocket and maybe a reduction for their own customers so they can provide better for the customer side. What you're actually seeing is that's the challenge that they're facing in that landscape that they're driving towards that they need guidance and help with towards that. And we find AMD lends itself well to that scale out architecture that connects so well with how cloud microservices are run today. >> It's not surprising to hear that. Keith, what other tips and tricks do you have for CIOs and CTOs trying to reduce FinOps and continue to excel as they're building out? >> Yeah, so there were a couple of other insights that we learned this year. One of those two insights that I'd like to mention is that it's not always obvious what size and shape infrastructure you need to acquire to maximize your cost productions, right? So we found that smaller instance types were by and large had a better TCO than larger instances even across the exact same configurations, we kept everything else the same. Smaller instances had a better price performance ratio than the larger instances. The other thing that we discovered this year that was really interesting, we did a bit of a cost analysis on networking. And largely because we're distributed system, we can scan span across availability zones, we can span across regions, right? And one of the things we discovered this year is the amount of cost for transferring data between availability zones and the amount of cost for transferring data across regions at least in the United States was the same. So you could potentially get more resiliency by spanning your infrastructure across regions, then you would necessarily just spanning across availability zones. So you could be across multiple regions at the same cost as you were across availability zones, which for something like CockroachDB, we were designed to support those workloads is a really big and important thing for us. Now you have to be very particular about where you're purchasing your infrastructure and where those regions are. Because those data transfer rates change depending on what the source and the target is. But at least within the United States, we found that there was a strong correlation to being more survivable if you were in a multi-region deployment and the cost stayed pretty flat. >> That's interesting. So it's interesting to see what the correlation is between things and when you think there may be relationship between variables and when there maybe isn't. So on that note, since it seems like you're both always learning, I can imagine, what are you excited to test or learn about looking forward? Jeff, let's start with you actually. >> For sort of future testing. One of those things is certainly those more scale out sort of workloads with respect to showing scale. Meaning as I'm increasing the working set, as I'm increasing the number of connections, variability is another big thing of showing that minimization from run to run because performance is interesting but consistency is better. And as the lower side is from the instant sizes as I was talking about earlier, a (indistinct) architecture lends itself so well to it because they have the local caching and the CCDs that you can now put a number of vCPUs that will benefit from that delivery of the local caching and drive better performance at the lower side for that scale out sort of architecture, which is so consistent with the microservices. So I would be looking for more of those dimensional testings variability across a variety of workloads that you can go from memory intense workloads to database persistence store as well as a blend of the two, Kafka, et cetera. So there's a great breath and depth of testing that I am looking for and to more connect with sort of the CTOs and CIOs, the higher level that really show them that that CapEx, OpEx, sustainability and provide a bit more around that side of it because those are are the big things that they're focused on as well as security, the fact that based on working sets et cetera, AMD has the ability with confidential compute around those kind of offerings that can start to drive to those outcomes and help from what the CTOs and CIOs are looking for from compliance as well. So set them out (indistinct). >> So you're excited about a lot. No, that's great. That means you're very excited about the future. >> It's a journey that continues as Keith knows, there's always something new. >> Yeah, absolutely. What about you Keith? What is the most excited on the journey? >> Yeah, there are a couple of things I'd like to see us test next year. One of those is to test a multi-region CockroachDB config. We have a lot of customers running in that configuration and production but we haven't scaled that testing up to the same breadth that we we do with our single region testing which is what we've based the cloud report on for the past four years. The other thing that I'd really love to see us do,, I'm a Kubernetes SME, at least that's kind of my technical background. I would love to see us get to a spot where we're comparing the performance of raw EC2 instances to using that same infrastructure running CockroachDB via EKS and kind of see what the differences are there. The vast majority of CockroachDB customers are running at least a portion of their infrastructure in Kubernetes. So I feel like that would be a real great value add to the report for the next time that we go around but go about publishing it. >> If I don't mind adding to that just to volley it back for a moment. And also as I was saying about the ScaleOut and how it leverages our AMD architecture so well with EKS specifically around the spin up, spin down. So you think of a whole development life cycle. As they grow and shrink the resources over time, time of those spin ups to spin downs are expensive. So that has to be as reduced as much as possible. And I think they'll see a lot of benefits in AMD's architecture with EKS running on it as well. >> The future is bright. There's a lot of hype about many of the technologies that you both just mentioned, so I'm very curious to see what the next cloud report looks like. Thank you Keith, and the team for the labor of love that you put into that every year. And Jeff, I hope that you continue to be as well positioned as everyone's innovation journey continues. Keith and Jeff, thank you so much for being on the show with us today. As you know, this is a continuation of our coverage of AWS re:Invent here on theCUBE. My name's Savannah Peterson and we'll see you for our next fascinating segment. (upbeat music)

>> (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)

>>The cube presents Koon and cloud native con Europe, 2022, brought to you by red hat, the cloud native computing foundation and its ecosystem partners. >>Welcome to Valencia Spain and CubeCon cloud native con Europe, 2022 I'm cube Townsend, along with Paul Gill, senior editor, enterprise architecture at Silicon angle. We are talking to some incredible folks this week, continuing the conversation around enabling developers to do their work. Paul you've said that this conference is about developers. What are you finding key as a theme running throughout the show >>That that developers really need a whole set of special tools. You know, it's not the end user, the end user tools, the end user access controls the authentication it's developers need a need their own to live their in their own environment. They need their own workflow tools, their own collaboration and their own security. And that's where teleport comes in. >>So speaking of teleport, we have Michael fork, chief marking our officer at teleport new world role for you. First, tell me about how long have you been at teleport now >>Going on seven or eight months now, >>Seven or eight months in this fast moving market. I'm I'm going to tell you a painful experience I've had in this new world. We've built applications. We've moved fast audits come in. The auditors have come in and they said, you know what, who authorized this change to the cluster? And we'll go into the change ticket and say, this person authorized the changes and the change ticket. And then they'll ask for trace back. Okay. Show me the change. What do it mean? Show you the changes. It just happened. >>Yeah. Check, check GitHub. >>Yeah, check GI, get, see, we, we, we, we said we were gonna make the changes, the change happen. That's not enough. What are CU, how are you helping customers solve this access control and audit problem? >>Yeah, that's a great question. There're kind of, there're kind of two, two sides to the puzzle. And actually I think that the intro hits it. Well, you you've talked about kind of developer experience needing needing tools to more efficiently do the job as a practitioner. And you're coming at it from kind of a security and compliance angle. And there's a tension between both of those teams. It's like, you know, there's, there's a tension between dev and ops before we created DevOps. There's also a tension between kind of security teams and developers. So we've created dev SecOps. What that means is you need an easy way for developers to get access, access to the resources they needed through their jobs. That's, you know, Linux hosts and databases and Kubernetes clusters and, you know, monitoring dashboards and managing all of those credentials is quite cumbersome. If I need to access a dozen systems, then you know, I'm using SSH keys to access this. >>I have admin credentials for my database. I I'm going through a VPN to access an internal dashboard, teleport, consolidates, all of that access into a single login via your identity provider, Okta active directory, but then on the security and compliance side, we make it really easy for that compliance officer. When they say, show me that change, we have all of the audit logs. That's that show exactly what changes Keith made when he logged into, into that system. And in fact, one of the booths behind here is talking about E B P F a modern way to get that kind of kernel level grade granularity. We build all of that observability into teleport to make the security and compliance teams happy. And the engineering teams a lot more productive. >>Where do the, the access control tools like Okta, you mentioned fall short. I mean, why, why is there a need for your level of, of control at the control plane? >>Yeah. When you, when you start to talk about authorization, authentication, audit at the infrastructure level, each of these technologies has its own way of managing what kind of in, in the jargon often and Ze, right? Authentication authorization. So you have SSH for, for Linux. Kubernetes has its own way of doing authorization. All of the database providers have their own way and it's quite complicated, right? It's, it's much different. So, you know, if I'm gonna access office 365 or I'm gonna a access Salesforce, right. I'm really talking about the HTTP protocol. It's relatively trivial to implement single sign on for web-based applications. But when we start talking about things that are happening at the Linux kernel level, or with Kubernetes, it's quite complicated to build those integrations. And that's where teleport extends what you have with your IDP. So for instance, Okta, lots of our customers use Okta as their identity provider, but then teleport takes those roles and applies them and enforces them at the actual infrastructure level. >>So if I'm a lay developer, I'm looking at this thinking, you know, I, I have service mesh, I've implemented link D SEO or something to that level. And I also have Ansible and Ansible has security, etcetera. What, what role, or how does that integrate to all together from a big picture perspective? >>Yeah. So >>What, one of the, kind of the meta themes at teleport is we, we like to, we like to say that we are fighting complexity cuz as we build new technologies, we tend to run the new tech on top of the old tech. Whereas for instance, when you buy a new car, you typically don't, you know, hook the old car to the back and then pull it around with you. Right? We, we replace old technology with new technology, but in infrastructure that doesn't happen as often. And so you end up with kind of layers of complexity with one protocol sitting on top of another protocol on top of another protocol. And what teleport does is for the access control plane, we, we kind of replace the legacy ways of doing authentication authorization and audit with a new modern experience. But we allow you to continue to use the existing tools. >>So we don't replace, for instance, you know, your configuration management system, you can keep using Ansible or, or salt or Jenkins, but teleport now is gonna give those, those scripts or those pipelines in identity that you can define. What, what should Ansible be able to do? Right? If, cuz people are worried about supply chain attacks, if a, if a vulnerable dependency gets introduced into your supply chain pipeline and your kind of Ansible playbook goes crazy and starts deploying that vulnerability everywhere, that's probably something you wanna limit with teleport. You can limit that with an identity, but you can still use the tools that you're, that you're used to. >>So how do I guarantee something like an ex-employee doesn't come in and, and initiate Ansible script that was sitting in the background just waiting to happen until, you know, they left. >>Yeah. Great question. It's there's kind of the, the, the great resignation that's happening. We did a survey where actually we asked the question kind of, you know, can you guarantee that X employees can no longer access your infrastructure? And shockingly like 89% of companies could not guarantee that it's like, wow, that's like that should, that should be a headline somewhere. And we actually just learned that there are on the dark web, there are people that are targeting current employees of Netflix and Uber and trying to buy credentials of those employees to the infrastructure. So it's a big problem with teleport. We solve this in a really easy, transparent way for developers. Everything that we do is based on short lift certificates. So unlike a SSH key, which exists until you decommission it, shortlist certificates by, by default expire. And if you don't reissue them based on a new login based on the identity, then, then you can't do anything. So even a stolen credential kind of the it's value decreases dramatically over time. >>So that statistic or four out of five companies can't guarantee X employees can't access infrastructure. Why is simply removing the employee from the, you know, from the L app or directory decommissioning their login credentials. Why is that not sufficient? >>Well, it, it depends on if everything is integrated into your identity provider and because of the complexities of accessing infrastructure, we know that developers are creative people. And by, by kind of by definition, they're able to create systems to make their lives easier. So one thing that we see developers doing is kind of copying an SSH key to a local notepad on, on their computer. So they essentially can take that credential out of a vault. They can put it somewhere that's easier for them to access. And if you're not rotating that credential, then I can also, you know, copy it to a, to a personal device as well. Same thing for shared admin credentials. So the, the, the issue is that those credentials are not completely managed in a unified way that enables the developer to not go around the system in order to make their lives easier. >>But rather to actually use the system, there's a, there's a market called privilege access management that a lot of enterprises are using to kind of manage credentials for their developers, but it's notoriously disruptive to developer workflows. And so developers kind of go around the system in order to make their jobs easier. What teleport does is we obviate the need to go around the system, cuz the simplest thing is just to come in in the morning, log in one time to my identity provider. And now I have access to all of my servers, all of my databases, all of my Kubernetes clusters with a short lift certificate, that's completely transparent. And does >>This apply to, to your, both your local and your cloud accounts? >>Yes. Yes, exactly. >>So as a security company, what's driving the increase in security breaches. Is it the lack of developer hygiene? Is it this ex-employee great resignation bill. Is it external intruders? What's driving security breaches today. >>Yes. >>It's you know, it's, it's all of those things. I think if I had to put, give you a one word answer, I would say complexity. The systems that we are building are just massively complex, right? Look at how many vendors there are at this show in order to make Kubernetes easy to use, to do what its promises. It's just, we're building very complex systems. When you build complex systems, there's a lot of back doors, we call it kind of a tax surface. And that's why for every new thing that we introduce, we also need to think about how do we remove old layers of the stack so that we can simplify so that we can consolidate and take advantage of the power of something like Kubernetes without introducing security vulnerabilities. >>One of the problems or challenges with security solutions is, you know, you there's this complexity versus flexibility knob that you, you need to be careful of. What's the deployment experience in integration experience for deploying teleport. >>Yeah, it's it, we built it to be cloud native to feel like any other kind of cloud native or Kubernetes like solution. So you basically, you deploy it using helm chart, you deploy it using containers and we take care of all of the auto configuration and auto update. So that it's just, it's, it's part of your stack and you manage it using the same automation that you use to manage everything else. That's a, that's a big kind of installation and developer experience. Part of it. If it's complex to use, then not only are developers not gonna use it. Operations teams are not gonna want to have to deal with it. And then you're left with doing things the old way, which is very unsatisfactory for everybody. >>How does Kubernetes change the security equation? Are there vulnerabilities? It introduces to the, to the stack that maybe companies aren't aware of >>Almost by definition. Yes. Kind of any new technology is gonna introduce new security vulnerabilities. That's the that's that is the result of the complexity, which is, there are things that you just don't know when you introduce new components. I think kind of all of the supply chain vulnerabilities are our way of looking at that, which is we have, you know, Kubernetes is itself built on a lot of dependencies. Those dependencies themselves could have security vulnerabilities. You might have a package that's maintained by one kind of hobbyist developer, but that's actually deployed across hundreds of thousands of applications across, across the internet. So again, it's about one understanding that that complexity exists and then saying, is there a way that we can kind of layer on a solution that provides a common layer to let us kind of avoid that complexity and say, okay, every critical action needs to be authorized with an identity that way if it's automated or if it's human, I have that level of assurance that a hacked Ansible pipeline is not going to be able to introduce vulnerabilities across my entire infrastructure. >>So one of the challenges for CIOs and CTOs, it's the lack of developer resources and another resulting pain point that compounds that issue is rework due to security audits is teleport a source of truth that when a auditor comes in to audit a, a, a, a C I C D pipeline that the developer or, or operations team can just say, Hey, here's, self-service get what you need. And come back to us with any questions or is there a second set of tools we have to use to get that audit and compliance reporting? >>Yeah, it's teleport can be that single source of truth. We can also integrate with your other systems so you can export all of the, what we call access logs. So every, every behavior that took place, every query that was run on a database, every, you know, curl command that was run on a Lennox, host, teleport is creating a log of that. And so you can go in and you can filter and you can view those, those actions within teleport. But we also integrate with other systems that, that people are using, you have its Splunk or Datadog or whatever other tool chain it's really important that we integrate, but you can also use teleport as that single source. So >>You can work with the observability suites that are now being >>Installed. Yeah, there, the, the wonderful thing about kind of an ecosystem like Kubernetes is there's a lot of standardization. You can pick your preferred tool, but under the hood, the protocols for taking a log and putting it in another system are standardized. And so we can integrate with any of the tools that developers are already using. >>So how big is teleport when I'm thinking about a, from a couple of things big as in what's the footprint and then from a developer operations team overhead, is this kind of a set and forget it, how much care feed and maintenance does it >>Need? So it's very lightweight. We basically have kind of two components. There's the, the access proxy that sits in front of your infrastructure. And that's what enables us to, you know, regardless of the complexity that sits across your multi data center footprint, your traditional applications, running on windows, your, your, your modern applications running on, you know, Linux and Kubernetes, we provide seamless access to all of that. And then there's an agent that runs on all of your hosts. And this is the part that can be deployed using yo helm or any other kind of cloud native deployment methodology that enables us to do the, the granular application level audit. For instance, what queries are actually being run on CockroachDB or on, on Postgres, you know, what, what CIS calls are running on Linnux kernel, very lightweight automation can be used to install, manage, upgrade all of it. And so from an operations perspective, kind of bringing in teleport shouldn't be any more complicated than running any application on a container. That's, that's the design goal and what we built for our customers. >>If I'm in a hybrid environment, I'm transitioning, I'm making the migration to teleport. Is this a team? Is this a solution that sits only on the Kubernetes cloud native side? Or is this something that I can trans transition to initially, and then migrate all of my applications to, as I transition to cloud native? >>Yeah. We, there are kind of, no, there are no cloud native dependencies for teleport. Meaning if you are, you're a hundred percent windows shop, then we support for instance, RDP. That's the way in which windows handles room access. If you have some applications that are running on Linux, we can support that as well. If you've got kind of the, you know, the complete opposite in the spectrum, you're doing everything, cloud native containers, Kubernetes, everything. We also support that. >>Well, Michael, I really appreciate you stopping by and sharing the teleport story. Security is becoming an obvious pain point for cloud native and container management. And teleport has a really good story around ensuring compliance and security from Licia Spain. I'm Keith towns, along with Paul Gillon and you're watching the cue, the, the leader, not the, the leader two, the high take tech coverage.

(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.

>> Narrator: Live from Boston, Massachusetts, it's theCUBE covering OpenStack Summit 2017. Brought to you by the OpenStack Foundation, Red Hat, and additional ecosystem support. (techno music) >> And we're back. I'm Stu Miniman joined by my co-host, John Troyer. Happy to welcome to the program two of the keynote speakers this morning, worked on some of the container activity, Kendall Nelson, who's a Upstream Developer Advocate with the OpenStack Foundation. >> Yep. >> And John Griffith, who's a Principal Engineer from NetApp, excuse me, through the SolidFire acquisition. Thank you so much both for joining. >> Kendall Nelson: Yeah. Thank you. >> John Griffith: Thanks for havin' us. >> Stu Miniman: So you see-- >> Yeah. >> When we have any slip-ups when we're live, we just run through it. >> Run through it. >> Kendall, you ever heard of something like that happening? >> Kendall Nelson: Yeah. Yeah. That might've happened this morning a little bit. (laughs) >> So, you know, let's start with the keynote this morning. I tell ya, we're pretty impressed with the demos. Sometimes the demo gods don't always live up to expectations. >> Kendall Nelson: Yeah. >> But maybe share with our audience just a little bit about kind of the goals, what you were looking to accomplish. >> Yeah. Sure. So basically what we set out to do was once the ironic nodes were spun up, we wanted to set up a standalone cinder service and use Docker Compose to do that so that we could do an example of creating a volume and then attaching it to a local instance and kind of showing the multiple backend capabilities of Cinder, so... >> Yeah, so the idea was to show how easy it is to deploy Cinder. Right? So and then plug that into that Kubernetes deployment using a flex volume plugin and-- >> Stu Miniman: Yeah. >> Voila. >> It was funny. I saw some comments on Twitter that were like, "Well, maybe we're showing Management that it's not, you know, a wizard that you just click, click, click-- >> John Griffith: Right. >> Kendall Nelson: Yeah. >> "And everything's done." There is some complexity here. You do want to have some people that know what they're doing 'cause things can break. >> Kendall Nelson: Yeah. >> I love that the container stuff was called ironic. The bare metal was ironic because-- >> Kendall Nelson: Yeah. >> Right. When you think OpenStack at first, it was like, "Oh. This is virtualized infrastructure." And therefore when containers first came out, it was like, "Wait. It's shifting. It's going away from virtualization." John, you've been on Cinder. You helped start Cinder. >> Right. >> So maybe you could give us a little bit about historical view as to where that came from and where it's goin'. Yeah. >> Yeah. It's kind of interesting, 'cause it... You're absolutely right. There was a point where, in the beginning, where virtualization was everything. Right? Ironic actually, I think it really started more of a means to an end to figure out a better way to deploy OpenStack. And then what happened was, as people started to realize, "Oh, hey. Wait." You know, "This whole bare metal thing and running these cloud services on bare metal and bare metal clouds, this is a really cool thing. There's a lot of merit here." So then it kind of grew and took on its own thing after that. So it's pretty cool. There's a lot of options, a lot of choices, a lot of different ways to run a cloud now, so... >> Kendall Nelson: Yeah. >> You want to comment on that Kendall, or... >> Oh, no. Just there are definitely tons of ways you can run a cloud and open infrastructure is really interesting and growing. >> That has been one thing that we've noticed here at the show. So my first summit, so it was really interesting to me as an outsider, right, trying to perceive the shape of OpenStack. Right? Here the message has actually been very clear. We're no longer having to have a one winner... You know, one-size-fits-all kind of cloud world. Like we had that fight a couple of years ago. It's clear there's going to be multiple clouds, multiple places, multiple form factors, and it was very nice people... An acknowledgement of the ecosystem, that there's a whole open source ecosystem of containers and of other open source projects that have grown up all around OpenStack, so... But I want to talk a little bit about the... And the fact that containers and Kubernetes and that app layer is actually... Doesn't concern itself with the infrastructure so much so actually is a great fit for sitting on top of or... And adjacent to OpenStack. Can you all talk a little bit about the perception here that you see with the end users and cloud builders that are here at the show and how are they starting to use containers. Do they understand the way these two things fit together? >> Yeah. I think that we had a lot of talks submitted that were focused on containers, and I was just standing outside the room trying to get into a Women of OpenStack event, and the number of people that came pouring out that were interested in the container stack was amazing. And I definitely think people are getting more into that and using it with OpenStack is a growing direction in the community. There are couple new projects that are growing that are containers-focused, like... One just came into the projects, OpenStack Helm. And that's a AT&T effort to use... I think it's Kubernetes with OpenStack. So yeah, tons. >> So yeah, it's interesting. I think the last couple of years there's been a huge uptick in the interest of containers, and not just in containers of course, but actually bringing those together with OpenStack and actually running containers on OpenStack as the infrastructure. 'Cause to your point, what everybody wants to see, basically, is commoditized, automated and generic infrastructure. Right? And OpenStack does a really good job of that. And as people start to kind of realize that OpenStack isn't as hard and scary as it used to be... You know, 'cause for a few years there it was pretty difficult and scary. It's gotten a lot better. So deployment, maintaining, stuff like that, it's not so bad, so it's actually a really good solution to build containers on. >> Well, in fact, I mean, OpenStack has that history, right? So you've been solving a lot of problems. Right now the container world, both on the docker side and Kubernetes as well, you're dealing with storage drivers-- >> John Griffith: Yeah. >> Networking overlays-- >> Right. >> Multi-tenancy security, all those things that previous generations of technology have had to solve. And in fact, I mean, you know, right now, I'd say storage and storage interfaces actually are one of the interesting challenges that docker and Kubernetes and all that level of containers and container orchestration and spacing... I mean, it seems like... Has OpenStack already solved, in some way, it's already solved some of these problems with things like Cinder? >> Abso... Yeah. >> John Troyer: And possibly is there an application to containers directly? >> Absolutely. I mean, I think the thing about all of this... And there's a number of us from the OpenStack community on the Cinder side as well as the networking side, too-- >> Yeah. >> Because that's another one of those problem spaces. That are actually taking active roles and participating in the Kubernetes communities and the docker communities to try and kind of help with solving the problems over on that side, right? And moving forward. The fact is is storage is, it's kind of boring, but it's hard. Everybody thinks-- >> John Troyer: It's not boring. >> Yeah. >> It's really awesomely hard. Yeah. >> Everybody thinks it's, "Oh, I'll just do my own." It's actually a hard thing to get right, and you learn a lot over the last seven years of OpenStack. >> Yeah. >> We've learned a lot in production, and I think there's a lot to be learned from what we've done and how things could be going forward with other projects and new technologies to kind of learn from those lessons and make 'em better, so... >> Yeah. >> In terms of multicloud, hybrid cloud world that we're seeing, right? What do you see as the role of OpenStack in that kind of a multicloud deployments now? >> OpenStack can be used in a lot of different ways. It can be on top of containers or in containers. You can orchestrate containers with OpenStack. That's like the... Depending on the use case, you can plug and play a lot of different parts of it. On all the projects, we're trying to move to standalone sort of services, so that you can use them more easily with other technologies. >> Well, and part of your demo this morning, you were pulling out of a containerized repo somehow. So is that kind of a path forward for the mainline OpenStack core? >> So personally, I think it would be a pretty cool way to go forward, right? It would make things a lot easier, a lot simpler. And kind of to your point about hybrid cloud, the thing that's interesting is people have been talking about hybrid cloud for a long time. What's most interesting these days though is containers and things like Kubernetes and stuff, they're actually making hybrid cloud something that's really feasible and possible, right? Because now, if I'm running on a cloud provider, whether it's OpenStack, Amazon, Google, DigitalOcean, it doesn't matter anymore, right? Because all of that stuff in my app is encapsulated in the container. So hybrid cloud might actually become a reality, right? The one thing that's missing still (John Troyer laughs) is data, right? (Kendall Nelson laughs) Data gravity and that whole thing. So if we can figure that out, we've actually got somethin', I think. >> Interesting comment. You know, hybrid cloud a reality. I mean, we know the public cloud here, it's real. >> Yeah. >> With the Kubernetes piece, doesn't that kind of pull together some... Really enable some of that hybrid strategy for OpenStack, which I felt like two or three years ago it was like, "No, no, no. Don't do public cloud. >> John Griffith: Yeah. >> "It's expensive and (laughter) hard or something. "And yeah, infrastructure's easy and free, right?" (laughter) Wait, no. I think I missed that somewhere. (laughter) But yeah, it feels like you're right at the space that enables some of those hybrid and multicloud capabilities. >> Well, and the thing that's interesting is if you look at things like Swarm and Kubernetes and stuff like that, right? One of the first things that they all build are cloud providers, whether OpenStack, AWS, they're all in there, right? So for Swarm, it's pretty awesome. I did a demo about a year ago of using Amazon and using OpenStack, right? And running the exact same workloads the exact same way with the exact same tools, all from Docker machine and Swarm. It was fantastic, and now you can do that with Kubernetes. I mean, now that's just... There's nothing impressive. It's just normal, right? (Kendall Nelson laughs) That's what you do. (laughs) >> I love the demos this morning because they actually were, they were CLI. They were command-line driven, right? >> Kendall Nelson: Yeah. >> I felt at some conferences, you see kind of wizards and GUIs and things like that, but here they-- >> Yeah. >> They blew up the terminal and you were typing. It looked like you were actually typing. >> Kendall Nelson: Oh, yeah. (laughter) >> John Griffith: She was. >> And I actually like the other demo that went on this morning too, where they... The interop demo, right? >> Mm-hmm. >> John Troyer: They spun up 15 different OpenStack clouds-- >> Yeah. >> From different providers on the fly, right there, and then hooked up a CockroachDB, a huge cluster with all of them, right? >> Kendall Nelson: Yeah. >> Can you maybe talk... I just described it, but can you maybe talk a little bit about... That seemed actually super cool and surprising that that would happen that... You could script all that that it could real-time on stage. >> Yeah. I don't know if you, like, noticed, but after our little flub-up (laughs) some of the people during the interop challenge, they would raise their hand like, "Oh, yeah. I'm ready." And then there were some people that didn't raise their hands. Like, I'm sure things went wrong (John Troyer laughs) and with other people, too. So it was kind of interesting to see that it's really happening. There are people succeeding and not quite gettin' there and it definitely is all on the fly, for sure. >> Well, we talked yesterday to CTO Red Hat, and he was talking same thing. No, it's simpler, but you're still making a complicated distributed computing system. >> Kendall Nelson: Oh, definitely. >> Right? There are a lot of... This is not a... There are a lot of moving parts here. >> Kendall Nelson: Yeah. >> Yeah. >> Well, it's funny, 'cause I've been around for a while, right? So I remember what it was like to actually build these things on your own. (laughs) Right? And this is way better, (laughter) so-- >> So it gets your seal of approval? We have reached a point of-- >> Yeah. >> Of usability and maintainability? >> Yeah, and it's just going to keep gettin' better, right? You know, like the interop challenge, the thing that's awesome there is, so they use Ansible, and they talk to 20 different clouds and-- >> Kendall Nelson: Yeah. >> And it works. I mean, it's awesome. It's great. >> Kendall Nelson: Yeah. >> So I guess I'm hearing containers didn't kill OpenStack, as a matter of fact, it might enable the next generation-- >> Kendall Nelson: Yeah. >> Of what's going on, so-- >> John Griffith: Yeah. >> How about serverless? When do we get to see that in here? I actually was lookin' real quick. There's a Functions as a Service session that somebody's doing, but any commentary as to where that fits into OpenStack? >> Go ahead. (laughs) >> So I'm kind of mixed on the serverless stuff, especially in a... In a public cloud, I get it, 'cause then I just call it somebody else's server, right? >> Stu Miniman: Yeah. >> In a private context, it's something that I haven't really quite wrapped my head around yet. I think it's going to happen. I mean, there's no doubt about it. >> Kendall Nelson: Yeah. >> I just don't know exactly what that looks like for me. I'm more interested right now in figuring out how to do awesome storage in things like Kubernetes and stuff like that, and then once we get past that, then I'll start thinking about serverless. >> Yeah. >> Yeah. >> 'Cause where I guess I see is... At like an IoT edge use case where I'm leveraging a container architecture that's serverless driven, that's where-- >> Yeah. >> It kind of fits, and sometimes that seems to be an extension of the public cloud, rather than... To the edge of the public cloud rather than the data center driven-- >> John Griffith: Yeah. >> But yeah. >> Well, that's kind of interesting, actually, because in that context, I do have some experience with some folks that are deploying that model now, and what they're doing is they're doing a mini OpenStack deployment on the edge-- >> Stu Miniman: Yep. >> And using Cinder and Instance and everything else, and then pushing, and as soon as they push that out to the public, they destroy what they had, and they start over, right? And so it's really... It's actually really interesting. And the economics, depending on the scale and everything else, you start adding it up, it's phenomenal, so... >> Well, you two are both plugged into the user community, the hands-on community. What's the mood of the community this year? Like I said, my first year, everybody seems engaged. I've just run in randomly to people that are spinning up their first clouds right now in 2017. So it seems like there's a lot of people here for the first time excited to get started. What do you think the mood of the user community is like? >> I think it's pretty good. I actually... So at the beginning of the week, I helped to run the OpenStack Upstream Institute, which is teaching people how to contribute to the Upstream Community. And there were a fair amount of users there. There are normally a lot of operators and then just a set of devs, and it seemed like there were a lot more operators and users looking that weren't originally interested in contributing Upstream that are now looking into those things. And at our... We had a presence at DockerCon, actually. We had a booth there, and there were a ton of users that were coming and talking to us, and like, "How can I use OpenStack with containers?" So it's, like, getting more interest with every day and growing rapidly, so... >> That's great. >> Yeah. >> All right. Well, want to thank both of you for joining us. I think this went flawless on the interview. (laughter) And yeah, thanks so much. >> Yeah. >> All these things happen... Live is forgiving, as we say on theCUBE and absolutely going forward. So thanks so much for joining us. >> John Griffith: Thank you. John and I will be back with more coverage here from the OpenStack Summit in Boston. You're watching theCUBE. (funky techno music)

(energetic music) >> Narrator: Live from Boston, Massachusetts it's the Cube, covering OpenStack Summit 2017 brought to you by the OpenStack Foundation, Red Hat, and additional ecosystem support. >> Hi and welcome back to SiliconANGLE TV's production of the Cube here at OpenStack Summit 2017 in Boston. I'm Stu Miniman joined with my co-host for the week, John Troyer. As you can see behind us, the day 2 keynotes letting out. John, it's always interesting to look at these shows. They had some demos that were awesome, a couple of demos were the demo gods were not smiling on them. They had Edward Snowden live via Q&A. They had Brian Stevens, who we're going to be talking with in a little bit, the CTO of Google, who was on The Early Start. For me, they're a little up and down. There's some of the vendor pitches in there, people are like, "Oh I have a great demo," and then you say, "Come to my booth "and see a bunch of my sessions." So, a little bit uneven and disjointed, which has been a some of the feedback you get about OpenStack in general over the last few years as to all those pieces come together. But yeah, what are your early thoughts coming out of the day 2 keynote? >> Well, it was definitely a keynote focused at the OpenStack community. We started off with open source and talking about the importance of open source, which is a little bit odd, because everyone here know that. I did like the message that OpenStack was composed of different projects, that it was a piece of the puzzle, not the whole puzzle. You and I both noted VMware's Scott Lowe tweeted, "It's good to the OpenStack Foundation talking about being a part of the overall solution, not the overall solution." I mean, as one example, they mentioned using etcd, which is a distributed key value store, instead of writing their own. Etcd powers Kubernetes. Your would be insane in 2017 to rewrite or distribute a key value pair, sorb at this point. Because, it's just out there, it's mature. You know, OpenStack has been around for seven years. There's been a lot of ecosystem grown up around them. >> Yeah, yeah. A couple of pieces on that. One is, there was a message about like, oh I can now take the individual components of OpenStack. I could actually do that before. I've noted, I've talked to a number of software companies, that when you did down into what they're doing, oh what do you know, there's, you know, there's Syndrr. Or, there's, you know, something in there, just as when I use AWS, I can use some of the individual components, same thing with OpenStack. It's not a monolith. There are the individual pieces. But, they're highlighting that a little bit more. They're saying use some of the pieces. The other thing, on the open source in general, they noted that like, in the artificial intelligence machine learning space, like, everyone that you see is using open source. Everything from Google and TensorFlow, is one that gets highlighted a lot. Amazon made a big push at their show about what they're doing with, you know, some of the machine learning. I can't remember right now, the program on there. But, right, in some of these emerging spaces, open source is the defacto way to do that. We had, in one of the conversations we had yesterday with one of the Cysco Distinguished Engineers, you know, it used to be standards. Now, open source really drives a lot of that. I actually got a quick conversation with Martin Casado, who had, you know, worked on a lot of open source things before Vmware acquired him. And, now he's at Andreessen Horowitz looking at all the open source models. So, unfortunately Martin didn't have enough time to come on the program, but we've had him on many times. Yeah, so sometime he's going to do that. >> Stu, I have a question. >> Stu: Yeah. >> The message today of being part of an ecosystem and being a componentized, open source set of projects, does that detract or add to this conversation around OpenStack Core versus Big Tent? >> I think Big Tent is dying. We talked to a number of the participants yesterday and said it was a little overblown. It does not mean that some pieces might still get worked on, but it's the core components. And you know, when dug into the survey, how many of the pieces do we really need? We want to make sure the Core works. I can have that distribution if I want to do what is OpenStack. When they highlighted those components, it wasn't 27 different projects there. You know, I think it was a handful of like six. >> Yeah. >> That were there. So, you know Swift and Syndrr, some interesting, cool little graphics. It was ironic, I tell you. The little graphic there, that was like a scary looking bear. It's like, I wouldn't want to run into him in a cartoon alley. Uh, but (laughs). >> Yeah, I did tweet. Yeah, there was an angry bear, kind of a poisonous spider, and a horse's behind. So, I'm not quite sure about the marketing there. But (laughs). >> What is the message you're sending? But, there's some fun. We've got, you know, Mark Collier and Jonathan Bryce coming on soon. We can ask them, you know, was this the community? And are there just some people that have a funny sense of humor, and this is how they show it? >> I did love the demos in today's talk, Stu. I especially liked, they spun up, live on stage, 15 from scratch, OpenStack clouds. And then, had them all join a CockroachDB cluster. I thought that was kind of cool and amazing. >> Yeah, absolutely. You talk about that hybrid, multi cloud world, showing it, you know, in reality, how that works. Pretty neat, and you know, you can actually see some applicability as to how that would fit into a customer environment. And, kudos to all the people. I mean, these were live, no net demos, not Camtasia, not some prerecorded things. Because like, oh wait, this thing's not quite ready to be able to be bootable, or you know, let me come in. I mean, they're up there on stage doing it. The wifi all seemed to work fine. That wasn't a challenge, but yeah, it was pretty cool. >> Well again, trying to give the message that OpenStack is indeed not a science project. That it's live, that it's configurable, that it's stable, that it's installable. And, I think that kind of message of stability, and configurability, and simplicity maybe is one of the ones they're trying to hit here today. >> Yeah, last thing I want to hit on, John, is I want to get your opinion. We throw out the term "open" a bunch. And, I'm watching some of the other industry things, and they say "open" when they mean "choice," as opposed to "open" as in "open source." So, you know, we see Google here, and Google talks about open. So many things that are now open source, a lot of times started out as a Google white paper or something. As we all say, we're all using open source which Google was using 10 years ago, right? You know, MapReduce, and Borg, and Spanner, and some of those things eventually get their way out. I've got some view points on this, but love to get your take first, yeah. >> Well, I mean, definitely it was an homage to open source this morning. In some ways, it was kind of a dig at AWS and Amazon, which uses a lot of open source tools, but does not share back. You know, OpenStack is clearly open source, and they were emphasizing that. I don't know. What are your thoughts, Stu? >> Yeah, it's, customers now, it used to be if you said open source, you know, go back 10, 15 years, and it was like, ooh, no. Now, open source is, a lot of times, a plus, something that they're asking for. Many companies are contributing and engaging in that. OpenStack is a great example of companies that have participated, you know, in helping to build OpenStack. That being said, you know, I always go to, you know, what's the problem to be solved, what's the solution that solves it. And, if it happens to be a little bit pre standard, or not 100% open source, most companies are fine with that. We were at Red Hat Summit last week with the Cube though, and everything they do is 100% open source. They're building their business. Their customers are really happy. So, you know, open source still has a little bit of a double edged sword as to how you do it. But, you know, open source absolutely, there's no question of if open source, it's how much, and to what extent, and where it fits. >> Sure, there is an ecosystem of providers here. There's always lock-in when you make a technical choice. But, in this case, I think they've successfully were trying to show off that there is a choice of clouds. There is an open, a set of open source components that you can mix and match. And so, that actually ties in very well to the interview with Edward Snowden. >> Yeah, absolutely, yeah. It was, and last point. Edward Snowden, towards the end he said fear is, I think the quote was, "the most powerful weapon in the world today." From a political statement, is what he's doing. Fear in IT is a powerful weapon. We know that, you know, enterprise and inertia, you know, tend to go together. With my background in networking, I used to draw these timelines. And, say, from when the time the standard was done to when, you know, the early majority adopt, is often times a decade. So, the technology adoption, moving the operational, we know the people piece is always tough to do, moving my applications. We think people are definitely moving faster, but fear is definitely something that holds them back. What do you see, john? >> Sure, I think the through line of the whole morning was about choice and diversity. Edward Snowden talked about the centralization of information services like Facebook, Google, and Twitter. And I think, and I think by implication, Amazon. And, I think the message that he was giving to the OpenStack crowd was look, you are enabling a multitude of services and a multitude of clouds, and that actually is a lever, a cultural lever against the over centralization of commercial forces, which are a little bit outside people's control. >> Yeah, so John, thanks for helping me wrap up day one. As always, we welcome our audience to please send us feedback. John and I are both pretty active on Twitter, very easy to get in touch with. We are at so many shows. You can check out SiliconANGLE TV. See where we're at. If we're not at a show that you think we should be at, reach, there's contact information at the top. If there's guests that we should have on our program, we're always looking for feedback. Love to get, especially those end user stories, talking about with interesting startups. So, we've got two more days of live coverage. So, for John and myself, stay with us. And, thanks, as always, for watching The Cube. (exciting music)

(upbeat music) >> Announcer: Live from Silicon Valley, it's theCUBE, covering Google Cloud Next '17. >> Welcome back to theCUBE's coverage of Google Next 2017, 10,000 people are in San Francisco, SiliconANGLE media, we've got reporters there, as well as the Wikibon analysts. I've been up there for the analyst's event, some of the keynotes, and we're getting thought leaders, partners, really getting lots of viewpoints as to what's happening, not just in the Google Cloud, but really the multi-Cloud world. And that's why I'm really excited to bring back a guest that we've had on the program before, Craig Mcluckie, who, four months ago, was with Google, but he's now the CEO of Heptio, and he's also one of the co-creators of Kubernetes, which anybody that's watching the event, definitely has been hearing, plenty about Kubernete so, welcome back to the program. >> Thanks for having me back. >> Yeah, absolutely, I know you were part of, a little event that kind of went before the Google Cloud event, brought in some people in the Cloud ecosystem, talk about a lot was going on. Maybe start us off with, what led you to kind of pop out of Google, what is Heptio, and how does that kind of extend what you're doing with Kubernetes when you're at Google? >> Certainly. So Heptio is a company that has been created, by my co-founder Joe and myself, to bring Kubernetes-- >> Stu: That's Joe Beda. >> Joe Beda. >> Stu: Yeah. To bring Kubernetes to enterprises, and the thing that really motivated me to start this company was the sense that there was not a unfettered Kubernetes company in existence. I spoke to a lot of organizations, that were having tremendous success with Kubernetes. It was transforming the way they approached infrastructure management. It created new levels of portability for their workloads. But they wanted to use Kubernetes on their own terms, in ways that made sense to them. And, most every other organization that is creating a Kubernetes distro, has attached it to other technologies. It's either attached to an opinionated operating system, or it's attached to a specific cloud environment, or it's attached to a Paas, and it just didn't meet the way that most of the customers I saw wanted to use the technology. I felt that a key missing part of this ecosystem, was a company that would meet the open source community where it is and help customers that just needed a little bit more help. A little more help with training, bit of documentation support, and the tools they needed to make themselves successful in the environments that they wanted to operate in. And that's what motivated Joe and I to start this company. >> Yeah, and it's interesting, cause you look at the biggest contributors, Google's there, you've got Red Hat, you've got, as you said, people that have their viewpoint as to where that fits. I think that that helps the development overall, but maybe you can help us unpack there. Why do you want, is it separate? Is there that opinionated-ness? What's inherently sub-optimal about that? (laughing) >> I think part of the key value in Kubernetes is the fact that it supports a common framework in a highly heterogonous world. Meaning you can mix together a broad variety of things, to your needs. So you could mix together, the right operating system, in the right hosting environment, with the right networking stack. And you could run general applications that are then managed and performed in a very efficient and easy to use way. And, one of the things that I think is really important, is this idea that customers should have choice, they should be picking the infrastructure based on the merits of the infrastructure. They should pick the OS that works for them, and they should be able to put together a system that operates tremendously well. And, I think it's particularly critical, at this juncture, that a layer emerges that allows customers, and service providers, to mix together the sort of things that they want to use, and consume, in a way that's agnostic to the infrastructure and the operating environment. I see the mainstream cloud providers, taking us in some ways back to the world of the mainframe. If you think about what we're starting to see, with companies like Amazon, who are spectacularly successful in the market, is this world where you have this deeply vertically integrated service provider, that provides not only the compute, but also the set of core services, and almost everything else that you need to run. And, at the end of the day, it's getting to a point where, a customer has to kind of pick their service provider. And, you know, for using IBM, but it was also sub-optimal from an ecosystem perspective. It inhibited innovation in many ways. And it was the emergence of Wintel, that sort of Windows and Intel ecosystem that really opened up the vendor ecosystem, and drove a tremendous amount of innovation and advancement. And, you know, when I think about what enterprise customers want and need today, they want that abstraction. They want a safe way to separate out the set of services that run their business, the set of technologies that they build and maintain, from the underlying infrastructure. And I think that's what driving a lot of the popularity of Kubernetes, is this idea that it is a logical infrastructure abstraction, that lets you pick the environment that you operate in, purely based on the merits of the environment. >> Yeah, it's been a struggle, I mean, I know through my entire career in IT, we've had that discussion of "do I just standardize on what we have? Cause, the enterprise today, absolutely. Every time I put a new technology in, it doesn't displace, it adds to it. So, I talked to lots of customers, still using mainframe. They're using the Wintel stuff, they using public cloud, they're using, you know, yes and and and, and therefore, managing it, orchestrating it, doing all those pieces that are difficult. The challenge when I put an abstraction layer in, and one of the big challenges is, how to really get the full value out of the pieces that I had. Sam Ramji said that, when he was at Cloud Foundry, they were trying to make it so that you really don't care which cloud, whether it's on premises or public cloud environments. And he said one of the reasons he joined Google was because he felt you couldn't make, if you went least common denominator or something, there was things Google was doing that nobody else can do. So there's always that balance of, "can I put an abstraction layer or virtualize something, and take advantage of it?" Or "do I just go all in with one vendor?" I mean, IBM back in the day, did lots of great things to make it simple, and cloud is trying to make it simple, lots of things, Amazon of course, no doubt that they're trying to vertically integrate everything they would like to do. You know, all your services. So, where do you see that balance? And, it's interesting, does it solve customers the best to be able to say "okay, you can take your mess that you have", and therefore, is this a silver bullet to help them solve it? >> I think it's a really good point. And, consistently, as I look through history, a lot of the platforms that people have pursued, that created this sort of complete decoupling, introduced this lowest common denominator problem, where you had to trade off a set of things that you really wanted with the capabilities of the platform. And, you know, I think that absolutely, in some cases, it makes a tremendous amount of sense, to invest in a vendor specific technology. So let's take an example out of Google, Cloud Spanner. Cloud Spanner has, it's literally the only, globally consistent, well right now it's regionally consistent, but it's literally the only globally consistent relational store available. There is nothing like it. The CockroachDB folks are building something that emulates some of the behavior, but without the true time API, that sort of atomic clock, you know, crazy infrastructure that Google's built. It adds very little utility. And so, in certain applications and certain workloads, if what you really want is a globally replicated, highly consistent relational data store, there is literally only one provider on the planet that would deliver it, which is Google. However, you might look at, you know, something that Amazon provides, and they may have some other service. Perhaps you've already built something on RedShift, and you want to be able to use that. Or Microsoft might offer up some other technologies that make sense to you. And, I think it's really important for enterprises to have the option. There's times when, for a given workload, it makes tremendous amount of sense, to put on a vendor, if you're looking to run something that has, deep machine learning hooks, or needs some other science fiction technology that Google's bringing to the world. It makes sense to run that on Google. For applications that are potentially integrated into a productivity suite, if you're an Office 365 user, it probably makes sense to host it on Microsoft. And then, perhaps there's some other pieces that you run on Amazon. And I don't think it's going to be pick one cloud provider and live in the static world forever. I think the landscape is constantly evolving and shifting. And, one of the things technologies like Kubernetes provide is an option. An option to move, an option to decide which specific services you want to pull through and use in which application. Recognizing that those are going to bind you to that cloud provider in perpetuity, but not necessarily pulling the entirety of your IT structure through. >> Yeah, Craig, I'm curious. When I look out as to kind of the people that commentate on this space, one of the things they say "Kubernetes is interesting, but this whole hybrid cloud thing, kill all the on premises stuff, public cloud's really where it's at." I know when I talk to most companies, they got plenty of on premises stuff, most infrastructure that is bought is still, there's a lot of it going on premises. So companies are sorting out what applications go where, what data goes where. Diane Green, suddenly 5% of the world's data really is in the public cloud today. What's your view on kind of that on premises, public cloud piece, and Kubernetes' role there? >> Yeah, I think it's a great question. And I have had some really interesting conversations with CIOS in the past. I remember in my very earliest days, pooh-poohing the idea of the private cloud, and having a really intense CIO look across the thing and he was like "you will pry my data centers from my cold, dead hands". (Stu laughing) He literally said that to me. And so, there's certainly a lot of passion in this space, and I think, at the end of the day, one has to be pragmatic. You know, first of all, one has to recognize that, if you're an organization that has bought significant data center footprint, you're probably going to want to continue to use that asset that you've acquired, and that's, you're going to want to use that in perpetuity. If you're a company, and most large companies are also naturally heterogonous, meaning as you go through an acquisition, the acquired portion of your company may have a profoundly different IT portfolio. You know, may have a different set of environments. And so, I think the world certainly benefits from an abstraction layer that allows you to train your engineers with a certain set of skills, and then be highly decoupled from the infrastructure environment you run in. And I think, again, Kubernetes is delivering some of that promise in a way that I think really resonates with customers. >> Absolutely, and even, we've been telling people for years "stop building data centers"? You know, there's very few companies that want to build data centers even, yes Google talks about their data centers, but Amazon? Gets their data center space from lots of other players there. But, if I stop building data centers today, I'm going to have em for another 25 30 years, and even it, what am I going to owe myself? I talked to plenty of the big financial guys, they're not going to move all of their information. They want to have it under their control, whether it's their own data center, a hosted managed environment there. So, we're going to be living with this multi-cloud thing for a long time. >> There is another thing that I don't think people have fully internalized yet, which is in many ways, the way that cloud provider data centers are structured is around power sources. At the end of the day, it's around cheap power and cooling. As you start looking at the dynamics of what's happening to our energy grid, it's no longer being quite as centralized as it was. And, it starts to beg the question "does it make sense to think about smaller units that are more distributed? Does it make sense to start really thinking about Edge compute capacity?" The option to deploy something really close to your customers if you need low latency and attainment scenarios. Or, the option to push a lot of capacity into your distribution center, if you're running high, heavy IoT workloads, where you just don't want to put all that data on the network. And so I think that, again, certainly, I think that people underestimate the power of the Amazon, Microsoft and Google. People that are still building data centers today, don't realize quite how remarkable the vendors at that scale are, in terms of their ability to build and run these things. But I do think that there are some interesting options, in terms of regional locality, data sovereignty, Edge latency, that legitimize, other types of deployment. >> Yeah, and you talked about IoT, Edge computing absolutely is something that comes up a lot there. At AWS Re:Invent last year, Amazon put their serverless solution using Greengrass, out at the Edge because there's tons of centers that I might not have the networking, or I can't have the latency I need to do the compute there. How does things like serverless at the Edge, and IoT play into the discussion of Kubernetes? >> I think it plays really well, insofar as, Kubernetes, it's not intrinsically magic. What it has done is created a relatively simple, and turns out, pretty reusable abstraction that lets you run a broad array of workloads. I wouldn't say it's exactly cracked the serverless paradigm in terms of event-driven, low cost of activation computing, but that's something that can certainly be built on top of it. The thing that it does do, is it provides you the ability to manage an application as if it were software as a service, in a location that is remote from you, by providing you a very principled, automated framework for operations. >> Alright, Craig, last thing I want you to do is give us an update on Heptio. How many people do you have? How are you engaging with customers? What's the business model look like for that? What can you share? >> So, we're currently 13 people. We've been in business for four months, and we've been able to hire some really amazing folks, out of the distributed systems communities. We are at a point where we're starting to provide our first supported configurations of Kubernetes. We don't position ourselves as a distribution provider, we rather like to think of ourselves as an organization that's invested in helping users get the most of the Upstream community. Right now, our focus is on training, support, and services, and over time, if we do that really well, we do aspire to provide a more robust set of product capabilities that help organizations succeed. For now, the thing that we focus most relentlessly on is helping customers manage down the cost of supporting a cluster. How do we create a better way for folks to understand what a configuration should look like? When are they likely to encounter issues? And if they do encounter those issues, helping them resolve them in the lowest friction and least painful way possible. >> Alright, and any relationships with the public cloud guys? Or what do you work with when you talk about OpenStack, Amazon, Google, Microsoft, what's the relationship and how do those work? >> So we announced the first joint quick start for Kubernetes with the Amazon folks last Tuesday. And that's been going pretty well. We're getting a lot of positive feedback around that. And we're now starting to think more broadly in terms of providing supported configurations on premises and then on Microsoft. So Amazon, for us, was the obvious starting point. It felt like an under-supported community from a Kubernetes perspective, insofar as, Microsoft had our friend Brenda Burns, who helped us build communities in the first place. And he's been doing some great work to bring Kubernetes to the Azure container service. What we really wanted to do was to make sure that Kubernetes runs well on Amazon, and that it is naturally integrated into the Amazon operating model, so cloud formation templates, and we have a really principled way to manage, maintain, upgrade and support those clusters. >> Alright, Craig Mcluckie, co-creator of Kubernetes, and CEO of Heptio. Really appreciate you coming here to our Palo Alto studio, helping us as we get towards the end of two days of live coverage of Google Cloud Next 2017. You're watching theCUBE. (upbeat music)