>>from around the globe. It's the Cube with coverage of Coop Con and Cloud, Native Con Europe 2020 Virtual brought to You by Red Hat, The Cloud Native Computing Foundation and its Ecosystem Partners. >>And welcome back to the Cube's coverage of Cube Con Cloud, Native Con Europe 20 twenties Virtual event. I'm Stew Minimum and and happy to Welcome back to the program, two of our Cube alumni. We're gonna be talking about storage in this kubernetes and container world. First of all, we have Sam Warner. He is the vice president of storage, offering management at IBM, and joining him is Brent Compton, senior director of storage and data architecture at Red Hat and Brent. Thank you for joining us, and we get to really dig in. It's the combined IBM and red hat activity in this space, of course, both companies very active in the space of the acquisition, and so we're excited to hear about what's going going. Ford. Sam. Maybe if we could start with you as the tee up, you know, Both Red Hat and IBM have had their conferences this year. We've heard quite a bit about how you know, Red Hat the solutions they've offered. The open source activity is really a foundational layer for much of what IBM is doing when it comes to storage, you know, What does that mean today? >>First of all, I'm really excited to be virtually at Cube Con this year, and I'm also really excited to be with my colleague Brent from Red Hat. This is, I think, the first time that IBM storage and Red Hat Storage have been able to get together and really articulate what we're doing to help our customers in the context of kubernetes and and also with open shift, the things we're doing there. So I think you'll find, ah, you know, as we talked today, that there's a lot of work we're doing to bring together the core capabilities of IBM storage that been helping enterprises with there core applications for years alongside, Ah, the incredible open source capabilities being developed, you know, by red Hat and how we can bring those together to help customers, uh, continue moving forward with their initiatives around kubernetes and rebuilding their applications to be develop once, deploy anywhere, which runs into quite a few challenges for storage. So, Brennan, I'm excited to talk about all the great things we're doing. Excited about getting to share it with everybody else. A cube con? >>Yes. So of course, containers When they first came out well, for stateless environments and we knew that, you know, we've seen this before. You know, those of us that live through that wave of virtualization, you kind of have a first generation solution. You know what application, What environment and be used. But if you know, as we've seen the huge explosion of containers and kubernetes, there's gonna be a maturation of the stack. Storage is a critical component of that. So maybe upfront if you could bring us up to speed you're steeped in, you know, a long history in this space. You know, the challenges that you're hearing from customers. Uhm And where are we today in 2020 for this? >>Thanks to do the most basic caps out there, I think are just traditional. I'm databases. APS that have databases like a post press, a longstanding APS out there that have databases like DB two so traditional APs that are moving towards a more agile environment. That's where we've seen in fact, our collaboration with IBM and particularly the DB two team. And that's where we've seen is they've gone to a micro services container based architecture we've seen pull from the market place. Say, you know, in addition to inventing new Cloud native APS, we want our tried true and tested perhaps I mean such as DB two, such as MQ. We want those to have the benefits of a red hat, open shift, agile environment. And that's where the collaboration between our group and Sam's group comes in together is providing the storage and data services for those state labs. >>Great, Sam, you know I IBM. You've been working with the storage administrator for a long time. What challenges are they facing when we go to the new architectures is it's still the same people it might There be a different part of the organization where you need to start in delivering these solutions. >>It's a really, really good question, and it's interesting cause I do spend a lot of time with storage administrators and the people who are operating the I T infrastructure. And what you'll find is that the decision maker isn't the i t operations or storage operations. People These decisions about implementing kubernetes and moving applications to these new environments are actually being driven by the business lines, which is, I guess, not so different from any other major technology shift. And the storage administrators now are struggling to keep up. So the business lines would like to accelerate development. They want to move to a developed, once deploy anywhere model, and so they start moving down the path of kubernetes. In order to do that, they start, you know, leveraging middleware components that are containerized and easy to deploy. And then they're turning to the I T infrastructure teams and asking them to be able to support it. And when you talk to the storage administrators, they're trying to figure out how to do some of the basic things that are absolutely core to what they do, which is protecting the data in the event of a disaster or some kind of a cyber attack, being able to recover the data, being able to keep the data safe, ensuring governance and privacy of the data. These things are difficult in any environment, but now you're moving to a completely new world and the storage administrators have ah tough challenge out of them. And I think that's where IBM and Red Hat can really come together with all of our experience and are very broad portfolio with incredibly enterprise hardened storage capabilities to help them move from their more traditional infrastructure to a kubernetes environment. >>Maybe if you could bring us up to date when we look back, it, like open stack of red hat, had a few projects from an open source standpoint to help bolster the open source or storage world in the container world. We saw some of those get boarded over. There's new projects. There's been a little bit of argument as to the various different ways to do storage. And of course, we know storage has never been a single solution. There's lots of different ways to do things, but, you know, where are we with the options out there? What's that? What's what's the recommendation from Red Hat and IBM as to how we should look at that? >>I wanna Bridget question to Sam's earlier comments about the challenges facing the storage admin. So if we start with the word agility, I mean, what is agility mean for it in the data world. We're conscious for agility from an application development standpoint. But if you use the term, of course, we've been used to the term Dev ops. But if we use the term data ops, what does that mean? What does that mean to you in the past? For decades, when a developer or someone deploying production wanted to create new storage or data, resource is typically typically filed a ticket and waited. So in the agile world of open shift in kubernetes, it's everything is self service and on demand or what? What kind of constraints and demands that place on the storage and data infrastructure. So now I'll come back to your questions. Do so yes. At the time, that red hat was, um, very heavily into open stack, Red Hat acquired SEF well acquired think tank and and a majority of the SEF developers who are most active in the community. And now so and that became the de facto software defying storage for open stack. But actually for the last time that we spoke at Coop Con and the Rook project has become very popular there in the CN CF as away effectively to make software defined storage systems like SEF. Simple so effectively. The power of SEF, made simple by rook inside of the open shift operator frame where people want that power that SEF brings. But they want the simplicity of self service on demand. And that's kind of the diffusion. The coming together of traditional software defined storage with agility in a kubernetes world. So rook SEF, open shift container storage. >>Wonderful. And I wonder if we could take that a little bit further. A lot of the discussion these days and I hear it every time I talk to IBM and Red Hat is customers air using hybrid clouds. So obviously that has to have an impact on storage. You know, moving data is not easy. There's a little bit of nuance there. So, you know, how do we go from what you were just talking about into a hybrid environ? >>I guess I'll take that one to start and Brent, please feel free to chime in on it. So, um, first of all, from an IBM perspective, you really have to start at a little bit higher level and at the middleware layer. So IBM is bringing together all of our capabilities everything from analytics and AI. So application, development and, uh, in all of our middleware on and packaging them up in something that we call cloud packs, which are pre built. Catalogs have containerized capabilities that can be easily deployed. Ah, in any open shift environment, which allows customers to build applications that could be deployed both on premises and then within public cloud. So in a hybrid multi cloud environment, of course, when you build that sort of environment, you need a storage and data layer, which allows you to move those applications around freely. And that's where the IBM storage suite for cloud packs was. And we've actually taken the core capabilities of the IBM storage software to find storage portfolio. Um, which give you everything you need for high performance block storage, scale out, um, file storage and object storage. And then we've combined that with the capabilities, uh, that we were just discussing from Red Hat, which including a CS on SEF, which allow you, ah, customer to create a common, agile and automated storage environment both on premises and the cloud giving consistent deployment and the ability to orchestrate the data to where it's needed >>I'll just add on to that. I mean that, as Sam noted and is probably most of you are aware. Hybrid Cloud is at the heart of the IBM acquisition of Red Hat with red hat open shift. The stated intent of red hat open shift is to be to become the default operating environment for the hybrid cloud, so effectively bring your own cloud wherever you run. So that that is at the very heart of the synergy between our companies and made manifest by the very large portfolios of software, which would be at which have been, um, moved to many of which to run in containers and embodied inside of IBM cloud packs. So IBM cloud packs backed by red hat open shift on wherever you're running on premises and in a public cloud. And no, with this storage suite for cloud packs that Sam referred to also having a deterministic experience. That's one of the things as we work, for instance, deeply with the IBM DB two team. One of the things that was critical for them, as they couldn't have they couldn't have their customers when they run on AWS have a completely different experience than when they ran on premises, say, on VM, where our on premises on bare metal critical to the DB two team t give their customers deterministic behavior wherever they can. >>Right? So, Sam, I I think any of our audience that it followed this space have heard Red House story about open shift in how it lives across multiple cloud environments. I'm not sure that everybody is familiar with how much of IBM storage solutions today are really this software driven. So ah, And therefore, you know, if I think about IBM, it's like, okay, and by storage or yes, it can live in the IBM Cloud. But from what I'm hearing from Brent in you and from what I know from previous discussion, this is independent and can live in multiple clouds, leveraging this underlying technology and can leverage the capabilities from those public cloud offers. That right, Sam? >>Yeah, that's right. And you know, we have the most comprehensive portfolio of software defined storage in the industry. Maybe to some, it's ah, it's a well kept secret, but those that use it No, the breadth of the portfolio. We have everything from the highest performing scale out file System Teoh Object store that can scale into the exabytes. We have our block storage as well, which runs within the public clouds and can extend back to your private cloud environment. When we talk to customers about deploying storage for hybrid multi cloud in a container environment, we give them a lot of houses to get there. We give them the ability to leverage their existing san infrastructure through the CS I drivers container storage interface. So our whole, uh, you know, physical on Prem infrastructure supports CS I today and then all the software that runs on our arrays also supports running on top of the public clouds, giving customers then the ability to extend that existing san infrastructure into a cloud environment. And now, with storage suite for cloud packs a sprint described earlier, we give you the ability to build a really agile infrastructure, leveraging the capabilities from Red Hat to give you a fully extensible environment and a common way of managing and deploying both on Prem and in the cloud. So we give you a journey with our portfolio to get from your existing infrastructure. Today, you don't have to throw it out it started with that and build out an environment that goes both on Prem and in the cloud. >>Yeah, Brent, I'm glad that you started with database, cause it's not something that I think most people would think about. You know, in a kubernetes environment, you Do you have any customer examples you might be able to give? Maybe Anonymous? Of course. Just talking about how those mission critical applications can fit into the new modern architect. The >>big banks. I mean, just full stop the big banks. But what I'd add to that So that's kind of frequently they start because applications based on structured data remain at the heart of a lot of enterprises. But I would say workload, category number two, our is all things machine Learning Analytics ai and we're seeing an explosion of adoption within the open shift. And, of course, cloud pack. IBM Cloud private for data, is a key market participant in that machine learning analytic space. So an explosion of the usage of of open shift for those types of workloads I was gonna touch just briefly on an example, going back to our kind of data data pipeline and how it started with databases, but it just it explodes. For instance, data pipeline automation, where you have data coming into your APS that are kubernetes based that our open shift based well, maybe we'll end up inside of Watson Studio inside of IBM ah, cloud pack for data. But along the way, there are a variety of transformations that need to occur. Let's say that you're a big bank. You need Teoh effectively as it comes in. You need to be able to run a CRC to ensure to a test that when when you modify the data, for instance, in a real time processing pipeline that when you pass it on to the next stage that you can guarantee well that you can attest that there's been no tampering of the data. So that's an illustration where it began, very with the basics of basic applications running with structured data with databases. Where we're seeing the state of the industry today is tremendous use of these kubernetes and open shift based architectures for machine learning. Analytics made more simple by data pay data pipeline automation through things like open shift container storage through things like open shift server lis or you have scale double functions and what not? So yeah, it began there. But boy, I tell you what. It's exploded since then. >>Yeah, great to hear not only traditional applications, but as you said so, so much interest. And the need for those new analytics use cases s so it's absolutely that's where it's going. Someone. One other piece of the storage story, of course, is not just that we have state full usage, but talk about data protection, if you could, on how you know things that I think of traditionally my backup restore and like, how does that fit into the whole discussion we've been having? >>You know, when you talk to customers, it's one of the biggest challenges they have honestly. And moving to containers is how do I get the same level of data protection that I use today? Ah, the environments are in many cases, more complex from a data and storage perspective. You want Teoh be able to take application consistent copies of your data that could be recovered quickly, Uh, and in some cases even reused. You can reuse the copies, for they have task for application migration. There's there's lots of or for actually AI or analytics. There's lots of use cases for the data, but a lot of the tools and AP eyes are still still very new in this space. IBM has made, uh, prior, uh, doing data protection for containers. Ah, top priority for our spectrum protect suite. And we provide the capabilities to do application aware snapshots of your storage environment so that a kubernetes developer can actually build in the resiliency they need. As they build applications in a storage administrator can get a pane of glass Ah, and visibility into all of the data and ensure that it's all being protected appropriately and provide things like S L A. So I think it's about, you know, the fact that the early days of communities tended to be stateless. Now that people are moving some of the more mission critical workloads, the data protection becomes just just critical as anything else you do in the environment. So the tools have to catch up. So that's a top priority of ours. And we provide a lot of those capabilities today and you'll see if you watch what we do with our spectrum. Protect suite will continue to provide the capabilities that our customers need to move their mission. Critical applications to a kubernetes environment. >>Alright And Brent? One other question. Looking forward a little bit. We've been talking for the last couple of years about how server lists can plug into this. Ah, higher kubernetes ecosystem. The K Native project is one that I, IBM and Red Hat has been involved with. So for open shift and server lis with I'm sure you're leveraging k native. What is the update? That >>the update is effectively adoption inside of a lot of cases like the big banks, but also other in the talk, uh, the largest companies in other industries as well. So if you take the words event driven architecture, many of them are coming to us with that's kind of top of mind of them is the need to say, you know, I need to ensure that when data first hits my environment, I can't wait. I can't wait for a scheduled batch job to come along and process that data and maybe run an inference. I mean, the classic cases you're ingesting a chest X ray, and you need to immediately run that against an inference model to determine if the patient has pneumonia or code 19 and then kick off another serverless function to anonymous data. Just send back in to retrain your model. So the need. And so you mentioned serverless. And of course, people say, Well, I could I could handle that just by really smart batch jobs, but kind of one of the other parts of server less that sometimes people forget but smart companies are aware of is that server lists is inherently scalable, so zero to end scalability. So as data is coming in, hitting your Kafka bus, hitting your object store, hitting your database and that if you picked up the the community project to be easy, Um, where something hits your relational database and I can automatically trigger an event onto the Kafka bus so that your entire our architecture becomes event >>driven. All right. Well, Sam, let me give you the funding. Let me let you have the final word. Excuse me on the IBM in this space and what you want them to have his takeaways from Cube con 2020 Europe. >>I'm actually gonna talk to I think, the storage administrators, if that's OK, because if you're not involved right now in the kubernetes projects that are happening within your enterprise, uh, they are happening and there will be new challenges. You've got a lot of investments you've made in your existing storage infrastructure. We had IBM and Red Hat can help you take advantage of the value of your existing infrastructure. Uh, the capabilities, the resiliency, the security of built into it with the years. And we can help you move forward into a hybrid, multi cloud environment built on containers. We've got the experience and the capabilities between Red Hat and IBM to help you be successful because it's still a lot of challenges there. But But our experience can help you implement that with the greatest success. Appreciate it. >>Alright, Sam and Brent, Thank you so much for joining. It's been excellent to be able to watch the maturation in this space of the last couple of years. >>Thank you. >>Alright, we'll be back with lots more coverage from Cube Con Cloud, native con Europe 2020 the virtual event. I'm stew Minimum And thank you for watching the Cube. Yeah, yeah, yeah, yeah

