(upbeat music) >> Hello, everyone, from Palo Alto, Lisa Martin here. This is The Cube's coverage of CloudNativeSecurityCon, the inaugural event. I'm here with John Furrier in studio. In Boston, Dave Vellante joins us, and our guest, Liz Rice, one of our alumni, is joining us from Seattle. Great to have everyone here. Liz is the Chief Open Source officer at Isovalent. She's also the Emeritus Chair Technical Oversight Committee at CNCF, and a co-chair of this new event. Everyone, welcome Liz. Great to have you back on theCUBE. Thanks so much for joining us today. >> Thanks so much for having me, pleasure. >> So CloudNativeSecurityCon. This is the inaugural event, Liz, this used to be part of KubeCon, it's now its own event in its first year. Talk to us about the importance of having it as its own event from a security perspective, what's going on? Give us your opinions there. >> Yeah, I think security was becoming so- at such an important part of the conversation at KubeCon, CloudNativeCon, and the TAG security, who were organizing the co-located Cloud Native Security Day which then turned into a two day event. They were doing this amazing job, and there was so much content and so much activity and so much interest that it made sense to say "Actually this could stand alone as a dedicated event and really dedicate, you know, all the time and resources of running a full conference, just thinking about cloud native security." And I think that's proven to be true. There's plenty of really interesting talks that we're going to see. Things like a capture the flag. There's all sorts of really good things going on this week. >> Liz, great to see you, and Dave, great to see you in Boston Lisa, great intro. Liz, you've been a CUBE alumni. You've been a great contributor to our program, and being part of our team, kind of extracting that signal from the CNCF cloud native world KubeCon. This event really kind of to me is a watershed moment, because it highlights not only security as a standalone discussion event, but it's also synergistic with KubeCon. And, as co-chair, take us through the thought process on the sessions, the experts, it's got a practitioner vibe there. So we heard from Priyanka early on, bottoms up, developer first. You know KubeCon's shift left was big momentum. This seems to be a breakout of very focused security. Can you share the rationale and the thoughts behind how this is emerging, and how you see this developing? I know it's kind of a small event, kind of testing the waters it seems, but this is really a directional shift. Can you share your thoughts? >> Yeah I'm just, there's just so many different angles that you can consider security. You know, we are seeing a lot of conversations about supply chain security, but there's also runtime security. I'm really excited about eBPF tooling. There's also this opportunity to talk about how do we educate people about security, and how do security practitioners get involved in cloud native, and how do cloud native folks learn about the security concepts that they need to keep their deployments secure. So there's lots of different groups of people who I think maybe at a KubeCon, KubeCon is so wide, it's such a diverse range of topics. If you really just want to focus in, drill down on what do I need to do to run Kubernetes and cloud native applications securely, let's have a really focused event, and just drill down into all the different aspects of that. And I think that's great. It brings the right people together, the practitioners, the experts, the vendors to, you know, everyone can be here, and we can find each other at a smaller event. We are not spread out amongst the thousands of people that would attend a KubeCon. >> It's interesting, Dave, you know, when we were talking, you know, we're going to bring you in real quick, because AWS, which I think is the bellweather for, you know, cloud computing, has now two main shows, AWS re:Invent and re:Inforce. Security, again, broken out there. you see the classic security events, RSA, Black Hat, you know, those are the, kind of, the industry kind of mainstream security, very wide. But you're starting to see the cloud native developer first with both security and cloud native, kind of, really growing so fast. This is a major trend for a lot of the ecosystem >> You know, and you hear, when you mention those other conferences, John you hear a lot about, you know, shift left. There's a little bit of lip service there, and you, we heard today way more than lip service. I mean deep practitioner level conversations, and of course the runtime as well. Liz, you spent a lot of time obviously in your keynote on eBPF, and I wonder if you could share with the audience, you know, why you're so excited about that. What makes it a more effective tool compared to other traditional methods? I mean, it sounds like it simplifies things. You talked about instrumenting nodes versus workloads. Can you explain that a little bit more detail? >> Yeah, so with eBPF programs, we can load programs dynamically into the kernel, and we can attach them to all kinds of different events that could be happening anywhere on that virtual machine. And if you have the right knowledge about where to hook into, you can observe network events, you can observe file access events, you can observe pretty much anything that's interesting from a security perspective. And because eBPF programs are living in the kernel, there's only one kernel shared amongst all of the applications that are running on that particular machine. So you don't- you no longer have to instrument each individual application, or each individual pod. There's no more need to inject sidecars. We can apply eBPF based tooling on a per node basis, which just makes things operationally more straightforward, but it's also extremely performant. We can hook these programs into events that typically very lightweight, small programs, kind of, emitting an event, making a decision about whether to drop a packet, making a decision about whether to allow file access, things of that nature. There's super fast, there's no need to transition between kernel space and user space, which is usually quite a costly operation from performance perspective. So eBPF makes it really, you know, it's taking the security tooling, and other forms of tooling, networking and observability. We can take these tools into the kernel, and it's really efficient there. >> So Liz- >> So, if I may, one, just one quick follow up. You gave kind of a space age example (laughs) in your keynote. When, do you think a year from now we'll be able to see, sort of, real world examples in in action? How far away are we? >> Well, some of that is already pretty widely deployed. I mean, in my keynote I was talking about Cilium. Cilium is adopted by hundreds of really big scale deployments. You know, the users file is full of household names who've been using cilium. And as part of that they will be using network policies. And I showed some visualizations this morning of network policy, but again, network policy has been around, pretty much since the early days of Kubernetes. It can be quite fiddly to get it right, but there are plenty of people who are using it at scale today. And then we were also looking at some runtime security detections, seeing things like, in my example, exfiltrating the plans to the Death Star, you know, looking for suspicious executables. And again, that's a little bit, it's a bit newer, but we do have people running that in production today, proving that it really does work, and that eBPF is a scalable technology. It's, I've been fascinated by eBPF for years, and it's really amazing to see it being used in the real world now. >> So Liz, you're a maintainer on the Cilium project. Talk about the use of eBPF in the Cilium project. How is it contributing to cloud native security, and really helping to change the dials on that from an efficiency, from a performance perspective, as well as a, what's in it for me as a business perspective? >> So Cilium is probably best known as a networking plugin for Kubernetes. It, when you are running Kubernetes, you have to make a decision about some networking plugin that you're going to use. And Cilium is, it's an incubating project in the CNCF. It's the most mature of the different CNIs that's in the CNCF at the moment. As I say, very widely deployed. And right from day one, it was based on eBPF. And in fact some of the people who contribute to the eBPF platform within the kernel, are also working on the Cilium project. They've been kind of developed hand in hand for the last six, seven years. So really being able to bring some of that networking capability, it required changes in the kernel that have been put in place several years ago, so that now we can build these amazing tools for Kubernetes operators. So we are using eBPF to make the networking stack for Kubernetes and cloud native really efficient. We can bypass some of the parts of the network stack that aren't necessarily required in a cloud native deployment. We can use it to make these incredibly fast decisions about network policy. And we also have a sub-project called Tetragon, which is a newer part of the Cilium family which uses eBPF to observe these runtime events. The things like people opening a file, or changing the permissions on a file, or making a socket connection. All of these things that as a security engineer you are interested in. Who is running executables who is making network connections, who's accessing files, all of these operations are things that we can observe with Cilium Tetragon. >> I mean it's exciting. We've chatted in the past about that eBPF extended Berkeley Packet Filter, which is about the Linux kernel. And I bring that up Liz, because I think this is the trend I'm trying to understand with this event. It's, I hear bottoms up developer, developer first. It feels like it's an under the hood, infrastructure, security geek fest for practitioners, because Brian, in his keynote, mentioned BIND in reference the late Dan Kaminsky, who was, obviously found that error in BIND at the, in DNS. He mentioned DNS. There's a lot of things that's evolving at the silicone, kernel, kind of root levels of our infrastructure. This seems to be a major shift in focus and rightfully so. Is that something that you guys talk about, or is that coincidence, or am I just overthinking this point in terms of how nerdy it's getting in terms of the importance of, you know, getting down to the low level aspects of protecting everything. And as we heard also the quote was no software secure. (Liz chuckles) So that's up and down the stack of the, kind of the old model. What's your thoughts and reaction to that? >> Yeah, I mean I think a lot of folks who get into security really are interested in these kind of details. You know, you see write-ups of exploits and they, you know, they're quite often really involved, and really require understanding these very deep detailed technical levels. So a lot of us can really geek out about the details of that. The flip side of that is that as an application developer, you know, as- if you are working for a bank, working for a media company, you're writing applications, you shouldn't have to be worried about what's happening at the kernel level. This might be kind of geeky interesting stuff, but really, operationally, it should be taken care of for you. You've got your work cut out building business value in applications. So I think there's this interesting, kind of dual track going on almost, if you like, of the people who really want to get involved in those nitty gritty details, and understand how the underlying, you know, kernel level exploits maybe working. But then how do we make that really easy for people who are running clusters to, I mean like you said, nothing is ever secure, but trying to make things as secure as they can be easily, and make things visual, make things accessible, make things, make it easy to check whether or not you are compliant with whatever regulations you need to be compliant with. That kind of focus on making things usable for the platform team, for the application developers who deliver apps on the platform, that's the important (indistinct)- >> I noticed that the word expert was mentioned, I mentioned earlier with Priyanka. Was there a rationale on the 72 sessions, was there thinking around it or was it kind of like, these are urgent areas, they're obvious low hanging fruit. Was there, take us through the selection process of, or was it just, let's get 72 sessions going to get this (Liz laughs) thing moving? >> No, we did think quite carefully about how we wanted to, what the different focus areas we wanted to include. So we wanted to make sure that we were including things like governance and compliance, and that we talk about not just supply chain, which is clearly a very hot topic at the moment, but also to talk about, you know, threat detection, runtime security. And also really importantly, we wanted to have space to talk about education, to talk about how people can get involved. Because maybe when we talk about all these details, and we get really technical, maybe that's, you know, a bit scary for people who are new into the cloud native security space. We want to make sure that there are tracks and content that are accessible for newcomers to get involved. 'Cause, you know, given time they'll be just as excited about diving into those kind of kernel level details. But everybody needs a place to start, and we wanted to make sure there were conversations about how to get started in security, how to educate other members of your team in your organization about security. So hopefully there's something for everyone. >> That education piece- >> Liz, what's the- >> Oh sorry, Dave. >> What the buzz on on AI? We heard Dan talk about, you know, chatGPT, using it to automate spear phishing. There's always been this tension between security and speed to market, but CISOs are saying, "Hey we're going to a zero trust architecture and that's helping us move faster." Will, in your, is the talk on the floor, AI is going to slow us down a little bit until we figure it out? Or is it actually going to be used as an offensive defensive tool if I can use that angle? >> Yeah, I think all of the above. I actually had an interesting chat this morning. I was talking with Andy Martin from Control Plane, and we were talking about the risk of AI generated code that attempts to replicate what open source libraries already do. So rather than using an existing open source package, an organization might think, "Well, I'll just have my own version, and I'll have an AI write it for me." And I don't, you know, I'm not a lawyer so I dunno what the intellectual property implications of this will be, but imagine companies are just going, "Well you know, write me an SSL library." And that seems terrifying from a security perspective, 'cause there could be all sorts of very slightly different AI generated libraries that pick up the same vulnerabilities that exist in open source code. So, I think we're going to go through a pretty interesting period of vulnerabilities being found in AI generated code that look familiar, and we'll be thinking "Haven't we seen these vulnerabilities before? Yeah, we did, but they were previously in handcrafted code and now we'll see the same things being generated by AI." I mean, in the same way that if you look at an AI generated picture and it's got I don't know, extra fingers, or, you know, extra ears or something that, (Dave laughs) AI does make mistakes. >> So Liz, you talked about the education, the enablement, the 72 sessions, the importance of CloudNativeSecurityCon being its own event this year. What are your hopes and dreams for the practitioners to be able to learn from this event? How do you see the event as really supporting the growth, the development of the cloud native security community as a whole? >> Yeah, I think it's really important that we think of it as a Cloud Native Security community. You know, there are lots of interesting sort of hacker community security related community. Cloud native has been very community focused for a long time, and we really saw, particularly through the tag, the security tag, that there was this growing group of people who were, really wanted to work at that intersection between security and cloud native. And yeah, I think things are going really well this week so far, So I hope this is, you know, the first of many additions of this conference. I think it will also be interesting to see how the balance between a smaller, more focused event, compared to the giant KubeCon and cloud native cons. I, you know, I think there's space for both things, but whether or not there will be other smaller focus areas that want to stand alone and justify being able to stand alone as their own separate conferences, it speaks to the growth of cloud native in general that this is worthwhile doing. >> Yeah. >> It is, and what also speaks to, it reminds me of our tagline here at theCUBE, being able to extract the signal from the noise. Having this event as a standalone, being able to extract the value in it from a security perspective, that those practitioners and the community at large is going to be able to glean from these conversations is something that will be important, that we'll be keeping our eyes on. >> Absolutely. Makes sense for me, yes. >> Yeah, and I think, you know, one of the things, Lisa, that I want to get in, and if you don't mind asking Dave his thoughts, because he just did a breaking analysis on the security landscape. And Dave, you know, as Liz talking about some of these root level things, we talk about silicon advances, powering machine learning, we've been covering a lot of that. You've been covering the general security industry. We got RSA coming up reinforced with AWS, and as you see the cloud native developer first, really driving the standards of the super cloud, the multicloud, you're starting to see a lot more application focus around latency and kind of controlling that, These abstraction layer's starting to see a lot more growth. What's your take, Dave, on what Liz and- is talking about because, you know, you're analyzing the horses on the track, and there's sometimes the old guard security folks, and you got open source continuing to kick butt. And even on the ML side, we've been covering some of these foundation models, you're seeing a real technical growth in open source at all levels and, you know, you still got some proprietary machine learning stuff going on, but security's integrating all that. What's your take and your- what's your breaking analysis on the security piece here? >> I mean, to me the two biggest problems in cyber are just the lack of talent. I mean, it's just really hard to find super, you know, deep expertise and get it quickly. And I think the second is it's just, it's so many tools to deal with. And so the architecture of security is just this mosaic and a mess. That's why I'm excited about initiatives like eBPF because it does simplify things, and developers are being asked to do a lot. And I think one of the other things that's emerging is when you- when we talk about Industry 4.0, and IIoT, you- I'm seeing a lot of tools that are dedicated just to that, you know, slice of the world. And I don't think that's the right approach. I think that there needs to be a more comprehensive view. We're seeing, you know, zero trust architectures come together, and it's going to take some time, but I think that you're going to definitely see, you know, some rethinking of how to architect security. It's a game of whack-a-mole, but I think the industry is just- the technology industry is doing a really really good job of, you know, working hard to solve these problems. And I think the answer is not just another bespoke tool, it's a broader thinking around architectures and consolidating some of those tools, you know, with an end game of really addressing the problem in a more comprehensive fashion. >> Liz, in the last minute or so we have your thoughts on how automation and scale are driving some of these forcing functions around, you know, taking away the toil and the muck around developers, who just want stuff to be code, right? So infrastructure as code. Is that the dynamic here? Is this kind of like new, or is it kind of the same game, different kind of thing? (chuckles) 'Cause you're seeing a lot more machine learning, a lot more automation going on. What's, is that having an impact? What's your thoughts? >> Automation is one of the kind of fundamental underpinnings of cloud native. You know, we're expecting infrastructure to be written as code, We're expecting the platform to be defined in yaml essentially. You know, we are expecting the Kubernetes and surrounding tools to self-heal and to automatically scale and to do things like automated security. If we think about supply chain, you know, automated dependency scanning, think about runtime. Network policy is automated firewalling, if you like, for a cloud native era. So, I think it's all about making that platform predictable. Automation gives us some level of predictability, even if the underlying hardware changes or the scale changes, so that the application developers have something consistent and standardized that they can write to. And you know, at the end of the day, it's all about the business applications that run on top of this infrastructure >> Business applications and the business outcomes. Liz, we so appreciate your time talking to us about this inaugural event, CloudNativeSecurityCon 23. The value in it for those practitioners, all of the content that's going to be discussed and learned, and the growth of the community. Thank you so much, Liz, for sharing your insights with us today. >> Thanks for having me. >> For Liz Rice, John Furrier and Dave Vellante, I'm Lisa Martin. You're watching the Cube's coverage of CloudNativeSecurityCon 23. (electronic music)

