>>Hey, welcome to the live panel. My name is Brett. I am your host, and indeed we are live. In fact, if you're curious about that, if you don't believe us, um, let's just show a little bit of the browser real quick to see. Yup. There you go. We're live. So, all right. So how this is going to work is I'm going to bring in some guests and, uh, in one second, and we're going to basically take your questions on the topic designer of the day, that continuous integration testing. Uh, thank you so much to my guests welcoming into the panel. I've got Carlos, Nico and Mandy. Hello everyone. >>Hello? All right, >>Let's go. Let's go around the room and all pretend we don't know each other and that the internet didn't read below the video who we are. Uh, hi, my name is Brett. I am a Docker captain, which means I'm supposed to know something about Docker. I'm coming from Virginia Beach. I'm streaming here from Virginia Beach, Virginia, and, uh, I make videos on the internet and courses on you to me, Carlos. Hey, >>Hey, what's up? I'm Carlos Nunez. I am a solutions architect, VMware. I do solution things with computers. It's fun. I live in Dallas when I'm moving to Houston in a month, which is where I'm currently streaming. I've been all over the Northeast this whole week. So, um, it's been fun and I'm excited to meet with all of you and talk about CIA and Docker. Sure. >>Yeah. Hey everyone. Uh, Nico, Khobar here. I'm a solution engineer at HashiCorp. Uh, I am streaming to you from, uh, the beautiful Austin, Texas. Uh, ignore, ignore the golden gate bridge here. This is from my old apartment in San Francisco. Uh, just, uh, you know, keeping that, to remember all the good days, um, that that lived at. But, uh, anyway, I work at Patrick Corp and I work on all things, automation, um, and cloud and dev ops. Um, and I'm excited to be here and Mandy, >>Hi. Yeah, Mandy Hubbard. I am streaming from Austin, Texas. I am, uh, currently a DX engineer at ship engine. Um, I've worked in QA and that's kind of where I got my, uh, my Docker experience and, um, uh, moving into DX to try and help developers better understand and use our products and be an advocate for them. >>Nice. Well, thank you all for joining me. Uh, I really appreciate you taking the time out of your busy schedule to be here. And so for those of you in chat, the reason we're doing this live, because it's always harder to do things live. The reason we're here is to answer a question. So we didn't come with a bunch of slides and demos or anything like that. We're here to talk amongst ourselves about ideas and really here for you. So we've, we obviously, this is about easy CII, so we're, we're going to try to keep the conversation around testing and continuous integration and all the things that that entails with containers. But we may, we may go down rabbit holes. We may go veer off and start talking about other things, and that's totally fine if it's in the realm of dev ops and containers and developer and ops workflows, like, Hey, it's, it's kinda game. >>And, uh, these people have a wide variety of expertise. They haven't done just testing, right? We, we live in a world where you all kind of have to wear many hats. So feel free to, um, ask what you think is on the top of your mind. And we'll do our best to answer. It may, might not be the best answer or the correct answer, but we're going to do our best. Um, well, let's get it start off. Uh, let's, let's get a couple of topics to start off with. Uh, th the, the easy CGI was my, one of my three ideas. Cause he's the, one of the things that I'm most excited about is the innovation we're seeing around easier testing, faster testing, automated testing, uh, because as much as we've all been doing this stuff for, you know, 15 years, since 20 years since the sort of Jenkins early days, um, it it's, it seems like it's still really hard and it's still a lot of work. >>So, um, let's go around the room real quick, and everybody can just kind of talk for a minute about like your experience with testing and maybe some of your pain points, like what you don't like about our testing world. Um, and we can talk about some pains, cause I think that will lead us to kind of talk about what, what are the things we're seeing now that might be better, uh, ideas about how to do this. I know for me, uh, testing, obviously there's the code part, but just getting it automated, but mostly getting it in the hands of developers so that they can control their own testing. And don't have to go talk to a person to run that test again, or the mysterious Jenkins platform somewhere. I keep mentioning Jenkins cause it's, it is still the dominant player out there. Um, so for me, I'm, I'm, I, I don't like it when I'm walking into a room and there's, there's only one or two people that know how the testing works or know how to make the new tests go into the testing platform and stuff like that. So I'm always trying to free those things so that any of the developers are enabled and empowered to do that stuff. So someone else, Carlos, anybody, um, >>Oh, I have a lot of opinions on that. Having been a QA engineer for most of my career. Um, the shift that we're saying is everyone is dev ops and everyone is QA. Th the issue I see is no one asked developers if they wanted to be QA. Um, and so being the former QA on the team, when there's a problem, even though I'm a developer and we're all running QA, they always tend to come to the one of the former QA engineers. And they're not really owning that responsibility and, um, and digging in. So that's kind of what I'm saying is that we're all expected to test now. And some people, well, some people don't know how it's, uh, for me it was kind of an intuitive skill. It just kind of fit with my personality, but not knowing what to look for, not knowing what to automate, not even understanding how your API end points are used by your front end to know what to test when a change is made. It's really overwhelming for developers. And, um, we're going to need to streamline that and, and hold their hands a little bit until they get their feet wet with also being QA. >>Right. Right. So, um, uh, Carlos, >>Yeah, uh, testing is like, Tesla is one of my favorite subjects to talk about when I'm baring with developers. And a lot of it is because of what Mandy said, right? Like a lot of developers now who used to write a test and say, Hey, QA, go. Um, I wrote my unit tests. Now write the rest of the test. Essentially. Now developers are expected to be able to understand how testing, uh, testing methodologies work, um, in their local environments, right? Like they're supposed to understand how to write an integration tasks federate into and tasks, a component test. And of course, how to write unit tests that aren't just, you know, assert true is true, right? Like more comprehensive, more comprehensive, um, more high touch unit tests, which include things like mocking and stubbing and spine and all that stuff. And, you know, it's not so much getting those tests. Well, I've had a lot of challenges with developers getting those tests to run in Docker because of usually because of dependency hell, but, um, getting developers to understand how to write tests that matter and mean something. Um, it's, it's, it can be difficult, but it's also where I find a lot of the enjoyment of my work comes into play. So yeah. I mean, that's the difficulty I've seen around testing. Um, big subject though. Lots to talk about there. >>Yeah. We've got, we've already got so many questions coming in. You already got an hour's worth of stuff. So, uh, Nico 81st thoughts on that? >>Yeah, I think I definitely agree with, with other folks here on the panel, I think from a, um, the shift from a skillset perspective that's needed to adopt the new technologies, but I think from even from, uh, aside from the organizational, um, and kind of key responsibilities that, that the new developers have to kinda adapt to and, and kind of inherit now, um, there's also from a technical perspective as there's, you know, um, more developers are owning the full stack, including the infrastructure piece. So that adds a lot more to the plate in Tim's oaf, also testing that component that they were not even, uh, responsible for before. Um, and, um, also the second challenge that, you know, I'm seeing is that on, you know, the long list of added, um, uh, tooling and, you know, there's new tool every other day. Um, and, um, that kind of requires more customization to the testing, uh, that each individual team, um, any individual developer Y by extension has to learn. Uh, so the customization, uh, as well as the, kind of the scope that had, uh, you know, now in conferences, the infrastructure piece, um, uh, both of act to the, to the challenges that we're seeing right now for, um, for CGI and overall testing, um, uh, the developers are saying, uh, in, in the market today. >>Yeah. We've got a lot of questions, um, about all the, all the different parts of this. So, uh, let me just go straight to them. Cause that's why we're here is for the people, uh, a lot of people asking about your favorite tools and in one of this is one of the challenges with integration, right? Is, um, there is no, there are dominant players, but there, there is such a variety. I mean, every one of my customers seems like they're using a different workflow and a different set of tools. So, and Hey, we're all here to just talk about what we're, what we're using, uh, you know, whether your favorite tools. So like a lot of the repeated questions are, what are your favorite tools? Like if you could create it from scratch, uh, what would you use? Pierre's asking, you know, GitHub actions sounds like they're a fan of GitHub actions, uh, w you know, mentioning, pushing the ECR and Docker hub and, uh, using vs code pipeline, I guess there may be talking about Azure pipelines. Um, what, what's your preferred way? So, does anyone have any, uh, thoughts on that anyone want to throw out there? Their preferred pipeline of tooling? >>Well, I have to throw out mine. I might as Jenkins, um, like kind of a honorary cloud be at this point, having spoken a couple of times there, um, all of the plugins just make the functionality. I don't love the UI, but I love that it's been around so long. It has so much community support, and there are so many plugins so that if you want to do something, you don't have to write the code it's already been tested. Um, unfortunately I haven't been able to use Jenkins in, uh, since I joined ship engine, we, most of our, um, our, our monolithic core application is, is team city. It's a dotnet application and TeamCity plays really well with.net. Um, didn't love it, uh, Ms. Jenkins. And I'm just, we're just starting some new initiatives that are using GitHub actions, and I'm really excited to learn, to learn those. I think they have a lot of the same functionality that you're looking for, but, um, much more simplified in is right there and get hubs. So, um, the integration is a lot more seamless, but I do have to go on record that my favorite CICT tools Jenkins. >>All right. You heard it here first people. All right. Anyone else? You're muted? I'm muted. Carlin says muted. Oh, Carla says, guest has muted themselves to Carlos. You got to unmute. >>Yes. I did mute myself because I was typing a lot, trying to, you know, try to answer stuff in the chat. And there's a lot of really dark stuff in there. That's okay. Two more times today. So yeah, it's fine. Yeah, no problem. So totally. And it's the best way to start a play more. So I'm just going to go ahead and light it up. Um, for enterprise environments, I actually am a huge fan of Jenkins. Um, it's a tool that people really understand. Um, it has stood the test of time, right? I mean, people were using Hudson, but 15 years ago, maybe longer. And, you know, the way it works, hasn't really changed very much. I mean, Jenkins X is a little different, but, um, the UI and the way it works internally is pretty familiar to a lot of enterprise environments, which is great. >>And also in me, the plugin ecosystem is amazing. There's so many plugins for everything, and you can make your own if you know, Java groovy. I'm sure there's a perfect Kotlin in there, but I haven't tried myself, but it's really great. It's also really easy to write, um, CIS code, which is something I'm a big fan of. So Jenkins files have been, have worked really well for me. I, I know that I can get a little bit more complex as you start to build your own models and such, but, you know, for enterprise enterprise CIO CD, if you want, especially if you want to roll your own or own it yourself, um, Jenkins is the bellwether and for very good reason now for my personal projects. And I see a lot on the chat here, I think y'all, y'all been agreed with me get hub actions 100%, my favorite tool right now. >>Um, I love GitHub actions. It's, it's customizable, it's modular. There's a lot of plugins already. I started using getting that back maybe a week after when GA and there was no documentation or anything. And I still, it was still my favorite CIA tool even then. Um, and you know, the API is really great. There's a lot to love about GitHub actions and, um, and I, and I use it as much as I can from my personal project. So I still have a soft spot for Travis CAI. Um, you know, they got acquired and they're a little different now trying to see, I, I can't, I can't let it go. I just love it. But, um, yeah, I mean, when it comes to Seattle, those are my tools. So light me up in the comments I will respond. Yeah. >>I mean, I, I feel with you on the Travis, the, I think, cause I think that was my first time experiencing, you know, early days get hub open source and like a free CIA tool that I could describe. I think it was the ammo back then. I don't actually remember, but yeah, it was kind of an exciting time from my experience. There was like, oh, this is, this is just there as a service. And I could just use it. It doesn't, it's like get hub it's free from my open source stuff. And so it does have a soft spot in my heart too. So yeah. >>All right. We've got questions around, um, cam, so I'm going to ask some questions. We don't have to have these answers because sometimes they're going to be specific, but I want to call them out because people in chat may have missed that question. And there's probably, you know, that we have smart people in chat too. So there's probably someone that knows the answer to these things. If, if it's not us, um, they're asking about building Docker images in Kubernetes, which to me is always a sore spot because it's Kubernetes does not build images by default. It's not meant for that out of the gate. And, uh, what is the best way to do this without having to use privileged containers, which privileged containers just implying that yeah, you, you, it probably has more privileges than by default as a container in Kubernetes. And that is a hard thing because, uh, I don't, I think Docker doesn't lie to do that out of the gate. So I don't know if anyone has an immediate answer to that. That's a pretty technical one, but if you, if you know the answer to that in chat, call it out. >>Um, >>I had done this, uh, but I'm pretty sure I had to use a privileged, um, container and install the Docker Damon on the Kubernetes cluster. And I CA I can't give you a better solution. Um, I've done the same. So, >>Yeah, uh, Chavonne asks, um, back to the Jenkins thing, what's the easiest way to integrate Docker into a Jenkins CICB pipeline. And that's one of the challenges I find with Jenkins because I don't claim to be the expert on Jenkins. Is there are so many plugins because of this, of this such a huge ecosystem. Um, when you go searching for Docker, there's a lot that comes back, right. So I, I don't actually have a preferred way because every team I find uses it differently. Um, I don't know, is there a, do you know if there's a Jenkins preferred, a default plugin? I don't even know for Docker. Oh, go ahead. Yeah. Sorry for Docker. And jacon sorry, Docker plugins for Jenkins. Uh, as someone's asking like the preferred or easy way to do that. Um, and I don't, I don't know the back into Jenkins that well, so, >>Well, th the new, the new way that they're doing, uh, Docker builds with the pipeline, which is more declarative versus the groovy. It's really simple, and their documentation is really good. They, um, they make it really easy to say, run this in this image. So you can pull down, you know, public images and add your own layers. Um, so I don't know the name of that plugin, uh, but I can certainly take a minute after this session and going and get that. Um, but if you really are overwhelmed by the plugins, you can just write your, you know, your shell command in Jenkins. You could just by, you know, doing everything in bash, calling the Docker, um, Damon directly, and then getting it working just to see that end to end, and then start browsing for plugins to see if you even want to use those. >>The plugins will allow more integration from end to end. Some of the things that you input might be available later on in the process for having to manage that yourself. But, you know, you don't have to use any of the plugins. You can literally just, you know, do a block where you write your shell command and get it working, and then decide if, for plugins for you. Um, I think it's always under important to understand what is going on under the hood before you, before you adopt the magic of a plugin, because, um, once you have a problem, if you're, if it's all a lockbox to you, it's going to be more difficult to troubleshoot. It's kind of like learning, get command line versus like get cracking or something. Once, once you get in a bind, if you don't understand the underlying steps, it's really hard to get yourself out of a bind, versus if you understand what the plugin or the app is doing, then, um, you can get out of situations a lot easier. That's a good place. That's, that's where I'd start. >>Yeah. Thank you. Um, Camden asks better to build test environment images, every commit in CII. So this is like one of those opinions of we're all gonna have some different, uh, or build on build images on every commit, leveraging the cash, or build them once outside the test pile pipeline. Um, what say you people? >>Uh, well, I I've seen both and generally speaking, my preference is, um, I guess the ant, the it's a consultant answer, right? I think it depends on what you're trying to do, right. So if you have a lot of small changes that are being made and you're creating images for each of those commits, you're going to have a lot of images in your, in your registry, right? And on top of that, if you're building those images, uh, through CAI frequently, if you're using Docker hub or something like that, you might run into rate limiting issues because of Docker's new rate, limiting, uh, rate limits that they put in place. Um, but that might be beneficial if the, if being able to roll back between those small changes while you're testing is important to you. Uh, however, if all you care about is being able to use Docker images, um, or being able to correlate versions to your Docker images, or if you're the type of team that doesn't even use him, uh, does he even use, uh, virgins in your image tags? Then I would think that that might be a little, much you might want to just have in your CIO. You might want to have a stage that builds your Docker images and Docker image and pushes it into your registry, being done first particular branches instead of having to be done on every commit regardless of branch. But again, it really depends on the team. It really depends on what you're building. It really depends on your workflow. It can depend on a number of things like a curse sometimes too. Yeah. Yeah. >>Once had two points here, you know, I've seen, you know, the pattern has been at every, with every, uh, uh, commit, assuming that you have the right set of tests that would kind of, uh, you would benefit from actually seeing, um, the, the, the, the testing workflow go through and can detect any issue within, within the build or whatever you're trying to test against. But if you're just a building without the appropriate set of tests, then you're just basically consuming almond, adding time, as well as all the, the image, uh, stories associated with it without treaty reaping the benefit of, of, of this pattern. Uh, and the second point is, again, I think if you're, if you're going to end up doing a per commit, uh, definitely recommend having some type of, uh, uh, image purging, um, uh, and, and, and garbage collection process to ensure that you're not just wasting, um, all the stories needed and also, um, uh, optimizing your, your bill process, because that will end up being the most time-consuming, um, um, you know, within, within your pipeline. So this is my 2 cents on this. >>Yeah, that's good stuff. I mean, those are both of those are conversations that could lead us into the rabbit hole for the rest of the day on storage management, uh, you know, CP CPU minutes for, uh, you know, your build stuff. I mean, if you're in any size team, more than one or two people, you immediately run into headaches with cost of CIA, because we have now the problem of tools, right? We have so many tools. We can have the CIS system burning CPU cycles all day, every day, if we really wanted to. And so you re very quickly, I think, especially if you're on every commit on every branch, like that gets you into a world of cost mitigation, and you probably are going to have to settle somewhere in the middle on, uh, between the budget, people that are saying you're spending way too much money on the CII platform, uh, because of all these CPU cycles, and then the developers who would love to have everything now, you know, as fast as possible and the biggest, biggest CPU's, and the biggest servers, and have the bills, because the bills can never go fast enough, right. >>There's no end to optimizing your build workflow. Um, we have another question on that. This is another topic that we'll all probably have different takes on is, uh, basically, uh, version tags, right? So on images, we, we have a very established workflow in get for how we make commits. We have commit shots. We have, uh, you know, we know get tags and there's all these things there. And then we go into images and it's just this whole new world that's opened up. Like there's no real consensus. Um, so what, what are your thoughts on the strategy for teams in their image tag? Again, another, another culture thing. Um, commander, >>I mean, I'm a fan of silver when we have no other option. Um, it's just clean and I like the timestamp, you know, exactly when it was built. Um, I don't really see any reason to use another, uh, there's just normal, incremental, um, you know, numbering, but I love the fact that you can pull any tag and know exactly when it was created. So I'm a big fan of bar, if you can make that work for your organization. >>Yep. People are mentioned that in chat, >>So I like as well. Uh, I'm a big fan of it. I think it's easy to be able to just be as easy to be able to signify what a major changes versus a minor change versus just a hot fix or, you know, some or some kind of a bad fix. The problem that I've found with having teams adopt San Bernardo becomes answering these questions and being able to really define what is a major change, what is a minor change? What is a patch, right? And this becomes a bit of an overhead or not so much of an overhead, but, uh, uh, uh, a large concern for teams who have never done versioning before, or they never been responsible for their own versioning. Um, in fact, you know, I'm running into that right now, uh, with, with a client that I'm working with, where a lot, I'm working with a lot of teams, helping them move their applications from a legacy production environment into a new one. >>And in doing so, uh, versioning comes up because Docker images, uh, have tags and usually the tax correlate to versions, but some teams over there, some teams that I'm working with are only maintaining a script and others are maintaining a fully fledged JAK, three tier application, you know, with lots of dependencies. So telling the script, telling the team that maintains a script, Hey, you know, you should use somber and you should start thinking about, you know, what's major, what's my number what's patch. That might be a lot for them. And for someone or a team like that, I might just suggest using commit shots as your versions until you figure that out, or maybe using, um, dates as your version, but for the more for the team, with the larger application, they probably already know the answers to those questions. In which case they're either already using Sember or they, um, or they may be using some other version of the strategy and might be in December, might suit them better. So, um, you're going to hear me say, it depends a lot, and I'm just going to say here, it depends. Cause it really does. Carlos. >>I think you hit on something interesting beyond just how to version, but, um, when to consider it a major release and who makes those decisions, and if you leave it to engineers to version, you're kind of pushing business decisions down the pipe. Um, I think when it's a minor or a major should be a business decision and someone else needs to make that call someone closer to the business should be making that call as to when we want to call it major. >>That's a really good point. And I add some, I actually agree. Um, I absolutely agree with that. And again, it really depends on the team that on the team and the scope of it, it depends on the scope that they're maintaining, right? And so it's a business application. Of course, you're going to have a product manager and you're going to have, you're going to have a product manager who's going to want to make that call because that version is going to be out in marketing. People are going to use it. They're going to refer to and support calls. They're going to need to make those decisions. Sember again, works really, really well for that. Um, but for a team that's maintaining the scripts, you know, I don't know, having them say, okay, you must tell me what a major version is. It's >>A lot, but >>If they want it to use some birds great too, which is why I think going back to what you originally said, Sember in the absence of other options. I think that's a good strategy. >>Yeah. There's a, there's a, um, catching up on chat. I'm not sure if I'm ever going to catch up, but there's a lot of people commenting on their favorite CII systems and it's, and it, it just goes to show for the, the testing and deployment community. Like how many tools there are out there, how many tools there are to support the tools that you're using. Like, uh, it can be a crazy wilderness. And I think that's, that's part of the art of it, uh, is that these things are allowing us to build our workflows to the team's culture. Um, and, uh, but I do think that, you know, getting into like maybe what we hope to be at what's next is I do hope that we get to, to try to figure out some of these harder problems of consistency. Uh, one of the things that led me to Docker at the beginning to begin with was the fact that it wa it created a consistent packaging solution for me to get my code, you know, off of, off of my site of my local system, really, and into the server. >>And that whole workflow would at least the thing that I was making at each step was going to be the same thing used. Right. And that, that was huge. Uh, it was also, it also took us a long time to get there. Right. We all had to, like Docker was one of those ones that decade kind of ideas of let's solidify the, enter, get the consensus of the community around this idea. And we, and it's not perfect. Uh, you know, the Docker Docker file is not the most perfect way to describe how to make your app, but it is there and we're all using it. And now I'm looking for that next piece, right. Then hopefully the next step in that, um, that where we can all arrive at a consensus so that once you hop teams, you know, okay. We all knew Docker. We now, now we're all starting to get to know the manifests, but then there's this big gap in the middle where it's like, it might be one of a dozen things. Um, you know, so >>Yeah, yeah. To that, to that, Brett, um, you know, uh, just maybe more of a shameless plug here and wanting to kind of talk about one of the things that I'm on. So excited, but I work, I work at Tasha Corp. I don't know anyone, or I don't know if many people have heard of, um, you know, we tend to focus a lot on workflows versus technologies, right. Because, you know, as you can see, even just looking at the chat, there's, you know, ton of opinions on the different tooling, right. And, uh, imagine having, you know, I'm working with clients that have 10,000 developers. So imagine taking the folks in the chat and being partnered with one organization or one company and having to make decisions on how to build software. Um, but there's no way you can conversion one or, or one way or one tool, uh, and that's where we're facing in the industry. >>So one of the things that, uh, I'm pretty excited about, and I don't know if it's getting as much traction as you know, we've been focused on it. This is way point, which is a project, an open source project. I believe we got at least, uh, last year, um, which is, it's more of, uh, it's, it is aim to address that really, uh, uh, Brad set on, you know, to come to tool to, uh, make it extremely easy and simple. And, you know, to describe how you want to build, uh, deploy or release your application, uh, in, in a consistent way, regardless of the tools. So similar to how you can think of Terraform and having that pluggability to say Terraform apply or plan against any cloud infrastructure, uh, without really having to know exactly the details of how to do it, uh, this is what wave one is doing. Um, and it can be applied with, you know, for the CIA, uh, framework. So, you know, task plugability into, uh, you know, circle CEI tests to Docker helm, uh, Kubernetes. So that's the, you know, it's, it's a hard problem to solve, but, um, I'm hopeful that that's the path that we're, you know, we'll, we'll eventually get to. So, um, hope, you know, you can, you can, uh, see some of the, you know, information, data on it, on, on HashiCorp site, but I mean, I'm personally excited about it. >>Yeah. Uh I'm to gonna have to check that out. And, um, I told you on my live show, man, we'll talk about it, but talk about it for a whole hour. Uh, so there's another question here around, uh, this, this is actually a little bit more detailed, but it is one that I think a lot of people deal with and I deal with a lot too, is essentially the question is from Cameron, uh, D essentially, do you use compose in your CIO or not Docker compose? Uh, because yes I do. Yeah. Cause it, it, it, it solves so many problems am and not every CGI can, I don't know, there's some problems with a CIO is trying to do it for me. So there are pros and cons and I feel like I'm still on the fence about it because I use it all the time, but also it's not perfect. It's not always meant for CIA. And CIA sometimes tries to do things for you, like starting things up before you start other parts and having that whole order, uh, ordering problem of things anyway. W thoughts and when have thoughts. >>Yes. I love compose. It's one of my favorite tools of all time. Um, and the reason why it's, because what I often find I'm working with teams trying to actually let me walk that back, because Jack on the chat asked a really interesting question about what, what, what the hardest thing about CIS for a lot of teams. And in my experience, the hardest thing is getting teams to build an app that is the same app as what's built in production. A lot of CGI does things that are totally different than what you would do in your local, in your local dev. And as a result of that, you get, you got this application that either doesn't work locally, or it does work, but it's a completely different animal than what you would get in production. Right? So what I've found in trying to get teams to bridge that gap by basically taking their CGI, shifting the CII left, I hate the shift left turn, but I'll use it. >>I'm shifting the CIO left to your local development is trying to say, okay, how do we build an app? How do we, how do we build mot dependencies of that app so that we can build so that we can test our app? How do we run tests, right? How do we build, how do we get test data? And what I found is that trying to get teams to do all this in Docker, which is normally a first for a lot of teams that I'm working with, trying to get them all to do all of this. And Docker means you're running Docker, build a lot running Docker, run a lot. You're running Docker, RM a lot. You ran a lot of Docker, disparate Docker commands. And then on top of that, trying to bridge all of those containers together into a single network can be challenging without compose. >>So I like using a, to be able to really easily categorize and compartmentalize a lot of the things that are going to be done in CII, like building a Docker image, running tests, which is you're, you're going to do it in CII anyway. So running tests, building the image, pushing it to the registry. Well, I wouldn't say pushing it to the registry, but doing all the things that you would do in local dev, but in the same network that you might have a mock database or a mock S3 instance or some of something else. Um, so it's just easy to take all those Docker compose commands and move them into your Yammel file using the hub actions or your dankest Bob using Jenkins, or what have you. Right. It's really, it's really portable that way, but it doesn't work for every team. You know, for example, if you're just a team that, you know, going back to my script example, if it's a really simple script that does one thing on a somewhat routine basis, then that might be a lot of overhead. Um, in that case, you know, you can get away with just Docker commands. It's not a big deal, but the way I looked at it is if I'm, if I'm building, if I build something that's similar to a make bile or rate file, or what have you, then I'm probably gonna want to use Docker compose. If I'm working with Docker, that's, that's a philosophy of values, right? >>So I'm also a fan of Docker compose. And, um, you know, to your point, Carlos, the whole, I mean, I'm also a fan of shifting CEI lift and testing lift, but if you put all that logic in your CTI, um, it changes the L the local development experience from the CGI experience. Versus if you put everything in a compose file so that what you build locally is the same as what you build in CGI. Um, you're going to have a better experience because you're going to be testing something more, that's closer to what you're going to be releasing. And it's also very easy to look at a compose file and kind of, um, understand what the dependencies are and what's happening is very readable. And once you move that stuff to CGI, I think a lot of developers, you know, they're going to be intimidated by the CGI, um, whatever the scripting language is, it's going to be something they're going to have to wrap their head around. >>Um, but they're not gonna be able to use it locally. You're going to have to have another local solution. So I love the idea of a composed file use locally, um, especially if he can Mount the local workspace so that they can do real time development and see their changes in the exact same way as it's going to be built and tested in CGI. It gives developers a high level of confidence. And then, you know, you're less likely to have issues because of discrepancies between how it was built in your local test environment versus how it's built in NCI. And so Docker compose really lets you do all of that in a way that makes your solution more portable, portable between local dev and CGI and reduces the number of CGI cycles to get, you know, the test, the test data that you need. So that's why I like it for really, for local dev. >>It'll be interesting. Um, I don't know if you all were able to see the keynote, but there was a, there was a little bit, not a whole lot, but a little bit talk of the Docker, compose V two, which has now built into the Docker command line. And so now we're shifting from the Python built compose, which was a separate package. You could that one of the challenges was getting it into your CA solution because if you don't have PIP and you got down on the binary and the binary wasn't available for every platform and, uh, it was a PI installer. It gets a little nerdy into how that works, but, uh, and the team is now getting, be able to get unified with it. Now that it's in Golang and it's, and it's plugged right into the Docker command line, it hopefully will be easier to distribute, easier to, to use. >>And you won't have to necessarily have dependencies inside of where you're running it because there'll be a statically compiled binary. Um, so I've been playing with that, uh, this year. And so like training myself to do Docker going from Docker dash compose to Docker space, compose. It is a thing I I'm almost to the point of having to write a shell replacement. Yeah. Alias that thing. Um, but, um, I'm excited to see what that's going, cause there's already new features in it. And it, these built kit by default, like there's all these things. And I, I love build kit. We could make a whole session on build kit. Um, in fact there's actually, um, maybe going on right now, or right around this time, there is a session on, uh, from Solomon hikes, the seat, uh, co-founder of Docker, former CTO, uh, on build kit using, uh, using some other tool on top of build kit or whatever. >>So that, that would be interesting for those of you that are not watching that one. Cause you're here, uh, to do a check that one out later. Um, all right. So another good question was caching. So another one, another area where there is no wrong answers probably, and everyone has a different story. So the question is, what are your thoughts on CII build caching? There's often a debate between security. This is from Quentin. Thank you for this great question. There's often a debate between security reproducibility and build speeds. I haven't found a good answer so far. I will just throw my hat in the ring and say that the more times you want to build, like if you're trying to build every commit or every commit, if you're building many times a day, the more caching you need. So like the more times you're building, the more caching you're gonna likely want. And in most cases caching doesn't bite you in the butt, but that could be, yeah, we, can we get the bit about that? So, yeah. Yeah. >>I'm going to quote Carlos again and say, it depends on, on, you know, how you're talking, you know, what you're trying to build and I'm quoting your colors. Um, yeah, it's, it's got, it's gonna depend because, you know, there are some instances where you definitely want to use, you know, depends on the frequency that you're building and how you're building. Um, it's you would want to actually take advantage of cashing functionalities, um, for the build, uh, itself. Um, but if, um, you know, as you mentioned, there could be some instances where you would want to disable, um, any caching because you actually want to either pull a new packages or, um, you know, there could be some security, um, uh, disadvantages related to security aspects that would, you know, you know, using a cache version of, uh, image layer, for example, could be a problem. And you, you know, if you have a fleet of build, uh, engines, you don't have a good grasp of where they're being cashed. We would have to, um, disable caching in that, in that, um, in those instances. So it, it would depend. >>Yeah, it's, it's funny you have that problem on both sides of cashing. Like there are things that, especially in Docker world, they will cash automatically. And, and then, and then you maybe don't realize that some of that caching could be bad. It's, it's actually using old, uh, old assets, old artifacts, and then there's times where you would expect it to cash, that it doesn't cash. And then you have to do something extra to enable that caching, especially when you're dealing with that cluster of, of CIS servers. Right. And the cloud, the whole clustering problem with caching is even more complex, but yeah, >>But that's, that's when, >>Uh, you know, ever since I asked you to start using build kits and able to build kit, you know, between it's it's it's reader of Boston in, in detecting word, you know, where in, in the bill process needs to cash, as well as, uh, the, the, um, you know, the process. I don't think I've seen any other, uh, approach there that comes close to how efficient, uh, that process can become how much time it can actually save. Uh, but again, I think, I think that's, for me that had been my default approach, unless I actually need something that I would intentionally to disable caching for that purpose, but the benefits, at least for me, the benefits of, um, how bill kit actually been processing my bills, um, from the builds as well as, you know, using the cash up until, you know, how it detects the, the difference in, in, in the assets within the Docker file had been, um, you know, uh, pretty, you know, outweigh the disadvantages that it brings in. So it, you know, take it each case by case. And based on that, determine if you want to use it, but definitely recommend those enabling >>In the absence of a reason not to, um, I definitely think that it's a good approach in terms of speed. Um, yeah, I say you cash until you have a good reason not to personally >>Catch by default. There you go. I think you catch by default. Yeah. Yeah. And, uh, the trick is, well, one, it's not always enabled by default, especially when you're talking about cross server. So that's a, that's a complexity for your SIS admins, or if you're on the cloud, you know, it's usually just an option. Um, I think it also is this, this veers into a little bit of, uh, the more you cash the in a lot of cases with Docker, like the, from like, if you're from images and checked every single time, if you're not pinning every single thing, if you're not painting your app version, you're at your MPN versions to the exact lock file definition. Like there's a lot of these things where I'm I get, I get sort of, I get very grouchy with teams that sort of let it, just let it all be like, yeah, we'll just build two images and they're totally going to have different dependencies because someone happened to update that thing and after whatever or MPM or, or, and so I get grouchy about that, cause I want to lock it all down, but I also know that that's going to create administrative burden. >>Like the team is now going to have to manage versions in a very much more granular way. Like, do we need to version two? Do we need to care about curl? You know, all that stuff. Um, so that's, that's kind of tricky, but when you get to, when you get to certain version problems, uh, sorry, uh, cashing problems, you, you, you don't want those set those caches to happen because it, if you're from image changes and you're not constantly checking for a new image, and if you're not pinning that V that version, then now you, you don't know whether you're getting the latest version of Davion or whatever. Um, so I think that there's, there's an art form to the more you pen, the less you have, the less, you have to be worried about things changing, but the more you pen, the, uh, all your versions of everything all the way down the stack, the more administrative stuff, because you're gonna have to manually change every one of those. >>So I think it's a balancing act for teams. And as you mature, I to find teams, they tend to pin more until they get to a point of being more comfortable with their testing. So the other side of this argument is if you trust your testing, then you, and you have better testing to me, the less likely to the subtle little differences in versions have to be penned because you can get away with those minor or patch level version changes. If you're thoroughly testing your app, because you're trusting your testing. And this gets us into a whole nother rant, but, uh, yeah, but talking >>About penny versions, if you've got a lot of dependencies isn't that when you would want to use the cash the most and not have to rebuild all those layers. Yeah. >>But if you're not, but if you're not painting to the exact patch version and you are caching, then you're not technically getting the latest versions because it's not checking for all the time. It's a weird, there's a lot of this subtle nuance that people don't realize until it's a problem. And that's part of the, the tricky part of allow this stuff, is it, sometimes the Docker can be almost so much magic out of the box that you, you, you get this all and it all works. And then day two happens and you built it a second time and you've got a new version of open SSL in there and suddenly it doesn't work. Um, so anyway, uh, that was a great question. I've done the question on this, on, uh, from heavy. What do you put, where do you put testing in your pipeline? Like, so testing the code cause there's lots of types of testing, uh, because this pipeline gets longer and longer and Docker building images as part of it. And so he says, um, before staging or after staging, but before production, where do you put it? >>Oh man. Okay. So, um, my, my main thought on this is, and of course this is kind of religious flame bait, so sure. You know, people are going to go into the compensation wrong. Carlos, the boy is how I like to think about it. So pretty much in every stage or every environment that you're going to be deploying your app into, or that your application is going to touch. My idea is that there should be a build of a Docker image that has all your applications coded in, along with its dependencies, there's testing that tests your application, and then there's a deployment that happens into whatever infrastructure there is. Right. So the testing, they can get tricky though. And the type of testing you do, I think depends on the environment that you're in. So if you're, let's say for example, your team and you have, you have a main branch and then you have feature branches that merged into the main branch. >>You don't have like a pre-production branch or anything like that. So in those feature branches, whenever I'm doing CGI that way, I know when I freak, when I cut my poll request, that I'm going to merge into main and everything's going to work in my feature branches, I'm going to want to probably just run unit tests and maybe some component tests, which really, which are just, you know, testing that your app can talk to another component or another part, another dependency, like maybe a database doing tests like that, that don't take a lot of time that are fascinating and right. A lot of would be done at the beach branch level and in my opinion, but when you're going to merge that beach branch into main, as part of a release in that activity, you're going to want to be able to do an integration tasks, to make sure that your app can actually talk to all the other dependencies that it talked to. >>You're going to want to do an end to end test or a smoke test, just to make sure that, you know, someone that actually touches the application, if it's like a website can actually use the website as intended and it meets the business cases and all that, and you might even have testing like performance testing, low performance load testing, or security testing, compliance testing that would want to happen in my opinion, when you're about to go into production with a release, because those are gonna take a long time. Those are very expensive. You're going to have to cut new infrastructure, run those tests, and it can become quite arduous. And you're not going to want to run those all the time. You'll have the resources, uh, builds will be slower. Uh, release will be slower. It will just become a mess. So I would want to save those for when I'm about to go into production. Instead of doing those every time I make a commit or every time I'm merging a feature ranch into a non main branch, that's the way I look at it, but everything does a different, um, there's other philosophies around it. Yeah. >>Well, I don't disagree with your build test deploy. I think if you're going to deploy the code, it needs to be tested. Um, at some level, I mean less the same. You've got, I hate the term smoke tests, cause it gives a false sense of security, but you have some mental minimum minimal amount of tests. And I would expect the developer on the feature branch to add new tests that tested that feature. And that would be part of the PR why those tests would need to pass before you can merge it, merge it to master. So I agree that there are tests that you, you want to run at different stages, but the earlier you can run the test before going to production. Um, the fewer issues you have, the easier it is to troubleshoot it. And I kind of agree with what you said, Carlos, about the longer running tests like performance tests and things like that, waiting to the end. >>The only problem is when you wait until the end to run those performance tests, you kind of end up deploying with whatever performance you have. It's, it's almost just an information gathering. So if you don't run your performance test early on, um, and I don't want to go down a rabbit hole, but performance tests can be really useless if you don't have a goal where it's just information gap, uh, this is, this is the performance. Well, what did you expect it to be? Is it good? Is it bad? They can get really nebulous. So if performance is really important, um, you you're gonna need to come up with some expectations, preferably, you know, set up the business level, like what our SLA is, what our response times and have something to shoot for. And then before you're getting to production. If you have targets, you can test before staging and you can tweak the code before staging and move that performance initiative. Sorry, Carlos, a little to the left. Um, but if you don't have a performance targets, then it's just a check box. So those are my thoughts. I like to test before every deployment. Right? >>Yeah. And you know what, I'm glad that you, I'm glad that you brought, I'm glad that you brought up Escalades and performance because, and you know, the definition of performance says to me, because one of the things that I've seen when I work with teams is that oftentimes another team runs a P and L tests and they ended, and the development team doesn't really have too much insight into what's going on there. And usually when I go to the performance team and say, Hey, how do you run your performance test? It's usually just a generic solution for every single application that they support, which may or may not be applicable to the application team that I'm working with specifically. So I think it's a good, I'm not going to dig into it. I'm not going to dig into the rabbit hole SRE, but it is a good bridge into SRE when you start trying to define what does reliability mean, right? >>Because the reason why you test performance, it's test reliability to make sure that when you cut that release, that customers would go to your site or use your application. Aren't going to see regressions in performance and are not going to either go to another website or, you know, lodge in SLA violation or something like that. Um, it does, it does bridge really well with defining reliability and what SRE means. And when you have, when you start talking about that, that's when you started talking about how often do I run? How often do I test my reliability, the reliability of my application, right? Like, do I have nightly tasks in CGI that ensure that my main branch or, you know, some important branch I does not mean is meeting SLA is meeting SLR. So service level objectives, um, or, you know, do I run tasks that ensure that my SLA is being met in production? >>Like whenever, like do I use, do I do things like game days where I test, Hey, if I turn something off or, you know, if I deploy this small broken code to production and like what happens to my performance? What happens to my security and compliance? Um, you can, that you can go really deep into and take creating, um, into creating really robust tests that cover a lot of different domains. But I liked just using build test deploy is the overall answer to that because I find that you're going to have to build your application first. You're going to have to test it out there and build it, and then you're going to want to deploy it after you test it. And that order generally ensures that you're releasing software. That works. >>Right. Right. Um, I was going to ask one last question. Um, it's going to have to be like a sentence answer though, for each one of you. Uh, this is, uh, do you lint? And if you lint, do you lent all the things, if you do, do you fail the linters during your testing? Yes or no? I think it's going to depend on the culture. I really do. Sorry about it. If we >>Have a, you know, a hook, uh, you know, on the get commit, then theoretically the developer can't get code there without running Melinta anyway, >>So, right, right. True. Anyone else? Anyone thoughts on that? Linting >>Nice. I saw an additional question online thing. And in the chat, if you would introduce it in a multi-stage build, um, you know, I was wondering also what others think about that, like typically I've seen, you know, with multi-stage it's the most common use case is just to produce the final, like to minimize the, the, the, the, the, the image size and produce a final, you know, thin, uh, layout or thin, uh, image. Uh, so if it's not for that, like, I, I don't, I haven't seen a lot of, you know, um, teams or individuals who are actually within a multi-stage build. There's nothing really against that, but they think the number one purpose of doing multi-stage had been just producing the minimalist image. Um, so just wanted to kind of combine those two answers in one, uh, for sure. >>Yeah, yeah, sure. Um, and with that, um, thank you all for the great questions. We are going to have to wrap this up and we could go for another hour if we all had the time. And if Dr. Khan was a 24 hour long event and it didn't sadly, it's not. So we've got to make room for the next live panel, which will be Peter coming on and talking about security with some developer ex security experts. And I wanted to thank again, thank you all three of you for being here real quick, go around the room. Um, uh, where can people reach out to you? I am, uh, at Bret Fisher on Twitter. You can find me there. Carlos. >>I'm at dev Mandy with a Y D E N D Y that's me, um, >>Easiest name ever on Twitter, Carlos and DFW on LinkedIn. And I also have a LinkedIn learning course. So if you check me out on my LinkedIn learning, >>Yeah. I'm at Nicola Quebec. Um, one word, I'll put it in the chat as well on, on LinkedIn, as well as, uh, uh, as well as Twitter. Thanks for having us, Brett. Yeah. Thanks for being here. >>Um, and, and you all stay around. So if you're in the room with us chatting, you're gonna, you're gonna, if you want to go to see the next live panel, I've got to go back to the beginning and do that whole thing, uh, and find the next, because this one will end, but we'll still be in chat for a few minutes. I think the chat keeps going. I don't actually know. I haven't tried it yet. So we'll find out here in a minute. Um, but thanks you all for being here, I will be back a little bit later, but, uh, coming up next on the live stuff is Peter Wood security. Ciao. Bye.

