Grey Beards on Systems - 36: GreyBeards discuss VMworld2016 with Andy Banta, Storage Janitor, NetApp Solidfire

Episode Date: September 13, 2016

In this episode, we talk with Andy Banta (@andybanta), Storage Janitor (Principal Virt. Architect), Netapp SolidFire. Andy’s been involved in Virtual Volumes (VVOLs) and other VMware API implementations at SolidFire and worked at VMware and other storage/system vendor companies before that. Howard and I were at VMworld2016 late last month and we thought Andy would be a … Continue reading "36: GreyBeards discuss VMworld2016 with Andy Banta, Storage Janitor, NetApp Solidfire"

Hey everybody, Ray Lucchese here with Howard Marks here. Welcome to the next episode of Greybeards on Storage, a monthly podcast to show where we get Greybridge storage and system bloggers to talk with storage and system vendors to discuss upcoming products, technologies, and trends affecting the data center today. This is our 36th episode of Graybridge on Storage, which was recorded on September 6, 2016. We have with us here today Andy Banta, Storage Janitor at NetApp SolidFire. We all attended VMworld last week. So what happened at VMworld, Andy?

Well, before we move on to that, Ray, it's our third anniversary. It's our third anniversary. We've done this for three years. It's shocking. It seems like just yesterday. Yeah, really. And I still enjoy it, quite frankly, although it's getting more and more interesting, actually, as we get more diverse technology discussions and stuff like that.

I mean, last year we've talked Flash again. We've talked copy data management. We've talked a lot of stuff. Storage certainly isn't boring. Okay, so once your Lovefest is done, we can talk about it. Okay, we're done. Lovefest is done. So tell us a little bit about what went on at VMworld last week.

Well, unfortunately, I spent way too much time in the booth and doing my own sessions. We were discussing, I guess, a few things that came out of it were some of the cloud and cross-cloud ideas that VMware is talking about and using vSAN as an underpinning to it. Quite honestly, the pieces that I was paying attention to most were how interested people were in virtual volumes. And this was a little tiny slice of VMworld, of course. But most interesting thing I saw was that Pete Fletch actually had a VVols deep dive that was standing room only. And he actually got called up to do it a second time. And I believe it was standing room only the second time as well.

So there certainly seems to be an awful lot of customer interest in virtual volumes. I don't know. Maybe Howard has a better idea of what's going on in the context. I'm really, well, I just want to say I'm really glad to see that we're starting to see that customer interest in virtual volumes. I think the HCI guys have gotten to play their you don't need a storage array, easier card for a year or two longer than I would have liked before those of us who believe that dedicated storage arrays aren't necessarily legacy infrastructure to be discarded at the first opportunity can get the support we need with vVols. Let's hope not. You know, the truth is, once you've got vVols installed and you're away connected, running vSphere with vVols is exactly the same experience through SPBM that running vSAN is.

But it brings us back to that joy we had when we first virtualized that our compute hosts are stateless. So I think it's a better idea, and I'm glad to see that customers are going after it. Unfortunately, in terms of announcements for people who do semi-traditional IT infrastructure, this was a snoozer early in the end. There wasn't the new version of vSphere that we got spoiled into that five or six or seven years. You know, there was, you know, 4.0 was announced at VMworld, and then 4.1 was at the next VMworld, and then 5.0

was at the one after that. And the cycle just isn't once a year anymore. Why do you think that is? Because the ecosystem has gotten so much bigger. There's just so much more regression testing you have to do. And frankly, VMware hasn't been perfect with several problems relating to change block tracking in 6.0.

I also think a big part of it is that as VMware has gone on with future releases, less and less of the new features are inward-looking features that they're actually implementing themselves. And an awful lot of them are actually APIs or integrations with the outside world or other vendors. And that actually takes more time to bake than just coming up with, let's do vMotion. Well, okay, it's something we can implement all by ourselves. We don't actually need to work with outside vendors. I see an awful lot of, especially virtual volumes, as something that needs to be integrated with other vendors.

