 Thanks everybody, I think we'll get started. I think the lesson from this is you snooze, you lose. When Mark Collier doesn't show up for his own panel, I guess that means that whoever's in the sport gets to take the moderator seat. So here I am, welcome. So yes, this is the software defined storage panel. All that software defined storage. Just to give you kind of a bit of background about software defined storage. If you look at the past decade, decade and a half, in the data center, there's a very clear bias towards a few specific trends. Trends around open source. Trends around virtualization, automation, agility in the data center. But in all these trends, there's a very clear open source bias. And you saw this manifest itself in the first place on the platform level and the virtualization level on the compute side. And the storage side has been kind of lagging. You haven't seen the same level of movement towards virtualization of storage. But over time, even that has taken place as the economies of scale that present in the data center take hold. And now we see it in storage as well. And now we've come to, you know you've arrived when there's a term that defines what you do. In this case, it's called software defined storage. So what we're gonna do is announce, I guess the panelists will introduce themselves. So I want you to tell who you are, who you work for and why you are on this panel. Let's start at the far left. Let's start with Awadi. Hi, I'm Anand Awati. I work for Red Hat. I'm the lead architect for GlusterFS and also the lead contributor. So I'm here because I work on GlusterFS. My name's Sage Weil. Founder CTO of Ink Tank. And I'm one of the chief architects and original creators of the SF distributed storage system. And I'm here because I just found out about 20 minutes ago that I'm apparently I'm on a panel and nobody told me so. Somebody got me in downstairs. Did you say you're one of the chief architects of stuff? I guess I'm the chief. I don't know. Okay. I think you're being a little modest there. That's okay. That's me. My name is Joe Arnold. I'm the CEO and one of the founders of a company called Swift Stack. And we do open stack Swift, the object storage system and build a product around that. I think the reason why I was at this panel is so I put a book together called Software Defined Storage with Open Stack Swift and we're gonna be giving away some copies tomorrow during lunch. Autograph copies. If you want. So we have the guy who wrote the book on Software Defined Storage. I think we can all go home now, right? Yeah, and then we're gonna tear apart the term I'm sure through this session. My name is John Griffith. I work for a company called SolidFire. We actually do a clustered storage appliance that's actually designed specifically for Software Defined Storage. So I have some maybe different or maybe similar views about that. So we'll hopefully get into that. Hopefully, yeah. I have not written a book, but I'd be happy if you want to buy one. I crank one out tonight. Did say give, get kind of an idea of where you stand with cloud storage in general. Raise your hand if you are an end user or operator of cloud storage. Sorry, yeah. Operator, deployer of cloud storage services. Okay, fair number of you. How many of you are developers that work with developing apps that use cloud storage services? Okay, and how many of you are here just because you're interested or you're blogging or you're pundits? Fair enough. Some of you raised your hands for all of those, isn't it? Okay, I just wanna get an idea. So let's start with that. Let's define what it is. It's great that we can say we're converging around software-defined storage, but what does that actually mean? And you get that when you look at announcements over the last few weeks or months, you can see lots of companies are now jumping on the term software-defined storage. And does it actually mean the same thing depending on the origins of the press release of whoever is making a particular announcement? So why don't we start with our illustrious panel, or esteemed panelists, and see whether there are any differences in their definitions of software-defined storage. Who wants to take the first crack at defining it? What is it? Can we say for sure? You asked for that, sorry. I asked for it, okay. So for us, it's about decoupling the software out of that physical hardware and putting it onto systems that just run that software and push data to physical drives. And I mean, we're just to kind of bring the point home. We're like, we start working with Seagate on this kinetic drive platform, and you plug it in and it's an ethernet drive. And what that means is we can have compute nodes, and all it is, or sorry, storage nodes, and all it is is hard drives. And then you have the storage part, the storage application, in this case, Swift, is just running in on compute nodes. And that's a complete decoupling of the software from the storage hardware. And I think that's kind of a manifestation of what software-defined storage is. I mean, we think that there's also, there's some control elements and access elements that we'll probably get into a little bit later. But that in my mind is what software-defined storage is. But that, I wouldn't call it a decoupling, that's more of a coupling, isn't it? I mean, is it more of a convergence of hardware and software, and now it's like... Well, I mean, it's no more different than writing blocks down into a drive, right? That's, now there's an OS already on your drive that's able to suck in blocks, so what's the difference between sucking in objects? True. So that sort of begs the question, what is software-defined storage? That's a really good, exactly, exactly, all right? So maybe I should have written the book. So in my view, in my opinion, there's a big difference between the device and the actual product that you're using versus software-defined storage. Software-defined storage to me is about the management layer, the control layer and stuff like that. It doesn't really matter what your product is that you're using to an extent. The point is, software-defined is a pool of virtualized storage resources so that you can go ahead and manage that, select it, deploy it, everything else. That's kind of the big thing in my mind. Fair enough. Any opinions on the other side of the panel? Sure. So I think in my mind, you have sort of the, the high-level storage interface that you're presenting to users, the actual storage service that you're consuming and the high-level requirements are things like availability, performance and reliability. And then you have systems that are built out of, obviously, low-level building blocks like disks, but they don't provide all those things because they can fail. And so you have all the stuff in between that's essentially creating all the value in your storage system, that's managing the replication and the performance and the data layout and so forth. And typically in traditional devices that you buy, this is all packaged up in a nice piece of tin with some logo on the front and is ridiculously expensive, even though it's built out of commodity components. So it's that sort of middle layer that's providing the real value in the system. And so in my mind, what software-defined storage means is that you can deliver that value, you can build a system that actually handles all that complexity of reliability and replication and so forth, but you can build it out of any building blocks that you want. Because the system really is built out of software, but as we move into sort of the new world instead of having to buy a monolithic, proprietary platform from different vendors, we can use open-source software and we can deploy systems that have, deliver that same value on any hardware. So I think a piece of that is gonna be the sort of the management layer that you can manage these systems with generic APIs and so forth. But I think that's really just one piece of it. I think the other piece is that the value in the system is hardware agnostic. So you can run it on top of the kinetic drive, you can run it on top of SATA drives, you can run on SSDs. But it's really that the software that's defining that value and delivering the system. Isn't that more software-based? Software-based storage. Yeah, I mean, storage systems are software and hardware, right? So I think software-defined storage is kind of a nebulous, kind of useless term, honestly, in my opinion. Yeah. Yeah. So I think for me, I think what the real, I mean, people have sort of glommed onto this term, software-defined storage, but I think that the real transition that's happened is they've realized that the value in their storage system is the software. And it's no longer the old world where you had to go, go to NetApp, and it was some secret sauce that you would just buy. Whereas today you can go, you can buy, get Gluster, you can run SAP, you can run Swift, you can run all these sort of open platforms that deliver that value, but you can run it on any hardware that you want. So what do you think there is a movement towards this software side of things? What's the value in it for the end user, for the customer? What, why is this, you know? So I mean, it's things like escaping vendor lock-in. It's things simple, it's the simple cost advantages. I mean, I think they're adopting it because they have to, right? And that's, yeah. I mean, we look at like Marketer Libre is in the audience right now, and they have to deliver a ton of images out to their customers to support their auction service. And the only way they can really do that to build up a system that can scale and they can manage it is by using something that allows them to overlay their infrastructure with another interface that is presented to the application. And I think the driving force behind this is really how applications are, the nature of applications are changing or seeing much more software as a service applications out there. And that consolidates the amount of storage that is needed in the data center just to support the concurrency workloads in the storage footprint. So I think there's a lot of, well, we have to change it because scaling silos for that type of data assets just doesn't work anymore. So then do you think it's fair to say that without cloud workloads and big data workloads that the whole software defined storage thing may not have been such a high priority for brand users? When you start having a petabyte cluster and suddenly you're measuring, let's say you're like, who uses Evernote, right? Okay, so when they started building the application, I mean, they home rolled their own storage system. And this was like, I don't know whenever they started their online service. And they did that because the pricing model that they had for their customers of subscription rates didn't allow for them to buy anything else. They had to do something that was outside of the norm. I always say that it's not necessarily how big your data is, it's what you can do with it. It's like data in place, just because you can store a lot of it doesn't necessarily mean anything. It's about whether or not you can actually put it to work and doing what you need to do to feed your services. It seems like the scaling is really a forcing function. So I think there's a correlation because it's easy to ignore a single expensive thing, but at the point where you're scaling you suddenly have a thousand expensive things and that the cost effectiveness of your solution becomes very apparent. Okay. Well, yeah. So I'm gonna quit making jokes about the different stuff, but I wanna go first. So the thing is I think we're kind of mixing kind of what we're talking about, right? Are we talking about software defined storage? Or are we talking about software based storage and open source storage and things like that? They're not the same thing? No, they're not the same thing. They're very different discussions. The thing about software, you know, and again, maybe my opinion is different. I couldn't tell, you know. I'm the moderator. I'm not supposed to have anything. Right, that's right. So the thing is from my perspective, what you're, again, like I said, what you're talking about is you're talking about deployment and management and things like that. You know, Sage, you had talked about vendor lock in and things like that. Well, that's kind of the beauty of software defined storage, right? So the idea is if the products that are underneath are granular enough and virtualized enough and robust enough, you can put whatever you want back underneath there. You have a common API outside. You have that virtualization, that deployment model and everything done outside. So it's basically, it's more of an abstraction. The key, though, is you have to have a device that will actually let you do that and give you the features and the granularity and the control and everything else that you need to actually do that. That's the hard part, in my opinion. I mean, that's, what do you want to say? Yeah, another, a few of the common themes you would see in most of the software defined storage, what we're seeing. One, as he already mentioned, it's the scale. I guess if our data sets never grew large enough and wouldn't fit in the same box, we would probably not even be talking about such a field. Pretty much every software defined storage system is a scale out system. If you're just talking about things in one box, there are, I mean, why make it software defined storage? It's only when the scale grows so large and you need to deploy so many of these. You look at things like using commodity hardware, taking away the logic from one appliance and implementing it as a piece of software. And that's when you also have this other correlation with respect to most of them being open source because now that everything is software, you can have a community around building software and the open source model has proven to be good at building software systems more than building an integrated appliance. So I heard two things there. I heard one, that software defined storage implies scale out architecture. And I also heard that scale up architecture does not necessarily necessitate the software defined storage overlay, any opinions? I have an opinion on that. I think that's properties of the storage systems, not necessarily properties of software defined storage. I mean, I think the model that we've chose is more of the eventual consistency model, which gives us the ability to do things like asynchronous replication across multiple sites. It's a very different, it's hugely different than what you guys do. I mean, it's just completely different workloads, but are we software defined storage and you're not? Just because, I mean, it doesn't, I think there's gonna be storage systems and they're gonna be software and they're all gonna have different properties. The reality is every storage system is software based storage or whatever you wanna call it. Every storage system, whether it's open source, proprietary or whatever, it's software. I mean, they're all, it's all software. So it's kind of a silly, it's kind of. Well, what constitutes non-software defined storage, I guess, but in my mind, well. In my mind, the definition is usually the proprietary black box, the combined stack of hardware and software is usually what is the counterpoint to the modern software. So I guess the thing is, as that goes back to where I started, right, is the product is not software defined storage. That's not it. Software defined storage is a concept, right? It's software as a service, networking as a service, compute as a service. So from my viewpoint, the way I look at it, right? Cinder is software defined storage. None of us sitting up here in what we're talking about, in my opinion, are software defined storage. We develop products that are better or specific for software defined storage, but we are not. That's not software defined storage. That's what my position is. Okay. Any audience questions or, yeah, you in the back? That's kind of my take. I don't know if that's necessary. I think that. Yeah, when you say like software abstraction, that's kind of how I think about it. I mean, that's the way I certainly have that opinion. So we'll take a box, we'll put Linux on it, whether that's Red Hat, CentOS, Ubuntu, and then the drives will slot in there and we'll manage those drives and then present an object storage interface out to the storage user. And so if someone slots in storage from a different manufacturer and it's slower, then we'll put less data on there or less user requests on there. If it's faster, we'll put more user requests on that and that's just kind of a function of how this OpenStack Swift in particular works. Damian, I think you're looking at the, like a group of panelists that have those types of products, right? I mean, we all have our respective products that. Yeah, you see companies popping up all the time that you could call white box vendors that slap on software on top of it and sell it. Yeah, and the ones. It happens all the time. I think a good thumb rule to check if a given solution is a software-defined solution or not is whether you can run it on absolute commodity hardware. If the solution requires some form of very specific hardware, if it has a dependency on a hardware from some vendor, that by definition kind of disqualifies it from being called a software-defined storage. You need to be able to build it. Typically, they are scale out and you need to be able to build them from commodity off-the-shelf components completely. You can choose to use, you know, 15KRPMs, 7200RPM SSDs depending on your performance needs, but the service what you deliver should be mostly agnostic to the specific hardware itself and should just exploit the available. That kind of gets into tiering, which I want to get into later, but you have a, wait, hang on. You have a response to that? Well, no, I mean, I'm not Seagod. I'm Swistak, right? So we just happen to be working with those guys, right? But, I mean, I'm just talking about some of the future technologies coming out in the roadmap ahead, right? More than, like, this is the only thing we run on. But I would agree that it's important to be able to install on a lot of different hardware platforms, but reality is we get out into the field, it kind of gets important what kind of hardware is the stuff is running on. And to that end, I think all of us will make recommendations for, here's a recommended hardware that you should use. Like, we're working with Intel right now on a set of workloads, and then what kind of hardware you need to support those workloads. And so it's not like it can just run on any old Jbods. In fact, sometimes the storage is not a Jbod. That's not enough power to really run a storage system because you need a lot of compute capacities to do what Sage was talking about, run around the failures, because hardware, when things go bad, so it's not just any old stuff. Can I ask a sort of, I know this is not a rhetorical question, but a question, when people are talking about software-defined networking, and what is the difference between software-defined networking and virtual networking? Or could you just say that software-defined, these services are really providing virtualized networks? Because that, is that sort of a valid comparison? Well, I mean, I think with software-defined... You're shaking your head. Software-defined, like... I'm a neosothole when it comes to networking, but I'm just trying to... Yeah, control. Or control over the network. Yeah, yeah, correct. And I'm not saying that in this definition, but I think that's... Yeah, that's the type, we have a whole product around control of the software-defined storage system, right? So Swift will just run and do its thing, but our opinion is that you need to have a controller that goes in and manages the data plate, like tell, hey, there's new capacity in the system, go take advantage of it. Hey, there's new users, go provision them. Things like that, we think comes from a controller component. Okay, we're getting a lot of questions from the audience now, so you and you and then you, so you first. That sounds like the perfect question to end the panel on. So I'm gonna save that one for the very end, if you don't mind. I can tell you what we do, or what we don't do. All right, so you had a question back. Sure, and then that begs the question of, is it just the API or does the API define the storage, or is it more than that? So I think that's a good question, I wanna open that up to the panelists. I think it's, I think there's sort of two things that we're talking about here, and one of them is this generic API control layer that you use software to orchestrate storage. And because you have, this is what you're talking about, and if you go read all the propaganda around, not propaganda, whatever, the press around EMC's Viper, for example, this EMC is a very traditional, like enterprise storage expensive array, and the Viper layer is really just about configuring the traditional storage layer. So I think that this is a very good thing, I think in general, having software control and orchestration and so forth. I don't know that I would call it software defined anything, I would call it software orchestrated storage perhaps. But then there's a totally separate sort of discussion where you have systems like Swift and Gluster and Seth that are really saying that the storage system itself, the smarts that actually make it useful, that virtualize your storage services from the hardware that's underneath, that that's really changing the face of the industry and so forth. So I think, and that I think is something, it's a totally different thing than orchestrating storage, it's open. It's the data path versus the control path. So I'm gonna go out on a limb and say that as soon as you start talking about software defined X, it's really a lot of software defined bullshit. And that you're gonna be better off if you, I think honestly, I think the community and everybody, everybody wants to say that their X is software defined storage because they can sort of piggyback on this term. But I think we'd actually be better off if we had like sort of more precise terms that describe what we're actually talking about, whether it's software orchestrated storage. You want clarity in marketing, right? Wait, wait, wait. But what you just did was actually just muddied that whole definition even more. I mean, you just took something like software defined storage as, like I said, I use the example since we're all at the OpenStack Summit, right? Cinder as being delivering software defined storage, which I think is pretty reasonable and there seems to be a few people at least that had that when we talked about networking and things like that. But now what you're saying is you're taking it back down to the product. So then I'll go back and I'll say, well, my product runs on commodity hardware as well. And then we just put software on it. So we're, by your definition, then we're in the club too, right? So what I'm saying actually is that because of this confusion, I think we should stop saying software defined storage, but we should use a different term that is more specific. For which one though? For both, honestly for both. I think that we should say software orchestrated storage. It talks about things like Cinder or Viper or storage as a service. I think that it's clear what you're actually talking about or SaaS. And then when you start talking about these, these open source architectures that are run on commodity hardware, you can sort of plug in any storage underneath. Then I think you can, I don't know what the term for that is. That's my opinion. Well, I think even there is some confusion because in my mind, when I think software defined networking, I'm thinking about people defining a virtual networks and then that being tunneled through various technologies on commodity switching infrastructure. But other people, to them it's a common API that then configures their storage hardware to do the same thing but in hardware. So, yeah. Well, yeah, I'm ignoring the open source piece, but I'm saying it's almost virtualized versus the API. Maybe. Maybe I'm in there. So you think in terms of that? I'm with you. You think of the control and orchestration API is what you're thinking. Okay, sorry. I did too by the way. Do we have a question over here? Okay. I think he's chomping at the bit too. I'll try and be quick. So from my perspective, I think the big thing that drives it is automation and management period. The reality is there's vendor lock-in, that's an issue, management, APIs, automation, all that sort of thing. Managing storage is not fun. It sucks, right? So if you can abstract that out and have it software defined, it's great. The other thing is you can do things like if you have a device, an array or whatever, and it is completely full and you need more space or whatever, it doesn't matter because if you have software defined API control, you can go ahead and just deploy a volume somewhere else. And it doesn't matter. You can keep adding devices. You can scale it horizontally. So that's my take. So to your point earlier, if I take some basic file system, some white box and a couple of hard drives and I install XFS on it, is that software defined storage? I mean, you would say no. And I would kind of say no as well. But what's the difference between that and some of the other things we're talking about up here? I mean, it seems like there's a... Yes? Well, that gives us back to your original question about what are the limitations in our products? Okay. I think the point I was trying to make is it's just we're all gonna have customer, like within OpenStack, like OpenStack object storage, it's serving the needs of, for that use case, right? And so some of those features are gonna be unique to that storage system and we're all gonna have different types of capabilities and different APIs and we're gonna get consumed in different ways. And I mean, that's gonna be the difference between I think all of our different takes on what software defined storage is. Yeah, I mean, I think if we wanna double click into the technology, how it works, I mean, like Thursday we'll do the thing on global clusters with Concur, for example, and you can hear about how that in particular works, right? But I think that's my point is like everything's gonna, every different storage system has different properties to it and... So if we wanna get into sort of like what the individual pieces do, why don't we take turns on the panel and talk about what each of us work on and how it delivers software defined storage and what it doesn't deliver as far as part of, in answer to your question, but also adding in the part of how do you deliver software defined storage and then what are you lacking? Why don't we just go from left to right and the... Okay. Sure. Do you wanna add that into your... I guess we are, at that point we are probably kind of... We have four minutes, so whatever it is, let's, yeah. We're probably overlapping with the abilities of a particular solution, but I guess part of the value of pulling things out from a specific appliance and into the software layer is that you get all these benefits of flexibility, automation, things like that, should be, I guess it's more expected from a software defined storage system to have those abilities. But then what are the limitations of, as far as the project you work on now, what does it not do, I guess, in this area? Well, I guess there are a few things which are in our roadmap. For example, one of the things which is not there in Gloucester today, but is in development, is active, active geo-replication. We've been able to do unidirectional geo-replication to scaling out geo-replication, cascading geo-replication for nearly two years now, but now we're adding the ability to do bidirectional geo-replication with policy-based conflict resolution. So in a way, being software, having everything in the software layer, one would expect us to deliver such features, which is not there yet, but is coming down the road. Okay, we need to roll through the panel. So I guess the project, obviously, I work on this stuff. I think that the key value is really in being able to scale up and scale out. As you need more storage resources, you just deploy more disks and sort of add them into the storage pool. I guess the way I would describe that is either virtualized storage, where you have a virtual disk or something and you're deploying racks of storage and all the replications and so forth is handled. That includes scale down and so forth. I don't know if you call that virtualized storage or whether you call that software-defined storage. Honestly, I don't really care about the terms. I think that the sort of the second piece that we're talking about here is having this sort of generic API orchestration layer, and I think also that's tremendously valuable. Don't get me wrong. I think it's difficult for any particular vendor to say that I deliver a generic API that can manage lots of different source or systems. But I think that both are very valuable, so I don't care what you call it. So Swift is good at high concurrency, high durability, it's architected for availability. It does not do high concurrency, or sorry, it doesn't do strong consistency. So if you wanna run a virtual machine on it, you don't do that. If you have a lot of data to store and you have a lot of transactions to send data in and out or you have a globally distributed footprint, it's a good model for eventual consistency and that's what Swift is specifically designed to deal with. So with the confusing definitions, I guess I'll talk about Solid Fire's product and what it does. So we are scale out high availability, virtualized block storage. It allows you to do things like set quality of service on a volume per volume basis. We have multi-tenancy awareness, things like that. So from our viewpoint, when I go into that definition that I gave of software defined storage, that's why it's a good fit. Things that we don't do well, I don't know. So we're a new company, we're a startup. So we've got growth and we've got things on the roadmap. So there's things that we need to do, but I think the first question is to figure out exactly what we're defining here because it's hard to really speak to it with that note. Okay, so on that note, how many of you think that software defined storage as a term is a load of bunk? Like there's nothing to it, a bunch of hype. Is that the takeaway lesson from today? How do you think it's actually real? There's a real substance of... There's a real thing going on. I think there are multiple real things happening. I'm afraid we didn't help define it any better than we had before. We're going from refrigerators to storage systems that we can get from a bunch of different vendors. Whatever you want to call that, it's real and it's happening. I think what Sage said as far as the two categories and stuff like that, in my opinion, that's perfect. That sums it up. And on that note, we're going to have to end it, but thank you to our illustrious panel. Thank you for coming. Thank you. Thanks so much.