(bright upbeat music) >> Welcome back to Detroit guys and girls. Lisa Martin here with John Furrier. We've been on the floor at KubeCon + CloudNativeCon North America for about two days now. We've been breaking news, we would have a great conversations, John. We love talking with CUBE alumni whose companies are just taking off. And we get to do that next again. >> Well, this next segment's awesome. We have former CUBE host, Brian Gracely, here who's an executive in this company. And then the entrepreneur who we're going to talk with. She was on theCUBE when it just started now they're extremely successful. It's going to be a great conversation. >> It is, Idit Levine is here, the founder and CEO of solo.io. And as John mentioned, Brian Gracely. You know Brian. He's the VP of Product Marketing and Product Strategy now at solo.io. Guys, welcome to theCUBE, great to have you here. >> Thanks for having us. >> Idit: Thank so much for having us. >> Talk about what's going on. This is a rocket ship that you're riding. I was looking at your webpage, you have some amazing customers. T-Mobile, BMW, Amex, for a marketing guy it must be like, this is just- >> Brian: Yeah, you can't beat it. >> Kid in a candy store. >> Brian: Can't beat it. >> You can't beat it. >> For giant companies like that, giant brands, global, to trust a company of our size it's trust, it's great engineering, it's trust, it's fantastic. >> Idit, talk about the fast trajectory of this company and how you've been able to garner trust with such mass organizations in such a short time period. >> Yes, I think that mainly is just being the best. Honestly, that's the best approach I can say. The team that we build, honestly, and this is a great example of one of them, right? And we're basically getting the best people in the industry. So that's helpful a lot. We are very, very active on the open source community. So basically it building it, anyway, and by doing this they see us everywhere. They see our success. You're starting with a few customers, they're extremely successful and then you're just creating this amazing partnership with them. So we have a very, very unique way we're working with them. >> So hard work, good code. >> Yes. >> Smart people, experience. >> That's all you need. >> It's simple, why doesn't everyone do it? >> It's really easy. (all laughing) >> All good, congratulations. It's been fun to watch you guys grow. Brian, great to see you kicking butt in this great company. I got to ask about the landscape because I love the ServiceMeshCon you guys had on a co-located event on day zero here as part of that program, pretty packed house. >> Brian: Yep. >> A lot of great feedback. This whole ServiceMesh and where it fits in. You got Kubernetes. What's the update? Because everything's kind of coming together- >> Brian: Right. >> It's like jello in the refrigerator it kind of comes together at the same time. Where are we? >> I think the easiest way to think about it is, and it kind of mirrors this event perfectly. So the last four or five years, all about Kubernetes, built Kubernetes. So every one of our customers are the ones who have said, look, for the last two or three years, we've been building Kubernetes, we've had a certain amount of success with it, they're building applications faster, they're deploying and then that success leads to new challenges, right? So we sort of call that first Kubernetes part sort of CloudNative 1.0, this and this show is really CloudNative 2.0. What happens after Kubernetes service mesh? Is that what happens after Kubernetes? And for us, Istio now being part of the CNCF, huge, standardized, people are excited about it. And then we think we are the best at doing Istio from a service mesh perspective. So it's kind of perfect, perfect equation. >> Well, I'll turn it on, listen to your great Cloud cast podcast, plug there for you. You always say what is it and what isn't it? >> Brian: Yeah. >> What is your product and what isn't it? >> Yeah, so our product is, from a purely product perspective it's service mesh and API gateway. We integrate them in a way that nobody else does. So we make it easier to deploy, easier to manage, easier to secure. I mean, those two things ultimately are, if it's an internal API or it's an external API, we secure it, we route it, we can observe it. So if anybody's, you're building modern applications, you need this stuff in order to be able to go to market, deploy at scale all those sort of things. >> Idit, talk about some of your customer conversations. What are the big barriers that they've had, or the challenges, that solo.io comes in and just wipes off the table? >> Yeah, so I think that a lot of them, as Brian described it, very, rarely they had a success with Kubernetes, maybe a few clusters, but then they basically started to on-ramp more application on those clusters. They need more cluster maybe they want multi-class, multi-cloud. And they mainly wanted to enable the team, right? This is why we all here, right? What we wanted to eventually is to take a piece of the infrastructure and delegate it to our customers which is basically the application team. So I think that that's where they started to see the problem because it's one thing to take some open source project and deploy it very little bit but the scale, it's all about the scale. How do you enable all those millions of developers basically working on your platform? How do you scale multi-cloud? What's going on if one of them is down, how do you fill over? So that's exactly the problem that they have >> Lisa: Which is critical for- >> As bad as COVID was as a global thing, it was an amazing enabler for us because so many companies had to say... If you're a retail company, your front door was closed, but you still wanted to do business. So you had to figure out, how do I do mobile? How do I be agile? If you were a company that was dealing with like used cars your number of hits were through the roof because regular cars weren't available. So we have all these examples of companies who literally overnight, COVID was their digital transformation enabler. >> Lisa: Yes. Yes. >> And the scale that they had to deal with, the agility they had to deal with, and we sort of fit perfectly in that. They re-looked at what's our infrastructure look like? What's our security look like? We just happened to be right place in the right time. >> And they had skillset issues- >> Skillsets. >> Yeah. >> And the remote work- >> Right, right. >> Combined with- >> Exactly. >> Modern upgrade gun-to-the-head, almost, kind of mentality. >> And we're really an interesting company. Most of the interactions we do with customers is through Slack, obviously it was remote. We would probably be a great Slack case study in terms of how to do business because our customers engage with us, with engineers all over the world, they look like one team. But we can get them up and running in a POC, in a demo, get them through their things really, really fast. It's almost like going to the public cloud, but at whatever complexity they want. >> John: Nice workflow. >> So a lot of momentum for you guys silver linings during COVID, which is awesome we do hear a lot of those stories of positive things, the acceleration of digital transformation, and how much, as consumers, we've all benefited from that. Do you have one example, Brian, as the VP of product marketing, of a customer that you really think in the last two years just is solo.io's value proposition on a platter? >> I'll give you one that I think everybody can understand. So most people, at least in the United States, you've heard of Chick-fil-A, retail, everybody likes the chicken. 2,600 stores in the US, they all shut down and their business model, it's good food but great personal customer experience. That customer experience went away literally overnight. So they went from barely anybody using the mobile application, and hence APIs in the backend, half their business now goes through that to the point where, A, they shifted their business, they shifted their customer experience, and they physically rebuilt 2,600 stores. They have two drive-throughs now that instead of one, because now they have an entire one dedicated to that mobile experience. So something like that happening overnight, you could never do the ROI for it, but it's changed who they are. >> Lisa: Absolutely transformative. >> So, things like that, that's an example I think everybody can kind of relate to. Stuff like that happened. >> Yeah. >> And I think that's also what's special is, honestly, you're probably using a product every day. You just don't know that, right? When you're swiping your credit card or when you are ordering food, or when you using your phone, honestly the amount of customer they were having, the space, it's like so, every industry- >> John: How many customers do you have? >> I think close to 200 right now. >> Brian: Yeah. >> Yeah. >> How many employees, can you gimme some stats? Funding, employees? What's the latest statistics? >> We recently found a year ago $135 million for a billion dollar valuation. >> Nice. >> So we are a unicorn. I think when you took it we were around like 50 ish people. Right now we probably around 180, and we are growing, we probably be 200 really, really quick. And I think that what's really, really special as I said the interaction that we're doing with our customers, we're basically extending their team. So for each customer is basically a Slack channel. And then there is a lot of people, we are totally global. So we have people in APAC, in Australia, New Zealand, in Singapore we have in AMEA, in UK and in Spain and Paris, and other places, and of course all over US. >> So your use case on how to run a startup, scale up, during the pandemic, complete clean sheet of paper. >> Idit: We had to. >> And what happens, you got Slack channels as your customer service collaboration slash productivity. What else did you guys do differently that you could point to that's, I would call, a modern technique for an entrepreneurial scale? >> So I think that there's a few things that we are doing different. So first of all, in Solo, honestly, there is a few things that differentiated from, in my opinion, most of the companies here. Number one is look, you see this, this is a lot, a lot of new technology and one of the things that the customer is nervous the most is choosing the wrong one because we saw what happened, right? I don't know the orchestration world, right? >> John: So choosing and also integrating multiple things at the same time. >> Idit: Exactly. >> It's hard. >> And this is, I think, where Solo is expeditious coming to place. So I mean we have one team that is dedicated like open source contribution and working with all the open source community and I think we're really good at picking the right product and basically we're usually right, which is great. So if you're looking at Kubernetes, we went there for the beginning. If you're looking at something like service mesh Istio, we were all envoy proxy and out of process. So I think that by choosing these things, and now Cilium is something that we're also focusing on. I think that by using the right technology, first of all you know that it's very expensive to migrate from one to the other if you get it wrong. So I think that's one thing that is always really good at. But then once we actually getting those portal we basically very good at going and leading those community. So we are basically bringing the customers to the community itself. So we are leading this by being in the TOC members, right? The Technical Oversight Committee. And we are leading by actually contributing a lot. So if the customer needs something immediately, we will patch it for him and walk upstream. So that's kind of like the second thing. And the third one is innovation. And that's really important to us. So we pushing the boundaries. Ambient, that we announced a month ago with Google- >> And STO, the book that's out. >> Yes, the Ambient, it's basically a modern STO which is the future of SDL. We worked on it with Google and their NDA and we were listed last month. This is exactly an example of us basically saying we can do it better. We learn from our customers, which is huge. And now we know that we can do better. So this is the third thing, and the last one is the partnership. I mean honestly we are the extension team of the customer. We are there on Slack if they need something. Honestly, there is a reason why our renewal rate is 98.9 and our net extension is 135%. I mean customers are very, very happy. >> You deploy it, you make it right. >> Idit: Exactly, exactly. >> The other thing we did, and again this was during COVID, we didn't want to be a shell-for company. We didn't want to drop stuff off and you didn't know what to do with it. We trained nearly 10,000 people. We have something called Solo Academy, which is free, online workshops, they run all the time, people can come and get hands on training. So we're building an army of people that are those specialists that have that skill set. So we don't have to walk into shops and go like, well okay, I hope six months from now you guys can figure this stuff out. They're like, they've been doing that. >> And if their friends sees their friend, sees their friend. >> The other thing, and I got to figure out as a marketing person how to do this, we have more than a few handfuls of people that they've got promoted, they got promoted, they got promoted. We keep seeing people who deploy our technologies, who, because of this stuff they're doing- >> John: That's a good sign. They're doing it at at scale, >> John: That promoter score. >> They keep getting promoted. >> Yeah, that's amazing. >> That's a powerful sort of side benefit. >> Absolutely, that's a great thing to have for marketing. Last question before we ran out of time. You and I, Idit, were talking before we went live, your sessions here are overflowing. What's your overall sentiment of KubeCon 2022 and what feedback have you gotten from all the customers bursting at the seam to come talk to you guys? >> I think first of all, there was the pre-event which we had and it was a lot of fun. We talked to a lot of customer, most of them is 500, global successful company. So I think that people definitely... I will say that much. We definitely have the market feed, people interested in this. Brian described very well what we see here which is people try to figure out the CloudNative 2.0. So that's number one. The second thing is that there is a consolidation, which I like, I mean STO becoming right now a CNCF project I think it's a huge, huge thing for all the community. I mean, we're talking about all the big tweak cloud, we partner with them. I mean I think this is a big sign of we agree which I think is extremely important in this community. >> Congratulations on all your success. >> Thank you so much. >> And where can customers go to get their hands on this, solo.io? >> Solo.io? Yeah, absolutely. >> Awesome guys, this has been great. Congratulations on the momentum. >> Thank you. >> The rocket ship that you're riding. We know you got to get to the airport we're going to let you go. But we appreciate your insights and your time so much, thank you. >> Thank you so much. >> Thanks guys, we appreciate it. >> A pleasure. >> Thanks. >> For our guests and John Furrier, This is Lisa Martin live in Detroit, had to think about that for a second, at KubeCon 2022 CloudNativeCon. We'll be right back with our final guests of the day and then the show wraps, so stick around. (gentle music)