And unfortunately, that means that the quality of the implementation varies significantly. There are some really nice vVols implementations, and there are some real losers. You would think that they publish an API, or at least publish it to the vendor community, and the vendor community would react over time to that as it seems like they're doing with vVols. But there would be, to some extent, less regression activity on the part of VMware. Now, does VMware, for a vVol implementation, would they take a storage system in and test it in their environment to see if it matches the quote-unquote VVOL specification? Actually, VMware has, for a long time, has had the self-certification idea where you actually, if you want to do a certified virtual volumes implementation, you download VMware's cert tests and run against them and demonstrate to VMware that you've actually passed their certification tests. So I know with vVols in particular and most of the other things that VMware has done ground up,

that they'll bring in a handful of reference vendors to make sure that they're actually on the right track. So like with Virtual Volume, there were actually five reference vendors that VMware used to make sure that vVols worked the way they wanted. After those reference vendors basically said, OK, this is working the way we want it to, VMware put together a certification test that the vendors need to run. That's interesting. So after the initial reference activity, then it's pretty much vendors come and go as they please. Right. And at the same time, VMware actually does update the certification tests each release or each major release at least. a.0 release that you shouldn't need to completely recertify for any. non-zero release unless you're actually trying to certify with new features.

That was always part of what the major releases meant, was that if you certified for that major release, you were certified throughout that entire major release. I'm sorry if I'm a little bit hoarse, but I'm still recovering from my VMworld cold. Yeah, no, I understand. Gosh, everybody thought there would be like a VVols 2, a Vasa 3, you know, and vSAN, I don't know what you'd call it, 6.4 or something. I don't know, 6.3? There were a lot of rumors, I think, primarily started by mid-level guys at VMware that, yeah, the reason we're not making big announcements about a new version of vSphere in Las Vegas

is we're holding them for Barcelona, which, you know, I think is as much spin as anything else. I'm, you know, I've been waiting for a while for the next vVols. It sounds like schedules slip no matter what. Yeah, right. The question is, did the schedules slip three months, or did the schedules slip so much that we can't even announce stuff three months late?

Yeah, I can't see that somebody for marketing purposes decided Barcelona was more important than Las Vegas. You think that the EMC acquisition with VMware sort of in play, has that any bearing on any of this stuff? I think there's some employee distraction factor. So everybody's 5% or 10% less productive because they're distracted by the fact that the check is going to have a new logo on it next week. It is next week, isn't it? It's tomorrow, actually. Actually, you're right it's tomorrow we're recording this on the 6th and so the official dell emc

marriage is tomorrow pmware has been a private company since 2007 they've been majority held by emc but that's not going to change the logo on the vmware check at all has its own board of directors it has its own management structure the fact that it has a majority of stockholders that's going to be held by a private company isn't going to change vmware tomorrow well shouldn't but i'm sure that you know the water cooler talk and that there's some distraction no No, you haven't been at VMware very often, have you? It's going to be the Espresso machine. Yeah.

But the truth is, roadmaps go on, and you still do what last year seemed like a good idea to do this year, but the supertanker turns slowly. I'm hoping for V-Balls 2.0 that includes the management of replication, but I'm not holding my breath for it to come in Barcelona either. So V-Balls 1.0 doesn't manage replication services? No, just snapshots, really, and provisioning. It didn't even have any real replication built into the spec at all.

And I get the impression that some of their thinking there is that they actually want the replication story to be consistent between virtual volumes and vSAN, so the same orchestration model can be used for both of them. That's just speculation on my part. So you think there would be a joint release where vVols and vSAN will both come out with replication support around the same time? Well, I mean, both of them actually use VASA, so if they're both using the same interfaces, then it makes sense that they would use the same mechanism for the idea of how you would actually orchestrate a replication story through that interface yeah so now we have to involve the the guys that do the native vcr replication and srm to

implement that api because they couldn't because they have to be ready day one and of course everything then takes more time the other thing i've seemed to notice, and I can't tell if this has been accelerating or not, it seems like the headcount churn or the executive, maybe not the executive churn as much as just the people that we've been dealing with have started to change over time

