>> Live from Barcelona, Spain, it's the Cube, covering KubeCon CloudNativeCon Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation, and Ecosystem Partners. >> Welcome back, this is theCube getting towards the end of two days live wall-to-wall coverage here at KubeCon, CloudNativeCon 2019 in Barcelona. I'm Stu Miniman, my co-host for this week has been Corey Quinn and happy to have on one of our hosts for this week from the Cloud Native Computing Foundation, Dee Kumar, the Vice President of Marketing, also helps with developer relations. Dee, welcome back to the program. >> Thanks for having me. >> And thank you for having us. We've been having a great time this week, a lot of buzz, a lot of people and obviously always a lot of enthusiasm at the show here. Thanks so much. Alright, so your team has been super busy. I've talked with a lot of them leading up to the show. >> That's right. >> Anybody that knows any show of this kind of magnitude know we're usually pretty exhausted before we get on planes and change all the time zones. So, you know, thank you for holding strong. Give us a little bit about, you know, when we talk marketing, you have a big annual report that came out recently from 2018. Give us some of the highlights of some of the things you've been seeing. >> Yeah, sure. Like you mentioned, you're seeing all the excitement and buzz here so this is our largest open-source developer conference, when compared to the last year we did in Copenhagen. So we have close to 8,000 attendees so we're really excited about that. And you're absolutely right, with that comes, we're so exhausted, but we really appreciate. I think the reason the conference has been so successful is primarily just because of the community engagement, which I highlight in the annual report. So it's a combination of our community, which is the developers, the contributors, also our end users, and the third significant portion of our ecosystem is our members. So we recently just announced that CNCF has crossed over 400 members, our end user community is growing, I think Sheryl mentioned this morning in the keynote, we have about 81 end users and this is phenomenal because end of the day, end users are companies who are not commercializing Cloud Native, but essentially they're using these products or technologies internally, so they are essentially the guinea pig of Cloud Native technologies and it's really important to learn from them. >> Well Dee, and actually it's interesting, you know, celebrating the five years of Kubernetes here, I happened to talk to a couple of the OG's of the community, Joe Beta, Tim Hawkin and Gabe Monroy. And I made a comment to Joe, and I'm like, "Well Google started it, but they brought in the Ecosync and pulled in a lot of other vendors too, it's people. And Gabe said, he's like "yeah, I started Deis and I was one of the people >> Absolutely. >> that joined in." So, we said this community is, it's people more than it's just the collection of the logos on the slides. >> Absolutely, I completely agree. And the other thing I also want to point out is a neutral home, like CNCF, it definitely increases contributions. And the reason I say that is, having a neutral home helps the community in terms of engaging and what is really interesting again, going back to the annual report is Google had a leadership role and most of the contributors were from Google, and now with having a neutral home, I think Google has done a phenomenal job to make sure that the contributors are not just limited to Google. And we're seeing all the other companies participating. We're also seeing a new little graph of independent contributors, who are essentially not associated with any companies and they've been again, very active with their comments or their engagement with overall, in terms of, not just limiting to Kubernetes, but all the other CNCF projects. >> So, this is sort of a situation of being a victim of your own success to some extent, but I've mentioned a couple of times today with various other guests, that this could almost be called a conference about Kubernetes and friends, where it feels like that single project casts an awfully long shadow, when you talk to someone who's vaguely familiar with the CNCF, it's "Oh you mean the Kubernetes people?" "Cool, we're on the same page." How do you, I guess from a marketing perspective begin to move out from under that shadow and become something that is more than a single project foundation? >> Yeah, that's a great question, and the way we are doing that is, I think, Kubernetes has become an economic powerhouse essentially, and what it has done is, it's allowed for other start-ups and other companies to come in and start creating new projects and technologies built around Kubernetes, so essentially, now, you're no longer talking about one single project. It's no longer limited to containers or orchestration, or just micro-services, which was the conversation 3 years ago at KubeCon, and today, what you will see is, it's about talking about the ecosystem. So, the way, from a marketing perspective, and it's actually the reality as well, is Kubernetes has now led to other growing projects, it's actually helped other developers come onboard, so now we are seeing a lot more co-ord, a lot more contributions, and now, CNCF has actually become a home to 35+ projects. So when it was founded, we had about 4 projects, and now it's just grown significantly and I think Kubernetes was the anchor tannin, but now we're just talking about the ecosystem as a whole. >> Dee, I'm wondering if it might be too early for this, but do you have a way of measuring success if I'm someone that has rolled out Kubernetes and some of the associated projects? When I talked to the early Kubernetes people, it's like, Kubernetes itself is just an enabler, and it's what we can do with it and all the pieces that go with it, so I don't know that there's spectrums of how are we doing on digital transformation, and it's a little early to say that there's a trillion dollars of benefit from this environm... but, do you have any measure today, or thoughts as to how we can measure the success of everything that comes out of the... >> Yeah, so I think there was Redmont, they published a report last year and it looks like they're in the process of updating, but it is just phenomenal to see, just based on their report, over 50% of fortune 100 companies have started to use Kubernetes in production, and then I would say, more than, I think, to be accurate, 71% of fortune 100 companies are using containers, so I think, right there is a big step forward. Also, if you look at it last year, Kubernetes was the first project to graduate, so one of the ways we also measure, in terms of the success of these projects, is the status that we have within CNCF, and that is completely community driven, so we have a project that's very early stage, it comes in as a sandbox, and then just based on the community growth, it moves onto the next stage, which is incubating, and then, it takes a big deal to graduate, and to actually go to graduation, so we often refer to those stages of the projects to Jeffery Moore, in terms of crossing the chasm. We've talked about that a lot. And again, to answer your question, in terms of how exactly you measure success is just not limited to Kubernetes. We had, this year, a few other projects graduates, we have 6 projects that have graduated within CNCF. >> How do you envision this unfolding in the next 5 years, where you continue to accept projects into the foundation? At some point, you wind up with what will only be described as a sarcastic number of logos on a slide for all of the included projects. How do you effectively get there without having the Cheesecake Factory menu problem of... the short answer is just 'yes', rather than being able to list them off coz no one can hold it all in their head anymore? >> Great question, we're still working on it. We do have a trail map that is a representation of 'where do I get started?', so it's definitely not prescriptive, but it kind of talks about the 10 steps, and it not only talks about it from a technology perspective, but it also talks about processes and people, so we do cover the DevOp, CICD cycle or pipeline. The other thing I would say is, again, we are trying to find other creative ways to move past the logos and landscape, and you're absolutely right, it's now becoming a challenge, but, you know, our members with 400+ members within CNCF. The other way to actually look at it is, back to my earlier point on ecosystems. So one of the areas that we are looking at is, 'okay, now, what next after orchestration?', which is all about Kubernetes is, now I think there's a lot of talks around security, so we're going to be looking at use cases, and also Cloud Native storage is becoming another big theme, so I would say we now have to start thinking more about solutions, solution, the terminology has always existed in the enterprise world for a long time, but it's really interesting to see that come alive on the Cloud Native site. So now we are talking about Kubernetes and then a bunch of other projects. And so now, it's like that whole journey from start to finish, what are the things that I need to be looking at and then, I think we are doing our best with CNCF, which is still a part of a playbook that we're looking to write in terms of how these projects work well together, what are some common use cases or challenges that these projects together can solve. >> So, Dee, we're here at the European show, you think back a few years ago it was a public cloud, there was very much adoption in North America, and starting to proliferate throughout the world. Alibaba is doing well in China and everything. CNCF now does 3 shows a year, you do North America, you do Europe and we've got the one coming up in China. We actually did a segment from our studio previewing the OpenStack Summit, and KubeCon show there, so maybe focus a little bit about Europe. Is there anything about this community and this environment that maybe might surprise people from your annual data? >> Yes, so if you look at... we have a tool called DevStart, it's open source, anyone can look at it, it's very simple to use, and based on that, we kind of monitor, what are the other countries that are active or, not just in terms of consuming, but who are actually contributing. So if you look at it, China is number 2, and therefore our strategy is to have a KubeCon in China. And then from a Euro perspective, I think the third leading country in terms of contributions would be Europe, and therefore, we have strategically figured out where do we want to host our KubeCon, and in terms of our overall strategy, we're pretty much anchoring to those 3 regions, which is North America, Europe as well as China. And, the other thing that we are also looking at is, we want to expand our growth in Europe as well, and now we have seen the excitement here at our KubeCon Barcelona, so we are looking to offer some new programs, or, I would say, new event types outside of KubeCon. Kind of you want to look at it as mini KubeCons, and so those would explore more in terms of different cities in Europe, different cities in other emerging markets as well. So that's still in the works. We're really excited to have, I would say 2 new event types that we're exploring, to really get the community to run and drive these events forward as well, outside of their participation in KubeCon because, oftentimes, I hear that a developer would love to be here, but due to other commitments, or, their not able to travel to Europe, so we really want to bring these events local to where they are, so that's essentially a plan for the next 5 years. >> It's fascinating hearing you describe this, because, everything you're saying aligns perfectly with what you'd expect from a typical company looking to wind up, building adoption, building footprints etc., Only, you're a foundation. Your fundamental goal at the end of it is user engagement, of people continuing to participate in the community, it doesn't turn into a 'and now, buy stuff', the only thing you have for sale here that I've noticed is a T-shirt, there's no... Okay, you also have other swag as well, not the important part of the story, I'm curious though, as far as, as you wind up putting all of this together, you have a corporate background yourself, was that a difficult transition to navigate, as far as, getting away from getting people to put money in towards something in the traditional sense, and more towards getting involved in a larger ecosystem and community. >> That was a big transition for me, just having worked on the classic B2B commercial software side, which is my background, and coming in here, I was just blown away with how people are volunteering their time and this is not where they're getting compensated for their time, it's purely based on passion, motivation and, when I've talked to some key community organizers or leaders who have done this for a while, one of the things that has had an impact on me is just the strong core values that the communities exhibit, and I think it's just based on that, the way they take a project and then they form a working group, and then there are special interest groups that get formed, and there is a whole process, actually, under the hood that takes a project from where Kubernetes was a few years ago, and where it is today, and I think it's just amazing to see that it's no longer corporate driven, but it's more how communities have come together, and it's also a great way to be here. Oftentimes... gone are the days where you try to set up a meeting, people look forward to being at KubeCon and this is where we actually get to meet face-to-face, so it's truly becoming a networking event as well, and to build these strong relationships. >> It goes even beyond just users, I mean, calling this a user conference would not... it would be doing it a bit of disservice. You have an expo hall full of companies that are more or less, in some cases, sworn enemies from one another, all coexisting peacefully, I have seen no fist-fights in the 2 days that we've been here, and it's fascinating watching a community effort get corporate decision makers and stakeholders involved in this, and it seems that everyone we've spoken to has been having a good time, everyone has been friendly, there's not that thousand yard stare where people are depressed that you see in so many other events, it's just something I've never experienced before. >> You know, that's a really amazing thing that I'm experiencing as well. And also, when we do these talks, we really make it a point to make sure that it's not a vendor pitch, and I'm not being the cop from CNCF policing everyone, and trying to tell them that, 'hey, you can't have a vendor pitch', but what I'm finding is, even vendors, just did a silverless talk with AWS, and he's a great speaker, and when he and I were working on the content, he in fact was, "you know, you're putting on that hat", and he's like, "I don't want to talk about AWS, I really want to make sure that we talk about the underlying technology, focusing on the projects, and then we can always build on top, the commercial aspect of it, and that's the job for the vendor. So, I think it's really great collaboration to see how even vendors put on the hat of saying, 'I'm not here to represent my products, or my thing', and of course they're here to source leads and stuff, but at the end of the day, the underlying common protocol that's already just established without having explicit guidelines saying, 'this is what you need to be following or doing', it's just like an implicit understanding. Everyone is here to promote the community, to work with the community, and again, I think I really want to emphasize on the point that people are very welcoming to this concept of a neutral home, and that really had helped with this implicit understanding of the communities knowing that it's not about a vendor pitch and you really want to think about a project or a technology and how to really use that project, and what are the use cases. >> It's very clear, that message has resonated well. >> Dee, thank you. We've covered a lot of ground, we want to give you the final word, anything else? We've covered the event, we've covered potential little things and the annual report. Any last words you have for us that you want people to take away? >> Not really, I think, like I said, it's the community that's doing the great work. CNCF has been the enabler to bring these communities together. We're also looking at creating a project journey it terms of how these projects come into CNCF, and how CNCF works with the communities, and how the project kind of goes through different stages. Yeah, so there are a lot of great things to come, and looking forward to it. >> Alright, well, Dee, thank you so much for all of the updates, and a big thank you, actually, to the whole CNCF team for all they've done to put this together. We really appreciate the partnership here. For Corey Quinn, I'm Stu Miniman. Back to wrap 2 days, live coverage, here at KubeCon, Cloud Native Con 2019, Thanks for watching the Cube. >> Thank you.

>> 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, we're in Barcelona, Spain and you're watching theCUBE, the worldwide leader in live tech coverage and this is KubeCon, CloudNativeCon. I'm Stu Miniman and my co-host for the two live days of coverage is Mr. Cory Quinn. And joining us was on the main stage yesterday, is Cheryl Hung who is the Director of Ecosystems at the Cloud Native Computing Foundation, or the acronym CNCF. Cheryl, welcome back to the program, thanks so much for joining us. >> Thank you, I always have a great time with theCUBE. >> So, first of all 7700 people here, one of the things that strikes me is we go to a lot of shows. We even do a decent amount of international shows. The community here is definitely global, and it's not, sometimes it's the same traveling pack, some person's like, "Well not quite as many people here "as were in Seattle." I'm like, well this isn't just the contributors all going and some of their friends and family. We've had on our program, thanks to the CNCF, and for some of the ecosystem, many of the customers here in Europe doing things, when we talk to people involved, it is obvious that it is a global community and it definitely shows here at the event, so great job on that. >> It's something that the CNCF really cares about because it's not just about one country or small set of countries, this is actually a global movement. There are businesses all over the globe that are in the middle of this transformational moment, so it's just really exciting to see it. I mean, I think of myself as being pretty involved with the Cloud Native community, but as I'm walking around the sponsor booths here today, there's a good 40-50% that I'm just not familiar with and that's quite surprising to me. I would've thought I'd knew almost all the companies around here, but it's always really fun to see the new companies coming in. >> Okay, so let's talk for a second about the diversity inclusion. One of the things is bringing in people that might not have been able to come on their own. Can you talk a little bit about that effort? And you've got some connection with that yourself. >> Yeah, yeah, so I care a lot about diversity in tech, and women in tech more specifically. One of the things that, I feel like this community has a lot of very visible women, so when I actually looked at the number of contributors by men and women, I was really shocked to find out it was 3%. It's kind of disappointing when you think about it. >> And what you're saying is it's 3% of all the contributors to all the projects in the CNCF. >> Exactly. If you look at the 36 projects, you look at the number of the people who've made issues, commits, comments, pull requests, it's 3% women and I think the CNCF has put a lot of effort into the, for example, the diversity scholarships, so bringing more than 300 people from under-represented groups to KubeCon, including 56 here in Barcelona, and it has a personal meaning to me because I really got my start through that diversity scholarship to KubeCon Berlin two years ago and when I first came to KubeCon Berlin, I knew nobody. But just that little first step can go a long way into getting people into feeling like they're part of the community and they have something valuable to give back. And then, once you're in, you're hooked on it and yeah, then it's a lot of fun. >> It's been said fairly frequently that talent is evenly distributed, but opportunity is not. As you take a look at the diversity inclusion efforts that the Cloud Native Computing Foundation is embarking on, how do you, what do you start evolving to next, and I ask that as two specific questions: One is do you have a target for next time, other than just larger than 3%? And, secondly, are you looking to actively expand the diversity scholarship program? And if so, how? >> Yeah, the diversity scholarship and the other initiatives around this are long-term initiatives. They're not going to pay off in the next three months; they're going to pay off in two year's time, three year's time. At least that's the hope, that's the goal. So we're always reliant on a lot of our sponsors. I mean, it's kind of a nice time at the moment because there's a lot of effort and willingness to be supportive of diversity in tech, and that means that we can offer more diversity scholarships to more people. But, I sometimes wonder, like I hope that this is not a, I hope that this is not a one-off thing will happen for five years and then people will lose interest. So, I think there are other things that need to happen. And one of the interesting things that I looked at recently is a GitHub survey, this was done in 2017, where they asked men and women how, the last time that you got help in open source, what was the source of that help? And women were, so women were just as likely to say they were interested in contributing, but they were half as likely to say that they had asked on a public forum, like a mailing list, and half as likely to say that they had received unsolicited help. So, I don't think it's something you can just say, right we'll look at individuals and make them do more, this is a community effort. We're all part of the same group of people, that we're trying to do the same, trying to work on the same things, and to do that, we need to get this mindset amongst the community that we need to reach out to more individuals and help them and pull them in, rather than saying well it's up to the CNCF to sort it out. >> Right, so Cheryl, another piece of the ecosystem that you're involved with is the end user piece. We've saw some of the interviews on the stage, as I've mentioned we've had some on the program, talk about the importance and the progress of end user participation in the CNCF. >> Yeah, so the CNCF was set up with these three bodies: the governing board, the technical oversight committee, and the end user community. And in theory, these three should be co-equal in power. At the moment, the end user community is probably lagging behind a little bit, but it's the reason that I joined the CNCF, the reason that my world exists, is to understand what the end users need and get them active and engaged in the community. So, my hope for the end user community is that end users who come in can see, not only the value of using these projects, but there's a path for them into becoming strong technical leaders and having actual influence in the projects beyond users, and then eventually, maybe contributing themselves and becoming leaders. >> Governance of open source projects has always been something of a challenge because it seems that in many respects, the most vocal people are often the ones who are afforded an unfortunate level of control, despite the fact that they may very well not speak for the common case. Instead they start adjudicating and advocating for corner cases. How, it seems that, at this point, based upon the sheer level of engagement you're seeing across enterprises and companies of all sizes, that that is clearly not the case. How do you, I guess, shape an ecosystem that has a healthy perspective on that? >> So, leadership in open source is very different from leadership in a typical corporate hierarchy. And leaders in open source are recognized, not only because of their technical depth and their hands-on contribution, but for their ability to communicate to others and have the empathy and understand what other people need. So, I think that's gone, the people who are seen as leaders in this community have, they've become role models for others and others kind of use that, to earn the actual trust of the community, you have to be very clearly making the right decisions and not doing it because you have an agenda in mind or because your employer wants you to do certain things. So I think that's gone a long way too, making sure that the ecosystem is really healthy and people really feel good about what they're doing. >> Cheryl, last thing is, could you give us for, how are we helping end users get an on-ramp into this community? If you could just give us, kind of, a real quick, what's the CNCF doing, what are some of those on-ramps for those that aren't already on the vote? >> The three big challenges for end users right now are number one, how do I navigate the ecosystem? Number two, how do I hire engineers? And number three, how do I make sure that my business strategy is aligned with Cloud Native? So, navigating the ecosystem is probably the trickiest one because there's so many channels, so many projects, there's no central authority that you can go to and say, I've got this problem, am I doing the right thing? Can you help me get this project, this feature into this project's road map? So, the CNCF has a lot of programs to ensure that end users can meet their peers and especially companies who are, perhaps, 12 months ahead of them, and everybody's trying to go through the same journey right now, everyone has these common challenges. So if they can figure them out together and solve them together, then it just saves a lot of time and effort for everybody. On the hiring piece, the CNCF does a lot around marketing and PR and brand awareness and there's companies here who have a booth, who are not selling their products at all, they're just here because they want to be in front of the engineers who are most involved with open source and Kubernetes, and so the CNCF facilitates that, and to some extent, subsidizes these end users to be at KubeCon. And then the third challenge is aligning your business strategy with Cloud Native. So, end users want to know these projects have longevity. They're going to be here in five year's or 10 year's time, and so for companies that want to get involved into that next level, for example running on that technical oversight committee or being on the governing board, the CNCF can help end users become, have that level of impact and have that level of engagement within the community. >> Alright so Cheryl, last word, any advice for people? What's the hottest job out there, that people are looking for? >> I've previously managed DevOps engineering teams and finding people with real Kubernetes production experience right now is just really hard. And I would say that the first thing that you should do, if you have no experience at all in it, is look at the training programs, for example the CKA, Certified Kubernetes Administrator. You don't have to get a certification, but if you look at the curriculum and go through it step by step, you can understand the basic concepts and after that point, get the production experience. There's no substitute to a year or two years of really running applications and monitoring and scaling them in production and dealing with fires. So, once you get to that point, it's a great place to be. >> Alright, well you heard it here. Cheryl, thanks so much for sharing everything with the ecosystem diversity inclusion. Really appreciate the updates. >> Thank you, really good to speak to you. >> For Cory Quinn, I'm Stu Miniman. Coming back with, getting towards the end of two days of live coverage here. Thanks for watching theCUBE. (upbeat music)