>> Announcer: "theCUBE" presents "Kubecon and Cloudnativecon Europe, 2022" brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to Valencia, Spain and "Kubecon + Cloudnativecon Europe, 2022." I'm Keith Townsend, and we're continuing the conversations with amazing people doing amazing things. I think we've moved beyond a certain phase of the hype cycle when it comes to Kubernetes. And we're going to go a little bit in detail with that today, and on all the sessions, I have today with me, Taylor Dolezal. New head of CNCF Ecosystem. So, first off, what does that mean new head of? You're the head of CNCF Ecosystem? What is the CNCF Ecosystem? >> Yeah. Yeah. It's really the end user ecosystem. So, the CNCF is comprised of really three pillars. And there's the governing board, they oversee the budget and fun things, make sure everything's signed and proper. Then there's the Technical Oversight Committee, TOC. And they really help decide the technical direction of the organization through deliberation and talking about which projects get invited and accepted. Projects get donated, and the TOC votes on who's going to make it in, based on all this criteria. And then, lastly, is the end user ecosystem, that encompasses a whole bunch of different working groups, special interest groups. And that's been really interesting to kind of get a deeper sense into, as of late. So, there are groups like the developer experience group, and the user research group. And those have very specific focuses that kind of go across all industries. But what we've seen lately, is that there are really deep wants to create, whether it be financial services user group, and things like that, because end users are having trouble with going to all of the different meetings. If you're a company, a vendor member company that's selling authentication software, or something in networking, makes sense to have a SIG network, SIG off, and those kinds of things. But when it comes down to like Boeing that just joined, does that make sense for them to jump into all those meetings? Or does it make sense to have some other kind of thing that is representative of them, so that they can attend that one thing, it's specific to their industry? They can get that download and kind of come up to speed, or find the best practices as quickly as possible in a nice synthesized way. >> So, you're 10 weeks into this role. You're coming from a customer environment. So, talk to me a little bit about the customer side of it? When you're looking at something, it's odd to call CNCF massive. But it is, 7.1 million members, and the number of contributing projects, et cetera. Talk to me about the view from the outside versus the view now that you're inside? >> Yeah, so honestly, it's been fun to kind of... For me, it's really mirrored the open-source journey. I've gone to Kubecon before, gotten to enjoy all of the booths, and trying to understand what's going on, and then worked for HashiCorp before coming to the CNCF. And so, get that vendor member kind of experience working the booth itself. So, kind of getting deeper and deeper into the stack of the conference itself. And I keep saying, vendor member and end user members, the difference between those, is end users are not organizations that sell cloud native services. Those are the groups that are kind of more consuming, the Airbnbs, the Boeings, the Mercedes, these people that use these technologies and want to kind of give that feedback back to these projects. But yeah, very incredibly massive and just sprawling when it comes to working in all those contexts. >> So, I have so many questions around, like the differences between having you as an end user and in inter-operating with vendors and the CNCF itself. So, let's start from the end user lens. When you're an end user and you're out discovering open-source and cloud native products, what's that journey like? How do you go from saying, okay, I'm primarily focused on vendor solutions, to let me look at this cloud native stack? >> Yeah, so really with that, there's been, I think that a lot of people have started to work with me and ask for, "Can we have recommended architectures? Can we have blueprints for how to do these things?" When the CNCF doesn't want to take that position, we don't want to kind of be the king maker and be like, this is the only way forward. We want to be inclusive, we want to pull in these projects, and kind of give everyone the same boot strap and jump... I missing the word of it, just ability to kind of like springboard off of that. Create a nice base for everybody to get started with, and then, see what works out, learn from one another. I think that when it comes to Kubernetes, and Prometheus, and some other projects, being able to share best practices between those groups of what works best as well. So, within all of the separations of the CNCF, I think that's something I've found really fun, is kind of like seeing how the projects relate to those verticals and those groups as well. Is how you run a project, might actually have a really good play inside of an organization like, "I like that idea. Let's try that out with our team." >> So, like this idea of springboarding. You know, is when an entrepreneur says, "You know what? I'm going to quit my job and springboard off into doing something new." There's a lot of uncertainty, but for enterprise, that can be really scary. Like we're used to our big vendors, HashiCorp, VMware, Cisco kind of guiding us and telling us like, what's next? What is that experience like, springboarding off into something as massive as cloud native? >> So, I think it's really, it's a great question. So, I think that's why the CNCF works so well, is the fact that it's a safe place for all these companies to come together, even companies of competing products. you know, having that common vision of, we want to make production boring again, we don't want to have so much sprawl and have to take in so much knowledge at once. Can we kind of work together to create all these things to get rid of our adminis trivia or maintenance tasks? I think that when it comes to open-source in general, there's a fantastic book it's called "Working in Public," it's by Stripe Press. I recommend it all over the place. It's orange, so you'll recognize it. Yeah, it's easy to see. But it's really good 'cause it talks about the maintainer journey, and what things make it difficult. And so, I think that that's what the CNCF is really working hard to try to get rid of, is all this monotonous, all these monotonous things, filing issues, best practices. How do you adopt open-source within your organization? We have tips and tricks, and kind of playbooks in ways that you could accomplish that. So, that's what I find really useful for those kinds of situations. Then it becomes easier to adopt that within your organization. >> So, I asked Priyanka, CNCF executive director last night, a pretty tough question. And this is kind of in the meat of what you do. What happens when you? Let's pick on service mesh 'cause everyone likes to pick on service mesh. >> XXXX: Yeah. >> What happens when there's differences at that vendor level on the direction of a CIG or a project, or the ecosystem around service mesh? >> Yeah, so that's the fun part. Honestly, is 'cause people get to hash it out. And so, I think that's been the biggest thing for me finding out, was that there's more than one way to do thing. And so, I think it always comes down to use case. What are you trying to do? And then you get to solve after that. So, it really is, I know it depends, which is the worst answer. But I really do think that's the case, because if you have people that are using something within the automotive space, or in the financial services space, they're going to have completely different needs, wants, you know, some might need to run Coball or Fortran, others might not have to. So, even at that level, just down to what your tech stack looks like, audits, and those kinds of things, that can just really differ. So, I think it does come down to something more like that. >> So, the CNCF loosely has become kind of a standards body. And it's centered around the core project Kubernetes? >> Mm-hmm. >> So, what does it mean, when we're looking at larger segments such as service mesh or observability, et cetera, to be Kubernetes compliant? Where's the point, if any, that the CNCF steps in versus just letting everyone hash it out? Is it Kubernetes just need to be Kubernetes compliant and everything else is free for all? >> Honestly, in many cases, it's up to the communities themselves to decide that. So, the groups that are running OCI, the Open Container Interface, Open Storage Interface, all of those things that we've agreed on as ways to implement those technologies, I think that's where the CNCF, that's the line. That's where the CNCF gets up to. And then, it's like we help foster those communities and those conversations and asking, does this work for you? If not, let's talk about it, let's figure out why it might not. And then, really working closely with community to kind of help bring those things forward and create action items. >> So, it's all about putting the right people in the rooms and not necessarily playing referee, but to get people in the right room to have and facilitate the conversation? >> Absolutely. Absolutely. Like all of the booths behind us could have their own conferences, but we want to bring everybody together to have those conversations. And again, sprawling can be really wild at certain times, but it's good to have those cross understandings, or to hear from somebody that you're like, "Oh, my goodness, I didn't even think about that kind of context or use case." So, really inclusive conversation. >> So, organizations like Boeing, Adobe, Microsoft, from an end user perspective, it's sometimes difficult to get those organizations into these types of communities. How do you encourage them to participate in the conversation 'cause their voice is extremely important? >> Yeah, that I'd also say it really is the community. I really liked the Kubernetes documentary that was put out, working with some of the CNCF folks and core, and beginning Kubernetes contributors and maintainers. And it just kind of blew me away when they had said, you know, what we thought was success, was seeing Kubernetes in an Amazon Data Center. That's when we knew that this was going to take root. And you'd rarely hear that, is like, "When somebody that we typically compete with, its success is seeing it, seeing them use that." And so, I thought was really cool. >> You know, I like to use this technology for my community of skipping rope. You see the girls and boys jumping double Dutch rope. And you think, "I can do that. Like it's just jumping." But there's this hesitation to actually, how do you start? How do you get inside of it? The question is how do you become a member of the community? We've talked a lot about what happens when you're in the community. But how do you join the community? >> So, really, there's a whole bunch of ways that you can. Actually, the shirt that I'm wearing, I got from the 114 Release. So, this is just a fun example of that community. And just kind of how welcoming and inviting that they are. Really, I do think it's kind of like a job breaker. Almost you start at the outside, you start using these technologies, even more generally like, what is DevOps? What is production? How do I get to infrastructure, architecture, or software engineering? Once you start there, you start working your way in, you develop a stack, and then you start to see these tools, technologies, workflows. And then, after you've kind of gotten a good amount of time spent with it, you might really enjoy it like that, and then want to help contribute like, "I like this, but it would be great to have a function that did this. Or I want a feature that does that." At that point in time, you can either take a look at the source code on GitHub, or wherever it's hosted, and then start to kind of come up with that, some ideas to contribute back to that. And then, beyond that, you can actually say, "No, I kind of want to have these conversations with people." Join in those special interest groups, and those meetings to kind of talk about things. And then, after a while, you can kind of find yourself in a contributor role, and then a maintainer role. After that, if you really like the project, and want to kind of work with community on that front. So, I think you had asked before, like Microsoft, Adobe and these others. Really it's about steering the projects. It's these communities want these things, and then, these companies say, "Okay, this is great. Let's join in the conversation with the community." And together again, inclusivity, and bringing everybody to the table to have that discussion and push things forward. >> So, Taylor, closing message. What would you want people watching this show to get when they think about ecosystem and CNCF? >> So, ecosystem it's a big place, come on in. Yeah, (laughs) the water's just fine. I really want people to take away the fact that... I think really when it comes down to, it really is the community, it's you. We are the end user ecosystem. We're the people that build the tools, and we need help. No matter how big or small, when you come in and join the community, you don't have to rewrite the Kubernetes scheduler. You can help make documentation that much more easy to understand, and in doing so, helping thousands of people, If I'm going through the instructions or reading a paragraph, doesn't make sense, that has such a profound impact. And I think a lot of people miss that. It's like, even just changing punctuation can have such a giant difference. >> Yeah, I think people sometimes forget that community, especially community-run projects, they need product managers. They need people that will help with communications, people that will help with messaging, websites updating. Just reachability, anywhere from developing code to developing documentation, there's ways to jump in and help the community. From Valencia, Spain, I'm Keith Townsend, and you're watching "theCUBE," the leader in high tech coverage. (bright upbeat music)