there. Not the technical as much as maybe the marketing side and program management. Have you guys seen anything like that? Well, how far do you want to go? I don't know, Andy. I guess the question I have is, is this accelerating or is this just going, this is just a normal part of business?

We've always had this sort of churn. I mean, I go back to like 2011, 2012, where there was actually a fairly major engineering drain out of VMware and I'll include myself in that where there was there were just quite a few people who you know saw the operating go off and do something different and left the engineering side of VMware and I imagine that VMware had a hard time backfilling some of that. I mean, just amongst our direct friends, there's you and our most frequent guest, Satyam Vaghani,

left at about the same time. Yeah. Actually, Satyam left like a year and a half before me, but it was still roughly the same time. Irfan, who went on to Cloud Physics, was a heavy hitter. Yep. Tom Phelan, you know, lots of us were there. Yeah, so the technical side took out,

started to see more opportunity elsewhere around 2011, 2012. But, I mean, lately it seems like the, I don't know if it's product marketing, product management kinds of people have been changing every VM world. You know, I see these guys pop up everywhere. I mean, they're obviously, you know, they're good, talented people and they're, you know, seeing that maybe the opportunities are better elsewhere at this time. I don't know. I think that's more just the normal churn. You know, the valley isn't a place

where most people have 20 years careers with the same company yeah and i i mean i i honestly do think it's just plain churn is uh i mean uh uh let's pick on frank deneman for a minute where you know it was uh vmware to pernix and now back to to VMware. There's that type of churn. And I think within VMware, there's an awful lot of churn as well. Like last year, I was talking about virtual volumes with Ken Wernerberg. And this year, it was with Pete Fletcher. And it's not that Ken has left the company. It's just that there's somebody new focusing on that side of the business.

Yeah, Ken just got moved up. Yeah, well, I've talked to Ken lately. I've been working with Ken on some other stuff. So, yeah, it's interesting. I mean, it shows opportunities are there if you want to take advantage of them, I guess, to some extent. I'll go back to the Pernix thing. You think that's because Nutanix picked them up?

Didn't Nutanix pick up Pernix? I'm not going to get into it. Okay, okay. Yes, Nutanix pick up Pernix? I'm not going to get into it. Okay. Yes, Nutanix picked up Pernix, but we're not going to discuss it in detail because it's not a happy story. If you want to gossip, just look for stuff that Frank has said. Yeah, that's okay. We'll set that aside. So what did happen at VMworld was they announced this cloud foundation and cross cloud services. I wrote a blog post and I can't rightfully remember what all was in cloud foundation, but it seems like it's a packaging of a private cloud enterprise class support model,

vSphere, vSAN, you know, NSX. Way to make an announcement with some impact. Yeah. Well, I think the – well, okay. So, obviously, I think VMware is more concerned about the cloud this year than they have been in the past. Or, you know, what is it? Is it a coopetition where they're trying to take it, you know, whereas before it was the number one enemy, and now it's more, you know, we want to be your friends, but we really want to be your friends by being able to move stuff in and out, I guess.

We have to show that we do cloud because otherwise Gartner would call us legacy and irrelevant. Like it's an analyst problem? Well, I think it's a shiny newness problem. I talk to some of the youngins that we hang out with at events like this, the 35-year-old guys who now have established some position in the industry, and they just don't realize the level of inertia in data centers. And so, sure, we'd love to make, you know, the ability to say, well, you know, on Wednesdays, we do this particular kind of transcode

and compute is cheaper on Azure. So we want to move everything from AWS to Azure on Tuesday night and then run that job on Wednesday and then move everything back to AWS on Thursday because Azure is bad for the jobs that we run over the weekend. And just leaving out the fact that doing that isn't just moving 10 gigabytes of application, it's moving 10 terabytes of data as well,