>>Hello, everyone. My name is John Jane Shake. I work from Iran. Tous Andi. I am here this afternoon very gratefully with Anders Vulcan, who is VP of technology strategy for cloud bees, a Miranda's partner and a well known company in the space that we're going to be discussing. Anders is also a well known entity in this space, which is continuous integration and continuous delivery. Um, you've seen already today some sessions that focus on specific implementations of continuous integration and delivery, um, particularly around security. And, uh, we think this is a critically important topic for anyone in the cloud space, particularly in this increasingly complicated kubernetes space. To understand, um, Miranda's thanks, Uh, if I can recapitulate our own our own strategy and, uh, and language that with complexity on uncertainty consistently increasing with the depth of the technology stacks that we have to deal with consistently, um um elaborating themselves that navigating this requires, um first three implementation of automation to increase speed, which is what C and C d do. Um, and that this speed ba leveraged toe let us ship and iterate code faster. Since that's ultimately the business that all of us air in one way or another. I would like, I guess, toe open this conversation by asking Onders what does he think of that core strategy? >>You know, I think you know, hitting the security thing, right? Right off the bat. You know, security doesn't happen by accident. You know, security is not something that you know, Like a like a server in a restaurant. You know, Sprinkles a little bit of Parmesan cheese right before they serve you the the food. It's not something you Sprinkle on at the end. It's something that has to be baked in from the beginning, not just in the kitchen, but in the supply chain from from from the very beginning. So the you know it's a feature, and if you don't build it, if you're not going to get an outcome that you're not gonna be happy with and I think the you know it's increasingly it's obviously increasingly important and increasingly visible. You know, the you know, the kinds of security problems that we that we see these days can can be, you know, life altering, for for people that are subject to them and and can be, you know, life or death for a company that that's exposed to it. So it's it's it's very, very important. Thio pay attention to it and to work to achieve that as an explicit outcome of the software delivery process. And I think, you know, C i n c d as as process as tooling as culture plays a big part in that because ah, lot of it has to do with, you know, set things up, right? Um run them the same way over and over, you know, get the machine going. Turned the crane. Now, you wanna you wanna make improvements over over time. You know, it's not just, you know, set it and forget it. You know, we got that set up. We don't have to worry about it anymore, but it really is a question of, you know, get the human out of the loop a lot of the times because if if you're dealing with configuring complex systems, you wanna make sure that you get them set up configured, you know, documented Ideally, you know, as code, whether it's a domain specific language or or something like that. And then that's something that you contest against that you can verify against that you can that you can difficult. And then that becomes the basis for for your, you know, for yourself, for pipelines, for your automation around, you know, kind of the software factory floor. So I think automation is a key aspect of that because it, you know, it takes a lot of the drudgery out of it, for one thing, So now the humans have more time to spend on doing on the on the creative things on the things that we're good at a zoo. Humans and it also make sure that, you know, one of the things that computers are really good at is doing the same thing over and over and over and over. Eso that kind of puts that responsibility into the hands of the entity that that knows how to do that well, which is which is the machine eso I think it's, you know, it's a light. It's a deep, deep topic, obviously, but, you know, automation plays into it. Uh, you know, small batch sizes play into it, you know, being able to test very frequently whether that's testing in. You're kind of you're C I pipeline where you're sort of doing building mostly unit testing, maybe some integration testing, but also in layering in the mawr. Serious kinds of testing in terms of security scanning, penetration, testing, vulnerability, scanning. You know those sorts of things which, you know, maybe you do on every single see I Bill. But most people don't because those things tend toe take a little bit longer on. And you know you want your sea ice cycle to be as fast as possible because that's really in service of the developer who has committed code and wants toe kind of see the thumbs up from the system saying it. And, um, so most organizations most organizations are are are focusing on, you know, making sure that there's a follow on pipeline to follow on set of tests that happened after the C I passes successfully and and that's, you know, where a lot of the security scanning and those sorts of things happen. >>It's a It's an interesting problem. I mean, you mentioned, um, what almost sounds like a Lawrence Lessig Ian kind of idea that, you know, code is law in enterprises today, code particularly see, I code ends up being policy, but At the same time, there's, Ah, it seems to me there's a an alternative peril, which is, as you increase speed, particularly when you become more and more dependent on things like containers and layering technology to provide components and capabilities that you don't have to build yourself to your build pipeline, that there are new vulnerabilities, potentially that creep in and can creep in despite automation. Zor at least 1st. 1st order automation is attempts toe to prevent them from creeping in. You don't wanna you wanna freeze people on a six month old version of a key container image. But on the other hand, if the latest version has vulnerabilities, that could be a problem. >>Yeah, I mean, it's, you know, it's it's a it's a it's a double edged sword. It's two sides of the same coin. I think you know, when I talked to a lot of security people, um, you know, people to do it for a living is supposed to mean I just talk about it, um, that Z not completely true. But, um, the ah, lot of times the problem is old vulnerabilities. The thing that I think keeps a lot of people up at night isn't necessarily that the thing at the tip of the releases for particular, you know, well known open source, library or something like that. But that's gonna burn you all the vast majority of the time. And I want to say, like, 80 85% of the time. The vulnerability is that you that you get hosed by are ones that have been known about for years. And so I think the if I had to pick. So if you know, in that sort of two sides of that coin, if I had to pick, I would say Be aggressive in making sure that your third party dependencies are updated frequently and and continuously right, because that is the biggest, biggest cause of of of security vulnerabilities when it comes to third party code. Um, now you know the famous saying, You know, move fast and break things Well, there's certain things you don't want to break. You know you don't want to break a radiation machine that's going to deliver radio radiotherapy to someone because that will endanger their health. So So those sorts of systems, you know, naturally or subject a little bit more kind of caution and scrutiny and rigor and process those sorts of things. The micro service that I run that shows my little avatar when I log in, that one probably gets a little less group. You know, Andre rightfully so. So I think a lot of it has to do. And somebody once said in a I think it was, Ah, panel. I was on a PR say conference, which was, which was kind of a wise thing to say it was Don't spend a million dollars protecting a $5 assets. You know, you wanna be smart and you wanna you wanna figure out where your vulnerabilities they're going to come from and in my experience, and and you know, what I hear from a lot of the security professionals is pay attention to your supply chain. You're you want to make sure that you're up to date with the latest patches of, of all of your third party, you know, open source or close source. It doesn't really matter. I mean, if anything, you know, open source is is more open. Eso You could inspect things a little bit better than the close source, but with both kinds of streams of code that you consume and and use. You wanna make sure that you're you're more up to date as opposed to a less up to date? Um, that generally will be better. Now, can a new version of the library cause problems? You know, introduce bugs? You know, those sorts of things? Yes. That's why we have tests. That's what we have automated tests, regression, sweets, You know, those sorts of things. And so you wanna, you know, you wanna live in a in a world where you feel the confidence as a as a developer, that if I update this library from, you know, one debt owed at 3 to 1 debt owed at 10 to pick up a bunch of, you know, bug fixes and patches and those sorts of things. But that's not going to break some on demand in the test suites that that will run against that ought to cover that that sort of functionality. And I'd rather be in that world of Oh, yeah, we tried to update to that, but it But it broke the tests and then have to go spend time on that, then say, Oh, it broke the test. So let's not update. And then six months later, you do find out. Oh, geez. There was a problem in one that owed at three. And it was fixed in one. That about four. If only we had updated. Um, you know, you look at the, um you look at some of the highest profile security breaches that are out there that you sort of can trace toe third party libraries. It's almost always gonna be that it was out of date and hadn't been patched. That's so that's my you know, opinionated. Take on that. Sure. >>What are the parts of modern C I c D. As opposed to what one would encounter 56 years ago? Maybe if we can imagine that is being before the micro services and containers revolution really took off. >>You know, I think e think you're absolutely right that, you know, not the whole world is not doing. See, I Yeah, and certainly the whole world is not doing city yet. Um, you know, I think you know, as you say, we kind of live in a little bit of an ivory tower. You know, we live in an echo chamber in a little bit of a bubble Aziz vendors in this space. The truth is that I would say less than 50% of the software organizations out there do real. See, I do real CD. The number's probably less than that. Um, you know, I don't have anything to back that up other than just I talked to a lot of folks and work with, you know, with a lot of organizations and like, Yeah, that team does see I that team does Weekly builds You know, those sorts of things. It's it's really all over the place, Onda. Lot of times there's There's definitely, in my experience, a high correlation there with the amount of time that a team or a code base has been around, and the amount of sort of modern technologies and processes and and and so on that are that are brought to it on. And that sort of makes sense. I mean, if you if you're starting with the green field with a blank sheet of paper, you're gonna adopt, you know, the technologies and the processes and the cultures of today. A knot of 5, 10 15 15 years ago, Um but but most organizations air moving in that direction. Right? Andi, I think you know what? What? What? What's really changed in the last few years is the level of integration between the various tools between the various pieces and the amount of automation that you could bring to bear. I mean, I you know, I remember, you know, five or 10 years ago having all kinds of conversations with customers and prospects and and people of conferences and so on and they said, Oh, yeah, we'd like to automate our our software development life cycle, but, you know, we can't We have a manual thing here. We have a manual thing there. We do this kind of testing that we can automate it, and then we have this system, but it doesn't have any guy. So somebody has to sit and click on the screen. And, you know, and I used to say e used to say I don't accept No for an answer of can you automate this right? Everything. Anything can be automated. Even if you just get the little drinking bird. You know that just pokes the mouse. Everyone something. You can automate it, and I Actually, you know, I had one customer who was like, Okay, and we had a discussion and and and and they said, Well, we had this old Windows tool. We Its's an obscure tool. It's no longer updated, but it's it's it's used in a critical part of the life cycle and it can't be automated. And I said, Well, just install one of those Windows tools that allows you to peek and poke at the, you know, mass with my aunt I said so I don't accept your answer. And I said, Well, unfortunately, security won't allow us to install those tools, Eh? So I had to accept No, at that point, but But I think the big change were one of the biggest changes that's happened in the last few years is the systems now have all I'll have a p i s and they all talk to each other. So if you've gotta, you know, if you if you've got a scanning tool, if you've got a deployment tool, if you have a deployment, you know, infrastructure, you know, kubernetes based or, you know, kind of sitting in front of our around kubernetes thes things. I'll talk to each other and are all automated. So one of the things that's happened is we've taken out a lot of the weight states. A lot of the pauses, right? So if you you know, if you do something like a value stream mapping where you sit down and I'll date myself here and probably lose some of the audience with this analogy. But if you remember Schoolhouse Rock cartoons in in the late seventies, early eighties, there was one which was one of my favorites, and and the guy who did the music for this passed away last year, sadly, But, uh, the it was called How a bill Becomes a Law and they personified the bill. So the bill, you know, becomes a little person and, you know, first time passed by the house and then the Senate, and then the president either signs me or doesn't and or he vetoes, and it really sort of did this and what I always talk about with respect to sort of value stream mapping and talking about your processes, put a GoPro camera on your source codes head, and then follow that source code all the way through to your customer understand all of the stuff that happens to it, including nothing, right? Because a lot of times in that elapsed time, nothing keeps happening, right. If we build software the way we were sorry. If we build cars the way we build software, we would install the radio in a car, and then we would park it in a corner of the factory for three weeks. And then we might remember to test the radio before we ship the car out to the customer. Right, Because that's how a lot of us still develop some for. And I think one thing that's changed in the in the last few years is that we don't have these kind of, Well, we did the bill. So now we're waiting for somebody to create an environment and rack up some hardware and install an operating system and install. You know, this that and the other. You know, that that went from manual to we use Scheffer puppet to do it, which then went to we use containers to do it, which then went to we use containers and kubernetes to do it. So whole swaths of elapsed time in our software development life cycles basically went to nothing, right and went to the point where we can weaken, weaken, configure them way to the left and and and follow them all the way through. And that the artifact that we're delivering isn't necessarily and execute herbal. It could be a container, right? So now that starts to get interesting for us in terms of being able to test against that container scan against that container, def. Against that container, Um, you know, and it, you know, it does bring complexity to in terms of now you've got a layered file system in there. Well, what all is in there, you know, And so there's tools for scanning those kinds of things, But But I think that one of the biggest things that's happened is a lot of the natural pause. Points are no longer natural. Pause points their unnatural pause points, and they're now just delays in yourself for delivery. And so what? What a lot of organizations are working on is kind of getting to the point where those sorts of things get get automated and connected, and that's now possible. And it wasn't 55 or 10 years ago. >>So It sounds like a great deal of the speed benefit, which has been quantified many different ways. But is once you get one of these systems working, as we've all experienced enormous, um, is actually done by collapsing out what would have been unused time in a prior process or non paralyze herbal stuff has been made parallel. >>I remember doing a, uh, spent some time with a customer, and they did a value stream mapping, and they they found out at the end that of the 30 days of elapsed time they were spending three days on task. Everything else was waiting, waiting for a build waiting foran install, waiting for an environment, waiting for an approval, having meetings, you know, those sorts of things. And I thought to myself, Oh, my goodness, you know, 90% of the elapsed time is doing nothing. And I was talking to someone Gene Kim, actually, and I said, Oh my God, it was terrible that these you know, these people are screwed and he says, 0 90%. That's actually pretty good, you know? So So I think you know, if you if you think today, you know, if you If you if you look at the teams that are doing just really pure continuous delivery, you know, write some code committed, gets picked up by the sea ice system and passes through CIA goes through whatever coast, see I processing, you need to do security scanning and so on. It gets staged and it gets pushed into production. That stuff can happen in minutes, right? That's new. That's different. Now, if you do that without having the right automated gates in place around security and and and and those sorts of things you know, then you're living a little bit dangerously, although I would argue not necessarily any more dangerously, than just letting that insecure coat sit around for a week before your shipment, right? It's not like that problem is going to fix itself if you just let it sit there, Um, but But, you know, you definitely operated at a higher velocity. Now that's a lot of the benefit that you're tryingto trying to get out of it, right? You can get stuff out to the market faster, or if you take a little bit more time, you get more out to the market in, in in the same amount of time you could turn around and fix problems faster. Um, if you have a vulnerability, you can get it fixed and pushed out much more quickly. If you have a competitive threat that you need to address, you can you know, you could move that that much faster if you have a critical bug. You know, I mean, all security issues or bugs, sort of by definition. But, you know, if you have a functionality bug, you can you can get that pushed out faster. Eso So I think kind of all factors of the business benefit from from this increase in speed. And I think developers due to because anybody you know, any human that has a context switch and step away from something for for for, you know, duration of time longer than a few minutes, you know, you're gonna you're gonna you're gonna you're gonna have to load back up again. And so that's productivity loss. Now, that's a soft cost. But man, is it Is it expensive and is a painful So you see a lot of benefit there. Think >>if you have, you know, an organization that is just starting this journey What would you ask that organization to consider in orderto sort of move them down this path? >>It's by far the most frequent and almost always the first question I get at the end of the talk or or a presentation or something like that is where do we start? How do I know where to start? And and And there's a couple of answers to that. What one is Don't boil the ocean, right? Don't try to fix everything all at once. You know that because that's not agile, right? The be agile about your transformation Here, you know, pick, pick a set of problems that you have and and make a, you know, basically make a burn down list and and do them in order. So find find a pain point that you have right and, you know, just go address that and and try to make it small and actionable and especially early on when you're trying to affect change. And you're tryingto convinced teams that this is the way to go and you may have some naysayers, or you may have people who are skeptical or have been through these processes before that have been you know failures released, not the successes that they that they were supposed to be. You know, it's important to have some wind. So what I always say is look, you know, if you have a pebble in your shoe, you've got a pain point. You know how to address that. You know, you're not gonna address that by changing out your wardrobe or or by buying a new pair of shoes. You know, you're gonna address that by taking your shoe off, shaking it until the pebble falls out there putting the shoe back on. So look for those kinds of use cases, right? So if you're engineers are complaining that whenever I check in the build is broken and we're not doing see, I well, then let's look at doing C I Let's do see eye, right? If you're not doing that. And for most organizations, you know, setting up C I is a very manageable, very doable thing. There's lots of open source tooling out there. There's lots of commercial tooling out there. Thio do that to do it for small teams to do it for large teams and and everything in between. Um, if the problem is Gosh, Every time we push a change, we break something. You know where every time something works in staging it doesn't work in production. Then you gotta look at Well, how are these systems being configured? If you're If you're configuring them manually, stop automate the configuration of them. Um, you know, if you're if you're fixing system manually, don't you know, as a friend of mine says, don't fix, Repave? Um, you know, you don't wanna, you know, there's a story of, you know how how Google operates in their data centers. You know, they don't they don't go look for a broken disk drive and swap it out. You know, when it breaks, they just have a team of people that, like once a month or something, I don't know what the interval is. They just walked through the data center and they pull out all the dead stuff and they throw it out, and what they did was they assume that if the scale that they operate, things are always going to break physical things are always going to break. You have to build a software to assume that breakage and any system that assumes that we're going to step in when a disk drive is broken and fix it so that we can get back to running just isn't gonna work at scale. There's a similarity. There's sort of ah, parallel to that in in software, which is you know, any time you have these kinds of complex systems, you have to assume that they're gonna break and you have to put the things in place to catch those things. The automated testing, whether it's, you know, whether you have 10,000 tests that you that you've written already or whether you have no tests and you just need to go right, your first test that that journey, you've got to start somewhere. But my answer thio their questions generally always just start small, pick a very specific problem. Build a plan around it, you know, build a burned down list of things that you wanna address and just start working your way down that the same way that you would for any, you know, kind of agile project, your transformation of your own processes of your own internal systems. You should use agile processes for those as well, because if you if you go off for six months and and build something. By the time you come back, it's gonna be relevant. Probably thio the problems that you were facing six months ago. >>A Then let's consider the situation of, ah, company that's using C I and maybe sea ice and C d together. Um, and they want to reach what you might call the next level. Um, they've seen obvious benefits they're interested in, you know, in increasing their investment in, you know and cycles devoted to this technology. You don't have to sell them anymore, but they're looking for a next direction. What would you say that direction should be? I >>think oftentimes what organizations start to do is they start to look at feedback loops. So on DAT starts to go into the area of sort of metrics and analytics and those sorts of things. You know what we're we're always concerned about? You know, we're always affected by things like meantime to recovery. Meantime, the detection, what are our cycle times from, you know, ideation, toe codecommit. What's the cycle? Time from codecommit the production, those sorts of things. And you know you can't change what you don't measure eso so a lot of times the next step after kind of getting the rudimentary zoo of C I Orsini or some combination of both in places start to measure. Stop you, Um, and and then but But there. I think you know, you gotta be smart about it, because what you don't want to do is kind of just pull all the metrics out that exists. Barf them up on the dashboard. And the giant television screens say boom metrics, right. You know, Mike, drop go home. That's the wrong way to do it. You want to use metrics very specifically to achieve outcomes. So if you have an outcome that you want to achieve and you can tie it to a metric start looking at that metric and start working that problem once you saw that problem, you can take that metric. And you know, if that's the metric you're showing on the big you know, the big screen TV, you can pop that off and pick the next one and put it up there. I I always worry when you know a little different when you're in a knock or something like that. When when you're looking at the network stuff and so on. But I'm always leery of when I walk into to a software development organization. You know, just a Brazilian different metrics, this whole place because they're not all relevant. They're not all relevant at the same time. Some of them you wanna look at often, some of them you just want to kind of set an alarm on and make sure that, you know, I mean, you don't go down in your basement every day to check that the sump pump is working. What you do is you put a little water detector in there and you have an alarm go off if the water level ever rises above a certain amount. Well, you want to do the same thing with metrics, right? Once you've got in the water out of your basement, you don't have to go down there and look at it all the time. You put the little detector in, and then you move on and you worry about something else. And so organizations as they start to get a little bit more sophisticated and start to look at the analytics, the metrics, um, start to say, Hey, look, if our if our cycle time from from, you know, commit to deploy is this much. And we want it to be this much. What happens during that time, And where can we take slices out of that? You know, without without affecting the outcomes in terms of quality and so on, or or if it's, you know, from from ideation, toe codecommit. You know what? What can we do there? Um, you start to do that. And and then as you get those sort of virtuous cycles of feedback loops happening, you know, you get better and better and better, but you wanna be careful with metrics, you know, you don't wanna, you know, like I said, you don't wanna barf a bunch of metrics up just to say, Look, we got metrics. Metrics are there to serve a particular outcome. And once you've achieved that outcome, and you know that you can continue to achieve that outcome, you turn it into an alarm or a trigger, and you put it out of sight. And you know that. You know, you don't need to have, like, a code coverage metric prominently displayed you you pick a code coverage number that you're happy with you work to achieve that. Once you achieve it, you just worry about not going below that threshold again. So you can take that graph off and just put a trigger on this as if we ever get below this, you know, raising alarm or fail a build or fail a pipeline or something like that and then start to focus on improving another man. Uh, or another outcome using another matter >>makes enormous sense. So I'm afraid we are getting to be out of time. I want to thank you very much on this for joining us today. This has been certainly informative for me, and I hope for the audience, um, you know, thank you very, very much for sharing your insulin.

