(bright upbeat music) >> Hey everyone, welcome to theCUBE's AWS startup showcase. This is season two of the startup showcase, episode one. I'm your host, Lisa Martin. Pleased to be welcoming back one of our alumni, Alexis Richardson, the founder >> Hey. >> and CEO of Weaveworks. Alexis, welcome back to the program. >> Thank you so much, Lisa, I'm really happy to be here. Good to see you again. >> Likewise. So it's been a while since we've had Weaveworks on the program. Give the audience an overview of Weaveworks. You were founded in 2014, pioneering getopts, automating Kubernetes across all industries, but help us understand, unpack that a bit. >> Well, so my previous role was at Pivotal, where I was head of application platform and I was responsible for Spring and Vfabric, and some pieces of Cloud Foundry. And you may remember back in those days, everybody wanted to build like a Heroku, but for the enterprise. And so they were asking, how can we build more cloud services? And my team was involved in building out cloud services, but we were running into trouble with the technology that we had. And then when containers appeared, we thought this is the technology for us to roll out cloud services. So with some of my team, we decided to start a new company, Weaveworks, really intending to focus on developers. Because these new containers were pretty cool, but they were really complex operational centric tools, and enterprise developers need simplicity. That's what we'd learned from things like Spring. They want simplicity, productivity, velocity, all of that stuff, they don't want operational complexity. So Weaveworks' mission is to make applications easy for developers with containers. >> Talk to me about how you've accomplished that over the last seven years, and some of the things that you're doing to facilitate a DevOps practice within organizations across any industry? >> Yeah, well, our story is pretty interesting because of course in 2014, all of this was incredibly new. You couldn't even take two containers and put them together into a single application. So forget about enterprise. What we did was we built a network, which gave the company its name, Weave. But then we spent several years building out more and more pieces of the stack. We decided that we should go to market commercially because we're an open source company with a commercial SaaS. And we thought we would be like new Relic, that there'll be lots of customers in the cloud. And, therefore, they would need monitoring and management. And Weave started writing a SaaS based on Kubernetes, which was what we chose as our platform, back in the day, very, very, very early. We were one of the very first companies to start running Kubernetes in production other than Google. And so what we learned was customers didn't want to have management and monitoring for applications in the cloud, based on Kubernetes. Because they were all still struggling to get Docker working, to get basic Kubernetes clusters set up. And they kept saying to us "this is great, we love your tool, but we really need simpler things right now." So what we had done was we'd learned how to operate Kubernetes. And we discovered that we were doing it in this specific way, a way that meant that we could be reliable, we could set things up remotely, we could move things between zones. And so we called this approach getopts. So we've named the practice of getopts, which is really DevOps for Kubernetes. We decided that it was exciting after we had an outage and made a very quick recovery. Told people about it and they said, "well, we can't even Kubernetes started, let alone recover it from a crash." So we started evangelizing getopts and saying to people that we knew how to set up and run Kubernetes as operators for developers of apps, based on this experience. And people said, "well, why don't you help us do that?" So we pivoted the company away from a SaaS business, doing management, and straight back into enterprise software, providing a solution for people to run Kubernetes stacks, deploy applications, detect drifts, and operate them at scale. And we've never looked back. And since then we've built, very successfully, a big business out of telco customers, banks, car companies, really global two thousands. Starting from that open source base, continuing to respect that, but always keeping in mind helping developers build applications at scale. >> So in terms of that pivot that you've made, it sounds like you made that in conjunction with developers across industries to really understand what the right direction is here. What's the approach, what's their appetite? Talk to me about a customer example or two that really you think articulate the value and the right decision that that pivot was and how you're helping customers to really further their DevOps practice. >> Well, one of our first customers was actually Fidelity in this new world. Fidelity has a very advanced technology organization, a very forward thinking CTO, who I seem to recall is, or CEO, who I think is female. Really is into technology as a source of, you know, velocity and business strength. And we were brought to Fidelity by our partner, Amazon. And they said, "look, Fidelity have been using your open source tools, they want to run on Kubernetes, the early EKS service on AWS, but they need help, because what they want is a shared application platform that people can use across Fidelity to deploy and manage apps." So the idea Fidelity had was they're going to split their IT into a platform team, that was going to provide this platform, and a bunch of app teams that were going to write business apps like risk management, other financial processing. Paths, basically. And we came in to help Fidelity. And what we did was help Fidelity rollout, using getopts, a Amazon wide application platform. We also helped them to build, this was very early days for us post pivot, we really helped them to build an add on layer. So you could take any Kubernetes cluster and add other components to it, and then you'd have your platform right there. And the whole stack would be managed by getopts, which nobody had done before. Nobody who'd come up with a way of managing the whole stack, so you could start and stop stacks wherever you wanted, at will, correctly. I mean, if you talk to people about what's hard in IT, they'll tell you shutting down Kubernetes is hard, 'cause I know I'm never going to know how to start it again. So being able to start and stop things, move them around is really crucial. What Fidelity also wanted, which made I think the whole thing even more exciting, was to duplicate this environment on Azure and actually also on-premise later on. So where Fidelity are today is the whole Fidelity platform runs on Microsoft and on Amazon and on-premise, using three different implementations of Kubernetes. But using this platform technology and getopts that we helped Fidelity rollout. And if you want to know a bit about the story, type FIDEKS, F I D E K S into Google and you'll find a video of me three or four years ago on stage at Cube Con talking with a Fidelity chief architect about this story. It's pretty exciting and these are early days for these new Kubernetes platforms. >> Early days, but so transformative. And I can't imagine the events of the last few years without having this capability and this technology to facilitate such pivots and transformation where we would all be. I want to kind of dig into some use cases, 'cause one of the things that you just mentioned with the Fidelity example got me thinking use case of hybrid, multi-cloud, but also continuous app development. Talk to me about some of the key use cases that you work with customers on. >> Well you just named two. So hybrid and multi-cloud is absolutely critical, and also sovereign, which is when you're actually offline and you only update your cloud periodically. That's one of the major use cases for us. And what customers want there is they want consistency. They want a single operating model, across all of these different locations, so that all of their teams can get trained on one set of technologies and then move from place to place. They're not looking for magic, where apps move with the sun or any of that stuff. They just want to know they can base everything on a single, homogeneous skillset and have scale across their teams. Maybe tens of thousands of developers, all who know how to do the same thing. That's a really important use case. You also mentioned continuous delivery. That's probably the second really critical use case for us. People say, "I've got Kubernetes set up now, and I have Jenkins." At JP Morgan once told me they had 40,000 Jenkins servers, or something like that, you know, Jenkins at scale. And they're like, "okay, how do I push changes from Jenkins into the cloud?" So getopts provides a bridge between the world of CI and the runtime of Kubernetes. So one group of our customers is help me to put that middle piece of CD that gets you CI, CD, to Kubernetes, that's a classic. And then what they're looking for is an increase in velocity. And what we typically see is people go from deploying once every six months to deploying once a week, to deploying once a day, to deploying several times a day. And then they split things up into teams and suddenly, wow, that vision of microservices has come and everybody's excited 'cause IT velocity has gone up by two X. Another really >> So, >> Sorry, carry on. >> Go ahead, I was just going to say in terms of IT velocity it sounds like that's a major business outcome that you're enabling for, whether it's teleco, financial services, or whatnot. That velocity is, as you just described, is rapidly accelerating. >> Yeah, if you go to our website, you'll find a bunch of these use cases. And one that I really like is NatWest mettle, which is another financial example. They're not all financial by the way. But there's some metrics in there. We're getting people up to two X productivity, which at scale is huge, really makes a difference. Also, meantime to recovery. If you know the metric space, you'll know these are all DORA metrics. And DORA, which was acquired by Google a couple of years ago, is a really fantastic analyst in the space that came up with a bunch of ways of thinking about how to measure your performance as a business and IT organization. Recovery time and things like this that you really need to focus on if you're in this world. >> Well, from an IT velocity perspective, if I translate that to business outcomes, especially given the dynamics in the market over the last two years, this is transformative and probably helped a lot of organizations to pivot multiple times during the last couple of years. To get to that survival mode and into that thriving mode, enabling organizations to meet customer demand that was changing faster, et cetera. That's a really big imperative that this technology can deliver to the business. >> Yeah, I mean, that's been huge for us. So when the pandemic first began, obviously, we had some road bumps and there were some challenges, but what we found out very quickly was that people were moving into digital much faster. And we've been mostly enabling them, not just in finance, as I said, but also, car companies, utilities, et cetera. The other one, of course, is modern operations. So, everyone's excited about the potential for automation. If I have thousands and thousands of developers and thousands of applications, do I need thousands of operations staff? And the answer is, with Kubernetes in this new era, you can reduce your operational loads. So that actually very few people are needed to keep systems up, to do basic monitoring, to do redeployments and so on, which are all boring infrastructure tasks that no developer wants to do. If we can automate all of that, we can modernize the whole IT space. And that's what I think the promise of Kubernetes that we're also seeing as well. So applications speed first and then operational competence second. >> So you guys had a launch, here we are in early calendar year 2022, you guys had a launch just about six or eight weeks ago in November of 2021, where you were launching announcing the GA of Weave getopts enterprise, which is a licensed product building on the free open source Weave getopts core. Talk to me about that and what the significance of that is. >> Well, this is an enterprise solution that helps customers build these critical use cases, like shared service platform or secure DevOps or multi-cloud, using getopts, which gives them higher security, lower costs of management, and better operations, and higher velocity. And all of it is taking all the best practices that we've learned starting from those days of running our own Kubernetes stack and then through those early customers like Fidelity into the modern era where we have an at-scale platform for these people. And the crucial properties are it provides you with a platform, it provides you with trusted delivery, and it provides you with what we call release orchestration, which is when you deploy things at scale into production, using tools like canaries and other modern practices. So, all of it is enabling what we call the cloud native enterprise, application delivery, modern operations. >> So what's the upgrade path for customers that are using the free open-source tier to the enterprise package, what does that look like? >> The good news is it's an add on. So, I have been in the industry a while and I strongly believe it's really important that if you have an open source product, you shouldn't ask people to delete it or uninstall it to install your enterprise product, unless you really, really, really have to. And I'm not trying to be picky here. Maybe there are cases where it's important, but actually in our case, it's very simple. If you're already using one of our upstream tools, like Flux, for example, then going from Flux to Weave getopts enterprise is an add-on installation. So you don't have to change or take out what you're doing. You might be using Flux without knowing it. You may not be aware of this, but it's also insight as your AKS and ARC, it's inside the Amazon EKS anywhere bundle. It's available on Alibaba, VMware have used it in cartographer and Tanzu application platform. And even Red Hat use it too in some cases. So you may be using it already, from one of the big vendors who are partners of ours, as a precursor to buying Weave getopts enterprise. So, you know, don't be scared. Get in touch is what I would say to people. >> Get in touch. And of course, folks can go to weave.works to learn more about that. And, also we want to watch the Weave.works space, 'cause you have some news coming out relatively soon that sounds pretty exciting, Alexis. >> Well, I mentioned trusted delivery. And I think one of the things with that is no CIO wants to go faster, unless they also have the safety wheels on, let's face it. And the big question we get asked is "I love this getopts stuff, but how can I bring my team with me? How can I introduce change?" I have all of these approvals mechanisms in place, can I move into the world of getopts? And the answer is yes, yes you can because we now support policy engines as baked into our enterprise product. Now, if you don't know what policy is, it's really a way of applying rules to what you're seeing in IT. And you can detect whether something passes or fails conditions, which means that we can detect if something bad is about to happen in a deployment and stop it from happening, this is really critical. It also goes hand in hand with things like supply chain and security, which I'm sure we read about in the news far too much. >> Yeah, pretty much daily supply chain and security >> Pretty much daily. >> is one of those things that we're all in every generation concerned about. Well, Alexis, it's been a pleasure having you back on the program, talking to us about what's new at Weaveworks, the direction that you're going, how you're helping organizations across industries really advance their DevOps practice. And we will check weave.works in the next couple of weeks for more on that news that you started to break a little bit with us today. We appreciate your time, Alexis. >> Thank you very much, indeed, take care. >> Likewise. For Alexis Richardson, I'm Lisa Martin. Keep it right here on theCUBE, your leader in hybrid tech event coverage. (bright music) (music fades)