and with the available bandwidth, those things take time. And maintaining multiple copies of the same data in multiple places not only costs money, but creates who's the authoritative copy and what happens if they don't jibe problems. Yeah, compliance kind of things. I hear people say, well, 80% of new application development is going on in the public cloud. It's like, okay, so let's take, let's eliminate all of the companies that are complete greenfields that are trying to be the next Twitter or some other, you know, greenfield starting from nothing application. And then let's leave out all of the applications that have a clean break. It's like, okay, I decided not to run Exchange on-prem. I decided to run Office 365 instead, but I didn't have any other applications that ever accessed the Exchange database.

Those look the same thing, aren't they? That's the low-hanging fruit. Yeah, those are the easy ones to move to the cloud, quote-unquote. Those are the easy ones. It's like as soon as you start saying, okay, I have this 400-gigabyte database that I have 400 different applications access, how do I move any of them? Because the database has to be either in my data center or in AWS. And until I can move all of those applications, somebody's going to have a lot of latency. You think it's a data bandwidth or a data transfer? You know, if the data bandwidth was, God, terabytes per hour rather than terabytes per day.

186,000 miles per second, Ray. It's not just a good idea. It's the law. Yeah, but I can have 12,000 of those 186,000 bytes per second, you know, miles per second going rather than two. Yes. You can do a lot of IOPS, but you're still going to have, you know, four milliseconds latency. No, no, no.

I understand. But now if I could move the damn data back and forth on, like, Tuesday move the two-terabyte database from AWS to Azure, and on Wednesday move it back, and et cetera, et cetera. Obviously, there's a cost in there. Obviously, there's, you know, where it stays and how long it's going to be there, a cost in there. But if I could move it quickly,

I think that's the key problem with the cloud today. Cloud, I wouldn't call it cloud, but cloud. With this whole multi-cloud. Yeah, I agree that moving it quickly is one of the issues. And I think actually cloud works out very nicely for an awful lot of places where you need to run stuff quickly, but you don't necessarily need to move it quickly. You know, it's one of the classic examples was SolidFire did some debugging that we had a bug in something a year or so ago, and we were only hitting it like once every 10,000 runs. And so we actually just dumped a bunch of virtual instances up to AWS and ran it until we actually tracked the thing down. In that case, it wasn't a matter of how quickly we could move the data.

It was a matter of how often we could run it to capture this thing and, you know, be able to sift through and actually collect the logs from times that it did fail rather than ignore the rest. Well, that's real interesting. Yeah, you know, in my days of development engineering, we had a regression testing environment, but it had a limited amount of hardware that you could use. So if you're trying to track down a real problem that was a bear to find, you'd sit there and you'd consume all these resources, but you couldn't do anything else. Oh, yeah.

Public cloud's perfect for that kind of bursting, not very data intensive application. For our little benchmark project, we're having people donate gigabyte or bigger trace files that we then map and reduce down to see how that application interacts with storage. And it's all on AWS because somebody uploads something and we crunch on it with like 400 cores for four hours. And then we're done. I think there's this mindset that workloads aren't transient or

ephemeral, and that's certainly changing. I think that's where the cloud comes in. The idea that you're going to have a workload that's going to run for two minutes and then it's going to be done. You'll never see it again. Yeah, I got you. Well, I mean, that's the whole idea behind containers, isn't it? Yeah. That we fire off this microservice and it runs as long as it needs to run and then it goes away. Right. God, there was this blog post called

Bacteria, Pets, and Cattle. And there was a solution that these guys had created for managing containers, and they were actually mapping the lifespan of these applications, right? And the vast majority of the container applications were on the order of, God, milliseconds or seconds, you know? We're thinking applications of the last years, right? This is graybeard stuff. We have, you know, applications still running that's been, you know, developed back in, you know, who knows when. But Docker containers and stuff like that, these things

spin into existence and out of existence in an iBlink. And that's actually another piece that at least we had to think about, and I'm guessing other people had to think about with virtual volumes is what happens when you do actually have these transient workloads in terms of VM rather

than the container, where they're going to go out, they're going to create their vVols, and then they're going to be done with them. Not everybody is actually doing all the the harvesting and garbage collection the virtual volumes immediately when the the vm goes away and oh yeah there's just the very fact that it's all now automated yep means that storage systems have to react much more quickly than they used to. Right. And it's also a matter of you get into these situations where the VM lives and dies,