>>In late 2009 when the industry was just beginning to offer so-called converged infrastructure, CI Nutanix was skating to the puck, so to speak, meaning unlike conversion infrastructure, which essentially bolted together compute and networking and storage into a single skew that was very hardware centric. Nutanix was focused on creating HCI hyperconverged infrastructure, which was a software led architecture that unified the key elements of data center infrastructure. Now, while both approaches saved time and money, HCI took the concept to new heights of cost savings and simplicity. Hyperconverged infrastructure became a staple of private clouds creating a cloudlike experience. OnPrem. As the public cloud evolved and grew, more and more customers are now taking a cloud first approach to it. So the challenge becomes how do you remodel your IT house so that you can connect your on-prem workloads to the cloud, to both simplify cloud migration, while at the same time creating an identical experience across your estate? >>Hello, and welcome to this special program, Accelerate Hybrid Cloud with Nutanix and Microsoft Made Possible by By Nutanix and produced by the Cube. I'm Dave Ante, one of your hosts today. Now, in this session, we'll hear how Nutanix is evolving its initial vision of simplifying infrastructure, deployment and management to support modern applications by partnering with Microsoft to enable that consistent experience that we talked about earlier, to extend hybrid cloud to Microsoft Azure and take advantage of cloud native tooling. Now, what's really important to stress here, and you'll hear this in our second segment, substantive engineering work has gone into this partnership. A lot of partnerships are sealed with a press release. We sometimes call it a Barney deal. You know, I love you, you love me. Like Barney, the once popular children's dinosaur character. We dig into the critical engineering aspects that enable that seamless connection between on-prem infrastructure and the public cloud. >>Now, in our first segment, Lisa Martin talks to Alro Salise, who is the vice president of Global ISD Commercial Solutions at Microsoft, and Michael Les Chica, who is the vice president of business development for the cloud and database partner ecosystem at Nutanix. Now, after that, Lisa will kick it back to me in our Boston studios to speak with Eric Lockard, who is the corporate vice president of Microsoft Azure specialized, along with Thomas Cornell, who is the senior vice president of products at Nutanix. And Indu Carey, who's the senior vice president of of engineering for NCI and NNC two at Nutanix. And we'll dig deeper into the announcement and it's salient features. Thanks for being with us. We hope you enjoy the program. Over to Lisa. >>Hi everyone. Welcome to our event Accelerate Hybrid Cloud with Nutanix and Microsoft. I'm your host Lisa Martin, and I've got two great guests here with me to give you some exciting news. Please welcome Alva Salise, the Vice President of Global ISD Commercial Solutions at Microsoft, and Michael Les Chika, VP of Business Development Cloud and database partner ecosystem at Nutanix. Guys, it's great to have you on the program. Thanks so much for joining me today. Great to be here. >>Thank you, Lisa. Looking forward, >>Yeah, so let's go ahead and start with you. Talk to me from your lens, what are you seeing in terms of the importance of the role of the the ISV ecosystem and really helping customers make their business outcomes successful? >>Oh, absolutely. Well, first of all, thank you for the invitation and thank you Michael and the Nutanix team for the partnership. The the ISV ecosystem plays a critical role as we support our customers and enable them in their data transformation journeys to create value, to move at their own pace, and more important to be sure that every one of them, as they transform themselves, have the right set of solutions for the long term with high differentiation, cost effectiveness and resiliency, especially given the times that we're living. >>Yeah, that resiliency is getting more and more critical as each day goes on. Ava was sticking with you. We got Microsoft Ignite going on today. What are some of the key themes that we should expect this year and how do they align to Microsoft's vision and strategy? >>Ah, great question. Thank you. When you think about it, we wanna talk about the topics that are very relevant and our customers have asked us to go deeper and, and share with them. One of them, as you may imagine, is how can we do more with less using Azure, especially given the current times that we're living in the, the business context has changed so much, they have different imperative, different different amount of pressure and priorities. How can we help? How can we combine the platform, the value that Microsoft can bring and our Microsoft ISV partner ecosystem to deliver more value and enable them to have their own journey? Actually, in that frame, if I may, we are making this announcement today with Nutanix. I, the Nutanix cloud clusters are often the fastest way on which customers will be able to do that journey into the cloud because it's very consistent with environments that they already know and use on premise. And once they go into the cloud, then they have all the benefit of scale, agility, resiliency, security, and cost benefits that they're looking for. So that topic and this type of announcements will be a big part of what we doing. Ignite, >>Exciting. Michael, let's bring you into the conversation now. Big milestone of our RDTs that the general availability of Nutanix Cloud clusters on Azure. Talk to us about that from Nutanix's perspective and also gimme a little bit of color, Michael, on the partnership, the relationship. >>Yeah, sure, absolutely. So we actually entered a partnership couple years ago, so we've been working on this solution quite a while, but really our ultimate goal from day one was really to make our customers journeys to hybrid cloud simpler and faster. So really for both companies, I think our goal is really being that trusted partner for our customers in their innovation journey. And as mentioned, you know, in the current macroeconomic conditions, really our customers really care about, but they have to be mindful of their bottom line as well. So they're really looking to leverage their existing investments in technology skill sets and leverage the most out of that. So the things like, for example, cost to operations and keeping those things consistent, cost on premises and the cloud are really important as customers are thinking about growth initiatives that they wanna implement. And of course, going to Azure public cloud is an important one as they think about flexibility, scale and modernizing their apps. >>And of course, as we look at the customer landscape, a lot of customers have an on on footprint, right? Whether that's for regulatory reasons for business or other technical reasons. So hybrid cloud has really become an ideal operating model for a lot of the customers that we see today. So really our partnership with Microsoft is critical because together, I really do see our US together simplifying that journey to the public cloud and making sure that it's not only easy but secure and really seamless. And really, I see our partnership as bringing the strengths of each company together, right? So Nutanix, of course, is known in the past versus hyperconverge infrastructure and really breaking down those silos between networking, compute, storage, and simplifying that infrastructure and operations. And our customers love that for the products and our, our NPS score of 90 over the last seven years. And if you look at Azure, at Microsoft, they're truly best in class cloud infrastructure with cutting edge services and innovation and really global scale. So when you think about those two combinations, right, that's really powerful for customers to be able to take their applications and whether they're on or even, and really combining all those various hybrid scenarios. And I think that's something that's pretty unique that we're to offer customers. >>Let's dig into that uniqueness of our, bringing you back into the conversation. You guys are meeting customers where they are helping them to accelerate their cloud transformations, delivering that consistency, you know, whether they're on-prem in Azure, in in the cloud. Talk to me about, from Microsoft's perspective about the significance of this announcement. I understand that the, the preview was oversubscribed, so the demand from your joint customers is clear. >>Thank you, Lisa. Michael, personally, I'm very proud and at the company we're very proud of the world that we did together with Nutanix. When you see two companies coming together with the mission of empowering customers and with the customer at the center and trying to solve real problems in this case, how to drive hybrid cloud and what is the best approach for them, opening more opportunities is, is, is extremely inspiring. And of course the welcome reception that we have from customer reiterates that we generating that value. Now, when you combine the power of Azure, that is very well known by resiliency, the scale, the performance, the elasticity, and the range of services with the reality of companies that might have hundreds or even thousands of different applications and data sources, those cloud journeys are very different for each and every one of them. So how do we combine our capabilities between Nutanix and Microsoft to be sure that that hybrid cloud journey that every one is gonna take can be simplified, you can take away the risk, the complexity on that transformation creates tones of value. >>And that's what a customers are asking us today. Either because they're trying to move and modernize their environment to Azure, or they're bringing their, you know, a enable ordinate services and cluster and data services on premise to a Nutanix platform, we together can combine and solve for that adding more value for any scenario that customers may have. And this is not once and done, this is not that we building, we forget it. It's a partnership that keeps evolving and also includes work that we do with our solution sales alliances that go to market seems to be sure that the customers have diverse service and support to make, to create the outcomes that they're asking us to deliver. >>Talk to me a little bit about the customers that were in the beta, as we mentioned, Alva, the, the preview was oversubscribed. So as I talked about earlier, the demand is clearly there. Talk to me about some of the customers in beta, you can even anonymize them or maybe talk about them by industry, but what, what were some of the, the key things they came to these two companies looking to, to solve, get to the cloud faster, be able to deliver the same sets of services with familiarity so that from a, they're able to do more with less? >>Maybe I could take that one out of our abital lines. It did. It means, but yeah, so like, like we, like you mentioned Lisa, you know, we've had a great preview oversubscribe, we had lots of, of cu not only customers, but also partners battle testing the solution. And you know, we're obviously very pleased now to have GN offered to everyone else, but one of our customers, Camper J was really looking forward to seeing how do they leverage Ncq and Azure to, like I mentioned, reduce that work workload, my, my migration and a risk for that and making sure, hey, some of the applications, maybe we are going to go and rewrite them, refactor them to take them natively to Azure. But there's others where we wanna lift and shift them to Azure. But like I mentioned, it's not just customers, right? We've been working with partners like PCs and Citrix where they share the same goal as Microsoft and Nutanix provides that superior customer experience where whatever the operating model might be for that customer. So they're going to be leveraging NC two on Azure to really provide those hybrid cloud experiences for their solutions on top of building on top of the, the work that we've done together. >>So this really kind of highlights the power of that Alva, the power of the ISV ecosystem and what you're all able to do together to really help customers achieve the outcomes that they individually need. >>A absolutely, look, I mean, we strongly believe that when you partner properly with an V you get to the, to the magical framework, one plus one equals three or more because you are combining superpowers and you are solving the problem on behalf of the customer so they can focus on their business. And this is a wonderful example, a very inspiring one where when you see the risk, the complexity that all these projects normally have, and Michael did a great job framing some of them, and the difference that they have now by having NC to on Azure, it's night and day. And we are fully committed to keep driving this innovation, this partnership on service of our customers and our partner ecosystem because at the same time, making our partners more successful, generating more value for customers and for all of us. >>Abar, can you comment a little bit on the go to market? Like how, how do your joint customers engage? What does that look like from their perspective? >>You know, when you think about the go to market, a lot of that is we have, you know, teams all over the world that will be aligned and working together in service of the customer. There is marketing and demand generation that will be done, that will be also work on enjoying opportunities that we will manage as well as a very tight connection on projects to be sure that the support experience for customers is well aligned. I don't wanna go into too much detail, but I will like to guarantee that our intent is not only to create an incredible technological experience, which the, the development teams are done, but also a great experience for the customers that are going through these projects, interacting with both teams that will work as one in service to empower the customer to achieve the outcomes that they need. >>Yeah, and just to comment maybe a little bit more on what Albar said, you know, it's not just about the product integration or it's really the full end to end experience for our customers. So when we embarked on this partnership with Microsoft, we really thought about what is the right product integration and with our engineering teams, but also how do we go and talk to customers with value prop together and all the way down through to support. So we actually been worked on how do we have a single joint support for our customers. So it doesn't really matter how the customer engages, they really see this as an end to end single solution across two companies. >>And that's so critical given just the, the natural challenges that that organizations face and the dynamics of the macro economic environment that we're living in. For them, for customers to be able to have that really seamless single point of interaction, they want that consistent experience on-prem to the cloud. But from an engagement perspective that you're, what sounds like what you're doing, Michael and Avaro is, is goes a long way to really giving customers a much more streamlined approach so that they can be laser focused on solving the business problems that they have, being competitive, getting products to market faster and all that good stuff. Michael, I wonder if you could comment on maybe the cultural alignment that Nutanix and Microsoft have. I know Microsoft's partner program has been around for decades and decades. Michael, what does that cultural alignment look like from, you know, the sales and marketing folks down to engineering, down to support? >>Yeah, I think honestly that was, that was something that kind of fit really well and we saw really a long alignment from day one. Of course, you know, Nutanix cares a lot about our customer experience, not just within the products, but again, through the entire life cycle to support and so forth. And Microsoft's no different, right? There's a huge emphasis on making sure that we provide the best customer experience and that we're also focusing on solving real world customer problems, right? And really focusing on the biggest problems that customers have. So really culturally it felt, it felt really natural. It felt like we were a single team, although it's, you know, two bar organizations working together, but I really felt like a single team working day in, day out on, on solving customer problems together. >>Yeah, >>Let, go ahead. >>No, I would say, well say Michael, the, the one element that we complement, the, I think the answer was super complete, is the, the fact that we work together from the outside in, look at it from the customer lenses is extremely powerful and inspire, as I mentioned, because that's what it's all about. And when you put the customer at the center, everything else falls in part on its its own place very, very quickly. And then it's hard work and innovation and, you know, doing what we do best, which is combining over superpowers in service of that customer. So that was the piece that, you know, I, I cannot emphasize enough how inspiring he's been. And again, the, the response for the previous is a great example of the opportunity that we have in there. >>And you've taken a lot of complexity out of the customer environment and I can imagine that the GA of Nutanix cloud clusters on Azure is gonna be a huge benefit for customers in every industry. Last question guys, I wanna get both your perspectives on Michael, we'll start with you and then Lvra will wrap with you. What's next? Obviously a lot of exciting stuff. What's next for the partnership of these, these two superheroes together, Michael? >>Yeah, so I think our goal doesn't change, right? I think our North star is to continue to make it easy for our customers to adopt, migrate and modernize their applications, leveraging Nutanix and Microsoft Azure, right? And I think NC two and Azure is just the start of that. So kind of maybe more immediate, like, you know, we mentioned obviously we have, we announced the ga that's J in Americas, but kind of the next more immediate step over the next few months look for us to continue expanding beyond Americas and making sure that we have support across all the global regions. And then beyond that, you know, again, as of our mentioned, it's working from kind of the s backwards. So we're, we're not, no, we're not waiting for ega. We're already working on the next set of solutions saying what are other problems that customer facing, especially across, they're running their workload cross on premises and public cloud, and what are the next set of solutions that we can deliver to the market to solve those real challenges for. >>It sounds really strongly that, that the partnership here, we're talking about Nutanix and Microsoft, it's really Nutanix and Microsoft with the customer at this center. I think you've both done a great job of articulating that there's laser focus there. Our last word to you, what excites you about the momentum that Microsoft and Nutanix have for the customers? >>Well, thank you Lisa. Michael, I will tell you, when you hear the customer feedback on the impact that you're having, that's the most inspiring part because you know you're generating value, you know, you're making a difference, especially in these complex times when the, the partnership gets tested where the, the right, you know, relationship gets built. We're being there for customers is extremely inspiring. Now, as Michael mentioned, this is all about what customer needs and how do we go even ahead of the game, being sure that we're ready not for what is the problem today, but the opportunities that we have tomorrow to keep working on this. We have a huge TA task ahead to be sure that we bring this value globally in the right way with the right quality. Every word, which is a, is never as small fist as you may imagine. You know, the, the world is a big place, but also the next wave of innovations that will be customer driven to keep and, and raise the bar on how, how much more value can we unlock and how much empowerment can we make for the customer to keep in innovating at their own pace, in their own terms. >>Absolutely that customer empowerment's key. Guys, it's been a pleasure talking to you about the announcement Nutanix cloud clusters on Azure of our Michael, thank you for your time, your inputs and helping us understand the impact that this powerhouse relationship is making. >>Thank you for having Lisa and thank you AAR for joining >>Me. Thank you Lisa, Michael, it's been fantastic. I looking forward and thank you to the audience for being here with us. Yeah, stay >>Tuned. Thanks to the audience. Exactly. And stay tuned. There's more to come. We have coming up next, a deeper conversation on the announcement with Dave and product execs from both Microsoft. You won't wanna.

>>And welcome to the DockerCon cube cover here on the main stage. So HIRA RA development manager at J Frogg. Welcome to the cube. You guys have been on many times, uh, with J Frogg on the cube, great product you guys are doing great. Congratulations on all the six. Thanks for coming on the cube. >>Thank you. Thank you for having >>Me. So I'm really interested in talking about the supply chain, uh, package management, supply chain, and software workflow, huge discussion. This is one of the hottest issues that's being solved on by, with, with in DevOps and DevSecOps in, in the planet. It's all over the, all over the news, a real challenge, open source, growing so fast and so successful with cloud scale and with automation, as you guys know, you gotta ha you gotta know what's trusted, so you gotta build trust into the, the product itself. So developers don't have to do all the rework. Everyone kind of knows this right now, and this is a key solve problem you guys are solving. So I gotta ask you, what is the package management issue? Why is it such an important topic when you're talking about security? >>Yeah. Uh, so if you look at, uh, look at how software is built today, about 80 to 90% of that is open source. And currently the way we, the way we pull those open source libraries, we just, we just have blind trust in, in repositories that are central, and we rely on whatever mechanism they have built to, to establish that trust, uh, with the developer who is building it. And from, from our experience, uh, we have learned that that is not sufficient, uh, that is not sufficient to tell us that that particular developer built that end product and, uh, whatever code that they build is actually coming out in the end product. So we need, we need something to bridge that gap. We need, we need a trustworthy mechanism there to bridge that gap. And there are, there are a few other, uh, elements to it. >>Um, all these center depositories are prone to, uh, single point of failures. And, you know, in, we have all experience what happens when one of those goes down and how it stops production and how it, how it stops just software, uh, development, right? And we, what we are working on is how do we build a system where we, we can actually have, uh, liquid software as a reality and just continue to build software, regardless of all these systems of being live all the time, uh, and also have a, an implicit, uh, way of mechanism to trust, uh, what is coming out of those systems? >>You know, we've talked with you guys in the past about the building blocks of software and what flows through the pipelines, all that stuff's part of what is automated these days and, and, and important. And what I gotta ask you because security these days is like, don't trust anything, you know, um, here it's, you're, you're trusting software to be in essence verified. I'm simplifying, obviously. So I gotta ask you what is being done to solve this problem, because states change, you know, you got data, you got software injections, and you got, we got containers and Kubernetes right here, helping all this is on the table now, but what is currently being done to solve the problem? Cause it's really hard. >>Yeah, it is. It is a really hard problem. And currently, right, when we develop software, we have a team, uh, which, which we work with and we trust whatever is coming out of the team. And we have, we have a, um, what do you call certified, uh, pro production mechanism to build that software and actually release it to our customers. And when it is done in house, it is easy because we are, we control all the pieces. Now what happens when, when we are doing this with open source, we don't have that chain. We need that chain, which is independent. We just independent of where the software was, you know, produced versus where it is going to be used. We need a way to have Providence of how it was built, which parts actually went in, uh, making, uh, making the end product. Uh, and, and what are the things that we see are, are, are, uh, continuing, uh, uh, continuing evidences that this software can be used. So if there is a vulnerability that is discovered now, that is discovered, and it is released in some database, and we need to do corrective action to say that this vulnerability associated with this version, and there is no, there's no automated mechanism. So we are working on an automated mechanism where, where you can run a command, which will tell you what has happened with this piece of, uh, software, this version of it, and whether it is production worthy or not. >>It's a great goal. I gotta say, but I'll tell you, I can guarantee there's gonna be a ton of skeptics on this security people. Oh, no, I don't. I doubt it's always a back door. Um, what's the relationship with Docker? How do you guys see this evolving? Obviously it's a super important mission. Um, it's not a trend that's gonna go away. Supply chain software is here to stay. Um, it's not gonna go away. And we saw this in hardware and everyone kind of knows kind of what happens when you see these vulnerabilities. Um, you gotta have trusted software, right? This is gonna be continuing what's the relationship with DockerCon? What are you guys doing with dock and here at DockerCon? >>So we, when we actually started working on this project, uh, both Docker and, uh, J frog had had similar ideas in mind of how, how do we make this, uh, this trust mechanism available to anyone, uh, who wants it, whether they're, whether they're in interacting with dock hub or, or regardless of that, right. And how do we actually make it a mechanism, uh, that just, uh, uh, that just provides this kind of, uh, this kind of trust, uh, without, without the developer having to do something. Uh, so what we worked with, uh, with Docker is actually integrating, um, integrating our solution so that anywhere there, uh, there is, uh, Docker being used currently, uh, people don't have to change those, uh, those behaviors or change those code, uh, those code lines, uh, right. Uh, because changing hand, uh, changing this a single line of code in hundreds of systems, hundreds of CI systems is gonna be really hard. Uh, and we wanted to build a seamless integration between Docker and the solution that we are building, uh, so that, so that you can continue to do Docker pro and dock push and, but get, uh, get all the benefits of the supply chain security solution that we have. >>Okay. So let's step back for a minute and let's discuss about the pro what is the project and where's the commercial J Frogg Docker intersect take that, break that apart, just step out the project for us. What's the intended goals. What is the project? Where is it? How do people get involved and how does that intersect with the commercial interest of JRO and Docker? >>Yeah. Yeah. My favorite topic to talk about. So the, the project is called Peria, uh, Peria is, uh, is an open source project. It is, it is an effort that started with JRO and, and Docker, but by no means limited to just JRO and dock contributing, we already have five companies contributing. Uh, we are actually building a working product, uh, which will demo during, uh, during our, uh, our talk. And there is more to come there's more to come. It is being built iteratively, and, and the solution is basically to provide a decentralized mechanism, uh, similar to similar to how, how you, uh, do things with GI, so that you have, you have the, uh, the packages that you are using available at your nearest peer. Uh, there is also going to be a multi load build verification mechanism, uh, and all of the information about the packages that you're going to use will be available on a Providence log. >>So you can always query that and find out what is the latest state of affairs, what ES were discovered and make, make quick decisions. And you don't have to react after the fact after it has been in the news for a while. Uh, so you can react to your customer's needs, um, uh, as quick as they happen. And we feel that the, our emphasis on open source is key here because, uh, given our experience, you know, 80 to 90% of software that is packaged, contains open source, and there is no way currently, which we, uh, or no engineering mechanisms currently that give us that, uh, that confidence that we, whatever we are building and whatever we are dependencies we are pulling is actually worthwhile putting it into production. >>I mean, you really, it's a great service. I mean, you think about like all that's coming out, open source, open source become very social, too. People are starting projects just to code and get, get in the, in the community and hang out, uh, and just get in the fray and just do stuff. And then you see venture capitals coming in funding those projects, it's a new economic system as well, not just code, so I can see this pipeline beautifully up for scale. How do people get involved with this project? Cause again, my, my questions all gonna be around integration, how frictionless it is. That's gonna be the challenge. You mentioned that, so I can see people getting involved. What's what's how do people join? What do they do? What can they do here at Docker con? >>Yeah. Uh, so we have a website, Percy, I P yr S I a.io, and you'll find all kinds of information there. Uh, we have a GI presence. Uh, we have community meetings that are open to public. We are all, we are all doing this under the, uh, under the umbrella limits foundation. We had a boots scrap project within Linux foundation. Uh, so people who have interest in, in all these areas can come in, just, just attend those meetings, uh, add, uh, you know, add comments or just attend our stand up. So we are running it like a, like a agile from, uh, process. We are doing stand up, we are doing retrospectives and we are, we are doing planning and, and we are, we are iteratively building this. So what you'll see at Dr. Conn is, is just a, a little bit of a teaser of what we have built so far and what you, what you can expect to, uh, see in, in future such events. >>So thanks for coming on the queue. We've got 30 seconds left, put a quick plug in for the swamp up, coming up. >>Yeah. Uh, so we, we will talk a lot more about Peria and our open source efforts and how we would like you all to collaborate. We'll be at swamp up, uh, in San Diego on May 26th, uh, May 24th to 26th. Uh, so hope to see you there, hope to discuss more about Peria and, and see what he will do with, uh, with this project. Thank you. >>All right. Thanks for coming on the back to the main stage. I'm John cube. Thanks for watching. >>Thank >>You.

(upbeat music) >> Welcome back to theCUBE special presentation, Simplifying Hybrid Cloud brought to you by Cisco. We're here with Vikas Ratna who's the director of product management for UCS at Cisco and James Leach, who is director of business development at Cisco. Gents welcome back to theCUBE, good to see you again. >> Hey, thanks for having us. >> Okay Jim, let's start. We know that when it comes to navigating a transition to hybrid cloud, it's a complicated situation for a lot of customers. And as organizations as they hit the pavement for their hybrid cloud journeys, what are the most common challenges that they face? What are they telling you? How Cisco specifically UCS helping them deal with these problems? >> Well, you know, first I think that's a, you know, that's a great question and, you know, customer-centric view is the way that we've taken, is kind of the approach we've taken from day one right? So I think that if you look at the challenges that we're solving for that our customers are facing, you could break them into just a few kind of broader buckets. The first would definitely be applications right? That's the, that's where the rubber meets your proverbial road with the customer, and I would say that, you know, what we're seeing is the challenges customers are facing within applications come from the way that applications have evolved. So what we're seeing now is more data-centric applications for example. Those require that we, you know, are able to move, and process large datasets really in real time. And the other aspect of applications I think that give our customers kind of some, you know, pose some challenges, would be around the fact that they're changing so quickly. So the application that exists today, or the day that they, you know, make a purchase of infrastructure to be able to support that application, that application is most likely changing so much more rapidly than the infrastructure can keep up with today. So, that creates some challenges around, you know, how do I build the infrastructure? How do I rightsize it without over provisioning for example? But also there's a need for some flexibility around life cycle and planning those purchase cycles based on the life cycle of the different hardware elements. And within the infrastructure, which I think is the second bucket of challenges, we see customers who are being forced to move away from the, like a modular or Blade approach which offers a lot of operational and consolidation benefits, and they have to move to something like a rack server model for some applications because of these needs that these data-centric applications have, and that creates a lot of, you know, opportunity for siloing infrastructure. And those silos in turn create multiple operating models within the, you know, a data center environment that, you know, again drive a lot of complexity. So that complexity is definitely the enemy here. And then finally I think life cycles. We're seeing this democratization of processing if you will, right? So it's no longer just CPU-focused, we have GPU, we have FPGA, we have, you know, things that are being done in storage and the fabrics that stitch them together, that are all changing rapidly and have very different life cycles. So, when those life cycles don't align, for a lot of our customers they see a challenge in how they can manage this, you know, these different life cycles and still make a purchase, without having to make too big of a compromise in one area or another because of the misalignment of life cycles. So that is a, you know, kind of the other bucket. And then finally I think management is huge, right? So management, you know, at its core is really rightsized for our customers and give them the most value when it meets the mark around scale and scope. You know, back in 2009 we weren't meeting that mark in the industry and UCS came about and took a management outside the chassis, right? We put it at the top of the rack and that worked great for the scale and scope we needed at that time, however, as things have changed, we're seeing a very new scale and scope needed right? So we're talking about a hybrid cloud world that has to manage across data centers, across clouds, and, you know, having to stitch things together for some of our customers poses a huge challenge. So there are tools for all of those operational pieces that touch the application, that touch the infrastructure but they're not the same tool. They tend to be disparate tools that have to be put together. >> Dave: All right. >> So our customers, you know, don't really enjoy being in the business of, you know, building their own tools so that creates a huge challenge. And one where I think that they really crave that full hybrid cloud stack that has that application visibility but also can reach down into the infrastructure. >> Right, you know, Jim I said in my open that you guys, Cisco had sort of changed the server game with the original UCS, but the X-Series is the next generation, the generation for the next decade which is really important 'cause you touched on a lot of things. These data-intensive workloads, alternative processors to sort of meet those needs, the whole cloud operating model and hybrid cloud has really changed so how is it going with with the X-Series? You made a big splash last year, what's the reception been in the field? >> Actually it's been great. You know, we're finding that customers can absolutely relate to our, you know, UCS X-Series story. I think that, you know, the main reason they relate to it is they helped create it, right? It was their feedback and their partnership that gave us really the, those problem areas, those areas that we could solve for the customer that actually add, you know, significant value. So, you know, since we brought UCS to market back in 2009, you know, we had this unique architectural paradigm that we created, and I think that created a product which was the fastest in Cisco history in terms of growth. What we're seeing now is X-Series is actually on a faster trajectory. So we're seeing a tremendous amount of uptake, we're seeing, you know, both in terms of, you know, the number of customers, but also more importantly, the number of workloads that our customers are using, and the types of workloads are growing, right? So we're growing this modular segment that exists, not just, you know, bringing customers onto a new product but we're actually bringing them into the product in the way that we had envisioned which is one infrastructure that can run any application into it seamlessly. So we're really excited to be growing this modular segment. I think the other piece, you know, that, you know, we judge ourselves is, you know, sort of not just within Cisco but also within the industry. And I think right now as a, you know, a great example, you know, our competitors have taken kind of swings and misses over the past five years at this, at a, you know, kind of the new next architecture, and we're seeing a tremendous amount of growth even faster than any of our competitors have seen when they announced something that was new to this space. So, I think that the ground-up work that we did is really paying off, and I think that what we're also seeing is it's not really a leapfrog game as it may have been in the past. X-Series is out in front today and, you know, we're extending that lead with some of the new features and capabilities we have. So we're delivering on the story that's already been resonating with customers, and, you know, we're pretty excited that we're seeing the results as well. So as our competitors hit walls, I think we're, you know, we're executing on the plan that we laid out back in June, when we launched X-Series to the world. And, you know, as we continue to do that, we're seeing, you know, again, tremendous uptake from our customers. >> So thank you for that Jim. So, Vikas I was just on Twitter just today actually talking about the gravitational pull, you've got the public clouds pulling CXOs one way, and you know, on-prem folks pulling the other way, and hybrid cloud so, organizations are struggling with a lot of different systems and architectures, and ways to do things. And I said that what they're trying to do is abstract all that complexity away and they need infrastructure to support that and I think your stated aim is really to try to help with that confusion with the X-Series right? I mean, so how so? Can you explain that? >> Sure, and that's the right, the context that you built up right there Dave. If you walk into enterprise data center you'll see plethora of compute systems spread all across because every application has its unique needs, and hence you find drive node, drive-dense system, memory-dense system, GPU-dense system, core-dense system, and variety of form factors, 1U, 2U, 4U, and every one of them typically come with, you know, variety of adapters and cables and so forth. This creates the siloness of resources. Fabric is brought, the adapter is brought, the power and cooling implications, the rack, you know, space challenges. And above all, the multiple management plane that they come up with which makes it very difficult for IT to have one common center policy, and enforce it all across the firmware, and software, and so forth. And then think about upgrade challenges of the siloness makes it even more complex as these go through the upgrade references of their own. As a result we observe quite a few of our customers, you know, really, seeing a slowness in their agility, and high burdened in the cost of overall ownership. This is where with the X-Series powered by Intersight, we have one simple goal. We want to make sure our customers get out of that complexities, they become more agile, and drive lower these issues. And we are delivering it by doing three things, three aspects of simplification. First, simplify their whole infrastructure by enabling them to run their entire workload on single infrastructure. An infrastructure which removes the siloness of form factor. An infrastructure which reduces the rightful footprint that is required. Infrastructure where power and cooling budgets are in the lower. Second, we want to simplify with, by delivering a cloud operating model. Where they can create the policy once across compute, network, storage, and deploy it all across. And third, we want to take away the pain they have by simplifying the process of upgrade, and any platform evolution that they're going to go through in the next two, three years. So that's where, the focus is on just driving down the simplicity, lowering down their issues. >> Oh, that's key. Less friction is always a good thing. Now of course, Vikas we heard from the HyperFlex guys earlier, they had news not to be outdone, you have hard news as well, what innovations are you announcing around X-Series today? >> Absolutely, so we are following up on the exciting X-Series announcement that we made in June last year Dave, and we are now introducing three innovation on X-Series with the goal of three things. First, expand the supported workload on X-Series. Second, take the performance to new levels. Third, dramatically reduce the complexities in the data center by driving down the number of adapters and cables that are needed. To that end, three new innovations are coming in. First, we are introducing the support for the GPU node using a cableless and very unique X Fabric architecture. This is the most elegant design to add the GPUs to the compute node in the modular form factor. Thereby our customers can now power in AI/ML workload, or any workload that need many more number of GPUs. Second, we are bringing in GPUs right onto the compute node. And thereby our customers can now fire up the accelerated VDI workload for example. And third, which is what you know, we are extremely proud about, is we are innovating again by introducing the 5th generation of our very popular Unified Fabric Technology. With the increased bandwidth that it brings in, coupled with the local drive capacity and densities that we have on the compute node, our customers can now fire up the big data workload, the HCI workload, the SDS workload, all these workloads that have historically not lived in the modular farm factor, can be run over there and benefit from the architectural benefits that we have. Second, with the announcement of fifth generation fabric we've become the only vendor to now finally enable 100 Gig end-to-end single port bandwidth, and there are multiple of those that are coming in there. And we are working very closely with our CI partners to deliver the benefit of this performance through our Cisco Validated Design to our CI franchise. And third, the innovations in the fifth gen fabric will again allow our customers to have fewer physical adapters, may it be ethernet adapter, may it be with fiber channel adapters, or may it be the other storage adapters, they've reduced it down and coupled with the reduction in the cable. So very, very excited about these three big announcements that we are making in the smart release. >> Great, a lot there, you guys have been busy, so thank you for that Vikas. So Jim you talked a little bit about the momentum that you have, customers are adopting, what problems are they telling you that X-Series addresses and how do they align with where they want to go in the future? >> That's a great question. I think if you go back to and think about some of the things that we mentioned before in terms of the problems that we originally set out to solve, we're seeing a lot of traction. So what Vikas mentioned I think is is really important, right? Those pieces that we just announced really enhanced that story and really move, again, to the, kind of to the next level of taking advantage of some of these, you know, problem solving for our customers. You know, if you look at, you know, I think Vikas mentioned accelerated VDI, that's a great example. These are where customers, you know, they need to have this dense compute, they need video acceleration, they need tight policy management, right? And they need to be able to deploy these systems anywhere in the world. Well, that's exactly what we're hitting on here with X-Series right now. We're hitting the market every, every single way, right? We have the highest compute config density that we can offer across the, you know, the very top end configurations of CPUs, and a lot of room to grow, we have the, you know, the premier cloud-based management you know, hybrid cloud suite in the industry right? So check there. We have the flexible GPU accelerators that you, that Vikas just talked about that we're announcing both on the system and also adding additional ones to the, through the use of the X Fabric, which is really, really critical to this launch as well, and, you know, I think finally the fifth generation of Fabric Interconnect, and Virtual Interface Card, and Intelligent Fabric Module go hand in hand in creating this 100 Gig end-to-end bandwidth story that we can move a lot of data. Again, you know, having all this performance is only as good as what we can get in and out of it right? So giving customers the ability to manage it anywhere, to be able to get the bandwidth that they need, to be able to get the accelerators that are flexible to, that it fit exactly their needs, this is huge, right? It solves a lot of the problems we can tick off right away. With the infrastructure as I mentioned, X Fabric is really critical here because it opens a lot of doors here, you know, we're talking about GPUs today, but in the future there are other elements that we can disaggregate like the GPUs that solve of these life cycle mismanagement issues, they solve issues around the form factor limitations. It solves all these issues for, like it does for GPU we can do that with storage or memory in the future. So that's going to be huge, right? This is disaggregation that actually delivers, right? It's not just a gimmicky bar trick here that we're doing, this is something that customers can really get value out of day one. And then finally, I think the, you know, the future readiness here, you know, we avoid saying future proof because we're kind of embracing the future here. We know that not only are the GPUs going to evolve, the CPUs are going to evolve, the drives, you know, the storage modules are going to evolve. All of these things are changing very rapidly, the fabric that stitches them together is critical and we know that we're just on the edge of some of the developments that are coming with CXL, with some of the PCI Express changes that are coming in the very near future, so we're ready to go. X, and the X Fabric is exactly the vehicle that's going to be able to deliver those technologies to our customers, right? Our customers are out there saying that, you know, they want to buy into something like X-Series that has all the operational benefits, but at the same time, they have to have the comfort in knowing that they're protected against being locked out of some technology that's coming in the future right? We want our customers to take these disruptive technologies and not be disrupted but use them to disrupt their competition as well. So we, you know, we're really excited about the pieces today, and I think it goes a long way towards continuing to tell the customer benefit story that X-Series brings, and, you know, again, you know, stay tuned because it's going to keep getting better as we go. >> Yeah, a lot of headroom for scale and the management piece is key there. Just have time for one more question Vikas, talk, give us some nuggets on the roadmap. What's next for X-Series that we can look forward to. >> Absolutely Dave. As we talked about and James also hinted, this is a future-ready architecture. A lot of focus and innovation that we are going through is about enabling our customers to seamlessly and painlessly adopt very disruptive hardware technologies that are coming up, no refund replace. And there we are looking into enabling the customer's journey as they transition from PCA in less than four to five to six, without rip and replace, as they embrace CXL without rip and replace, as they embrace the newer paradigm of computing through the disaggregated memory, disaggregated PCI or NVMe-based dense drives and so forth. We are also looking forward to X Fabric next generation which will allow dynamic assignment of GPUs anywhere within the chassis and much more. So this is again all about focusing on the innovation that will make the enterprise data center operations a lot more simpler, and drive down the TCO, by keeping them not only covered for today but also for future. So that's where some of the focus is on Dave. >> Okay, thank you guys, we'll leave it there, in a moment I'll have some closing thoughts. (bright upbeat music) We're seeing a major evolution perhaps even a bit of a revolution in the underlying infrastructure necessary to support hybrid work. Look, virtualizing compute and running general purpose workloads is something it figured out a long time ago. But just when you have it nailed down in the technology business, things change don't they? You can count on that. The cloud operating model has bled into on-premises locations, and is creating a new vision for the future, which we heard a lot about today. It's a vision that's turning into reality and it supports much more diverse and data-intensive workloads and alternative compute modes. It's one where flexibility is a watchword enabling change, attacking complexity, and bringing a management capability that allows for a granular management of resources at massive scale. I hope you've enjoyed this special presentation, remember all these videos are available on demand at thecube.net, and if you want to learn more please click on the information link. Thanks for watching Simplifying Hybrid Cloud brought to you by Cisco and theCUBE, your leader in enterprise tech coverage. This is Dave Vellante be well, and we'll see you next time. (upbeat music)

