 Live from San Francisco, extracting the signal from the noise, it's theCUBE covering Nimble Storage, the power of predictive analytics. Now, your host, Stu Miniman. Welcome back to theCUBE, a special presentation here from downtown San Francisco at the Nimble Storage Predictive Flash Launch. I'm Stu Miniman, happy to have as my co-host on this segment, David Fleuer, who's the co-founder and CTO of Wikibon and happy to have the co-founder and VP of Engineering, Varun Mehta with Nimble Storage. Varun, thank you so much for joining us again. Happy to be here. So, you know, first of all, congratulations to you and your team, you know, it's come, you know, very far, I mean, 7,500 customers, products doing well, and a big announcement. I had one of the analysts on today said that, you know, a couple of the sub-bullets could have made a whole announcement for most companies, and so you've got a lot packed into this event. Can you give us just a little bit of the behind the scenes, you know, how long did this, you know, project take? How many people you had on it? And, you know, really went into this big launch. Great, great, great questions. So, the project actually started over two years ago, and initially, you know, we had built the product with inline compression in mind, and for an all flash array, you know, the hard, the thing that is required is inline deduplication as well. Now, there are many mainstream applications actually are just fine with compression, you know, databases and so on, but there are some applications that are dedu, you know, hogs. They love dedu, VDI is a big one, some parts of virtual infrastructure. So, the question was, if we're going to do dedu, put in dedupe into our system, how do we make it the most efficient, the best dedu possible? So, that's what we started thinking about more than two years ago. So, the team started with just a handful of people as these projects always do, and then it swelled to over 50 engineers. And, we were amazed at that, because we didn't think that, you know, the full engineering size at Nimble is about 300 engineers. So, it took up a very substantial amount of people to work on this single feature, and it is one of the big changes that we've made to the Nimble storage system. So, dedupe was a big feature that we put in, and it was a two-year project. And, at the end of it, we were very happy, because we ended up with this really efficient dedupe. We're very proud of the fact that we have a very small memory footprint per terabyte of data that we can support on the system. And, of course, it is in line. So, we were very, very happy with the end results. Well, congratulations on the whole announcement and the whole product. One of the things that really interested me that is you're one of the first people into the 3D NAND, and you've taken it, obviously, from Samsung, which are with the leaders in there. So, why did you choose that? Why do you think it's going to take you? What did you have to do special to take advantage of this? It's really, really interesting. So, one of the reasons we chose 3D NAND is you have to use a cliched phrase, skate to where the puck is going. And, really, where NAND is going is increasing density and potentially decreasing endurance. So, you really need a file system that can deal with low endurance and very high densities. And so, we know that 3D NAND today is four terabytes. Probably, within the year, it'll go to eight terabytes. Next year, it might double again. And so, that's where the memory efficiency was very important. We wanted to make sure that the system could support expanding RAM. Now, it's really interesting. If you look at the way Flash works, there's very high grades of Flash, which are very expensive. Everybody starts with the same die, and then the manufacturers will give you different ranges of performance, basically based on over-provisioning. So, looking at one manufacturer, and I'm not going to pick Samsung in particular, there are multiple of them, but this same manufacturer could start with a four terabyte system, but only give you 1.6 terabytes because the rest is over-provisioned to give you high-right performance. So, you end up with a system that is seriously over-provisioned to give you very high-right performance and decent endurance with that right performance. Actually, very good endurance. But then, you can decrease the amount of over-provisioning all the way down to you have zero over-provisioning, and so you get for four terabytes or NAND, you get four terabytes that is usable, but you have to pay a big price for that. And the big price is your random-right performance decreases substantially, and your endurance decreases substantially. But there's one thing that does not decrease as you go from this serious over-provisioning and high-cost to zero over-provisioning and low-cost, and that is your random-read performance stays the same, and interestingly, your sequential-right performance stays the same, which is interesting because that fits with our castle technology. We do all our right sequentially, and so it's interesting that these high-right performance high-capacity, low-endurance, low-cost SSDs, actually, in some ways, are very characteristic of disks. Don't do random writes on them because that's for performance. Do sequential writes and do random reads, which is exactly how we use the system. So that was what went into our thinking behind how to architect the system. So Farun, what one of the, Suresh said one of the challenges also was you didn't just create, in all flash arrays, a standalone device, you have it so that it can work with the hybrid adaptive flash solutions. Can you talk about, can I just move data back and forth between those two types? Are there any limitations or what kind of gotchas do we need to make sure that users are aware of when mixing and matching, if you will? Right, right. So actually, that was one of the other things that we spent a lot of time on. We have put a lot of data management into our hybrid arrays. So for example, we had scale out, we had replication, we had deep integration with InfoSight, we wanted to carry all that over to the all flash array. So our hybrid array, and that's what we spent a lot of time on, and it works. The APIs are exactly the same. So the hybrid arrays and the all flash arrays can be part of the same cluster. And this is really useful because it matches how application life cycles work. So for example, you start out with test and dev and you may need a variable amount of infrastructure. For example, you want to spin up 100 test instances. You can do that very economically with a hybrid array because you have a lot of disk and the system will automatically move things to flash as you need it. Now once you've done with your test and dev and you want consistently low latency, high performance, you can seamlessly move that workload to the all flash array, assuming they're part of the same cluster. And this is great because there are no changes required on the host at all. So no changes to the host, you just move the one click, the volume moves over to all flash, and now you've got consistent guaranteed low latency performance. But again, to match the application life cycle, over time you say, okay, I'm going to retire this version of the app because now I've got a new one in development, I want to archive this. So you move it from all flash back to hybrid. So we know that applications go through this cycle of test, dev, production, archiving and the hybrid and all flash combination in a single system allows you to work in that regard. Yeah, so can you talk a little bit more about the scaling you've got, which is in my opinion, very important in this industry because obviously it's CPUs are at a premium when you're doing as much work on all of this data as you have underneath it. So can you talk a little bit more about how you share the metadata across the clusters? How do you manage it as a cluster? I presume it's a little more than just four places with a screen sharing between them. No, no. So in fact, one of the things that we're very proud of is the work we did for our cluster. So you can actually choose multiple nodes in the way we cluster. So one is where a volume lives exclusively on a specific array in the node and that's one way of doing it. So now you get all the benefits of integrated management and you get isolation. And that's probably the preferred thing to do when you have a hybrid array and an all flash array in the same cluster. On the other hand, suppose you had, you wanted as much performance as you could get, then you would take similar arrays, say two all flash arrays, and now you could stripe a volume across the two and now you would have data which is striped. Now there are issues with this because you don't necessarily want a lot of traffic going between the nodes. There are some architectures that require that, but then you have to invest in low latency switching bandwidth between the two nodes. So for example, ExtremeIO does this. They require infinite band so that they can have a lot of traffic between the nodes. We chose an architecture where there's very little sharing going on between the nodes. And that required putting some intelligence on the server that is talking to our storage. So the server has a little map on it which says, hey, if I want data block A, I go to this array. If I want data block B, I go to that array. And we were able to condense this into a very small map that we keep there. And that allows the system to work with very little bandwidth between the nodes, which makes it really cost effective. And so we have this low sharing situation. Now sometimes we will transfer a fair amount of data between the nodes, but those happen, for example, when you bring a new node on the street or you add a new shelf to an existing node, then there's some amount of data rebalancing. But those are things that'll happen once a year and they can be controlled. So in normal operation, there's very little traffic between the nodes. So that's a very good explanation indeed. So where are you going from here? Where do you see that you can take this flash array, this architecture, obviously I presume you're looking to increase the density of the 3D NAND, and are you looking to scale more to higher levels of things? And what about the IOP side? What do you see yourself going in the next few years? Great question. So it's almost a given in the storage business. You know, people say it's a treadmill and it is to some extent. Every year, you want to be bigger and faster. So you want to support more capacity and you want to have higher performance. And we will absolutely be on that conveyor belt. The nice thing for us is we have very, very CPU sort of bound. So we depend on Intel to get us faster CPUs and whenever they do, we get an automatic boost in performance. So that is wonderful. You know, some of the performance gains are absolutely taken care of us. To improve memory, again, we're in a good situation because at two petabytes effective, we are far and away ahead of everybody else, but we want to keep that lead. So we're going to keep increasing the capacity that we can address. The sort of things that you'll see us look at in the future are things that make us even more interesting to enterprises. So for example, on the roadmap, we have synchronous replication. We're not announcing when we will deliver that, but it is something that is of interest to our enterprise customers because you want now to be completely resilient. We already have almost six nines availability, but there are customers who say, I want two copies of everything completely up to date. And so that's what we'll deliver to them. And then further down the road, there are other protocols. So we have iSCSI, we have FiberChannel, and an all-flash array, FiberChannel is by far the most important protocol. I've heard that for vendors who offer a choice, 80% use FiberChannel, 20% use iSCSI. So the rumors of the death of FiberChannel have been greatly exaggerated. It lives on. But over time, we will add the NAS protocols as well. Well, Varun, really appreciate you joining us. Fascinating look at the architecture. We're excited to see where you take it in the future. And we'll be back with a wrap up here from the Nimble Storage Predictive Flash event. This is theCUBE. I'm Stu Miniman with David and Flayer. Thanks so much for watching.