and you're not going to actually reuse the same volume name or volume number, and you actually end up with figures that are far beyond what you actually were ever thinking you would see with normal volumes. Previously, if you had a VMFS where you would just spin up a VM, run it, let it die, the VMFS would still stick around. And the other thing, you know, so now that, you know, VMware integrated containers, and I don't know if it's available now or if it's coming soon, you know, a container is operating under vSphere. You would think that the whole, A, I don't know if vVols are supported for VMware integrated containers.

I assume so because it's just storage from its perspective. But you'd think that there would start to be a lot more churn in virtual machines. And I'm not saying, I don't think the containers in a VM integrated container is a virtual machine, or is it? I'd have to think about that. I wouldn't think it is a virtual machine, other than having the very clever name of Vic, I have to know very little about. Yeah, I'd have to look back at my notes, but.

If I remember right, it's kind of the difference between VMware integrated containers and Project Photon is whether there's a VM wrapper or not. Yeah, yeah. Every company I've ever worked at has had a Project Photon. No kidding. Is that that light speed problem limit thing? Is that you think that? No, I don't know. No, it's actually Photon at Sun Microsystems was their first fiber channel

arbitrated loop box. So if you want to go into the graybeards age. I still remember that stuff. Sad to say. I still have flashbacks to fiber channel hubs. Yeah, yeah, yeah. Arbitrated loop was not my favorite. In fact, Arbitrated Loop was what started me saying that, you know,

Fibre Channel was a network designed by storage guys, and making round was too hard, so they made the wheels octagonal. Yeah. Actually, I love what Val Bercovici said, that Fibre Channel and spinning disc were technologies made for each other. Oh, nice. Was that a cut, you think? I think so.

Hey, you know, electric cars worked really well at the turn of the last century. That's right. I'd have to say Val was the guy that turned me on to this bacteria, cattle, and pets blog post. I'll have to send it to you guys. That's pretty interesting. Infections from Val. I like that. Yeah, he was quite the guy at VMworld.

God, you know, the other thing about VMworld, there seems to be a little bit of a churn in the booth activity. I mean, last year, there were a few more storage vendors out there. And this year year they're just not there. I don't know if there's obviously, it could be a leading indicator here, went to short storage companies or something like that. I don't know. They're either dying or getting acquired. Yeah, there is a generation of

startups that's running, reaching the end of their rope. Yeah, there was no SolidFire booth this year. There was no Pernix booth this year. Yeah, but those are easy, right? I understand that. There was no Reduxio this year. Was it Reduxio? Yeah, but there was Primary Data and Data Room.

Primary Data was big. You know, there's another class of startups coming out. And I can't say that I actually walked the whole show floor so that I didn't see somebody. I'm not going to put down that they weren't there. But I met with the Reduxio guys, so they were in town. I didn't get a chance to meet with them. I didn't see their booth. I did walk the floor a couple of times, but I could have missed if they were well hidden or something like that.

But I think Las Vegas was a good place for VMworld. What do you think of the crowd at the booth, Andy? The crowd at certainly the SolidFire corner of the NetApp booth was very good. And I did see you walking the floor. God, I can't remember. It must have been a blur. Okay. I only know I saw Ray because Andy Warfield gave us photographic evidence. No.

I think we shook hands in the aisle somewhere. And I do not remember seeing Howard wander the floor. But that's not... Booth traffic was heavy. I mean, I had heard that the Emerald was actually going to be smaller this year, and I don't think it was. I think at the end of the day it was like right up in the 20,000s again. Yeah, they announced 23,000, which would make it flat from the last couple of years, which is fine.

Okay, I had heard earlier that it was going to be way down, so it was good to see was going to be way down. So it was good to see that it wasn't way down. And booth traffic, at least for something that people were interested in, seemed very good. There was an awful lot of interest in the NetApp box with a red face on it. I heard a couple of vendors say that the booth traffic on Sunday was really good. And then I heard another vendor or two say the booth traffic on Tuesday was really good. And then I heard another vendor or two say the booth traffic on Tuesday wasn't as good. But yeah, I think there's a standard drop off there, right? That's to be expected. The Sunday booth traffic is there's nothing else