>>from around the globe. It's the Cube with coverage of Coop Con and Cloud, Native Con Europe 2020 Virtual brought to You by Red Hat, The Cloud Native Computing Foundation and its ecosystem Partners. Hi, I'm stupid, man. And this is the Cube's coverage of Cube con Cloud Native Con Europe event, which, of course, this year has gone virtual, really lets us be able to talk to those guests where they are around the globe. Really happy to welcome back to the program. Liz Rice. First of all, she is the vice president of Open Source Engineering at Aqua Security. She's also the chair of the Technical Oversight Committee has part of Ah CN cf. Liz, it is great to see you. Unfortunately, it's remote, but ah, great to catch up with you. Thanks for joining. >>Yeah, Thanks for having me. Nice to see you if you know across the ocean. >>So, uh, you know, one of the one of the big things? Of course, for the Cube Con show. It's the rallying point for the community. There are so many people participating. One of the things we always love to highlight its not only the the vendor ecosystem. But there is a very robust, engaged community of end users that participate in it. And as I mentioned, you're the chair of that technology oversight committee. So maybe just give our audience a little bit of, you know, in case they're not familiar with the TOC does. And let's talk about the latest pieces there. >>Yes, say the TOC is really hit. C can qualify the different projects that want to join the CNC F. So we're assessing whether or not they're cloud native. We're assessing whether they could joined at sandbox or incubation or graduation levels. Which of the different maturity levels that we have for for project within the CN CF yeah, we're really there, Teoh also provide it steering around the What does cloud native mean and what does it mean to be a project inside the CN CF community? We're also a voice for all of the projects. We're not the only voice, but, you know, part >>of our role >>really is to make sure the projects are getting what they need in order to be successful. So it's it's really around the technology and the projects that we call cloud native >>Yeah, and and obliges Cloud Native because when people first heard of the show, of course, Kubernetes and Cube Con was the big discussion point. But as you said, Cloud native, there's a lot of projects there. I just glanced at the sandbox page and I think there's over 30 in the sandbox category on and you know they move along their process until they're, you know, fully mature and reach that, you know, 1.0 state, which is the stamp of approval that, you know, this could be used in production. I understand there's been some updates for the sandbox process, so help us understand you know where that is and what's the new piece of that? >>Yeah. So it's really been because of the growth off cloud native in general, the popularity off the CN CF and so much innovation happening in our space. So there's been so many projects who want Teoh become hard off the CNC f family on and we used to have a sponsorship model where members of the TOC would essentially back projects that they wanted to see joining at the sandbox level. But we ran into a number of issues with that process on and also dealing with the scale, the number of applications that have come in. So we've revamped the process. We made it much easier for projects to apply as much simpler form where really not making so much judgment we're really saying is it's a cloud native project and we have some requirements in terms off some governance features that we need from a project. And it's worth mentioning that when a project joins the CN CF, they are donating the intellectual property and the trademark off that project into the foundation. So it's not something that people should take lightly. But we have tried to make it easier and therefore much smoother. We're able Teoh assess the applications much more quickly, which I think everyone, the community, the projects, those of us on the TOC We're all pretty happy that we can make that a much faster process. >>Yeah, I actually, it brings up An interesting point is so you know, I've got a little bit of background in standards committees. A swell as I've been involved in open source for a couple of decades now some people don't understand. You know, when you talk about bringing a project under a foundation. You talked about things like trademarks and the like. There are more than one foundation out there for CN CF Falls under the Linux Foundation. Google, of course, brought Kubernetes in fully to be supported. There's been some rumblings I've heard for the last couple of years about SDO and K Native and I know about a month before the show there was some changes along SDO and what Google was doing there may be without trying to pass too many judgments in getting into some of the political arguments, help us understand. You know what Google did and you know where that kind of comparison the projects that sit in the CN cf themselves. >>Yeah, So I e I guess two years ago around two years ago, Stu was very much the new kid in the cloud native block. So much excitement about the project. And it was actually when I was a program co chair that we had a lot of talks about sdo at Cube Con cloud native bomb, particularly in Copenhagen, I'm recalling. And, uh, I think everyone I just saw a natural fit between that project on the CN, CF and There was an assumption from a lot of people across the community that it would eventually become part of the CNC f. That was it's natural home. And one of the things that we saw in recent weeks was a very clear statement from IBM, who were one off the Uh huh, yeah, big contributing companies towards that project that that was also their expectation. They were very much under the impression that Stu would be donated to the CN CF at an appropriate point of maturity, and unfortunately, that didn't happen. From my point of view, I think that has sown a lot of confusion amongst the community because we've seen so much. It's very much a project of fits. Service mesh designed to work with kubernetes is it really does. You're fit naturally in with the other CN CF projects. So it's created confusion for end users who, many of whom assume that it was called the CN CF, and that it has the neutral governance that the other projects. It's part of the requirements that we have on those projects. They have to have an open governance that they're not controlled by a single vendor, Uh, and we've seen that you know that confusion, Andi. Frustration around that confusion being expressed by more and more end users as well as other people across the community. And yeah, the door is still open, you know, we would still love to see SDO join the community. Clearly there are different opinions within the SD wan maintainers. I will have to see what happens. >>Yeah, lets you bring up some really good points. You know, absolutely some of some of that confusion out there. Absolutely. I've heard from customers that if they're making a decision point, they might say, Hey, maybe I'm not going to go down that maybe choose something else because I'm concerned about that. Um, you know, I sdo front and center k native, another project currently under Google that has, you know, a number of other big vendors in the community that aiding in that So hopefully we will see some progress on that, you know, going forward. But, you know, back to you talked about, You know, the TOC doesn't make judgements as to you know which project and how they are. One of the really nice things out there in the CN CF, it's like the landscape just for you to help, understand? Okay, here's all of these projects. Here's the different categories they fit in. Here is where they are along that maturity. There's another tool that I read. Cheryl Hung blogged about the technology radar. I believe for continuous delivery is the first technology radar. Help us understand how that is, you know, not telling customers what to do but giving them a little guidance that you know where some of these projects projects fit. In a certain segment, >>Yeah, the technology radar is a really great initiative. I'm really excited about it because we have increasing numbers or end users who are using these different projects it both inside the CN CF and projects that are outside of the CNC F family. Your end users are building stacks. They're solving real problems in the real world and with the technology radar. What Cheryl's been able to facilitate is having the end you to the end user community share with us. What tools? They're actually using what they actually believe are the right hammers for specific nails. And, you know, it's it's one thing for us as it's more on the developer or vendor side Teoh look at different projects and say what we think are the better solutions for solving different problems. Actually hearing from the horse's mouth from the end users who are doing it in the real world is super valuable. And I think that is a really useful input to help us understand. What are the problems that the end user is still a challenge by what are the gaps that we still need to fail more input we can get from the end user community, the more will be solving real problems and no necessarily academic problems that we haven't sorry discovered in >>the real world. Alright, well is, you know, teeing up a discussion about challenges that users still have in the world. If we go to your primary jobs, Main hat is you live in the security world and you know, we know security is still something, you know, front and center. It is something that has never done lots of discussion about the shared responsibility model and how cloud native in security fit together and all that. So maybe I know there's some new projects there, but love to just give me a snap shot as where we are in the security space. As I said, Overall, it's been, you know, super important topic for years. This year, with a global pandemic going on, security seems to be raised even more. We've seen a couple of acquisitions in the space, of course. Aqua Security helping customers along their security journey. So what do you seeing out there in the marketplace today and hear from your custom? >>Yeah, I Every business this year has, you know, look at what's going on and you know, it's been crazy time for everyone, but we've been pleasantly surprised at how, you know, in relative terms, our business has been able to. It's been strong, you know. And I think you know what you're touching on the fact that people are working remotely. People are doing so many things online. Security is evermore online. Cloud security's evermore part off what people need to pay attention to. We're doing more and more business online. So, actually, for those of us in the security business, it has bean, you know that there have been some silver linings to this this pandemic cloud? Um, yes. So many times in technology. The open source projects and in particularly defaults in kubernetes. Things are improving its long Bina thing that I've you know, I wished for and talked about that. You know, some of the default settings has always been the most secure they could be. We've seen a lot of improvements over the last 23 years we're seeing continuing to see innovation in the open source world as well as you know, on the commercial side and products that vendors like Akwa, you know, we continue to innovate, continue to write you ways for customers to validate that the application workloads that they're going to run are going to run securely in the cloud. >>Alright and lives. There's a new project that I know. Ah, you know, you Aqua are participating in Tell us a little bit about Starbird. You know what's what's the problem? It's helping solve and you know where that budget >>Yes, So stockholders, one of our open source initiatives coming out of my team are equal on, and the idea is to take security reporting information and turn it into a kubernetes native, uh, resources custom resources. And then that means the security information, your current security status could be queried over the kubernetes AP I, as you're querying the status or the deployment, say you can also be clearing to see whether it's passing configuration audits or it's passing vulnerability scans for the application containers inside that deployment. So that information is available through the same AP eyes through the queue control interface through dashboards like Octane, which is a nice dashboard viewer for kubernetes. And starboard brings security information not just from acquittals but from other vendor tools as well front and center into that kubernetes experience. So I'm really excited about Star Border. It's gonna be a great way of getting security visibility, Teoh more kubernetes use it >>all right. And we were talking earlier about just the maturity of projects and how they get into the sandbox. Is is this still pretty sandbox for >>this? OK, we're still very much in the early phases and you know it. I think in the open source world, we have the ability to share what we're doing early so that we can get feedback. We can see how it resonates with with real users. We've had some great feedback from partners that we've worked with and some actual customers who actually collaborated with When we're going through the initial design, some great feedback. There's still lots of work to do. But, yeah, the initial feedback has been really positive. >>Yeah, is usually the event is one of those places where you can help try toe, recruit some other people that might have tools as well as educate customers about what's going on. So is that part of the call to action on this is, you know, what are you looking for for kind of the rest of 2020 when it when it comes to this project? >>Yeah, absolutely. So internally, we're working on an operator which will automate some of the work that's double does in the background in terms off getting more collaboration. We would love to see integrations from or security tooling. We're talking with some people across the community about the resource definition, so we've come up with some custom resource definitions, but we'd love them to be applicable it to a variety of different tools. So we want to get feedback on on those definitions of people are interested in collaborating on that absolutely do come and talk to me and my team are reluctant. >>Great. Listen, and I'll give you the final word. Obviously, we're getting the community together while we're part So you know any other you know, engagement opportunities, you get togethers. Things that you want people to know about the European show this year. >>Well, it's gonna be really you know, I'm on tenterhooks to see whether or not we can recreate the same atmosphere as we would have in Q con. I mean, it won't be exactly the same, but I really hope that people will engage online. Do come and, you know, ask questions of the speakers. Come and talk to the vendors, get into slack channels with the community. You know, this is an opportunity to pretend we're in the same room. Let's let's let's do what we can Teoh recreate as close as we can. That community experience that you keep corn is famous for >>Yeah, absolutely. That whole way track is something that is super challenging to recreate. And there's no way that I am getting the Indonesian food that I was so looking forward to in Amsterdam just such a great culinary and cultural city. So hopefully sometime in the future will be able to be back there. Liz Rice. Always pleasure catching up with you. Thanks so much for all the work you're doing on the TOC. And always a pleasure talking to you. >>Thanks for having me. >>All right, Lots more coverage from Cube Con Cloud, Native con the European 2020 show, Of course. Virtual I'm stew minimum. And thank you for watching the Cube. Yeah, yeah, yeah, yeah.