>>from around the globe. It's the Cube with digital coverage of Red Hat. Summit 2020 Brought to you by Red Hat. >>Hi, I'm stupid, man. And this is the Cube's coverage of the Red Hat Summit 2020 course. The event this year is digital. We're talking to Red Hat executives, partners and customers where they are around the globe, pulling them in remotely happy to welcome back to the program. One of our Cube alumni on a very important topic, of course, that red hat open shift and joining me is Clayton Coleman. Who's the open shift chief architect with Red Hat. Clayton, thanks so much for joining us. Thank you >>for having me today. >>All right, So before we get into the product, it's probably worthwhile that we talked about you know what's happening in the community and talking specifically, you know, kubernetes the whole cloud, native space. Normally we would have gotten together. I would have seen you at Cube Con Ah, you know, at the end of March. But instead, here we are at the end of April. Looking out, you know, more CN cf events later this year, but first Red Hat Summit is a great open source event and broad community. So would really love your viewpoint as to what's happening in that ecosystem. >>It's been a really interesting year, obviously. Ah, with an open source community, you know, we react to this. Um, like we always react to all the things that go on in open source. People come to the community and sometimes they have more time, and sometimes they have less time. I think just from a community perspective, there's been a lot of people you know. It's reaching out to their colleagues outside of their companies, to their friends and coworkers and all of the different participants in the community. And there's been a lot of people getting together for a little bit of extra time trying todo, you know, connect virtually where they can't connect physically. And it's been it's been great to at least see where we've come this year. We haven't had Cube con and that'll be coming up later this year. But Kubernetes just had the 1 18 release, and I think Kubernetes is moving into that phase where it's a mature, open source project. We've got a lot of the processes down. I'm really happy with the work that the steering committee, um, has gone through. We handed off the last of the bootstrap Steering Committee members hand it off to the new, fully elected steering committee last year, and it's gone absolutely smoothly, which has been phenomenal on the The core project is trying to be a little bit more stable and to focus on closing out those loose ends being a little bit more conservative to change. And at the same time, the ecosystem has really exploded in a number of directions, as as Kubernetes becomes more of a bedrock technology for, um, enterprises and individuals and startups and everything in between. We've really seen a huge amount of of innovation in the space, and every year it just gets bigger and bigger. There's a lot of exciting projects that >>I >>have never even talk to somebody on the Kubernetes project. But they have made and build and, uh, and solve problems for their environments without us ever having to be involved, which I think it's success. >>Yeah, Clayton, you know, one of the challenges when you talk to practitioners out there is just keeping up with the pace of change. Can really be challenging. Something we really saw acutely was Docker was rolling out updates every six weeks. Most customers aren't going to be able to change fast enough to keep up with things you love your view point both is toe really what the CN CF says, as well as how Red Hat thinks of products. So you talked about you know, kubernetes 1.18. My understanding, even Google isn't yet packaging and offering that version there. So there's a lag between things. And as we start talking about managing across lots of clusters, how does Red Hat think of this? How should customers think about this? How do we make sure that we're, you know, staying secure and keeping updated on things without getting run over by the constant treadmill of >>change? That the interesting part about kubernetes Is it so much more than just that core project? You know, no matter what any of us in the in the core kubernetes project or in the products that red hat that build around open shift and layers on top, there's a There's a whole ecosystem of components that most people think of this fundamental to accomplishing building applications deploying them, running them, Whether it's their continuous integration pipelines or it's their monitoring stacks, we really as communities has become a little bit more conservative. >>Um, I >>think we really nail down our processes for taking that change from the community, testing it. You know, we run tens of thousands of automation tests a week on the latest and greatest kubernetes code, given time to soak, and we did it together with all those pieces of the ecosystem and then make sure that they work well together. And I've noticed over the last two years that the rate of oops we missed that in KUBERNETES 1 17 that by the time someone saw it, people are already using that that started to go down for us, it really hasn't been about the pace of keeping up with the upstream. But it's about making sure that we can responsibly pull together all the other ecosystem components that are still have much newer and a little bit. How do we say, Ah, they are then the exciting phase of their development while still giving ah predictable, reliable update stream. I would say that the challenges that most people are going to see is how they bring together all those pieces. And that's something that, on open shift, we think of as our goal is to help pull together all the pieces of this ecosystem, Um, and to make some choices for customers that makes sense and to give them flexibility where it's not clear yet what the right choice might be or where different people could reasonably disagree. And I'm really excited. I feel like we've got our We have a release cadence down and we're shipping the latest Cube after it's had time to quickly review, and I think we've gotten better and better at that. So I'm really proud of the team on Red Hat and how they've worked within the community so that everybody benefits from that in that testing of that stability. >>Great. I'd like to teach here, you dig in a little bit on the application side what's happening from the work loads that customers are using? Ah, what other innovations happening around that space? And how is Red Hat really helping? Really, The the infrastructure team and the developer team work even closer together, like Red Hat has done for a long time. >>This is This is a great question. I say There's two key, um, two key groups coming together. People are bringing substantial important critical production workloads, and they expect things both to just work, but also to be able to understand it. And they're making the transition. Ah, lot of folks I talked to were making the transition from previous systems they've got. They've been running open shift for a while, or they've been running kubernetes for a while, and they're getting ready to move, um, a significant portion of their applications over. And so, you know, in the early days of any project, you get the exciting Greenfield development and you get to go play with new technologies. But as you start moving your 1st 1 and then 10 and then 100 of your core business applications from the EMS or from bare metal into containers, you're taking advantage of that technology in a responsible way. And so the the expectations on us as engineers and community members is to really make sure that we're closing out the little stuff. You know, no bug is too small, but it can't trip up someone's production applications. So seeing a lot of that whether it's something new and exciting like, Um uh, model is a service or ai workloads or whether it's traditional big enterprise transaction processing. APS on the other side on that development, um, model I think we're starting to see phase to our community is 2.0, in the community, which is people are really leveraging the flexibility and the power of containers, things that aren't necessarily new to people who had. We got into containers early and had a chance to go through a couple of iterations. But now people are starting to find patterns that up level development teams, so being able to run applications the same way on a local machine as in a production environment. Well, most production environments are there now, and so people are really having toe. They're having to go through all of their tools and saying, Well, does this process that works for an individual developer also work when I want to move it there, my production or staging environments to production, and so on. New projects like K native and tectonic, which are kubernetes native, that's just one part of the ecosystem around development. On top of kubernetes, there's tons of exciting projects out there from companies that have adopted the full stack of kubernetes. They built it into their mindset, this idea of flexible infrastructure, and we're seeing this explosion of new ways where kubernetes is really just a detail, and containers are just the detail and the fact that it's running this little thing called Docker down at the heart of it. Nobody talks about anymore, and so that that transition has been really exciting. I think there's a lot that we're trying to do to help developers and administrators see eye to eye. And a lot of it's learning from the customers and users out there who really paved the way the which is the open source way. It's learning from others and helping others benefit from that. >>Yeah, I think you bring up a really important point we've been saying for a couple of years. Now that you know KUBERNETES should get to the point where it's boring and boring in a way also cause it's gonna be baked in everywhere we saw from basically customers just taking the code, really spending a lot of their own things by building the stack to, of course, lots of customers have used open shift over the year to If I'm adopting Public Cloud more and more, they're using those services from that standpoint. Can you talk a bit about how Red Hat is really integrating with public clouds? And you know your architectural technical philosophy on that? And how might that be? Differ from some other companies that you might call a little bit more, you know, Cloud of Jason, as opposed to being deeply integrated with the public cloud. >>The interesting thing about Kubernetes is that while it was developed on top of the clouds, it wasn't really built from Day one assuming a cloud underneath it. And I think that was an opportunity that we really missed. And to be fair, we had to make the thing work first before we depended on these unreliable clouds. You know, when we started, the clouds were really hitting their stride on stability and reliability, and people were it was the hot was becoming the obvious choice to some of what we've tried to do is take flexible infrastructure is a given, um, assume that the things that the cloud provides should be programmed for the for the benefit of the developer and the application, and I think that's a that's a key trend is we're not using the cloud because our administration teams want us. We're using the cloud because it makes us more powerful developers. That enables new scenarios. It shortens the the time between idea reality. What we have done in open shift is we've really built around The idea of open shift running on a cloud should take advantage of that cloud to an extreme degree, which is infrastructure could be flexible. The machines in that cluster need to come and go according to the demands of the applications on top of it. So giving a little bit more power to the cluster and taking a little bit of way from the cloud I'm. But that benefits. That also needs to benefit that those who are running on premise because I think, as you noted, our goal is you want this ubiquitous kubernetes environment everywhere, and the operations teams and the development teams and the Dev Ops teams in between need to have a consistent environment and so you can do this on the cloud. But you don't have that flexibility on premise. You've lost something. And so what we've tried to do as well is to think about those ideas that are what we think of as quote unquote cloud native that starts with a mutable operating systems. It starts with everything being declarative and working backwards from, you know, I wanna have 15 machines and then the cluster or controllers on the cluster say, Oh, well, you know, one of the machines has gone bad. Let's replace it on the cloud. You ask for a new I'm cloud infrastructure provider or you ask the the cloud a p i for a new machine, and then you replace it automatically, and no one knows any better on premise. We'd love to do the same thing with both bare metal virtualization on top of kubernetes. So we have that flexibility to say you may not have all of the options, but we should certainly be able to say, Oh, well, this hardware is bad or the machine stopped, so let's reboot it, and there's a lot of that same mindset that could be applied. We think that'll, um if you need virtualization, you can always use it. But virtualization is a layer on top benefits from some of the same things that all the other extensions and applications on top of kubernetes competitive trump. So trying to pay that layer and make sure that you have flexible, reliable storage on premise through our SEF and red hat storage products, which are built on top of the cluster exactly like virtualization, is both on top of the cluster. So you get cloud native storage mixed in working with those teams toe. Take those operational best practices. You know there's well, I think one of the things that interests me is no. 1 20 years ago, who was running an early version of SEF wouldn't have some approach to run these very large things that scales organizations like CERN have been using SEF for over a decade at extremely large scales. Some of what our mindset is we think it's time to bake some of that knowledge actually into our software for a very long time. We've kind of been building out and adding more and more software, but we always left the automation and the the knowledge about how that software supposed to be run to the side. And so by taking that and we talked about operators. Kubernetes really enshrines. This principle is taking that idea, taking some of that operational knowledge into the software we ship. Um, though that software can rely on kubernetes open shift tries to hide the details of the infrastructure underneath and our goal. I think in the long run it will just make everybody's lives easier. I shouldn't have to ship you a SEF admin for you to be successful. And we think we think there's a lot more room here that's really gonna improve how operations teams work, that the software that they use day to day. >>So Clinton you mentioned virtualization is one of the topics in there. Of course, virtualization is very prevalent in a customer's data center environment today. Red Hat open shift, oftentimes in data centers, is sitting on BM ware environments. Of course. Recently, VM Ware announced that they have kubernetes baked into the solution, and red hat has open shift with red hat virtualization. Maybe, you know, without going into too much depth, and you probably have breakouts and white papers on this. But you know what kind of decision point should customers be thinking about when they're deciding? Do I do this in bare metal. Do I do it in virtualization? What are some of the, you know, just high level trade offs there when they need to make those decisions, >>I think it's, um I think the 1st 1 is Virtualization is a mature technology. It's a known quantity for many organizations, and so those who are comfortable with virtualization, I'd say, like any responsible, uh, architecture engineering team. You don't want to stop using something that's working well just because you can. And a lot of what I would see as the transition that companies on is for some organizations without a big investment in virtualization. They don't see the need for it anymore, except as maybe a technical detail of how they isolate insecure workloads. One of the great things about virtualization technology that we're all aware of over the last couple years is it creates a boundary between work loads and the underlying environment. That doesn't mean that the underlying environment and containers can't be as secure or benefit from those same techniques. And so we're starting to see that in the community, this kind of spectrum of virtualization all the way from the big traditional virtualization to very streamlined, stripped down virtualization wrappers around containers. Um, like some of the cloud providers use for their application environments. So I'm really excited about the open source. Community is touching each of these points on the spectrum. Some of our goals are if you're happy with your infrastructure provider, we want to work well with, and that's kind of the pragmatic of everyone's on a different step in that journey. The benefit of containers is no matter how fast you make of VM, it's never gonna be quite as fast, is it containers. And it's never gonna be quite as easy for a developer to run on their laptop. And I think working through this is there's still a lot of work that we as a community to do around, making it easier for developers to build containers and test them locally in smaller environments. But all of that flexibility can still benefit from virtualization under later or virtualization used as an isolation technology. So projects like Kata and some of the work that's being done in the open source community around projects like firecracker taking the same, um, open source ideas and remixing them a different points gives us a lot of flexibility. So I would say, um, I'm actually less interested in virtualization then all of the other technologies that are application centric and at the heart of it, a VM isn't really a developer centric idea. It's specifically an administrative concept that benefits the administrator, and developers can take advantage of it. But I think all of the capabilities that you think of when you think about building an application like scaling out and making sure patches are applied, being able to roll back separating your configuration on then all of the hundreds of other levels of complexity that will add around that like service MASH and the ability to gracefully tolerate failures in your database. These were where I think, um, virtualization needs to work with the platform rather than being something that dominates how we think about the platform. It's application first, not being first. >>Yeah, no, you're absolutely right that the critique I've always given, you know for a number of years now is if you look at virtualization, the promise was, let's take that old application that probably should have been updated and just shove it in a VM and never think about it again. That's not doing good things for the user. So if I look at that at one end of the spectrum away at the other end of the spectrum, trying not to think about infrastructure, you mentioned K native s 01 of the things that you know I've been digging in tryingto learn more about at Red Hat Summit has really been the open shift server lists. So give us the update on that piece. Um, you know, that's obviously very different discussion than what we were just having from a virtualization standpoint. Eso How does open shift look at server lists? How does that tie into what? You know, if I'm doing server, listen, Amazon versus you know some of the other open source options for serverless. How should I be thinking about that? >>There's a lot of great choices on the spectrum out there. I think one of the interesting things and I love the word spectrum here because cane native kind of sits in a spot where it tries to be, as the name says, it tries to be as kubernetes native as possible, which lets you tap into some of those additional capabilities when you need it. And one of the things I've always appreciate it is the more restrictive framework is usually the better. It is doing that one thing and doing it really well. We learned this with rails. We learned this with no Js. And as people have built over the years, the idea of simple development platforms. The core function idea is a great simple idea, but sometimes you need to break out of that. You need extra flexibility or your application needs to run longer or slow Start is actually an issue. One of the things I think is most interesting about K native and I see comers and user. I think this way it's a good point. Um, that gives you some of the flexibility of kubernetes and a lot of the simplicity of, um, the functions is a service, but I think that there's going to be an inevitable set of use cases that tie into that which are simpler where open organization has a very opinionated way of running applications, and I think that flexibility will really benefit K native. Whereas some of the more opinionated remarks around server lists lose a little bit of that. So that's one dimension that I still think a native is well positioned to kind of capture the broadest possible audience, which for kubernetes and Containers was kind of our mindset. We wanted to solve enough of the problems that you can solve. You can run all your software. We don't have to solve all those problems to such a level that there's endless complexity, although we've been accused of having endless complexity and Cooper days before, but just trying to think through what are the problems that everyone's going to have to give them a way out? I'm at the same time for us, when we think about prioritization functions is service about integration. It's about taking applications and connecting them, connecting them through kubernetes. And so it really depends on identity and access to data and tying that into your cloud environment. If you're running on top of a cloud or tying it into your back end databases, if your on premise, >>I >>think that is where the ecosystem is still working to bring together and standardize some of those pieces in kubernetes or on top of Kubernetes. What I'm really excited about is the team as much. You know, there's been this core community effort to get a native to a G, a quality. Alongside that, the open shift serverless team has been trying to make it a dramatically simpler action. If you have kubernetes and open shift, it's a one click action to get started with, Um Kay native and just like any other technology. How accessible it is determines how easy users find it to get started and to build the applications they need. So for us, it's not just about the core technology. It's about someone who's not familiar with Serverless or not familiar with kubernetes. Bring up an editor and build a function and then deploy it on top of open shift. See it scale out like a normal kubernetes application, not having to know about pods or persistent volumes or notes. And so these air, these are some of the steps. I've been really proud that the team's done. I think there's a huge amount of innovation that will happen this year and next year, as the maturity of the kubernetes ecosystem really grows up, we'll start to see standardized technologies, for I'm sharing identity across multiple clouds across multiple environments. It's no good if you've got these applications on the cloud that need to tie into your corporate L dap. But you can't connect your corporate held up to the cloud. And so your applications need 1/3 identity system. Nobody wants 1/3 identity system. And so, working through some of this thing where the challenges I think that hybrid organizations are already facing and our job is just to work with them in the open source communities and with the cloud providers partner with them and open source so that the technologies in kubernetes fit very well into whatever environment they run it. Alright, >>well, Clayton, really appreciate all the updates there. I know the community is definitely looking forward to digging through some of the breakout sessions reading all the new announcements. And, of course, we look forward to seeing you on the team participating in many of the kubernetes related events happening later this >>year. That's right. It's ah, gonna be a good year. >>All right. Thanks so much for joining us. I'm still Minuteman and as always thank you for watching you. >>Yeah, yeah, yeah, yeah