happening and there's free liquor in the exhibit hall. So that's always the peak. There's Vodgeball happening on Sunday. There is Vodgeball happening on Sunday. Do you go to the Vodgeball tournaments, Andy? I mean, you might... I've been a referee at Vodgeball for five straight years. Congratulations. I didn't know you were so... I make way too big a target for Vodgeball.

Me too, actually. And I'm not that fast. That's the side. That's why I'm a ref and not actually a player. So I heard the non-EMC team won this year. Is it NetApp or Pure or what? God. So it's EMC versus the world.

Is that it? So Pure won this year. Okay. Pure and EMC were down to the final two and played each other fairly hard. So it's actually a round-robin tournament. There are multiple teams. It's not just EMC and one other company. No, no, it's multiple teams.

It's all a fundraiser for the Wounded Warrior project. Yeah, it's a fundraiser for Wounded Warrior. It's a double elimination tournament. So there were 12 teams this year. Oh, God. It was, I don't know how many games I refed. It was at least six or seven rounds. I guess for 12 teams, it would need to be at least seven rounds, possibly eight rounds.

So where was it played? I mean, was it some sort of gym someplace? Just the Las Vegas Sports Complex. Las Vegas Sports Complex. Geez, were they playing like basketball? Yep, exactly. Oh, my God. We're serious. I mean, it wasn't the Thomas and Mack Center. They weren't selling tickets. Yeah, like, basketball? Yep, exactly. Oh, my God. We're serious.

Well, I mean, it wasn't the Thomas and Mac Center. They weren't selling tickets. Yeah, no, I understand. But it's still a pretty serious venue and stuff like that. Yeah. Yep. We were there ahead of time. We had to lay out the courts and all that stuff.

God, that's a whole different discussion. I mean, you know, dodgeball when I was a kid was not really, you know, full of rules, quite frankly. I mean, there might have been a line on the floor, and that was about it. There's official rules now at all. That's good. That's good. So back to cloud services. So, I mean, the other thing that they did was this cross-cloud services. They showed software that could effectively be NSX at Amazon, AWS.

And so they were actually deployed NSX services in the cloud and were able, once that was done, to actually take over IP address administration, I think, for instances that were running AWS, which I thought was kind of interesting because all that was. Well, that could be really interesting because one of the problems with AWS is the very limited networking flexibility that you have. An AWS instance has one NIC and an IP address, and there's only layer three coming out. I'm not sure which layer it is, but it seems like you were able to extend your IP addressing from your data center through AWS, which I thought was really intriguing.

Yeah, I would be happy if they just let me virtualize the funky three-tier app where the mid-tier server has two NICs, one to talk to the users and one to talk to the database server. You know, the corporate data centers mid-tier server has two NICs, one to talk to the users and one to talk to the database server. Corporate data centers include all of these one-off things that need weird

networking that AWS hasn't been able to do. And if that means that with NSX I can now do DR as a service for those applications, I'm interested. They certainly announced when it's going to be available. Yeah, it's all technology preview.

God knows when we'll actually see it. But it was interesting. It showed, you know, they showed this little video of the whole thing. The other thing that CrossCloud Services was able to do, and I'm not sure if this was dependent on NSX being there or not, but it was almost like you configured an instance

with a VMware, I'll call it agent, running in the instance. And once you had that VMware agent running in the instance, you could actually migrate your data from AWS or Azure to, you know, VMware vSphere environment running on site and stuff like that. It was a relatively small database, and they actually spent – they didn't have enough time to do it in real time,

so they kind of had already moved it before the demo started. So it was kind of jerry-rigged. But again, the problem with moving data, it just takes so damn long and stuff like that. Yeah. VMware had been talking about that feature for a while, so if they actually have a demo of it, that's pretty cool. Yeah, that's what they tried. That's what the tech preview was. Now, it's not clear to me if the agent talked to yet another instance