(soft upbeat music) (crowd chattering) >> Over the past 18 to 24 months, chief information security officers have dramatically changed their priorities. They had to, to support the remote work trend. So things like endpoint security, cloud security, and in particular identity and access management became top of mind. And a whole shift occurred. And we're going to talk about that today. Hi everybody, this is Dave Vellante and you're watching theCUBE. We're here at AWS re:Invent 2021. Katie Curtin-Mestre is here. She's the vice president of marketing at CyberArk and Bar Lavie senior product manager at Cloud Identity and Security. Bar, sorry for botching your name, but folks welcome to theCUBE, great to see you. >> Glad to be here. >> Great to hear. >> So Katie, upfront I talked about some of those trends. It's been a hugely dramatic shift away from this kind of traditional approaches to cyber. What are some of the trends that CyberArk has seen? >> Well, Bar is going to take the first part of this. >> Great, just go on. (Bar laughing) >> Yeah, so one trait that we are seeing is that cloud migration projects accelerate as organization turbocharged digital transformation. Is they're a looking to take advantage off the agility and operational efficiency of the cloud providers. Some of the concerns that I can think about one of those is the reducing the potential loss of data that is caused due to the excessive access to resources. And the other one is provision secure and scalable access to resources. And the third one would be implementing least privilege for all type of identity whether if it's a human identity or non-human identity. >> And on that end Dave, we recently commissioned a survey with the Cloud Security Alliance. We co-sponsored a survey and found that 94% of respondents said that securing human permissions was a top security challenge and machine identities weren't far behind at 77%. Another challenge that we're hearing from our customers is the need to secure the secrets used by applications. So we're really excited by today's news from AWS. They announced some new capabilities with a code guru called Secret Detector that helps to find unsecured secrets in applications. And the other concern that we're hearing from our customers is the need to monitor and audit the activity of all of their cloud identities. This is really important to help their security operation teams with their investigations and also to meet audit and compliance requirements. >> So the definition of identity is now more encompassing and includes like you say machines, right? It's not just people anymore. Of course we've seen, you know, phishing has always been problematic. It's escalated daily, right? We get phished. I mean, are we going to see the day where we finally get rid of passwords? Is that even possible? But maybe we could talk a little bit about sort of identity, how identity is evolving, this notion of zero trust. Zero trust used to be a Password. So, maybe Bar you could talk a little bit about what you're seeing in terms of identity access management. Maybe privileged access management are those things coming together? How does CyberArk think about those things? >> You going to take this one Katie >> Well, what CyberArk sees is we definitely see a trend where access management and privileged access management are coming together. Security teams are struggling too many security tools and they're really looking to standardize on a small handful of vendors and get more bank for their buck from their security investment. So we're definitely seeing that trends of unified platforms across access and privileged access management to secure any identity, whether human or machine from kind of like your standard workforce identity, to those who have highly privileged access. >> I don't know if you've ever, ever seen that chart. I think Optiv puts it out. It's consultancy. And it's this eye chart. It's a taxonomy of all the different security I have published at a number of times. it's mind boggling. So CSOs, SecOps teams they have to manage all this complexity, all these different tools and you ask CSOs what's your biggest challenge? They'll tell you lack of skills. We just can't find people. We can't train them fast enough. So what's CyberArk working on? What are some of the key initiatives that you guys are focused on that people should know about? >> Well, one of the things that we're working on is actually, and we see a greater adoption of it is something that was actually started as an initiative within our innovation lab. It's a CyberArk Clouding Titles Manager, which help to detect and remediate excessive permissions to cloud resources for any type of identity. I mentioned before the both human and non-human. Which are the something that you were looking to to secure. Another solution that we see a great adoption is our circuit ranger which helps organization to re remove the necessity of having a hard-coded credentials within application. It can be either traditional applications for their own premise or even cloud native applications. And peg this also into your CI CD pipeline. And we are actually innovating in these type of area with AWS as well. So this is one of the great things that we were doing. Also we're investing on a new solution for just-in-time access for cloud VMs and cloud consoles. And all of these solutions that I've mentioned and more to that are part of our identity security platform which came to provide you with the suite of solution to apply least privilege and secure access to any type of resource from any device for any type of identity. >> So is that best practice? I mean, if you had to, you know, advise a customer on best practice in identity, how should they think about that? Where should they start? >> Well, on the best practices front we recently published an ebook with AWS. And it's focused on the shared responsibility model and foundational best practices for securing cloud access. And it's all part of an initiative that CyberArk has, which is our identity security blueprint. Which guides customers on how best to move forward with their identity security initiatives. >> So where do they start? First of all how do they get that is it a security website or? >> It's available on our website and we detailed some of the steps that that customers can take. For example, one of the steps that we recommend to our customers is to limit the use of the root account and also to very much lock down the root account to use federated identities whenever possible. And Bar already alluded to some of the other best practices that we recommend. Such as removing hard-coded credentials from secrets. Another best practice that we really recommend to our customers is to have a consistent set of controls across their entire estate. Both from on-premises to the cloud. And this really helps to reduce complexity by having a unified and consistent set of security controls. And in fact one of our customers who is one of the world's largest convenience chains. They're using CyberArk to secure the credentials both for their on-premise servers and their AWS EC2 instances. And they're also using us as well to secure the credentials used by applications in the CI CD pipeline. So getting to those consistent controls is another best practice we highly recommend. >> So, consistent identity across your state, whether it's on-prem or in the cloud. And then also you've referenced CI CD a couple of times. So it's it's developer friendly? Are you're designing security in as opposed to a bolt on after the fact? And then you mentioned root accounts access. Is that where privilege access management comes in? Are we going to treat everybody as privileged access? Or how do you deal with machines? You mentioned hard-coded? Like some machines are hard-coded. Like I would imagine a lot of these internet cameras are exposures. How do you deal with all that? I mean, do you just have to cycle through and modernize your fleet of machines? Are there ways in which CyberArk can help sort of anticipate that or defend against that? >> Well, CyberArk can help on, on multiple fronts. Of course you need to secure the root account but that's just only one example of needing to secure a privilege access. And one thing that customers need to understand is that now going forward, any identity can have privilege access at any point in time, because at any point and time, you yourself could have access to a highly sensitive system or have access to highly sensitive data. So with CyberArk we help our customers understand which of their applications and infrastructure have the most sensitive data and then work with them to secure the access to that data whether that access be a human access or machine or programmatic access. >> So what are the customer implications of all this? I mean pre pandemic, you know, this whole zero trust thing with password. Now it's like fundamental premise. You don't trust to verify. What are the customer implications as we enter this new era ransomware through the roof, the adversaries are well funded highly capable. They're living off the land, they're island hopping. They're, doing self forming malware. It's a new world, right? So what are the customer implications? What should they be thinking about? You know, they don't have unlimited budget. So what's the advice? >> Well, eventually at the end of the day, there are all kinds of best practices of how to applies security. I think that both AWS have their own best practices and CyberArk has also our own best practices calling the blueprint which help organization to focus on to crown jewel on the most important stuff. And then going deeper and lower within each and every initiative. And on each and every level, try to investigate what you're trying to protect and what kind of security mechanisms can be applied in order to protect both access and maintaining that no one whether if it's internal or external attacker can gain access to it. >> Yup, I think the other implication for customers and you already alluded to it is really to continue to move forward with their zero trust initiatives. I think that that is a foundational going forward. Now that remote work is kind of the defacto norm and we can no longer rely on the traditional network perimeter. And so in this new environment securing your identities is the new perimeter. So that's an important implication for customers. And then another one that I would mention is that security teams need to work more closely with their dev and dev ops counterparts to bacon security earlier. It really can't be that security is brought in after the fact. Security very much needs to shift left and be included in the very early stages of application development before an application comes to production. >> I mean, I think it's that last point but all good points. The last point was a huge theme at CubeCon this year. That notion of shift left developers, you've mentioned the CI CD pipeline several times. I mean I think that is, you know, especially when you think about machines and the edge and IoT. I used to say all the time, you know that you used to put a moat around the castle, build a wall, protect the queen. Well, the queen has left the castle. But now with the pandemic, we've seen the effects of that. And as I say, the adversaries are seeing huge opportunities. Well-funded super sophisticated. It's like it makes Stuxnet look like a kindergarten. I know that was still >> That's scary. still pretty sophisticated. But I mean, look at what we saw with the government hack and solar winds, you know huge huge. But if we can talk to CSOs about that, they're like, you know, that's, we have to move fast. But they don't have unlimited budget, right? Cybersecurity is their number one initiative in terms of priorities. But then they have all these other things to fund. They have to fund a forced march to digital transformation, machine learning and AI, they're migrating to the cloud. They're driving automation. They're modernizing their application portfolio. So, security is still number one, isn't it? So it's a good business that you're in. >> Yes, and we really want to work with our CSOs so they can get the most investment out of what they're putting into CyberArk and the rest of their strategic security vendors. Because as you mentioned there's a talent shortage. So anything that we can do as vendors to make it easier for them to use our products and get more value from our solutions, is something that's really important. >> And automation is part of the answer but it's not the only answer, right? You got to follow the NIST framework and follow these best practices and keep fighting the fight. Guys. Thanks so much for coming on theCUBE. It was great to have you. I'd love to have you back. >> Thanks for having us. >> Thank you for having us. >> All right. Our pleasure. All right, this is Dave Vellante for theCUBE. You're watching our coverage of AWS re:Invent 2021. (gentle upbeat music)

>>mhm Yes, everyone, welcome back to the cubes coverage of dr khan 2021. I'm john for your host of the cube. Got a great segment here. One of the big supporters and open source amazon web services returning back second year. Dr khan virtual Deepak Singh, vice president of the compute services at AWS Deepak, Great to see you. Thanks for coming back on remotely again soon. We'll be in real life. Reinvent is going to be in person, we'll be there. Good to see you. >>Good to see you too, john it's always good to do these. I don't know how how often I've been at the cube now, but it's great every single time your >>legend and getting on there, a lot of important things to discuss your in one of the most important areas in the technology industry right now and that is at the confluence of cloud scale and modern development applications as they shift towards as Andy Jassy says, the new guard, right. It's been happening. You guys have been a big proponent of open source and enabling open source is a service creating business models for companies. But more importantly, you guys are powering, making it easier for folks to use software. And doctor has been a big relationship for you. Could you take a minute to first talk about the doctor, a W S relationship and your involvement and what you're doing? >>Yeah, actually it goes back a long way. Uh you know, Justin, we announced PCS had reinvented 2014 and PCS at that time was very much managed orchestration service on top of DACA at that time. I think it was the first really big one out there from a cloud provider. And since then, of course, the world has evolved quite a bit and relationship with DR has evolved a lot. The thing I'd like to talk to is something that we announced that Dr last year, I don't remember if I talked about it on the cube at that time. But last year we started working with DR on how can we go from doctor Run, which customers love or DR desktop, which customers love and make it easy for people to run containers on pcs and Fergie. Uh so most new customers running containers and AWS today start with this Yes and party or half of them and we wanted to make it very easy for them to start with where they are on the laptop which is often bucket to stop and have running services the native US. So we started working with DR and that that collaboration has been very successful. We want to keep you look forward to continuing to work on evolving that where you can use Docker compose doctor, desktop, doctor run the fuel that darker customers used and the labour grand production services on the end of your side, which is the part that we've got that on. So I think that's one area where we work really well together. Uh, the other area where I think the two companies continue to work well together. It's open source in general as some of, you know, AWS has a very strong commitment to contain a. D uh, EKS our community service is moving towards community. Forget it actually runs all on community today and uh, we collaborate dr Rhonda on the Ocr specification because, you know, the Oc I am expect is becoming the de facto packaging format idea. W S. This morning we launched yesterday, we launched a service called Opera. And the main expected input for opera is an Ocr image are being in this Atlanta as well, where those ci images now a way of packaging for lambda. And I think the last one I like to call out and it has been an amazing partnership and it's an area where most people don't pay attention is amid signing. Uh, there's a project called Notary. We do the second version of the Notary Spec for remit signing and AWS Docker and a couple of other companies have been working very closely together on bringing that uh, you know, finalizing no tv too, so that at least in our case we can start building services for our customers on top of that. You know, it's it's a great relationship and I expect to see it continue. >>Well, I think one of the themes this year is developer experience. So good. Good call out there in the new announcements on the tools you have and software because that seems to be a great developer integration with Docker question I have for you is how should the customers think about things like E C. S and versus E K. S. App, Runner lambda uh for kind of running their containers. How do they understand the difference is, what's there? What's the, what's the thought process there? What's >>that? It's a good question actually been announced after. And I think there was one of the questions I started getting on twitter. You know, let's start at the very beginning. Anyone can pick up a Docker container and run it on easy to today. You can run it on easy to, we can run a light sail, but doc around works just fine. It's the limits machine. Then people want to do more complex things. They want to run large scale orchestrated services. They won't run their entire business and containers. We have customers will do that today. Uh, you know, you have people like Vanguard who runs a significant portion of the infrastructure on pcs frg or you have to elope with the heavy user of chaos, our community service. So in general, if you're running large scale systems, you're building your platforms, you're most likely to use the csny Chaos. Um, if you come from a community's background, you're, you're running communities on prem or you want the flexibility and control the communities gives you, you're gonna end up with the chaos. That's what we see our customers doing. If you just want to run containers, you want to use AWS to its fullest extent where you want the continue a P I to be part of the W A S A P. I said then you pick is yes. And I think one of the reasons you see so many customers start with the CSN, Forget is with forget to get the significant ease of use from an operational standpoint. And we see many start ups and you know, enterprises, especially security focus enterprises leaning towards farming. But there's a class of customers that doesn't want to think about orchestration that just wants. Here's my code, here's my container image just run my service for me and that's when things like happen, I can come and that's one of the reasons we launched it. Land is a little bit different. Lambda is a unique service. You buy into an event driven architecture. If you do that, then you can figure our application into this. That's they should start its magic. Uh, the container part, there is what land announced agreement where they now support containers, packaging. So instead of zip files, you can package up your functions as containers. Then lambda will run them for you. The advantage it gives you with all the tooling that you built, that you have to build your containers now works the land as well. So I won't call and a container orchestration service in the same sense of the CSC cso Afrin are but it definitely allows the container image format as a standard packaging format. I think that's the sort of universal common theme that you find across AWS at this point of time. >>You know, one of the things that we're observing at this at this event here is a lot of developers Coop con and Lennox foundations. A lot of operators to kubernetes hits that. But here's developers. And the thing is I want to ease of use, simplicity experience, but also I want the innovation. Yeah, I want all of it. When I ask you what is amazon bring to the table for the new equation, what would you say? >>Yeah, I mean for me it's always you've probably heard me say this 100 times. Many 1000 times. It's foggy fog. It's unique to us. It takes a lot of what we have learned about operating infrastructure scale. The question we asked ourselves, you know, in many ways we talk about forget even before belong pcs but we have to learn on what it meant and what customers really wanted. But the idea was when you are running clusters of instances of machines to run containers on, you have to start thinking about a lot of things that in some ways VMS but BMS in the car were taken away capacity. What kind of infrastructure to run it on? Should have been touched. Should have not been back. You know, where is my container running? Those are things. They suddenly started having to think about those kind of backwards almost. So the idea was how can we make your containerized bundles? So TCS task or community is part of the thing that you talk to and that is the main unit that you operate on. That is the unit that you get built on and meet it on. That's where Forget comes in and it allows us to do many interesting things. We've effectively changed the engine of forget since we've launched it. Uh, we run it on ec two instances and we run it on fire cracker. Uh, we have changed the forget agent architecture. We've made a lot of underneath the hood, uh, changes that even take the take advantage of the broader innovation, the rate of us, We did a whole bunch more to launch acronym trans on top of family customers don't have to think about it. They don't have to worry about it. It happens underneath the hood. It's always your engine as as you go along and it takes away all the operational pain of managing clusters of running into picking which instances to use to getting out, trying to figure out how to bend back and get efficiency. That becomes our problem. So, you know, that is an area where you should expect to see a Stuart done more. It's becoming the fabric of so many things that eight of us now. Uh, it's, you know, in some ways we're just talking a lot more to do. >>Yeah. And it's a really good time. A lot more wave of developers coming in. One of the things that we've been reporting on on Silicon England cube with our cute videos is more developers keep on coming on, more people coming in and contributing to the open source community. Even end users, not just the normal awesome hyper scholars you're talking about like classic, I call main street enterprises. So two things I want to ask you on the customer side because you have kind of to customers, you have the community that open source community and you have enterprise customers that want to make it easier. What are you seeing and hearing from customers? I know you guys work backwards from the customer. So I got to ask you work backwards from the community and work backwards from the enterprise customer. What's going on in their environment? What's the key trends that they're riding? What's the big challenges? What's the big opportunities that they're facing and saying for the community? >>Yeah, I start with the enterprise. That's almost an easier answer. Which is, you know, we're seeing increasingly enterprises moving into the cloud wholesale. Like in some ways you could argue that the pandemic has just accelerated it, but we have started seeing that before. Uh they want to move to the cloud and adult modern best practices. Uh If you see my talk agreement last few years, I've talked about modernization and all the aspects of modernization, and that's 90% of our conversation with enterprises, I've walked into a meeting supposedly to talk about containers, whatever half a conversation is spent on. How does an organization modernize? What does an organization need to do to modernize and containers and serverless play a pretty important part in it, because it gives them an opportunity to step away from the shackles of sort of fixed infrastructure and the methods and approaches that built in. But equally, we are talking about C I C. D, you know, fully automated deployments. What does it mean for developers to run their own services? What are the child, how do you monitor and uh, instrument uh, your services? How do you do observe ability in the modern world? So those are the challenges that enterprises are going towards, and you're spending a ton of time helping them there. But many of them are still running infrastructure on premises. So, you know, we have outpost for them. Uh, you know, just last week, you're talking to a bunch of our customers and they have lots of interesting ideas and things that they want to do without both, but many of them also have their own infrastructure and that's where something like UCS anywhere came from, which is hey, you like using Pcs in the cloud, You like having the safety i that just orchestrates containers for you. It does it on on his in an AWS region. It will do it in an outpost. It'll do it on wavelength, it'll do it on local zone. How about we allow you to do it on whatever infrastructure you bring to us. Uh you want to bring a raspberry pi, you can do that. You want to bring your on premises data center infrastructure, we can do that or a point of sale device, as long as you can get the agent running and you can connect to an AWS region, even though it's okay to lose connectivity every now and then. We can orchestrate a container for you over there and, you know, the same customer that likes the ease of use of Vcs. And the simplicity really resonated with that message really resonates with them. So I think where we are today with the enterprise is we've got some really good solutions for you in eight of us and we are now allowing you to take those a. P. I. S and then launch containers wherever you want to run them, whether it's the edge or whether it's your own data center. I think that's a big part of where the enterprise is going. But by and large, I think yes, a lot of them are still making that change from running infrastructure and applications the way they used to do a modern sort of, if you want to use the word cloud native way and we're helping them a lot. We've done, the community is interesting. They want to be more participatory. Uh that's where things like co pilot comes from. God, honestly, the best thing we've ever done in my order is probably are open road maps where the community can go into the road map and engage with us over there, whether it's an open source project or just trying to tell us what the feature is and how they would like to see it. It's a great engagement and you know, it's not us a lot. It's helped us prioritize correctly and think about what we want to do next. So yeah, I think that's, that >>must be very hard to do for opening up the kimono on the road map because normally that's the crown jewels and its secretive and you know, and um, now it's all out in the open. I think that is a really interesting, um, experiment and what's your reaction to that? What's been the feedback on the road map peace? Because I mean, I definitely want to see, uh, >>we do it pretty much for every service in my organization and we've been doing it now for three years. So years forget, I think about three years and it's been great. Now we are very we are very upfront, which is security and availability. Our job 000 and you know, 100 times out of 100 at altitudes between a new feature and helping our customers be available and safe. We'll do that. And this is why we don't put dates in that we just tell you directionally where we are and what we are prioritizing Uh, there every now and then we'll put something in there that, you know, well not choose not to put a feature in there because we want to keep it secret until it launches. But for the most part, 99% of our own myself there and people engaged with it. And it's not proven to be a problem because you've also been very responsible with how we manage and be very transparent on whether we can commit to something or not. And I think that's not. >>I gotta ask you on as a leader uh threaded leader on this group. Open source is super important, as you know, and you continue to do it from under years. How are you investing in the future? What's your plan? Uh plans for your team, the industry actually very inclusive, Which is very cool. It's gonna resonate well, what's the plans? Give us some details on what you're investing in, what your priorities? What's your first principles? >>Yeah, So it goes in many ways, one when I I also have the luxury also on the amazon open source program office. So, you know, I get the chance to my team, rather not me help amazon engineers participate in open source. That that's the team that helps create the tools for them, makes it easy for them to contribute, creates, you know, manages all the licenses, etcetera. I'll give you a simple example, you know, in there, just think of the cr credential helper that was written by one of our engineers and he kind of distorted because he felt it was something that we needed to do. And we made it open source in general, in in many of our teams. The first question we asked is should something the open why is this thing not open source, especially if it's a utility or some piece of software that runs along with services. So they'll step one. But we've done some big things also, I, you know, a couple of years ago we launched Lennox operating system called bottle Rocket. And right from the beginning it was very clear to us that bottle Rocket was two things. It was both in AWS product. But first it was an open source project. We've already learned a little bit from what we've done at Firecracker. But making bottle rocket and open source operating system is very important. Anyone can take part of Rocket the open source to build tooling. You can run it whatever you want. If you want to take part of Rocket and build a version and manage it for another provider. For another provider wants to do it, go for it. There's nothing stopping you from doing that. So you'll see us do a lot there. Obviously there's multiple areas. You've seen WS investing on the open source side. But to me, the winds come from when engineers can participate in small things, released little helpers or get contributions from outside. I think that's where we're still, we can always have that. We're going to continue to strive to make it better and easier. And uh, you know, I said, I have, you know, me and my team, we have an opportunity to help their inside the company and we continue to do so. But that's what gets me excited. >>Yeah, that's great stuff. And congratulations on investing in the community, really enjoys it and I know it moves the needle for the industry. Deepak, I gotta ask you why I got you here. Dr khan obviously, developers, what's the most important story that they should be paying attention to as a developer because of what's going on shift left for security day two operations also known as a I ops getups, whatever you wanna call it, you know, ongoing, you get server lists, you got land. I mean, all kinds of great things are going on. You mentioned Fargate, >>um >>what should they be paying attention to that's going to really help their life, both innovation wise and just the quality of life. >>Yeah, I would say look at, you know, in the end it is very easy developers in particular, I want to build the buildings and it's very easy to get tempted to try and get learn everything about something. You have access to all the bells and whistles and knobs, but in reality, if you want to run things you want to, you want to focus on what's important, the business application, that and you the application. And I think a lot of what I'll tell developers and I think it's a lot of where the industry is going is we have built a really solid foundation, whether it's humanity, so you CSN forget or you know, continue industries out there. We have very solid foundation that, you know, our customers and develop a goal of the world can use to build upon. But increasingly, and you know, they are going to provide tools that sort of take that wrap them up and providing a nice package solution After another great example, our collaboration, the doctor around Dr desktop are a great example where we get all the mark focus on the application and build on top of that and you can get so much done. I think that's one trend. You'll see more and more. Those things are no longer toys, their production grade systems that you can build real world applications on, even though they're so easy to use. The second thing I would add to that is uh, get uh, it is, you know, you can give it whatever name you want. There's uh, there's nuances there, but I actually think get up is the way people should be running the infrastructure, my virus in my personal, you know, it's something that we believe a lot in homicide as hard as you go towards immutable infrastructure, infrastructure, automation, we can get off plays a significant role. I think developers naturally gravitate towards it. And if you want to live in a world where development and operations are tightly linked, I think it after the huge role to play in that it's actually a big part of how we're planning to do things like yes, anywhere, for example, a significant player and that it would be a proton. I think get up will be a significant in the future of proton as well. So I think that's the other trend. If you wanted to pick a trend that people should pay attention. That's what I believe in a lot. >>Well you're an expert. So I want to get you a quick definition. What is get Ops, how would you define it? Because that's a big trend. What does it, what does that mean? >>Electricity will probably shoot me for getting this wrong. I tell you how I think about it. Which is, you know, in many cases, um, you when you're doing deployments are pushing a deployment getups is more of a full deployment. When you are pushing code to get depository, you have a system that knows that the event has happened and then pulls from there and triggers the thing as opposed to you telling it take I have this new piece of code now go deployed everywhere. So to me, the biggest changes that Two parts one is it's more for full mechanism where you're pulling because something has changed. So it needs systems like container orchestrators to keep them, you know, to keep them in sync. And the second part of the natural natural evolution of infrastructure score, which is basically everything is called the figures code. Infrastructure as code, code is code and everything is getting stored in that software repo and the software repo becomes your store of record and drives everything. Uh So for a glass of customers, that's going to be a pretty big deal. >>Yeah, when you're checking in code, that's again, it's like a compiler for the compiler, a container for the container, you've got things for each other. Automation is ultimately what we're talking about here. And that's to me where machine learning kicks in. So again, having this open source foundational fabric, as you said, forget out the muck or the undifferentiated heavy lifting. This is what we're talking about automation, isn't it? Deepak? >>Yes. I mean I said uh one thing where we hang our hat on is there's such good stuff out there in the world which we like to contribute to, but the thing we like to hang our hat on is how do you run this? How do you do it this in ways that you can uniquely bring capabilities to customers where there's things like nitro or things are nitro open stuff. Well, the fact that we have built up this operational infrastructure over the last in a decade plus or in the container space over the last seven years where we really really know how to run these things at scale and have made all the investments to make it easy to do. So that's that's where we have hanger hard keeping people safe, helping them only available applications, their new startup, that just completely takes off in over the weekend. For whatever reason, because, you know, you're the next hot thing on twitter and our goal is to support you whether you are, you know, uh enterprise that's moving from the main train or you are the next hot startup, that's you know, growing virally and uh, you know, we've done a lot to build systems help both sides and yeah, it's >>interesting if you sing about open source where it's come from, I mean I remember that base wouldn't open source wasn't open, I would be peddling software, there's a free copy of Linux, UNIX um in college and now it's all free. But I mean just what's changed now. It used to be just free software, download software. You got it now, it's a service. Service now can be monetized quickly. And what you guys are offering with AWS and cloud scale is you've done all these things as I don't have to have a developer. I get the benefits of the scale, I can bring my open source code to the table, make it a service integrated in with other services and be the next snowflake, be the next, you know, a company that could scale. And that is that's the that's the innovation, right? That's the this is a new phenomenon. So it also changes the business model. >>Yeah, actually you're you're quite right. Actually, I I like one more thing to it. But you look at how a lot of enterprises use containers today. Most of them are using something like this year, Symphony or GS to build an internal developer platform and internal developer portal. And then the question then becomes this hard to scale this modern and development practices to an entire organization. What is your big bank that's been around as thousands and thousands of ID stuff That may not all be experts are running communities running container is when you scale it out different systems that proton come into play. That was actually the inspiration is how do you help an organization where they're building these developer Portholes and developer infrastructure, developer platforms, How do you make it easy for them to build it? Be almost use it as a way to get these modern practices into the hands of all the business units, where they may not have the time to become experts at the modern ways of running infrastructure because they're busy doing other things. And I think you'll see the a lot more happening that space that's not happening in the open source community. There's proton, there's a bunch of interesting things happening here and be interesting to see how that evolves. >>And also, you know, the communal, communal aspect of not just writing code together, but succeeding, right, building something. I mean, that's when you start to see the commercial meets open kind of ethos of communal activity of working together and sharing a big part of this year's. Dakar Con is sharing not just running and shipping code but sharing. >>Yeah, I mean if you think about it uh Dockers original value was you build run and shit right? You use the same code to build it, you use the same code to ship it, the same sort of infrastructure interface and then you run it and that, you know, the fact that the doctor images such a wonderfully shareable entity uh that can run every girl is such a powerful and it's called the Ci Image. Now I still call him Dr images because it's just easier. But that to me like that is a big deal and I think it's becoming and become an even bigger deal over the years. I came from something before, Amazon has to work in The sciences and bioinformatics and you know, the ability to share codeshare dependencies, package all of that up in a container image is a big deal. It's what got me one of the reasons I got fascinated with container 78 years ago. So it will be interesting to see where all of systems. >>It's great, great stuff. Great success. And congratulations. Deepak, Great to always talk to you got a great finger on the pulse. You lead a really important organizations at AWS and you know, doctor has such a huge success with developers, even though the company has gone through kind of a uh change over and a pivot to what they're doing now. They're back to their open source roots, but they have millions and millions of developers use Docker and new developers are coming in dot net developers are coming in. Windows developers are coming in and and so it's no longer about Lennox anymore. It's about just coding. >>Yeah. And it's it's part of this big trend towards infrastructure, automation and and you know development and deployment practices that I think everyone is going to adopt faster than we think they will. But you know, companies like Doctor and opens those projects that they involved are critical in making that a lot easier for them. And then you know, folks like us get to build on top of that orbit them and make it even easier. >>Well, great testimony the doctor that you guys based your E C. S on Docker Doctor has a critical role in developing community. I run composed in their hub with dr desktop and we'll be watching amazon and and the community activity and see what kind of experiences you guys can bring to the table and continue that momentum. Thank you Deepak for coming on the >>cube. Thank you, john. That's always a pleasure. >>Okay. Mr cubes. Dr khan 2021 virtual coverage. I'm john for your host of the cube. Thanks for watching.

>>Hey, everyone. I want to welcome you back. This is our intermission. And let me tell you what a morning we've had for those of you that don't know. I'm, Hayma Ganapati, I'm in product marketing at Docker. And I would just want to quote, actually someone who was in one of the chat rooms and this, I think encapsulates exactly how I feel today, because this is my first Docker con and the quote was from. And he said, I feel like a kid in an ice cream store where I don't know which flavor to choose. I want to go to all of the sessions and I got to tell you that's how I felt. And, you know, um, I want to just do some specific call-ups. Um, first of all, Dana way to keep it real in your interview. I love the cube interview. If you miss that, um, it was really great. >>She talks a lot about, uh, CI CD pipeline and you know, what to do with GoodHub. It was great. Um, I also want to say that I was, uh, slipping back and forth between the community rooms and way to go Brazil obrigado until all of the people who participate in the Brazil room, we had about 250 plus people in that room. And the, the chat window was just going crazy and in the French community room, Vive left hall. So if you've a uncle funny, uh, we had about 150 plus people in that room. So I just want to say that, you know, we've been seeing a lot of participation and I just want to thank everyone for attending and for participating on people have been so kind in the chat rooms, we just want to remind you to stay kind, you know, presenters put a lot of effort into their presentations, so just, you know, offer some positive and supportive critique to them. >>And the other thing I want to mention is all of the countries that we're seeing, all of the participation. So I'm just going to call out a few. We have people from the Netherlands, from Canada, from South Africa, Akron, Ohio, Belgium, Austria, yeah, Ecuador, New Zealand. And he cut up Westchester. Like, I mean, it just goes list goes on and on and on. And I think this really speaks to the power of Docker community. And it's a real testimony to how people from all over the world are in love with Docker technology and are excited to be here. And so I just wanted to thank everyone again and want to remind you that we want to leverage the power of community. And we have a fundraising campaign going on to help, uh, people who are affected by COVID. And you know, some of our big communities, especially in India and Brazil are, have been really affected by COVID. >>So we're asking you to contribute and we'd really like you to participate. Um, we have, uh, the, the link you can see here, Docker donates, you can tweet about it and would love to see the numbers go up for those donations, because, you know, I've personally been affected, had some family members pass away from COVID in India, and I'm sure other people may have stories that firsthand or secondhand. So please do that and let's show what the power of Docker community can do. And before I hand over to, to Peter, I'm just going to read out some of the tweets we've been getting, okay, this Brett and Peter, these are great. Uh, one of the, one of the tweets said dev environments is one of the most exciting features in the past few years. Super excited to try this out. Great, great, great tweet. Yeah. >>I agree to, um, another loving the content that was not your tweets. You can, you can slip me the 20 bucks later. Um, there's another tweet that says loving the content from hashtag Docker con so far fascinating use cases and interesting progress and future directions love that. And then there's another one I'm trying to find it here. Uh, I've been waiting for this so long Docker builds now work on Intel and M one. So keep those tweets coming. We love getting this kind of feedback and we love reading the chat room. So, um, Peter, you know, I attended your, your panel and I love that we were talking about a security and that moving, moving it left. So how did that go for you? >>Uh, it was, it was, uh, it was extremely fun. And for those that are, uh, I think my parents might be watching, so they probably watched it and were like, w this is the most boring thing I've ever seen, but, um, you know, you get a bunch of geeks and, uh, Brett has told me I should use geek instead of nerd, but I, I liked, uh, geek. So you get a bunch of geeks talking about security and coding and, um, what, what, what containers actually are, what vulnerabilities are. Yeah, it was, it was extremely fun. The panel was fantastic. They were very engaging the chat. I mean, I couldn't keep up with the chat. Right. It would just kept flying by, uh, luckily I had a helper to pull off questions, but, um, yeah, it's super exciting. You can, I know we're all remote, but you can just feel that energy, right. It was, it was great. It was great. Yeah. Yeah, for sure. It's super >>Connected. I felt that with your panel to Brett as well, sorry to talk over you there, but yeah. How did, how did it go for you? I, there was a lot of engagement in your session. >>Uh, ditto, like it was just, uh, there was so many questions. We only got to get a fraction of them. I tried to pick themes because, uh, when you talk about continuous testing and integration and all the things that take a part of that, um, you, you end up with lots of, well, what I like is the discussion around opinions, because so much of these pipelines from code on your machine, into production and everything in between, it's really, uh, it's a culture. It turns out to be the description of your culture and how you all perceive testing, how you, what you value in testing. And so that really started to come out as a theme, um, throughout that show. And we, we ran at a time. I was also watching Peters and it was fantastic, but like you think an hour is enough time to cover a topic, but it's just tipping tip of the iceberg kind of stuff. So I think it was super helpful. I learned some things, um, I really enjoyed watching Peters and, uh, yeah, can't wait for the next one. There's >>More than that. And likewise, great. I mean, I know, I know we're w maybe we pat chose it, but it, it was, it was super exciting to watch your panel. They were very Nikos, one of my favorite people in the world, uh, a fellow Austinite, but, um, yeah, I love that too. How you, uh, you were talking about opinions right. And playing off each other. It's, it's always interesting to hear smart people, uh, how they think, right. Yeah. I learned from how they think, right. Yeah. A hundred percent. >>So, all right. So we're, we're, um, what's next? Like, we, we gotta keep this thing going, so I've got to remember that. >>I want to, so I want to talk a bit about some of the panels that are, or the sessions that are coming up and just want to remind people that happened this afternoon. I'm all about use cases. You know, I was a developer for many decades, and it's great to hear how other developers are using the tools. But, uh, as a developer, I always wanted to know how are, what are the end user applications? And so we have two exciting sessions at 1:00 PM. We have sneak and red ventures, and they're going to be talking about how they used Docker containers. The title of the, uh, uh, session is great. An ounce of prevention, curing, insecure, container images. So check that out. And we also have another one at one 30 with Massimo, from AWS and Dexter Legaspi from Sirius XM. And they're going to be talking about a real world application using Docker containers. So I really want you to, to encourage you to attend those. >>Yeah. Um, can I say one really quick? Cause I'm Sue and a shout out to Eric Smalling. He's giving the red ventures talk with our partners. He's awesome. Go check out his, uh, but I'm really excited about Matt. Jarvis's sneak talk around. Uh, I think we might've talked about it earlier. My container image has 500 vulnerabilities vulnerabilities now what, right. I mean, I think as developers, as we're coming into this and dev ops and everybody right. You scan and then you see all these vulnerabilities just shoot by. And you're like, well, what do I do? So Matt, Matt will be addressing that. And he is fantastic. I can go on. There's a bunch of them. >>Yeah. There's a whole bunch of coming up and right up after this, I'm on a live stream with a bunch of panels on get ops. And then after that, Peter will be back. And so stay tuned and thanks for watching during the intermission. And we'll see you soon. >>I'm also leading the women in tech panel attend that. Don't forget to do that. >>Absolutely. Yep. All right. Ciao. Ciao >>For me like my first, oh, I get it about Docker was when I used a SQL server container on my neck book for the first time >>Being able to install Docker desktop, which was the first thing that I did and be able to build this without worrying about any of my software versions that I currently had on my machine. It was >>Awesome. One of the things, because I love the most about Docker is because I write books and I do video training courses to help a lot of people take their first steps with Docker and containers and to get a connection with those people and for them to come back to me and say, do you know what this is so cool, so easy, and it's going to change both my job. And, but also my organization, my team, all of that kind of stuff, change the experience that our customers have with our applications and what our business really puts a smile on my face. If >>You want to use containers, then Docker is the first toys, especially with tools like the mark Docker, compose, you can, uh, easily do your day-to-day job as a developer, or even if you're an ops person, then there are the books of the cloud and other things. So yeah, the idea is that we can go the simplicity one simple task, uh, to, uh, Daugherty mate and make that reuse as many times. Uh, that is one of the cool things I like about my >>Favorite part about Docker is using it as a developer tool. I using Docker desktop, really easy to install, really easy to run. >>Every time I come back to DACA, I love the simplicity of the way that it works, especially on things like security, which I find frustrating and hard. It's just done so seamlessly. And so my favorite thing about DACA is not just that it changed the world in the way that we develop in and ship and build applications and put that. It's just so easy that even the guy, like, I think >>It really is all about finding that aha moment, that hook where Docker really makes sense to you because once you have that moment, then all of a sudden, you, you know, you are on your way to being a Docker power user. >>We need for people to understand this technology better before they can, uh, actually dive deep into that. And Docker makes it easier to explain things, to explain the concept of containers, to explain how containers will work, how you can split your environments, how you can, uh, standardize all your pipelines and so on. It's important that we also take the time to help other people. And I think it's very important that we also give back and that's part of the motto of open sources. How do we give back to other people and how we help other people learn? And I think that's what I'm really passionate about. This whole thing is continuing, uh, giving back to the community. I just >>Hope and has fun at Docker con. And I know that there's a lot of great speakers coming and I will be watching the talks, even though they're happening at 3:00 AM and in my local time zone, um, I'm pretty excited to watch and, uh, hopefully watch more than later on streaming or YouTube or wherever they're going to be. So I hope everyone has fun and learn something and yeah, I don't see how you couldn't have fun.