>> Announcer: Live from Barcelona Spain, it's theCube. Covering Cisco Live 2018, brought to you by Cisco, Veeam, and the theCUBE's ecosystem partners. (electronic music) >> Okay, welcome back everyone. This is theCUBE's live coverage at Cisco Live 2018 in Europe. I'm John Furrier, cohost of theCUBE with my partner in crime this week, Stu Miniman, analyst at Wikibon.com. Also, cohost at all the events we go to, most of the events I should say. Our next guest is Ashutosh Malegaonkar, who's the Principal Engineer at Cisco DevNet, involved in a lot of the great projects in Sandbox we're going to talk about. Welcome to theCUBE. >> Thank you. Thank you for having me, John. >> Thanks for coming on. >> One of the exciting stories here is the DevNet momentum continues. Congratulations to your team. >> Ashutosh: Thank you. But you're involved in a couple cool parts of the projects that we notice was getting a lot of traction, co-create a sandbox. >> Ashutosh: Yes. >> First, take a minute to talk about what that project is and why is it so popular. >> Yeah, so as you know DevNet is becoming the key core for Cisco and one of the things that we did in DevNet is like, it's a strategic initiative where we said that we are going to call it co-creations. And what that means is we are co-creating with Cisco's strategic partners, that's one. The second is that we are taking our customers, like our top 10 customers, our top 100 customers, our partners, and our developers. So we are looking at each of these three categories and saying, how can we actually help and take that to the next level with DevNet. >> So you're sharing a lot of resource. Is is the same project? Do people bring their own project to the table? How does it work? >> Yeah, so it's both. So for example, first let's talk about strategic initiatives where ... a strategic partner sorry. And in there we have Apple and Google as our strategic partners. With Apple, what we have done is we have actually created a Fast Lane Validation program and what that does is, with Fast Lane as a product, what we are doing is any app developer who wants to use application quality of service, we actually help them validate that application in DevNet. And one of the things that we noticed is app developers really don't understand quality of service, QOS, and as soon as we say quality of service they freak out. And so we have to actually handhold them, let them understand what it means and then we actually help them take their application on the path. >> I mean there's a lot of things in networks that are like that. Deep packet inspection, people freak out and QOS, but QOS is a very important feature. >> Ashutosh: It is. >> Big time. >> It is and that's one thing that we are basically saying how can network be the platform where you can use performance as a building block? And if you heard Susie and her keynote, that's what she was stressing on, right? We want to have that as a building block for developers. >> Yeah, really interesting points. One of the things we've been digging in the last few days is kind of the changing partner ecosystem. There's some partners that have been with Cisco for decades, networking, infrastructure, but Apple, not a traditional Cisco partner. The other one, you mentioned Google. >> Ashutosh: I did, yeah. >> So I believe Google's here doing some presentations. John and I have been digging in to all the C and SEF projects so what's Google doing here. >> Yeah, so with Google, what Cisco has done is we are coming up with our hybrid or multi-cloud strategy and in the hybrid cloud strategy what we are doing is there things where, if I'm an app developer, on-prem app developer and I want to access services which are in the cloud. Now what the partnership does is we have our security services all the way from on-prem to the cloud deployed in the Google Cloud system and as an app developer I can do my services on-prem but access some services which are in the cloud. So that's one application. Second is that if I'm an app developer working only in the cloud but I want to access some of the services which are on-prem, than how do I do it? And that's what this partnership is also helping out. >> Great. How's the reaction been of the Cisco Live audience here? How many people are lining up to come listen to Google talk about Istio? >> Yeah, so Istio is one part, but Kubernetes, like if you look at our sandbox, like it's becoming one our most popular sandbox in DevNet and Kubernetes is part. And with the Google partnership we are also working with Google on Istio. It's an open source project and what we have done is we have created a sandbox for Istio and that is also it's kind of an industry first, where developers are able to go through a learning lab to actually understand what it means. >> Yeah, absolutely. John and I were at the KubeCon show. We interviewed Lou from the Cisco team, heavily involved in the open source. But yeah, one of those things, how do we simplify it, how do we help people get the on-ramp? Sandbox is a great way for people to get started. >> Ashutosh: That's correct, that's correct. >> One of the things that we're excited about and this something that we're going to be doing, digging into all year is the impact of Kubernetes. And the sandboxing points to the trend of how people are partnering. I think you guys struck a really interesting form in this co-creation model because if you look at what service meshes are doing in markets is that the more that you can make it easier for developers and at the same time enabling the engineering side of it, getting down and dirty. We're talking about QOS, we're talking about plumbing stuff. There's still a lot of automation being done under the hood. This is the network opportunity, this is where we're seeing automation around provisioning and configuration management and all that good stuff. That needs to get done but it has to be addressable for true programmability. We're not there yet, but we're almost there. >> Ashutosh: We're getting there, yes. >> What's your reaction to that, a 19-year veteran at Cisco? Cisco has an inherent advantage having the network, so looking up, that's been enabling, but now you have people who want to look down and program into you. Kind of new dynamic. >> It is, it is. >> How are you guys looking at this? >> So the way I look at it, as you said, I've seen Cisco grow. I mean, I've grown up in the company and one of things, Cisco being the expert in networking, we have experts now which are getting to doing everything, in a sense. Like the edge is where a lot of stuff is happening and when you deploy edge services you also need stuff that needs to be done in the cloud. So for example, one of the examples I like to do is let's take machine learning as a good example, where I want to download some models, machine learning models onto the edge but the traffic is actually all at the edge, so I'm taking all the inputs from the edge, taking at the edge, calculating things, and then the models are being built in the cloud because I can't build those at the edge. So that's the thing that is happening now and what we see here is that Cisco is in the midst of both edge as well as cloud. >> And IoT was going to be very instrumental. If you talk to the pure networking nerds and geeks out there, they're going to say, "Edge? "We've been doing edge of the network for years." But now the edge is extending, right? To IoT so it's not a new concept for Cisco at all, is it? >> Its not. It's not new at all. Because as I said, something very similar to what we are doing for the Apple Fast Lane, as I told you before, like now the app developer has the ability to give QOS right at the app level. It's the same thing like with IoT. It's like all the devices are connected to Cisco. >> And this is what's going to be- it's fun to watch because you guys now have compute to throw at the edge, you have cloud that you can connect to the edge, but this going to change the nature of programming. Stateful and stateless applications become a really interesting dynamic. What's your reaction to that trend of as developers start to really start thinking about state? >> Sure, so one of the things that ... Again I go back to the edge thing where like if you have a tunnel and then there are cars passing by, you are actually looking at the cars as, let's say a stream of dots. Now that state you cannot be giving and storing it somewhere so you basically keep it at the edge, you figure out what's happening, compute, and take some actions there itself. >> That' where the action is. Ashutosh, thank you for coming on theCUBE and sharing your knowledge, appreciate it. Congratulations on the co-creation Fast Lane service you guys have, among other things. The collaboration model is the future. Cisco's really demonstrating that in the DevNet zone so props to the team. It's theCUBE, we always collaborate, sharing the best content here live in Barcelona with you. I'm John Furrier, Stu Miniman. More live coverage, day two of our two days wall to wall live coverage of Cisco Live 2018 in Europe. This is theCUBE. Be right back with more after this short break. (electronic music)