>> Announcer: From around the globe, it's the queue with digital coverage of DockerCon live 2020. Brought to you by Docker and its ecosystem partners. >> Welcome, welcome, welcome to DockerCon 2020. We got over 50,000 people registered so there's clearly a ton of interest in the world of Docker and Eddie's as I like to call it. And we've assembled a power panel of Open Source and cloud native experts to talk about where things stand in 2020 and where we're headed. I'm Shawn Conley, I'll be the moderator for today's panel. I'm also a proud alum of JBoss, Red Hat, SpringSource, VMware and Hortonworks and I'm broadcasting from my hometown of Philly. Our panelists include; Michelle Noorali, Senior Software Engineer at Microsoft, joining us from Atlanta, Georgia. We have Kelsey Hightower, Principal developer advocate at Google Cloud, joining us from Washington State and we have Chris Aniszczyk, CTO CIO at the CNCF, joining us from Austin, Texas. So I think we have the country pretty well covered. Thank you all for spending time with us on this power panel. Chris, I'm going to start with you, let's dive right in. You've been in the middle of the Docker netease wave since the beginning with a clear focus on building a better world through open collaboration. What are your thoughts on how the Open Source landscape has evolved over the past few years? Where are we in 2020? And where are we headed from both community and a tech perspective? Just curious to get things sized up? >> Sure, when CNCF started about roughly four, over four years ago, the technology mostly focused on just the things around Kubernetes, monitoring communities with technology like Prometheus, and I think in 2020 and the future, we definitely want to move up the stack. So there's a lot of tools being built on the periphery now. So there's a lot of tools that handle running different types of workloads on Kubernetes. So things like Uvert and Shay runs VMs on Kubernetes, which is crazy, not just containers. You have folks that, Microsoft experimenting with a project called Kruslet which is trying to run web assembly workloads natively on Kubernetes. So I think what we've seen now is more and more tools built around the periphery, while the core of Kubernetes has stabilized. So different technologies and spaces such as security and different ways to run different types of workloads. And at least that's kind of what I've seen. >> So do you have a fair amount of vendors as well as end users still submitting in projects in, is there still a pretty high volume? >> Yeah, we have 48 total projects in CNCF right now and Michelle could speak a little bit more to this being on the DOC, the pipeline for new projects is quite extensive and it covers all sorts of spaces from two service meshes to security projects and so on. So it's ever so expanding and filling in gaps in that cloud native landscape that we have. >> Awesome. Michelle, Let's head to you. But before we actually dive in, let's talk a little glory days. A rumor has it that you are the Fifth Grade Kickball Championship team captain. (Michelle laughs) Are the rumors true? >> They are, my speech at the end of the year was the first talk I ever gave. But yeah, it was really fun. I wasn't captain 'cause I wasn't really great at anything else apart from constantly cheer on the team. >> A little better than my eighth grade Spelling Champ Award so I think I'd rather have the kickball. But you've definitely, spent a lot of time leading an Open Source, you've been across many projects for many years. So how does the art and science of collaboration, inclusivity and teamwork vary? 'Cause you're involved in a variety of efforts, both in the CNCF and even outside of that. And then what are some tips for expanding the tent of Open Source projects? >> That's a good question. I think it's about transparency. Just come in and tell people what you really need to do and clearly articulate your problem, more clearly articulate your problem and why you can't solve it with any other solution, the more people are going to understand what you're trying to do and be able to collaborate with you better. What I love about Open Source is that where I've seen it succeed is where incentives of different perspectives and parties align and you're just transparent about what you want. So you can collaborate where it makes sense, even if you compete as a company with another company in the same area. So I really like that, but I just feel like transparency and honesty is what it comes down to and clearly communicating those objectives. >> Yeah, and the various foundations, I think one of the things that I've seen, particularly Apache Software Foundation and others is the notion of checking your badge at the door. Because the competition might be between companies, but in many respects, you have engineers across many companies that are just kicking butt with the tech they contribute, claiming victory in one way or the other might make for interesting marketing drama. But, I think that's a little bit of the challenge. In some of the, standards-based work you're doing I know with CNI and some other things, are they similar, are they different? How would you compare and contrast into something a little more structured like CNCF? >> Yeah, so most of what I do is in the CNCF, but there's specs and there's projects. I think what CNCF does a great job at is just iterating to make it an easier place for developers to collaborate. You can ask the CNCF for basically whatever you need, and they'll try their best to figure out how to make it happen. And we just continue to work on making the processes are clearer and more transparent. And I think in terms of specs and projects, those are such different collaboration environments. Because if you're in a project, you have to say, "Okay, I want this feature or I want this bug fixed." But when you're in a spec environment, you have to think a little outside of the box and like, what framework do you want to work in? You have to think a little farther ahead in terms of is this solution or this decision we're going to make going to last for the next how many years? You have to get more of a buy in from all of the key stakeholders and maintainers. So it's a little bit of a longer process, I think. But what's so beautiful is that you have this really solid, standard or interface that opens up an ecosystem and allows people to build things that you could never have even imagined or dreamed of so-- >> Gotcha. So I'm Kelsey, we'll head over to you as your focus is on, developer advocate, you've been in the cloud native front lines for many years. Today developers are faced with a ton of moving parts, spanning containers, functions, Cloud Service primitives, including container services, server-less platforms, lots more, right? I mean, there's just a ton of choice. How do you help developers maintain a minimalist mantra in the face of such a wealth of choice? I think minimalism I hear you talk about that periodically, I know you're a fan of that. How do you pass that on and your developer advocacy in your day to day work? >> Yeah, I think, for most developers, most of this is not really the top of mind for them, is something you may see a post on Hacker News, and you might double click into it. Maybe someone on your team brought one of these tools in and maybe it leaks up into your workflow so you're forced to think about it. But for most developers, they just really want to continue writing code like they've been doing. And the best of these projects they'll never see. They just work, they get out of the way, they help them with log in, they help them run their application. But for most people, this isn't the core idea of the job for them. For people in operations, on the other hand, maybe these components fill a gap. So they look at a lot of this stuff that you see in the CNCF and Open Source space as number one, various companies or teams sharing the way that they do things, right? So these are ideas that are put into the Open Source, some of them will turn into products, some of them will just stay as projects that had mutual benefit for multiple people. But for the most part, it's like walking through an ion like Home Depot. You pick the tools that you need, you can safely ignore the ones you don't need, and maybe something looks interesting and maybe you study it to see if that if you have a problem. And for most people, if you don't have that problem that that tool solves, you should be happy. No one needs every project and I think that's where the foundation for confusion. So my main job is to help people not get stuck and confused in LAN and just be pragmatic and just use the tools that work for 'em. >> Yeah, and you've spent the last little while in the server-less space really diving into that area, compare and contrast, I guess, what you found there, minimalist approach, who are you speaking to from a server-less perspective versus that of the broader CNCF? >> The thing that really pushed me over, I was teaching my daughter how to make a website. So she's on her Chromebook, making a website, and she's hitting 127.0.0.1, and it looks like geo cities from the 90s but look, she's making website. And she wanted her friends to take a look. So she copied and paste from her browser 127.0.0.1 and none of her friends could pull it up. So this is the point where every parent has to cross that line and say, "Hey, do I really need to sit down "and teach my daughter about Linux "and Docker and Kubernetes." That isn't her main goal, her goal was to just launch her website in a way that someone else can see it. So we got Firebase installed on her laptop, she ran one command, Firebase deploy. And our site was up in a few minutes, and she sent it over to her friend and there you go, she was off and running. The whole server-less movement has that philosophy as one of the stated goal that needs to be the workflow. So, I think server-less is starting to get closer and closer, you start to see us talk about and Chris mentioned this earlier, we're moving up the stack. Where we're going to up the stack, the North Star there is feel where you get the focus on what you're doing, and not necessarily how to do it underneath. And I think server-less is not quite there yet but every type of workload, stateless web apps check, event driven workflows check, but not necessarily for things like machine learning and some other workloads that more traditional enterprises want to run so there's still work to do there. So server-less for me, serves as the North Star for why all these Projects exists for people that may have to roll their own platform, to provide the experience. >> So, Chris, on a related note, with what we were just talking about with Kelsey, what's your perspective on the explosion of the cloud native landscape? There's, a ton of individual projects, each can be used separately, but in many cases, they're like Lego blocks and used together. So things like the surface mesh interface, standardizing interfaces, so things can snap together more easily, I think, are some of the approaches but are you doing anything specifically to encourage this cross fertilization and collaboration of bug ability, because there's just a ton of projects, not only at the CNCF but outside the CNCF that need to plug in? >> Yeah, I mean, a lot of this happens organically. CNCF really provides of the neutral home where companies, competitors, could trust each other to build interesting technology. We don't force integration or collaboration, it happens on its own. We essentially allow the market to decide what a successful project is long term or what an integration is. We have a great Technical Oversight Committee that helps shepherd the overall technical vision for the organization and sometimes steps in and tries to do the right thing when it comes to potentially integrating a project. Previously, we had this issue where there was a project called Open Tracing, and an effort called Open Census, which is basically trying to standardize how you're going to deal with metrics, on the tree and so on in a cloud native world that we're essentially competing with each other. The CNCF TC and committee came together and merged those projects into one parent ever called Open Elementary and so that to me is a case study of how our committee helps, bridges things. But we don't force things, we essentially want our community of end users and vendors to decide which technology is best in the long term, and we'll support that. >> Okay, awesome. And, Michelle, you've been focused on making distributed systems digestible, which to me is about simplifying things. And so back when Docker arrived on the scene, some people referred to it as developer dopamine, which I love that term, because it's simplified a bunch of crufty stuff for developers and actually helped them focus on doing their job, writing code, delivering code, what's happening in the community to help developers wire together multi-part modern apps in a way that's elegant, digestible, feels like a dopamine rush? >> Yeah, one of the goals of the(mumbles) project was to make it easier to deploy an application on Kubernetes so that you could see what the finished product looks like. And then dig into all of the things that that application is composed of, all the resources. So we're really passionate about this kind of stuff for a while now. And I love seeing projects that come into the space that have this same goal and just iterate and make things easier. I think we have a ways to go still, I think a lot of the iOS developers and JS developers I get to talk to don't really care that much about Kubernetes. They just want to, like Kelsey said, just focus on their code. So one of the projects that I really like working with is Tilt gives you this dashboard in your CLI, aggregates all your logs from your applications, And it kind of watches your application changes, and reconfigures those changes in Kubernetes so you can see what's going on, it'll catch errors, anything with a dashboard I love these days. So Yali is like a metrics dashboard that's integrated with STL, a service graph of your service mesh, and lets you see the metrics running there. I love that, I love that dashboard so much. Linkerd has some really good service graph images, too. So anything that helps me as an end user, which I'm not technically an end user, but me as a person who's just trying to get stuff up and running and working, see the state of the world easily and digest them has been really exciting to see. And I'm seeing more and more dashboards come to light and I'm very excited about that. >> Yeah, as part of the DockerCon just as a person who will be attending some of the sessions, I'm really looking forward to see where DockerCompose is going, I know they opened up the spec to broader input. I think your point, the good one, is there's a bit more work to really embrace the wealth of application artifacts that compose a larger application. So there's definitely work the broader community needs to lean in on, I think. >> I'm glad you brought that up, actually. Compose is something that I should have mentioned and I'm glad you bring that up. I want to see programming language libraries, integrate with the Compose spec. I really want to see what happens with that I think is great that they open that up and made that a spec because obviously people really like using Compose. >> Excellent. So Kelsey, I'd be remiss if I didn't touch on your January post on changelog entitled, "Monoliths are the Future." Your post actually really resonated with me. My son works for a software company in Austin, Texas. So your hometown there, Chris. >> Yeah. >> Shout out to Will and the chorus team. His development work focuses on adding modern features via micro services as extensions to the core monolith that the company was founded on. So just share some thoughts on monoliths, micro services. And also, what's deliverance dopamine from your perspective more broadly, but people usually phrase as monoliths versus micro services, but I get the sense you don't believe it's either or. >> Yeah, I think most companies from the pragmatic so one of their argument is one of pragmatism. Most companies have trouble designing any app, monolith, deployable or microservices architecture. And then these things evolve over time. Unless you're really careful, it's really hard to know how to slice these things. So taking an idea or a problem and just knowing how to perfectly compartmentalize it into individual deployable component, that's hard for even the best people to do. And double down knowing the actual solution to the particular problem. A lot of problems people are solving they're solving for the first time. It's really interesting, our industry in general, a lot of people who work in it have never solved the particular problem that they're trying to solve for the first time. So that's interesting. The other part there is that most of these tools that are here to help are really only at the infrastructure layer. We're talking freeways and bridges and toll bridges, but there's nothing that happens in the actual developer space right there in memory. So the libraries that interface to the structure logging, the libraries that deal with rate limiting, the libraries that deal with authorization, can this person make this query with this user ID? A lot of those things are still left for developers to figure out on their own. So while we have things like the brunettes and fluid D, we have all of these tools to deploy apps into those target, most developers still have the problem of everything you do above that line. And to be honest, the majority of the complexity has to be resolved right there in the app. That's the thing that's taking requests directly from the user. And this is where maybe as an industry, we're over-correcting. So we had, you said you come from the JBoss world, I started a lot of my Cisco administration, there's where we focus a little bit more on the actual application needs, maybe from a router that as well. But now what we're seeing is things like Spring Boot, start to offer a little bit more integration points in the application space itself. So I think the biggest parts that are missing now are what are the frameworks people will use for authorization? So you have projects like OPA, Open Policy Agent for those that are new to that, it gives you this very low level framework, but you still have to understand the concepts around, what does it mean to allow someone to do something and one missed configuration, all your security goes out of the window. So I think for most developers this is where the next set of challenges lie, if not actually the original challenge. So for some people, they were able to solve most of these problems with virtualization, run some scripts, virtualize everything and be fine. And monoliths were okay for that. For some reason, we've thrown pragmatism out of the window and some people are saying the only way to solve these problems is by breaking the app into 1000 pieces. Forget the fact that you had trouble managing one piece, you're going to somehow find the ability to manage 1000 pieces with these tools underneath but still not solving the actual developer problems. So this is where you've seen it already with a couple of popular blog posts from other companies. They cut too deep. They're going from 2000, 3000 microservices back to maybe 100 or 200. So to my world, it's going to be not just one monolith, but end up maybe having 10 or 20 monoliths that maybe reflect the organization that you have versus the architectural pattern that you're at. >> I view it as like a constellation of stars and planets, et cetera. Where you you might have a star that has a variety of, which is a monolith, and you have a variety of sort of planetary microservices that float around it. But that's reality, that's the reality of modern applications, particularly if you're not starting from a clean slate. I mean your points, a good one is, in many respects, I think the infrastructure is code movement has helped automate a bit of the deployment of the platform. I've been personally focused on app development JBoss as well as springsSource. The Spring team I know that tech pretty well over the years 'cause I was involved with that. So I find that James Governor's discussion of progressive delivery really resonates with me, as a developer, not so much as an infrastructure Deployer. So continuous delivery is more of infrastructure notice notion, progressive delivery, feature flags, those types of things, or app level, concepts, minimizing the blast radius of your, the new features you're deploying, that type of stuff, I think begins to speak to the pain of application delivery. So I'll guess I'll put this up. Michelle, I might aim it to you, and then we'll go around the horn, what are your thoughts on the progressive delivery area? How could that potentially begin to impact cloud native over 2020? I'm looking for some rallying cries that move up the stack and give a set of best practices, if you will. And I think James Governor of RedMonk opened on something that's pretty important. >> Yeah, I think it's all about automating all that stuff that you don't really know about. Like Flagger is an awesome progressive delivery tool, you can just deploy something, and people have been asking for so many years, ever since I've been in this space, it's like, "How do I do AB deployment?" "How do I do Canary?" "How do I execute these different deployment strategies?" And Flagger is a really good example, for example, it's a really good way to execute these deployment strategies but then, make sure that everything's happening correctly via observing metrics, rollback if you need to, so you don't just throw your whole system. I think it solves the problem and allows you to take risks but also keeps you safe in that you can be confident as you roll out your changes that it all works, it's metrics driven. So I'm just really looking forward to seeing more tools like that. And dashboards, enable that kind of functionality. >> Chris, what are your thoughts in that progressive delivery area? >> I mean, CNCF alone has a lot of projects in that space, things like Argo that are tackling it. But I want to go back a little bit to your point around developer dopamine, as someone that probably spent about a decade of his career focused on developer tooling and in fact, if you remember the Eclipse IDE and that whole integrated experience, I was blown away recently by a demo from GitHub. They have something called code spaces, which a long time ago, I was trying to build development environments that essentially if you were an engineer that joined a team recently, you could basically get an environment quickly start it with everything configured, source code checked out, environment properly set up. And that was a very hard problem. This was like before container days and so on and to see something like code spaces where you'd go to a repo or project, open it up, behind the scenes they have a container that is set up for the environment that you need to build and just have a VS code ID integrated experience, to me is completely magical. It hits like developer dopamine immediately for me, 'cause a lot of problems when you're going to work with a project attribute, that whole initial bootstrap of, "Oh you need to make sure you have this library, this install," it's so incredibly painful on top of just setting up your developer environment. So as we continue to move up the stack, I think you're going to see an incredible amount of improvements around the developer tooling and developer experience that people have powered by a lot of this cloud native technology behind the scenes that people may not know about. >> Yeah, 'cause I've been talking with the team over at Docker, the work they're doing with that desktop, enable the aim local environment, make sure it matches as closely as possible as your deployed environments that you might be targeting. These are some of the pains, that I see. It's hard for developers to get bootstrapped up, it might take him a day or two to actually just set up their local laptop and development environment, and particularly if they change teams. So that complexity really corralling that down and not necessarily being overly prescriptive as to what tool you use. So if you're visual code, great, it should feel integrated into that environment, use a different environment or if you feel more comfortable at the command line, you should be able to opt into that. That's some of the stuff I get excited to potentially see over 2020 as things progress up the stack, as you said. So, Michelle, just from an innovation train perspective, and we've covered a little bit, what's the best way for people to get started? I think Kelsey covered a little bit of that, being very pragmatic, but all this innovation is pretty intimidating, you can get mowed over by the train, so to speak. So what's your advice for how people get started, how they get involved, et cetera. >> Yeah, it really depends on what you're looking for and what you want to learn. So, if you're someone who's new to the space, honestly, check out the case studies on cncf.io, those are incredible. You might find environments that are similar to your organization's environments, and read about what worked for them, how they set things up, any hiccups they crossed. It'll give you a broad overview of the challenges that people are trying to solve with the technology in this space. And you can use that drill into the areas that you want to learn more about, just depending on where you're coming from. I find myself watching old KubeCon talks on the cloud native computing foundations YouTube channel, so they have like playlists for all of the conferences and the special interest groups in CNCF. And I really enjoy talking, I really enjoy watching excuse me, older talks, just because they explain why things were done, the way they were done, and that helps me build the tools I built. And if you're looking to get involved, if you're building projects or tools or specs and want to contribute, we have special interest groups in the CNCF. So you can find that in the CNCF Technical Oversight Committee, TOC GitHub repo. And so for that, if you want to get involved there, choose a vertical. Do you want to learn about observability? Do you want to drill into networking? Do you care about how to deliver your app? So we have a cig called app delivery, there's a cig for each major vertical, and you can go there to see what is happening on the edge. Really, these are conversations about, okay, what's working, what's not working and what are the next changes we want to see in the next months. So if you want that kind of granularity and discussion on what's happening like that, then definitely join those those meetings. Check out those meeting notes and recordings. >> Gotcha. So on Kelsey, as you look at 2020 and beyond, I know, you've been really involved in some of the earlier emerging tech spaces, what gets you excited when you look forward? What gets your own level of dopamine up versus the broader community? What do you see coming that we should start thinking about now? >> I don't think any of the raw technology pieces get me super excited anymore. Like, I've seen the circle of around three or four times, in five years, there's going to be a new thing, there might be a new foundation, there'll be a new set of conferences, and we'll all rally up and probably do this again. So what's interesting now is what people are actually using the technology for. Some people are launching new things that maybe weren't possible because infrastructure costs were too high. People able to jump into new business segments. You start to see these channels on YouTube where everyone can buy a mic and a B app and have their own podcasts and be broadcast to the globe, just for a few bucks, if not for free. Those revolutionary things are the big deal and they're hard to come by. So I think we've done a good job democratizing these ideas, distributed systems, one company got really good at packaging applications to share with each other, I think that's great, and never going to reset again. And now what's going to be interesting is, what will people build with this stuff? If we end up building the same things we were building before, and then we're talking about another digital transformation 10 years from now because it's going to be funny but Kubernetes will be the new legacy. It's going to be the things that, "Oh, man, I got stuck in this Kubernetes thing," and there'll be some governor on TV, looking for old school Kubernetes engineers to migrate them to some new thing, that's going to happen. You got to know that. So at some point merry go round will stop. And we're going to be focused on what you do with this. So the internet is there, most people have no idea of the complexities of underwater sea cables. It's beyond one or two people, or even one or two companies to comprehend. You're at the point now, where most people that jump on the internet are talking about what you do with the internet. You can have Netflix, you can do meetings like this one, it's about what you do with it. So that's going to be interesting. And we're just not there yet with tech, tech is so, infrastructure stuff. We're so in the weeds, that most people almost burn out what's just getting to the point where you can start to look at what you do with this stuff. So that's what I keep in my eye on, is when do we get to the point when people just ship things and build things? And I think the closest I've seen so far is in the mobile space. If you're iOS developer, Android developer, you use the SDK that they gave you, every year there's some new device that enables some new things speech to text, VR, AR and you import an STK, and it just worked. And you can put it in one place and 100 million people can download it at the same time with no DevOps team, that's amazing. When can we do that for server side applications? That's going to be something I'm going to find really innovative. >> Excellent. Yeah, I mean, I could definitely relate. I was Hortonworks in 2011, so, Hadoop, in many respects, was sort of the precursor to the Kubernetes area, in that it was, as I like to refer to, it was a bunch of animals in the zoo, wasn't just the yellow elephant. And when things mature beyond it's basically talking about what kind of analytics are driving, what type of machine learning algorithms and applications are they delivering? You know that's when things tip over into a real solution space. So I definitely see that. I think the other cool thing even just outside of the container and container space, is there's just such a wealth of data related services. And I think how those two worlds come together, you brought up the fact that, in many respects, server-less is great, it's stateless, but there's just a ton of stateful patterns out there that I think also need to be addressed as these richer applications to be from a data processing and actionable insights perspective. >> I also want to be clear on one thing. So some people confuse two things here, what Michelle said earlier about, for the first time, a whole group of people get to learn about distributed systems and things that were reserved to white papers, PhDs, CF site, this stuff is now super accessible. You go to the CNCF site, all the things that you read about or we used to read about, you can actually download, see how it's implemented and actually change how it work. That is something we should never say is a waste of time. Learning is always good because someone has to build these type of systems and whether they sell it under the guise of server-less or not, this will always be important. Now the other side of this is, that there are people who are not looking to learn that stuff, the majority of the world isn't looking. And in parallel, we should also make this accessible, which should enable people that don't need to learn all of that before they can be productive. So that's two sides of the argument that can be true at the same time, a lot of people get caught up. And everything should just be server-less and everyone learning about distributed systems, and contributing and collaborating is wasting time. We can't have a world where there's only one or two companies providing all infrastructure for everyone else, and then it's a black box. We don't need that. So we need to do both of these things in parallel so I just want to make sure I'm clear that it's not one of these or the other. >> Yeah, makes sense, makes sense. So we'll just hit the final topic. Chris, I think I'll ask you to help close this out. COVID-19 clearly has changed how people work and collaborate. I figured we'd end on how do you see, so DockerCon is going to virtual events, inherently the Open Source community is distributed and is used to not face to face collaboration. But there's a lot of value that comes together by assembling a tent where people can meet, what's the best way? How do you see things playing out? What's the best way for this to evolve in the face of the new normal? >> I think in the short term, you're definitely going to see a lot of virtual events cropping up all over the place. Different themes, verticals, I've already attended a handful of virtual events the last few weeks from Red Hat summit to Open Compute summit to Cloud Native summit, you'll see more and more of these. I think, in the long term, once the world either get past COVID or there's a vaccine or something, I think the innate nature for people to want to get together and meet face to face and deal with all the serendipitous activities you would see in a conference will come back, but I think virtual events will augment these things in the short term. One benefit we've seen, like you mentioned before, DockerCon, can have 50,000 people at it. I don't remember what the last physical DockerCon had but that's definitely an order of magnitude more. So being able to do these virtual events to augment potential of physical events in the future so you can build a more inclusive community so people who cannot travel to your event or weren't lucky enough to win a scholarship could still somehow interact during the course of event to me is awesome and I hope something that we take away when we start all doing these virtual events when we get back to physical events, we find a way to ensure that these things are inclusive for everyone and not just folks that can physically make it there. So those are my thoughts on on the topic. And I wish you the best of luck planning of DockerCon and so on. So I'm excited to see how it turns out. 50,000 is a lot of people and that just terrifies me from a cloud native coupon point of view, because we'll probably be somewhere. >> Yeah, get ready. Excellent, all right. So that is a wrap on the DockerCon 2020 Open Source Power Panel. I think we covered a ton of ground. I'd like to thank Chris, Kelsey and Michelle, for sharing their perspectives on this continuing wave of Docker and cloud native innovation. I'd like to thank the DockerCon attendees for tuning in. And I hope everybody enjoys the rest of the conference. (upbeat music)