>> Narrator: From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2021 virtual. Brought to you by Red Hat, The Cloud Native Computing Foundation, and ecosystem partners. >> Hey, welcome back to theCUBE's coverage of KubeCon 2021 CloudNativeCon Europe. Part of the CNCF and ongoing, could be in there from the beginning, love this community, theCUBE's proud to support and continue to cover it. We're virtual this year again because of the pandemic but it looks like we'll be right around the corner for a physical event, hopefully for the next one, fingers crossed. Got a great guest here from Red Hat. Siamak Sadeghianfar, a Senior Principal Product Manager. Welcome to theCUBE. Thanks for coming in. >> Thank you for having me. >> So, this topic's about GitOps, Pipelines, code. Obviously Infrastructure as Code has been the ethos since I can remember going back to 2008 and the original cloutaroti vision. And we were always talking about that. Now it's mainstream. Now it's DevSecOps. So, it's now, day two operations, shifting left with security. OpenShift is continuing to get, take ground. Congratulations on that. So my first question is you guys announced the general availability of OpenShift Pipelines and GitOps at KubeCon. What are, what's this about? And what's the benefits for the customer. Let's get into the news >> Thanks for, to begin with for the Congress and this, this is definitely a hot topic around the DevSecOps. And the different variations of that year about some versions that during in, in FinTech and other verticals as well. The idea is here really is that CI/CD has been around for a long time, continuous integration and continuous delivery, as one of the core practices of the DevOps movement. DevOps movement is quite widespread, now. You, you see reports of above 90% of organizations are in the process of adoption in their journey. And this is one of the main practices but something that has become quite apparent is that many of these organizations that are investing more and more in Cloud Native apps and adopting Cloud Native ways of building applications the tooling and technology that they use for CI/CD since CI/CD is nothing new is from 10 years old, five years old pre Kubernetes era which is not quite Cloud Native. So there is always a clash of how do I build Cloud Natives application using these technologies that are not really built for Cloud Native space and an OpenShift Pipelines OpenShift GitOps is really an opening in this direction and bring more Cloud Native ways of continuous integration and continuous delivery to customers on OpenShift. >> Got it, so I got to ask you, so a couple of questions on this topic, I really want to dig into. Can you describe the Cloud Native CI/CD process versus traditional CI/CD? >> Sure, so traditional when we think about CI/CD there is usually this monolithic solutions that are running on a virtual machine on a type of infrastructure that they use to deploy applications as well. 'Cause you, you need reliability and you have to be making an assumption about an infrastructure that you're running on. And when you come to Cloud Native infrastructure you have a much more dynamic infrastructure. We have a lot less assumptions. You might be running on a public cloud or on premise infrastructure or different types of public cloud. So these environments are often also containerized. So there are, there's a high chance you're running on a container platform, regardless if it's a public or on premises. And with the whole containers, you, you have different types of disciplines and principals to think in, about your infrastructure. So in the Cloud Native ways of CI/CD, you're running most likely in a container platform. You don't have dedicated infrastructure. You are running mostly on demand. You scale when there is a demand for running CI/CD, for example, rather than dedicated infrastructure to it. And also from the mode of operation from organization perspective, they are more adapted to this decentralized ways of ownership. As a part of the DevOps culture, this comes really with that movement, that more and more development teams are getting ownership of some portion of the delivery of their applications. And it's cognitive CS/CD solutions, they focus on supporting these models that you go away from that central model of control to decentralize and have more ownership, more capabilities within the development teams for delivering application. >> Okay, so I then have to ask you the next question. It's like you, like a resource, you'd say: Hey Siri, what is, what is GitOps? What is GitOps? 'Cause that's the topic that's been getting a lot of traction, everyone's talking about it. I mean we know DevOps. So what is the GitOps model? Can you define that? And is that what a, it that what comes after DevOps? Is it DevOps 2.0, what is the GitOps model? >> That's a very good question. GitOps is nothing really new. It's rather a more descriptive way of DevOps principles. DevOps talks about the cultural changes and mindset and ways of working. And when it comes to the, to the concrete work flow it is quite open for interpretation. So GitOps is one, a specific interpretation of how you, you do continuous integration and continuous delivery, how we implement DevOps. And the concept have been around for a couple of years. But just recently, it's got a lot of traction within the Cloud Native space. >> So how does GitOps fit into Kubernetes then? 'Cause that's going to be the next dot that we want to connect. What is that, what is, how, how. How does GitOps fit into Kubernetes? >> So GitOps is really the, the core principle of GitOps is that you, you, you think about everything in your infrastructure and application in a declarative manner. So everything needs to be declared in, in, in a number of gate repositories and you drive your operations through Git Workflows. Which if you think about it is quite similar to how Kubernetes operates. The, the reason Kubernetes became so popular is because of this declarative way of thinking about your infrastructure. You declare what you expect and Kubernetes actualizes that on, on some sort of infrastructure. So GitOps is, is, is exact same concept, but the, but applied not to the infrastructure itself, but to the operations of that infrastructure, operations of those applications. It becomes a really nice fit together. It's the same mindset really applied in different place. >> It's like Kubernetes is like the linchpin or the enabler for GitOps. Just a whole nother level of, I mean, I think GitOps essentially DevOps 2.0 in my opinion because it takes this whole nother level above that for the developer modern developer because it allows them to do more. So it's been around for a while. We've been talking about this, it's got a new name but GitOps is kind of concept has been around. Why is the increase adoption happening now in your opinion or do you have any data on or any facts or opinion on why it's such an increase in, in conversation and adoption? >> You had the, you had like very accurate point there that Kubernetes has been a great enabler for, for DevOps and later the same applies to GitOps as well because of that, that great fit. It has been, GitOps the concept has been there but implementation of that has been quite difficult before Kubernetes and also for non-containerized environments. Kubernetes is, is a very potent platform for this kind of operation because the the mindset and the ways of working is really native to how Kubernetes thinks. But there is also another driver that has been influential in, in the rise of GitOps in the last year or two. And this is an observation we see at a lot of our customers, that the number of clusters that organizations are deploying, Kubernetes clusters increasing. As their maturity increases they get more comfortable with Cloud Native way of working and transfer the workflows to become Cloud Native, they are, they are having, they move more and more of their infrastructure to Kubernetes clusters. So a new challenge rises with this. And now that I have a larger number of clusters how do I ensure consistency across all these, all these clusters? So before I had to deploy an application to production environment, perhaps, which meant two clusters across two geographical zones. Now I have to deploy to 20 clusters. And these 20 clusters also change over time. So this week is a different 20 clusters then three weeks from now. So this, this dynamic ways of working and the customers maturing in, in dealing with Kubernetes operating communities has increased really the pace of adoption of GitOps because it addresses a lot of those challenges that customers are dealing with in this space. >> Yeah, you bring up a really good challenge there. And I think that's worth calling out, this idea of expansion. And I won't say sprawl because it's not a sprawl of cluster. It's more a state provisioning and standing up clusters. And you said they they're changing because the environment has needs and the workloads might have requirements. This makes total sense in a DevOps kind of GitOps way. So I get that and I see that definitely happening. So this brings up the question, if I'm a customer, what I'm worried about is I don't want to have that Hadoop factor where I build a cluster and it takes too long to manage it, or I can't measure it, or understand the data, or have any observability. So I want to have an ease of provisioning and standing up and I want to have consistency that my apps who are using it, don't have to be, you know mangled with or coded with. So, you know, this combination of ease of deploying, ease of integrating, ease of consuming the clusters becomes a service model. Can you share your thoughts on how that gets solved? >> Yeah, absolutely. So that, that's a great point because as, as this is happening, there is also heterogenesis in this, this type of Kubernetes infrastructure window. Like, they're all Kubernetes but this problem also has multiple facets as customers running on multiple public clouds and, and combination of that with their on-premise Kubernetes clusters. And that is, they may as well be OpenShift across all this, all this infrastructure. But the, the problem that GitOps helps its customers advise that they can have the exact same operational model across all these apps and infrastructure, regardless of what kind of application it is. And regardless of where OpenShift is installed or if you're using that combined with a public cloud managed a Kubernetes stats, is the exact same process because you're relying on, on the Gits Workflows, right? And even beyond that, this standard workflow has the benefit of something that many organizations are already familiar with. So if you think about what GitOps operations mean it is essentially what developers have been always using for developing applications. So this standardizes the operations of both application and infrastructure as solvers. >> Listen to me, I got to ask you as the product manager on the whole pipelining in Kubernetes deployments. In your opinion, share your perspective on, real quick, on Kubernetes, where we're at? Because just the accelerated adoption has been phenomenal. We've seen it mature this year at KubeCon. And certainly when KubeCon North America happens, you're going to see more and more end user participation. You're going to see much more end-user use cases. You mentioned clusters are growing. What's the state of Kubernetes from your perspective, from a developer mindset? >> So Kubernetes, I think it has moved from a place that it was seen as only a, a type of infrastructure for Cloud Native applications because of the capability that it provides to a type of infrastructure for any type of application, any type of workload. I think what we have seen over the last two years is, is a shift to expansion of the use cases. And if, if you are, you talked about head open if you are a data scientist, or if you are an AIML type of developer or any type of workload really, see use cases that are coming to the Kubernetes platform as the targets type of infrastructure. So that's really where we see Kubernetes at right now is the really, the preferred infrastructure for any type of workload. And I believe this trend going to to keep continuing to address any of the challenge that exists that prevents maybe part of the, a particular type of workload to address that within the platform and opens that to add to, to developers. Which means for the developers now, once you learn the platform you are really proficient in a, you have this skills for any type of application or any type of infrastructure because they're all standardized, regardless of what type of application or workloads or technology you're specialized in. They're all going to the exact same platform. So it's very standardized type of skills across organizations, different type of teams that they have. >> Awesome, great, thanks for sharing that insight and definition. You're like a walking dictionary today for our CUBE audience. Thank you for all this good stuff. Appreciate it. Final question for you is, what does it mean for developers that are using Jenkins or other cloud-based CI solutions like GitHub Actions? What, what's the impact to them with all this from a working standpoint? 'Cause obviously you've got to make it workable. >> Right, so it's CI/CD also like it's, it's it's great to see like with DevOps adoption, there are many organizations that already have processes in place. They have, they're already using a CI tool or a CD tool. They might be using Jenkins. A lot of organizations really use, use Jenkins even though it comes with challenges and you might be using public cloud services or cloud-based CI tools, like you have Actions, you have pipelines and so on. So we are very well aware of the existing investment that many organizational teams have made. And we make sure that OpenShift as a platform works really well alongside all these different types of CI and CD technology that exists. We want to make sure that for developers starting on OpenShift, they, they have a really solid Cloud Native foundation for CI/CD. They have of strategies included but replaceable type of strategies. So they, they have a supportive platform that is Cloud Native, that gives them capability that matches the type of Cloud Native workloads that they have on the platform but also integrate well with existing tooling that exists around CI/CD. So that they can match and choose if they want to replace a piece of that with an existing investment that they have done, integrated with the rest of the platform. >> Awesome, well, great to have you on. Having the principal product manager is awesome, to talk about the two new announcements here. OpenShift pipe, Pipelines, and OpenShift GitOps. Final, final question, bumper sticker this for the audience. What's the bottom line with OpenShift Pipelines and GitOps? What's the, what's the bottom line benefit for customers? >> It's a, so OpenShift Pipeline and OpenShift GitOps makes it really simple for customers to create Cloud Native Pipelines and GitOps model for delivering application. And also making cluster changes across a large range of clusters that they have, make it really simple to grow from that point to many, many clusters and still manage the complexity of this complex infrastructure that it will be growing into. >> All right, Siamak Sadeghianfar, Senior Principal Product Manager at Red Hat. Here for the KubeCon + CloudNativeCon, Europe. CUBE conversation, thanks for coming on, appreciate it. >> Thanks John, thanks for having me. Okay, CUBE coverage continues. I'm John Farrow with theCUBE. Thanks for watching. (upbeat music)

>>mhm Yes, Welcome back to the cubes coverage of red hat summit 2021 virtual, which we were in person this year but we're still remote. We still got the Covid coming around the corner. Soon to be in post. Covid got a great guest here, Clayton Coleman architect that red hat cuba love and I've been on many times expanded role again this year. More cloud, more cloud action. Great, great to see you. Thanks for coming on. >>It's a pleasure >>to be here. So great to see you were just riffing before we came on camera about distributed computing uh and the future of the internet, how it's all evolving, how much fun it is, how it's all changing still. The game is still the same, all that good stuff. But here at Red had some and we're gonna get into that, but I want to just get into the hard news and the real big, big opportunities here you're announcing with red hat new managed cloud services portfolio, take us through that. >>Sure. We're continuing to evolve our open shift managed offerings which has grown now to include um the redhead open shift service on amazon to complement our as your redhead open shift service. Um that means that we have um along with our partnership on IBM cloud and open ship dedicated on both a W S and G C P. We now have um managed open shift on all of the major clouds. And along with that we are bringing in and introducing the first, I think really the first step what we see as uh huh growing and involving the hybrid cloud ecosystem on top of open shift and there's many different ways to slice that, but it's about bringing capabilities on top of open shift in multiple environments and multiple clouds in ways that make developers and operation teams more productive because at the heart of it, that's our goal for open shift. And the broader, open source ecosystem is do what makes all of us safer, more, uh, more productive and able to deliver business value? >>Yeah. And that's a great steak you guys put in the ground. Um, and that's great messaging, great marketing, great value proposition. I want to dig into a little bit with you. I mean, you guys have, I think the only native offering on all the clouds out there that I know of, is that true? I mean, you guys have, it's not just, you know, you support AWS as your and I B M and G C P, but native offerings. >>We do not have a native offering on GCPD offered the same service. And this is actually interesting as we've evolved our approach. You know, everyone, when we talk about hybrid, Hybrid is, um, you know, dealing with the realities of the computing world, We live in, um, working with each of the major clouds, trying to deliver the best immigration possible in a way that drives that consistency across those environments. And so actually are open shift dedicated on AWS service gave us the inspiration a lot of the basic foundations for what became the integrated Native service. And we've worked with amazon very closely to make sure that that does the right thing for customers who have chosen amazon. And likewise, we're trying to continue to deliver the best experience, the best operational reliability that we can so that the choice of where you run your cloud, um, where you run your applications, um, matches the decisions you've already made and where your future investments are gonna be. So we want to be where customers are, but we also want to give you that consistency. That has been a hallmark of um of open shift since the beginning. >>Yeah. And thanks for clarifying, I appreciate that because the manage serves on GCB rest or native. Um let me ask about the application services because Jeff Barr from AWS posted a few weeks ago amazon celebrated their 15th birthday. They're still teenagers uh relatively speaking. But one comment he made that he that was interesting to me. And this applies kind of this cloud native megatrend happening is he says the A. P. I. S are basically the same and this brings up the hybrid environment. You guys are always been into the api side of the management with the cloud services and supporting all that. As you guys look at this ecosystem in open source. How is the role of A PS and these integrations? Because without solid integration all these services could break down and certainly the open source, more and more people are coding. So take me through how you guys look at these applications services because many people are predicting more service is going to be on boarding faster than ever before. >>It's interesting. So um for us working across multiple cloud environments, there are many similarities in those mps, but for every similarity there is a difference and those differences are actually what dr costs and drive complexity when you're integrating. Um and I think a lot of the role of this is, you know, the irresponsible to talk about the role of an individual company in the computing ecosystem moving to cloud native because as many of these capabilities are unlocked by large cloud providers and transformations in the kinds of software that we run at scale. You know, everybody is a participant in that. But then you look at the broad swath of developer and operator ecosystem and it's the communities of people who paper over those differences, who write run books and build um you know, the policies and who build the experience and the automation. Um not just in individual products or an individual clouds, but across the open source ecosystem. Whether it's technologies like answerable or Terror form, whether it's best practices websites around running kubernetes, um every every part of the community is really involved in driving up uh driving consistency, um driving predictability and driving reliability and what we try to do is actually work within those constraints um to take the ecosystem and to push it a little bit further. So the A. P. I. S. May be similar, but over time those differences can trip you up. And a lot of what I think we talked about where the industry is going, where where we want to be is everyone ultimately is going to own some responsibility for keeping their services running and making sure that their applications and their businesses are successful. The best outcome would be that the A. P. R. S are the same and they're open and that both the cloud providers and the open source ecosystem and vendors and partners who drive many of these open source communities are actually all working together to have the most consistent environment to make portability a true strength. But when someone does differentiate and has a true best to bring service, we don't want to build artificial walls between those. I mean, I mean, that's hybrid cloud is you're going to make choices that make sense for you if we tell people that their choices don't work or they can't integrate or, you know, an open source project doesn't support this vendor, that vendor, we're actually leaving a lot of the complexity buried in those organizations. So I think this is a great time to, as we turn over for cloud. Native looking at how we, as much as possible try to drive those ap is closer together and the consistency underneath them is both a community and a vendor. And uh for red hat, it's part of what we do is a core mission is trying to make sure that that consistency is actually real. You don't have to worry about those details when you're ignoring them. >>That's a great point. Before I get into some architectural impact, I want to get your thoughts on um, the, this trends going on, Everyone jumps on the bandwagon. You know, you say, oh yeah, I gotta, I want a data cloud, you know, everything is like the new, you know, they saw Snowflake Apollo, I gotta have some, I got some of that data, You've got streaming data services, you've got data services and native into the, these platforms. But a lot of these companies think it's just, you're just gonna get a data cloud, just, it's so easy. Um, they might try something and then they get stuck with it or they have to re factor, >>how do you look >>at that as an architect when you have these new hot trends like say a data cloud, how should customers be thinking about kicking the tires on services like that And how should they think holistically around architect in that? >>There's a really interesting mindset is, uh, you know, we deal with this a lot. Everyone I talked to, you know, I've been with red hat for 10 years now in an open shift. All 10 years of that. We've gone through a bunch of transformations. Um, and every time I talked to, you know, I've talked to the same companies and organizations over the last 10 years, each point in their evolution, they're making decisions that are the right decision at the time. Um, they're choosing a new capability. So platform as a service is a great example of a capability that allowed a lot of really large organizations to standardize. Um, that ties into digital transformation. Ci CD is another big trend where it's an obvious wind. But depending on where you jumped on the bandwagon, depending on when you adopted, you're going to make a bunch of different trade offs. And that, that process is how do we improve the ability to keep all of the old stuff moving forward as well? And so open api is open standards are a big part of that, but equally it's understanding the trade offs that you're going to make and clearly communicating those so with data lakes. Um, there was kind of the 1st and 2nd iterations of data lakes, there was the uh, in the early days these capabilities were knew they were based around open source software. Um, a lot of the Hadoop and big data ecosystem, you know, started based on some of these key papers from amazon and google and others taking infrastructure ideas bringing them to scale. We went through a whole evolution of that and the input and the output of that basically let us into the next phase, which I think is the second phase of data leak, which is we have this data are tools are so much better because of that first phase that the investments we made the first time around, we're going to have to pay another investment to make that transformation. And so I've actually, I never want to caution someone not to jump early, but it has to be the right jump and it has to be something that really gives you a competitive advantage. A lot of infrastructure technology is you should make the choices that you make one or two big bets and sometimes people say this, you call it using their innovation tokens. You need to make the bets on big technologies that you operate more effectively at scale. It is somewhat hard to predict that. I certainly say that I've missed quite a few of the exciting transformations in the field just because, um, it wasn't always obvious that it was going to pay off to the degree that um, customers would need. >>So I gotta ask you on the real time applications side of it, that's been a big trend, certainly in cloud. But as you look at hybrid hybrid cloud environments, for instance, streaming data has been a big issue. Uh any updates there from you on your managed service? >>That's right. So one of we have to manage services um that are both closely aligned three managed services that are closely aligned with data in three different ways. And so um one of them is redhead open shift streams for Apache Kafka, which is managed cloud service that focuses on bringing that streaming data and letting you run it across multiple environments. And I think that, you know, we get to the heart of what's the purpose of uh managed services is to reduce operational overhead and to take responsibilities that allow users to focus on the things that actually matter for them. So for us, um managed open shift streams is really about the flow of data between applications in different environments, whether that's from the edge to an on premise data center, whether it's an on premise data center to the cloud. And increasingly these services which were running in the public cloud, increasingly these services have elements that run in the public cloud, but also key elements that run close to where your applications are. And I think that bridge is actually really important for us. That's a key component of hybrid is connecting the different locations and different footprints. So for us the focus is really how do we get data moving to the right place that complements our API management service, which is an add on for open ship dedicated, which means once you've brought the data and you need to expose it back out to other applications in the environment, you can build those applications on open shift, you can leverage the capabilities of open shift api management to expose them more easily, both to end customers or to other applications. And then our third services redhead open shift data science. Um and that is a, an integration that makes it easy for data scientists in a kubernetes environment. On open shift, they easily bring together the data to make, to analyze it and to help route it is appropriate. So those three facets for us are pretty important. They can be used in many different ways, but that focus on the flow of data across these different environments is really a key part of our longer term strategy. >>You know, all the customer checkboxes there you mentioned earlier. I mean I'll just summarize that that you said, you know, obviously value faster application velocity time to value. Those are like the checkboxes, Gardner told analysts check those lower complexity. Oh, we do the heavy lifting, all cloud benefits, so that's all cool. Everyone kind of gets that, everyone's been around cloud knows devops all those things come into play right now. The innovation focuses on operations and day to operations, becoming much more specific. When people say, hey, I've done some lift and shift, I've done some Greenfield born in the cloud now, it's like, whoa, this stuff, I haven't seen this before. As you start scaling. So this brings up that concept and then you add in multi cloud and hybrid cloud, you gotta have a unified experience. So these are the hot areas right this year, I would say, you know, that day to operate has been around for a while, but this idea of unification around environments to be fully distributed for developers is huge. >>How do you >>architect for that? This is the number one question I get. And I tease out when people are kind of talking about their environments that challenges their opportunities, they're really trying to architect, you know, the foundation that building to be um future proof, they don't want to get screwed over when they have, they realize they made a decision, they weren't thinking about day to operation or they didn't think about the unified experience across clouds across environments and services. This is huge. What's your take on this? >>So this is um, this is probably one of the hardest questions I think I could get asked, which is uh looking into the crystal ball, what are the aspects of today's environments that are accidental complexity? That's really just a result of the slow accretion of technologies and we all need to make bets when, when the time is right within the business, um and which parts of it are essential. What are the fundamental hard problems and so on. The accidental complexity side for red hat, it's really about um that consistent environment through open shift bringing capabilities, our connection to open source and making sure that there's an open ecosystem where um community members, users vendors can all work together to um find solutions that work for them because there's not, there's no way to solve for all of computing. It's just impossible. I think that is kind of our that's our development process and that's what helps make that accidental complexity of all that self away over time. But in the essential complexity data is tied the location, data has gravity data. Lakes are a great example of because data has gravity. The more data that you bring together, the bigger the scale the tools you can bring, you can invest in more specialized tools. I've almost do that as a specialization centralization. There's a ton of centralization going on right now at the same time that these new technologies are available to make it easier and easier. Whether that's large scale automation um with conflict management technologies, whether that's kubernetes and deploying it in multiple sites in multiple locations and open shift, bringing consistency so that you can run the apps the same way. But even further than that is concentrating, mhm. More of what would have typically been a specialist problem, something that you build a one off around in your organization to work through the problem. We're really getting to a point where pretty soon now there is a technology or a service for everyone. How do you get the data into that service out? How do you secure it? How do you glue it together? Um I think of, you know, some people might call this um you know, the ultimate integration problem, which is we're going to have all of this stuff and all of these places, what are the core concepts, location, security, placement, topology, latency, where data resides, who's accessing that data, We think of these as kind of the building blocks of where we're going next. So for us trying to make investments in, how do we make kubernetes work better across lots of environments. I have a coupon talk coming up this coupon, it's really exciting for me to talk about where we're going with, you know, the evolution of kubernetes, bringing the different pieces more closely together across multiple environments. But likewise, when we talk about our managed services, we've approached the strategy for managed services as it's not just the service in isolation, it's how it connects to the other pieces. What can we learn in the community, in our services, working with users that benefits that connectivity. So I mentioned the open shift streams connecting up environments, we'd really like to improve how applications connect across disparate environments. That's a fundamental property of if you're going to have data uh in one geographic region and you didn't move services closer to that well, those services I need to know and encode and have that behavior to get closer to where the data is, whether it's one data lake or 10. We gotta have that flexibility in place. And so those obstructions are really, and to >>your point about the building blocks where you've got to factor in those building blocks, because you're gonna need to understand the latency impact, that's going to impact how you're gonna handle the compute piece, that's gonna handle all these things are coming into play. So, again, if you're mindful of the building blocks, just as a cloud concept, um, then you're okay. >>We hear this a lot. Actually, there's real challenges in the, the ecosystem of uh, we see a lot of the problems of I want to help someone automate and improved, but the more balkanize, the more spread out, the more individual solutions are in play, it's harder for someone to bring their technology to bear to help solve the problem. So looking for ways that we can um, you know, grease the skids to build the glue. I think open source works best when it's defining de facto solutions that everybody agrees on that openness and the easy access is a key property that makes de facto standards emerged from open source. What can we do to grow defacto standards around multi cloud and application movement and application interconnect I think is a very, it's already happening and what can we do to accelerate it? That's it. >>Well, I think you bring up a really good point. This is probably a follow up, maybe a clubhouse talk or you guys will do a separate session on this. But I've been riffing on this idea of uh, today's silos, tomorrow's component, right, or module. If most people don't realize that these silos can be problematic if not thought through. So you have to kill the silos to bring in kind of an open police. So if you're open, not closed, you can leverage a monolith. Today's monolithic app or full stack could be tomorrow's building block unless you don't open up. So this is where interesting design question comes in, which is, it's okay to have pre existing stuff if you're open about it. But if you stay siloed, you're gonna get really stuck >>and there's going to be more and more pre existing stuff I think, you know, uh even the data lake for every day to lake, there is a huge problem of how to get data into the data lake or taking existing applications that came from the previous data link. And so there's a, there's a natural evolutionary process where let's focus on the mechanisms that actually move that day to get that data flowing. Um, I think we're still in the early phases of thinking about huge amounts of applications. Microservices or you know, 10 years old in the sense of it being a fairly common industry talking point before that we have service oriented architecture. But the difference now is that we're encouraging and building one developer, one team might run several services. They might use three or four different sas vendors. They might depend on five or 10 or 15 cloud services. Those integration points make them easier. But it's a new opportunity for us to say, well, what are the differences to go back to? The point is you can keep your silos, we just want to have great integration in and out of >>those. Exactly, they don't have to you have to break down the silos. So again, it's a tried and true formula integration, interoperability and abstracting away the complexity with some sort of new software abstraction layer. You bring that to play as long as you can paddle with that, you apply the new building blocks, you're classified. >>It sounds so that's so simple, doesn't it? It does. And you know, of course it'll take us 10 years to get there. And uh, you know, after cloud native will be will be galactic native or something like that. You know, there's always going to be a new uh concept that we need to work in. I think the key concepts we're really going after our everyone is trying to run resilient and reliable services and the clouds give us in the clouds take it away. They give us those opportunities to have some of those building blocks like location of geographic hardware resources, but they will always be data that spread. And again, you still have to apply those principles to the cloud to get the service guarantees that you need. I think there's a completely untapped area for helping software developers and software teams understand the actual availability and guarantees of the underlying environment. It's a property of the services you run with. If you're using a disk in a particular availability zone, that's a property of your application. I think there's a rich area that hasn't been mined yet. Of helping you understand what your effective service level goals which of those can be met. Which cannot, it doesn't make a lot of sense in a single cluster or single machine or a single location world the moment you start to talk about, Well I have my data lake. Well what are the ways my data leg can fail? How do we look at your complex web of interdependencies and say, well clearly if you lose this cloud provider, you're going to lose not just the things that you have running there, but these other dependencies, there's a lot of, there's a lot of next steps that we're just learning what happens when a major cloud goes down for a day or a region of a cloud goes down for a day. You still have to design and work around those >>cases. It's distributed computing. And again, I love the space where galactic cloud, you got SpaceX? Where's Cloud X? I mean, you know, space is the next frontier. You know, you've got all kinds of action happening in space. Great space reference there. Clayton, Great insight. Thanks for coming on. Uh, Clayton Coleman architect at red Hat. Clayton, Thanks for coming on. >>Pretty pleasure. >>Always. Great chat. I'm talking under the hood. What's going on in red hats? New managed cloud service portfolio? Again, the world's getting complex, abstract away. The complexities with software Inter operate integrate. That's the key formula with the cloud building blocks. I'm john ferry with the cube. Thanks for watching. Yeah.

