 Coming out, I'm Jeff O'Neill, Senior Director, responsible for OpenStack at NetApp. And I'll introduce our panel as we go along. We're going to cover white as enterprise storage matter to OpenStack. And I'd like to thank you all coming out at this late hour on day two here to join us. Before I get started, I want to say one of the great things about this conference is that we're all together. We all know OpenStack. And so that's great. And we're going to talk a little bit about what happens when you go back to your respective businesses and how do people outside of this bubble we create here in Vancouver, how are they accepting OpenStack and what's the story there? So I created this one, this next slide, he said. So the notion is that, well, this is wisdom that was given to me by my seven-year-old nephew just before I got here. And he says, what happens when you're attacked by a bunch of clowns? Go for the juggler. So you can take that back with you. Wisdom from Vancouver. So we have a great panel here today representing a number of different companies in this area. So we have Nick Berset from Red Hat, Pete Chadwick from SUSE, Reddy Chagom from Intel, and Manu Pradhan from HP. And we're going to talk a little bit about what we see happening around enterprise storage and OpenStack. So set of themes that came out as we were prepping for this. And so I was going to ask you, Nick, to get us started here. And please introduce yourself in more thoroughly as we go. Yeah, there's a common appeal around open source technology and commodity hardware. And I know I answer this question all the time. It's an initial low cost of entry. And so it's a way to get started. Weighing that versus successful growth, operating cost at scale, all of those issues. How do you see OpenStack and enterprise storage playing there? So introduction first. Nick Berset, director of product management for OpenStack at Red Hat. Joined Red Hat a few months back in June when Inovance was acquired by Red Hat. Been a great journey so far. I've been involved in the OpenStack journey for now six years. And that also has been a lot of fun. So to come back to your question, OpenStack, we, I'm going to say we because everybody in this room has been contributing, I'm sure, have been building OpenStack all around the notion of choices. I am now in charge of a product called Red Hat Enterprise Linux OpenStack platform. And when we go work with enterprise and check what their needs are, choice is very important to them. And choice is something that they need to offer when they build an OpenStack platform to their users. And their users are people building application. And when you build an application that has enterprise class requirement, you cannot offer the same level of storage that you would offer to another application that has been built for stateless. And in these cases, you may have requirements that go up to very strong disaster recovery or very fast access time. And it is not the same back end that you're going to be offering to Zeus applications that you would for the former ones. So enterprise storage is one of the key component that we need to enable in order to offer the choice that are needed by the various kinds of users of an OpenStack environment. Great, thanks. Pete, anybody have some data on that? So this is I'm Pete Chadwick. I'm senior product manager at SUSE responsible for SUSE OpenStack Cloud, which is our OpenStack distribution. And I read everything that Nick just said and would expand upon that because we actually have customers that are looking at moving enterprise workloads into OpenStack. There's a lot of debate going on in the industry about pets versus cattle. And I actually have customers that want to put pets into OpenStack. And one of the things, for example, that we've done working with NetApp is enabling SAP applications in OpenStack. And SAP applications have a strong dependency on solid shared back end storage that can take advantage of things like fast cloning. And a lot of things that a NetApp or enterprise storage products can provide and customers, quite honestly, couldn't make that kind of a leap without that level of functionality. My name is Reddy Chagam. I focus on a couple of things, mostly software-defined storage architecture and enabling the open-source solutions in the industry. So I have a background. My background is, essentially, from the manufacturing. I spent probably 10 years' worth of my life at Intel in manufacturing automation. I truly appreciate the enterprise workloads. Essentially, if you look at the enterprise workloads, what you're looking for is the high availability. So that's one of the fundamental pillars in the enterprise workloads, reliability. You are looking for extremely high reliability, easy to diagnose and debug specific issues that happen in production environment. So having that kind of instrumentation in OpenStack, enabling the enterprise workloads is extremely key for the successful OpenStack deployments in the enterprise private cloud type of implementations. Otherwise, what happens is you are essentially looking at test and dev type of infrastructure. Yeah, you can deploy a scale out. You can actually use it for maybe test and dev type of virtual machines. But if you are really serious about brown field implementations for OpenStack, specifically looking at the enterprise workloads, you have to have that type of integration with the enterprise grade storage appliances that are actually deployed in a data center to be able to take advantage of that. Hi, everybody. My name is Moni Prada, and I work for HP. I'm in the product management team. And prior to HP, I've worked at NetApp. And full disclosure. My full disclosure. I've only been a year at HP, but prior to HP, I've spent 24 years in the storage industry. And to see OpenStack, to see software-defined storage, is extremely appealing to customers today. And primarily because who wouldn't want to build an array out of open source? And SEF, Swift, and all these OpenStack services today are enabling them to build those infrastructure. I believe that the road has already been paved by Amazon and Googles of the world. They have created software-defined infrastructures. I also very strongly believe that enterprises want to do the same. And in some ways, data is the sticky point. And Amazon and Google and Azure, you can go after them. They've built a very good industry for us. But then it's proprietary. And the reason I believe that OpenStack is very attractive to enterprises, because it allows them to build software-defined infrastructures from their very own commoditized hardware on their premise and create the value proposition that has been brought forth by Amazon and Googles of the world in their very own enterprise. And what helps them do that today is OpenStack. And it allows them to scale. It gives them the flexibility. They can now choose whether they want to go after open source, or they can go after proprietary vendors, like HP itself offers software-defined storage. NetApp offers software-defined storage. Many other companies are now moving in that direction. But I think the prime value proposition here is we're allowing enterprises to run their applications on the very hardware that they own, and enabling them to build Google and Amazon-like infrastructures with their very own hardware. And there's no vendor lock-in. So that's my piece. Thank you, Manu. I think the only thing I'd add, and it's really a plug for another session, is University of Melbourne is here. And they've had experience in actually scaling these solutions using both sender and Swift on enterprise storage. They gave a talk in Paris, and they're giving another talk here. I believe it's tomorrow. You'll have to search your schedules for that. But you can check in. I like these where you're seeing the same customer coming back, the same member of the community coming back and reporting out. Want to move forward, though, is one of the things that comes up a lot is SLO or service level management. And a lot of the ephemeral applications that you first start out on have no SLA expectations. As we start looking at the crown jewels, and Pete mentioned that already a little bit with what is expected in SAP style of application, I'm curious about can we be hosting those kinds of apps and some examples of where you're seeing those kinds of apps being hosted? And I know, Reddy, you've looked a lot at the SLO management aspects of OpenStack. If it's in, you want to give us a start on that one? Sure. So if you were to look at the, in my opinion, your infrastructure is not going to be uniform. Your applications are not going to be uniform. So if you were to look at your infrastructure, you're going to have a wide variety of compute nodes with all kinds of combinations and combinations. And if you were to look at your storage, you may have scale out open source. You may have scale out proprietary. And you may have the SAN and NAS scale up appliances as well. If you were to look at just the infrastructure itself, if you were to assume that it is uniform, it is completely a myth. Then on top of it, if you bring in the workloads, workloads are not going to be just a uniform set of workloads. You are going to deploy wide variety of workloads. I call them as a blender effect. So if you have wide variety of workloads that are actually deployed on OpenStack, you essentially need to have some way of managing the quality and partitioning the workloads and dropping the workloads on the right infrastructure that can actually service the workloads. So for example, if you were to look at just a brute force way of doing, I can create a volume. And I can create a volume across the board on any one of the storage appliances. But why would I buy a very expensive flash array and I put a workload that it does not really require? Ideally, you would like to partition your infrastructure based on the quality of service that it provides. And you should be able to deploy the workloads based on what the workload requires as opposed to a very brute force mapping process. What it gives you is, one is it actually addresses the application performance requirements. It could be in the performance reliability, availability, all kinds of attributes associated with it. Things like how many I have, what I want, and what could be the throughput I'm looking for for my workload, et cetera, as well as optimize your infrastructure capacity. So having rich constructs to explain what your workload requires as opposed to what infrastructure capacity you want on which node or which appliance you want to create is the stuff that we really want to move away from. So describing the workload requirements using service level objectives as a way to meet your SLAs and then having that intelligence in the middle, which is what I call software-defined infrastructure, software-defined storage is one of the critical building blocks in it, to be able to carve out the resources and allocate the resources much more intelligently, to meet your application requirements as well as optimize infrastructure to reduce the cost both on CAPEX and OPEX. That is the key, to be able to move into the enterprise workloads for OpenStack. Anyone want to add anything to that? OK. So I fully agree with what you said, but in addition to the capacity of expressing the requirement of a given deployment for its storage, you also have with OpenStack the ability to define complete stacks that will integrate various components which may require different types of storage. And the expression of the complexity, whether it is expressed with a variety of Docker containers or within a heat template, and the capacity that we have to link some of it to a very fast Manila back storage, or to a fairly slow object storage, or to a medium open source, very scalable storage. Depending on the type of component is also the kind of thing that the user expect. They want their app. They don't want to know what backend needs to be suitable for MySQL, or for this other database, or for the shared file system. And hiding the complexity is what the APIs that we are piling up is giving us. And this API having the ability to access different service classes is really the key to success. Yeah, I would just add to that, and it goes along with the baby in the bathwater, is a lot of our enterprise customers look at the journey to OpenStack as being a relatively risky one. They're looking at completely restructuring their entire data center infrastructure around a new set of APIs, around a new set of a way of delivering services to the end user, which typically is a line of business who pays the freight. And I think quite honestly one of the things they're looking at is how can I de-risk that journey. And so the first step is let's not throw out everything. There are some things that work pretty well. There are some things that are solid. And there are some things that I know aren't going to lose my data because they haven't lost my data for the last 10, 15 years. I'm not sure that when I go on this very risky reconstruction of my data center that I want to bet that much on the data. So I think it's not necessarily being risk averse. It's just recognizing what's the value of an enterprise storage solution and what it can do for me as I move into this new infrastructure. Thanks, Pete. So that was very well covered. I don't know if I think that. And you've actually even touched a little bit on the next question I was going to ask. But I want to see if there's anything more you'd like to pull out of that is how can enterprise storage features that are there provide capabilities that open stack alone by itself can't get to? And I know, Manu, you've been around this industry for a long time. I thought maybe you could take us. Sure. So the way I look at it is what open stack is allowing you is basically giving you the flexibility to apply to your workload the characteristics that workload needs. And in open stack, for example, there is a way where you can specify that for my, let's say you are deploying an Oracle workload, you can actually specify the cost capabilities of that workload. And the way you do it is using the extra specs. So that in some ways allows you to exploit the enterprise capabilities of a back end array that is probably or may not be provided by, let's say, an open source storage software. And a lot of, since I've been like Jeff said, I've been in the industry for a long time. Providing cost capabilities at a volume level is not easy. Like I said, I've been in the industry 24 years. It's taken a long time for the industry and for the enterprise back end systems to at least provide that capability today. And you can actually leverage that capabilities from these enterprise arrays and percolate it up to your applications. So you can now, if you have multi-tenancy and you want certain workloads with certain capabilities for throughput and bandwidth and priorities, you can actually request those parameters. And if the back end array provides that capability, you can now extend it to your application. So this is where I see open stack, the marriage between open stack and the enterprise arrays today has a useful outcome. Yeah, I totally agree. While there is active effort going on in enabling the enterprise array features all the way to the top tier to be able to actually deploy your applications, I still think there is a lot more work to be done in this area. For example, you may have extremely advanced replication technology. You should be able to bubble it up and you should be able to consume that. I would not say that the enterprise plumbing and features that are available in open stack today are complete by itself, but we are definitely on the right path. I wouldn't say it is end, but it is the beginning of the journey. Right. Anything else, dad? The only thing I would add to that is really it's the basic blocking and tackling of it all. I know our chief scientist talks about 25% of the code that we work is to make inherently unreliable drives reliable for enterprise applications. So that's just stuff that you don't even think about and the testing all the corner cases. And there's a lot of thought. As I want to mention, there's many now decades of effort that have gone into specifically tuning on that component. And that actually goes back to the baby in the bathwater kind of idea as well. So there's things that I guess should not be taken for granted as you move along. And I think just underline this at that same point. So I want to actually ask the audience here a question. And we're all here. We're here, I think, for the same reason, to contribute, to learn, to make new partnerships. What are you all finding is, let me ask it so we can get a show of hands. How many of you are finding some resistance when you go back to your organizations regarding OpenStack and having OpenStack adopted in your organizations? That's great. So everybody else is smooth sailing. And we're just in pure execution mode. So it was tougher in the beginning. So if you can't hear the response, but some of us haven't got far enough long to know yet. So you haven't hit it. Actually, I should have kind of asked who's in the audience a little bit. So how many of you are from enterprises and you're looking to use OpenStack? Pretty good number. And how many of you are on the vendor side? A little bit more. And then how many of you are developers? OK, pretty good mix. Kind of like the OpenStack community. So OK, great. Just what are you guys finding when you go out and talk to your customers? Where are we on the maturity curve? So the clear answer to that question is no. And I think it's quite honestly a lot of the enterprises that we work with have built up these silos of expertise. So you have the storage silo. You have the networking silo. You have the compute silo. You have the Windows silo, the Linux silo, whatever. And that goes back to one of my comments earlier, is that one of the ways to get around that is you tell the storage guy, don't worry. OpenStack will work with your vendor of choice for the storage area network. So again, as opposed to telling somebody you have to rip out everything and start all over again, you can at least de-risk the option. And we've had customers that actually have started down the path of doing OpenStack, not with us. They've started down the path and then run into problems. And the first thing we actually help them go through is how do you get everybody in the organization lined up, because OpenStack is not just compute. It's not just networking. It's not just storage. It's everything and it completely touches how you do business once you've deployed it. So having enterprise storage that the storage guy feels comfortable with is important, just as it's important to go buy and get buy in from the networking guy that the way you're going to deploy this is going to comply with their existing policies and procedures. So I don't know if you intended that, but Alexi, we're sitting right over there and I are doing a session called, don't change my mindset, I'm not that open. And it's just about how do you go across deploying OpenStack in an organization which by nature will be resisting to change? All organization has this natural resistance to change and we've got to deploy treasure of imagination to go against that, touched on a couple ways to change that. And the resistance can happen at many level. It can happen at the guy handling the storage area network to the application developer that certainly doesn't want to have anything to do with reliability of his application to the manager that is used to give order in a given way and the fact that now there is an API he has no more order to give. All these guys are going to be resisting and you've got to find a way to go around this resistance and that's what really makes the project fun because without that it would only be technical and technical is fun, but only for a while. Let me share my experience in the manufacturing guy as I introduced myself in the beginning. I worked in manufacturing. I have seen the evolution from running a factory completely on bare metal to a virtualized infrastructure but the storyline goes like this, right? So you are actually running everything on bare metal. How would you go actually transition an organization that is completely focused towards high reliability, mission critical, nonstop operations and move towards an infrastructure that really gets you flexibility, right? So on one side it may give you the flexibility but on the other side your business priorities are completely orthogonal sometimes. So you will have to kind of strike a balance between those two. So typically my experience has been with my customers that I normally deal with. You cherry pick essentially the place where you really want to start off. You normally don't go and say, hey I'm going to take OpenStack, put it in production workloads, my line of business type of workloads and see what happens, right? That's not going to happen. You typically start off with something that is low risk where you can actually show the value prop. Get the organizations into more of move into the culture of how you kind of train them with DevOps type of mentality with OpenStack, it's open source implementation, the stability aspects and the whole team coming and understanding the aspects of how do you deploy it, how do you maintain it, how do you sustain it. All those things will need to be organically grown as opposed to a disruptive way. Typically you start off with something that low risk and you kind of slowly go into tier two workloads, tier three workloads where you really are running the line of business apps. It's the change is not going to happen overnight but you want to start somewhere and I have seen with most of the customers, they start with low risk, low profile type of workloads, show that you can really make it happen and then start actually deploying the other ones, right? So that's one element. The second one is if you look at enterprise, it's not like you have one data center, you have one portfolio of applications, you deploy OpenStack, everything will work seamlessly. You have lots of these org boundaries as well, lots of support boundaries, lots of QA boundaries. You are not going to see one OpenStack instance that is deployed in a data center, you're going to see many of them. My recommendation is start small, look for low risk, high visibility type of opportunities where you can add value, show value and then move from there. So in my experience, I've actually met the spectrum. Some people that don't know anything about it but would love to learn what is OpenStack and a part of it I felt is evangelizing this notion and as soon as you relate that they can create environments like Amazon and Google, they get extremely excited about it. Then there are of course other people in the middle that I've met that know a little bit, have tried. Some of course, it's appealed to them, the challenge has actually appealed to them and when they found out, oh, I can do this myself and I don't have to rely on a third party software, it's really gotten them excited. And some, I was like, no, can you put this in an appliance and send it to me? And so, you know, with HP, everything is possible, right? And so that approach appeals to them and then I've met the extreme on the right hand who love this product, have actually put together an entire business unit that is actually working on open source, OpenStack products. So I've really seen this spectrum and I think what I've taken away from this spectrum is that OpenStack is, I don't know how many of you, it reminds me of my early days and now you know my age of course but when I was doing, at IBM, I was doing the virtualization product and the idea there was that, you know, hardware is gonna get commoditized, dollar per gig is gonna go down and the intelligence is really in the software. So let's take the software and build virtualization engines that can do all the functions of what multimillion dollar arrays can do. And then people would say, well, why should I put this thing in the middle? You know, it's only gonna increase my latencies and we had to do a lot of evangelization but it was innovation at that time and I feel the same way with OpenStack. People are still learning about it. There's a lot of power in it. Those that can see how they can extend this flexibility and create that environment are getting extremely attracted to this and some of them have already learned the power of OpenStack and are actually using it and developing their own insight or are going after companies that are already established and putting it in for them. So again, my range has been a spectrum and I'm really excited to see and I think looking at the number of people that attended this conference more than what were at Paris, it really tells me that we are on our way to something really cool. Yeah, certainly right. So another thing we hear on this topic is, yeah, it's not about free but it's about the freedom to build what you need to build. So another way of looking at that though is there's the potential for decision paralysis and we have, you know, the choices are mind-boggling and a lot of times I get this question is so, where do I start? In fact, I just walked out of a meeting with a customer and that was the kind of where we started was what do you recommend? Where do we go? And how do we get started? So I'm curious what your experiences have been around decision paralysis? How do we make it easy? Are there best practices? How can we simplify this so that it is more consumable? I know that that's a major theme across but since I have these experts here I wanted to hear from you all. So we've actually been shipping an OpenStack distribution since Essex. We're on our fifth release currently and we've actually been shipping Ceph as part of that as well as Swift since the beginning and it was exactly that point. In the Essex days, NetApp was about the only option for backend storage other than Ceph and so we had some customers that quite honestly, much to Jeff's chagrin were not NetApp customers so we didn't really feel like we had to go tell them they needed to go buy a NetApp array if they wanted to use Nova and Glantz and things like that but as people have bought into the notion that you want to have the flexibility and the vendors have participated, they now have pretty much, if you're using HP, you're using IBM, you're using Hitachi, NetApp, EMC, whatever storage array you're using today, you can take advantage of that as you start going down the path but you may have some tier three data that you're fully comfortable with putting it on something like Swift or Ceph that doesn't necessarily have the same performance and performance parameters that you get with your existing storage array so I absolutely do think that the way that the community has reacted has been very positive and quite honestly the array vendors could have said, we're not gonna play with this stuff because it's potentially disruptive to their business models but they've all stepped up, they've all participated, they're all trying to figure out how they can provide the same level of feature functionality or provide their feature functionality in a way that's consumable by the OpenStack consumer and provide that kind of flexibility. I think there is, I've been expressing that in other summits that there is a somewhat of a closed link between the transformation that needs to happen when you deploy an OpenStack cloud and agility. So I've been using over and over again in order to define what is needed at the technical level, a technique which is to get to understand very precisely what are the requirements, what are the use cases that someone needs to implement before making any recommendation. And by driving this from top to bottom approach you are making sure that you're not missing on the actual business reason why you will want to run OpenStack and this is really the key. If you're not focusing on what is going to be the end result, what is going to be the output of the wonderful factory that you're building based on OpenStack, you're missing the point. And therefore the freedom that we have below is to support the output that we want to produce. And once you've got a good vision of what's the business case, what's the output that you want, I think the choices just fall into place. Yeah, so I don't know if, to me it is more about a choice, right? So the fundamental thing as if I were to consume OpenStack, a couple of things actually come out very strong. One is the, it's about choice and it's about on demand deployment of your infrastructure. Now the next question is going to be what do I have that is already deployed? Can I actually take OpenStack and integrate the existing solutions that I already have in my data center? If it is specifically within the context of storage, I may have NetApp filers, for example. I may have EMC stuff in it. Can I actually take the plugins and can I actually integrate those systems and consume them without actually doing a lot of acrobatic work? So the key is that the distros, OpenStack distros cannot be biased towards I have Swift and I have Self. But in reality the enterprise customers are looking for, I have already invested significant amount of capital. My enterprise workloads are running on the higher end, high mature platforms and storage infrastructure goes along those lines. I need to have a way to manage them as well. So it cannot be skewed towards just open source only top to bottom. But it has to be more of opening up the innovation across the pipeline. And specifically on the distros, what I see is there is a trend. If you were to look at Mirantis that had distros, who said distros, you will see all these plugins emerging, which is an extremely positive sign in my view as a way to consume the existing investments without actually doing a whole lot of work and heavy lifting, which is key to drive the implementations for the enterprise adoption. It's a simplifying. Exactly. Simplifying is extremely important. I think someone was making the comment in the conference and you don't need a PhD to manage OpenStack. You've got to continue to tone it down to make it more and more usable. It's not about making it usable. It is also making it highly integratable as well with the existing infrastructure to be able to consume for enterprise. So actually if you look, the word freedom actually encapsulates free. But I think it's more about free and the domain that you're going to manage and the freedom it gives you, the powerful message that one customer relate to me was, if I'm going to use OpenStack, can I build my own applications? Can I actually manipulate the software in the way I want it to go and in the direction I want it to go? And the answer is yes. So what OpenStack is lending to the user is the ability for him to manipulate the software in a manner that can meet his needs. And it's really about understanding what is your use case? What is the pain point? Is it allowing you to leverage the infrastructure that you have? And the fourth important key aspect that I've observed is that it allows you to work with your commoditized hardware. And so I think the people do see that it gives them an ability to use OpenStack to create new innovations. And to me, that is the power that OpenStack is actually bringing to the customer. Thanks. You know, that is. So what I want to do is point out two things on to this last question. We're now shipping, or we'll be shipping in the near future, the FlexPod concept with OpenStack built on top of FlexPod, which is a simplifying assumption. I know, Manu, you mentioned that HP has a similar capability. So there's choice at that of integrations. I'd also say that we have, with SAP, built on top of, Sue say we have application stacks starting to build out and having that kind of simplification as well. So with that, I'll finish. Are we there yet? I'd say we've got a ways to go, but we're well on our way. So thank you for your attention and we'll see you around the show. Thank you. Thank you.