>> Live from Barcelona, Spain it's theCUBE. Covering KubeCon + CloudNativeCon Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation and ecosystem partners. >> Welcome back to theCUBE here in Barcelona, Spain at the Fira, it's KubeCon + CloudNativeCon 2019. I'm Stu Miniman and my co-hosts for two days of live wall-to-wall coverage is Corey Quinn. Joining us back, we have two CUBE alums, Liz Rice, right to my right here who is a Technology Evangelist with Aqua security. Liz, thank you so much welcome back. >> Pleasure to be here. >> And Jeff Brewer, Vice President and Chief Architect, Small Business & Self-Employed Group, of Intuit. A CUBE alum since a few hours ago this morning. >> Yes, yes, thank you. >> Jeff, welcome back. >> Thank you. >> So, we've got you back with a different hat. Everybody in our industry can definitely recognize we wear lots of different hats we have lots of jobs thrown at us. Both of you are in the Technical Oversight Committee and Liz is not only a member but also the Chairperson, President. (people laughing) >> President is definitely a promotion. But, yeah, I'm Chair of the committee. >> Maybe, as it's known, the TOC. Liz, before we get there, your shirt says +1 binding. You have to explain for us and did not get a preview before the interview, so we'll see where this goes. >> It's one of the perks of being on the TOC. When we have something that comes to a vote we want to get input from the community so we ask anyone in the community to vote. But unless you're a member of the TOC your vote is non-binding. As a member of the committee, we have binding votes. And the traditional thing you write on the voting email is +1 binding. So, it's a nice surprise to get a t-shirt when I joined the TOC. >> Very nice. Can you just give us, our audience, that might not be familiar with the TOC, give us some of the key things about it. >> It's the Technical Oversight Committee for the CNCF. We are, really, the technical curation of the projects that come in to the CNCF. Which projects will get support and at what level because we have the sandbox experimentation stage then incubation and then finally graduation for the really established and kind of, de-risked projects. So, we're really evaluating the projects and kind of making a decision collaboratively on which ones we want the CNCF to support. >> All right. So Jeff, we had a great conversation with you about Intuit's cloud journey. Tell us how you got involved in the TOC. We always love the end users, not just using but participating in and helping to give some governance over what the community is doing. >> Yeah, so, about a year and a half ago we made a decision to acquire a small company called Applatix. Who was, actually, already in the end user community. And also contributors as well. Through that acquisition, I was part of that acquisition, I led that acquisition from the Intuit side and really got excited about the Kubernetes and the KubeCon story overall. Through the Kubernetes experts, I met them at a KubeCon and they introduced me to a whole lot more of the community. Just through some overall partnerships with AWS and also spending a lot of time with end-users that's how I really got to know the community a little bit. And then, was voted onto the CNCF as an end user representative in January. >> Wonderful. As far as you're concerned, as you go through this, do you find it challenging at times to separate your roles professionally from working for a large company, to whom many things matter incredibly. Again, as mentioned earlier, I am one of your customers. I care very much about technical excellence, coming out of Intuit, versus your involvement with the larger project. >> Yeah, so like most people in technology companies I'm extremely busy and I would love to spend, I would love to clone myself and spend more (laughing) more time. >> Everybody wants to submit a client project to the TOC we will prioritize that one. >> Exactly, exactly. >> The way I really balance it is that I make an explicit time carve out for those two activities. And most importantly, I attend the meetings. The TOC meetings that we have, those are extremely important. We get a lot of project reviews in those meetings. Liz chairs those meetings. That's where I always make sure that my schedule is cleared for that. >> Taking it, I guess, one step further. Do you find it challenging at all to separate out, in fact, when you're making decisions and making votes, for example, that are presumably binding, +1 binding as we've learned now, is the terminology. Do you find that you are often pulled between trying to advocate for your company and advocating for the community or are they invariably aligned in your mind? >> I mean, my job's the easiest because I come from an end user. So what I use and what I consume is likely what the community at large. There might be some niches and stuff like that. But I usually don't have that conflict. I don't know, as more of a vendor, you might have more of a conflict. >> It's something that I have be conscious of. I just try to mentally separate. I have a role with a company that pays my salary but when I'm doing open-source things if I feel conflicted about. This hasn't really come up yet, but if I do feel that there's some kind of conflict of interest I will always recuse myself. Actually, in my previous role, as the Co-Chair for the Program Committee for the KubeCon and CloudNativeCon Conference, on a couple of occasions we had competitors submit, and I would always just step back from those. Because it's the right thing to do. >> All right. So Liz, there's quite a few projects now, under the umbrella of CNCF. If I've go it right, it was like, 38 different ones. When Brian went on the stage this morning, 16 in the sandbox, 16 incubating and six have graduated now. How do you manage that? You know, there's some in the community they're like, oh my gosh, reminds us of like, big tent, from some initiatives. Some other things here, how much is too much? How do you balance that and what's the input of the TOC? >> Yeah, so one of the things that we're doing with the TOC is we've just established a thing called the SIGs, the special interest groups. Very much following the same model of Kubernetes SIGs. But the idea here is that we can, kind of formalize getting experts in the community to help us with particular kind of areas. So, we've already got a storage and security SIG set up. We expect there will be probably four to six more coming on board during the year. And that helps us with things like the project reviews and the due diligence to just be able to say, we would really appreciate some help. Those groups are also really enthusiastic about kind of sharing knowledge in the form of things like white papers. I think it will be really important for end-users to be able to navigate their way around these projects. Quite often there is more than one solution for a particular thing. And being able to, in a non-vendor way, in a neutral way, express why project X is good in one circumstance and project Y would be better in a different environment. There's work to be done there and I'm hoping to see that come out. >> This is one of my passions as the end user representative, is that trail map or that road map. That's one of the reasons why we really have invested at Intuit, in the Kubernetes technology and the Cloud Native technology. We didn't just roll them out as is. We actually curate them and create, really, a paved road for our developers to navigate that space. >> Yeah, and as we heard from your story it's not always, well, if there's some overlap you use SDO and Hellman. >> Yeah. >> That there's a fit for both of those in your environment, right. >> Yeah. >> From a, I guess, an end user perspective is there a waiting difference between someone like Intuit and someone like Twitter for pets, where there's a slight revenue scale, a slight revenue difference, like scale difference, like everything difference. >> Yes. >> Certainly, there is. I think that, but that's one of the beautiful things about the Cloud Native technologies. You can consume what you need and what you want, right. It's not one size fits all. A lot of people talk about, oh, there's a paradox of choice, there's so many projects, right. Actually, that's a benefit. Really, all you need is that road map to navigate your way through that, rather than just adopting a paved road that might not work for everybody. >> It almost feels, to some extent, almost like the AWS Service Catalog. Whenever you wind up looking at all the things they offer. It feels like going out to eat at the Cheesecake Factory. Where there is 80 pages of menu to flip through with some advertisements, great. And reminding yourself, at time, that they are not Pokemon, you do not need to catch them all. It's, sometimes, a necessary step, as you start to contextualize this. >> That's one of the great things about having over 80 members in the end user is. You can find a buddy, you can find a company like you. Talk to them, get connected with them and figure out what they're doing and learn from them. The community is broad enough to be able to do that. >> All right, so Liz, let's talk about security. >> Okay. (people laughing) >> You said there's a SIG that started up. Where are we, how are things going and you can you share about where we're going in the near future? >> The SIG came together from a group of people who really wanted to make it easier for end-users to roll out their Cloud Native stacks in a secure fashion. We don't always, as a community, speak the same language about security, we don't always have the most secure settings by default. They really came together around this common interest of just making it easier for people to secure. I think a big part of that will be looking at how the different projects, are they applying best practices from a security perspective? Is there more they should do to document how to operate their particular project more securely? I think that whole initiative and that group of people who've come together for SIG security, I'm so impressed and so pleased that they have come together with that enthusiasm to help on that front. >> Any commentary on what you're seeing in this space? >> Yeah, so as an almost, a fintech company, with a lot of fintech and, you know, we're not quite a bank, but we have a lot of the same security and compliance things. That SIG is so, so important to us. And having a roadmap. I found a education is really, really a big part of it of the security experts, right. Because this is somewhat newer technology. Even though it's been in use at Google for a long time the regulator's, the compliance people, don't totally understand it, right. So you have to have a way to explain to them what's going on. So things like, open policy agent, something that we've adopted, helps us explain what's going on in our system. Once they get it, they're like, this is awesome and our end users can now, really, our end users, meaning the people that use QuickBooks and TurboTax can really trust that we have those guardrails in place. >> At Aqua, it's a huge concern from a lot of our customers. Many of whom, coming from that kind of finance industry. That they're coming to us and saying, well, how can I be PCI compliant or GDPR. How do I manage these requirements with my container based stack, with my Cloud Native stack. That's why there is this huge ecosystem quite a lot of effort around security, compliance, policy. >> It feels very much like it's two problems rolled into one. First, how do you make sure that data is secure in these things? Secondly, how do you effectively and responsibly communicate that to a regulator, who expects to be taken on a tour of a data center when they show up on site? (people laughing) I checked, they won't let you. >> There are definitely two sets of security people in my experience. There are a set of people who care about how will I get attacked. How will breaches happen. And there are other people who go, I have a checklist and I need to check the boxes in the checklist, tell me how. Sometimes those two things overlap, but not always. >> All right, Liz, lot of updates, as always. Jeff, I really appreciate your commentary there. Well, there's the paradox of choice but we have a lot of customers out there and therefore we do. (people chuckling) Any highlights you want to share with our audience? >> I think one thing that happens every year is we see more. Well, we saw Kubernetes graduate, I think, early last year, end of the previous year. Now we've got six projects into graduation. From my perspective, that says something about how mature this whole set of projects, this whole platform is becoming. Because graduation is a pretty high bar. Not least in terms of the number of end users that have to be using it in production. This is solid technology. >> Yeah, any highlights from you? >> I think, like we might have touched on a little bit this morning. But I think that usually the technologies that where you're facing the big problems is pretty obvious which one to use, right. Like serverless, you're going to go look at something like Knative or whatnot. Functions as a service. There's some open fast projects, whatnot, like that. SDO services mesh is another one where it's getting mature and it's getting to the point where you can have these ubiquitous service meshes throughout it. So, those are the areas that we're most looking at right now. >> Great, all right. Well, Liz and Jeff, thank you so much for joining us. Thanks for all the work you do on the Oversight Committee and appreciate you sharing the updates with our community. >> Thank you for having us. >> Thank you. >> For Cory Quinn, I'm Stu Miniman. We'll be back more, with theCUBE here at KubeCon + CloudNativeCon 2019. Thanks for watching. (upbeat music)