>> Narrator: From theCUBE's studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is theCUBE Conversation. >> You know, businesses have a staggering number of options today to support mission-critical applications. And much of the world's mission-critical data happens to live on converged infrastructure. Converged infrastructure is really designed to support the most demanding workloads. Words like resilience, performance, scalability, recoverability, et cetera. Those are the attributes that define converged infrastructure. Now with COVID-19 the digital transformation mandate, as we all know has been accelerated and buyers are demanding more from their infrastructure, and in particular converged infrastructure. Hi everybody this is Dave Vellante and welcome to this power panel where we're going to explore converged infrastructure, look at its past, its present and its future. And we're going to explore several things. The origins of converged infrastructure, why CI even came about. And what's its historic role been in terms of supporting mission-critical applications. We're going to look at modernizing workloads. What are the opportunities and the risks and what's converged infrastructures role in that regard. How has converged infrastructure evolved? And how will it support cloud and multicloud? And ultimately what's the future of converged infrastructure look like? And to examine these issues, we have three great guests, Trey Layton is here. He is the senior vice president for converged infrastructure and software engineering and architecture at Dell Technologies. And he's joined by Joakim Zetterblad. Who's the director of the SAP practice for EMEA at Dell technologies. And our very own Stu Miniman. Stu is a senior analyst at Wikibon. Guys, great to see you all welcome to theCUBE. Thanks for coming on. >> Thanks for having us. >> Great. >> Trey, I'm going to start with you. Take us back to the early days of converged infrastructure. Why was it even formed? Why was it created? >> Well, if you look back just over a decade ago, a lot of organizations were deploying virtualized environments. Everyone was consolidated on virtualization. A lot of technologies were emerging to enhance that virtualization outcome, meaning acceleration capabilities and storage arrays, networking. And there was a lot of complexity in integrating all of those underlying infrastructure technologies into a solution that would work reliably. You almost had to have a PhD and all of the best practices of many different companies integrations. And so we decided as Dell EMC, Dell Technologies to invest heavily in this area of manufacturing best practices and packaging them so that customers could acquire those technologies and already integrated fully regression tested architecture that could sustain virtually any type of workload that a company would run. And candidly that packaging, that rigor around testing produced a highly reliable product that customers now rely on heavily to operationalize greater efficiencies and run their most critical applications that power their business and ultimately the world economy. >> Now Stu, cause you were there. I was as well at the early days of the original announcement of CI. Looking back and sort of bringing it forward Stu, what was the business impact of converged infrastructure? >> Well, Dave as Trey was talking about it was that wave of virtualization had gone from, you know, just supporting many applications to being able to support all of your applications. And especially if you talk about those high value, you know business mission, critical applications, you want to make sure that you've got a reliable foundation. What the Dell tech team has done for years is make sure that they fully understand, you know the life cycle of testing that needs to happen. And you don't need to worry about, you know, what integration testing you need to do, looking at support major CS and doing a lot of your own sandbox testing, which for the most part was what enterprises needed to do. You said, okay, you know, I get the gear, I load the virtualization and then I have to see, you know, tweak everything to figure out how my application works. The business impact Dave, is you want to spend more time focusing on the business, not having to turn all the dials and worry about, do I get the performance I need? Does it have the reliability uptime that we need? And especially if we're talking about those business critical applications, of course, these are the ones that are running 24 by seven and if they go down, my business goes down with it. >> Yeah, and of course, you know, one of the other major themes we saw with conversion infrastructure was really attacking the IT labor problem. You had separate compute or server teams, storage teams, networking teams, they oftentimes weren't talking together. So there was a lot of inefficiency that converged infrastructure was designed to attack. But I want to come to the SAP expert. Joakim, that's really your wheelhouse. What is it about converged infrastructure that makes it suitable for SAP application specifically? >> You know, if you look at a classic SAP client today, there's really three major transformational waves that all SAP customers are faced with today, it's the move to S/4HANA, the introduction of this new platform, which needs to happen before 2027. It's the introduction of a multicloud cloud or operating model. And last but not least, it is the introduction of new digitization or intelligent technologies such as IOT, machine learning or artificial intelligence. And that drove to the need of a platform that could address all these three transformational waves. It came with a lot of complexity, increased costs, increased risk. And what CI did so uniquely was to provide that Edge to Core to Cloud strategy. Fully certified for both HANA, non HANA workloads for the classical analytical and transactional workloads, as well as the new modernization technologies such as IOT, machine learning, big data and analytics. And that created a huge momentum for converged in our SAP accounts. >> So Trey, I want to go to you cause you're the deep technical expert here. Joakim just mentioned uniqueness. So what are the unique characteristics of converged infrastructure that really make it suitable for handling the most demanding workloads? >> Well, converged infrastructure by definition is the integration of an external storage array with a highly optimized compute platform. And when we build best practices around integrating those technologies together, we essentially package optimizations that allow a customer to increase the quantity of users that are accessing those workloads or the applications that are driving database access in such a way where you can predictably understand consumption and utilization in your environment. Those packaged integrations are kind of like. You know, I have a friend that owns a race car shop and he has all kinds of expertise to build cars, but he has a vehicle that he buys is his daily driver. The customization that they've created to build race cars are great for the race cars that go on the track, but he's building a car on his own, it didn't make any sense. And so what customers found was the ability to acquire a packaged infrastructure with all these infrastructure optimizations, where we package these best practices that gave customers a reliable, predictable, and fully supported integration, so they didn't have to spend 20 hour support calls trying to discover and figure out what particular customization that they had employed for their application, that had some issue that they needed to troubleshoot and solve. This became a standard out of the box integration that the best and the brightest package so that customers can consume it at scale. >> So Joakim, I want to ask you let's take the sort of application view. Let's sort of flip the picture a little bit and come at it from that prism. How, if you think about like core business applications, how have they evolved over the better part of the last decade and specifically with regard to the mission-critical processes? >> So what we're seeing in the process industry and in the industry of mission-critical applications is that they have gone from being very monolithic systems where we literally saw a single ERP components such as all three or UCC. Whereas today customers are faced with a landscape of multiple components. Many of them working both on and off premise, there are multicloud strategies in place. And as we mentioned before, with the introduction of new IOT technologies, we see that there is a flow of information of data that requires a whole new set of infrastructure of components of tools to make these new processes happen. And of course, the focus in the end of the day is all on business outcomes. So what industries and companies doesn't want to do is to focus all their time in making sure that these new technologies are working together, but really focusing on how can I make an impact? How can I start to work in a better way with my clients? So the focus on business outcome, the focus on integrating multiple systems into a single consolidated approach has become so much more important, which is why the modernization of the underlying infrastructure is absolutely key. Without consolidation, without a simplification of the management and orchestration. And without the cloud enabled platform, you won't get there. >> So Stu that's key, what Joakim just said in terms of modernizing the application as being able to manage them, not as one big monolith, but integration with other key systems. So what are the options? Wikibon has done some research on this, but what are the options for modernizing workloads, whether it's on-Prem or off-prem and what are some of the trade offs there? >> Yeah, so Dave, first of all, you know, one of the biggest challenges out there is you don't just want to, you know, lift and shift. If anybody's read research for it from Wikibon, Dave, for a day, for the 10 years, I've been part of it talks about the challenges, if you just talk about migrating, because while it sounds simple, we understand that there are individual customizations that every customer's made. So you might get part of the way there, but there's often the challenges that will get in the way that could cause failure. And as we talked about for you, especially your mission-critical applications, those are the ones that you can't have downtime. So absolutely customers are reevaluating their application portfolio. You know, there are a lot of things to look at. First of all, if you can, certain things can be moved to SaaS. You've seen certain segments of the market. Absolutely SaaS can be preferred methodology, if you can go there. One of the biggest hurdles for SaaS of course, is there's retraining of the workforce. Certain applications they will embracing of that because they can take advantage of new features, get to be able to use that wherever they are. But in other cases, there are the SaaS doesn't have the capability or it doesn't fit into the workflow of the business. The cloud operating model is something we've been talking about it with you Dave, for many years. When you've seen rapid maturation of what originally was called "private cloud", but really was just virtualization plus with a little bit of a management layer on top. But now much of the automation that you build in AI technologies, you know, Trey's got a whole team working on things that if you talk to his team, it sounds very similar to what you had the same conversation should have with cloud providers. So "cloud" as an operating model, not a destination is what we're going for and being able to take advantage of automation and the like. So where your application sits, absolutely some consideration. And what we've talked about Dave, you know, the governance, the security, the reliability, the performance are all reasons why being able to keep things, you know, under my environment with an infrastructure that I have control over is absolutely one of the reasons why I might keep things more along a converged infrastructure, rather than just saying to go through the challenge of migration and optimizing and changing to something in a more of a cloud native methodology. >> What about technical debt? Trey, people talk about technical debt as a bad thing, what is technical debt? Why do I want to avoid it? And how can I avoid it? And specifically, I know, Trey, I've thrown a lot of questions at you yet, but what is it about converged infrastructure and its capabilities that helped me avoid that technical debt? >> Well, it's an interesting thing, when you deploy an environment to support a mission-critical application, you have to make a lot of implementation decisions. Some of those decisions may take you down a path that may have a finite life. And that once you reached the life expectancy of that particular configuration, you now have debt that you have to reconcile. You have to change that architecture, that configuration. And so what we do with converged infrastructure is we dedicate a team of product management, an entire product management organization, a team of engineers that treat the integrations of the architecture as a releases. And we think long range about how do we avoid not having to change the underlying architecture. And one of the greatest testaments to this is in our conversion infrastructure products over the last 11 years, we've only saw two major architectural changes while supporting generational changes in underlying infrastructure capabilities well beyond when we first started. So converged infrastructure approach is about how do we build an architecture that allows you to avoid those dead-end pathways in those integration decisions that you would normally have to make on your own. >> Joakim, I wanted to ask you, you've mentioned monolithic applications before. That's sort of, we're evolving beyond that with application architectures, but there's still a lot of monoliths out there so. And a lot of customers want to modernize those application and workloads. What, in your view, what are you seeing as the best path and the best practice for modernizing some of those monolithic workloads? >> Yeah, so Dave, as clients today are trying to build a new intelligent enterprise, which is one of SAP's leading a guidance today. They needed to start to look at how to integrate all these different systems and applications that we talked about before into the common business process framework that they have. So consolidating workloads from big data to HANA, non HANA systems, cloud, non-cloud applications into a single framework is an absolute key to that modernization strategy. The second thing which I also mentioned before is to take a new grip around orchestration and management. We know that as customers seek this intelligent approach with both analytical data, as well as experience and transactional data, we must look for new ways to orchestrate and manage those application workloads and data flows. And this is where we slowly, slowly enter into the world of a enterprise data strategy. And that's again, where converged as a very important part to play in order to build these next generation platforms that can both consolidate, simplify. And at the same time enable us to work in a cloud enabled fashion with our cloud operating model that most of our clients seek today. >> So Stu, why can't I just shove all this stuff into the public cloud and call it a day? >> Yeah, well, Dave, we've seen some people that, you know, I have a cloud first strategy and often those are the same companies that are quickly doing what we call "repatriation". I bristle a little bit when I hear these, because often it's, I've gone to the cloud without understanding how I take advantage of it, not understanding the full financial ramifications what I'm going to need to do. And therefore they quickly go back to a world that they understand. So, cloud is not a silver bullet. We understand in technology, Dave, you know, things are complicated. There's all the organizational operational pieces they do. There are excellent cloud services and it's really it's innovation. You know, how do I take advantage of the data that I have, how I allow my application to move forward and respond to the business. And really that is not something that only happens in the public clouds. If I can take advantage of infrastructure that gets me along that journey to more of a cloud model, I get the business results. So, you know, automation and APIs and everything and the Ops movement are not something that are only in the public clouds, but something that we should be embracing holistically. And absolutely, that ties into where today and tomorrow's converge infrastructure are going. >> Yeah, and to me, it comes down to the business case too. I mean, you have to look at the risk-reward. The risk of changing something that's actually working for your business versus what the payback is going to be. You know, if it ain't broken, don't fix it, but you may want to update it, change the oil every now and then, you know, maybe prune some deadwood and modernize it. But Trey, I want to come back to you. Let's take a look at some of the options that customers have. And there are a lot of options, as I said at the top. You've got do it yourself, you got a hyper-converged infrastructure, of course, converged infrastructure. What are you seeing as the use case for each of these deployment options? >> So, build your own. We're really talking about an organization that has the expertise in-house to understand the integration standards that they need to deploy to support their environment. And candidly, there are a lot of customers that have very unique application requirements that have very much customized to their environment. And they've invested in the expertise to be able to sustain that on an ongoing basis. And build your own is great for those folks. The next in converged infrastructure, where we're really talking about an external storage array with applications that need to use data services native to a storage array. And self-select compute for scaling that compute for their particular need, and owning that three tiers architecture and its associated integration, but not having to sustain it because it's converged. There are enormous number of applications out there that benefit from that. I think the third one was, you talked about hyper-converged. I'll go back to when we first introduced our hyper-converged product to the market. Which is now leading the industry for quite some time, VxRail. We had always said that customers will consume hyper-converged and converged for different use cases and different applications. The maturity of hyper-converged has come to the point where you can run virtually any application that you would like on it. And this comes down to really two vectors of consideration. One, am I going to run hyper-converged versus converged based on my operational preference? You know, hyper-converged incorporates software defined storage, predominantly a compute operating plane. Converge as mentioned previously uses that external storage array has some type of systems fabric and dedicated compute resources with access into those your operational preference is one aspect of it. And then having applications that need the data services of an external storage, primary storage array are the other aspect of deciding whether those two things are needed in your particular environment. We find more and more customers out there that have an investment of both, not one versus the other. That's not to say that there aren't customers that only have one, they exist, but a majority of customers have both. >> So Joakim, I want to come back to the sort of attributes from the application requirements perspective. When you think about mission-critical, you think about availability, scale, recoverability, data protection. I wonder if you could talk a little bit about those attributes. And again, what is it about converged infrastructure that that is the best fit and the right strategic fit for supporting those demanding applications and workloads? >> Now, when it comes to SAP, we're talking about clients and customers, most mission-critical data and information and applications. And hence the requirements on the underlying infrastructure is absolutely on the very top of what the IT organization needs to deliver. This is why, when we talk about SAP, the requirements for high availability protection disaster recovery is very, very high. And it doesn't only involve a single system. As mentioned before, SAP is not a standalone application, but rather a landscape of systems that needs to be kept consistent. And that's what a CI platform does so well. It can consolidate workloads, whether it's big data or the transactional standard workloads of SAP, ERP or UCC. The converged platforms are able to put the very highest of availability protection standards into this whole landscape and making a really unique platform for CI workloads. And at the same time, it enables our customers to accelerate those modernization journeys into things such as ML, AI, IOT, even blockchain scenarios, where we've built out our capabilities to accelerate these implementations with the help of the underlying CI platforms and the rest of the SAP environment. >> Got it. Stu, I want to go to you. You had mentioned before the cloud operating model and something that we've been talking about for a long time and Wikibon. So can converged infrastructure substantially mimic that cloud operating model and how so? What are the key ingredients of being able to create that experience on-prem? >> Yeah, well, Dave as, we've watched for more than the last decade, the cloud has looked more and more like some of the traditional enterprise things that we would look for and the infrastructure in private clouds have gone more and more cloud-like and embrace that model. So, you know, I got, I think back to the early days, Dave, we talked about how cloud was supposed to just be, you know, "simple". If you look at deploying in the cloud today, it is not simple at all that. There are so many choices out there, you know, way more than I had an initial data center. In the same way, you know, I think, you know, the original converged infrastructure from Dell, if you look at the feedback, the criticism was, you know, oh, you can have it in any color you want, as long as black, just like the Ford model T. But it was that simplicity and consistency that helped build out most of what we were talking about the cloud models I wanted to know that I had a reliable substrate platform to build on top of it. But if you talk about Dave today and in the future, what do we want? First of all, I need that operating model in a multicloud world. So, you know, we look at the environments that can spread, but beyond just a single cloud, because customers today have multiple environments, absolutely hybrid is a big piece of that. We look at what VMware's doing, look at Microsoft, Red Hat, even Amazon are extended beyond just a cloud and going into hybrid and multicloud models. Automation, a critical piece of that. And we've seen, you know, great leaps and bounds in the last couple of generations of what's happening in CI to take advantage of automation. Because we know we've gone beyond what humans can just manage themselves and therefore, you know, true automation is helping along those environments. So yes, absolutely, Dave. You know, that the lines are blurred between what the private cloud and the public cloud. And it's just that overall cloud operating model and helping customers to deal with their data and their applications, regardless of where it lives. >> Well, you know, Trey in the early days of cloud and conversion infrastructure, that homogeneity that Stu was talking about any color, as long as it's black. That was actually an advantage to removing labor costs, that consistency and that standardization. But I'm interested in how CI has evolved, its, you know, added in optionality. I mean Joakim was just talking about blockchain, so all kinds of new services. But how has CCI evolved in the better part of the last decade and what are some of the most recent innovations that people should be thinking about or aware of? >> So I think the underlying experience of CI has remained relatively constant. And we talk about the experience that customers get. So if you just look at the data that we've analyzed for over a decade now, you know, one of the data points that I love is 99% of our customers who buy CI say they have virtually no downtime anymore. And, that's a great testament. 84% of our customers say that they have that their IT operations run more efficiently. The reality around how we delivered that in the past was through services and humans performing these integrations and the upkeep associated with the sustaining of the architecture. What we've focused on at Dell Technologies is really bringing technologies that allow us to automate those human integrations and best practices. In such a way where they can become more repeatable and consumable by more customers. We don't have to have as many services folks deploying these systems as we did in the past. Because we're using software intelligence to embed that human knowledge that we used to rely on individuals exclusively for. So that's one of the aspects of the architecture. And then just taking advantage of all the new technologies that we've seen introduce over the last several years from all flash architectures and NVMe on the horizon, NVMe over fabric. All of these things as we orchestrate them in software will enable them to be more consumable by the average everyday customer. Therefore it becomes more economical for them to deploy infrastructure on premises to support mission-critical applications. >> So Stu, what about cloud and multicloud, how does CI support that? Where do those fit in? Are they relevant? >> Yeah, Dave, so absolutely. As I was talking about before, you know, customers have hybrid and multicloud environments and managing across these environments are pretty important. If I look at the Dell family, obviously they're leveraging heavily VMware as the virtualization layer. And VMware has been moving heavily as to how support containerized and incubates these environments and extend their management to not only what's happening in the data center, but into the cloud environment with VMware cloud. So, you know, management in a multicloud world Dave, is one of those areas that we definitely have some work to do. Something we've looked at Wikibon for the last few years. Is how will multicloud be different than multi-vendor? Because that was not something that the industry had done a great job of solving in the past. But you know, customers are looking to take advantage of the innovation, where it is in the services. And you know, the data first architecture is something that we see and therefore that will bring them to many services and many places. >> Oh yeah, I was talking before about in the early days of CI and even a lot of organizations, some organizations, anyway, there's still these sort of silos of, you know, storage, networking, compute resources. And you think about DevOps, where does DevOps fit into this whole equation? Maybe Stu you could take a stab at it and anybody else who wants to chime in. >> Yeah, so Dave, great, great point there. So, you know, when we talk about those silos, DevOps is one of those movements to really help the unifying force to help customers move faster. And so therefore the development team and the operations team are working together. Things like security are not a bolt-in but something that can happen along the entire path. A more recent addition to the DevOps movement also is something like FinOps. So, you know, how do we make sure that we're not just having finance sign off on things and look back every quarter, but in real time, understand how we're architecting things, especially in the cloud so that we remain responsible for that model. So, you know, speed is, you know, one of the most important pieces for business and therefore the DevOps movement, helping customers move faster and, you know, leverage and get value out of their infrastructure, their applications and their data. >> Yeah, I would add to this that I think the big transition for organizations, cause I've seen it in developing my own organization, is getting IT operators to think programmatically instead of configuration based. Use the tool to configure a device. Think about how do we create programmatic instruction to interacts with all of the devices that creates that cloud-like adaptation. Feeds in application level signaling to adapt and change the underlying configuration about that infrastructure to better run the application without relying upon an IT operator, a human to make a change. This, sort of thinking programmatically is I think one of the biggest obstacles that the industry face. And I feel really good about how we've attacked it, but there is a transformation within that dialogue that every organization is going to navigate through at their own pace. >> Yeah, infrastructure is code automation, this a fundamental to digital transformation. Joakim, I wonder if you could give us some insight as you talk to SAP customers, you know, in Europe, across the EMEA, how does the pandemic change this? >> I think the pandemic has accelerated some of the movements that we already saw in the SAP world. There is obviously a force for making sure that we get our financial budgets in shape and that we don't over spend on our cost levels. And therefore it's going to be very important to see how we can manage all these new revenue generating projects that IT organizations and business organizations have planned around new customer experience initiatives, new supply chain optimization. They know that they need to invest in these projects to stay competitive and to gain new competitive edge. And where CI plays an important part is in order to, first of all, keep costs down in all of these projects, make sure to deliver a standardized common platform upon which all these projects can be introduced. And then of course, making sure that availability and risks are kept high versus at a minimum, right? Risk low and availability at a record high, because we need to stay on with our clients and their demands. So I think again, CI is going to play a very important role. As we see customers go through this pandemic situation and needing to put pressure on both innovation and cost control at the same time. And this is where also our new upcoming data strategies will play a really important part as we need to leverage the data we have better, smarter and more efficient way. >> Got it. Okay guys, we're running out of time, but Trey, I wonder if you could, you know break out your telescope or your crystal ball, give us some visibility into the futures of converged infrastructure. What should we be expecting? >> So if you look at the last release of this last technology that we released in power one, it was all about automation. We'll build on that platform to integrate other converged capability. So if you look at the converged systems market hyper-converged is very much an element of that. And I think that we're trending to is recognizing that we can deliver an architecture that has hyper-converged and converged attributes all in a single architecture and then dial up the degrees of automation to create more adaptations for different type of application workloads, not just your traditional three tier application workloads, but also those microservices based applications that one may historically think, maybe it's best to that off premises. We feel very confident that we are delivering platforms out there today that can run more economically on premises, provide better security, better data governance, and a lot of the adaptations, the enhancements, the optimizations that we'll deliver in our converged platforms of the future about colliding new infrastructure models together, and introducing more levels of automation to have greater adaptations for applications that are running on it. >> Got it. Trey, we're going to give you the last word. You know, if you're an architect of a large organization, you've got some mission-critical workloads that, you know, you're really trying to protect. What's the takeaway? What's really the advice that you would give those folks thinking about the sort of near and midterm and even longterm? >> My advice is to understand that there are many options. We sell a lot of independent component technologies and data centers that run every organization's environment around the world. We sell packaged outcomes and hyper-converged and converged. And a lot of companies buy a little bit of build your own, they buy some converged, they buy some hyper-converged. I would employ everyone, especially in this climate to really evaluate the packaged offerings and understand how they can benefit their environment. And we recognize that everything that there's not one hammer and everything is a nail. That's why we have this broad portfolio of products that are designed to be utilized in the most efficient manners for those customers who are consuming our technologies. And converged and hyper-converge are merely another way to simplify the ongoing challenges that organizations have in managing their data estate and all of the technologies they're consuming at a rapid pace in concert with the investments that they're also making off premises. So this is very much the technologies that we talked today are very much things that organizations should research, investigate and utilize where they best fit in their organization. >> Awesome guys, and of course there's a lot of information at dell.com about that. Wikibon.com has written a lot about this and the many, many sources of information out there. Trey, Joakim, Stu thanks so much for the conversation. Really meaty, a lot of substance, really appreciate your time, thank you. >> Thank you guys. >> Thank you Dave. >> Thanks Dave. >> And everybody for watching. This is Dave Vellante for theCUBE and we'll see you next time. (soft music)

>> Narrator: From theCUBE's studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is theCUBE Conversation. >> You know, businesses have a staggering number of options today to support mission-critical applications. And much of the world's mission-critical data happens to live on converged infrastructure. Converged infrastructure is really designed to support the most demanding workloads. Words like resilience, performance, scalability, recoverability, et cetera. Those are the attributes that define converged infrastructure. Now with COVID-19 the digital transformation mandate, as we all know has been accelerated and buyers are demanding more from their infrastructure, and in particular converged infrastructure. Hi everybody this is Dave Vellante and welcome to this power panel where we're going to explore converged infrastructure, look at its past, its present and its future. And we're going to explore several things. The origins of converged infrastructure, why CI even came about. And what's its historic role been in terms of supporting mission-critical applications. We're going to look at modernizing workloads. What are the opportunities and the risks and what's converged infrastructures role in that regard. How has converged infrastructure evolved? And how will it support cloud and multicloud? And ultimately what's the future of converged infrastructure look like? And to examine these issues, we have three great guests, Trey Layton is here. He is the senior vice president for converged infrastructure and software engineering and architecture at Dell Technologies. And he's joined by Joakim Zetterblad. Who's the director of the SAP practice for EMEA at Dell technologies. And our very own Stu Miniman. Stu is a senior analyst at Wikibon. Guys, great to see you all welcome to theCUBE. Thanks for coming on. >> Thanks for having us. >> Great. >> Trey, I'm going to start with you. Take us back to the early days of converged infrastructure. Why was it even formed? Why was it created? >> Well, if you look back just over a decade ago, a lot of organizations were deploying virtualized environments. Everyone was consolidated on virtualization. A lot of technologies were emerging to enhance that virtualization outcome, meaning acceleration capabilities and storage arrays, networking. And there was a lot of complexity in integrating all of those underlying infrastructure technologies into a solution that would work reliably. You almost had to have a PhD and all of the best practices of many different companies integrations. And so we decided as Dell EMC, Dell Technologies to invest heavily in this area of manufacturing best practices and packaging them so that customers could acquire those technologies and already integrated fully regression tested architecture that could sustain virtually any type of workload that a company would run. And candidly that packaging, that rigor around testing produced a highly reliable product that customers now rely on heavily to operationalize greater efficiencies and run their most critical applications that power their business and ultimately the world economy. >> Now Stu, cause you were there. I was as well at the early days of the original announcement of CI. Looking back and sort of bringing it forward Stu, what was the business impact of converged infrastructure? >> Well, Dave as Trey was talking about it was that wave of virtualization had gone from, you know, just supporting many applications to being able to support all of your applications. And especially if you talk about those high value, you know business mission, critical applications, you want to make sure that you've got a reliable foundation. What the Dell tech team has done for years is make sure that they fully understand, you know the life cycle of testing that needs to happen. And you don't need to worry about, you know, what integration testing you need to do, looking at support major CS and doing a lot of your own sandbox testing, which for the most part was what enterprises needed to do. You said, okay, you know, I get the gear, I load the virtualization and then I have to see, you know, tweak everything to figure out how my application works. The business impact Dave, is you want to spend more time focusing on the business, not having to turn all the dials and worry about, do I get the performance I need? Does it have the reliability uptime that we need? And especially if we're talking about those business critical applications, of course, these are the ones that are running 24 by seven and if they go down, my business goes down with it. >> Yeah, and of course, you know, one of the other major themes we saw with conversion infrastructure was really attacking the IT labor problem. You had separate compute or server teams, storage teams, networking teams, they oftentimes weren't talking together. So there was a lot of inefficiency that converged infrastructure was designed to attack. But I want to come to the SAP expert. Joakim, that's really your wheelhouse. What is it about converged infrastructure that makes it suitable for SAP application specifically? >> You know, if you look at a classic SAP client today, there's really three major transformational waves that all SAP customers are faced with today, it's the move to S/4HANA, the introduction of this new platform, which needs to happen before 2027. It's the introduction of a multicloud cloud or operating model. And last but not least, it is the introduction of new digitization or intelligent technologies such as IOT, machine learning or artificial intelligence. And that drove to the need of a platform that could address all these three transformational waves. It came with a lot of complexity, increased costs, increased risk. And what CI did so uniquely was to provide that Edge to Core to Cloud strategy. Fully certified for both HANA, non HANA workloads for the classical analytical and transactional workloads, as well as the new modernization technologies such as IOT, machine learning, big data and analytics. And that created a huge momentum for converged in our SAP accounts. >> So Trey, I want to go to you cause you're the deep technical expert here. Joakim just mentioned uniqueness. So what are the unique characteristics of converged infrastructure that really make it suitable for handling the most demanding workloads? >> Well, converged infrastructure by definition is the integration of an external storage array with a highly optimized compute platform. And when we build best practices around integrating those technologies together, we essentially package optimizations that allow a customer to increase the quantity of users that are accessing those workloads or the applications that are driving database access in such a way where you can predictably understand consumption and utilization in your environment. Those packaged integrations are kind of like. You know, I have a friend that owns a race car shop and he has all kinds of expertise to build cars, but he has a vehicle that he buys is his daily driver. The customization that they've created to build race cars are great for the race cars that go on the track, but he's building a car on his own, it didn't make any sense. And so what customers found was the ability to acquire a packaged infrastructure with all these infrastructure optimizations, where we package these best practices that gave customers a reliable, predictable, and fully supported integration, so they didn't have to spend 20 hour support calls trying to discover and figure out what particular customization that they had employed for their application, that had some issue that they needed to troubleshoot and solve. This became a standard out of the box integration that the best and the brightest package so that customers can consume it at scale. >> So Joakim, I want to ask you let's take the sort of application view. Let's sort of flip the picture a little bit and come at it from that prism. How, if you think about like core business applications, how have they evolved over the better part of the last decade and specifically with regard to the mission-critical processes? >> So what we're seeing in the process industry and in the industry of mission-critical applications is that they have gone from being very monolithic systems where we literally saw a single ERP components such as all three or UCC. Whereas today customers are faced with a landscape of multiple components. Many of them working both on and off premise, there are multicloud strategies in place. And as we mentioned before, with the introduction of new IOT technologies, we see that there is a flow of information of data that requires a whole new set of infrastructure of components of tools to make these new processes happen. And of course, the focus in the end of the day is all on business outcomes. So what industries and companies doesn't want to do is to focus all their time in making sure that these new technologies are working together, but really focusing on how can I make an impact? How can I start to work in a better way with my clients? So the focus on business outcome, the focus on integrating multiple systems into a single consolidated approach has become so much more important, which is why the modernization of the underlying infrastructure is absolutely key. Without consolidation, without a simplification of the management and orchestration. And without the cloud enabled platform, you won't get there. >> So Stu that's key, what Joakim just said in terms of modernizing the application as being able to manage them, not as one big monolith, but integration with other key systems. So what are the options? Wikibon has done some research on this, but what are the options for modernizing workloads, whether it's on-Prem or off-prem and what are some of the trade offs there? >> Yeah, so Dave, first of all, you know, one of the biggest challenges out there is you don't just want to, you know, lift and shift. If anybody's read research for it from Wikibon, Dave, for a day, for the 10 years, I've been part of it talks about the challenges, if you just talk about migrating, because while it sounds simple, we understand that there are individual customizations that every customer's made. So you might get part of the way there, but there's often the challenges that will get in the way that could cause failure. And as we talked about for you, especially your mission-critical applications, those are the ones that you can't have downtime. So absolutely customers are reevaluating their application portfolio. You know, there are a lot of things to look at. First of all, if you can, certain things can be moved to SAS. You've seen certain segments of the market. Absolutely SAS can be preferred methodology, if you can go there. One of the biggest hurdles for SAS of course, is there's retraining of the workforce. Certain applications they will embracing of that because they can take advantage of new features, get to be able to use that wherever they are. But in other cases, there are the SAS doesn't have the capability or it doesn't fit into the workflow of the business. The cloud operating model is something we've been talking about it with you Dave, for many years. When you've seen rapid maturation of what originally was called "private cloud", but really was just virtualization plus with a little bit of a management layer on top. But now much of the automation that you build in AI technologies, you know, Trey's got a whole team working on things that if you talk to his team, it sounds very similar to what you had the same conversation should have with cloud providers. So "cloud" as an operating model, not a destination is what we're going for and being able to take advantage of automation and the like. So where your application sits, absolutely some consideration. And what we've talked about Dave, you know, the governance, the security, the reliability, the performance are all reasons why being able to keep things, you know, under my environment with an infrastructure that I have control over is absolutely one of the reasons why am I keep things more along a converged infrastructure, rather than just saying to go through the challenge of migration and optimizing and changing to something in a more of a cloud native methodology. >> What about technical debt? Trey, people talk about technical debt as a bad thing, what is technical debt? Why do I want to avoid it? And how can I avoid it? And specifically, I know, Trey, I've thrown a lot of questions at you yet, but what is it about converged infrastructure and its capabilities that helped me avoid that technical debt? >> Well, it's an interesting thing, when you deploy an environment to support a mission-critical application, you have to make a lot of implementation decisions. Some of those decisions may take you down a path that may have a finite life. And that once you reached the life expectancy of that particular configuration, you now have debt that you have to reconcile. You have to change that architecture, that configuration. And so what we do with converged infrastructure is we dedicate a team of product management, an entire product management organization, a team of engineers that treat the integrations of the architecture as a releases. And we think long range about how do we avoid not having to change the underlying architecture. And one of the greatest testaments to this is in our conversion infrastructure products over the last 11 years, we've only saw two major architectural changes while supporting generational changes in underlying infrastructure capabilities well beyond when we first started. So converged infrastructure approach is about how do we build an architecture that allows you to avoid those dead-end pathways in those integration decisions that you would normally have to make on your own. >> Joakim, I wanted to ask you, you've mentioned monolithic applications before. That's sort of, we're evolving beyond that with application architectures, but there's still a lot of monoliths out there so. And a lot of customers want to modernize those application and workloads. What, in your view, what are you seeing as the best path and the best practice for modernizing some of those monolithic workloads? >> Yeah, so Dave, as clients today are trying to build a new intelligent enterprise, which is one of SAP's leading a guidance today. They needed to start to look at how to integrate all these different systems and applications that we talked about before into the common business process framework that they have. So consolidating workloads from big data to HANA, non HANA systems, cloud, non-cloud applications into a single framework is an absolute key to that modernization strategy. The second thing which I also mentioned before is to take a new grip around orchestration and management. We know that as customers seek this intelligent approach with both analytical data, as well as experience and transactional data, we must look for new ways to orchestrate and manage those application workloads and data flows. And this is where we slowly, slowly enter into the world of a enterprise data strategy. And that's again, where converged as a very important part to play in order to build these next generation platforms that can both consolidate, simplify. And at the same time enable us to work in a cloud enabled fashion with our cloud operating model that most of our clients seek today. >> So Stu, why can't I just shove all this stuff into the public cloud and call it a day? >> Yeah, well, Dave, we've seen some people that, you know, I have a cloud first strategy and often those are the same companies that are quickly doing what we call "repatriation". I bristle a little bit when I hear these, because often it's, I've gone to the cloud without understanding how I take advantage of it, not understanding the full financial ramifications what I'm going to need to do. And therefore they quickly go back to a world that they understand. So, cloud is not a silver bullet. We understand in technology, Dave, you know, things are complicated. There's all the organizational operational pieces they do. There are excellent cloud services and it's really it's innovation. You know, how do I take advantage of the data that I have, how I allow my application to move forward and respond to the business. And really that is not something that only happens in the public clouds. If I can take advantage of infrastructure that gets me along that journey to more of a cloud model, I get the business results. So, you know, automation and APIs and everything and the Ops movement are not something that are only in the public clouds, but something that we should be embracing holistically. And absolutely, that ties into where today and tomorrow's converge infrastructure are going. >> Yeah, and to me, it comes down to the business case too. I mean, you have to look at the risk-reward. The risk of changing something that's actually working for your business versus what the payback is going to be. You know, if it ain't broken, don't fix it, but you may want to update it, change the oil every now and then, you know, maybe prune some deadwood and modernize it. But Trey, I want to come back to you. Let's take a look at some of the options that customers have. And there are a lot of options, as I said at the top. You've got do it yourself, you got a hyper-converged infrastructure, of course, converged infrastructure. What are you seeing as the use case for each of these deployment options? >> So, build your own. We're really talking about an organization that has the expertise in-house to understand the integration standards that they need to deploy to support their environment. And candidly, there are a lot of customers that have very unique application requirements that have very much customized to their environment. And they've invested in the expertise to be able to sustain that on an ongoing basis. And build your own is great for those folks. The next in converged infrastructure, where we're really talking about an external storage array with applications that need to use data services native to a storage array. And self-select compute for scaling that compute for their particular need, and owning that three tiers architecture and its associated integration, but not having to sustain it because it's converged. There are enormous number of applications out there that benefit from that. I think the third one was, you talked about hyper-converged. I'll go back to when we first introduced our hyper-converged product to the market. Which is now leading the industry for quite some time, VxRail. We had always said that customers will consume hyper-converged and converged for different use cases and different applications. The maturity of hyper-converged has come to the point where you can run virtually any application that you would like on it. And this comes down to really two vectors of consideration. One, am I going to run hyper-converged versus converged based on my operational preference? You know, hyper-converged incorporates software defined storage, predominantly a compute operating plane. Converge as mentioned previously uses that external storage array has some type of systems fabric and dedicated compute resources with access into those your operational preference is one aspect of it. And then having applications that need the data services of an external storage, primary storage array are the other aspect of deciding whether those two things are needed in your particular environment. We find more and more customers out there that have an investment of both, not one versus the other. That's not to say that there aren't customers that only have one, they exist, but a majority of customers have both. >> So Joakim, I want to come back to the sort of attributes from the application requirements perspective. When you think about mission-critical, you think about availability, scale, recoverability, data protection. I wonder if you could talk a little bit about those attributes. And again, what is it about converged infrastructure that that is the best fit and the right strategic fit for supporting those demanding applications and workloads? >> Now, when it comes to SAP, we're talking about clients and customers, most mission-critical data and information and applications. And hence the requirements on the underlying infrastructure is absolutely on the very top of what the IT organization needs to deliver. This is why, when we talk about SAP, the requirements for high availability protection disaster recovery is very, very high. And it doesn't only involve a single system. As mentioned before, SAP is not a standalone application, but rather a landscape of systems that needs to be kept consistent. And that's what a CI platform does so well. It can consolidate workloads, whether it's big data or the transactional standard workloads of SAP, ERP or UCC. The converged platforms are able to put the very highest of availability protection standards into this whole landscape and making a really unique platform for CI workloads. And at the same time, it enables our customers to accelerate those modernization journeys into things such as ML, AI, IOT, even blockchain scenarios, where we've built out our capabilities to accelerate these implementations with the help of the underlying CI platforms and the rest of the SAP environment. >> Got it. Stu, I want to go to you. You had mentioned before the cloud operating model and something that we've been talking about for a long time and Wikibon. So can converged infrastructure substantially mimic that cloud operating model and how so? What are the key ingredients of being able to create that experience on-prem? >> Yeah, well, Dave is, we've watched for more than the last decade, the cloud has looked more and more like some of the traditional enterprise things that we would look for and the infrastructure in private clouds have gone more and more cloud-like and embrace that model. So, you know, I got, I think back to the early days, Dave, we talked about how cloud was supposed to just be, you know, "simple". If you look at deploying in the cloud today, it is not simple at all that. There are so many choices out there, you know, way more than I had an initial data center. In the same way, you know, I think, you know, the original converged infrastructure from Dell, if you look at the feedback, the criticism was, you know, oh, you can have it in any color you want, as long as black, just like the Ford model T. But it was that simplicity and consistency that helped build out most of what we were talking about the cloud models I wanted to know that I had a reliable substrate platform to build on top of it. But if you talk about Dave today and in the future, what do we want? First of all, I need that operating model in a multicloud world. So, you know, we look at the environments that can spread, but beyond just a single cloud, because customers today have multiple environments, absolutely hybrid is a big piece of that. We look at what VMware's doing, look at Microsoft, Red Hat, even Amazon are extended beyond just a cloud and going into hybrid and multicloud models. Automation, a critical piece of that. And we've seen, you know, great leaps and bounds in the last couple of generations of what's happening in CI to take advantage of automation. Because we know we've gone beyond what humans can just manage themselves and therefore, you know, true automation is helping along those environments. So yes, absolutely, Dave. You know, that the lines are blurred between what the private cloud and the public cloud. And it's just that overall cloud operating model and helping customers to deal with their data and their applications, regardless of where it is. >> Well, you know, Trey in the early days of cloud and conversion infrastructure, that homogeneity that Stu was talking about any color, as long as it's black. That was actually an advantage to removing labor costs, that consistency and that standardization. But I'm interested in how CI has evolved, its, you know, added in optionality. I mean Joakim was just talking about blockchain, so all kinds of new services. But how has CCI evolved in the better part of the last decade and what are some of the most recent innovations that people should be thinking about or aware of? >> So I think the underlying experience of CI has remained relatively constant. And we talk about the experience that customers get. So if you just look at the data that we've analyzed for over a decade now, you know, one of the data points that I love is 99% of our customers who buy CI say they have virtually no downtime anymore. And, that's a great testament. 84% of our customers say that they have that their IT operations run more efficiently. The reality around how we delivered that in the past was through services and humans performing these integrations and the upkeep associated with the sustaining of the architecture. What we've focused on at Dell Technologies is really bringing technologies that allow us to automate those human integrations and best practices. In such a way where they can become more repeatable and consumable by more customers. We don't have to have as many services folks deploying these systems as we did in the past. Because we're using software intelligence to embed that human knowledge that we used to rely on individuals exclusively for. So that's one of the aspects of the architecture. And then just taking advantage of all the new technologies that we've seen introduce over the last several years from all flash architectures and NVMe on the horizon, NVMe over fabric. All of these things as we orchestrate them in software will enable them to be more consumable by the average everyday customer. Therefore it becomes more economical for them to deploy infrastructure on premises to support mission-critical applications. >> So Stu, what about cloud and multicloud, how does CI support that? Where do those fit in? Are they relevant? >> Yeah, Dave, so absolutely. As I was talking about before, you know, customers have hybrid and multicloud environments and managing across these environments are pretty important. If I look at the Dell family, obviously they're leveraging heavily VMware as the virtualization layer. And VMware has been moving heavily as to how support containerized and incubates these environments and extend their management to not only what's happening in the data center, but into the cloud environment with VMware cloud. So, you know, management in a multicloud world Dave, is one of those areas that we definitely have some work to do. Something we've looked at Wikibon for the last few years. Is how will multicloud be different than multi-vendor? Because that was not something that the industry had done a great job of solving in the past. But you know, customers are looking to take advantage of the innovation, where it is in the services. And you know, the data first architecture is something that we see and therefore that will bring them to many services and many places. >> Oh yeah, I was talking before about in the early days of CI and even a lot of organizations, some organizations, anyway, there's still these sort of silos of, you know, storage, networking, compute resources. And you think about DevOps, where does DevOps fit into this whole equation? Maybe Stu you could take a stab at it and anybody else who wants to chime in. >> Yeah, so Dave, great, great point there. So, you know, when we talk about those silos, DevOps is one of those movements to really help the unifying force to help customers move faster. And so therefore the development team and the operations team are working together. Things like security are not a built-in but something that can happen along the entire path. A more recent addition to the DevOps movement also is something like FinOps. So, you know, how do we make sure that we're not just having finance sign off on things and look back every quarter, but in real time, understand how we're architecting things, especially in the cloud so that we remain responsible for that model. So, you know, speed is, you know, one of the most important pieces for business and therefore the DevOps movement, helping customers move faster and, you know, leverage and get value out of their infrastructure, their applications and their data. >> Yeah, I would add to this that I think the big transition for organizations, cause I've seen it in developing my own organization, is getting IT operators to think programmatically instead of configuration based. Use the tool to configure a device. Think about how do we create programmatic instruction to interacts with all of the devices that creates that cloud-like adaptation. Feeds in application level signaling to adapt and change the underlying configuration about that infrastructure to better run the application without relying upon an IT operator, a human to make a change. This, sort of thinking programmatically is I think one of the biggest obstacles that the industry face. And I feel really good about how we've attacked it, but there is a transformation within that dialogue that every organization is going to navigate through at their own pace. >> Yeah, infrastructure is code automation, this a fundamental to digital transformation. Joakim, I wonder if you could give us some insight as you talk to SAP customers, you know, in Europe, across the EMEA, how does the pandemic change this? >> I think the pandemic has accelerated some of the movements that we already saw in the SAP world. There is obviously a force for making sure that we get our financial budgets in shape and that we don't over spend on our cost levels. And therefore it's going to be very important to see how we can manage all these new revenue generating projects that IT organizations and business organizations have planned around new customer experience initiatives, new supply chain optimization. They know that they need to invest in these projects to stay competitive and to gain new competitive edge. And where CI plays an important part is in order to, first of all, keep costs down in all of these projects, make sure to deliver a standardized common platform upon which all these projects can be introduced. And then of course, making sure that availability and risks are kept high versus at a minimum, right? Risk low and availability at a record high, because we need to stay on with our clients and their demands. So I think again, CI is going to play a very important role. As we see customers go through this pandemic situation and needing to put pressure on both innovation and cost control at the same time. And this is where also our new upcoming data strategies will play a really important part as we need to leverage the data we have better, smarter and more efficient way. >> Got it. Okay guys, we're running out of time, but Trey, I wonder if you could, you know break out your telescope or your crystal ball, give us some visibility into the futures of converged infrastructure. What should we be expecting? So if you look at the last release of this last technology that we released in power one, it was all about automation. We'll build on that platform to integrate other converged capability. So if you look at the converged systems market hyper-converged is very much an element of that. And I think that we're trending to is recognizing that we can deliver an architecture that has hyper-converged and converged attributes all in a single architecture and then dial up the degrees of automation to create more adaptations for different type of application workloads, not just your traditional three tier application workloads, but also those microservices based applications that one may historically think, maybe it's best to that off premises. We feel very confident that we are delivering platforms out there today that can run more economically on premises, provide better security, better data governance, and a lot of the adaptations, the enhancements, the optimizations that we'll deliver in our converged platforms of the future about colliding new infrastructure models together, and introducing more levels of automation to have greater adaptations for applications that are running on it. >> Got it. Trey, we're going to give you the last word. You know, if you're an architect of a large organization, you've got some mission-critical workloads that, you know, you're really trying to protect. What's the takeaway? What's really the advice that you would give those folks thinking about the sort of near and midterm and even longterm? >> My advice is to understand that there are many options. We sell a lot of independent component technologies and data centers that run every organization's environment around the world. We sell packaged outcomes and hyper-converged and converged. And a lot of companies buy a little bit of build your own, they buy some converged, they buy some hyper-converged. I would employ everyone, especially in this climate to really evaluate the packaged offerings and understand how they can benefit their environment. And we recognize that everything that there's not one hammer and everything is a nail. That's why we have this broad portfolio of products that are designed to be utilized in the most efficient manners for those customers who are consuming our technologies. And converged and hyper-converge are merely another way to simplify the ongoing challenges that organizations have in managing their data estate and all of the technologies they're consuming at a rapid pace in concert with the investments that they're also making off premises. So this is very much the technologies that we talked today are very much things that organizations should research, investigate and utilize where they best fit in their organization. >> Awesome guys, and of course there's a lot of information at dell.com about that. Wikibon.com has written a lot about this and the many, many sources of information out there. Trey, Joakim, Stu thanks so much for the conversation. Really meaty, a lot of substance, really appreciate your time, thank you. >> Thank you guys. >> Thank you Dave. >> Thanks Dave. >> And everybody for watching. This is Dave Vellante for theCUBE and we'll see you next time. (soft music)

