 Okay, we're back. This is Dave Vellante, day two of Edge. We're live. I'm here with my co-host, Stu Miniman. This is theCUBE, Silicon Angles wall-to-wall production. We drop into shows like this. We try to extract the signal from the noise. We go out, we find the best guests at these events, and we bring them on. We find IT practitioners, CIOs, technologists, analysts, bloggers, executives, and bring to you our audience the flavor of the show and the major trends that are going on and hopefully bring you some advice. Karim Abdullah is here. He's an IT practitioner with Sprint. Karim and I first met down in New York City in April. Karim, welcome to the live CUBE. Thanks, Dave. Good to be back. Yeah, it's nice to see you again. So we're here at Edge. Were you at Edge last year, by any chance? Yes, I was at it. Yeah, so you saw that we were in Orlando. We were here too. It was quite a bit smaller. So we're seeing some major progression. What does an IT practitioner like yourself get out of an event like this? Number one is validation of the things you're working on. You meet professionals like yourselves who may have challenges very similar to you and you validate things you're doing very similar to what they're doing or what challenges they might be facing, sort of sharing results and trials. So in that spirit, what are some of the things that you're getting validation on or things that you might go back and say, oh, guys, we maybe need to rethink this? Well, the validation is that we have pushed many envelopes in our SVC deployment, which eventually led to the flash system deployment and overall tremendous success in that avenue. It's been very positive for us. We're leading in terms of the volume we have deployed and some folks are actually learning from what we have already experienced. It's a good thing to share. Yeah, okay. So anything that has caused you to rethink what you're doing or is it pretty much confirmation of you? Mostly confirmation because many folks are still in the area where they're trying to simplify to get where we are because they've got multiple solutions on the floor or very similar solutions. So let's talk about SVC a little bit. So did you hear Ambuj Gayal's talk yesterday? No, I wasn't here for that one. Okay, so basically he put forth this vision of software defined and we'll talk about that a little bit. But essentially, you think about software defined, you really do need some kind of way to abstract the underlying hardware and that's what SVC does. What brought SVC to sprint originally? What was the motivation? What was the driver there? Strictly a cost and an end of life issue. We had an end of life approaching on all of our existing storage arrays. So over the last three, three and a half to four years, we've gotten rid of over a hundred storage arrays simply by installing a virtualization platform and then redeploying or deploying newer platforms behind the virtualization. And as we roll the virtualization platform up, we roll the end of life devices off. We're reducing operations costs, managing some capital expense in lieu of some long-term high overhead. And are you able to do that migration non-disruptively? Today we are. Today we are fully utilizing SVC at lower cost and at no cost, whereas comparatively it would have been a very expensive proposition a few years ago. I was looking at some data this morning on the wiki, on wiki-bond.org. And I found a piece that David Floyer wrote and essentially he estimated that over the life of an array, a migration could cost as much as 30% of the total cost of ownership of an array. Does that feel right to you? Does it feel high, low? Some of my personal experience tells me that that might be very low because of distance migration, not just inter-data center but inter-cities or inter-states. So I've seen it much, much higher than that. And the impact is the timing. You can't time it perfectly. You have to keep, you have to renew leases, all kinds of things. You have to continue the maintenance. So it's timing, it's leasing, it's renewal. Also what's not mentioned there is disruption to application availability, which is what is so-called my bread and butter. I need to keep systems online and available and at pertinent at all times. Yeah, so quantifying that is potentially telephone numbers compared to the hardware. Correct, correct. Telephone numbers, I guess pun intended. So, okay, now let's talk a little bit about your use of flash systems. So I know from talking to you that you put, and this has surprised a lot of people, in the early days of SVC, people would say, well, you're only going to put, you know, you're sort of your crapplications behind the SVC. You're not going to put your tier one storage behind SVC, but you actually have a VMAX running behind your SVC, is that correct? Yeah, our SVC installation now have four tiers of storage from tier zero to tier three. And tier zero is the new flash system, whereas tier one is your traditional high-end DMX or VMAX. Tier two and three are your CEDA and or your Clarion and or some XIV. So we've got four tiers of storage, and the whole SVC has reduced the number of interventions a person has to make to manage the storage, and that's what's making it unbelievably easy in terms of being able to allocate and provision and carbote storage based on performance needs, application needs and tiering needs. So for us, for us using flash system was really just dropping a block of storage as a new item or a new node within an SVC infrastructure. Now, do you do chargebacks at Sprint? We don't, but we're working on it. You are. Okay, do you do any kind of showback or? That's where we are now. We're trying to demonstrate where it is to showback for certain deployments as part of a budgetary practice for cost of projects. So obviously different tiers have different costs associated with them. Do you see, we talked about this in New York, and I'm going to ask you again, because I think your answer caused you to rethink it. So do you see those tiers, those four tiers collapsing over time? Do you see them maintaining? Have you thought about that anymore? Maybe the four tiers reducing down to three from where we are today, but having flash system replaced tier one, I don't see it really occurring near term. It may over a period of time. And one of the reasons is the price point, right? So now we're looking at price point for iOS versus price point for gig. And that's where the differentiator is coming in. Now, in terms of the storage functions, the services that you access for those different tiers, where do they come from? Do they come from the SVC? Do they come from the device itself? Do they come from a combination? It's a combination and the storage is 100% behind SVC. The allocations occur from the application layer. So applications may have a very hot spot of processing, a medium spot and a low spot. And we will allocate storage based on the performance profile of the spots and put that on the appropriate storage. Okay, so you make that decision based upon the capabilities of the storage services that you can get from the array and the application and workload requirements. The behavior profile. What advice would you give to customers that are thinking, because everybody's talking about this software defined storage and everybody's going to get to some kind of virtualization layer, whether it's SVC or other vendors have similar capabilities or maybe you do so through some other kind of mechanism, like VMware, what advice would you give to people in terms of how they can construct those storage services to the greatest value for their organization? Well, number one is understand the footprint you operate and how you can modify and where you can make modifications. I like the concept of software defined storage because now you can manipulate the use of your storage more in line with your application needs and your end user needs and your compute needs. But you have to understand where you are and what modifications you need to make to get there, meaning going behind some sort of virtualization infrastructure to reduce the number of manual inputs into that environment. Once you automate it, it becomes fairly straightforward. Yeah, and I want to ask you about your SDN strategies before I do. We talked to Eric Eiberg about the 100 microsecond overhead in the flash systems that SVC injects. And I mean, it's a virtualization layer, so obviously there's overhead. Was that a concern to you prior to going SVC? I mean, obviously you're all in on SVC, but I presume the benefits outweigh that, but can you talk about that a little bit? Yeah, the 100 millisecond was not such a big factor because we were going from an end of life comparison, right? You had one bit of comparison here that says you're extremely latent to something that was much more automatic and had the ability to grow and move faster. So the latency introduced by the overhead in the SVC was not such a challenge. When you can go to a flash system based on a six to eight millisecond to a 200 microsecond, that's where you see real benefit of going Yang SVC. So for the most part you ignore that 100 millisecond just from the SVC overhead. Okay, Stu, why don't you talk a little bit, Stu, about SDN, what you're seeing in that space and maybe take the line of questioning with Karim there. Sure, so Karim, we were talking a little bit about kind of virtualizing, getting greater efficiency out of our environment, even getting longer, kind of having to slow down the refresh cycle. Networking's trying to tackle this problem. Can you tell us where you are on that journey and what's your thoughts on SDN, which to tell you, we think the term itself is rather meaningless, but let's get your take on to where you are with it. Well, my new role in IT network now is very similar to the role in storage in that you're trying to get to the next platform that gives you more mobility, more flexibility, more agility, and more usage. So what we're trying to do now is to match the whole mobility front and bring your own device and where computing occurs. And it's not occurring in a central location anymore. So as the end user or as the general user moves and expect demands to grow, your face of the position now where you have to move your network capacity to where the demand is, and that's where we're looking at SDN to help solve some of that, is to be able to say my location X needs more compute or more network power than my former location Y, but location Y may have the capacity. So I want to be able to move that capacity around as I see users and needs move around, and that's where we are now. We're doing the analysis around it. We're doing some deep dives. We've got some third party studies being done that hopefully will enable us in a short time. Okay, so a lot of times SDN, the discussion is really, you know, scalability and automation, but it sounds like mobility is really one of the key drivers as to what you're doing. Well mobility, because the mobile user is now driving greater consumption and greater volume in the network, and you have to have the network to help provide that support. Okay, so where are you on that journey and what are you missing? What is the vendor community really need to do in your opinion to make this more real for you? Things around security, things around access points, things around, you know, enabling the hardcore infrastructure because there has to be some amount of infrastructure that enables your software to find that work. So getting ready at the lower level infrastructure is important to me, and that's where I'm working with vendors closely to understand what minimal upgrade or what code upgrades or what, you know, practical upgrades I can do there to start enabling my SDN. Yeah, no, when I heard you talking about storage, you said, you know, I can take my older environments, I think server virtualization, you know, even my end of life operating systems I could take. There's one of the challenges with, you know, SDN in general is, you know, do I have a switch that supports? Are you looking at open flow or what kind of tools are you looking at? We're looking at open flow, we're looking at some open software as well to help with that where we may not want to pay the full cost, but yes, we're looking at any and every number of available avenues to get the best solution. Okay, and, you know, what's your take as to how long it's going to take before the solution's ready for you guys to start putting it into your environments? The challenge today, Eric, is not so mahogany, how long it'll take means how long it'll take my customers to get frustrated with me, so I have to respond fast. It has to be flexible, it has to be agile, and it has to be capable. And I feel pressured in terms of needing to do this tomorrow or the day after, but it has to be done intelligently, you don't want to break anything in the process, you also want to be very secure in your solution, so I would say within six months, you have to get some solution out there or some position on a solution. Karim Abdulla, pushing the envelope, I always love talking to you, your wealth of knowledge, you've got really good advice for your fellow practitioners. A new friend of the cube, really appreciate you coming on. Thanks, Steve. Thanks, Eric. All right, keep it right there, buddy, we'll be right back. Alex Yost is in the house, we're going to talk to him about what's happening in the blade systems business and the server lines, and we'll keep it right there, we'll be right back, this is the cube, right back from Edge.