>> Live from Barcelona, Spain, it's theCUBE, covering KubeCon CloudNativeCon Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation, and ecosystem partners. >> Hi and welcome back, I'm Stu Miniman with my co-host Corey Quinn, and you're watching theCUBE, the worldwide leader in live tech coverage of KubeCon CloudNativeCon 2019. Happy to welcome to the program a first-time guest, Jeff Brewer, who's the Vice President and Chief Architect of Small Business and Self-Employed Group at Intuit. He's going to talk about your cloud journey. Jeff, thanks so much for joining us. >> You're welcome, I'm glad to be here. >> All right, so, Jeff, the easy part of this is, I think, most of our audience has probably heard of Intuit, but maybe give us that first setting of, you know, the part of the group you're in, and your role, and then we want to get into that journey. >> Yeah, yeah, no, it's great. So, yeah, first of all, thanks for having me here and I'm what's called the Chief Architect of the Small Business and Self-Employed Group. Intuit is about powering prosperity around the world. That's our fairly new mission. And helping both taxpayers with TurboTax and QuickBooks is our other big project. So, think of me as the Chief Architect for the QuickBooks group. And so, mostly for small businesses, helping small businesses survive through their first year, survive and prosper continuing on, so. >> And your charter there, is that the infrastructure there, you're not trying to help the world rid those malicious attacks of like, oh no, I got the new TurboTax and it didn't work well because, disclaimer, you know, I'm not paid, I've used it for many years and it's super easy for me. >> Yeah so, as a Chief Architect, I set the technical direction of the overall QuickBooks franchise both the desktop version which is our older version that, you know, has been around for 20, 25 years, and our QuickBooks Online version, which is about, only about 15 years old and is our SAS offering. And so, I do things like choose technologies that we adopt. I do things like set what are the most important technology priorities whether it's breaking things up into microservices, our cloud strategy, Kubernetes, going to cloud native, all that kind of stuff. >> Okay, so, you are a member of the Technical Oversight Committee, but we're actually going to bring you back a little bit later to talk about that, so, we'll put a pin in that. But give us a little bit as to kind of what led to this journey towards cloud and, you know, all of those pieces that you were just talking about. >> Yes, so, like many other companies with, you know, lots of legacy and lots of code that we've developed over about 35 years of existence, we actually started out in the early 2000's with building our own data centers, right. And it's very expensive, very ambitious, but at the time, there really wasn't a public cloud. But we realized that, you know, putting servers under our desks and stuff like that, you know, we really needed to grow to a more robust data center. And, you know, as we progressed in that journey, we figured out we're not the experts at maintaining and developing all the complicated networking you have to do, reliability, resiliency. We had some outages, this is 10 years ago or so, where a truck drove into a light post outside one of our data centers and took us down for a day. And that's just not acceptable for our customers. The public cloud was just starting out, AWS was a big partner out there, and our CIO, and CEO, met with the AWS executives and really decided that we needed a great partner in public cloud that really was their technical expertise. And so, we began this journey, mostly I would describe it as lift and shift, of technologies and services that we already had. We had to rewrite a few of them to make them actually work with the cloud. But by and large, most of our code is written in Java and that ports pretty well. So, we started on that journey and really right now, we are mostly running in the public cloud. We have a few legacy systems that are still running in our private data centers, but we're planning on decommissioning those. And with the public cloud, a journey we really have seen quite a, improvement in our reliability, our downtime, we can fail over between availability zones, it's just been fantastic from our overall availability, recoverability standpoint. But what we realized during that journey was that the, that the AWS native experience for our developers, while AWS is just an amazing, amazing partner, it wasn't quite the developer experience we wanted. >> It had some sharp edges. >> Yeah, we worked with them on that, and that's why we started looking at cloud-native technologies, things already developed by the community. AWS is part of the community, as well, and so they were extremely supportive in our journey to want to, from the developer experience standpoint, really start to press on these cloud-native technologies. >> Wonderful. As you went down that entire path, whenever a company goes public and they put in their S1 that they're doing some committed level of giant deal with AWS, people immediately chime in with, oh, they could save so much money by building and running their own data centers. How do you stand on that particular perspective? >> So, what's really interesting about our, our public cloud journey, right, it's not necessarily about saving a lot of money, right? And we realized that, you know, Intuit, as a mature company, you know, we're not a start-up looking to shave every little penny off of every little server. What we really want is reliability for our customers, we want awesome operations, and so, the public cloud journey actually hasn't been a huge, huge cost savings, but it has been a huge improvement in all these other levels, so it does amazing things for our customers. And we're looking to cloud native as just another, you know, bump up in that overall thing, where we get immediate mean time to recovery, where things go down, things go wrong, and we get those pods and those services right back up and running. >> Can you elaborate a little bit about the application that you're talking about, like when I first heard you say, you know, we just lifted and shifted there, it's like, oh wait, you know, a lot of times that is when we kind of claw things back because it's costs more than I thought or it didn't run as well as I thought. >> It turns out the mainframe's hard to move because they didn't build an AWS 400 yet, something doesn't happen. >> So, the challenges there, and then, you know, connect the dots with that to what you're calling the cloud native piece of this, as to what your application development looks like. >> So, I'll use QuickBooks Online as an example. Massive property, over four million customers. >> I'm one of them. >> And it started out as a, as kind of our first really big foray into SAS, right? And luckily, at the time we wrote it, mostly in Java. But it was written as this huge, monolithic piece of code, right. And so, millions of lines of code, you can imagine, large memory footprints, all that kind of stuff. And so, during our first, for public cloud, we just looked at, well, we're not going to rewrite these millions and millions of lines of code, but we want to get into public cloud. Lucky for us, EC2 instances, things like that, can run those large memory footprints. But once there, we really started examining, okay, what does this look like as microservices? Because when you have over 400 engineers working on a single code base, imagine what doing a release, a release is a ceremony, right? It's like this huge thing, you have-- >> It takes a many page calendar in order to do those things. >> Exactly, and so, what we really wanted to do is press into the microservices journey and say, okay, what if instead of having this huge oil tanker, you know, driving down the, you know, sailing down the ocean, what if we could be a bunch of speedboats, right, and use that analogy. And that's where cloud native comes in, because that's really what it's meant to do, right? A bunch of independent teams doing dev ops, you build it, you run it, right? You write the code, you run the code. And so, it plays right into to this, this ability to be very agile, give each team, you can imagine at a scale of 4000 engineers, you want little pizza team, you know, to be independent and do their own releases, and not have to coordinate all with each other. >> So, Jeff, which of the, you know, CNTF pieces are you using at Intuit, and I would like you to go in a little bit, you know, Kubernetes, a lot of people, it's like, oh well, I want portability, and it sounds like you're all in, primarily, on one public cloud, so that's probably not the first thing on your list, so, help us understand the landscape from your eyes. >> So, really it's about, it's about developer productivity. So yes, we do have this very good, strong partnership with AWS, and that is our public cloud provider. And so, the cloud-native technology, using, obviously, Kubernetes, obviously, you know, we're running Docker in the background for running the containers and all that infrastructure. We have our own open source called Argo, which we're using for deployments in the community, so we're contributing a little bit back to community, as well. We're using Istio and Envoy as a service match to really secure the interservice communications and support all the routing and whatnot. And we're also leaning very heavily now into serverless technologies, and so, we write our app, QBO or QuickBooks Online, as a stateful application, but we're realizing the power of having these really stateless small functions, and so we want to do that, as well. And the way we look at it as, Lambda is a fantastic technology for something like that, but the developer experience, we want the same developer experience for our containers that we do from our functions, right? And if you really think about it, it's just about deploying, it's how you deploy. Do I deploy into containers and then a pod structure, like in Kubernetes? Or do I deploy to a functions as a service? It should run on the infrastructure, and so, from a developer standpoint, from the end developer that's actually developing the applications and services that our customers are using, we want the declarative infrastructure of Kubernetes, we want the ease of deployment and of operations. You can just imagine a development team not having to learn the huge depth that's behind that Kubernetes, that developer experience is just unbelievable and second to none. And you can imagine these teams sitting around, you know, at lunch time, doing their release, something goes wrong, they're on the call, they're solving the problems for their customers, in fact, doing another release, if there's any problems. And so, that's where we really, really lean in heavily to these cloud technologies, the cloud-native technologies, so we can get even faster at the developers. >> Do you find that making it more accessible and having a consistent developer experience has, I guess, broadened the ability of your developers to iterate more rapidly, or is more about ensuring consistency across the board? In other words, is it a speed value for you or is it more about just consistency, so you can wind-up up-to-point to multiple architectures? >> It's really about both. We see, you know, agility is often confused with speed and velocity, but we see that enabling a developer to release code to production in just a few minutes is extremely, extremely powerful to the overall velocity because what they're more likely to do is they're more likely to experiment, be bold, try new things, and then get immediate feedback for the customer. There's this experimentation loop that you want it to move as fast as possible. And so, not only that, but to your second part about the consistency, for a company like Intuit with 4000 developers, you want mobility in your organizations, and so, you want someone to feel very natural going from one small pizza team to another, and have the same tools, the same deployment architecture, and the same thing, right? So, you're not retraining them on a ton of different technologies. >> Alright, so, Jeff, you know, what could the ecosystem, you know, the partners you're working with, the various ecosystem, what could they do to make your life easier? I mean, the one that comes to mind for me is, you know, today, serverless, you know, Lambda, specifically, and Kubernetes. There are some ways to get them, you know, work at little bit, but, you know, is that top of your mind or are there other things? >> That is actually really top of my mind. We have a lot of teams experimenting with Lambda. We're running huge workloads in Lambda, but we're very much worried about this. If there's teams working on that and it's very, it's very fragmented. Some teams are deploying Lambdas off their laptops, other teams are, you know, using CICD processes. And so, we want that experience to be consistent, secure and everything. And so, as it moves to more production workloads, right, we would really like the Kubernetes and the CNCF Foundation to really have a story about serverless itself. I think it's probably more aptly called functions as a service or running functions. And I think a lot of thing happens is that it's treated as a versus. It's like, oh, I'm going to skip over that containers to Kubernetes thing and go to serverless, because it's versus, right? It's not versus, it's a choice for the developer about what to I want to deploy in functions, in short-running functions, or do I want to deploy in containers? Everything else up to that point is the same. And so, I'd really like to see, and that, as my role on the Technical Oversight Committee, that's something I'm really focused on for the end users 'cause I see that a lot in the end user's communities. They're dealing with the same things that we are on that functions as a service. >> Alright, so, Jeff, before I let you go, Intuit's an award winner, so, congratulations on that. >> Thank you. >> I want final word from you. Talk a little bit about the award and two, talk your peers that might be, you know, they've heard about Kubernetes, but, you know, we're into the, we've crossed the chasm in the majority, but that means there's a lot of people that are still relatively early. What do you recommend to them, what tips would you give them, and start with the award though. >> Yeah, so, we're extremely honored to be the CNCF end user award winner. Our cloud journey has been a really interesting one that came really out of a, also, out of an acquisition that we did of some fantastic Kubernetes experts about 14 of them, a little company called Applatix that had this Argo project. And their mission was to make Kubernetes accessible to the overall community. And by acquiring them, we left their mission the same, but they're really helping Intuit, and we're not selling their, they're helping the community for free, when they were charging before as enterprise customers. And that's something I'd overall recommend for the peers and the companies thinking about going on a cloud native journey is it's about those people that you can find here at the conference, right, about those experts that you can hire, just a few of them, have them come into your company, explain these things, and it turns the entire company around. We now have hundreds and hundreds of teams going through and onboarding, we call it modern SAS, internally, onboarding onto this technology because they started out with that nugget or that kernel. >> Alright, well, Jeff, modern SAS, love the story, thank you so much and thanks for joining us and we will see you later to talk about the TOC. >> Glad to be here, thank you very much. >> Thank you very much. >> For Corey Quinn, I'm Stu Miniman, and that was Jeff Brewer from Intuit, we'll be back with lots more coverage and thank you for watching theCUBE. (dynamic digital music)