>>from around the globe. It's the Cube with digital coverage of Red Hat. Summit 2020 Brought to you by Red Hat. >>Yeah. Hi. And welcome back to the Cube's coverage of Red Hat Summit 2020 on stew. Minimum in this year's event, of course, happened globally. Which means we're talking to Red Hat executives, customers and partners where they are around the globe on and happy to welcome back to the program. One of our cube alumni, Badani, who is the senior vice president. Cloud platforms at Red Hat is great to see you. >>Yeah, thanks a lot for having me back on. >>Yeah, absolutely. So you know, the usual wall to wall coverage that we do in San Francisco? Well, it's now the global digital, a little bit of a dispersed architecture to do these environments. Which reminds me a little bit of your world. So, you know, the main keynote stage. You know, Paul's up There is the, you know, new CEO talking about open hybrid cloud. And of course, the big piece of that is, you know, open shift and the various products, you know, in the portfolio there, So ah, personal. We know there's not, you know, big announcements of, you know, launches and the like, But your team and the product portfolio has been going through a lot of changes. A lot of growth since last time we connected. So bring us up to speed as to what we should know about. >>Sure. Thanks s Oh, yes, not not a huge focus around announcements, this summit, especially given everything going on in the world around us today. Ah, but you know, that being said, we continue our open shift journey. We started that well, you know, many years ago. But in 2015 and we had our first release both the stone kubernetes in a container focused platform. Ever since then, you know, we continue to groan to evolve Atlassian count now over 2000 customers globally. I trusted the platform in industries that literally every industry and also obviously every job around around the globe. So that's been great to see you. And last summit, we actually announced a fairly significant enhancement of a platform with a large fortune before big focus around created manageability ability to use operators which is, you know, kubernetes concept to make applications much more manageable. um, you know, when they're being run natively within within the platform, we continue to invest. There s so there's a new release off the platform. Open shift 4.4 based on kubernetes 1.17 big made available to our customers globally. And then really, sort of this this notion of over the air updates right to create a platform that is almost autonomous in nature, you know, acts more like your your your mobile phone in the way you can manage and and update and upgrade. I think that's a key value proposition that, you know, we're providing to our customers. So we're excited to see that and then be able to share that with you. >>Yeah, so a chef won't want to dig into that a little bit. So one of the discussions we've had in the industry for many years is how much consistency there needs to be across my various environments. We know you know Kubernetes is great, but it is not a silver bullet. You know, customers will have clusters. They will have different environments. I have what I do in my data centers or close. I'm using things in the public clouds and might be using different communities offering. So you know, as you said, there's things that Red Hat is doing. But give us a little insight into your customers as to how should they be thinking about it? How do they manage it? One of the new pieces that we're building it into a little bit, of course, from a management sand point is ACM, which I know open shift today, but going toe support some of the other kubernetes options you know down the road. So how should customers be thinking about this? How does Red Hat think about managing? Did this ever complex world >>Yes, So Student should have been talking about this for several years now, right with regard to just the kind of the customers are doing. And let's start with customers for us, because it's all about you know, the value for them so that this year's summit we're announcing some innovation award winners, right? So a couple of interesting ones BMW and Ford, um, you know BMW, you know, building It's next generation autonomous driving platform using containers. And then, you know, police Massive data platform an open ship for doing a lot of interesting work with regard to, uh, bringing together. It's a development team taking advantage of existing investments in hardware and so on, You know, the in place, you know, with the platform. But also, increasingly, companies that are you know, for example, in all accept. All right, so we've got the Argentine Ministry of Health. We've got a large electricity distribution company adopting containers, adopting middleware technology, for example, on open shift until great value. Right. So network alerts when there's electricity outrage going from three minutes to 10 seconds. And so, as you now see more and more customers doing, you know, more and more if you will mission critical activities on these platforms to your points to your question is a really good one is not got clusters running in multiple markets, right? Perhaps in their own data center, across multiple clouds and managing these clusters at scale, it becomes, you know, more, more critical up. And so, you know, we've been doing a bunch of work with regard to the team, and I actually joined us from IBM has been working on this. Let's remember technology for a while, and it's part of Red Hat. We're now releasing in technology preview. Advanced cluster management trying to solve address questions around. What does it mean to manage the lifecycle of the application process? Clusters. How do I monitor and imbue cluster help? You know, regardless of you know, where they run. How do I have consistent security and compliance for my policies across the different clusters. So really excited, right? It is a really interesting technology. It's probably most advanced placement. That's our market. What? IBM working on it. We know. Well, before you know, the team from from there, you know, joined us. And now we're making it much more >>widely available. Yeah, actually, I just want one of things that really impressed some of those customers. First off. Congratulations. 2000 you know, great milestone there. And yeah, we've had We're gonna have some of the opportunity to talk on the cube. Some of those essential services you talk Ministry of Health. Obviously, with a global pandemic on critically environment, energy companies need to keep up and running. I've got Vodafone idea also from India, talking about how communication service is so essential. Pieces and definitely open shift. You know, big piece of this story asst to how they're working and managing and scaling. Um, you know, everybody talks about scale for years, but the current situation around the globe scale something that you know. It's definitely being stressed and strained and understood. What? What? What's really important? Um, another piece. Really interesting. Like to dig in a little bit here. Talk about open shift is you know, we talk kubernetes and we're talking container. But there's still a lot of virtualization out there. And then from an application development standpoint, there's You know what? Let's throw everything away and go all serverless on there. So I understand. Open shift. Io is embracing the full world and all of the options out there. So help us walk through how Red Hat maybe is doing things a little bit differently. And of course, we know anything right Does is based on open source. So let's talk about those pieces >>Yes, to super interesting areas for us. Um, one is the work we're doing based on open source project called Kube Vert, and that's part of the CN CF incubating projects. And that that is the notion off bringing virtualization into containers. And what does that mean? Obviously There are huge numbers of workloads running in which machines globally and more more customers want, you know, one control plane, one environment, one abstraction to manage workloads, whether they're running in containers or in IBM, I believe you sort of say, Can we take workloads that are running in these, uh, give, um, based which machines or, uh, VMS running in a VM based environment and then bring them natively on, run them as containers and managed by kubernetes orchestrate across this distributed cluster that we've talked about? I've been extremely powerful, and it's a very modern approach to modernizing existing applications as well as thinking about building new services. And so that's a technology that we're introducing into the platform and trying to see some early customer interest. Um, around. So, >>you know, I've got ah, no, I'm gonna have a breakout with Joe Fernandez toe talk about this a little bit, but you know what a note is you're working on. That is, you're bringing a VM into the container world and what red hat does Well, because you know your background and what red hat does is, you know, from an operating system you're really close to the application. So one of my concerns, you know, from early days of virtualization was well, let's shut things in a VM and leave it there and not make any changes as opposed to What you're describing is let's help modernize things. You know, I saw one of the announcements talking about How do I take job of workloads and bring them into the cloud? There's a project called Marcus. So once again, do I hear you right? You're bringing V M's into the container world with help to move towards that journey, to modernize everything so that we were doing a modern platform, not just saying, Hey, I can manage it with the tool that I was doing before. But that application, that's the important piece of it. >>Yeah, and it's a really good point, you know, We've you know, so much to govern, probably too little time to do it right, because the one that you touched on is really interesting. Project called caucuses right again. As you rightly pointed out, everything that is open source up, and so that's a way for us to say, Look, if we were to think about Java and be able to run that in a cloud native way, right? And be able to run, um, that natively within a container and be orchestrated again by kubernetes. What would that look like? Right, How much could be reduced density? How much could be improved performance around those existing job applications taking advantage off all the investments that companies have made but make that available in kubernetes and cloud native world. Right? And so that's what the corpus project is about. I'm seeing a lot of interest, you know, and again, because the open source model right, You don't really have companies that are adopting this, right? So there's I think there's a telecom company based out of Europe that's talking about the work that they're already doing with this. And I already blogged about it, talking about, you know, the value from a performance and use of usability perspective that they're getting with that. And then you got So you couple this idea off. How do I take BMC? Bring them into contempt? Right? Right. Existing workloads. Move that in. Run that native check. Right? Uh, the next one. How do I take existing java workloads and bring them into this modern cloud native Kubernetes space world, you know, making progress with that orchestra check. And then the third area is this notion off several lists, right? Which is, you know, I've got new applications, new services. I want to make sure that they're taking advantage, appropriate resources, but only the exact number of resources that require We do that in a way that's native to kubernetes. Right? So we're been working on implementing a K native based technologies as the foundation as the building blocks, um, off the work we're doing around serving and eventing towards leading. Ah, more confortable several institution, regardless of where you run it across any off your platform prints up. And that will also bring the ability to have functions that made available by really any provider in that same platform. So So if you haven't already to put all the pieces together right that we were thinking about this is the center of gravity is a community space platform that we make fully automated, that we make it very operational, make it easy for different. You know, third party pieces to plug in, writes to sort of make sure that it's in trouble in modular and at the same time that start layering on additional Kim. >>Yeah, I'm a lot of topics. As you said, it's Siachin. I'm glad on the serverless piece we're teasing out because it is complicated. You know, there are some that were just like, Well, from my application developer standpoint, I don't >>need to >>think about all that kubernetes and containers pieces because that's why I love it. Serverless. I just developed to it, and the platform takes care of it. And we would look at this year to go and say, Well, underneath that What is it? Is it containers? And the enter was Well, it could be containers. It depends what the platform is doing. So, you know, from from Red Hat's standpoint, you're saying open shift server lists, you know? Yes, it's kubernetes underneath there. But then I heard you talk about, you know, live aware of it is so, um, I saw there's, you know, a partner of Red Hat. It's in the open source community trigger mesh, which was entering one of the questions I had. You know, when I talk to people about serverless most of the time, it's AWS based stuff, not just lambda lots of other services. You know, I didn't interview with Andy Jassy a few years ago, and he said if I was to rebuild AWS today, everything would be built on serverless. So might some of those have containers and kubernetes under it? Maybe, but Amazon might do their own thing, so they're doing really a connection between that. So how does that plug in with what you're doing? Open shift out. All these various open sourced pieces go together. >>Yes, I would expect for us to have partnerships with several startups, right? You know you name, you know, one in our ecosystem. You know, you can imagine as your functions, you know, running on our serverless platform as well as functions provided by any third party, including those that are built and by red hat itself, Uh, you know, for the portal within this platform. Because ultimately, you know, we're building the platform to be operational, to be managed at scale to create greater productively for developments. Right? So for example, one of things we've been working on we are in the area of developer tools. Give the customers ability. Do you have you know, the product that we have is called cordon Ready workspaces. But essentially this notion off, you know, how can we take containers and give work spaces that are easy for remote developers to work with? Great example. Off customer, actually, in India that's been able to rapidly cut down time to go from Dev Productions weeks, you know, introduced because they're using, you know, things like these remote workspaces running in containers. You know, this is based on the eclipse. Ah, Apache, the the CI Project, You know, for this. So this this notion that you know, we're building a platform that can be used by ops teams? Absolutely true, but the same time the idea is, how can we now start thinking about making sure these abstractions are providing are extremely productive for development teams. >>Yeah, it's such an important piece. Last year I got the chance to go to Answerable Fest for the first time, and it was that kind of discussion that was really important, you know, can tools actually help me? Bridge between was traditionally some of those silos that they talked about, You know, the product developer that the Infrastructure and Ops team and the AB Dev teams all get things in their terminology and where they need but common platforms that cut between them. So sounds like similar methodology. We're seeing other piece of the platforms Any other, you know, guidance. You talked about all your customers there. How are they working through? You know, all of these modernizations adopting so many new technologies. Boy, you talked about like Dev ops tooling it still makes my heads. Then when I look at it, some of these charts is all the various tools and pieces that organizations are supposed to help choose and pick. Ah, out of there, they have. So how how is your team helping customers on kind of the organizational side? >>Yes. So we'll do this glass picture. So one is How do you make sure that the platform is working to help these teams? You know, by that? What I mean is, you know, we are introducing this idea and working very closely with our partners globally and on this notion of operators, right, which is every time I want to run data bases. And you know, there's so many different databases. There are, you know, up there, right? No sequel, no sequel. and in a variety of different ones for different use cases. How can you make sure that we make it easy for customers trial and then be able to to deploy them and manage them? Right? So this notion of an operator lifecycle because application much more manageable when they run with data s O. So you make you make it easier for folks to be able to use them. And then the question is, Well, what other? If you will advise to help me get that right So off late, you probably heard, you know, be hired a bunch of industry experts and brought them into red hat around this notion of a global transformation and be able to bring that expertise to know whether you know, it's the So you know, Our Deep in Dev Ops and the Dev Ops Handbook are you know, some of the things that industry is a lot like the Phoenix project and, you know, just just in various different you know what's your business and be able to start saying looking at these are told, music and share ideas with you on a couple that with things like open innovation labs that come from red hat as well as you know, similar kinds of offerings from our various partners around the world to help, you know, ease their transition into the >>All right. So final question I have for you, let's go a little bit high level. You know, as you've mentioned you and I have been having this conversation for a number of years last year or so, I've been hearing some of the really big players out there, ones that are, of course, partners of Red Hat. But they say similar things. So you know, whether it's, you know, Microsoft Azure releasing arc. If it's, you know, VM ware, which much of your open ship customers sit on top of it. But now they have, you know, the Project Pacific piece and and do so many of them talk about this, you know, heterogeneous, multi cloud environment. So how should customers be thinking about red hat? Of course. You partner with everyone, but you know, you do tend to do things a little bit different than everybody else. >>Uh, yeah. I hope we do things differently than everyone else. You know, to deliver value to customers, right? So, for example, all the things that we talk about open ship or really is about industry leading. And I think there's a bit of a transformation that's going on a swell right within the way. How Red Hat approaches things. So Sam customers have known Red Hat in the past in many ways for saying, Look, they're giving me an operating system that's, you know, democratizing, if you will. You know what the provider provides, Why I've been given me for all these years. They provided me an application server, right that, you know, uh, it's giving me a better value than what proprietary price. Increasingly, what we're doing with, you know, the work they're doing around, Let's say whether it's open shift or, you know, the next generation which ization that we talked about so on is about how can we help customers fundamentally transform how it is that they were building deploy applications, both in a new cloud native way. That's one of the existing once and what I really want to 0.2 is now. We've got it least a five year history on the open shift platform to look back at you will point out and say here are customers that are running directly on bare metal shears. Why they find, you know, this virtualization solution that you know that we're providing so interesting Here we have customers running in multiple different environments running on open stack running in these multiple private clouds are sorry public clouds on why they want distribute cluster management across all of them. You know, here's the examples that you know we could provide right? You know, here's the work we've done with, you know, whether it's these, you know, government agencies with private enterprises that we've talked to write, you know, receiving innovation awards for the world been doing together. And so I think our approach really has been more about, you know, we want to work on innovation that is fundamentally impacting customers, transforming them, meeting them where they are moving the four into the world we're going into. But they're also ensuring that we're taking advantage of all the existing investments that they've made in their skills. Right? So the advantage of, for example, the years off limits expertise that they have and saying How can we use that? Don't move you forward. >>Well, a chef's Thank you so much Absolutely. I know the customers I've talked to at Red Hat talking about not only how they're ready for today, but feel confident that they're ready to tackle the challenges of tomorrow. So thanks so much. Congratulations on all the progress and definitely look forward to seeing you again in the future. >>Likewise. Thanks, Ian Stewart. >>All right, I'm still Minuteman. And much more coverage from Red Hat Summit 2020 as always. Thanks for watching the Cube. >>Yeah, Yeah, yeah, yeah, yeah, yeah.

>> Sue: Hello everybody. Thank you for joining us today for the Virtual Vertica BDC 2020. Today's breakout session in entitled Extending Vertica with the Latest Vertica Ecosystem and Open Source Initiatives. My name is Sue LeClaire, Director of Marketing at Vertica and I'll be your host for this webinar. Joining me is Tom Wall, a member of the Vertica engineering team. But before we begin, I encourage you to submit questions or comments during the virtual session. You don't have to wait. Just type your question or comment in the question box below the slides and click submit. There will be a Q and A session at the end of the presentation. We'll answer as many questions as we're able to during that time. Any questions that we don't get to, we'll do our best to answer them offline. Alternatively, you can visit the Vertica forums to post you questions after the session. Our engineering team is planning to join the forums to keep the conversation going. Also a reminder that you can maximize your screen by clicking the double arrow button in the lower right corner of the slides. And yes, this virtual session is being recorded and will be available to view on demand later this week. We'll send you a notification as soon as it's ready. So let's get started. Tom, over to you. >> Tom: Hello everyone and thanks for joining us today for this talk. My name is Tom Wall and I am the leader of Vertica's ecosystem engineering team. We are the team that focuses on building out all the developer tools, third party integrations that enables the SoftMaker system that surrounds Vertica to thrive. So today, we'll be talking about some of our new open source initatives and how those can be really effective for you and make things easier for you to build and integrate Vertica with the rest of your technology stack. We've got several new libraries, integration projects and examples, all open source, to share, all being built out in the open on our GitHub page. Whether you use these open source projects or not, this is a very exciting new effort that will really help to grow the developer community and enable lots of exciting new use cases. So, every developer out there has probably had to deal with the problem like this. You have some business requirements, to maybe build some new Vertica-powered application. Maybe you have to build some new system to visualize some data that's that's managed by Vertica. The various circumstances, lots of choices will might be made for you that constrain your approach to solving a particular problem. These requirements can come from all different places. Maybe your solution has to work with a specific visualization tool, or web framework, because the business has already invested in the licensing and the tooling to use it. Maybe it has to be implemented in a specific programming language, since that's what all the developers on the team know how to write code with. While Vertica has many different integrations with lots of different programming language and systems, there's a lot of them out there, and we don't have integrations for all of them. So how do you make ends meet when you don't have all the tools you need? All you have to get creative, using tools like PyODBC, for example, to bridge between programming languages and frameworks to solve the problems you need to solve. Most languages do have an ODBC-based database interface. ODBC is our C-Library and most programming languages know how to call C code, somehow. So that's doable, but it often requires lots of configuration and troubleshooting to make all those moving parts work well together. So that's enough to get the job done but native integrations are usually a lot smoother and easier. So rather than, for example, in Python trying to fight with PyODBC, to configure things and get Unicode working, and to compile all the different pieces, the right way is to make it all work smoothly. It would be much better if you could just PIP install library and get to work. And with Vertica-Python, a new Python client library, you can actually do that. So that story, I assume, probably sounds pretty familiar to you. Sounds probably familiar to a lot of the audience here because we're all using Vertica. And our challenge, as Big Data practitioners is to make sense of all this stuff, despite those technical and non-technical hurdles. Vertica powers lots of different businesses and use cases across all kinds of different industries and verticals. While there's a lot different about us, we're all here together right now for this talk because we do have some things in common. We're all using Vertica, and we're probably also using Vertica with other systems and tools too, because it's important to use the right tool for the right job. That's a founding principle of Vertica and it's true today too. In this constantly changing technology landscape, we need lots of good tools and well established patterns, approaches, and advice on how to combine them so that we can be successful doing our jobs. Luckily for us, Vertica has been designed to be easy to build with and extended in this fashion. Databases as a whole had had this goal from the very beginning. They solve the hard problems of managing data so that you don't have to worry about it. Instead of worrying about those hard problems, you can focus on what matters most to you and your domain. So implementing that business logic, solving that problem, without having to worry about all of these intense, sometimes details about what it takes to manage a database at scale. With the declarative syntax of SQL, you tell Vertica what the answer is that you want. You don't tell Vertica how to get it. Vertica will figure out the right way to do it for you so that you don't have to worry about it. So this SQL abstraction is very nice because it's a well defined boundary where lots of developers know SQL, and it allows you to express what you need without having to worry about those details. So we can be the experts in data management while you worry about your problems. This goes beyond though, what's accessible through SQL to Vertica. We've got well defined extension and integration points across the product that allow you to customize this experience even further. So if you want to do things write your own SQL functions, or extend database softwares with UDXs, you can do so. If you have a custom data format that might be a proprietary format, or some source system that Vertica doesn't natively support, we have extension points that allow you to use those. To make it very easy to do passive, parallel, massive data movement, loading into Vertica but also to export Vertica to send data to other systems. And with these new features in time, we also could do the same kinds of things with Machine Learning models, importing and exporting to tools like TensorFlow. And it's these integration points that have enabled Vertica to build out this open architecture and a rich ecosystem of tools, both open source and closed source, of different varieties that solve all different problems that are common in this big data processing world. Whether it's open source, streaming systems like Kafka or Spark, or more traditional ETL tools on the loading side, but also, BI tools and visualizers and things like that to view and use the data that you keep in your database on the right side. And then of course, Vertica needs to be flexible enough to be able to run anywhere. So you can really take Vertica and use it the way you want it to solve the problems that you need to solve. So Vertica has always employed open standards, and integrated it with all kinds of different open source systems. What we're really excited to talk about now is that we are taking our new integration projects and making those open source too. In particular, we've got two new open source client libraries that allow you to build Vertica applications for Python and Go. These libraries act as a foundation for all kinds of interesting applications and tools. Upon those libraries, we've also built some integrations ourselves. And we're using these new libraries to power some new integrations with some third party products. Finally, we've got lots of new examples and reference implementations out on our GitHub page that can show you how to combine all these moving parts and exciting ways to solve new problems. And the code for all these things is available now on our GitHub page. And so you can use it however you like, and even help us make it better too. So the first such project that we have is called Vertica-Python. Vertica-Python began at our customer, Uber. And then in late 2018, we collaborated with them and we took it over and made Vertica-Python the first official open source client for Vertica You can use this to build your own Python applications, or you can use it via tools that were written in Python. Python has grown a lot in recent years and it's very common language to solve lots of different problems and use cases in the Big Data space from things like DevOps admission and Data Science or Machine Learning, or just homegrown applications. We use Python a lot internally for our own QA testing and automation needs. And with the Python 2 End Of Life, that happened at the end of 2019, it was important that we had a robust Python solution to help migrate our internal stuff off of Python 2. And also to provide a nice migration path for all of you our users that might be worried about the same problems with their own Python code. So Vertica-Python is used already for lots of different tools, including Vertica's admintools now starting with 9.3.1. It was also used by DataDog to build a Vertica-DataDog integration that allows you to monitor your Vertica infrastructure within DataDog. So here's a little example of how you might use the Python Client to do some some work. So here we open in connection, we run a query to find out what node we've connected to, and then we do a little DataLoad by running a COPY statement. And this is designed to have a familiar look and feel if you've ever used a Python Database Client before. So we implement the DB API 2.0 standard and it feels like a Python package. So that includes things like, it's part of the centralized package manager, so you can just PIP install this right now and go start using it. We also have our client for Go length. So this is called vertica-sql-go. And this is a very similar story, just in a different context or the different programming language. So vertica-sql-go, began as a collaboration with the Microsoft Focus SecOps Group who builds microfocus' security products some of which use vertica internally to provide some of those analytics. So you can use this to build your own apps in the Go programming language but you can also use it via tools that are written Go. So most notably, we have our Grafana integration, which we'll talk a little bit more about later, that leverages this new clients to provide Grafana visualizations for vertica data. And Go is another rising popularity programming language 'cause it offers an interesting balance of different programming design trade-offs. So it's got good performance, got a good current concurrency and memory safety. And we liked all those things and we're using it to power some internal monitoring stuff of our own. And here's an example of the code you can write with this client. So this is Go code that does a similar thing. It opens a connection, it runs a little test query, and then it iterates over those rows, processing them using Go data types. You get that native look and feel just like you do in Python, except this time in the Go language. And you can go get it the way you usually package things with Go by running that command there to acquire this package. And it's important to note here for the DC projects, we're really doing open source development. We're not just putting code out on our GitHub page. So if you go out there and look, you can see that you can ask questions, you can report bugs, you can submit poll requests yourselves and you can collaborate directly with our engineering team and the other vertica users out on our GitHub page. Because it's out on our GitHub page, it allows us to be a little bit faster with the way we ship and deliver functionality compared to the core vertica release cycle. So in 2019, for example, as we were building features to prepare for the Python 3 migration, we shipped 11 different releases with 40 customer reported issues, filed on GitHub. That was done over 78 different poll requests and with lots of community engagement as we do so. So lots of people are using this already, we see as our GitHub badge last showed with about 5000 downloads of this a day of people using it in their software. And again, we want to make this easy, not just to use but also to contribute and understand and collaborate with us. So all these projects are built using the Apache 2.0 license. The master branch is always available and stable with the latest creative functionality. And you can always build it and test it the way we do so that it's easy for you to understand how it works and to submit contributions or bug fixes or even features. It uses automated testing both for locally and with poll requests. And for vertica-python, it's fully automated with Travis CI. So we're really excited about doing this and we're really excited about where it can go in the future. 'Cause this offers some exciting opportunities for us to collaborate with you more directly than we have ever before. You can contribute improvements and help us guide the direction of these projects, but you can also work with each other to share knowledge and implementation details and various best practices. And so maybe you think, "Well, I don't use Python, "I don't use go so maybe it doesn't matter to me." But I would argue it really does matter. Because even if you don't use these tools and languages, there's lots of amazing vertica developers out there who do. And these clients do act as low level building blocks for all kinds of different interesting tools, both in these Python and Go worlds, but also well beyond that. Because these implementations and examples really generalize to lots of different use cases. And we're going to do a deeper dive now into some of these to understand exactly how that's the case and what you can do with these things. So let's take a deeper look at some of the details of what it takes to build one of these open source client libraries. So these database client interfaces, what are they exactly? Well, we all know SQL, but if you look at what SQL specifies, it really only talks about how to manipulate the data within the database. So once you're connected and in, you can run commands with SQL. But these database client interfaces address the rest of those needs. So what does the programmer need to do to actually process those SQL queries? So these interfaces are specific to a particular language or a technology stack. But the use cases and the architectures and design patterns are largely the same between different languages. They all have a need to do some networking and connect and authenticate and create a session. They all need to be able to run queries and load some data and deal with problems and errors. And then they also have a lot of metadata and Type Mapping because you want to use these clients the way you use those programming languages. Which might be different than the way that vertica's data types and vertica's semantics work. So some of this client interfaces are truly standards. And they are robust enough in terms of what they design and call for to support a truly pluggable driver model. Where you might write an application that codes directly against the standard interface, and you can then plug in a different database driver, like a JDBC driver, to have that application work with any database that has a JDBC driver. So most of these interfaces aren't as robust as a JDBC or ODBC but that's okay. 'Cause it's good as a standard is, every database is unique for a reason. And so you can't really expose all of those unique properties of a database through these standard interfaces. So vertica's unique in that it can scale to the petabytes and beyond. And you can run it anywhere in any environment, whether it's on-prem or on clouds. So surely there's something about vertica that's unique, and we want to be able to take advantage of that fact in our solutions. So even though these standards might not cover everything, there's often a need and common patterns that arise to solve these problems in similar ways. When there isn't enough of a standard to define those comments, semantics that different databases might have in common, what you often see is tools will invent plug in layers or glue code to compensate by defining application wide standard to cover some of these same semantics. Later on, we'll get into some of those details and show off what exactly that means. So if you connect to a vertica database, what's actually happening under the covers? You have an application, you have a need to run some queries, so what does that actually look like? Well, probably as you would imagine, your application is going to invoke some API calls and some client library or tool. This library takes those API calls and implements them, usually by issuing some networking protocol operations, communicating over the network to ask vertica to do the heavy lifting required for that particular API call. And so these API's usually do the same kinds of things although some of the details might differ between these different interfaces. But you do things like establish a connection, run a query, iterate over your rows, manage your transactions, that sort of thing. Here's an example from vertica-python, which just goes into some of the details of what actually happens during the Connect API call. And you can see all these details in our GitHub implementation of this. There's actually a lot of moving parts in what happens during a connection. So let's walk through some of that and see what actually goes on. I might have my API call like this where I say Connect and I give it a DNS name, which is my entire cluster. And I give you my connection details, my username and password. And I tell the Python Client to get me a session, give me a connection so I can start doing some work. Well, in order to implement this, what needs to happen? First, we need to do some TCP networking to establish our connection. So we need to understand what the request is, where you're going to connect to and why, by pressing the connection string. and vertica being a distributed system, we want to provide high availability, so we might need to do some DNS look-ups to resolve that DNS name which might be an entire cluster and not just a single machine. So that you don't have to change your connection string every time you add or remove nodes to the database. So we do some high availability and DNS lookup stuff. And then once we connect, we might do Load Balancing too, to balance the connections across the different initiator nodes in the cluster, or in a sub cluster, as needed. Once we land on the node we want to be at, we might do some TLS to secure our connections. And vertica supports the industry standard TLS protocols, so this looks pretty familiar for everyone who've used TLS anywhere before. So you're going to do a certificate exchange and the client might send the server certificate too, and then you going to verify that the server is who it says it is, so that you can know that you trust it. Once you've established that connection, and secured it, then you can start actually beginning to request a session within vertica. So you going to send over your user information like, "Here's my username, "here's the database I want to connect to." You might send some information about your application like a session label, so that you can differentiate on the database with monitoring queries, what the different connections are and what their purpose is. And then you might also send over some session settings to do things like auto commit, to change the state of your session for the duration of this connection. So that you don't have to remember to do that with every query that you have. Once you've asked vertica for a session, before vertica will give you one, it has to authenticate you. and vertica has lots of different authentication mechanisms. So there's a negotiation that happens there to decide how to authenticate you. Vertica decides based on who you are, where you're coming from on the network. And then you'll do an auth-specific exchange depending on what the auth mechanism calls for until you are authenticated. Finally, vertica trusts you and lets you in, so you going to establish a session in vertica, and you might do some note keeping on the client side just to know what happened. So you might log some information, you might record what the version of the database is, you might do some protocol feature negotiation. So if you connect to a version of the database that doesn't support all these protocols, you might decide to turn some functionality off and that sort of thing. But finally, after all that, you can return from this API call and then your connection is good to go. So that connection is just one example of many different APIs. And we're excited here because with vertica-python we're really opening up the vertica client wire protocol for the first time. And so if you're a low level vertica developer and you might have used Postgres before, you might know that some of vertica's client protocol is derived from Postgres. But they do differ in many significant ways. And this is the first time we've ever revealed those details about how it works and why. So not all Postgres protocol features work with vertica because vertica doesn't support all the features that Postgres does. Postgres, for example, has a large object interface that allows you to stream very wide data values over. Whereas vertica doesn't really have very wide data values, you have 30, you have long bar charts, but that's about as wide as you can get. Similarly, the vertica protocol supports lots of features not present in Postgres. So Load Balancing, for example, which we just went through an example of, Postgres is a single node system, it doesn't really make sense for Postgres to have Load Balancing. But Load Balancing is really important for vertica because it is a distributed system. Vertica-python serves as an open reference implementation of this protocol. With all kinds of new details and extension points that we haven't revealed before. So if you look at these boxes below, all these different things are new protocol features that we've implemented since August 2019, out in the open on our GitHub page for Python. Now, the vertica-sql-go implementation of these things is still in progress, but the core protocols are there for basic query operations. There's more to do there but we'll get there soon. So this is really cool 'cause not only do you have now a Python Client implementation, and you have a Go client implementation of this, but you can use this protocol reference to do lots of other things, too. The obvious thing you could do is build more clients for other languages. So if you have a need for a client in some other language that are vertica doesn't support yet, now you have everything available to solve that problem and to go about doing so if you need to. But beyond clients, it's also used for other things. So you might use it for mocking and testing things. So rather than connecting to a real vertica database, you can simulate some of that. You can also use it to do things like query routing and proxies. So Uber, for example, this log here in this link tells a great story of how they route different queries to different vertical clusters by intercepting these protocol messages, parsing the queries in them and deciding which clusters to send them to. So a lot of these things are just ideas today, but now that you have the source code, there's no limit in sight to what you can do with this thing. And so we're very interested in hearing your ideas and requests and we're happy to offer advice and collaborate on building some of these things together. So let's take a look now at some of the things we've already built that do these things. So here's a picture of vertica's Grafana connector with some data powered from an example that we have in this blog link here. So this has an internet of things use case to it, where we have lots of different sensors recording flight data, feeding into Kafka which then gets loaded into vertica. And then finally, it gets visualized nicely here with Grafana. And Grafana's visualizations make it really easy to analyze the data with your eyes and see when something something happens. So in these highlighted sections here, you notice a drop in some of the activity, that's probably a problem worth looking into. It might be a lot harder to see that just by staring at a large table yourself. So how does a picture like that get generated with a tool like Grafana? Well, Grafana specializes in visualizing time series data. And time can be really tricky for computers to do correctly. You got time zones, daylight savings, leap seconds, negative infinity timestamps, please don't ever use those. In every system, if it wasn't hard enough, just with those problems, what makes it harder is that every system does it slightly differently. So if you're querying some time data, how do we deal with these semantic differences as we cross these domain boundaries from Vertica to Grafana's back end architecture, which is implemented in Go on it's front end, which is implemented with JavaScript? Well, you read this from bottom up in terms of the processing. First, you select the timestamp and Vertica is timestamp has to be converted to a Go time object. And we have to reconcile the differences that there might be as we translate it. So Go time has a different time zone specifier format, and it also supports nanosecond precision, while Vertica only supports microsecond precision. So that's not too big of a deal when you're querying data because you just see some extra zeros, not fractional seconds. But on the way in, if we're loading data, we have to find a way to resolve those things. Once it's into the Go process, it has to be converted further to render in the JavaScript UI. So that there, the Go time object has to be converted to a JavaScript Angular JS Date object. And there too, we have to reconcile those differences. So a lot of these differences might just be presentation, and not so much the actual data changing, but you might want to choose to render the date into a more human readable format, like we've done in this example here. Here's another picture. This is another picture of some time series data, and this one shows you can actually write your own queries with Grafana to provide answers. So if you look closely here you can see there's actually some functions that might not look too familiar with you if you know vertica's functions. Vertica doesn't have a dollar underscore underscore time function or a time filter function. So what's actually happening there? How does this actually provide an answer if it's not really real vertica syntax? Well, it's not sufficient to just know how to manipulate data, it's also really important that you know how to operate with metadata. So information about how the data works in the data source, Vertica in this case. So Grafana needs to know how time works in detail for each data source beyond doing that basic I/O that we just saw in the previous example. So it needs to know, how do you connect to the data source to get some time data? How do you know what time data types and functions there are and how they behave? How do you generate a query that references a time literal? And finally, once you've figured out how to do all that, how do you find the time in the database? How do you do know which tables have time columns and then they might be worth rendering in this kind of UI. So Go's database standard doesn't actually really offer many metadata interfaces. Nevertheless, Grafana needs to know those answers. And so it has its own plugin layer that provides a standardizing layer whereby every data source can implement hints and metadata customization needed to have an extensible data source back end. So we have another open source project, the Vertica-Grafana data source, which is a plugin that uses Grafana's extension points with JavaScript and the front end plugins and also with Go in the back end plugins to provide vertica connectivity inside Grafana. So the way this works, is that the plugin frameworks defines those standardizing functions like time and time filter, and it's our plugin that's going to rewrite them in terms of vertica syntax. So in this example, time gets rewritten to a vertica cast. And time filter becomes a BETWEEN predicate. So that's one example of how you can use Grafana, but also how you might build any arbitrary visualization tool that works with data in Vertica. So let's now look at some other examples and reference architectures that we have out in our GitHub page. For some advanced integrations, there's clearly a need to go beyond these standards. So SQL and these surrounding standards, like JDBC, and ODBC, were really critical in the early days of Vertica, because they really enabled a lot of generic database tools. And those will always continue to play a really important role, but the Big Data technology space moves a lot faster than these old database data can keep up with. So there's all kinds of new advanced analytics and query pushdown logic that were never possible 10 or 20 years ago, that Vertica can do natively. There's also all kinds of data-oriented application workflows doing things like streaming data, or Parallel Loading or Machine Learning. And all of these things, we need to build software with, but we don't really have standards to go by. So what do we do there? Well, open source implementations make for easier integrations, and applications all over the place. So even if you're not using Grafana for example, other tools have similar challenges that you need to overcome. And it helps to have an example there to show you how to do it. Take Machine Learning, for example. There's been many excellent Machine Learning tools that have arisen over the years to make data science and the task of Machine Learning lot easier. And a lot of those have basic database connectivity, but they generally only treat the database as a source of data. So they do lots of data I/O to extract data from a database like Vertica for processing in some other engine. We all know that's not the most efficient way to do it. It's much better if you can leverage Vertica scale and bring the processing to the data. So a lot of these tools don't take full advantage of Vertica because there's not really a uniform way to go do so with these standards. So instead, we have a project called vertica-ml-python. And this serves as a reference architecture of how you can do scalable machine learning with Vertica. So this project establishes a familiar machine learning workflow that scales with vertica. So it feels similar to like a scickit-learn project except all the processing and aggregation and heavy lifting and data processing happens in vertica. So this makes for a much more lightweight, scalable approach than you might otherwise be used to. So with vertica-ml-python, you can probably use this yourself. But you could also see how it works. So if it doesn't meet all your needs, you could still see the code and customize it to build your own approach. We've also got lots of examples of our UDX framework. And so this is an older GitHub project. We've actually had this for a couple of years, but it is really useful and important so I wanted to plug it here. With our User Defined eXtensions framework or UDXs, this allows you to extend the operators that vertica executes when it does a database load or a database query. So with UDXs, you can write your own domain logic in a C++, Java or Python or R. And you can call them within the context of a SQL query. And vertica brings your logic to that data, and makes it fast and scalable and fault tolerant and correct for you. So you don't have to worry about all those hard problems. So our UDX examples, demonstrate how you can use our SDK to solve interesting problems. And some of these examples might be complete, total usable packages or libraries. So for example, we have a curl source that allows you to extract data from any curlable endpoint and load into vertica. We've got things like an ODBC connector that allows you to access data in an external database via an ODBC driver within the context of a vertica query, all kinds of parsers and string processors and things like that. We also have more exciting and interesting things where you might not really think of vertica being able to do that, like a heat map generator, which takes some XY coordinates and renders it on top of an image to show you the hotspots in it. So the image on the right was actually generated from one of our intern gaming sessions a few years back. So all these things are great examples that show you not just how you can solve problems, but also how you can use this SDK to solve neat things that maybe no one else has to solve, or maybe that are unique to your business and your needs. Another exciting benefit is with testing. So the test automation strategy that we have in vertica-python these clients, really generalizes well beyond the needs of a database client. Anyone that's ever built a vertica integration or an application, probably has a need to write some integration tests. And that could be hard to do with all the moving parts, in the big data solution. But with our code being open source, you can see in vertica-python, in particular, how we've structured our tests to facilitate smooth testing that's fast, deterministic and easy to use. So we've automated the download process, the installation deployment process, of a Vertica Community Edition. And with a single click, you can run through the tests locally and part of the PR workflow via Travis CI. We also do this for multiple different python environments. So for all python versions from 2.7 up to 3.8 for different Python interpreters, and for different Linux distros, we're running through all of them very quickly with ease, thanks to all this automation. So today, you can see how we do it in vertica-python, in the future, we might want to spin that out into its own stand-alone testbed starter projects so that if you're starting any new vertica integration, this might be a good starting point for you to get going quickly. So that brings us to some of the future work we want to do here in the open source space . Well, there's a lot of it. So in terms of the the client stuff, for Python, we are marching towards our 1.0 release, which is when we aim to be protocol complete to support all of vertica's unique protocols, including COPY LOCAL and some new protocols invented to support complex types, which is our new feature in vertica 10. We have some cursor enhancements to do things like better streaming and improved performance. Beyond that we want to take it where you want to bring it. So send us your requests in the Go client fronts, just about a year behind Python in terms of its protocol implementation, but the basic operations are there. But we still have more work to do to implement things like load balancing, some of the advanced auths and other things. But they're two, we want to work with you and we want to focus on what's important to you so that we can continue to grow and be more useful and more powerful over time. Finally, this question of, "Well, what about beyond database clients? "What else might we want to do with open source?" If you're building a very deep or a robust vertica integration, you probably need to do a lot more exciting things than just run SQL queries and process the answers. Especially if you're an OEM or you're a vendor that resells vertica packaged as a black box piece of a larger solution, you might to have managed the whole operational lifecycle of vertica. There's even fewer standards for doing all these different things compared to the SQL clients. So we started with the SQL clients 'cause that's a well established pattern, there's lots of downstream work that that can enable. But there's also clearly a need for lots of other open source protocols, architectures and examples to show you how to do these things and do have real standards. So we talked a little bit about how you could do UDXs or testing or Machine Learning, but there's all sorts of other use cases too. That's why we're excited to announce here our awesome vertica, which is a new collection of open source resources available on our GitHub page. So if you haven't heard of this awesome manifesto before, I highly recommend you check out this GitHub page on the right. We're not unique here but there's lots of awesome projects for all kinds of different tools and systems out there. And it's a great way to establish a community and share different resources, whether they're open source projects, blogs, examples, references, community resources, and all that. And this tool is an open source project. So it's an open source wiki. And you can contribute to it by submitting yourself to PR. So we've seeded it with some of our favorite tools and projects out there but there's plenty more out there and we hope to see more grow over time. So definitely check this out and help us make it better. So with that, I'm going to wrap up. I wanted to thank you all. Special thanks to Siting Ren and Roger Huebner, who are the project leads for the Python and Go clients respectively. And also, thanks to all the customers out there who've already been contributing stuff. This has already been going on for a long time and we hope to keep it going and keep it growing with your help. So if you want to talk to us, you can find us at this email address here. But of course, you can also find us on the Vertica forums, or you could talk to us on GitHub too. And there you can find links to all the different projects I talked about today. And so with that, I think we're going to wrap up and now we're going to hand it off for some Q&A.