that was running this VMware migration service in the cloud or what, but my guess is it probably did have something like that, and then that would pipe the data across to the vSphere on-prem or something like that. And that could get really interesting for the, you know, we developed it in AWS, but then we found out that actually paying for it 720. Well, that, you know, if it is the kind of application that's consuming resources 724, it becomes, then if, you know, if your on-premises isn't ridiculously overpriced,

it could be cheaper to run it on-premises. The more I talk to big customers, the more I figure out that corporate America just doesn't care about price. Really? Yeah. I mean, I see IT departments all the time, you know, buying things that cost substantially more than what they need because of other reasons. We're buying V-blocks. We're paying 15% more than if we bought the same best-of-breed parts and negotiated all three pieces separately because we just don't have time. Yeah. I mean, there are other constraints in purely CapEx. You know, there's OpEx and stuff like that. And there's, but there's, there's also just, you know, it's easier for me that, that, you know, I've seen people spend hundreds of, you know, literally spend enough to pay for an FTE to save a man month of time because you couldn't actually hire the guy to do it and only need him for a month and then get rid of him.

Yeah. And so what the public cloud guys are showing us is that if you do pay attention to those costs, just how much, you know, that there's 20 or so percent of what it costs to run a corporate data center, that's that kind of waste. I think that's actually changing a little bit as well. I think that an awful lot of IT departments

are actually starting to look at what their costs are, and it's like, you know, back when this was new and innovative, yeah, this might have cost a lot of money, but it shouldn't be costing that much now. Yeah, I think there's the leading 10% or 15% of customers who are getting it. But I'm talking to not stupid people who are just saying, I have a $90 million budget.

I'll just throw $100,000 at it. It's easier than worrying about it. What's bothered me about the cross-cloud services, quite frankly, is I understand each of these. But it's almost like every one of these services is going to be a special implementation. NSX for AWS, cross-data migration for AWS. These all seem to be targeted, specific services that are going to be available and made available to VMware users and cloud users. Rather than coming at it from a whole different direction, what I would really like to see is VMware for the clouds. So complete virtualization that doesn't matter whether I'm running AWS or Azure or Google

or, you know, Bluemix or whatever, the same services are available to me within a, within a hype, not even a hypervisor. I don't know what you'd call it. It's not a hypervisor. It's a meta hypervisor for the cloud kind of thing. Yeah. The problem there is that each of those public clouds has a different philosophical architecture. Oh, absolutely. Absolutely. There are differences all over the place. Yeah. And you're looking to eliminate those differentiations, which none of those people are going to be happy with, except for VMware, if they

were pulling it, if they could pull it off. And they've got to do it, first they've got to get it working for one before they generalize things. I suppose. I was just surprised that they didn't go after the big gun. They're going after the little, like you'd say, low-hanging fruit,

I guess, at this point, rather than spending a million man-years to try to develop, person-years to try to develop the cloud virtualization layer. Yes. Well, you know, it's the valley. It's the land of minimum viable product. You build the minimum viable product, you generate some cash flow, and then you find out what people want. Huh. So back to SolidFire and stuff like that, you know, we talked about it at the analyst meeting that this is vVols done right.

Could you kind of elaborate, Andy, on what you think you guys are doing differently with vVols? And this is kind of away from VMworld, I know, but I thought we'd go after that a little bit while we got you on the line. Well, certainly, yeah. I've spent I don't know how much time talking about this. vVols done right. That was Dave Wright's tag for it. There are a handful of things that we actually attempted to put into our VVols implementation to make clear that it was a differentiator. We've completely separated the storage container idea from anything having to do with the protocol endpoints or any other piece of the storage.

A storage container is something that a VMware admin cares about. It's not something that a storage admin should have to care about at all. The really big thing that SolidFire is trying to do with virtual volumes is drive home the point that you can do large-scale, policy-driven VM granularity QoS. That's something that just really hasn't been available from any other vendor. The idea that you can actually do QoS at the VM level or even at the virtual disk level, do it at large scale and have guaranteed QoS at that level. So you can create one or a thousand VMs, have certain QoS settings, you can set it that way, and each VM will get that setting