>> Live from Seattle, Washington, it's theCUBE covering KubeCon and CloudNativeCon, North America 2018, brought to you by Redhat, the Cloud Native Computing Foundation and it's ecosystem partners. >> Okay, welcome back, everyone, this is theCUBE's live coverage here in Seattle for KubeCon and CloudNativeCon 2018. I'm John Furrier with Stu Miniman breaking down all the action, talking to all the top people, influencers, executives, start-ups, vendors, the foundation itself. We're here with two co-leads of Kubernetes at Google, legends in the Kubernetes industry. Tim Hockin and Brian Grant, both with Google, both co-leads at GKE. Thanks for joining us, legends in the industry. Kubernetes is still a short life, but still, being there from the beginning, you guys were instrumental at Google building out and contributing to this massive tsunami of 8000 people here. Who would have thought? >> It's amazing! >> It's a little overwhelming. >> It's almost like you guys are celebrity-status here inside this crowd. How's that feel? >> It's a little weird. I don't buy into the celebrity culture for technologists. I don't think it works well. >> We agree, but it's great to have you on. Let's get down to it. Kubernetes, certainly the rise of Kubernetes has grown. It's now pretty mainstream, people look at that as a key linchpin for the center of Cloud Native. And we see the growth of Cloud, you guys are living it with Google. What is the importance of Kubernetes? Why is it so important? Fundamentally at it's core, has a lot of impact, what's the fundamental reason why it's so successful? >> I think fundamentally Kubernetes provides a framework for driving migration towards Cloud Native patterns across your entire operational infrastructure. The basic design of Kubernetes is pretty simple and can be applied to automating pretty much anything. We're seeing that here, there are at least more than half a dozen talks about how people are using the Kubernetes to control plane to manage their applications or workflows or functions or things other than just core Kubernetes, containers, for example. Cloud Native is about... One of the things I'm involved with is I'm on the Technical Oversight Committee of the Cloud Native Computing Foundation. I drove the update of the Cloud Native definition. If you're trying to operate with high velocity, deploying many times a day, if you're trying to operate at scale, especially with containers and functions, scale is increasing and compounding as people break their applications into more and more micro services. Kubernetes really provides the framework for managing that scale and for integrating other infrastructure that needs to accommodate that scale and that pace of change. >> I think Kubernetes speaks to the pain points that users are really having today. Everybody's a software company now, right? And they have to deploy their software, they have to build their software, they have to run their software, and these things, they build up pain. When it was just a little thing, you didn't have to worry about scale, internet-scale and web-scale, you could tolerate it within your organization. But more and more, you need to deploy faster, you need to automate things. You can't afford to have giant staffs of people who are running your applications. These things are all part of Kubernetes purvey. I think it just spoke to people in a way, they said I suffer from that every day and you just made it go away. >> And what's the core impact now? Because then now people are seeing it, what is the impact to the organizations that are rethinking their entire operation from all parts of the staff, from how they buy infrastructure, which is also Cloud, you see some Cloud there, and then that deploying applicant, what's the real impact? >> I think the most obvious, the most important part here is the way it changes how people operate and how they think about how they manage systems. It no longer becomes scary to update your application. It's just a thing you do. If you can do it with high confidence, you're going to do it more often, which means you get features and bugs fixed and you get your roll-outs done quicker. It's amazing, the result that it can have on the user experience. A user reports a bug in the morning, and you fix it in the afternoon, and you don't worry about that. >> You bring up some really interesting points. I think back 10 years ago, from a research standpoint, we were looking at how can the enterprise do some of the things that the hyperscale vendors were doing. I feel over the last 10 years, every time Google released one of the great scientific papers, we'd all get a peer inside and say like, oh hey. When I went to the first DockerCon and heard how Google was using containers, when Kubernetes first came out, it's like, oh wow, maybe the rest of us will get to do something that Google's been doing for the last 10 years. Maybe bring us back a little bit to Borg and how that led to Kubernetes. Are we still all the rest of us just doing whatever Google did 10 years ago? >> Yeah, Tim and I both worked on Borg previously, Tim on the node-agent side and I worked on the control-point side in Borg One lesson we really took from Borg is that really you can run all types of applications. People started with stateless applications and we started with that because it's simpler in Kubernetes. But really it's just a general management control plane for managing applications. With the model of one application per container, then you can manage the applications in a much more first-class way and unlock a lot of opportunities for automation in the management control plane. At Google, several years ago when we started, Google had already gone through the transition of moving most of its applications to Borg. It was after that phase that Google started its Cloud effort and the rest of the world was doing VMs. When Docker emerged, we were... In the early phases, Tim mentioned this in our keynote yesterday of open-sourcing our container runtime. When Docker emerged, it is clear it had a much better user experience for the way folks were managing applications outside of Google and we just pivoted to that immediately. >> When Docker first came out, we took a look at it, we, my node-agent team in Borg, and we went, yeah, it's kind of like poor man's version of Borglet. We sort of ignored it for awhile because we were already working on our open-source effort. We were open-sourcing it, not really to change the world and make everybody use it, but more so that we can have conversations with people like the Linux kernel community. When we said we need this feature, and they'd say well why, why do you need this, we could actually demonstrate for them why we needed it. When Docker landed, we saw the community building, and building, and building. That was a snowball of its own, right? As it caught on, we realized we know what this is going to. We know once you embrace the Docker mindset that you very quickly need something to manage all of your Docker nodes once you get beyond two or three of them. We know how to build that. We got a ton of experience here. We went to our leadership and said, please, this is going to happen with us or without us and I think the world would be better if we helped. >> I think that's an interesting point. You guys had to open-source to do collaboration with Linux to get that flywheel going for you guys out of necessity. Then when Docker validated the community acceptance of hey, we can just use containers, a lot of magic will happen, it hit the second trigger point. What happened after that? You guys just had a debate internally? Is this another MapReduce? What's happening? Like, we should get behind this. I knew there was a big argument or debate, I should say, within Google. At that time there were a lot of conversations, how do we handle this? >> That was around the time that Google Compute Engine, our infrastructures and service platform, was going GA and really starting to get usage. So then we had an opportunity to enable our customers to benefit from the kinds of techniques we had been using internally. So I don't think the debate was whether we should participate, it was more how. For example, should we have a fully managed product, should we have to do open-source, should we do managed open-source, so those were really the three alternatives that we were discussing. >> Well, congratulations, you guys done great work and certainly a huge impact to the industry. I think it's clear that the motivation to have some sort of standardization, de facto standard, whatever word can be used to kind of let people be enabled on top or below Kubernetes is great. I guess the next question is how do you guys envision this going forward as a core? If we're going to go to decomposition with low levels of granularity tying together through the network and cloud-scale and the new operating law, we'll have comments in this, how does the industry maintain the greatness of what Kubernetes is delivering and bring new things to market faster? What's your vision on this? >> I talked a little bit about this this week. We put a ton of work into extension points, extensibility of the system trying to stay very true to the original vision of Kubernetes. It is a box, and Kubernetes fits inside a box, and anything that's outside the box has to stay outside the box. This gives us the opportunity to build new ecosystems. You can see it in networking space, you can see it in storage space where whole sort of cottage industries are now springing up around doing networking for Kubernetes and doing storage for Kubernetes. And that's fantastic! You see projects like Istio, which I'm a big fan of, it's outside of Kubernetes. It works really well with Kubernetes, it's designed on top of Kubernetes infrastructure, but it's not Kubernetes. It's totally removable and you don't need it. There's systems like Knative which are taking the serverless idea and upleveling Kubernetes into serverless space. It's happening all over the place. We're trying to sort of pray fanatically, say, no, we're staying this big and no bigger. >> It's a really... From an engineering standpoint, it's much simpler if I just build a product and build everything into it. All those connection points, I go back to my engineering training. It's like every connection point is going to be another place where it could fail. Now it's got all these APIs, there's all the security issues, and things like that. But what I love what I heard right here is some of the learnings that we've had in open-source is these are all of these individual components that most of them can stand on their own. They don't even have to be with Kubernetes, but altogether you can build lots of different offerings. How do you balance that? How do you look at that from kind of a design and architecture standpoint? >> So one thing I've been looking at is how do we ensure compatibility of workloads across Kubernetes in all different environments and different configurations. How do we ensure that the tools and other systems building an ecosystem work with Kubernetes everywhere? So this is why we created the Conformance Program to certify that the critical APIs that everybody depends on behave the same way. As we try to improve the test coverage of the conformance, people are focusing on these areas of the system that are highly pluggable and extensible. So for example, the kubelet in the node has a pluggable container runtime, pluggable networks, pluggable storage systems now with CSI. So we're really focusing on ensuring we have good coverage of the Pod API, for example. And other parts of the system, people have swapped out an ecosystem, whether it's kube-proxy for our Kubernetes services or the scheduler. So we'll be working through those areas to make sure that they have really good coverage so users can deploy, say, a Helm Chart or their takes on a configuration or whatever, however they manage their applications and have that behave the same way on Kubernetes everywhere. >> I think you guys have done a great job of identifying this enabling concept. What is good enabling technology? Allowing others to do innovation around it. I think that's a nice positioning. What are the new problem areas that you guys see to work on next? Now I see things are developing in the ecosystem. You mentioned the Istio service mesh and people see value in that. Security is certainly a big conversation we've been having this week. What new problem areas or problem sets you guys see emerging that are needed to just tackle and just knock down right away? >> The most obvious, the thing that comes up sort of in every conversation of users now is multi-cluster, multi-cloud, hybrid, whether that's two clouds or on-prem plus cloud or even across different data centers on your premises. It's a hard topic. For a long time Kubernetes was able to sort of put a finger in our ears and pretend it didn't exist while we built out the Kubernetes model. Now we're at a place where we've crossed the adoption chasm. We're into the real adoption now. It's a real problem. It actually exists and we have to deal with it, and so we're now looking at how's it supposed to work. Philosophically, what do we think is supposed to happen here? Technologically, how do we make it happen? How do these pieces fit together? What primitives can we bring into Kubernetes to make these higher level systems possible? >> Would you consider 2019 to be the year of multi-cloud, in terms of the evolution of trying to tackle some of these things from latency? >> Yeah, I'm always reluctant to say the year of something because... >> Someone has to get killed, and someone dies, and someone's winning. >> It's the year of the last desktop. >> It's the year of something. (laughs) EDI, I'm just saying. >> I think multi-cluster is definitely the hot topic right now. It's certainly almost every customer that we talk to through Google and tons of community chatter about how to make this work. >> You've seen companies like NetApp and Cisco, for instance, and how they're been getting a tail-wind from the Kubernetes. It's been interesting. You need networks. They have a lot of networks. They can play a role in it. So it's interesting how it's designed to allow people to put their hands in there without kind of mucking up the main... >> Yeah, I think that really contributes to the success of Kubernetes, the more people that can help add value to Kubernetes, more people have a stake in the success of Kubernetes, both users and vendors, and developers, and contributors. We're all stakeholders in this endeavor now and we all share common goals, I think. >> Well guys, final question for you. I know we got to break on time. Thanks for coming. I really appreciate the time. Talk about an area of Kubernetes that most people should know about that might not know about. In other words, there was a lot of hype around Kubernetes, and it's warranted, it's a lot of buzz, what's an important area that's not talked about much that people should know more about it and pay attention to within the Kubernetes realms of that world? Is there any area that you think is not talked about enough that should be focused on in the conversations, the press, or just in general? >> Wow, that's a challenging question. I spent a lot of my time in the infrastructure side of Kubernetes, the lower end of the stack, so my brain immediately goes to networking and storage and all the lower level pieces there. I think there's a lot of policy knobs that Kubernetes has that not everybody's aware of, whether those are security policies or network policies. There's a whole family of these things and I think we're going to continue to acree more and more policy as more people come up with real-use cases for doing stuff. It's hard to keep that all in your mind, but it's really valuable stuff down there. >> For programmability, it's like a Holy Grail, really. Thoughts on the things that (chuckles) put you on the spot there? >> I think this question of how people should change what they were doing before if they're going to migrate to Kubernetes. To operate any workload, you need at least monitoring and you need really CI/CD if you want to operate with any amount of velocity. When you bring those practices to Kubernetes, should you just lift and shift those into Kubernetes or do you really need to change your mindset? I think Kubernetes really provides some capabilities that create opportunities for changing the way some things happen. I'm a big fan of GitOps, for example, in managing the resources to declaritively using version control as a source of truth and keeping that in sync with the state in your for live clusters. I think that enables a lot of interesting capabilities like instant disaster recovery, for example, migrations, new locations. There are some key folks here who are talking about that, giving that message, but we're really at the early stages there. >> All right, well great to have you guys on. Thanks for the insight. We've got to wrap up. Thanks Brian, thanks Tim, appreciate it. Live coverage here, theCUBE is at KubeCon, Cloud Native, Cloud 2018. I'm John Furrier with Stu Miniman, we'll be back after this short break.