>> Announcer: Live from San Francisco, celebrating ten years of high-tech coverage, it's theCUBE! Covering VMworld, 2019. Brought to you by VMware and its ecosystem partners. >> Kay welcome back everyone, live CUBE coverage here at VMworld 2019 in San Francisco, we're in Moscone North lobby, I'm John Furrier. My cohost Stu Miniman. We're here with two great guests, David Appel, Vice President C2 Space and Intelligence and Defense, Civil Solutions at Raytheon, and Gil Shneorson, who's the senior vice president general manager of VxRail, of Dell EMC, great to have Raytheon, anything with space Stu and I get jacked up for that. Thanks for coming on. >> Yeah I appreciate it, thank you, I'm glad to be here. >> Gil, VxRail, got a customer here, impressive role out. Talk about the story. >> Well I think it starts with the fact that we have recently announced our support for Pivotal community services over VMware Cloud Foundation over VxRail which has actually the only Q-rated automated stacking industry that allows people to leverage containers and infrastructure as a service on one stack and we've been doing this for about three years now in a different way called Pivotal Ready Architecture and Raytheon has actually adopted that architecture to help their customer, the air force. And that's why we're here today together to talk about you know. >> Seriously modernization couldn't be a more important conversation in government solutions, you guys are a big provider, Raytheon, known for the tech chops, known for having good engineering. Talk about the solution, what you guys did, what's the use case, talk about the deployment. >> Yes with what's going on with the federal government for a while is the acquisition processes and what's taking sometimes years or decades to get software in the field is causing a lot of unmet requirements and needs of the ultimate user, the war fighters out in the field, to be met. So we've been on a journey for the last two years with Pivotal and Dell of how to help the air force, modernize the air force has gone under a transformation and a program called Kessel Run which is where we've deployed the Pivotal Ready Architecture to allow us to quickly deploy an infrastructure and allow us to focus on the end users and develop the capabilities that they need worldwide. And what took years and to now months and days so it's been a fantastic journey. >> Tell us what that means for the folks that might not know the pace of the procurement process. I mean some of this stuff is like 1995 procurement rules. I mean modernization these days is such an important part of it because the impact is significantly relevant. Share some color into the process. >> If you think about in the commercial world today where hundreds of applications be deployed overnight and updates on the what, hourly basis. In the government space it can literally take years to define a requirement, then you have to go through a budgeting cycle all the way up through congress and then you have to go through an acquisition cycle that could take a year to complete and so by the time you're actually fielding capability it is literally five years or more by the time the need was actually identified. And in that five years the technology probably changed which means your solution has probably changed from what's currently available. So shortening the cycles is what it's all about. >> And that's really about having the right product at the right time, not the old product five years ago. How fast things change, it's pretty important to have that nailed down. >> It's pretty amazing and you know I think you look at transformation and there's usually a trade off. What we have been working on and what we're announcing but really what we've been leaving over the last four years is a way to transform but stay close to your core. In other words transformation without trade offs. And so if you can get your VMware stack now running containers in a fully managed automated stack you don't have to change your skill set and you can do all of that and start innovating while staying very close to your core competency. You know you transform but you don't have to go too far and I think the story what Raytheon did is fairly amazing because they turned, you know, what did you tell me, a 50-year-old process, you know in like in less than half a year you turned automated systems that you know saves the US air force a lot of money. >> And lives too, are saved. I mean you're talking about people in the field, this is about people's lives too, I mean this is the money making. >> And it's been about transforming the culture of the way the DoD does software and the first example that Gil is mentioning was tanker planning which was the ability for the air force to refuel flight missions in the air, would typically take over eight hours to plan. And it was done by a white board. It was done manually. And in order to automate that and shrink the time, again that would have gone to that five year procurement cycle. We were able to deploy new applications using the Pivotal-ready architecture within 150 days and get those out worldwide to the field. That's done two things. It's from a financial perspective it's saving over $200,000 a day in just fuel costs from optimizing the tanker planning. But more importantly it's actually more efficient and protecting the safety of those flight crews. They're not in the air as long, they might not be in a hostile environment as long, so the security of the air force is even more important. >> As Pivotal always says they're outcome driven and that's pretty good outcome. I mean talk about the impact that you've had on everyone else around you because I'm sure there's some blockers in your way, people's feathers got ruffled, but then people see success they want to come copy it, right? So that's a pattern you see in a lot of government work. Hey there's a new way to do it, modern way. >> Yeah so our hindsight we're seeing it in two ways. One from a broader DoD perspective. The air force was out front here. They established this and from a DoD perspective what they're calling their Kessel Run initiative is really taking off. You're seeing other Kessel Run like programs being stood up like a program called Kobayashi Maru and Rogue Blue and a few others across DoD. So it's proliferating out across the DoD from a customer perspective, DoD customer perspective. From an industry perspective you know our competitors are quickly trying to catch up to us and they're trying to, you know, copy our playbook but we're continuing to innovate and continue on this journey so we're moving ahead with Pivotal and Dell. >> First of all David I think Pat Gelsinger must have been talking to your team because you're mashing up Star Wars and Star Trek with Kessel Run and Kobayashi there. But talk about mashing up, the stack that you're putting together, VxRail was really built around simplicity. It delivers that, that's what hyperconverged infrastructure does. You start talking about VCF and containers and PKS on that, Kubernetes nobody says is simple, but you know help us walk through, you know, how simple is it for you to leverage and deploy this. You've got organizational challenges and other things, so, you know, where is the solution, it sounds like you use the ready node, and where directionally is it headed? >> Yeah let me answer from this perspective. So we started this journey with Pivotal and the air force about two years ago. And at that time we started with a group of probably a dozen or less folks that actually even understood the technology or the products and the solutions that Dell and Pivotal bring forward. In those two years we're now up to over 100 people. Fully embracing the technology. It's creating an environment where it's easier for us to recruit and retain people because it's modern, it's not the old ways we used to do business. And we're finding that it's been very easy to deploy, very easy to train people up and very easy to operate. So from that perspective it's just been fantastic from not just the technology perspective but also the cultural transformation perspective. >> Yeah Gil I'd love you to comment on that because you know remember gosh when CI and HCI first rolled out you know the people that had those jobs were worried we were going to take their jobs away. Now when I hear your customer talking about, you know, it's easy to train them and even easier for me to recruit and retain, a powerful story. Are you hearing that across your customer base? >> Yeah I'll tell you what's a little different. In the past we have simplified things and we've made work somewhat go away but there was no alternative work. Today every developer, every IT person, they can't wait to go and be a dev ops person, right? So for IT when we come in and we say we're going to take this off your plate so you can free up your time, it really means something now, 'cause they know exactly what they want to do. They want to go and they want to be dev ops, they want to develop new apps, they want to move forward. And so it's very syngergistic in a way that we offload some of the burden from them and they actually do free up to do cooler stuff and then they like it. >> And they get to keep their traditional apps, with containers, gives them great capabilities. Not the throwaway. >> And that's a great point I think as I said before and it's really important to convey this, the transformation without trade offs is a big deal because they can keep the application. They can run the same environment. Right in our case they can do it you know at ease and in remote locations all over the world with less management. And at the same time they can innovate and manage those environments. And I think as long as we can keep that up we'll make a lot of people productive. >> Well I got to ask David the security question because one of the things that comes up all the time obviously Department of Defense, security's top of mind. Industrial IOT are now not just malware getting in for credit card information, you're talking about actual equipment, you're talking about flights in the air, hacking with physical things is a concern and it's a big IOT kind of conversation. You're in the middle of that, this is your world. What's your thoughts on the security? >> You know so we've obviously had to go through that in order to get authority to operate to push things into theater and one of the strongest benefits we've seen is the dev ops process and the platforms has all that security built in and all the testing as we're going through it. So the thousands of tests that are running as new threats are identified, the platform is updating with the latest patches or whatever it may be, so. >> John: On the automation stuff? >> On the automation side of it. So we're actually seeing a lot of the security, I don't want to call it risks go away, but our ability to mitigate them is being built into the software itself. So we haven't seen an issue yet where we haven't been able to get things authority to operate and push it out to the field, so. >> There's a high bar there too, obviously. >> It's a very high bar, very high bar, and that was part of the also the challenge of getting systems fielded in months and days versus years because of the ability to get that operations. >> Now this is a really big story I think. First of all Raytheon's a well-known brand, but, the modernization of getting stuff into theater and or into your production theater, military operations, that's a big deal, I mean, I think people don't really understand that aren't in government how fast this happens. I think that's a real testament to the solution, so I mean. >> Well the powerful thing to it is the national defense strategy is all about capability at the speed of relevance, and that's all about technology. Future wars aren't going to be decided by the size of your army or the size of your arsenal. It's going to be about how do you get data to decision makers faster and how do they can act faster. And that's where software and this infrastructure we're putting in place and putting capabilities in the hands of people that need it faster. That's what it's all about. >> And you know Secretary Matthis who was former Secretary of Defense said 48% of all the casualties are usually frontline war fighters. And that's where the technology edges so to speak. So again this is such a cutting edge topic, talk about it for days. How do you feel about this? This is pretty exciting. >> I'm just happy that every time I come into theCUBE, this is the second time I do it with a customer, you give me the opportunity to learn, you know, have a deeper relationship with one of my of probably now 7,000 customers. Which you know is really hard to keep up with these days and so you know we make technologies for people to use and when you see it in the field doing good it's a great thing. >> Well it's a transformation story. It's really a great transformation story. They have to, making a difference. >> Great, David, would love to hear, you know, what's on your ask for your partners that are deploying. Kind of give us a look forward roadmap that you can share. >> Yeah again I go back to everything we're about right now is speed and and getting capability faster. Currently in our marketplace right now we're fully embracing agile dev ops and everything it takes to deploy software from that perspective. Moving into things like artificial intelligence and machine learning and autonomy are the big things that are on our horizon from a technology perspective. And as our partners are in those areas and can help us bring more capability in that, that's going to help our end customer, the DoD, faster as well, so. >> What's the big takeaway from VMworld this year for you guys? What's the big observation? >> I'll be honest this is my first time at VMware. I'm amazed, I was at Dell Technology World a few months ago, I've really enjoyed it, I think it's a great event. And I'm just enjoying learning all the technologies so, it's, I've enjoyed the day. >> Gil what's your big takeaway? >> Well I'm part of the family. So I'm a little more familiar and even for me-- >> Whoever: You were briefed. >> No, no, even for me the rate of innovation that Vmworld puts out there is amazing. Right and you see how everything plugs together and you see how the vision keeps being, you know, completed, right, and we're in a good spot in the sense that we actually have what people need right now. And we do it better than everybody else. And you'd think that being number one in almost every category you'd be sitting there complacent and no, you know, we keep pushing the envelope, doing more innovating, more integrating more, so it's very exciting to see what's happening. >> Well great story here, Raytheon congratulations for your success I think it's super important to have a prepared military, certaintly, and saving lives and doing it in a modern way is kind of of a miracle these days in government, so congratulations. >> And I thank our partners for continuing to innovate 'cause that's helping us so. >> All right, great story, CUBE coverage here, Vmworld 2019, I'm John Furrier with Stu Miniman. We'll be back with more after this short break. (upbeat electronic music)

>> Announcer: Live from San Diego, California, it's theCUBE covering Cisco Live U.S. 2019. Brought to you by Cisco and its ecosystem partners. >> Welcome back to Cisco Live 2019 in San Diego everybody. You're watching theCUBE, the leader in live tech coverage and my name is Dave Vellante and I'm with my co-host Stu Miniman and Lisa Martin is also in the house. This is day three of our coverage, Danny Allan is here. He's the Vice President of Product Strategy at Veeam and one of the key thought leaders at the company, one of the main figures at VeeamON, which we were just doing three weeks ago. Danny, great to see you again. >> Wonderful to be here with you. >> That was a really fun show VeeamON, it always is. You guys got a cool vibe. >> You chose the Fontainebleau Hotel this year in Miami, in Miami Beach which is just a great location. Many thousands of customers and you guys hit some milestones recently. You talked about a billion dollars in revenue, it's been something you're going after for a while, you've seen that happen. Of course things change, right? All the subscription stuff started to happen. That slowed you down a little bit but that's awesome that you guys finally hit that, so congratulations. Raised a big pile of dough and you just keep moving that ball forward. Give us the update on Veeam. >> So as you said, Veeam has a great culture, right? There's a passionate green army out there that loves us and we're thankful for that. We hit one billion in bookings for the trailing 12 months, we have 350,000 customers and the business is going well. One of the interesting things about Veeam is because we're private, we actually have the opportunity to decide when and how we do things like switch from perpetual to subscription type bookings. But business is doing great, we love it, we're glad to be here. >> One of the things that you talked about at VeeamON was kind of getting back to the basics. You talked a lot about look, it starts with backup. There's a lot of noise in the market today. You hear a lot about, you know, data management. We talk a lot about date assurance but at the end of the day, it starts with backup. That's something that you gave a lot of thought to. I mentioned that you were one of the thought leaders at Veeam. Double click on that, add some color. What were you thinking in terms of that being the starting point and that really driving a lot of your messaging at VeeamON? >> Yeah, I always say it's three things, right? This is a journey that we're on and I get excited about the end stages of that journey. But how many people actually have a budget for machine learning or blockchain or artificial intelligence? No one has a budget for that. What they have a budget for is backup and so we believe A, it's a journey, B, it does start with backup. There's a budget for that and the key thing is choose a partner for this journey and we believe Veeam is the right partner obviously to choose for that but we really wanted to go back to who is spending money to buy the products and for that, it's the technical decision maker who has the budget for backup today. >> Yeah, all right. So Danny, we talk about the Cisco relationship and budgets like you were talking about there. Cisco UCS was from day one a heavily virtualized environment and therefore had strong affinity with Veeam there. But you've got some great visibility into where UCS is going, what CI and HCI solutions are really starting to gain traction. So talk a little bit about that partnership and which ones of those Cisco solutions are really starting to, you know, kick in the market. >> We have a great partnership with Cisco, first of all and really in two areas, if you're talking infrastructure. So on the HyperFlex, the Converged Infrastructure but also on just the S3260 for example, a storage dense system and we have a target this year, this is public information, we have a target, a joint target of $100 million. We're actually at 80% of that right now. Business has been doing really well. In fact, we've been on the Global Price List now for 18 months and in 18 months, we've actually closed over 350 transactions. Like it's been going really, really well and here's what's exciting about that. Those customers that are spending money on Cisco gear with Veeam software, they might start in the drag, these are quantifiable numbers, it's about five to one. So every dollar they spend on Veeam, it's about $5 on Cisco. But over 35% of those customers within twelve months come back and buy more Cisco gear and actually if you look at the actual drag, quantifiable drag that we're bring for Cisco, it's 11 to one. So for every dollar they spend with Veeam, they're spending $11 in Cisco HyperFlex or S3260. So it's been a great partnership both for us obviously because we're on their resell list but also for them. >> And you said you're 80% of the way there. We're talking a calendar year or is that a fiscal year? >> That is their fiscal year, so that's ending in August or July. I should know the date but I know we're 80%. We're on track to hit that $100 million. >> What do you think is driving that? I mean obviously this is a partnership, which takes time. >> Yes. >> This is not just a press release partnership. What else have you done to really facilitate this? >> Well I would say two things. One is their infrastructure is great. In fact we have one of our Veeam cloud service providers that is protecting over a million VMs right now. So these are massive scale, are using S3260s in the backend as a repository, so their hardware actually works. But I would say the other thing that really resonates is, so they have this Hyper FEX Solution and on top of that they have Intersite and that concept of a cloud management plain that can roll out the hardware, can update it not only at the infrastructure but also the Veeam software is really critical and that resonates with customers. It's again, good for them but it's also good for us. >> Let's see. The last couple years you guys have had a big emphasis on the enterprise and then again we're hearing this theme of kind of back to basics. I mean you heard at VeeamON, it starts with backup. You talk to people at VeeamON, the customers. It's the, you know, a lot of medium sized customers, a lot of smaller customers. Do you feel like you over-rotated to the enterprise or do you feel like hey, we could get there just by slow and steady and still putting the accelerator on our core business? Can you just add some color to that and explain? >> Yeah, so if you back three years, our focus was very much on the small and medium enterprise where we said we wanted to capture the major enterprise and that by the way has worked. If you look, since January of 2017 we've done over a billion just in enterprise, enterprise being 1,000 employees or above. So focusing on the enterprise for a few years was the right thing to do. However, that was all on the messaging side and we had this core constituent that has been with us for over decade now and we didn't want to pivot away from them. So in the last six months, nine months, what you've seen is pivoting back towards the center. So we do a third of our business with SMB, a third with commercial and a third with enterprise. So we believe we're right there on the fairway now and it's a perfect alignment of that messaging. >> Well I mean history would show that the disruptors oftentimes come from, you know, down below and move up. I mean you certainly saw that with Microsoft in the 80s and there are many other examples. Is that part of the philosophy, that you guys just can keep adding value that will appeal to the enterprise customers? It sounds like with a 30 year business, you're actually already there in terms of functionality. Is there a functionality gap though still that you need to close in your opinion? >> I don't think so. We announced as you know probably v10 a few years ago and what we've done is we've introduced that over the years and so the final check box if you will for v10 is coming in our next release later this year. But that really covers off the gambit of everything that needs to be done and that's been resonating really strongly. We believe we have a portfolio that addresses everything from the smallest customer to the largest customer. >> Yeah and you don't live and die, we heard this from Radmere, you don't live and die by your long term product development roadmap. You tend to be very tactical and listen to customers and-- >> We're very agile, so we keep a backlog of all the things that we want to do but we will pivot on a dime if we believe hey, this is really strategic for our customer base. We'll change something that, you know, we had planned for year out and do something else in the interim. >> Dave: Pretty judicious about how you decide there. >> Yeah so Danny, bring us inside some of the customer conversations you're having here to show, you know, when I watch the keynotes, many of the messages about multi-cloud sound like the same kind of things that I've been hearing at VeeamON for the last couple of years. What are you hearing from the customers at this? >> Well, definitely cloud date management is top of mind. I ate dinner last night with an enterprise customer. They're rolling this out across about 100 different locations around the world and they very much wanted a local repository of data but they also wanted to tier that data into the HyperScale public cloud, so that is clearly an enterprise-centric message. But that same capability goes down to the SMB. But if you asked me what is the conversation on everyone's, on the tip of their tongue, it is cloud. How are you addressing cloud? And we've done that a number of ways. One is we take the backup data, we'll tier it into cloud. We'll recover workloads in cloud. It's not so much a lift and shift. You know what's interesting is the cloud is not a charity. If you just take what you had on premises and move it into the cloud, there's merge-in layered in there, right? But for some use cases, disaster recovery, business continuity, you want to be able to turn it on in cloud and then after it's in cloud of course, then you need to protect it. And so we've been addressing all of those capabilities within the Veeam portfolio. >> Do you think there's going to be a backlash? I mean you don't see it in the numbers. You see, you know, AWS's growth and I'm not talking about repatriation but the cloud as a target is just another piece of infrastructure, even though it's kind of virtual, that I have to manage. I mean it does add complexity in that sense. So do you think there'll be, there's maybe somewhat over-enthusiasm now or do you see this as an unstoppable trend? >> I believe that cloud is a tool in the toolbox and it's both the smallest, most precise tool and also the largest tool and everything in between. What I mean by that is this isn't just a lift and shift and move it over to the cloud. It's how do I leverage the cloud to extend my data center? I actually, a lot of people talk about multi-cloud, I actually think that the era is really hybrid cloud. It's how do I extend what I have on premises into the cloud? And we're only now really being pragmatic about how to leverage it. The people that jumped in, all in and said, "I'm going all to cloud," those are the ones that you're seeing a bit of buyers remorse but those that are a lot more pragmatic, they're now saying, "How do I deliver business outcomes?" Because it's not about cloud, it's actually about business outcomes, right? Focus on the services. How do I deliver business outcomes that are improved by leveraging aspects of the cloud? >> Yes. So Danny, I know you've talked to our team. You know, we look at the environment and customers today, they have multi-cloud. But the strategy has been well, I've got some stuff here and I use that service here and wait, I need to spin that stuff over here. We've almost remade multi-vendor into multi-cloud. >> Yes. >> So the goal we've been looking for is the solution should be more than just the sum of the parts. Veeam sits in an interesting layer to help customers leverage that and get value out of their data across all of those environments. So you know, do we see that as a viable future that is not just the state that we're in but be able to get more value out of those pieces in the near future? >> Yeah, so I'm obviously biased 'cause I work for Veeam but I think we sit at the intersection of all of this because what we do is we take services, we take workloads and we make them portable. I can take something from on premises, I can put it in cloud A, I can put it in cloud B, I can take it back on premises, I can move it to a private cloud provider. So we have the ability to be completely flexible and agnostic as to where it lands and the reason why that's important, people don't go out and say "I'm going to put 50% "of my workload in this cloud or this cloud." They say, "I need a data center in this geography" or "I need a data center that has this kind of service." So the reason they end up in multi-cloud is not because of a multi-cloud strategy but because they have a business need that is met by that infrastructure and we allow the portability, the flexibility to move the workloads as the business needs. >> So we have some data here. I want to dig into it a little bit. Can you share with us some of the fun facts? Like when, maybe the timeline of your relationship with Cisco, some of the things you've done. Walk us through that, Danny. >> So, we partnered with, we've had a longstanding relationship with Cisco. Officially we went on their Global Price List like I said, 18 months ago. Since then, 300 and, earlier this week, 359 transactions. But almost a transact, two transactions every three days and we have a great go-to-market program with them right now, so we do a lot of joint activities, both in the channel as well as between. We fund heads with them and vice versa. >> Who's your favorite partner? No, you don't have to answer that. >> We have, we have a lot of partners. They're all of my favorite children. >> So we're hearing kind of this land and expand strategy. We've heard that from many other companies. But it's actually happening inside of or within the Veeam ecosystem and what I heard here was you're selling with Cisco and then people are coming back and buying more Cisco. So that's part of land and expand but another dimension of land and expand is you sell it to an organization. Not only do they buy more but other parts of the organization, you sort of fan out horizontally. How much of that is happening? >> It's happening quite a bit. I would say the most significant expansion right now is actually at a line of business level and so you'll have multiple lines of business and then they will begin to coalesce together and say "Okay, let's supply a central policy to that." So that's what we're seeing. What we do know is that 35% of Cisco customers that are joint Veeam and Cisco customers, they'll come back within the next 12 months and they'll buy more Veeam and more Cisco gear. >> Okay last question, why Veeam? You got a lot of competitors obviously in this market. You and I have talked about that a lot. You got, Cisco has made an investment in one of them. Why Veeam? >> So, simple, reliable, flexible and the flexible is probably the key to all of this because we don't lock people in. We don't lock them into our hardware, we don't lock them into a specific cloud, we don't lock them into any one of our children if you will, we love them all equally and that flexibility, future proofing the organization is a huge deciding point for the organizations. Because they don't know what the landscape's going to look like two, three years from now. Is this still going to be your partner or is it not? So having an organization that will partner with you, that will be flexible in, and this isn't just flexibility at a technology level, it's also at a business level. Licensing, for example. Flexibility to move licenses from physical systems to virtual systems to cloud systems to back again. They want to partner with someone that has that flexibility. >> Danny, great to see you again. Thanks so much for coming to theCUBE, always a pleasure. >> Yes, likewise. >> Okay, Stu Miniman, Dave Vellante, Lisa Martin from Cisco Live in San Diego 2019. You're watching theCUBE, we'll be right back. (upbeat electronic tones)