(upbeat techno 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, this is The Cube's coverage of KubeCon CloudNativeCon 2019. I'm Stu Miniman with Corey Quinn as my cohost, even though he says kucon. And joining us on this segment, we're not going debate how we pronounce certain things, but I will try to make sure that I get Bridget Kromhout correct. She is a Principle Cloud Advocate at Microsoft. Thank you for coming back to The Cube. >> Thank you for having me again. This is fun! >> First of all I do have to say, the bedazzled shirt is quite impressive. We always love the sartorial, ya know, view we get at a show like this because there are some really interesting shirts and there is one guy in a three-piece suit. But ya know-- >> There is, it's the high style, got to have that. >> Oh, absolutely. >> Bringing some class to the joint. >> Wearing a suit is my primary skill. (laughing) >> I will tell you that, yes, they sell this shirt on the Microsoft company store. And yes, it's only available in unisex fitted. Which is to say much like Alice Goldfuss likes to put it, ladies is gender neutral. So, all of the gentleman who say, but I have too much dad bod to wear that shirt! I say, well ya know get your bedazzlers out. You too can make your own shirt. >> I say it's not dad bod, it's a father figure, but I digress. (laughing) >> Exactly! >> Alright, so Bridget you're doing some speaking at the conference. You've been at this show a few times. Tell us, give us a bit of an overview of what you're doing here and your role at Microsoft these days. >> Absolutely. So, my talk is tomorrow and I think that, I'm going to go with its a vote of confidence that they put your talk on the last day at 2:00 P.M. instead of the, oh gosh, are they trying to bury it? But no, it's, I have scheduled enough conferences myself that I know that you have to put some stuff on the last day that people want to go to, or they're just not going to come. And my talk is about, and I'm co-presenting with my colleague, Jessica Deen, and we're talking about Helm 3. Which is to say, I think a lot of times it would, with these open-sourced shows people say, oh, why do you have to have a lot of information about the third release of your, third major release of your project? Why? It's just an iterative release. It is, and yet there are enough significant differences that it's kind of valuable to talk about, at least the end user experience. >> Yeah, so it actually got an applause in the keynote, ya know. (Bridget laughing) There are certain shows where people are hootin' and hollerin' for every, different compute instance that that is released and you look at it a little bit funny. But at the keynote there was a singular moment where it was the removal of Tiller which Corey and I have been trying to get feedback from the community as to what this all means. >> It seems, from my perspective, it seemed like a very strange thing. It's, we added this, yay! We added this other thing, yay! We're taking this thing and ripping it out and throwing it right into the garbage and the crowd goes nuts. And my two thoughts are first, that probably doesn't feel great if that was the thing you spent a lot of time working on, but secondly, I'm not as steep in the ecosystem as perhaps I should be and I don't really know what it does. So, what does it do and why is everyone super happy to con sine it to the dub rubbish bin of history? >> Right, exactly. So, first of all, I think it's 100% impossible to be an expert on every single vertical in this ecosystem. I mean, look around, KubeCon has 7,000 plus people, about a zillion vendor booths. They're all doing something that sounds slightly, overlapping and it's very confusing. So, in the Helm, if you, if people want to look we can say there's a link in the show notes but there, we can, people can go read on Helm.sh/blog. We have a seven part, I think, blog series about exactly what the history and the current release is about. But the TLDR, the too long didn't follow the link, is that Helm 1 was pretty limited in scope, Helm 2 was certainly more ambitious and it was born out of a collaboration between Google actually and a few other project contributors and Microsoft. And, the Tiller came in with the Google folks and it really served a need at that specific time. And it was, it was a server-side component. And this was an era when the Roll by Stacks has control and Kubernetes was, well nigh not existent. And so there were a lot of security components that you kind of had to bolt on after the fact, And once we got to, I think it was Kubernetes 1.7 or 1.8 maybe, the security model had matured enough that instead of it being great to have this extra component, it became burdensome to try to work around the extra component. And so I think that's actually a really good example of, it's like you were saying, people get excited about adding things. People sometimes don't get excited about removing things, but I think people are excited about the work that went into, removing this particular component because it ends up reducing the complexity in terms of the configuration for anyone who is using this system. >> It felt very spiritually aligned in some ways, with the announcement of Open Telemetry, where you're taking two projects and combining them into one. >> Absolutely. >> Where it's, oh, thank goodness, one less thing that-- >> Yes! >> I have to think about or deal with. Instead of A or B I just mix them together and hopefully it's a chocolate and peanut butter moment. >> Delicious. >> One of the topics that's been pretty hot in this ecosystem for the last, I'd say two years now it's been service matched, and talk about some complexity. And I talk to a guy and it's like, which one of these using? Oh I'm using all three of them and this is how I use them in my environment. So, there was an announcement spearheaded by Microsoft, the Service Mesh Interface. Give us the high level of what this is. >> So, first of all, the SMI acronym is hilarious to me because I got to tell you, as a nerdy teenager I went to math camp in the summertime, as one did, and it was named SMI. It was like, Summer Mathematics Institute! And I'm like, awesome! Now we have a work project that's named that, happy memories of lots of nerdy math. But my first Unix system that I played with, so, but what's great about that, what's great about that particular project, and you're right that this is very much aligned with, you're an enterprise. You would very much like to do enterprise-y things, like being a bank or being an airline or being an insurance company, and you super don't want to look at the very confusing CNCF Project Map and go, I think we need something in that quadrant. And then set your ships for that direction, and hopefully you'll get to what you need. And it's especially when you said that, you mentioned that, this, it basically standardizes it, such that whichever projects you want to use, whichever of the N, and we used to joke about JavaScript framework for the week, but I'm pretty sure the Service Mesh Project of the week has outstripped it in terms of like speed, of new projects being released all the time. And like, a lot of end user companies would very much like to start doing something and have it work and if the adorable start-up that had all the stars on GitHub and the two contributors ends up, and I'm not even naming a specific one, I'm just saying like there are many projects out there that are great technically and maybe they don't actually plan on supporting your LTS. And that's fine, but if we end up with this interface such that whatever service mesh, mesh, that's a hard word. Whatever service mesh technology you choose to use, you can be confident that you can move forward and not have a horrible disaster later. >> Right, and I think that's something that a lot of developers when left to our own devices and in my particular device, the devices are pretty crappy. Where it becomes a, I want to get this thing built, and up and running and working, and then when it finally works I do a happy dance. And no one wants to see that, I promise. It becomes a very different story when, okay, how do you maintain this? How do you responsibly keep this running? And it's, well I just got it working, what do you mean maintain it? I'm done, my job is done, I'm going home now. It turns out that when you have a business that isn't being the most clever person in the room, you sort of need to have a longer term plan around that. >> Yeah, absolutely. >> And it's nice to see that level of maturation being absorbed into the ecosystem. >> I think the ecosystem may finally be ready for it. And this is, I feel like, it's easy for us to look at examples of the past, people kind of shake their heads at OpenStack as a cautionary tale or of Sprawl and whatnot. But this is a thriving, which means growing, which means changing, which means very busy ecosystem. But like you're pointing out, if your enterprises are going to adapt some of this technology, they look at it and everyone here was, ya know, eating cupcakes or whatever for the Kubernetes fifth birthday, to an enterprise just 'cause that launched in 2014, June 2014, that sounds kind of new. >> Oh absolutely. >> Like, we're still, we're still running that mainframe that is still producing business value and actually that's fine. I mean, I think this maybe is one of the great things about a company like Microsoft, is we are our customers. Like we also respect the fact that if something works you don't just yolo a new thing out into production to replace it for what reason? What is the business value of replacing it? And I think for this, that's why this, kind of Unix philosophy of the very modular pieces of this ecosystem and we were talking about Helm a little earlier, but there's also, Draft, Brigade, etc. Like the Porter, the CNET spec implementation stuff, and this Cloud Native application bundles, that's a whole mouthful. >> Yes, well no disrespect to your sparkly shirt, but chasing the shiny thing, and this is new and exciting is not necessarily a great thing. >> Right? >> I heard some of the shiny squad that were on the show floor earlier, complaining a little bit about the keynotes, that there haven't been a whole lot of new service and feature announcements. (Bridget laughing) And my opinion on that is feature not bug. I, it turns out most of us have jobs that aren't keeping up with every new commit to an open-source project. >> I think what you were talking about before, this idea of, I'm the developer, I yolo'd out this co-load into production, or I yolo'd this out into production. It is definitely production grade as long as everything stays on the happy path, and nothing unexpected happens. And I probably have air handling, and, yay! We had the launch party, we're drinkin' and eatin' and we're happy and we don't really care that somebody is getting paged. And, it's probably burning down. And a lot of human misery is being poured into keeping it working. I like to think that, considering that we're paying attention to our enterprise customers and their needs, they're pretty interested in things that don't just work on day one, but they work on day two and hopefully day 200 and maybe day 2000. And like, that doesn't mean that you ship something once and you're like, okay, we don't have to change it for three years. It's like, no, you ship something, then you keep iterating on it, you keep bug fixing, you keep, sure you want features, but stability is a feature. And customer value is a feature. >> Well, Bridget I'm glad you brought that up. Last thing I want to ask you 'cause Microsoft's a great example, as you say, as a customer, if you're an Azure customer, I don't ask you what version of Azure you're running or whether you've done the latest security patch that's in there because Microsoft takes care of you. Now, your customers that are pulled between their two worlds is, oh, wait, I might have gotten rid of patch Tuesdays, but I still have to worry and maintain that environment. How are they dealing with, kind of that new world and still have, certain things that are going to stay the old way that they have been since the 90's or longer? >> I mean, obviously it's a very broad question and I can really only speak to the Kubernetes space, but I will say that the customers really appreciate, and this goes for all the Cloud providers, when there is something like the dramatic CVE that we had in December for example. It's like, oh, every Kubernetes cluster everywhere is horribly insecure! That's awesome! I guess, your API gateway is also an API welcome mat for everyone who wants to, do terrible things to your clusters. All of the vendors, Microsoft included, had their managed services patched very quickly. They're probably just like your Harple's of the world. If you rolled your own, you are responsible for patching, maintaining, securing your own. And this is, I feel like that's that tension. That's that continuum we always see our customers on. Like, they probably have a data center full of ya know, veece, fear and sadness, and they would very much like to have managed happiness. And that doesn't mean that they can easily pickup everything in the data center, that they have a lease on and move it instantly. But we can work with them to make sure that, hey, say you want to run some Kubernetes stuff in your data center and you also want to have AKS. Hey, there's this open-source project that we instantiated, that we worked on with other organizations called Vertual Kubelet. There was actually a talk happening about it I think in the last hour, so people can watch the video of that. But, we have now offered, we now have Virtual Node, our product version of it in GA. And I think this is kind of that continuum. It's like, yes of course, you're early adapters want the open-source to play with. Your enterprises want it to be open-source so they can make sure that their security team is happy having reviewed it. But, like you're saying, they would very much like to consume a service so they can get to business value. Like they don't necessarily want to, take, Kelsey's wonderful Kubernetes The Hard Way Tutorial and put that in production. It's like, hmm, probably not, not because they can't, these are smart people, they absolutely could do that. But then they spent their, innovation tokens as, the McKinley blog post puts it, the, it's like, choose boring technology. It's not wrong. It's not that boring is the goal, it's that you want the exciting to be in the area that is producing value for your organization. Like that's where you want most of your effort to go. And so if you can use well vetted open-source that is cross industry standard, stuff like SMI that is going to help you use everything that you chose, wisely or not so wisely, and integrate it and hopefully not spend a lot of time redeveloping. If you redevelop the same applications you already had, its like, I don't think at the end of the quarter anybody is getting their VP level up. If you waste time. So, I think that is, like, one of the things that Microsoft is so excited about with this kind of open-source stuff is that our customers can get to value faster and everyone that we collaborate with in the other clouds and with all of these vendor partners you see on the show floor, can keep the ecosystem moving forward. 'Cause I don't know about you but I feel like for a while we were all building different things. I mean like, instead of, for example, managed services for something like Kubernetes, I mean a few jobs that would go out was that a start up that we, we built our own custom container platform, as one did in 2014. And, we assembled it out of all the LEGOs and we built it out of I think Docker and Packer and Chef and, AWS at the time and, a bunch of janky bash because like if someone tells you there's no janky bash underneath your home grown platform, they are lying. >> It's always a lie, always a lie. >> They're lying. There's definitely bash in there, they may or may not be checking exit codes. But like, we all were doing that for a while and we were all building, container orchestration systems because we didn't have a great industry standard, awesome! We're here at KubeCon. Obviously Kubernetes is a great industry standard, but everybody that wants to chase the shiny is like but surface meshes. If I review talks for, I think I reviewed talks for KubeCon in Copenhagen, and it was like 50 or 60 almost identical service mesh talk proposals. And it's like, and then now, like so that was last year and now everyone is like server lists and its like, you know you still have servers. Like you don't add sensation to them, which is great, but you still have them. I think that that hype train is going to keep happening and what we need to do is make sure that we keep it usable for what the customers are trying to accomplish. Does that make sense? >> Bridget, it does, and unfortunately, we're going to have to leave it there. Thank you so much for sharing everything with our audience here. For Corey, I'm Stu, we'll be back with more coverage. Thanks for watching The Cube. (upbeat techno 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. This is theCUBE's live coverage of KubeCon + CloudNativeCon 2019 here in Barcelona, Spain. I'm Stu Miniman, my cohost is Corey Quinn. Happy to welcome to the program two first-time guests, a company we've had on the program, Reduxio. But some changes have been going on, as have been in the industry. Sitting to my right is Ori Bendori, who is the CEO of the company. Sitting to his right is Jacob Cherian, who is the CMO and vice president of product. Gentlemen, thanks so much for joining us. >> Thank you. >> Thank you for having us. >> One of the things that I've really enjoyed at this conference is, it is a global conference. The CNCF puts on three pieces of it, but this one definitely has a very European flavor. You gentlemen are coming to us from Israel. Ori, let's start with you. Just give us the update, kind of the quick, the who and the why and the what of Reduxio. >> Okay. So we are a storage and data management company, and where we are aiming is having Kubernetes native, containers native, cloud native solution. We have some unique capabilities. And actually we are getting ourself to the public this exhibition, so it's very important for us. We've been developing it for the last year, so this is the first time we announce that we have a new product that is container native, headed to clouds, and very unique. >> So Jacob, we actually had an analyst on earlier and he said, "The thing about this space is, "we're talking it's stateless, "it's trussless, it's codeless. "That doesn't mean I can't deal "with those environments, "they all have some challenges when you talk about storage." I mean those of us that know storage, it's a complicated thing. I loved the presentation this morning, and the key note was it's turtles all the way down. There's a lot of complexity inside storage and that doesn't go away, and sometimes we're trying to make this world no less complicated than storage would be outside of it, as I guess an industry thing. How is Reduxio helping us solve that? >> So as customers move applications from traditional infrastructures to storage, to containerized infrastructure, I think the expectation is that these customers would expect the same capability that they had with the existing storage systems in the container native storage. Because why would a customer move their applications to an environment that's less capable? And our focus is to deliver storage that is enterprise grade, where customers feel comfortable for moving their business-critical applications from the traditional environment into a container environment. >> You mentioned a few minutes ago that this is, you have something very unique that you've been working on for a year and are now deploying into the marketplace. In your conversations with customers, what unmet need did you wind up seeing and what differentiates you from other options people could go with? >> Thank you. I think we're talking about three things. The most important thing, the first one, as Jacob was describing, is we are enterprise grade. We have the full set of data management and storage capability, which we believe some of our customers do not have. We believe containers are moving to production. To real serious enterprise application, you need this kind of capability. And we have it. The other two are very unique. The first one, we are microservice based. We believe the first wave of solutions for containers native was built on just putting stuff inside a container instead of virtual machine. We think you need to go all the way. We took our technology, and we put it in microservices. This brings us a huge advantage in multiple areas. If you think about it, is one of the reasons people went and adopted containers is all this capability they bring. When you are not implementing the microservices, you are actually losing a lot of this value. The third one is a unique capability, which is our unique IP as well, is what we call data mobility or application mobility. We believe containers, one of the major things people are looking for is mobility. They want to move their stuff between on-prem to the public cloud. They all want to move from one public cloud provider to another. They want to do it quickly. You can do it with containers and with Kubernetes. You cannot move the data. If you move your application from on-prem to the public cloud, data is not with you because storage is not with you. We make it different. What we are offering is this unique IP. When you move the application, by the way everything is application-based in our solution, when you move it, we are moving the kind of metadata we need, which takes a minute or two, and you can start working immediately in the new location. We'll make sure everything happening in the new location, we will move your data in the background. By the way, we move the hot data first and the cold data later. We believe that makes a big difference for hybrid solutions. If you want to run multiple clouds, both on-prem and public, you would like to have the ability to move stuff quickly. It cannot be that you move the application and a week later the data arrives. It just doesn't work. >> There are very definitely latency considerations in there. When you're doing this, do you find that you're presenting this as file, block, object, or does it not matter given that your application-- >> Yes, so the solution we provide to that provides persistent volumes in Kubernetes. It's container native. It actually uses a CSI plug-in to basically deliver persistent volumes to pods that run within Kubernetes. >> So Jacob, when I talk to storage companies today, there are your traditional storage companies, and they're all, "We're moving toward cloud native, "yeah, microservices, we're all in on that stuff." We've seen a resistance in the enterprise to how developer models are going to go in there, how they're going to modernize. And then I've got cloud native people that would just say, "We're built for multi-cloud, and we do this." Where do you fit? What's the industry getting right, and was does differentiate your team? >> So I think let's define container native first, right? I think that's important because everybody says that they're cloud native; if you have a CSI plug-in, people claim, and people are cloud native because you can attach them to Kubernetes. But I think container native has unique value because once you move to Kubernetes, you truly are building a cloud environment where you want all your work, everything to be running inside that Kubernetes cluster. This is really realization of ITS code, right? Where infrastructure is shared, physical resources are shared, and your networking, your applications, and storage are just services that run on top of a physical infrastructure. For us, when we look at container native, the important attribute for container native is that it runs within Kubernetes, it's implemented as containers, and it is orchestrated and scales with Kubernetes. It should not be something that's separate. >> All right, so Ori, you've been in the industry for a while. >> The storage people, they buy on risk. It's like, oh, this cool new stuff it's all nice and everything but it needs to be trusted. While they're interested and they're trying new things, and sure they're going to get Kubernetes in production in the next six months. Why Reduxio, how can they be trusted in this space? >> So I think this is a bit talking about go to market and what we are doing. So we've been engaging to customers from day one, and we're going to to do a peer see in the coming months with I don't know how many of them. I think we learned where the use cases make sense, okay? So, the good news for us is that the market is moving forward as of containers. We don't have like financial institutions, many of them decided strategically they're moving there, they're going to containers. They probably aren't going to do everything on containers, but new staff will go to containers. So those people, I don't have to convince them. When they look around, there's not much. If you want to have storage that is container native, there's not a lot. By the way, most of it is coming from start-ups, if not all of it right now. And they're saying, we went all the way, now we go back and have an external storage, it just doesn't make sense. So those people, anyway, it is a bit new. I'm not fighting for their application they have since the '90s, okay? I don't think they will move many of those into containers. But there is enough that is moving to containers. The other one that I think is important is the use case which are very natural to containers, people already adopt them. I'll name two of them. One is CICD. People are using it to move stuff anyway. They want to have on a public cloud, on a private cloud. They are using Jenkins in many cases. We deliver into Jenkins a solution that is so natural and so valuable to them, it's almost a no-brainer. By the way, it is CICD, so it fails. So restart it, right? It's out of production data at this stage, and if it works, by the way, half a year from now they'll put us in other places. The other thing around is Hadoop. Anything that has to do with data processing, a lot of those people are moving into containers anyway. In a way we are riding with them. They are looking for a solution that will simplify the way they put, they construct their stuff. They want to move easily and have the kind of mobility we talked about. And in a way they are willing to take the risk. And by the way, none of the current incumbent provide 'em any of the solution. Which is the benefit of the small guys. >> Jacob, what's the roll out of this new offering? >> Yes, so what we've announced at KubeCon is that we've started customer evaluations. We expect to start POCs in about three months. So from evaluation to POC it's about three months, and product will be available for production by fall of this year. >> All right, so Ori, I want to give you the final word. Where should people be looking for Reduxio, and what do we expect from the company throughout the year? >> I think in the end of the day, I'm trying to be modest, but I won't. We believe we are in a way the future of storage. Not because we're that smart, because it makes a lot of sense because this is the way the public cloud guys are building their stuff. It has to be cloud native. It has to be container native because that is where the IT is moving to. So in a way, we're saying in the end of the day, storage needs to behave like everybody else. It cannot be the exception. Storage has to be part of the containers ecosystem. We represent the first one, maybe not the first one. There will be others, we're not going to be alone. But we believe the direction we're taking is the direction the storage industry will take. >> Well, Ori and Jacob thanks so much for sharing everything. >> Thank you. >> We know there's always the next new thing, it's going to make everything nice and easy. Some hard work to make sure that storage works right in all these new environments. We look forward to tracking everything. For Corey Quinn, I'm Stu Miniman, we'll be back with more coverage here from KubeCon + CloudNativeCon 2019. Thanks for watching theCUBE. (upbeat music)

>> Live from Barcelona, Spain, it's theCUBE. Covering KubeCon + CloudNativeCon Europe 2019. Brought to you by Red Hat, the CloudNative Computing Foundation and ecosystem partners. >> In mid-2014, announced the world, coming out of Google led by Joe Beda, sitting to my right, Brendan Burges and Craig McLucky, all Kube alumni. Kubernetes, which is the Greek for governor helmsman or captain and here we are, five years later at the show. I'm Stu Miniman and this is theCUBE's coverage of KubeCon + CloudNativeCon here in Barcelona, Spain. Joe you've got your title today is that you're a principal engineer at VMware of course, by way of acquisition through Heptio, but you are one of the people who helped start this journey that we are all on Kubernetes, thanks so much for joining us. >> Yeah, thank you so much for having me. >> Alright, so, the cake and the candles and the singing we'll hold for the parties later. We have Fippy and the gang have been watching our whole thing, for people who don't know there's a whole cartoon, books and stuffed animals and everything like that. Joe, when you started this merchandising, that was what you were starting, no. In all seriousness though, bring us back a little bit give us a little bit of historical context as to we've had you on the program a few times but yeah, here we are five years later was this what you were expecting? >> I mean when I remember Craig and Bren and I sitting around and we're like hey, we should do this as an open source project This is before we got approvals and got the whole thing started. And I think there was, like an idea in the back of our head, of like, this could be a big deal. You dream big a lot of times and you know that there's a reality and that it's not always going to end up being this. And so, I don't think anybody involved with Kubernetes in the early days really thought it was going to turn into what it has turned into. >> Yeah, so when we look at open source projects, I remember back a few years back, it was like to succeed you must have a phoenetical dictator that will make sure the community does this or wait we don't want too much vendor we're just going to let the user community take over and there's all these extremes out there, but these are complicated pieces. The keynote this morning the discussion was Kubernetes is a platform of platforms it's like I've got all of these APIs and by itself, Kubernetes doesn't do a lot. It is, what it enables and what things put together, so walk us through a little bit of that the mission, how it changed a bit and a little bit of the community and we'll go from there. >> Yeah, I think so early on one of the goals with Kubernetes from Google's point of view was to essentially take a lot of the ideas that had been incubated over about a decade, with respect to Borg and other things and so, a lot of the early folks who got involved in the project and worked on those systems and really bring that to the outside world as a way to actually start bridging the gap between what Googlers did and what the rest of the world did. We had a really good idea of what we were looking to get out of this system and that was widely shared based on experience across a bunch of relatively senior engineers. We brought in some of the Red Hat folks early on Clayton Coleman and some of the other folks who are still super involved in the project. I think there was enough of an understanding that we looked and said okay we got a lot of work to do let's just get this done. So, we didn't really need sort of the benevolent dictator because there was a shared understanding and we had senior engineers that were willing to make trade-offs to be able to go and move forward. So that I think was a key bit of the success early on. >> Alright, so you talked, it was pulling in some other vendor community there. Talk a little bit about how that ecosystem grew and when was user feedback part of that discussion? >> Yeah, I mean, when you say we pulled in the vendor we pulled in people who worked for vendors but we never really viewed it as, there was really from the beginning this idea of well what's good for the project? What's going to actually create sustainability and for the project, sort of project over vendor is really something that we wanted to establish. And that even came down to the name, right? Like, when we named the project, we could have called it Google XYZ or some sort of XYZ but we didn't want to do that because we wanted to establish it as an independent thing with a life of its own. And so, yeah, so we wanted to bring in those external ideas and I think early on, we did have some early users, we did listen to them but it really resonated with folks who could actually see where we were going. I think it took time for the rest of the world to really catch on with what the vision was. >> OK, when we look at today, there's a lot at the show that is on top of or next to or with Kubernetes it's not all about that piece. How do you balance what goes in it versus what goes with it? One of my favorite lines last year overall, was from you, saying Kubernetes is not a magic player it is not the be all and end all it is set with very specific guidelines. How do you avoid scope creep? As engineers it's always like, I don't know, we know how to do that piece of it better. >> So when we started out the project we didn't actually have a governance model. It was just a bunch of engineers that sort of worked well together. Over time and as the project grew, we knew that we needed to actually get some sort of structure in place. And so a bunch of us who had been there from the start got together, formed a steering committee, held elections. There's a secret architecture that we formed and these are the places where we can actually say what is Kubernetes what is Kubernetes not how do we actually maintain sort of good taste with how we actually approach this stuff and that's one of the ways that we try to contain scope creep. But also, I think everybody realizes that a thriving ecosystem whether officially part of the CNCF or adjacent to it, is good for everybody. Trying to hold on too tight is not going to be good for the project. >> So, Joe, tremendous progress in five years. Look forward for us a little bit. What does Kubernetes 2024 look like for us? >> Well a lot of folks like to say that in five years, Kubernetes is going to disappear. And sometimes they come at this from this sort of snarky angle. (chuckles) But other times, I think it's going to disappear in terms of like it's going to be so boring, so solid, so assumed that people don't talk about it anymore. I mean, we're here, at something that the CNCF is part of the Linux Foundation, which is great. But how often do people really focus on the Linux kernel these days? It is so boring, so solid, there's new stuff going on, but clearly, all the exciting stuff all the action, all the innovation is happening at higher layers. I think we're going to see something similar happen with Kubernetes over time. >> Yeah, that being said the reach of Kubernetes is further than ever. I was talking to this special interest group looking at edge computing and IoT people making the micro-cage version of this stuff when the team first got together, I mean, is you must look at and said there were many fathers, many parents of this solution, but, could you imagine the kind of the family and ecosystem that would have grown out of it? >> I think we knew that it could go there I mean, Google had some experience with this, I mean When Google bought YouTube, they had a problem where they had to essentially build out something that looked a little bit like a CDN. And so there were some examples of sort of like, how does technology, like Boar, adapt to an Edge type of situation. So, there was some experience to borrow we definitely knew that we wanted this thing to scale up and down. But I think that's a hallmark of these successful technologies is that they can be used in ways and in places that you really never thought about when you got started. So that's definitely true. >> Alright, Joe, want to give you the final word the contributors, the users, the ecosystem community, what do you say with five years of Kubernetes now in the books? >> I just want to send a huge thank you to everybody who made it happen. This is, it was started by Google it was started by a few of us early on. But, we really want to make it so that everybody feels like it's theirs. A lot of times Brendan Burns and me and Kelsey wrote a book together and I'll do signing and a lot of times I'll sign that and I'll say thank you for being a part of Kubernetes. Because I really feel like every user everybody who bets on it, everybody who shares their knowledge, they're really a big part of it. And so thank you to everybody who's a big part of Kubernetes. >> All right, well, Joe, thank you as always for sharing your knowledge with our community >> Thank you so much. >> We've been happy to be a small part in helping to spread the knowledge and everything going on here, so congratulations to the community on five years of Kubernetes and we'll be back with more coverage here from KubeCon + CloudNativeCon 2019. I'm Stu Miniman and thanks for watching theCUBE. (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 at KubeCon CloudNativeCon 2019 in Barcelona, Spain. I'm Stu Miniman. My co-host is Corey Quinn and we're thrilled to welcome to the program two gentlemen from CERN. Of course, CERN needs no introduction. We're going to talk some science, going to talk some tech. To my right here is Ricardo Rocha, who is the computer engineer, and Lukas Heinrich, who's a physicist. So Lukas, let's start with you, you know, if you were a traditional enterprise, we'd talk about your business, but talk about your projects, your applications. What piece of, you know, fantastic science is your team working on? >> All right, so I work on an experiment that is situated with the Large Hadron Collider, so it's a particle accelerator experiments where we accelerate protons, which are hydrogen nuclei, to a very high energy, so that they almost go with the speed of light. And so, we have a large tunnel underground, 100 meters underground in Geneva, so straddling the border of France and Switzerland. And there, we're accelerating two beams. One is going clockwise. The other one is going counterclockwise, and there, we collide them. And so, I work on an experiment that kind of looks at these collisions and then analyzes this data. >> Lukas, if I can, you know, when you talk to most companies, you talk about scale, you talk about latency, you talk about performance. Those have real-world implications for your world. Do you have anything you could share there? >> Yeah, so, one of the main things that we need to do, so we collide 40 million times a second these protons, and we need to analyze them in real time, because we cannot write out all the collision data to disk because we don't have enough disk space, and so we've essentially run 10,000 core real-time application to analyze this data in real-time and see what collisions are actually most interesting, and then only those get written out to disk, so this is a system that I work on called The Trigger, and yeah, that's pretty dependent on latency. >> All right, Ricardo, luckily you know, your job's easy. We say most people you need to respond, you know, to what the business needs for you and, you know, don't worry, you can't go against the laws of physics. Well, you're working on physics here, and boy those are some hefty requirements there. Talk a little bit about that dynamic and how your team has to deal with some pretty tough challenges. >> Right, so, as Lukas was saying, we have this large amount of data. The machines can generate something around the order of a petabyte a second, and then, thanks to their hardware- and software-level triggers, they will reduce this to something that is 10 gigabytes a second, and that's what my side has to handle. So, it's still a lot of data. We are collecting something like 70 petabytes a year, and we keep adding, so right now we have, the amount of storage available is on the order of 400 petabytes. We're starting to get at a pretty large scale. And then we have to analyze all of this. So we have one big data center at CERN, which is 300,000 cores, or something like this, around that, but that's not enough, so what we've done over the last 15, 20 years, we've created this large distributed computing environment around the world. We link to many different institutes and research labs together, and this doubles our capacity. So that's our challenge, is to make sure all the effort that the physicists put into building this large machine, that, in the end, it's not the computing that is breaking the world system. We have to keep up, yup. >> One thing that I always find fascinating is people who are dealing with real problems that push our conception of what scale starts to look like, and when you're talking about things like a petabyte a second, that's beyond the comprehension of what most of us can wind up talking about. One problem that I've seen historically with a number of different infrastructure approaches is it requires a fair level of complexity to go from this problem to this problem to this problem, and you have to wind up working through a bunch of layers of abstraction, and the end result is, and at the end of all of this we can run our blog that gets eight visits a day, and that just doesn't seem to make sense. Whereas what you're talking about, that level of complexity is more than justified. So my question for you is, as you start seeing these things evolve and looking at other best practices and guidance from folks who are doing far less data-intensive applications, are you seeing that a lot of the best practices start to fall down as you're pushing theoretical boundaries of scale? >> Right, that's actually a good point. Like, the physicists are very good at getting things done, and they don't worry that much about the process, as long as in the end it works. But there's always this kind of split between the physicists and the more computing engineer where the practices, we want to establish practices, but at the end of the day, we have a large machine that has to work, so sometimes we skip a couple of steps, but we still need, there's still quite a lot of control on like data quality and the software validation and all of this. But yeah, it's a non-traditional environment in terms of IT, I would say. It's much more fast pacing than most traditional companies. >> You mentioned you had how many cores working on these problems on site? >> So in-house, we have 300,000. >> If you were to do a full migration to the public cloud, you'd almost have to repurpose that many cores just to calculating out the bill at that point. Just, because all the different dimensions, everything winds working on at that scale becomes almost completely non-trivial. I don't often say that I'm not sure public cloud can scale to the level that someone would need to. In your case, that becomes a very real concern. >> Yeah, so that's one debate we are having now, and it's, it has a lot of advantages to have the computing in-house, and also because we pretty much use it 24/7, it's a very different type of workload. So we need a lot of resources 24/7, like even the pricing is kind of calculated differently. But the issue we have now is that the accelerator will go through a major upgrade just in five years' time, where we will increase the amount of data by 100 times. Now we are talking about 70 petabytes a year and we're very soon talking about like exabytes. So the amount of computing we'll need there is just going to explode, so we need all the options. We're looking into GPUs and machine learning to change how we do computing, and we are looking at any kind of additional resources we might get, and there the public cloud will probably play a role. >> Could you speak to kind of the dynamic of how something like an upgrade of that, you know, how do you work together? I can't imagine that you just say, "Well, we built it, "whatever we needed and everything, and, you know, "throw it over the wall and make sure it works." >> Right, I mean, so I work a lot on this boundary between computing and physics, and so internally, I think we also go through the same processes as a lot of companies, that we're trying to educate people on the physics side how to go through the best practices, because it's also important. So one thing I stressed also in the keynote is this idea of reproducibility and reusability of scientific software is pretty important, so we teach people to containerize their applications and then make them reusable and stuff like that, yup. >> Anything about that relationship you can expound on? >> Yeah, so like this keynote we had yesterday is a perfect example of how this is improving a lot at CERN. We were actually using data from CMS, which was one of the experiments. Lukas is a physicist in ATLAS, which is like a computing experiment, kind of. I'm in IT, and like all this containerized infrastructure kind of is getting us all together because computing is getting much easier in terms of how to share pieces of software and even infrastructure, and this helps us a lot internally also. >> So what particular about Kubernetes helps your environment? You talk for 15 years that you've been on this distributed systems build-out, so sounds like you were the hipsters when it came to some of these solutions we're working on today. >> That has been like a major change. Lukas mentioned the container part for the software reproducibility, but I have been working on the infrastructure for, I joined CERN as a student and I've been working on the distributed infrastructure for many years, and we basically had to write our own tools, like storage systems, all the batch systems, over the years, and suddenly with this public cloud explosion and open source usage, we can just go and join communities that have requirements sometimes that are higher than ours and we can focus really on the application development. If we base, if we start writing software using Kubernetes, then not only we get this flexibility of choosing different public clouds or different infrastructures, but also we don't have to care so much about the core infrastructure, all the monitoring, log collection, restarting. Kubernetes is very important for us in this respect. We kind of remove a lot of the software we were depending on for many years. >> So these days, as you look at this build-out and what you're looking, not just what you're doing today but what you're looking to build in the upcoming years, are you viewing containers as the fundamental primitive of what empowers this? Are you looking at virtual machines as that primitive? Are you looking at functions? Where exactly do you draw the abstraction layer, as you start building this architecture? >> So, yeah, traditionally we've been using virtual machines for like the last maybe 10 years almost, or, I don't know, eight years at least, and we see containerization happening very quickly, and maybe Lukas can say a bit more about the physics, how this is important on the physics side? >> Yeah, what's been, so currently I think we are looking at containers for the main abstraction because it's also we go through things like functions as a service. What's kind of special about scientific applications is that we don't usually just have our entire code base on one software stack, right? It's not like we would deploy Node.js application or Python stack and that's it. And so, sometimes you have a complete mix between C++, Python, Fortran, and all that stuff. So this idea that we can build the entire software stack as we want it is pretty important. So even for functions as a service where, traditionally, you had just a limited choice of runtimes, this becomes important. >> Like, from our side, the virtual machines still had a very complex setup to be able to support all this diversity of software and the containerization, just all the people have to give us is like run this building block and it's kind of a standard interface, so we only have to build the infrastructure to be able to handle these pieces. >> Well, I don't think anyone can dispute that you folks are experts in taking larger things and breaking them down into constituent components thereof. I mean, you are, quite obviously, the leading world experts on that. But was there any challenge to you as you went through that process of, I don't necessarily even want to say modernizing, but in changing your viewpoint of those primitives as you've evolved, have you seen that there were challenges in gaining buy-in throughout the organization? Was there pushback? Was it culturally painful to wind up moving away from the virtual machine approach into a containerized world? >> Right, so yeah, a bit, of course. But traditionally we, like physicists really focus on their end goal. We often say that we don't count how many cores or whatever, we care about events per second, how many events we can process per second. So, it's a kind of more open-minded community maybe than traditional IT, so we don't care so much about which technology we use at some point, as long as the job gets done. So, yeah, there's a bit of traction sometimes, but there's also a push when you can demonstrate that we get a clear benefit, then it's kind of easier to push it. >> What's a little bit special maybe also for particle physics is that it's not only CERN that is the researcher. We are an international collaboration of many, many institutes all around the world that work on the same project, which is just hosted at CERN, and so it's a very flat hierarchy and people do have the freedom to try out things and so it's not like we have a top-down mandate what technology we use. And then somebody tries something out. If it works and people see a value in it then you get adoption from it. >> The collaboration with the data volumes you're talking about as well has got to be intense. I think you're a little bit beyond the, okay, we ran the experiment, we put the data in Dropbox, go ahead and download it, you'll get that in only 18 short years. It seems like there's absolutely a challenge in that. >> That was one of the key points actually in the keynote is that, so a lot of the experiments at CERN have an open data policy where we release our data, and so that's great because we think it's important for open science, but it was always a bit of an issue, like who can actually practically analyze this data for people who don't have a data center? And so one part of the keynote was that we could demonstrate that using Kubernetes and public cloud infrastructure actually becomes possible for people who don't work at CERN to analyze this large-scale scientific data sets. >> Yeah, I mean maybe just for our audience, the punchline is rediscovering the Higgs boson in the public cloud. Maybe just give our audience a little bit of taste of that. >> Right, yeah, so basically what we did is, so the Higgs boson was discovered in 2012 by both ATLAS and CMS, and a part of that data, we used open data from CMS and part of that data has now been released publicly, and basically this was a 70-terabyte data set which we, thanks to our Google Cloud partners, could put onto public cloud infrastructure and then we analyzed it on a large-scale Kubernetes cluster, and-- >> The main challenge there was that, like, we publish it and we say you probably need a month to process it, but we had like 20 minutes on the keynote, so we kind of needed a bit larger infrastructure than usual to run it down to five minutes or less. In the end, it all worked out, but that was a bit of a challenge. >> How are you approaching, I guess, making this more accessible to more people? By which I mean, not just other research institutions scattered around the world, but students, individual students, sometimes in emerging economies, where they don't have access to the kinds of resources that many of us take for granted, particularly work for a prestigious research institutions? What are you doing to make this more accessible to high school kids, for example, folks who are just dipping their toes into a world they find fascinating? >> We have entire programs, outreach programs that go to high schools. I've been doing this when I was a student in Germany. We would go to high schools and we would host workshops and people would analyze a lot of this data themselves on their computers. So we would come with a USB stick that have data on them, and they could analyze it. And so part of also the open data strategy from ATLAS is to use that open data for educational purposes. And then there are also programs in emerging countries. >> Lukas and Ricardo, really appreciate you sharing the open data, open science mission that you have with our audience. Thank you so much for joining us. >> Thank you. >> Thank you. >> All right, for Corey Quinn, I'm Stu Miniman. We're in day two of two days live coverage here at KubeCon + CloudNativeCon 2019. Thank you for watching theCUBE. (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 coverage here at KubeCon + CloudNativeCon. I'm Stu Miniman, my co-host is Corey Quinn. And happy to welcome back to the program Mark Shuttleworth who os the CEO of Canonical. Of course, the orange shirts of Ubuntu, are seen all throughout the show. Mark, thank you so much for joining us, great so see you. >> Great to see you. >> All right, so for years, actually, we've had these conversations at the OpenStack Summit. It's interesting that, every time you mention it around this show you get snark online, as like, it is dead, Kubernetes killed it and it's like wait, no, no, you know we're talking about, a couple of open-source projects. I've been talking to people, especially in the telco space, that's like, oh yeah, well no, we just run OpenStack underneath and Kubernetes on top and put all things together. Give us a little bit of your broad view of some of these big trends, and open-source monoliths and microservices and all these pieces, all kind of fly together. >> Yeah, I think if your in the Reddit SubChannels, then you know it can feel a bit like turf war, and gangster-type, free software riffing, right. But the reality is, OpenStack solves business problems for people. They want large scale, virtualized infrastructure, that's cheaper than VMware. We are deploying OpenStacks in enterprise environments at double the scale and double the speed, in other words, like twice as many every month, as we were a year ago. I think people have gotten comfortable with the idea that Kubernetes is an application operations construct. I think we will see virtualization blur into the Kubernetes lives, but mainly for security reasons. So I want deeper isolation of applications that come from third-party vendors, for example. And I'm willing to trade performance for isolation, in circumstances where I am bringing in third-party code into my private infrastructure. After we see a couple of significant security compromises, I mean, we saw the GitHub compromise. If you shave that Yak, it gets to a very uncomfortable place of, what are we actually running as root all over our data centers with Docker and Docker Hub. So, people are going to want that kind of isolation of containers, the Kata Containers work is going to bring that. But that's very different to the proposition of, essentially, give me large scale, machine virtualization which OpenStack addresses. OpenStack hasn't done itself any favors, don't need to go into that here. But nonetheless, as far as we're concerned, it's straight forward to deliver large scale, low cost, enterprise virtualization infrastructure for telco's or IT use cases. >> Let's get into this ecosystem here. I want to say the Cloud Native ecosystem, and I say that specifically because there are some that look at this and they say, oh, there's dozens of projects now, Kubernetes is a platform against platform. Somebody even mentioned the word big tent once. We've seen some projects merging, we've seen some various pieces. >> I saw making a bigger tent on the keynote and I was like, not my favorite choice of words. >> I seem to remember a certain article that you wrote poking a whole in the big tent thing. What's the same, what's different? What's your take on this? Is it an ecosystem? Is it Kubernetes and friends, as Corey has liked to say here? What's your take? >> Look, I think we're still trying to figure out what are the appropriate labels to attach to this kind of forum, it is a forum, right. There is a tremendous amount of value attached to being here, to the ideas that are getting bounced about. But I wouldn't call it a simple community in the sort of, traditional open-source sense. The reality is there's very serious money behind every, sort of project that's been framed as a community project. This is a new kind of consortium. And that brings with it certain, delicate, political posturing and so on. But, nonetheless, it's a valuable place to be. It's definitely staking out important concepts and operational platforms, ideas, regimes, whatever you want to call it. This is going to be a fun week. >> I started off my career in the Linux world as a grumpy Unix administrator because there really wasn't any other kind. Then I started dipping my toes into the Linux world and something struck me, almost immediately, about Ubuntu. Was how welcoming everyone was in the community. There was no such thing as a stupid question. I asked the kind of questions you would expect from someone working on a computer, wearing a suit. People were very eager to embrace newcomers into that. It was one of the absolute best things that I saw coming out of Canonical, in addition to the software itself. I love that you're here as a part of this. What is the larger picture? What do you see in the Cloud Native ecosystem that's resonating with what Canonical's doing? >> So, the big thing that we do is, essentially, try to figure out where, what's possible with open-source that's hard to do. And then make it really straight forward so that more people can do the important stuff easily. That doesn't stop people from doing all the crazy stuff at the periphery that you can do with Ubuntu. It's generally easier with Ubuntu than any other platform. But we try to make the really most important things really easy for everybody. That's the first thing. The second thing is, we're a little non-judgemental about the fact that there are different perspectives on the same stuff. In the Ubuntu ecosystem, we make a point of saying that GNOME guys, and the KDE guys, and the LXQt, and the MATE guys. The Ubuntu ecosystem is where they actually meet to hash out how they can do stuff in a way that means users get a real choice between those. There's a very similar role for us to play in an environment like this. It's kind of acronym soup out there. Like 50 new projects every KubeCon. They're all interesting, they're all important, there's a lot of overlap between them. There's work for us to do in figuring out which ones are going to be really more important in the tent. We did that very effectively with OpenStack. The people who rode the OpenStack wave with us haven't had to abandon their OpenStacks. Because the stuff that we really chose to make central and easy, turned out to be the stuff that was the important poles in the tent. And we'll do exactly the same stuff here with Kubernetes. So, to put that into context, it's been real fun to be on the booth. We had, just tons, of people coming up and saying thank you for Microk8s. Microk8s is a single package of Kubernetes, that works in lots Linux distributions. It gives you, in about a minute, it gives you a standard Kubernetes environment, that's pure upstream. That, for a developer, just let's you get productive immediately. Figure out these new development application operations, constructs. You can use it on an airplane, you can use it on a train. Of course, it's compatible with all of the public clouds so that's the second thing that we're doing. We work with Amazon, with the EKS team, I spoke at their event on Monday. We work with Azure, the AKS team, we work with Google, we work with Oracle, we work with IBM. Essentially making sure that all of them offer Ubuntu worker nodes for their Kubernetes, SaaS offerings. That means that the developer who's doing stuff on their workstation with Microk8s can take those containers straight to any other public clouds. So, we're not trying to force people to use a particular solution, we're saying, in all of those environments, there are going to be choices people have. We want to make that as easy as possible for them. We want to avoid unnecessary friction in that process. That kind of underlining culture is coming through in this forum, as well. >> We've had many conversations about how you've always tried to make the job of that developer really easy. One of the things we always look at on this show is how much of it is the infrastructure people, or the platform underneath and the developer, and how much are they coming together. Anything different about this ecosystem? >> Very much so, yeah. >> Or your customers here that you can share? >> Kubernetes is an application construct. You can think of it as a next generation message bus. It's how components of an application find each other, communicate with each other, essentially, coordinate with each other. That makes it very tightly woven in to the developer experience. By contrast, you can be sitting writing a Java application inside a bank and not know or care whether it's going to be running on a physical machine, a virtual machine or an OpenStack cloud. You just don't know, you don't care. It's too far away from the application. Kubernetes is right there. I think that's one of the really interesting things is that it's bringing those infrastructure brains together with the application, app dev brains, in a very interesting way. It's going to be challenging. I wouldn't underestimate it, there are a lot of people, sort of, wondering around here, feeling a little confused, but that's okay. Do you know what I mean, the stuff shakes out. >> So, something that's been a recurring theme here has been the idea of going in a multi-cloud direction. Where people are talking about wanting to build workloads that they can seamlessly deploy across different providers. People talk about that, periodically, as a strategic goal but I'm not seeing people do it very often in the real world. You're in a much better position than a lot of us, to see that. Is that something you're seeing people moving towards as an adoption? >> Well, yes. Because we work with all of the major public clouds to optimize Ubuntu there, in a way that I don't think any other Linux does. You get an optimized Amazon Ubuntu on Amazon. You get an optimized Azure Ubuntu on Azure, and so on. >> Going very deep in the Amazon ecosystem. Most of my customers are using Ubuntu far ahead of anything else out there. >> That's right. >> And it's the right answer for what they're doing. >> That's right. It gives them, essentially, the best of what Amazon's offering, it still gives them the ability to feel like if they want to go somewhere else, they can. And that actually works well for Amazon. In the early days, I think there was a little tension between us and the cloud guys, because they were saying, look, if people use Ubuntu then they can go somewhere else. Yes, but in a sense, that makes them more likely to be more relaxed about starting wherever they choose to start. We don't advise enterprises as to which cloud to use. We advise them to engage with those clouds and figure out their differences, they are different. Amazon's really good at some things that are different, to what Microsoft is good at. Oracle is really good at some things which are different too. And what we're starting to see is the level of maturity in the enterprise governance process. They know they want to work with multiple clouds. They initially thought that was a straight kind of commodity exchange, competition thing. They now realize that it's a bit richer than that. That there are actually business reasons to have deeper relationships with particular clouds, based on what those clouds are prioritizing, and what they are prioritizing. So, we're not going to say you should use this cloud, you should use that cloud. Obviously, we can draw a distinction between the clouds where we're deeply engaged and the clouds where, you know, where you just don't have the benefit of that. But, more importantly we can say, you know, here are the set of practices that you can adopt internally that will give you comfort that your getting the best out of those clouds, the ones that you've chosen. And you have the portability that you really need. The key turns out be, enabling your developers, to use multiple clouds and challenging the developers to do different phases of the development life cycle on different clouds. Develop on your private cloud or your work station, use Microk8s, for example. Do tests on one cloud. Do staging and production on a different cloud. Now you already know that that whole, seamless ecosystem works. If you want to go use a high value, proprietary function, effectively on a cloud, that's a business decision and it's not a bad business decision. There's some spectacular capabilities from Amazon that are unique to Amazon. Or from Microsoft that are unique, or from Oracle that are unique to Oracle. They're spectacular. Those are business decisions to use them. There's other stuff that effectively you can give yourself optionality on. I wouldn't be black and white about that, put yourself in a position to make smart choices. And our best customers are getting are getting there. PayPal, they're operating on Ubuntu in a very sophisticated way, across multiple public clouds and private infrastructure. >> All right, so Mark we're five years into Kubernetes now. We've seen adoption grow, people feel there's a certain level of maturity here. There's always that concern that we've reached that peak and we're about to fall off the cliff. What do we need to worry about? What does the ecosystem need to do to make sure we continue along the stability and security that customers are looking for. >> There will be an over shoot regardless. I don't think there's any sort of leadership or governance approach that could avoid that. It's a little bit like, if your stock is going crazy. On the one hand, you're kind of happy. On the other hand, if you feel it's over valued it's a difficult sort of thing to say. You need to say, guys, you know what I mean, we're humans too. We've got our challenges to work through. And no one likes volatility, but too a certain extent, there's always speculation and over shoot, and over-enthusiasm, and hype. Kubernetes will over shoot. There's a bunch of emperors walking around here that, frankly, have no clothes. My job, our job, is very calmly, to sort through the wheat from the chaff. Make sure that it's possible for people to experiment with everything. But, that the stuff that we think has legs, effectively, is nicely integrated for people, that they have that for the long term, they won't regret things. We have a good track record of doing that. We've done it in the Linux desktop. We did it in OpenStack, we're doing it in public cloud. We've done it here in the Cloud Native world. I'd say things like AI are going in the same direction. Again, tons of complexity, tons of new options. Helping people effectively navigate through that is what we do very well. >> Yeah, one of the questions that I started to see as well, as we look at the way that these technologies continue to evolve, has been that, for better or worse, when developers are writing applications now and even infrastructure people are working with a lot of the things they care about. What operating system, let alone what distribution they're using, is increasingly slipping beneath the waves. People don't think about that as a primary area of focus anymore. And as, I guess, of the foundational Linux vendors in this space, how are you seeing that evolving? And how does Canonical remain relevant in a world where suddenly, people in a serverless future, I just throw some code over somewhere else and it runs is the limit of where most companies get involved. >> Yes, of course, we can point to the servers. And on the servers, we can point to the operating systems and inside the containers, we can point to the operating systems and underneath the serverless code, we can point to the language runtimes. So, the reality is that those things matter less and less to the developer. >> Yes. >> They still matter to the institution. So, I'm super comfortable with the language that says, the OS doesn't matter. What it means is that that whole tangle is getting professionalized and abstracted. But to be confident in the abstractions, someone needs to do a lot of work. I know how much work we do with Google, with Amazon, with Microsoft, with Oracle, with IBM, to make sure that nobody else has to feel like the OS matters. That that stuff essentially just works. You can extend that out to what we do with VMware, what we do, essentially, on bare-metal, what we do on developer workstations, what we do with the Windows crowd, effectively, and Windows subsystem for Linux, so that developers really can just build on Windows subsystem for Linux, Ubuntu, effectively, and ship that container straight to Amazon EKS and have it just work. There are a ton of little lies that have to line up. Containers are all kind of a fiction. The fiction breaks if those pieces don't line up. So, being Ubuntu, effectively and being being able to be consistent in all of those places, is a ton of work to enable it not to matter for anybody upstairs. That's allowing developers to go faster. It's allowing them to be more productive. It's allowing them to be more heroic. And it's allowing the people who do worry about the middleware to have far fewer nights scratching their heads as to, why didn't this version of this library tie up to that driver with that kernel. All of those things are still there. When you drop that container onto Amazon, we've got to connect the GPGPU in the hardware, through the hypervisor, to the guest OS, up into the container. And there's code getting injected all the way up. It's only the fact that we can typically have Ubuntu everywhere there that, essentially, allows those pieces to line up without some spectacular fireworks. It satisfies me when people say they don't have to worry about that. >> It's a victory condition. >> Mark, I want to give you the final word. What should we be looking for, from Canonical, through the rest of the year? >> So, for us, this has been a big year in terms of visibility in the enterprise. In terms of penetration, Ubuntu's everywhere in the Fortune 500, everywhere in the Global 2000. What's changed this year, is the CIO suddenly is seeing Ubuntu on their desk. For two reasons, one is IBM Red Hat. The CIO suddenly wants to know, okay, what does this mean? What else are we running? Where else can we get 24/7 SLAs? Where else can we get long term commitments to Linux and so on? And the fact is Ubuntu's already in the building so that's one, sort of, easy connect. The other thing is, there's really interesting, new workloads that Ubuntu leads in the enterprise. Obviously the container story, the multi-cloud story, edge. It's not just telcos. Every retailer, every logistics company, anybody that has physical distribution is now trying to say, well how can I automate compute in my physical world, effectively. So, edge is super interesting and IoT beyond that. People transforming businesses through taking a Raspberry Pi with Ubuntu and putting a snap on it is really, really cool. Which of those is going to drive the biggest headlines or the scariest headlines, I can't tell you. We're just trying to take care of security, performance and operations across all of them. >> All right, well, Mark Shuttleworth, always a pleasure to catch up, thank you so much for the updates. >> Great to see you. >> All right, for Corey Quinn, I'm Stu Miniman. We'll be back with lots more coverage here from KubeCon + CloudNativeCon 2019 in Barcelona, Spain. Thanks for watching theCUBE. (upbeat music)

>> Live from Barcelona, Spain, it's theCUBE! Covering KubeCon and CloudNativeCon Europe 2019. Brought to you by Red Hat, the Cloud Native Computing Foundation, and ecosystem partners. >> Welcome back. This is theCUBE's live coverage of KubeCon, CloudNativeCon 2019 here in Barcelona, Spain. 7,700 here in attendance, here about all the Cloud Native technologies. I'm Stu Miniman; my cohost to the two days of coverage is Corey Quinn. And to help us break down what's happening in this ecosystem, we've brought in Jason Bloomberg, who's the president at Intellyx. Jason, thanks so much for joining us. >> It's great to be here. >> All right. There's probably some things in the keynote I want to talk about, but I also want to get your general impression of the show and beyond the show, just the ecosystem here. Brian Liles came out this morning. He did not sing or rap for us this morning like he did yesterday. He did remind us that the dinners in Barcelona meant that people were a little late coming in here because, even once you've got through all of your rounds of tapas and everything like that, getting that final check might take a little while. They did eventually filter in, though. Always a fun city here in Barcelona. I found some interesting pieces. Always love some customer studies. Conde Nast talking about what they've done with their digital imprint. CERN, who we're going to have on this program. As a science lover, you want to geek out as to how they're finding the Higgs boson and how things like Kubernetes are helping them there. And digging into things like storage, which I worked at a storage company for 10 years. So, understanding that storage is hard. Well, yeah. When containers came out, I was like, "Oh, god, we just fixed it for virtualization, "and it took us a decade. "How are we going to do it this time?" And they actually quoted a crowd chat that we had in our community. Tim Hawken, of course one of the first Kubernetes guys, was in on that. And we're going to have Tim on this afternoon, too. So, just to set a little context there. Jason, what's your impressions of the show? Anything that has changed in your mind from when you came in here to today? Let's get into it from there. >> Well, this is my second KubeCon. The first one I went to was in Seattle in December. What's interesting from a big picture is really how quickly and broadly KubeCon has been adopted in the enterprise. It's still, in the broader scheme of things, relatively new, but it's really taking its place as the only container orchestrator anybody cares about. It sort of squashed the 20-or-so alternative container orchestrators that had a brief day in the sun. And furthermore, large enterprises are rapidly adopting it. It's remarkable how many of them have adopted it and how broadly, how large the deployment. The Conde Nast example was one. But there are quite a number. So we turned the corner, even though it's relatively immature technology. That's the interesting story as well, that there's still pieces missing. It's sort of like flying an airplane while you're still assembling it, which makes it that much more exciting. >> Yeah, one of the things that has excited me over the last 10 years in tech is how fast it takes me to go from ideation to production, has been shrinking. Big data was: "Let's take the thing that used to take five years "and get it down to 18 months." We all remember ERP deployments and how much money and people you need to throw at that. >> It still takes a lot of money and people. >> Right, because it's ERP. I was talking to one of the booths here, and they were doing an informal poll of, "How many of you are going to have Kubernetes "in production in the next six months?" Not testing it, but in production in the next six months, and it was more than half of the people were going to be ramping it up in that kind of environment. Anything architecturally? What's intriguing you? What's the area that you're digging down to? We know that we are not fully mature, and even though we're in production and huge growth, there's still plenty of work to do. >> An interesting thing about the audience here is it's primarily infrastructure engineers. And the show is aimed at the infrastructure engineers, so it's technical. It's focused on people who code for a living at the infrastructure level, not at the application level. So you have that overall context, and what you end up having, then, is a lot of discussions about the various components. "Here's how we do storage." "Here's how we do this, here's how we do that." And it's all these pieces that people now have to assemble, as opposed to thinking of it overall, from the broader context, which is where I like writing about, in terms of the bigger picture. So the bigger picture is really that Cloud Native, broadly speaking, is a new architectural paradigm. It's more than just an architectural trend. It's set of trends that really change the way we think about architecture. >> One interesting piece about Kubernetes, as well. One of the things we're seeing as we see Kubernetes start to expand out is, unlike serverless, it doesn't necessarily require the same level of, oh, just take everything you've done and spend 18 months rewriting it from scratch, and then it works in this new paradigm in a better way. It's much less of a painful conversion process. We saw in the keynote today that they took WebLogic, of all things, and dropped that into Kubernetes. If you can do it with something as challenging, in some respects, and as monolithic as WebLogic, then almost any other stack you're going to see winds up making some sense. >> Right, you mentioned serverless in contrast with Kubernetes, but actually, serverless is part of this Cloud Native paradigm as well. So it's broader than Kubernetes, although Kubernetes has established itself as the container orchestration platform of choice. But it's really an overall story about how we can leverage the best practices we've learned from cloud computing across the entire enterprise IT landscape, both in the cloud and on premises. And Kubernetes is driving this in large part, but it's bigger picture than the technology itself. That's what's so interesting, because it's so transformative, but people here are thinking about trees, not the forest. >> It's an interesting thing you say there, and I'm curious if you can help our community, Because they look at this, and they're like, "Kubernetes, Kubernetes, Kubernetes." Well, a bunch of the things sit on Kubernetes. As they've tried to say, it's a platform of platforms. It's not the piece. Many of the things can be with Kubernetes but don't have to be. So, the whole observability piece. We heard the merging of the OpenCensus, OpenTracing with OpenTelemetry. You don't have to have Kubernetes for that to be a piece of it. It can be serverless underneath it. It can be all these other pieces. Cloud Native architecture sits on top of it. So when you say Cloud Native architecture, what defines that? What are the pieces? How do I have to do it? Is it just, I have to have meditated properly and had a certain sense of being? What do we have to do to be Cloud Native? >> Well, an interesting way of looking at it is: What we have subtracted from the equation, so what is intentionally missing. Cloud Native is stateless, it is codeless, and it is trustless. Now, not to say that we don't have ways of dealing with state, and of course there's still plenty of code, and we still need trust. But those are architectural principals that really percolate through everything we do. So containers are inherently stateless; they're ephemeral. Kubernetes deals with ephemeral resources that come and go as needed. This is key part of how we achieve the scale we're looking for. So now we have to deal with state in a stateless environment, and we need to do that in a codeless way. By codeless, I mean declarative. Instead of saying, how are we going to do something? Let's write code for that, we're going to say, how are we going to do that? Let's write a configuration file, a YAML file, or some other declarative representation of what we want to do. And Kubernetes is driven this way. It's driven by configuration, which means that you don't need to fork it. You don't need to go in and monkey with the insides to do something with it. It's essentially configurable and extensible, as opposed to customizable. This is a new way of thinking about how to leverage open-source infrastructure software. In the past, it was open-source. Let's go in an monkey with the code, because that's one of the benefits of open-source. Nobody wants to do that now, because it's declaratively-driven, and it's configurable. >> Okay, I hear what you're saying, and I like what you're saying. But one of the things that people say here is everyone's a little bit different, and it is not one solution. There's lots of different paths, and that's what's causing a little bit of confusion as to which service mesh, or do I have a couple of pieces that overlap. And every deployment that I see of this is slightly different, so how do I have my cake and eat it, too? >> Well, you mentioned that Kubernetes is a platform of platforms, and there's little discussion of what we're actually doing with the Kubernetes here at the show. Occasionally, there's some talk about AI, and there's some talk about a few other things, but it's really up to the users of Kubernetes, who are now the development teams in the enterprises, to figure out what they want to do with it and, as such, figure out what capabilities they require. Depending upon what applications you're running and the business use cases, you may need certain things more than others. Because AI is very different from websites, it's very different from other things you might be running. So that's part of the benefit of a platform of platforms, is it's inherently configurable. You can pick and choose the capabilities you want without having to go into Kubernetes and fork it. We don't want 12 different Kubernetes that are incompatible with each other, but we're perfectly okay with different flavors that are all based on the same, fundamental, identical code base. >> We take a look at this entire conference, and it really comes across as, yes, it's KubeCon and CloudNativeCon. We look at the, I think, 36 projects that are now being managed by this. But if we look at the conversations of what's happening here, it's very clear that the focus of this show is Kubernetes and friends, where it tends to be taking the limelight of a lot of this. One of the challenges you start seeing as soon as you start moving up the stack, out through the rest of the stack, rather, and seeing what all of these Cloud Native technologies are is, increasingly, they're starting to be defined by what they aren't. I mean, you have the old saw of, serverless runs on servers, and other incredibly unhelpful sentiments. And we talk about what things aren't more so than we do what they are. And what about capabilities story? I don't have an answer for this. I think it's one of those areas where language is hard, and defining what these things are is incredibly difficult. But I see what you're saying. We absolutely are seeing a transformative moment. And one of the strangest things about it, to me at least, is the enthusiasm with which we're seeing large enterprises, that you don't generally think of as being particularly agile or fast-moving, are demonstrating otherwise. They're diving into this in fascinating ways. It's really been enlightening to have conversations for the last couple of days with companies that are embracing this new paradigm. >> Right. Well, in our perspective at Intellyx, we're focusing on digital transformation in the enterprise, which really means putting the customer first and having a customer-driven transformation of IT, as well as the organization itself. And it's hard to think in those terms, in customer-facing terms, when you're only talking about IT infrastructure. Be that as it may, it's still all customer-driven. And this is sometimes the missing piece, is how do we connect what we're doing on the infrastructure side with what customers require from these companies that are implementing it? Often, that missing piece centers on the workload. Because, from the infrastructure perspective, we have a notion of a workload, and we want workload portability. And portability is one of the key benefits of Kubernetes. It gives us a lot of flexibility in terms of scalability and deployment options, as well as resilience and other benefits. But the workload also represents the applications we're putting in front of our end users, whether they're employees or end customers. So that's they key piece that is like the keystone that ties the digital story, that is the customer-facing, technology-driven, technology-empowered story, with the IT infrastructure stories. How do we support the flexibility, scalability, resilience of the workloads that the business needs to meet its business goals? >> Yeah, I'm really glad you brought up that digital transformation piece, because I have two questions, and I want to make sure I'm allowing you to cover both of them. One is, the outcome we from people as well: "I need to be faster, and I need to be agile." But at the same point, which pieces should I, as an enterprise, really need to manage? Many of these pieces, shouldn't I just be able to consume it as a managed service? Because I don't need to worry about all of those pieces. The Google presentation this morning about storage was: You have two options. Path one is: we'll take care of all of that for you. Path two is: here's the level of turtles that you're going to go all the way down, and we all know how complicated storage is, and it's got to work. If I lose my state, if I lose my pieces there, I'm probably out of business or at least in really big trouble. The second piece on that, you talked about the application. And digital transformation. Speed's great and everything, but we've said at Wikibon that the thing that will differentiate the traditional companies and the digitally transformed is data will drive your business. You will have data, it will add value of business, and I don't feel that story has come out yet. Do you see that as the end result from this? And apologies for having two big, complex questions here for you. >> Well, data are core to the digital transformation story, and it's also an essential part of the Kubernetes story. Although, from the infrastructure perspective, we're really thinking more about compute than about data. But of course, everything boils down to the data. That is definitely always a key part of the story. And you're talking about the different options. You could run it yourself or run it as a managed service. This is a key part of the story as well, is that it's not about making a single choice. It's about having options, and this is part of the modern cloud storage. It's not just about, "Okay, we'll put everything in one public cloud." It's about having multiple public clouds, private clouds, on-premises virtualization, as well as legacy environments. This is what you call hybrid IT. Having an abstracted collection of environments that supports workload portability in order to meet the business needs for the infrastructure. And that workload portability, in the context of multiple clouds, that is becoming increasingly dependent on Kubernetes as an essential element of the infrastructure. So Kubernetes is not the be-all and end-all, but it's become an essentially necessary part of the infrastructure, to make this whole vision of hybrid IT and digital transformation work. >> For now. I mean, I maintain that, five years from now, no one is going to care about Kubernetes. And there's two ways that goes. Either it dries up, blows away, and something else replaces it, which I don't find likely, or, more likely, it slips beneath the surface of awareness for most people. >> I would agree, yeah. >> The same way that we're not sitting here, having an in-depth conversation about which distribution of Linux, or what Linux kernel or virtual memory manager we're working with. That stuff has all slipped under the surface, to the point where there are people who care tremendously about this, but you don't need to employ them at every company. And most companies don't even have to think about it. I think Kubernetes is heading that direction. >> Yeah, it looks like it. Obviously, things continue to evolve. Yeah, Linux is a good example. TCP/IP as well. I remember the network protocol wars of the early 90s, before the web came along, and it was, "Are we going to use Banyan VINES, "are we going to use NetWare?" Remember NetWare? "Or are we going to use TCP/IP or Token Ring?" Yeah! >> Thank you. >> We could use GDP, but I don't get it. >> Come on, KOBOL's coming back, we're going to bring back Token Ring, too. >> KOBOL never went away. Token Ring, though, it's long gone. >> I am disappointed in Corey, here, for not asking the question about portability. The concern we have, as you say: okay, I put Kubernetes in here because I want portability. Do I end up with least-common-denominator cloud? I'm making a decision that I'm not going to go deep on some of the pieces, because nice as the IPI lets things through, but we understand if I need to work across multiple environments, I'm usually making a trade-off there. What do you hear from customers? Are they aware that they're doing this? Is this a challenge for people, not getting the full benefit out of whichever primary or whichever clouds they are using? >> Well, portability is not just one thing. It's actually a set of capabilities, depending upon what you are trying to accomplish. So for instance, you may want to simply support backing up your workload, so you want to be able to move it from here to there, to back it up. Or you may want to leverage different public clouds, because different public clouds have different strengths. There may be some portability there. Or you may be doing cloud migration, where you're trying to move from on-premises to cloud, so it's kind of a one-time portability. So there could be a number of reasons why portability is important, and that could impact what it means to you, to move something from here to there. And why, how often you're going to do it, how important it is, whether it's a one-to-many kind of thing, or it's a one-to-one kind of thing. It really depends on what you're trying to accomplish. >> Jason, last thing real quick. What research do you see coming out of this? What follow-up? What should people be looking for from Intellyx in this space in the near future? >> Well, we continue to focus on hybrid IT, which include Kubernetes, as well as some of the interesting trends. One of the interesting stories is how Kubernetes is increasingly being deployed on the edge. And there's a very interesting story there with edge computing, because the telcos are, in large part, driving that, because of their 5G roll-outs. So we have this interesting confluence of disruptive trends. We have 5G, we have edge computing, we have Kubernetes, and it's also a key use case for OpenStack, as well. So it's like all of these interesting trends are converging to meet a new class of challenges. And AI is part of that story as well, because we want to run AI at the edge, as well. That's the sort of thing we do at Intellyx, is try to take multiple disruptive trends and show the big picture overall. And for my articles for SiliconANGLE, that's what I'm doing as well, so stay tuned for those. >> All right. Jason Bloomberg, thank you for helping us break down what we're doing in this environment. And as you said, actually, some people said OpenStack is dead. Look, it's alive and well in the Telco space and actually merging into a lot of these environments. Nothing ever dies in IT, and theCUBE always keeps rolling throughout all the shows. For Corey Quinn, I'm Stu Miniman. We have a full-packed day of interviews here, so be sure to stay with us. And thank you for watching theCUBE. (upbeat techno music)

>> Live, from Barcelona Spain, it's theCube! Covering, KubeCon CloudNativeCon Europe 2019: Brought to you by RedHat, the Cloud Native Computing Foundation and the Ecosystem Partners. >> Hi, and welcome back. this is theCube's coverage of KubeCon CloudNativeCon 2019 here in Barcelona, Spain. We're at the end of day one of two days of live, wall-to-wall coverage. I'm Stu Miniman, and at the end of the day, what we try to do always is do our independent analysis and say what we really think. And joining me is someone that usually has no problem telling you exactly what he thinks online. So, I've challenged Mr. Corey Quinn. Cloud economist, of the Duckbill Group. and the curator, author, Last Week in AWS. To tell us what he actually thinks. >> Well, Stu, you know what your problem is. All the best feedback starts off that way. Now, this has been a fascinating experience for me. This is the first time I've ever been to KubeCon. I didn't quite know what to expect- >> It's KubeCon, not Koob-Con. Come on. It is in GitHub, how you have to make the pronunciation correct. >> We are on theCube. We would think that we would be subject matter experts on this. >> CNCF will be cracking down on you if I don't correct you on this. >> I still maintain we're in Barcelona, Italy. But that's a whole separate argument to have with other people. >> Yes, well, most Americans are geographically challenged. And we understand you have some challenges too. >> Exactly, most Americans need to learn geography, we go to war. (chuckling) >> All right, so, Corey, I guess the first question for you is, you usually go to mostly AWS shows. Most of the customers we've talked to have been AWS customers. So is this feeling much different from the usual show you go to? >> The focus of the conversations is different, and to be clear, I'm not much of a cloud partisan myself. I deal with AWS primarily because, not for nothing, that's where my customers are. That tends to be exactly where the expensive problems tend to live. For better or worse. If that changes, so will I. >> So, you're saying yet that the other cloud providers don't have their customers big enough bills, or they just haven't figured out how you might be able to help them in the future? >> To be very honest with you. Yes, is the short answer. Right now on aggregate, my customers spend about a billion dollars a year on AWS. I don't see the same order of magnitude on other providers, but it's coming. It is very clearly coming. None of these providers are shrinking as far as size goes. It's largely a matter of time. >> Alright. But Corey, I hope at least you've understood that Kubernetes at the center for all things. And that multi-cloud is the way that we are today and will always be in the future. And we should all hold hands and sing along, that we all get along. Is that what you've learned so far? >> I think that's absolutely what I've learned so far. It comes down to religion and it's perfectly name for it. I mean, Kubernetes was the Greek God of spending money on cloud services. >> All right. But seriously. Corey, I think one of the things that I really liked is. We talk to customers and there were some interesting things at least I heard when you talked about they see huge value in what they're doing with Kubernetes. Many of them only have one cloud provider today. Yet they are choosing to lay on Kubernetes either with AWS or with another solution there. What's been your take of what you've heard about. Kind of the why and what they're doing? >> There've been a few different reasons on it. One that resonated with me did validate what I talked about at the beginning of the day. Which was, that by trying to position yourself to be strategically amenable to any potential provider you might want to use in the future. You are sacrificing velocity. And you're gaining agility, losing velocity to do that. Is that trade off worth it? I don't think I'm qualified to judge. I think that's a decision every business has to make on its own. My argument has always been that if that's the decision you make, do it knowingly. And I don't think we've talked to anyone who's made that unknowingly today. >> Yeah. I think that's a really good point. What is it, you know, surprised you or interest you that we've heard so far? >> I have to be honest. I have a long and storied history in open source. I was staff at the Freenode IRC network for about a decade. Which was an interesting time. And I've seen a lot of stuff, but I don't think I've ever seen two open source projects merge before. The fact that we saw that today is still swirling around in my head for better or worse. >> Yeah. And it was OpenCensus and OpenTracing coming together. Open Telemetry. So, definitely check out Ben Siegelman. and it was Morgan McLean from a Google cloud. You know, really interested in discussion. I don't think we're sharing too much when we say off camera. There were like, look, it's like, yes, they got us in a room and we worked, but we'll try not to throw punches here on the set and everything like that. We understand that look, there are people that put these things together and you have smart people that build things the way that it should be done. And these were not like two very similar projects going in the same direction, they were built with different design principles and therefore there'll be somethings that they all need to reconcile to be able to go forward. But yeah, very interesting. >> And everyone we spoke to today was very focused on what the needs of their customers, whoever they happen to be and how to meet those customers and their business requirements. There's no one that we spoke to that was sitting here saying, oh, this is the right answer because it is technically correct. The answer is we're always of the form. This is what we need to do in order to serve customers. And it's very hard to argue against that strategy. >> All right, but none of this really matters because Serverless, right Corey? >> Oh, absolutely. Serverless is the way and the light of the future and to some extent I believe that. >> But they're not doing Serverless. I'm pretty sure they're half a step behind you. Yes, it tends to be, it's easy to make go ahead and die and say, Oh, if you're not running the absolute latest bleeding edge thing, you're behind, you're backwards, etc. And I don't get that all the sense that that is reality. I think that there's, if you're building something greenfield today, you are fundamentally going to make different choices, than if you have something you're trying to carry forward. And I don't just mean carrying forward a technical sense. I mean carrying it forward in terms of process, in terms of culture, in terms of existing business units that need to modernize. People are moving in the same general direction. The question that I think is still on answered is, today, there's a perception rightly or wrongly, that Containers are slightly behind Serverless. I don't know that that necessarily holds true. I think that they are aligned towards the same business value. I think, judge either one of them by today's constraints in the context of longer term strategy is a mistake. I'm curious to see what happens. >> Corey, I love. So we had Jeff Brewer from Intuit and they were like look, we're doing Serverless, we're doing a lot of Containerless stuffs and I'd love it for my developer not to have to worry about. And they've had been moved down that path. So, we know one of the truisms out there is everything in IT is always additive. When you talk to them and say, oh, well I'm going into cloud wait, I still have some stuff that, running on my main frame or my eyes series. And that we'll probably be running there when I've retired. We were talking offline. It's like, well, there's been a little resurgence in COBOL. Just because it did not die after Y2K and so did these things always come back and it's always additive and the longer you've been in business as a company, the more legacy you need to be able to maintain and extend and connect to where you want to go with the future. >> It's almost a sawtooth curve. As complexity continues to rise it becomes to a point where it's untenable. There's something that comes out that abstracts that away and you're back down to a level a human being might actually be able to understand. And you take it a step further and you start to see it again and again and again, and then it collapses down. Docker and a lot of the handbuilt orchestration systems were like that. And then Kubernetes came out. Initially it was fairly simple and then things have been added to it now. And I think we're climbing that sawtooth curve again. Whether or not that maintains? Whether or not that simplifies again? I find that history rhymes particularly in tech. >> Well yeah and I always worry sometimes when you talk about the abstraction layer you got to be really careful what you're abstracting. What we see here a lot, is a lot of times it's people, how can I just consume that? I want to buy it as a service and somebody take care of that not, it hides the complexity for me but some of the complexity is still there. >> Right. So our site is now intermittently slow what do you plan to do? Its update my resume immediately cause we're never untangling that Gordian knot of an infrastructure. That's not a great answer but it is an honest one in some shops. >> I've talked to, we know that there was, for a long time people outsourced what they were doing. And we need to make sure that when you're buying something as a service that you haven't outsourced, That you understand what's important to your business, what happens when things go wrong. We had some discussion today about, networking and observability that we need to be able to go down that rabbit hole, at least turn to somebody who can. Because just because I can't touch that gear doesn't mean my next not on the line, If something goes wrong. >> You can outsource a lot of work. You can't outsource responsibility. I put slightly more succinctly, the line I've always liked was you own your own availability. If you have a provider that you've thrown a lot of these things over to and they go down, well sure you're going to have loud angry phone calls and maybe a few bucks back from an SLA credit. We your customers we're down and we're suffering. So the choices you made impact your businesses perception in the market and your customer's happiness. So as much as fun as it is to be able to throw things over the wall for someone else to deal with, you're still responsible. And I think that people forget that at their own peril. >> One of the things I like. I've got a long history in open source to. If there are things that aren't perfect or things that are maturing. A lot of times we're talking about them in public. Because there is a roadmap and people are working on it and we can all go to the repositories and see where people are complaining. So at a show like this, I feel like we do have some level of transparency and we can actually have realism here. What's been your experience so far? >> I think that people have been remarkably transparent about the challenges that they're facing in a way that you don't often get at a vendor show. Where you have a single vendor, you're at their show, regardless of who that might be. You're not going to be invited back if you wind up with a litany of people coming on a video show or a podcast or screaming and sobbing in the bathroom, however you want to, whatever your media is. Just have a litany of complaints the entire time or make that provider look bad. I don't sense that there's any of that pressure. And for some reason, and this is my first coop gone, so maybe this is just the way this culture it works. Everyone, regardless of who they worked for or what they're working on or what their experience has been, seems happy. I can only assume there's something in the water. >> All right. Well, I've just been informed that the CNCF had asked me to remove Corey because he refuses to say KubeCon. But, Corey. Since this might be your last time on the program, any other final words that you have for it or I will let you do something very rare and if you have any questions for me. Love on my way. >> Absolutely. What did you find today that you didn't expect to find? >> The one that jumps out for me really is two things. One, we discussed it already is the, the observability piece coming together. The other one is. You talk about that maturation of where Amazon fits in this ecosystem. And we had lovely conversation, with Abby fuller. But not just that one. We talked to the users and how they think about it. Which is what really matters is, there's so much talk about, who contributes more code and who does the most here. But look, we're talking cloud. Most of these customers are using AWS as if not the cloud, one of the clouds. I've set it on theCube many times. When you live in a hybrid and multi-cloud world and the public cloud, AWS is the far leader. There's no debating that. So they are participating here. They are doing plenty for what their customers want and they give choice and they listen to the feedback. So that was interesting to me that maturation of where that sits because when I come into the show and many times it is, it is the open source in this whole ecosystem, trying to prevent Amazon from taking over the world. And look, we want a good robust ecosystem out there. >> We absolutely do. >> While I have many friends that work for Amazon. We probably don't want to all be working for a single company down the road. >> I certainly don't. >> We like a nice robust ecosystem where there is choice out there and that keeps its (mumbles). So that maturation of where they are on has been interesting to me so far, especially from the user stand point. >> Very much so. I don't think that anyone wants to look back and say, wow, I'm sure glad we have only one option in this entire space that does anything useful. And then a whole bunch of could have the didn't. And for better or worse, I don't think that the future is nearly as clear cut as the past of cloud. Historically, AWS has been the 800 pound gorilla. I think that we hearing fascinating things from GCP and from Azure. I don't necessarily think that the future is preordained. I do think right now it is AWS game to lose, but I'm starting to see a lot of other players in his face start to make a lot of very interesting and arguably very correct moves. >> All right. Well, we know you as our audience have lots of places where you can turn to find your information and we are always pleased that when you turn to us to watch theCube. if you have any feedback for ourselves, Corey Quinn and myself, Stu Miniman. Reach out on Twitter. We are easy to reach on that. And we have lots of posts. So if you're like, Hey, tired of looking at this mug here. Let us know. But hopefully we're asking the questions and digging into the areas that you want and we'll help your businesses going forward. So we are at the end of day one, Two days live coverage here at KubeCon CloudNativeCon. This is the cube. You're a leader in live tech coverage. Thanks for watching. (music)

>> Live, from Barcelona, Spain, it's theCUBE, covering KubeCon CloudNativeCon Europe 2019. Brought to you by Red Hat, the CloudNative computing foundation and ecosystem partners. >> Welcome back to theCUBE here in Barcelona, Spain. It's KubeCon CloudNativeCon 2019, I'm Stu Miniman, and my cohost for two days wall-to-wall coverage is Corey Quinn. And we're always thrilled when we get to speak to a user, and not just any user but Fernando Alvarez, who is a cloud architect at X by Orange. Fernando, muchas gracias for joining us, Sir. >> It's a pleasure. >> So Orange, we are familiar and many people are. X by Orange though, maybe you could explain to our audience a little bit what this group is, inside of a large global brand. >> X by Orange is a subsidiary from Orange Spain, and from a Orange telecom group in France, and what we try to do is to reinvent the way that telco companies operates. Going more natural of a way than the traditional way. So it's more or less what we're trying to do, and we started operations in September of last year, just with a different proposal, to see if it could make it viable for the small and medium businesses in Spain. >> Yeah, so digital transformation, you know, many people talk about it, but I've had some really good conversations with customers in the last year or so. Data is so important to businesses these days. Being data-driven, and being software at the core of what you do. So, it's sometimes overstated that every company will be a software company some time in the future. But you have done these transformations before, and that's what brought you into X by Orange. So, tell us a little a bit, your role as a cloud architect, what's your mission and what's your role in the org? >> Well, my mission is to make all the different pieces inside the whole IT stack to work together, especially in a cloud environment. So from the designing from the whole ecosystem that supports the platform, and at the same time supports the whole company as a tech operator, or multiple tech operators. What my role is to make sure that everything fits together. We're trying to accomplish it and we're very happy to have it in a cloud environment, in public cloud and using Kubernetes, as our continuing orchestration engine. >> So, can you lay out are you in one public cloud? Many public clouds, data centers? What is your-- >> We are now in one public cloud in AWS but having this cloud orchestration layer allows us to move to, or to go multicloud or hybrid cloud as soon as we want to do it. But I think that we have to keep it simple from the beginning. Having a tight schedule to start operations is key to (stuttering) have our value proposal into the market and to do so we have to do it in a simple way so going first in one public cloud, going public cloud first because it's not a logical movement in a big company even though we are in Spain now but normally, big enterprises want to do in their own way in a private data center so what we want is to be very fast and to do so the election is clearly logical to go public cloud and to have an orchestration engine like Kubernetes to do everything, no? >> Do you find that making decisions that enable portability in the future if you want to move to alternate clouds or go hybrid, is in any way constraining what you're able to do or the speed you're able to innovate with? >> Yeah, but I think benefits are way better than the drawbacks of that. Normally every single decision you have to make about the architecture of NEPs, one of the key aspects is to see if it involves vendor blocking for any of the components on the stack for example in the public cloud. But I think it's worth the effort because most things that you can design as an engineer or as an architect can be solved not only using (stuttering) A specific solution from a specific cloud provider but using a more generic way. In this way then you can assure that you can move more or less easier to other cloud or to other infrastructure. >> All right, so I guess it begs the question, you said it's AWS today and Kubernetes, it's OpenShift yes? >> Yes. >> That is the, the Kubernetes platform? How did you come about choosing that and you know, obviously Red Hat, one of their strengths is working in lots of different environments so as you go to that hybrided multicloud was that the driver for them? Or were you a Red Hat customer? How did you end up with OpenShift? >> Yeah, that was one of the drivers. And the other was the support for the platform. We were in a really tight schedule and we knew Kubernetes well enough but we weren't sure if our knowledge were enough to be in operations in only nine months. So for that we get Red Hat on board, to have all their knowledge in terms of support and the professional services to help us to define how to do things with their platform on OpenShift and because OpenShift is like Kubernetes distribution we were sure enough that we share the Kubernetes way of doing things so that for us was a logical election. >> What was it that drove your move to the public cloud in the first place? And I guess your entire digital transformation by extension? >> Did you say what, sorry? >> What drove your entire decision to first go to the public cloud and secondly, to go I guess as part of your larger digital transformation? >> The main reason probably was the speed. At the beginning the whole company was started thinking that we were going to build our platform on a private cloud, but once we made the numbers and see that that needed one more year to start operations, with zero value to the customer, the decision was pretty easy. Let's go public cloud and let's think about this, if it really adds value in the future. >> All right. So Fernando if I heard you right you said nine months from you know, >> Yeah. >> when you went to deployment. Big companies aren't necessarily known for their speed of change. >> (laughing) Yeah. >> Talk a little bit about the organizational dynamics. How much internal ramp up there was versus relying on your partners and your vendors to be able to help you meet those schedules. >> The good news is that we had the full Orange support to start a new company and we started as a separate company recently because we wanted to be very fast. So instead of having all the processes from the big company to do something that maybe it will fail, or maybe it will affect the brand, we decided to start a new company from scratch, with Orange in its name because we have all the (stuttering) well-known, All the brand is well-known in the world, but at the same time we wanted to start from scratch. That's why we started with a little people, with most of them were coming from, some were industry instead of the telco industry and we started to build from scratch the whole company and that we were 20 in February 2018 and now we are more than 200 and we started operations in nine months from January 2018. So I think it was a really completely success in terms of speed. >> If you were going to do it all again starting over, what would you do differently? >> That's a really good question. Probably I will put even more effort in transmitting the right culture because when you grow a lot you have to be very carefully in transmitting the right culture to the new commerce. Because it's very easy to let dissipate the culture that you create at the beginning when you are only 10 or 20 people and it's very difficult to maintain it when you are 200. And then if you are 200 with a wrong culture you are transforming yourself in a big company with a small revenue so, that's something that needs to be taken into account. >> Okay, so what's the road map from here? Does the 200 then help infuse into the rest of the company? How do things work going forward? >> Well, what are we doing now is to, we build up a completely new IT stack, that was from the beginning multi tenant to host multiple telco operators and now we are hosting our second telco operator. That's Orange Spain branch for small and medium enterprises, that is now coming to our stack, so this is in our run up for this year, what we are doing is integrating all the stack from Orange Spain to the new one. And at the same time, trying to complete our portfolio with new products. And these new products could be managed and commercialized by X by Orange as a telco provider and also by Orange Spain as another telco provider. >> Right. When people look this show there are so many projects going on and so many different pieces. We sometimes hear "There's a lot of choices, how do I make them?" How did X by Orange, how did you figure out what pieces of the stack was Red Hat, mostly prescriptive as to how you do, or were you choosing the service mesh and all the other various pieces and what can you tell us about your stack? >> Well what I can tell you is that we put a lot of effort on designing the stack by ourselves, not having any turnkey solutions, because we think that this is key for the success of the company. Because normally telco operators put a lot of effort in their core network but they don't put so much effort in the software technology, but now things are changing a lot and we really think that the software layer is as much as important as it was the network. And here is the real perceived value from the customer now resides in the software pack, so we designed each part individually and we selected the right partners for starting the development of each part and then make altogether to work. Instead of going of a full stack provided by a unique company. >> Perfect. As you've gone down this path have you started to look down the serverless environment at all? Or are you strictly in a more container based approach? Let me broaden that a bit. Are you looking into functions as a service and other serverless technologies? Or are you mostly keeping it to more commonplace things that are half a step back? >> Well, in telco industry what is traditionally the vendor, the traditional vendor for the telco industry are the network vendors that are more in their way of virtualization instead of their continuation on not even to mention the deploying serverless. So we are putting a lot of effort on making them to understand and some of them they are understanding it really, really well, that it's key to have their products be able to make an extreme automation. So it's a pity that we don't have enough time (stuttering) to use technologies like serverless. We use them for little operations in our internal stack but we are not at the point of using it in products that we have because what we are doing is trying to, for example, to move the management part of the network services to the containers and now our efforts are in that place. >> And to be very clear, that's absolutely the right answer. You have to meet your customers where they are with things that are appropriate fits for the problems that they have. And average gating for a technology stack because, oh, it seemed like the right answer when I polled a bunch of people on stack overflow or something, is never the right answer to solve those problems, unless "How do I make people "on stack overflow happy?" is the question. Spoiler, you can't. >> Yeah, that's completely true, yeah. >> So Fernando one last question I had for you is here at a big show, what are you looking to get out of the show? What excited you to bring you to the event? And any other things around your experience so far, what you're hoping to do that you could share? >> I think that the most important thing when we're talking about the internal structural transformation for any sized company is the people and the mentality of the people. So I can never say enough times that we really need to invest time with people to embrace the change, to embrace the kind of culture that is behind... The CloudNative mentality because if not, if we don't do so, what we are doing is just transporting our old stack to a new technology without changing anything. So put in that effort, talk with people, make this change happen together with people that is working already in big companies is key for the success of any story. >> All right, well Fernando Alvarez, really appreciate you sharing your story. Congratulations on the progress so far. >> Thank you very much. >> And best of luck in the future. >> Thank you. >> All right. For Corey Quinn, I'm Stu Miniman. We'll be back with lots more. Thank you for watching theCUBE. (upbeat techno 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, two days live coverage here in Barcelona, Spain at KubeCon CloudNativeCon 2019. I'm Stu Miniman. My co-host is Corey Quinn, and happy to welcome to the program first-time guest Vijoy Pandey, who's the vice president and CTO of Cloud at Cisco, and Vijoy, it's a relatively new job for you. Something we're still measuring in months. So, why don't we start there, give our audience a little bit of your background and what brought you to the Cisco Cloud team? >> Sure, so first of all thank you Stu, thank you Corey. Glad to be here. Yes, I am measuring my tenure right now in months. It was days, now it's months, soon it will be years and soon it will be forgotten, but I did come from Google. I spent a whole bunch of time there in the networking space. I actually ran their data center footprint. I also ran the ram footprint for a couple of years. And then I ended up building the automation, modeling, telemetry, data analytic stack for all of their physical infrastructure, for a while. >> Okay, so how much time do we have? Because I always put out there, I'm an networking guy by background and if you talk about just the Google network, how do we get our search results, and our ads to us globally in a short period of time. And you talk about undersea cables, I mean, Google was the example. The first time I heard about SDN and what that was going to be, oh, well lets look at what Google was doing, and when Cloud rolled out, Google's network was really second to none. Now of course, you move over to Cisco, which knows a thing or two about networking. Can you tell us some of those, I guess help connect the dots for me. We've had this premise that the hyperweb scale, what they have done, is what's bleeding into the enterprise. That's what Kubernetes is, what Google did at Boar. And from a networking standpoint, some of the things that the top 20 hyper-scale companies were doing we're now starting to see into the enterprise. Does that premise hold water for you? >> Yeah, that's correct. But what I think what you need to realize is that not everybody is hyper-scaler, not everybody is a Google. But there are concepts and there are mechanisms that Google has used and AWS and Facebook and the others have used, that are very, very relevant to large enterprises, to large service providers, and that is the opportunity. You asked me earlier, why I came and joined Cisco, and you're right, Cisco is the big behemoth in the networking space. And there is a little bit of disconnect in how the hyper-scalers have approached networking in the past couple of years, or few years. And how Cisco's customers and Cisco's global market has been approaching their customers over the past couple of decades. So trying to bridge that gap is what's exciting. And I think there are a lot of concepts that have been developed in the hyper-scalers space that do apply. For example, like you said, SDN is a big one. It simplifies how you do networking. Automation is the other big one. So we see, I've seen in the eight months I've been here, most of our customers looking for an automation platform to build at the same agility and on the same zero-offs mentality that the Googles and AWSs have done. So bringing those concepts within Cisco and giving it to our customers is where the opportunity is. >> If I go back in time, 15 years or so, and I want to start a 50-person company, there's no way I'm going to be able to effectively do that without at least one network engineer on the staff, or almost any reasonable company. Today if something starts up that's cloud-native, a lot of that starts to instead be pushed onto the networks of sort that you used to build at Google, or folks doing the similar things at AWS. Do you see that as a longer-term trend where enterprises are going to start moving in that type of direction as well? Or do you see that enterprises are always going to have specific needs that are not going to be met by the hyper-scale public clouds? >> Yeah, I think that it's probably the latter. What I see in the future is, especially, the way I look at the market, it's data driven in a different way. So wherever you have data, you have the need for compute, you have a need for the network. It comes in a variety of ways. One is just around regulations, so if you have data you need to protect, you need on-prem computes towards networking. If you need a lot of insight from your data, you need to do a lot of number crunching or data crunching. ML, AI, for all of those workloads, you need local compute, you need local network. So, depending upon where the data is, you will see computer networking follow. So in that sense, yes, there will be the need for cloud-based access for all of our enterprises, cloud based applications. But the need for on-prem will never disappear. And that's why I think making the bet on multi-cloud, making the bet on hybrid, is a critical way forward. >> All right, so, Vijoy, one of the things we see at this show, especially, is that intersection between what's happening in the enterprise and what's happening in the developer community. We've watched closely the DevNet group inside of Cisco, and that rise of, it's not just in the DevNet group but Cisco going through a lot of transformation. Heard one of the keynotes in this building a year ago, is when you think of Cisco in like 2030, it shouldn't be Cisco, the networking company, it's Cisco's a software company. And there's the platitudes out there about softwares eating the world alive, but help us give it a little insight as to what that means. Networking of course is Cisco's DNA and how most of us today still think of Cisco, but what's that journey that Cisco is going through? >> Sure. And you touched upon a couple of points there, so let me just walk through a couple of them. First of all, the reference to DevNet, it's pretty evident that everything is moving towards a developer mindset. And the network is no different. So talking about the automation bits that I mentioned earlier even at Cisco the products have been built around even physical boxes, which is the bread and butter for a large majority of out customers. We are trying to move that towards a more developer-friendly paradigm. And instead of going through SNMP or CLI, we are moving towards a very programmatic API, model-driven networks, streaming telemetry. And to do all of those things, you need a developer-centric mindset. So whereas our products are enabling APIs to do those things, there is a need for a community to ingest that API set, and that's were DevNet comes in. So just to be able to train the people who are operating the networks or building on top of out networks, you need a community that is familiar with programmability and development and the software engine principles that go with it. So that's one aspect of the statement that you mentioned earlier and that's one place where Cisco is going. Just with the switches and routers. Another aspect is in 2030 where do you see Cisco evolving towards? And like everybody else we are also going through a transformation. We are becoming cloud-native internally. So it's not just that our products are becoming cloud-native in there nature, it's also what we offer is becoming cloud-native. So the products, the way they are constructed, the way the apps are being developed are becoming cloud-native. We want to be SaaS enabled, so the company is going through a transformation of enabling SaaS on a lot of our products. So transforming Cisco to enable that business model, is also something that you see happen over the course of the next few years. And so we are internally going through how do we build these things out of microservices? How do we scale out? How do we share common code? How do we share common services? How do we stand up a platform just like the Googles and the AWSs have done? And so that's a big push inside of Cisco, as well. >> What does that look like as you go through your own transformation and how does that inform how you meet your customers? >> I didn't catch the last part. >> How does that inform how you meet your customers? As you start to gain empathy for what they're going through too, by going through it yourself. >> That's right, I think, that's exactly right. If you look at what Cisco's trying to do, it's no different than our entire customer set. You can see a whole bunch of things happening, whether whether their companies are being acquired. So lets say, Duo is a great example that we just acquired in the security space. AB Dynamics is a great example. So there's a whole bunch of companies that you acquire that are already SaaS based that are already microservices based. Then there are products that we have had internally that are going through a transformation themselves. Our IT department is going through a transformation. The way we are consuming our own products, talking about DevNet, we are actually consuming them in a very programtic way. So we are no different than all of our customers out there, most of our customers out there, if you skip the top four or five hyper-scalers that we just talked about. So how we approach this problem resinates really, really well with our customer set. And so coming up with use cases and saying that this is how we've solved the problem, these are the products that we built and we consume ourselves so we dog food our own products. For example, the Kubernetes tag that we've had, CCP, we consume it internally. We run it as SaaS product internally. Actually there are a lot of other BUs within Cisco, that consume it as part of their own product offering. So enabling that gives us a lot of credibility when we go and talk to our customers, that this is how we've gone through the journey. And in fact, we want to talk a lot more about that journey in the coming few quarters, because that'll give us the credibility in the marketplace, as well. >> All right, so Vijoy, one of the hottest topics at this show, and has been for a while, is security. And we know there is a tight connection between security and a lot of time with networking there. On the keynote this morning, you talked a little bit about Network Service Match, which is now a sandbox project under the CNCF, explain a little bit how that's helping to attack some of these key issues. >> Sure. I think the NSM is just the first step. So the Network Service Match is basically doing a couple of things. One is it is simplifying networking, so that the consumption paradigm is similar to what you see on the developer L7 layer. So if you think Istio, and how Istio is changing the game in terms of how you consume Layer 7 services, think of bringing that down to the layer to layer three layer, as well. So the way a developer would discover services at the L7 layer is the same way, we would want developers to discover networking endpoints, or networking services, or security capabilities. That's number one. So the language in which you consume needs to be simplified, whereby it becomes simple for developer to consume. The second thing that I touched upon is we don't want developers to think about switches, routers, subnets, BCP, VXLAN, VLAN. >> And they don't! >> They don't, exactly. And so how do you get hybrid and multi-cloud connectivity when you leave a Kubernetes port. Within a port it is very nice and well constructed, and you don't think about those concepts. The moment you leave the port, all of those things come in. And IPs change, subnets change, routing comes into the picture, peering endpoints come into the picture. You don't want developers to think about it and they don't want to think about it, so NSM tries to hide all of that below a shim layer and gives you a simple discovery mechanism, from point A to point B regardless of how far you're going. So that's how the other abstraction that we are bringing in. The third bit, going back to your security question, today if I look at how VNFs are constructed, these are basically cardboard boxes, like I said. They are basically you took the sheet metal, that you are building, you wrap it up in a VM and you call it a virtualized network function. You could follow the same paradigm, wrap up everything, put it in a container, and call it a container network function. We don't want that to happen. So we want to end up in a world where you want specific targeted capabilities. So if a certain application all it needs is an IPSec Tunnel and nothing else, you should be able to provide just that capability, and just basic connectivity for that application. If another application needs a lot more than that, maybe it needs a WAF, maybe it needs something more beyond that, you should be able to provide those capabilities without bringing in the other things. So just dissecting the capabilities of the networking and security space and offering them as individual capabilities which are specific to the application is where we want to be. And that's the world we want to enable. >> Perfect, my last question for you is, when I started off my career as a grumpy Unix administrator, because there's no other kind of Unix administrator that isn't grumpy, I had to learn networking in order to be halfway effective at my job. Today I think you can do the same sort of operational role without having much awareness of networks, because very often that's handled for you, they're a lot more reliable these days, in most cases, too. So you have people who are hitting senior or architect-level roles that have never really touched networking at all. It's always been working behind the scenes until it doesn't. At which point there's not awareness there among those types of people. Those developers are viewing that as part of the plumbing, it always just works. You don't question whether the water's going to come out we turn the tap on, same issue with networking. Do you find that the lack of being first and foremost in people's mind, which is incidentally is a assessment to your success, that that is going to start working against you in some ways as some people stop thinking about networking as a primary thing they need to solve for? >> So, it's and interesting point, and I think if you think about, again, my background where I came from. So at Google, we used to have this thing, that since we control the application stack end to end, we could build the infrastructure the way the applications would want them to be built. So for example, you would go to YouTube or an ML application and say, what do you want infrastructure to be? And in a utopian world they would tell you, build me this. To your point what they told us, even within Google, is, give me infinite capacity at zero latency, at zero cost and then go away. That's what developers want. They don't want to think about it, till it breaks. >> Yes. >> And so number one, building something that will give you infinite capacity at zero latency, high availability and as little cost as possible, I think there is a role for networking for a long, long, long time to come. Number one, because there are architects and products to enable that. Number two, observability. Figuring out how to bump up availability as you go on, getting into zero ops and automation, getting into AI and making sure that these things operate and run on their own, and there is very little burden on the network engineer or operator. These are all problems that a company like Cisco can bring, or solve, in this world. And so you will see Cisco just move up the stack. So it's not that these things will disappear. But, yes, there will be parts that will be plumbing, but there will be parts that Cisco will move up the stack. Getting the observability, getting SLAs in the network figured out, I think there's where, those are the places were Cisco will add value. >> All right, so Vijoy, I'll ask you to close with how you opened your keynote. Help explain network Please Evolve. >> So this, actually yes, so I think wrapping up in terms of everything that I've just said, a few things that networking needs to do is move forward into the cloud-native world, where you are building things in the same way that applications are being built today. And so the consumption model, the architecture of the application in terms of microservices, the way you would operate these networks in terms of building very specific SRE teams, those are the ways the network should be built, as well. The other thing, which is near and dear to my heart, is the need to build in a zero ops matter. You cannot have network engineers and operators muck around with the network anymore. Because they're becoming bigger, larger, and more complicated than ever before. So we need to move towards a zero ops model, and that's were I think evolution of the network should be. >> Well, Vijoy, congratulations on the progress so far, and thank you so much for joining us. >> hank you, and it was very nice to be here. >> All right, for Corey Quinn, I'm Stu Miniman. Back with more of two days of wall-to-wall coverage here at KubeCon CloudNativeCon 2019 Barcelona, Spain. Thank you for watching theCUBE. (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 the theCUBE, covering KUBECON and CloudNativeCon Europe 2019. Brought to you by RedHat, the Cloud Native Computing Foundation, and the Ecosystem Partners. >> Welcome back to theCUBE. I'm Stu Miniman. My co-host, Corey Quinn. 7700 here in Barcelona, Spain, for KUBECON, CLOUDNATIVECON. Happy to welcome to the program a first-time guest, Erin Boyd, who is a senior Principal Software Engineer in the office of the CEO of RedHat. Erin, thanks so much for joining us. >> Yeah, thanks for having me. >> Alright, so just a couple of weeks ago, I know I was in Boston, you probably were too, >> Yep. >> For RedHat Summit. Digging into a lot of the pieces. You focus on multi-cloud and storage. Tell us a little bit about, you know, your role, and what you're doing here at the KUBECON show. >> Sure, I'd be happy to. So for over a year now, RedHat's really been kind of leading the pack on hybrid cloud. You know, allowing customers to have more choice, you know, with both public and private cloud offerings. And, of course, OpenShift being our platform built on Kubernetes, we believe that should be the consistent API in which we have Federation. Yeah, so Erin, I got to talk to quite a few OpenShift customers at RedHat Summit. It was really how they're using that as a lever to help them really gain agility in their application deployment. But, let's start for a second, without getting too fanatic, you say hybrid cloud. What does that mean to your customers? You know, RedHat has a long legacy of, well, lives everywhere. So, public cloud, private cloud, hosting provider, all of the environments, you, RedHat, Enterprise, Linux, can live there. So in your space, what does hybrid cloud mean? >> So, hybrid cloud, I think follows a model of real. It's everywhere. So it's having OpenShift run on top of that and being able to have the application portability that you would expect. Along with the application portability, which is my focus, is having the data agility within those applications. >> Alright, how do you wind up approaching a situation where an app is now agile enough to move between providers almost seamlessly, without having it, I guess, descend down to the lowest common denominator that all providers that it's on are going to provide? I mean, at some point, doesn't that turn into treating the cloud as a place to just run your either instances or containers, and not taking advantage of, I guess, the platform level services? >> Sure, so I think that the API should expose those choices, I don't think it's a one size fits all when we talk about, you know, if you move your application maybe your data doesn't necessarily have to move. So part of the core functionality the Federation is meant to provide, which has been renamed Kubefed since Summit, is that you have the choice within that. And, you know, defining policies around the way we do this. So, perhaps your application is agile enough to span three different clouds, but due to data privacy, you want to keep your data on prem. So, Kubefed should enable you to have that choice. >> You know, so you know, help us dig down a little bit in the storage, you know, environment here, you know. >> Sure. I go back and I worked for a very large storage company that was independent before it got bought for a very large sum of money. But, we had block and file storage. And mostly, that you know, lived in a box, or in a certain application. >> Right. You know, the future, we always talked that there's going to be this wonderful object storage and actually it's designed to be, you know, we'll shard it, we'll spread it around >> Right. And it can live in lots of places. Cloud, a lot of times has that underneath it, so you know, have we started to you know, cross that gap of you know, that mythical nirvana of where say, you know, storage should actually live up to that distributive architecture that we're all looking for. >> Right, so with Kubernetes, the history is, we started off with only file systems. Block is something very new within the last couple releases that I actually personally worked on. The next piece that we're doing at Red Hat is leading the charge to create CRDs for object storage. So it's defining those APIs so customers can dynamically provision and manage their object storage with that. In addition, we recently acquired a company called NooBaa that does exactly that. They're able to have that data mobility through object buckets across many clouds doing the sharding and replication with the ability to dedupe. And that's super important because it opens up for our customers to have image streams, photos, things like that that they typically use within an enterprise, and quickly move the data and copy it as they need to. >> Yeah, so I've actually talked to the Noovaa team. I would joke with them that, didn't they deduplicate, couldn't they deduplicate their name 'cause it's like Noovaa. >> (laughs) yeah. >> So you know, plenty of vowels there. But, right, storage built for the cloud world is, you know, what we're talking about there. >> Right. >> How's that different from some of the previous storage solutions that we've been dealing with? >> So I think before, we were trying to maybe make fit what didn't work. That's not to say that file and block aren't important. I mean, having local storage for a high performance application is absolutely critical. So I think we're meeting the market where it is. It's dependent on the behavior of the application. and we should be able to provide that. And applications that primarily run in the cloud and need that flexibility, we should be offering object as a first-class citizen, and that's why our work with those CRDs is really critical. >> What is the customer need that drives this? Historically, with my own work with object stores, I tend to view that as almost exclusively accessed via HTTP end points. And at that point, it almost doesn't matter where that lives, as long as the networking and security and latency requirements are being met. What is it that's driving this as making it a first-class citizen built in to Kubernetes itself, the Rook? >> So it allows us to create the personas that we need. So it allows an administrator to administrate storage, just like they would normally with your persistent volume, persistent volume claims and quotas. And then it abstracts the details of, for instance, including that URL in your application. We use a config map within the app so the user doesn't have access necessarily to your keys in the cloud. It also creates a user so you're able to manage users like you would normal objects, which is a little bit different than the PV PVC, and that's why we feel like you know, it's important to have a CRD that defines object in that sense because it is a little bit different. >> All right, so Erin, is this Rook we're talking about then, is, you know, Rook, did I understand, I think got to 1.0, just got released. >> Yeah. >> You know, give us the update on what Rook is, you know, how that fits with this conversation we've been having. >> Right. You know, where we are with the maturity of it. And Rook, as was on the keynote this morning, you know, is a great CNCF project with a really healthy community behind it. One of the provisioners we've created as part of those object CRDs is a Rook provisioner for CEF block, or excuse me, CEF object. We also have an s3 provisioner. So, you know, we hope to have, just like we had external provisioners in Kubernetes, use, you know, allow for the same contribution from the community for those. >> Okay, yeah, there, I remember a couple of years ago at the show, this fixing storage for containers in Kubernetes was something that was a little bit contention in there, and there were a few different projects out there. >> Right. >> For that, you know, where are we with that? We understand that it's never, you know, one solution for every single use case. You know, you already talked about, you know, block file and object. >> Right. >> And how there's going to be a you know, a spectrum of options. >> Sure and so I think there's lots of things to fix. >> Yeah. >> When you talk about that. One of the key things that Rook offered was the ability to ease the deployment of the storage and administration of it, and, as you know, Rook you know, has a plethora of different storage systems that it provides. And, you know, what we're really pushing at RedHat, which I think is important, is having, you know, operators. Like the operator hub that was released with OpenShift 4.0. Rook will be an operator in there. So what that allows is for more automation and true scaling. 'Cause that's where we want to get to with hybrid cloud. If you're managing 10,000 clusters, you cannot do that manually. So having Rook, having operators, and automating the storage piece underneath is really critical to make it now-scale happen. >> Forgive my ignorance. When you say that Rook winds up exposing, for example, now an object store underneath. Is that it's own pile of disks on a system somewhere that it's running? Is it wrapping around object store provided by other cloud providers? Is it something else entirely? What is the, where do the actual drives that hold my data, when I'm using Rook's object store, live? So with Rook today, the object storage that it uses is CEF object. So it exposes the ability to create, you know the CEF components underneath, which Rook can lay down and then expose the object piece of that. So that's the first provisioner in there, yep. >> Wonderful. >> Alright, so I guess when I think about object storage, for years it's been, well, I've got s3 compatibility. And that's kind of the big thing. >> Yep. Is Rook s3 compatible then? Is it, you know, giving more flexibility to users to make this the standard in a cloud native environment? Help us, you know, put a fine as to what this is and isn't. >> Yeah, that's a great question, actually, and we get asked it often. So one of the first provisioners we did is just a proof the concept was an s3, a generic s3 provisioner. And of course, CEF is s3 compliant, so it also does that, but you know, there isn't a standard for object. So most providers of object are s3 compatible. We found it very easy to take off the s3 provisioner we created to create the CEF one. There wasn't much differentiation, which means it's a great pattern for anyone to want to onboard. >> Yeah. Do you find that as s3 itself, and of course, it's competitors of other cloud providers, become more capable, you're starting to see differentiation. Now easy example would be with some of the object storage tiers, where there's increased latency on retrievals. In some cases, as little as five minutes, or as much as 12 hours. Other providers, like Google Cloud, for example, or Azure, have consistent retrieval times on their archive storage. As an easy example, is that something that you're going to start seeing divergence on as object storage becomes smarter by, I guess, all of the providers as they race each other to improve their products. >> Absolutely. I think tiering is one of the facets of object that's really critical. And you know, of course, as we spoke earlier, it's physics, you know, and having data consistency at that very low threshold is important. So, you know, using the storage for what it's worth. Using the best tools, and pulling object into the ecosystem is part of that. >> Yeah, Erin, is there anything that differentiates kind of Kubernetes storage from, you know, what people are familiar with in the past? >> I think Kubernetes storage continues to evolve. The more we learn about how people use Kubernetes, and their needs, I think we listen closely to the community and we develop against that. >> Okay, I guess the other thing is, you know, what kind of feedback are you getting from customers? Where are we along this maturation journey. You know, my history is you know, I worked when we had to fix networking and storage in virtualized environment, and it took about a decade. We're five years into Kubernetes. It feels like we've, you know, accelerated that based on what we've done in the past, but you know, definitely, you know, when it first started, it was you know, let's put stateless stuff in containers and you know, storage will be an afterthought. >> Right. >> Or something that was kind of a side car over here where you had your repository. >> Right. And I think that's the beauty of Kubefed, is that in order to have true hybrid cloud, and have Federation, we have to come together in consensus with both network compute and storage. So it really brings the story full circle. >> Perfect. What do you think right now customers are having their biggest challenges with, as they start wrapping their minds around this new way of thinking? I mean, again, it's easy for a tiny start-up, it's Twitter for Pets, or something like that, to spin off in a pure cloud native way, but larger companies with this legacy concept known as a business model that might involve turning a profit, generally predate cloud, and have done an awful lot of stuff on the data center. What are they seeing as currently being limiting factors on their digital transformation? >> So with Kubernetes just being five years old, as we celebrate the birthday today, I think customers are also maturing. You know, they're entering the landscape, learning about Kubernetes, learning how to containerize, you know, lift and ship their applications, and then they're running up, to costs, right? And lock-ins and things they want to avoid. And that's really where we in the community want to provide a platform and a runway for them to have that choice. >> Alright. Erin, any customer successes that you can share with us, either about the operator or about work specifically? >> Certainly not with Federation. We haven't released it. It will come out in OpenShift 4.2, so we don't have any customer success stories yet, but I would say definitely it's a request, and you know, we're asking customers about it, and if they're interested. And you will find many times maybe they're not familiar with the word Federation, but they're definitely interested in that use case. >> Okay, how's the general feel. You know, what kind of feedback are you getting from customers so far, things that you're excited about that are happening here at the show? >> I'm just excited that Kubernetes is kind of growing up. And it's you know, becoming a true enterprise-level project that customers rely on, and build their business on. >> Well, Erin Boyd, really appreciate you joining us, sharing all the updates. Look forward to the upcoming release, and definitely get to follow up with you soon, to hear about those customers as they start rolling it out. >> Alright, great. Thank you. >> Alright. For Corey Quinn, I'm Stu Miniman, here at KUBECON, CLOUDNATIVECON 2019, Barcelona, Spain. Thanks for watching theCUBE (techno 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 Barcelona, Spain, this is theCUBE's live coverage of KubeCon, CloudNativeCon, 2019. 7,700 people in attendance, including myself, Stu Miniman, and co-host Corey Quinn, and returning to the program, Abby Fuller, who is the principal container czarina (Abby laughs) at Amazon Web Services. Yeah, Abby, I could say it without laughing, but, uh-- >> I can't. >> I don't think you can. Yeah, so, you know, let's just, czarina? You know, how does one, you know, become a czarina in their career, Abby? Let's start there. >> You ask Deepak really nicely, and he'll change your title for you. Longer answer, I think I'm doing a similar version of what I've always done for Amazon. Which is, how can I get what customers are asking for, and their feedback, and what they're struggling with, they're working on, or enjoying? Taking that back to our internal product development process, and then doing the same thing back the other way. So if we're building something, how can I help educate customers on how to work with it, and how to use it, how to build with it? So, same thing, just funnier title. >> All right, well, Abby, you know, it's a big, cloud show, so of course we know Amazon will be here. Lot's of developers here at the show, lot's of activity. Yesterday AWS held a, kind of, pre-show workshop. Maybe start there, tell us a little bit about that. >> Yeah, so we had AWS Container Day, maybe five or six hundred people, we did it at the hotel that is allegedly across the street, but is really, like, twenty five minute walk away. We did some workshops, we did a Birds of a Feather session at night. We had a little, mini, product preview announcement, so that was pretty fun. Something called, Container Insights, from CloudWatch team. I think my favorite thing about KubeCon is my favorite thing about the Kubernetes community, right, which is that, everyone is so happy to be here. They're all so enthusiastic. I've never had that many questions at a Birds of a Feather session before. We sent a ton of Amazon people here, to, kind of, talk about EKS, and Kubernetes, and community work. And the energy at the KubeCon is always so impressive. >> Give us a little sampling, you know, there's passion, is there questions? Are they trying to understand the various pieces? Are they excited about some of the new features? What's some of the energy you're capturing? >> Yeah, you know, I think it's both. I think on the EKS side, there's always the balance, right, in the Kubernetes community between, how can I have more power and flexibility? And then, how can you carry pager for more of this? So I think it's always an interesting balance, between the folks that are like, hmm, do you think you could manage that for me as well? And the folks that are like, I want to be able to pass in control plain flags. So, there's always an interesting balance. A lot of questions about version upgrades. I think that one is always, always seems to be top of mind, 'cause the Kubernetes community moves so fast. So, compared to a lot of other products, and how quickly they can release new versions, Kubernetes moves so fast. So, if you don't have a good upgrade strategy, you're in trouble. So-- >> Well, to that point, yesterday during the talk, there was a slide that went up, that listed, over the trailing 12 months, that there were 1,900 and change major service and feature releases. And that's very much a two edged sword, sitting in the audience, 'cause on the one hand, yay, the pace of innovation continues to increase, and services are getting better all the time. On the other, it's one of those, hmm, at least four of those would have been critically important, but I may not know about them. And to that end, something that the container group seems to have done, that almost no one else has, has been to put up a public roadmap of what's coming down the pike. Which has been tremendously helpful for customers, as far as being able to plan things out. How did that come to be? >> A lot of talking. I think, ultimately, right, all teams at AWS work the same way. Which is, backwards from what the customer is asking for. So, we have a lot of customer meetings. We have a lot of customer conversations, we talk to a lot of people. I do a lot with that on social media, or at conferences, or with blogs, or with live streaming. But ultimately, at the root of it, we all follow the same process. And I think the roadmap is really an extension of that. It's, how could we get, both what we're working on, to customers a little bit faster, but also, how can you have a voice that we hear so much more loudly? So, right? That you can be the smallest start up, or the largest enterprise, and you can open a GitHub issue just the same. And say, hey, you know, I'd really like to see you do that. And, I think the other piece of it, is that everyone has an AWS story. Where they build something custom, to work around something, or to add a feature, and then six weeks later we're like, we shipped it! And that's awesome, it's a good problem to have, and being able to delete code is one of everyone's favorite problems, I think. It's my favorite problem. >> It's one of life's true joys. >> It is one of life's true joys. (Corey laughs) But, what I think is even better than that, is a little bit of a heads up. And I think that that really builds trust between us and the community, is, how can we let you know we're working on, so you can plan around it? Or, if you don't see something, let us know that we're not thinking about the things that you value. >> Well, So Abby, you know, we've been at the Amazon shows for a number of years-- >> Yeah. >> And that customer feedback loop is something that we hear a lot. >> Yeah. >> Are there any dynamics about, just being in a big, open source community here, is, you know, just listening, and feedback loops as part of that? So, how does that impact, you know, how you work on things? >> Yeah, so, when we do events like this, I try to talk to as many people as possible. I try to listen in to the conversations, when I can. People come by the booth, they come by the meeting rooms. And I think it's about taking that back from all the different sources that were at the conference, the reviews online, the blog posts that people write after this, coverage like theCUBE, taking that all back, and then let's go through it. And then, how many of these things do we know about? Have a lot of people asked us for this? Is this something new? If it is new, how can we go find other people to talk to, to see who else is having that problem, that maybe we just didn't know to ask about before? So it's all part of that same working backwards process, but feedback comes from so many different places, and I think that, that ultimately is what makes it cool, right? It's because you get different feedback at a KubeCon than you will at a re:Invent, than you will on a Twitter, or that you will at a customer meeting. So, you need all of those sources to kind of figure out, what's more important? And, who is it important to? >> Yeah, one of the things that I find fascinating about the entire AWS Container story is, you almost get to decide your own level of involvement. You can run it all yourself, on top of EC2, you can wind up doing one of the manage serves with ECS, or EKS. And then there's Fargate, which I'm very bullish on for the future, if for no other reason that, if that takes over, suddenly we will never have to hear someone from Amazon mispronounce AMI, ever again. Which, I'll take my victories where I can find them. (Abby laughs) But, what are you seeing customers doing with Fargate? What's the paradigm look like, that's different than you might have expected at launch? >> Yeah, so, the way that I ultimately think about Fargate, right, is as a, it's a capacity provider for EC2. So, when you think about, kind of, the levels of control, right? You start at maybe the orchestrator level, so an ECS or an EKS. And if you're using ECS through Fargate, you're not interacting directly with EC2. So it's about, how can I control and define everything at just the container level, just at the task definition level, without having to think about the underlying EC2 instances? And they're still there, before someone tells me that serverless still has servers. But, you're not the one that's actively managing them. We're managing them on your behalf. All you care about is your workload itself. And then you can go a step deeper than that, and say, you know what, I want control over those EC2 instances. I want to manage them myself, maybe I want to do something in user data, or I want to be able to run DaemonSets myself, on the underlying infrastructure, and that's fine. So, I think it's ultimately about the level of control that you want. Fargate, to me, is interesting because it's like Lambda, in the sense that people have seemed very joyful about not having to manage EC2. Because ultimately, that's not what's providing them business value. That's not what let's them differentiate, and I think the way that Werner puts it is, you want everything that you write to be business logic. And I think with things like Lambda and Fargate, it gets you one step closer to that. That instead of having to manage infrastructure, to then manage your code, it's, just manage my code, please figure out the rest of it for me. >> This is borderline heresy in some circles, so don't, at me. (Abby laughs) But, what I'm wondering is, are things like containers, and functions as a service, aligned longer term, on the same axis? At some point, where it just becomes an implementation detail, and not a battle that needs to be fought. >> Yeah, the way that we think about it, right, is that, and I think the way that customers see it, is that serverless is ultimately a spectrum. There are many different flavors of it, depends on how you kind of want to work with it. But ultimately, I think, even longer term, maybe this is even more heretical, right? But, I want to not care. I don't want to have to care about the primitive that you're using. I don't want you to have to choose. And right now, I think you have to choose, regardless of the tool that you're using, you must choose very early. And to take advantage of a new tool, to go from containers, to Lambda, or whatever else you want to use, you have to re-write. Or you have to rebuild, or you have to re-wrap what you're doing. And I want to get to a point where you don't care. That I can use whatever combination of the below that I want to use, and that AWS will provide tools around that, that just says, you run this however you want. You mix and match whatever flavors you like, and we'll take care of it. >> Yeah, it's interesting, almost every time we've done one of these Kubernetes shows, we've had somebody from Amazon on, and even if we haven't had an AWS employee, almost every customer we have on is doing some, if not a lot of Amazon. There's some out there that look, and they're like, well, Amazon doesn't have the biggest booth, and Amazon has all of these different choices out there, so they must not be fully committed to, you know, capitol K, Kubernetes, and things like that. How can you help us understand what's going on? >> Yeah, so, I think Bob Wise, and his team spent a ton of time working on the community, and the whole team does, right? We're one of the biggest contributors to etcd, we're hosting Birds of a Feather. We've contributed back to a fair amount of community projects, and I think a lot of them are, in fact, around how to just make Kubernetes work better on AWS. And that might be something that we built because, EKS. Or, it might be something like Cluster Autoscaler, right? Which, ultimately, people would like to work better with Auto Scaling groups. So, I think we have the community involvement, but, I think it's about having a quiet community involvement, right? That, it's about chopping wood, and carrying water, and being present, and committing, and showing up, and having experts, and answering questions, and being present in things like SIG groups, than it is, necessarily, having the biggest booth. >> Yeah, I mean, from my perspective, at conferences, across the board, community involvement can never be measured by who spends enough money on the conference to have a booth large enough to play ice hockey in. That doesn't really seem to be as good of a barometer. Things like the roadmap, tend to be a spectacular, I guess, expression of how that engagement is starting to look. And I really am enthusiastic to see what's been done so far, and I'm looking forward to seeing more of it. >> Well thank you, I'm really proud of the roadmap. It's been so interesting to see customers take a, kind of, a new level of transparency, for us, product roadmap wise. And then, I love seeing people go through, and start adding more. So, I feel like the roadmap started to feel successful to me when customers started opening a ton of issues, and saying, hey, have you thought about this? Our new thing is, we've been posting requests for comments, or design docs on there, and saying, you know, we're thinking about building this, and here's what we were thinking about building. Did the way that we built this solve the problem that you're trying to solve? 'Cause ultimately, you can build the coolest thing in the world, and if it doesn't solve problems for your customers, what's the point? >> Yeah, and Abby, I'll reiterate that the roadmap was something that, you know, the ecosystem, the community, was very excited about. What other things did you want to share before we wrap? You know, things at the show, or related to the container space that, you know, you're hearing your customers talking, and asking a lot about. >> Yeah, so I've heard great things about all the sessions. I think that I'm a little biased, 'cause I was on the program committee. So, obviously the selection was universally excellent. Yeah, I think, what I like the most, I think, about events like this, is that everyone seems to have a different way of solving things. They're all asking for something new. They're all talking about a different project. They're all in different SIG groups. They're all making different feature requests. They're all using different tools. I think that that's really powerful, and I think was what's made Kubernetes so amazing, is that, the whole community feels like this. This is a huge turn out for a conference, and everyone feels very, like, actively engaged. And I like seeing us, kind of, push the boundaries, right? Between, how much can I pass off to something like EKS? And then, how much can I keep customizing, but on only the things that matter to me? >> I guess, as you're talking about roadmap, and plans for the future, if I were to build an environment on AWS, going back, let's say a decade-ish, I would have built something in a single AWS account, using EC2 classic, and maybe simple DB, as a data store. Which, generally, is in no way aligned with best practices today, and migrating off of those types of architectures, for some customers, has been painful. Is there any way to, I guess, loosen the abstraction, for lack of a better term? Of, what, the things we can do, and build in a forward looking way today, that will make migrating to whatever best practices emerge from the customer learnings, or the rest, in the future, not be the equivalent of an entire migration? >> Yeah, so, I think what you're asking, right, is, how can I make, kind of, adopting new technologies, or migrating, a little bit easier? >> Yeah. Or even, adopting new patterns. >> That's a really interesting one. Yeah. I think where I see this space kind of going, and where I think it gets interesting to me, is thinks like App Mesh. So, I can have many different kinds of compute inside of a mesh, through App Mesh, right? So I can have an application running on EC2, I can have a container running with EKS, or ECS, I can have Kubernetes on EC2. In the fullness of time, I'd love to see things like Lambda functions inside an App Mesh. What I like about that, is that, how that can make the migration process easier. Because if I can have many types of primitives in the same mesh, I can mix and match, or I can drain traffic off from one to the other, and I can experiment a little bit more without having to re-write, 'cause I can try it out. It can be part of the same mesh, and if I want to move, I can just move more stuff over. So, I think that's interesting, and I think, as for, kind of, the best practices, and stuff like that, we evolve hand in hand with our customers. As our customers are figuring out new technologies that they want to use, or new ways of building things, we want to be right there with them. And I think the AWS way is about, how can we help customers build whatever way they want to do, but help them be secure, reliable and scalable. >> Yeah. What I'm hearing from that, as a take away, is, if I'm not playing around with service mesh's, or app mesh's now, it's probably time to fix that, and learn how they work. >> I think it's a new technology. I think it's an interesting one, I'm excited to see where it goes, but, watching it, kind of, grow along with Kubernetes, has been really interesting. >> All right, well Abby Fuller, thanks so much for joining again on theCUBE. >> Thanks for having me. >> For Corey Quinn, I'm Stu Miniman, you're watching KubeCon, CloudNativeCon 2019, in Barcelona, Spain, thanks for watching theCUBE. (futuristic 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 Barcelona Spain it's theCUBE covering KubeCon CloudNativeCon Europe 2019. Brought to you by Red Hat. >> 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. >> Hola Barcelona I'm Stu Miniman and my guest host for this week is the one and only Corey Quinn, and you're watching theCUBE the leader in live tech coverage, actually the fourth year we've been doing the KubeCon and CloudNativeCon. This is KubeCon CloudNativeCon Barcelona 2019. We've got two days of wall to wall live coverage. Last year we were in Copenhagen it was outside a little bit windy and we had this lovely silk above us. This time we are inside at the Fira. We've got some lovely Cube branding. The store with all the t-shirts and the little plushies of Fippy and all the animals are right down the row for us, and there is 7,700 people here. So I have been, I did the Austin show in 2017 did the Seattle show last year 2018. We had done the Portland show in 2016, so it's my third time doing one of these, but Corey it is your first time at one of these shows. Wait this isn't an AWF show, so what are you doing here? >> I'm still trying to figure that out myself when people invite me to go somewhere "Do you know anything about insert topic here?" absolutely, smile and bluff your way through. Eventually someone might call you on it, but that's tomorrow's problem not quite today's. >> Yeah I have this general rule of thumb the less I know about something the more I overdress to overcompensate it. Oh so here's the guy in the three piece suit. >> My primary skill is wearing a suit everything else is just edging details. >> Alright, so let's set the stage for our audience here Corey. As I've said we've got the Foundation, we've got a lot of the big members, we've got some of the project people, but I'm really excited we actually have some excellent users here, because it is five years now since Kubernetes came onto the scene of course built off of Borg from Google, and as Dan Conn said in the opening key note, he actually gave a nice historical lesson. The term he used is simultaneous invention and basically those things that, you know, there are times where we argue, who created the light bulb first, or who did this and this? Because there were multiple times out there and he said look there were more than a dozen projects out there. >> Many of them open source or a little bit open as to these things like container orchestration, but it is Kubernetes that is the defacto standard today, and it's why so many people show up for this show, >> and there's such a large ecosystem around it. So you live in the Cloud world you know what's your general view on CloudNative and Kubernetes and this whole kind of space? >> Well going back to something you said a minute or two ago. I think there's something very strong to be said about this being defined by it's users. I've never yet seen a successful paradigm takeoff in the world of technology that was vendor defined. It's at some point you wind up with these companies doing the digital equivalent of here we've crafted you this amazingly precise wrench, and you hand it to a user and the first thing they say is wow it's kind of a crappy hammer, but it's at least good for a first attempt. Tools are going to be used as users want to use them and they define what the patterns look like. >> Yeah so I'll give you the counter point there because we understand if we ask users what they wanted they wanted better buggy whips so we can go faster. To compare and contrast we had done a few years ago was this openstack was user driven and it came out of NASA, and if it was good enough for the rocket scientist, it should be something we that can learn on, and Rackspace had done good and gave it to the open source community, and stepped back and let people use it. First of all openstack it's not dead it's being used in the Telco world it's being used outside of North America quite a bit, but we saw the kind of boom and bust of that. >> We are a long way passed the heyday. >> The vendor ecosystem of openstack was oh it's an alternative to AWS, and maybe some way to get off the VMY licensing, and I've actually said it's funny if you listen to what happens in this ecosystem. Well, giving people the flexibility not to be totally locked in to AWS, and oh it's built on Linux and therefore I might not want to have licensing from certain vendors. Still echos from previously but it is very different. >> Very much so, and I will say the world has changed. >> I was very involved in Eucalyptus which was a bit of a different take on the idea, or the promise of what openstack was going to be What if you had Cloud API's in your own data center in 2012 that seemed like a viable concern. The world we live in today of public cloud first for a lot of shops was by no means assured. >> Yeah, Martin Meikos, Cube alum by the way, fantastic leader still heavily involved in open source. >> Very much so >> One of those things I think he was a little bit ahead of his time on these. So Corey, one of the reasons, why are you here? You are here because I pulled you here, and we do pay you to be here as a host. You're not here for goodwill and that. Your customers are all users and tend to be decent sized users and they say Corey helps people with their Amazon bills no that's the AWS bills not the I have a pile of boxes of smiley faces on there, oh my God what did I do around Christmas time. >> Exactly >> So the discussion at the show is this whole hybrid and multi cloud world when I talk to users they don't use those words. Cloud strategy, sure, my pile of applications, and how I'm updating some of them, and keeping some of them running, and working with that application portfolio and my data. All hugely important but what do you hear from users, and where does the things like cloud and multi cloud fit into their world? >> There are two basic archetypes of user that I tend to deal with. Because I deal with, as you mentioned, with predominately large customers >> you have the born in the cloud types who have more or less a single application. Picture a startup that hits meteoric growth and now is approaching or is in the IPO stage. They have a single application. They're generally all in on one provider, and the idea of going multi cloud is for auxiliary things. If we take a step back, for example, they're saying things like oh PagerDuty is a service that's not run by one of our major public cloud providers. There are a bunch of SaaS applications like that that factor in, but their infrastructure is >> predominately going to be based in one environment. The other large type of customer you'll tend to see is one of those multinational very divisional organizations where they have a long legacy of being very data center first because historically that was kind of the only option. And you'll start to see a bunch of different popup cloud providers inside those environments, but usually they stop at the line of business boundary or very occasionally on a per workload basis. I'm not seeing people say, >> well we're going to build this one application workload, and we want to be able to put that on Oracle cloud, and Azure and GCP and AWS, and this thing that my cousin runs out of the Ozarks. No one wants to do that in the traditional sense because as soon as you go down that path you are constrained to whatever the lowest common denominator across all those things are, and my cousins data center in the Ozarks doesn't have a lot of frills. So you wind up trying to be able to deploy anywhere, but by doing that you are giving up any higher level offering. You are slowing yourself down. >> Yeah, the thing we've always been worried about is back in the day when you talk about multi vendor do we go by the standard, and then go to least common denominator and what has worked it's way through the environment? That's what the customers want. I want today if I'm the user, agility is really one of the things that seem to be top of mind. What IT needs to do is respond to the speed of what the business needs and a CloudNative environment that I look at is it has to be that lever to be able to help me deliver on the next thing, or change the thing, or update my thing to get that working. It was, so disclaimer Red Hat is our headline sponsor here we thank them for our presence, but actually it's a great conversation with open shift customers, and they didn't talk about open shift to open shift to open shift. They talk about their digital transformation. They talk about their data. They talk about the cool new things that they are able to do, and it was that platform happened to be built on Kubernetes. That was the lever to help them do this at the Google show where you were at. That was the same conversation we had whether it is in GCP or whether it was in my own data center. >> You know yes we can do it with containers and everything like that. It was that lever to be able to help me modernize and run new apps and do it faster than I would've done it in the past. So it's that kind of progression that is interesting for me to hear, and just there is not, there is this tendency now to be like oh look everybody is working together and it's wonderful open source ecosystem. It's like well look the world today is definitely coopetition. Yes you need to be up on stage and if a customer says, I need to work with vendors A, B, C, and D. A, B, C, and D, you better work with that or they will go and find an alternative, because there are alternatives out there. >> (Corey) Absolutely, and when a company embarks on a digital transformation and starts moving into public cloud, there are two reasons they are doing that. The first is for cost savings in which case (laughs), let's talk, and the other is for capability storing, and you're not going to realize cost savings for a lot longer than you think you will. In any case you are not going realize capability story if all you view public cloud is being, is another place to run your VAMS or now your containers. >> Yeah, so thank you, Corey your title in your day job You're a Cloud economist. >> I am, two words that no one can define. So no one calls me on it. >> Kubernetes it's magical and free right >> That's what everyone tells me. It feels like right now we are sort of peak heighth as far as Kubernetes goes, and increasingly, whenever you see a technology that has gotten this level of adoption. We saw it with openstack, we've seen it with cloud, we've seen it with a bunch of things. We are starting to see it with Serverless as well. Where, what problem are you trying to solve? I'm not going to listen to the answer, today that answer is Kubernetes, and it seems like everyone's first project is their own resume. Great, there has to be a value proposition, there has to be a story for it, >> and I'm not suggesting that there isn't, but I think that it is being used as sort of an upscale snake oil in some cases or serpen grease as we like to call it in some context. >> Yeah, and that's one of our jobs here is to help extract the sigma from the noise. We've got some good customers. We're going into the environment. One of the things I try to do in the open keynote is find that theme. Couple of years, for a couple of shows >> it's been service mesh is the new hotness. We're talking about Istio, we're talking about Helm, We're talking about all these all these environments that say okay how do I pull together all the pieces of the application, >> and manage that together? Because there's just, you know, moving up the stack, and getting closer to that application. We'll talk about Serverless in one of the other segments later this week I'm sure because you know there's the, okay here Knative can help bridge that gap, but is that what I need? We talk a lot about Kubernetes is how much does the public cloud versus in my data center, and some of the guys they talk to, Serverless is in the public cloud. We'll call it functions of the service if you put it in your own data center, because while yes there are servers everywhere. If you actually manage those racks and everything like that it probably doesn't make sense to call it Serverless. We try not to get into too many semantics arguments here on theCUBE. >> You can generally tend to run arbitrary code anywhere the premise of Serverless to my mind. >> Is more about the event model, and you don't get that on VRAM in the same way that you do in a large public cloud provider, and whether that is the right thing or not, I'm not prepared to say, but it's important for that to be understood as you are going down that path. >> So Corey, any themes that jumped out for you, or things that you want to poke at, at the show, for me, Kubernetes has really kind of crossed that Chasm, and we do have large crowds. You can see the throngs of people behind us, and users that have great stories to tell, and CNCF itself, you know has a lot of projects out there, we're trying to make some sense of all those pieces. There's six now that have graduated, and FluentD is the most recent, but a lot of interesting things from the sandbox, through that kind of incubating phase there, and we're going to dig into some of the pieces there. Some of them build on top of Kubernetes, some of them are just part of this whole Cloud Native Ecosystem, and therefore related but don't necessarily need it, and can play in all these various worlds. >> What about you? >> For me I want to dig a little bit more into the idea of multi cloud. I have been making a bit of a stink for the past year. With the talk called the myth of multi cloud. Where it's not something I generally advise as a best practice, and I'm holding that fairly well, but what I want to do is I want to have conversations with people who are pursuing multi cloud strategies and figure out first, are they in fact pursuing the same thing, so we're defining out terms and talking on the same page, and secondly I want to get a little more context, and insight into why they are doing that, and what that looks like for them. Is it they want to be able to run different workloads in different places? Great that's fair, the same workload run everywhere, on the lowest common denominator. Well lets scratch below the surface a bit, and find out why that is. >> Yeah, and Corey you're spot on, and no surprise because you talk to users on this. From our research side on our team, we really say multi cloud or hybrid cloud. Hybrid cloud means you've got your own data centers, as opposed to multi cloud could be any of them. There's a little bit of a Venn Diagram you could do between that. >> But I am prepared to be wrong as well. I'm a company of two people. I don't have a research department, that's called the spare time I get >> when I can't sleep at night. So I don't have data, I have anecadata. I can talk about individual use cases, but then I'm telling individual company stories that I'm generally not authorized to tell. So it's more a question now of starting to speak to a broader base. >> So just to finish on the thought from out team is everything from I have all of these pieces, and they're really not connected, and I'm just trying to get my arms around through some of the solutions. Like in the AWS world we're looking at the VMware on AWS, and the outpost type of solution. That pullout or what Azure does with Azure stack, and the like, or even company like IBM and Oracle, where they have a stack that can be both >> in the public cloud and the private cloud. Those kind of fully integrated pieces versus the right now I'm just putting applications in certain areas, and then how do I manage data protection, how do I manage security across all these environments. It is a heterogeneous mess that we had, and I spent a lot of my career trying to help us break down those silos, get away from the cylinders of excellence as we called them, and we worked more traditionalist. So how much are we fighting that? I will just tell you that most of the people we're going to have on theCUBE, probably aren't going to want to get into that. They'll be happy to talk about their piece, and how they work with this broad wonderful ecosystem, but we can drill into where Kubernetes fits. We've got the five year anniversary of Kubernetes. We'll be talking to some of the people that helped create this technology, and lots of the various pieces. So with that, Corey, want to give you the final take here, before we talk about the stickers, and some of the rest. >> Oh absolutely, I think it's a fascinating show. I think that they're the right people who are attending. To give valuable perspective that, quite frankly, you're not going to get almost anywhere else. It's just a fascinating blend of people from large companies, small companies, giant vendors, and of course the middleware types, who are trying to effectively stand between in many cases, customers and the raw vendors, for a variety of very good reasons. Partner strategies are important. I'm very curious to see what that becomes, and how that tends to unfold in the next two days. >> Okay, so theCUBE by the way, we're not only a broadcast, but we are part of the community. We understand this network, and that is why Corey and I, you know, we come with stickers. So we've got these lovely sticker and partnership with Women Who Go, that made this logo for us for the Seattle show, and I have a few left, so if you come on by. Corey has his platypus, last week in AWS. So come on by where we are, you get some stickers, and of course, hit us up on Twitter if you have any questions. We're always looking for the community, and the network to help us with the data, and help us pull everything apart. So for Corey Quinn, I'm Stu Miniman, two days of live wall to wall coverage >> will continue very soon, and thank you as always for watching theCUBE. (Fading Electronic Music)