rather than attempting to lump them together into a data store that gets that type of setting. The other big point that we try to make is that you can actually go in and change those QoS settings on the VMs or on the virtual disks, and they get changed from the VMware side of things, from the vSphere client, and there's actually no data movement involved on the SolidFire side when you change it.

Those are the compelling features that we think make SolidFire vVols look good. It's really amazing how QoS and vVols go together. QoS on a VMFS data store is kind of like just making smaller neighborhoods. But the thugs that live in your neighborhood can still get noisy. It's like turbocharging your bus.

I had a bus at one time. I know you, and you would think about doing things like that. Yes, I would. But it's the whole, it's like you know, saying that your entire train goes this fast or this slow versus each individual component of it. The other thing that SolidFire is really aware of is doing vVols and a couple VMs is something that you can do by hand fairly easily.

Once you get into more than just a handful of VMs, you actually have to automate it. SolidFire certainly understands the automation side of things. Our entire API is available. We actually have pushed a couple scripts up to GitHub at this point that allow you to actually migrate VMs from a VMFS data store to a vVol storage container and apply policy at the same time. And another one that actually allows you to change the policies on VMs or on individual virtual disks in a VM. These can both happen while they're running. And while SolidFire has pushed these scripts up, Josh Atwell is responsible for them.

They're not SolidFire specific. They will work on anybody's virtual volumes implementation. It's just the idea that the number of objects you're playing with, with virtual volumes, you have to automate it. You cannot sit around and figure that you can diddle this stuff through a UI anymore. Yeah, no, because we're talking about thousands of objects, not tens of objects at the very least. I mean, Viva should be something that DevOps people love to hear about.

It's the type of thing where they can go in and monkey with this stuff as much as they want to. Yeah, unfortunately that implies that this storage backend actually does a decent job at QoS. Well, there's that side of it. The other part of it is that from SolidFire's perspective, we're trying to make sure that the SolidFire side of it is invisible. So everything that you do to manipulate virtual volumes, you can do through the vSphere client. We want you to forget what your SolidFire UI looks like. You should never be using it.

You should be doing everything through your vSphere client. You should be going in and managing your storage containers through the plug-in that we'll be supplying. You should be setting policies through your SPBM in your vSphere client. So the scripts and stuff, they're all driving vSphere client services? Yes. Yeah, so yes, keep in mind that the scripts are actually setting policies through the vSphere side of things, and the policies are actually getting picked up through the vSphere side of things and the policies are

actually getting picked up through the VASA provider that runs between vSphere and SolidFire. So the automation scripts are not actually going there and poking the SolidFire side of things. Yeah, all of this is reinforcing my position that the storage administrators job is no longer all of this day-to-day provisioning. Shift that to the VMware guys. The storage administrator's job is being the designated paranoid who makes sure that all the policies the VMware guys get to choose aren't stupid. Yeah.

So actually, we had some props made up that didn't actually make it to VMworld US, but they will be there for VMworld Barcelona. We actually have some styrofoam tombstones that say storage admin. Don't do it. No, no, no. Andy, don't do it. I don't want to see a storage admin tombstone. I really don't.

Yeah, Ray doesn't want to see it. I want one. Some of us are more advanced than others. All right, gents. Well, we've come to the end of another graybirds on storage podcast is there any other questions you'd like to ask howard before we end no i would like to thank andy for the lovely dinner at picasso though very good andy is there anything you'd like to say to the graybirds audience thanks for having me i'd love to do it again sometime and i i'm really disappointed in my first chance at this.

Got lost in the VMworld archives last year. It's okay. No worries. No worries. Well, this has been great. It's been a pleasure to have Andy with us on our podcast. Next month, we'll talk to another startup storage technology person. Any questions you want to ask, please let us know.

That's it for now. Bye, Howard. Bye, Ray. And until next time, thanks ask, please let us know. That's it for now. Bye, Howard. Bye, Ray. And until next time, thanks again, Andy. Thank you.