>> Announcer: Live, from Copenhagen, Denmark. It's theCUBE! Covering KubeCon and CloudNativeCon Europe 2018. Brought to you by the Cloud Native Computing Foundation, and its Ecosystem partners. >> Hi everyone, welcome back, this is theCUBE's exclusive coverage of the Linux Foundation's Cloud Native Compute Foundation KubeCon 2018 in Europe. I'm John Furrier, host of theCUBE and we're here with two Google folks. JD Velazquez who's the Product Manager for Stackdriver, got some news on that we're going to cover, and David Aronchick, who's the co-founder of Kubeflow, also with Google, news here on that. Guys, welcome to theCUBE, thanks for coming on. >> Thank you John. >> Thank you very much. >> So we're going to have Google Next coming out, theCUBE will be there this summer, looking forward to digging in to all the enterprise traction you guys have, and we had some good briefings at Google. Ton of movement on the Cloud for Google, so congratulations. >> JD: Thank you. >> Open source is not new to Google. This is a big show for you guys. What's the focus, you've got some news on Stackdriver, and Kubeflow. Kubeflow, not Cube flow, that's our flow. (laughing) David, share some of the news and then we'll get into Stackdriver. >> Absolutely, so Kubeflow is a brand new project. We launched it in December, and it is basically how to make machine learning stacks easy to use and deploy and maintain on Kubernetes. So we're not launching anything new. We support TensorFlow and PyTorch, Caffe, all the tools that you're familiar with today. But we use all the native APIs and constructs that Kubernetes rides to make it very easy and to let data scientists and researchers focus on what they do great, and let the I.T. Ops people deploy and manage these stacks. >> So simplifying the interactions and cross-functionality of the apps. Using Kubernetes. >> Exactly, when you go and talk to any researcher out there or data scientist, what you'll find is that while the model, TensorFlow, or Pytorch or whatever, that gets a little bit of the attention. 95% of the time is spent in all the other elements of the pipeline. Transforming your data, ingesting it, experimenting, visualizing. And then rolling it out toward production. What we want to do with Kubeflow is give everyone a standard way to interact with those, to interact with all those components. And give them a great workflow for doing so. >> That's great, and the Stackdriver news, what's the news we got going on? >> We're excited, we just announced the beta release of Stackdriver Kubernetes monitoring, which provides very rich and comprehensive observability for Kubernetes. So this is essentially simplifying operations for developers and operators. It's a very cool solution, it integrates many signals across the Kubernetes environment, including metrics, logs, events, as well as metadata. So what it allows is for you to really inspect your Kubernetes environment, regardless of the role, and regardless of where your deployment is running it. >> David is bringing up just the use cases. I just, my mind is exploding, 'cause you think about what Tensorflow is to a developer, and all the goodness that's going on with the app layer. The monitoring and the instrumentation is a critical piece, because Kubernetes is going to bring the people what is thousands and thousands of new services. So, how do you instrument that? I mean, you got to know, I want to provision this service dynamically, that didn't exist. How do you measure that, I mean this is, is this the challenge you guys are trying to figure out here? >> Yeah, for sure John. The great thing here is that we, and at Google primarily, many of our ancillary practices go beyond monitoring. It really is about observability, which I would describe more as a property of a system. How do you, are able to collect all these many signals to help you diagnose the production failure, and to get information about usage and so forth. So we do all of that for you in your Kubernetes environment, right. We take that toil away from the developer or the operator. Now, a cool thing is that you can also instrument your application in open source. You can use Prometheus, and we have an integration for that, so anything you've done in a Prometheus instrumentation, now you can bring into the cloud as needed. >> Tell about this notion, everyone gets that, oh my God, Google's huge. You guys are very open, you're integrating well. Talk about the guiding principles you guys have when you think about Prometheus as an example. Integrating in with these other projects. How are you guys treating these other projects? What's the standard practice? API Base? Is there integration plans? How do you guys address that question? >> Yeah, at a high level I would say, at Google, we really believe in contributing and helping grow open communities. I think that the best way to maintain a community open and portable is to help it grow. And Prometheus particularly, and Kubernetes of course, is a very vibrant community in that sense. So we are, from the start, designing our systems to be able to have integration, via APIs and so on, but also contributing directly to the projects. >> And I think that one thing that's just leveraging off that exact point, y'know, we realize what the world looks like. There's literally zero customers out there, like, "Well, I want be all in on one cloud. "Y'know, that 25 million dollar data center "I spent last year building. "Yeah, I'll toss that out so that I can get, "y'know, some special thing." The reality is, people are multi-cloud. And the only way to solve any problem is with these very open standards that work wherever people are. And that's very much core to our philosophy. >> Well, I mean, I've been critical of multi-cloud, by the definition. Statistically, if I'm on Azure, with 365, that's Azure. If I'm running something on Amazon, those are two clouds, they're not multi-cloud, by my definition. Which brings up where this is going, which is latency and portability, which you guys are really behind. How are you guys looking at that, because you mentioned observation. Let's talk about the observation space of clouds. How are you guys looking at, 'cause that's what people are talking about. When are we going to get to the future state, which is, I need to have workload portability, in real time, if I want to move something from Azure to AWS or Google Cloud, that would be cool. Can't do that today. >> That is actually the core of what we did around Kubeflow. What we are able to do is describe in code all the layers of your pipeline, all the steps of your pipeline. That works based on any conformant Kubernetes cluster. So, you have a Kubernetes conformant cluster on Azure, or on AWS, or on Google Cloud, or on your laptop, or in your private data center, that's great. And to be clear, I totally agree. I don't think that having single workloads spread across cloud, that's not just unrealistic, because of all the things you identified. Latency, variability, unknown failures, y'know. Cap theorem is a thing because, y'know, it's well-known. But what people want to do is, they want to take advantage of different clouds for the efforts that they provide. Maybe my data is here, maybe I have a legal reason, maybe this particular cloud has a unique chip, or unique service-- >> Use cases can drive it. >> Exactly, and then I can take my workload, which has been described in code and deploy it to that place where it makes sense. Keeping it within a single cloud, but as an organization I'll use multiple clouds together. >> Yeah, I agree, and the data's key, because if you can have data moving between clouds, I think that's something I would like to see, because that's going to be, because the metadata you mentioned is a real critical piece of all these apps. Whether it's instrumentation logging, and/or, y'know, provisioning new services. >> Yeah, and as soon as you have, as David is mentioning, if you have deployments on, y'know, with public or private clouds, then the difficult part is that of severability, that we were talking before. Because now you're trying to stitch together data, and tools to help you get that diagnosed, or get signals when you need them. This is what we're doing with Stackdriver Kubernetes monitoring, precisely. >> Y'know, we're early days in the cloud. It stills feels like we're 10 years in, but, y'know, a lot of people are now coming to realize cloud native, so. Y'know, I'm not a big fan of the whole, y'know, Amazon, although they do say Amazon's winning, they are doing quite well with the cloud, 'cause they're a cloud. It's early days, and you guys are doing some really specific good things with the cloud, but you don't have the breadth of services, say, Amazon has. And you guys are above board about that. You're like, "Hey, we're not trying to meet them "speed for speed on services." But you do certain things really, really well. You mentioned SRE. Site Reliability Engineers. This is a scale best practice that you guys have bringing to the table. But yet the customers are learning about Kubernetes. Some people who have never heard of it before say, "Hey, what's this Kubernetes thing?" >> Right. >> What is your perspectives on the relevance of Kubernetes at this point in history? Because it really feels like a critical mass, de facto, standard movement where everyone's getting behind Kubernetes, for all the right reasons. It feels a lot like interoperability is here. Thoughts on Kubernetes' relevance. >> Well I think that Alexis Richardson summed it up great today, the chairperson of the technical oversight committee. The reality is that what we're looking for, what operators and software engineers have been looking for forever, is clean lines between the various concerns. So as you think about the underlying infrastructure, and then you think about the applications that run on top of that, potentially services that run on top of that, then you think about applications, then you think about how that shows up to end users. Before, if you're old like me, you remember that you buy a $50,000 machine and stick it in the corner, and you'd stack everything on there, right? That never works, right? The power supply goes out, the memory goes out, this particular database goes out. Failure will happen. The only way to actually build a system that is reliable, that can meet your business needs, is by adopting something more cloud native, where if any particular component fails, your system can recover. If you have business requirements that change, you can move very quickly and adapt. Kubernetes provides a rich, portable, common set of APIs, that do work everywhere. And as a result, you're starting to see a lot of adoption, because it gives people that opportunity. But I think, y'know and let me hand off to JD here, y'know, the next layer up is about observability. Because without observing what's going on in each of those stacks, you're not going to have any kind of-- >> Well, programmability comes behind it, to your point. Talk about that, that's a huge point. >> Yeah, and just to build on what David is saying, one thing that is unique about Google is that we've been doing for more than a decade now, we've been very good at being able to provide innovative services without compromising reliability. Right, and so what we're doing is in that commitment, and you see that with Kubernetes and Istio, we're externalizing many of our, y'know, opinionated infrastructure, and platforms in that sense, but it's not just the platforms. You need those methodologies and best practices. And now the toolset. So that's what we're doing now, precisely. >> And you guys have made great strides, just to kind of point out to the folks watching, in the enterprise, I know you've got a lot more work to do but you're pedaling as fast as you can. I want to ask you specifically around this, because again, we're still early days with the cloud, if you think about it, there are now table stakes that are on the table that you got to get done. Check boxes if you will. Certainly on the government side there's like, compliance issues, and you guys are now checking those boxes. What is the key thing, 'cause you guys are operating at a scale that enterprises can't even fathom. I mean, millions of services, on and on up a huge scale. That's going to be helpful for them down the road, no doubt about it. But today, what is the Google table stakes that are done, and what are enterprises need to have for table stakes to do cloud native right, from your perspective? >> Well, I think more than anything, y'know, I agree with you. The reality is all the hyperscale cloud providers have the same table stakes, all the check boxes are checked, we're ready to go. I think what will really differentiate and move the ball forward for so many people is this adoption of cloud native. And really, how cloud native is your cloud, right? How much do you need to spin up an entire SRE team like Netflix in order to operate in the Netflix model of, y'know, complete automation and building your own services and things like that. Does your cloud help you get cloud native? And I think that's where we really want to lean in. It's not about IAS anymore, it's about does your cloud support the reliability, support the distribution, all the various services, in order to help you move even faster and achieve higher velocity. >> And standing up that is critical, because now these applications are the business model of companies, when you talk about digital. So I tweeted, I want to get your reaction to this, yesterday I got a quote I overheard from a person here in the hallways. "I need to get away from VPNs and firewalls. "I need user application layer security "with unphishable access, otherwise I'm never safe." Again this talks about the perimeterless cloud, spearphishing is really hot right now, people are getting killed with security concerns. So, I'm going to stop if I'm enterprise, I'm going to say, "Hold on, I'm not going," Y'know, I'm going to proceed with caution. What are you guys doing to take away the fear, and also the reality that as you provision all these, stand up all this infrastructure, services for customers, what are you guys doing to prevent phishing attacks from happening, security concerns, what's the Google story? >> So I think that more than anything, what we're trying to do is exactly what JD just said, which is externalize all the practices that we have. So, for example, at Google we have all sorts of internal tools that we've used, and internal practices. For example, we just published a whitepaper about our security practices where you need to have two vulnerabilities in order to break out of any system. We have all that written up there. We just published a whitepaper about encryption and how to do encryption by default, encryption between machines and so on. But I think what we're really doing is, we're helping people to operate like Google without having to spin up an entire SRE team as big as Google's to do it. An example is, we just released something internally, we have something called BeyondCorp. It's a non-firewall, non-VPN based way for you to authenticate against any Google system, using two-factor authentication, for our internal employees. Externally, we just released it, it's called, Internet, excuse me, IdentityAware proxy. You can use with literally any service that you have. You can provision a domain name, you can integrate with OAuth, you can, including Google OAuth or your own private OAuth. All those various things. That's simply a service that we offer, and so, really, y'know, I think-- >> And there's also multi, more than two-factor coming down the road, right? >> Exactly, actually IdentityAware proxy already supports two-factor. But I will say, one of the things that I always tell people, is a lot of enterprises say exactly what you said. "Jeez, this new world looks very scary to me. "I'm going to slow down." The problem is they're mistaken, under the mistaken impression that they're secure today. More than likely, they're not. They already have firewall, they already have VPN, and it's not great. In many ways, the enterprises that are going to win are the ones that lean in and move faster to the new world. >> Well, they have to, otherwise they're going to die, with IOT and all these benefits, they're exposed even as they are, just operationally. >> Yep. >> Just to support it. Okay, I want to get your thoughts, guys, on Google's role here at the Linux Foundation's CNCF KubeCon event. You guys do a lot of work in open source. You've got a lot of great fan base. I'm a fan of what you guys do, love the tech Google brings to the table. How do people get involved, what are you guys connecting with here, what's going on at the show, and how does someone get on board with the Google train? Certainly TensorFlow has been, it's like, great open source goodness, developers are loving it, what's going on? >> Well we have over almost 200 people from Google here at the show, helping and connecting with people, we have a Google booth which I invite people to stop by and tell about the different project we have. >> Yeah, and exactly like you said, we have an entire repo on Github. Anyone can jump in, all our things are open source and available for everyone to use no matter where they are. Obviously I've been on Kubernetes for a while. The Kubernetes project is on fire, Tensorflow is on fire, KubeFlow that we mentioned earlier is completely open source, we're integrating with Prometheus, which is a CNCF project. We are huge fans of these open source foundations and we think that's the direction that most software projects are going to go. >> Well congratulations, I know you guys invested a lot. I just want to highlight that. Again, to show my age, y'know these younger generation have no idea how hard open source was in the early days. I call it open bar and open source, you guys are bringing so much, y'know, everyone's drunk on all this goodness. Y'know, just these libraries you guys bringing to the table. >> David: Right. >> I mean Tensorflow is just the classic poster-child example. I mean, you're bringing a lot of stuff to the table. I mean, you invented Kubernetes. So much good stuff coming in. >> Yeah, I couldn't agree more. I hesitate to say we invented it. It really was a community effort, but yeah, absolutely-- >> But you opened it up, and you did it right, and did a good job. Congratulations. Thanks for coming on theCUBE, I'm going to see you at Google Next. theCUBE will be broadcasting live at Google Next in July. Of course we'll do a big drill-down on Google Cloud platform at that show. It's theCUBE here at KubeCon 2018 in Copenhagen, Denmark. More live coverage after this short break, stay with us. (upbeat music)