 Okay, we're back live in New York City. This is SiliconANGLE.com, SiliconANGLE.tv's theCUBE, our flagship telecast where we go out and talk to the smartest people in the room. I'm John Furrier, I'm here with Dave Vellante and one smart note, or smart person, a CUBE alumni, Doug Gorlay, Rista Networks, back again. You're outspoken, you're not controversial, but you're knowledgeable. You've been around the block, you've been on theCUBE many times. Welcome back. Humblest person I know. Dupe World, I mean obviously, cutting edge, you're here, you're always on the forefront of new technology. You guys are delivering great solutions at Arista, and I see your boxes when I go to companies, I can't say where, but a lot of units being shipped. Increasingly, things are going the right direction. Absolutely. Big data companies, John. I had to take a picture, I showed Dave, like look at these eight Arista boxes. They're growing. And these are really expensive ones. You don't care, you don't bring those in unless you're growing. How's it going? What's the update since we last talked with you? I think the last time we chatted was at VMworld, where we had introduced some solutions for VMware, and actually came away from that with, very thankfully, the best of VMworld award for best network hardware for virtualization. And as we're here today at Hadoop World, very similarly, we've been introducing networking capabilities that actually integrate with the HDFS file system, which is really the first topology aware file system out there, which is one of the things that makes it really cool. It distributes data and protects it by being topology aware. And then it distributes the jobs to where the data is. And if you know the underlying topology, the infrastructure works better. If you want to break a Hadoop topology in a heartbeat, mess up the rack locality file. You know, mess up the rack locality section. You'll get things in the wrong place. You'll think your data is protected, it's not. You'll think you're distributing the jobs correctly, and you won't be. So if we can automatically keep it coherent, what we end up having is a better performing infrastructure, but it's applications coming together with the network. We talked about this at VMworld slightly. We didn't really do a drill down on it, but since we're at Hadoop world, this new configuration, as you mentioned, topology aware is key, but people are talking about software. They're talking about software. There is kind of a software revolution going on in the networking space. You see OpenFlow getting some traction. It's been around for a few years. You talked a little bit about some of the secret sauce you have, but what people don't talk about the network is really moving data around. That's a key component. And sometimes data's sizes are big, sometimes, and they are certainly growing. What are the dynamics in moving across the network? Because with Hadoop, compute kind of goes away, storage kind of goes away, hardware, that hardware layer kind of becomes not irrelevant, but it's still not a bottleneck like it used to be. What's the issues at the network level? Well, the first piece is, and I think you described it well, is when you roll out Hadoop, the model you use to deploy it is markedly different than what people are used to. This isn't buying big iron enterprise storage systems and saying, now let's load it up with 10 petabytes. And now in those worlds, you have to move the data off of the storage across a network, which as a network guy is a good thing, to a set of compute nodes, process it, determine your result, and then either discard or push the data back. The Hadoop model is distribute the data across a large number of nodes, and then make replicas of it to keep it, data protection is through increasing the number of replicas you have, and distributing them the right place. Well, you have to know what the topology is to do that. Hadoop is a layer three aware file system. You can route it. So every switch at the top of every cabinet is actually routing, which is brilliant. The network guys get excited by that. I can actually route that stuff. I mean, I'm sorry, but do you know how many companies chased this, let's build big flat layer two networks because it will be easier. Yet, the application world through VXLAN and VMware, and through HDFS with Hadoop, got rid of the need for that. And so we come back to, what are the network architectures that built the internet? What are the network architectures that the largest search firms, the largest networks the world run on, it's all based on putting routers in the right place. And we're able to do that with Hadoop, which was large, scalable, but also cost effective and reliable infrastructures. So Jay Shree said, sorry, Josh, Jay Shree at VMworld said that virtualization requires fat and flat networks, right? So Hadoop requires just flat networks. Not even flat. Just fat or neither, thin and. What it requires. Any network. It requires networks. It requires a network. But you know. On any kind. Yes and no. So what's different? What it requires, it's a topology aware file system. It requires a network that's Hadoop aware. That means the network needs to know and integrate with that topology construction. If I don't know where the servers are connected, I might think that you guys are on different switches. So I'm going to give you a copy of the data and I'm going to give you a copy of the data, John. And then when the switch supporting Dave fails. Well, if you were on separate ones, it would work. But if the same switch supported both of you, if it went down, you just lost data. Your jobs stopped. And until you get some advanced replacement or new component in, you cannot resume your data processing mining. And it's sequential too. It's a sequential model as well. So that's another point. And then you see applications like HBase coming in, running on top of Hadoop. And that says, now let's take this Hadoop model and now let's put a real time transactional 24-7-365 system on top of it. And it's a lot of data too. It's not just little data. It's a bounding data. I mean, we've been working with architectures with some customers, putting between a third to almost a petabyte per cabinet. And then you look at, let me put a hundred cabinets in. And so now we're talking 10 petabytes, 20 petabyte type of clusters. You can't lose the data. And if you have to move it across the network, because you're not architecting it properly, then it's just going to slow everything down. You know, Doug, I always appreciate your perspective because, you know, for the folks out there who haven't seen Doug on theCUBE, many times he's been on, you had a stellar career at Cisco back in the glory days of Cisco. It's good times. When they were growing so fast, you guys were running and powering the networks. The internet was growing, the web was growing. You were a big part of that important stage of distributed computing and networking. So, you know, really pivotal time in history and it's well documented. Now, at Rista, you're in that same kind of situation in this new generation. So, share with us your perspective. Drawing on your history, but also looking forward. Kirk Dunn, COO, Cloudera mentioned that this is so disruptive that it's disrupting existing players. What are the big disruptions you're seeing that Hadoop and this movement is causing to the incumbents? You mentioned HP and the hardware guys and the networking guys. What do you see as this big disruption? Well, there's probably a couple big ones, John. The first, let's say Hadoop and let's take Cloud as examples. The, to build Hadoop, you use commodity hardware and open source software. It does not require a million dollar storage arrays anymore. I struggle to find the relevance. If I was the multi-million dollar storage array company, I don't know what I would sell into a Hadoop model because nothing in my portfolio fits. What fits is the Super Micro 2RU box with 24 SAS drives across the front loaded up with a terabyte SAS drive in each one of them, giving me 24 terabytes per two rack units. Oops, that's a lot cheaper. If I maintain three copies of data, it's just as reliable and it doesn't require me to change my network architecture to do it. It works across the routed infrastructure I have today. That's incredibly disruptive to the storage industry. Let's look at Cloud. What's the Cloud message? Commodity hardware, open source software, open standards, open source, automation, automation, automation. It's an entrepreneur's dream. I'm like licking my chops right there, you know? I'm sitting here looking at a market. I mean, with the Intel Romly chip set coming in like the Q1 timeframe, every server manufacturer building servers on that are basing it on 10 gigabit ethernet as a default interconnect technology. Why did we build 10 gig products? Because it's where the puck's going. It's a Gretzky move, be where the puck's going. Why did we open up the APIs and open up the operating system? Because it's a world depending on automation and open source. You tie into that. Software is key, not just the hardware we build. Sorry to my hardware team, you're not going to appreciate that, but that's why we have 170 software guys and a lot less hardware guys. The next thing we look at is ensuring that we can automate things. Because both of these worlds are a world of DevOps. Not a world of dedicated network guys, dedicated storage guys, dedicated server guys. It's about cross-functional people. Yeah, at Facebook, we put an exclamation point on that. They're like, look it, engineering and ops are one. When we hire ops that are engineers and engineers that know ops, there's no finger pointing of any kind and the disciplines aren't that siloed at all. Completely integrated. And if that's the go forward, go to model that is the most operationally efficient, that lets you be increasingly profitable, those guys know Linux. So you build your operating system based on Linux and you give them access to it. Somebody said to me once, it was a distinguished engineer at my former company said, you would give your customers bash access? I'm like, yeah. You'd let them run with scissors? Like, that's a really good analogy. Yeah, we would. He said, my God, what if they screwed something up? He said, some of the largest credit card transaction processors in the world run thousands of Linux servers. I think they know how to run them. Their business and mission credit, their businesses run on Linux. So they know that better than they know your network operating system that's proprietary. So why don't we give them access to the tools they know? And you're talking about a notion of automation in the cloud and we have a lot of cloud service providers that we talk to that are really driving this very hard. You're putting forth a scenario where basically automate everything that an SE might do except perhaps replace a failed component. I guess that's the only thing that you're not going to automate. I can deploy a Hadoop cluster in less than 30 minutes by plugging a switch in, plugging the fiber ports into it, turning it on and walking away. And with no human touching it from there, it will download its configuration. It will download the correct software version, download the right extensions, configure itself, download a Pixieboot server and download the Hadoop or CloudAir image you want on every single server and then boot the servers automatically and load the image on them and add them back into the Hadoop configuration file. Can do that in less than half an hour. There's a company, Piston Cloud, that came out in the cloud computing world. The way they load their cloud, they take a USB key, they plug in our switch, power cycle the switch, then it loads their software into our switch, gets it running and then loads their software onto every one of the direct attached servers. And how do you do it in another world? Oh wait, an 80 by 24 CLI screen circa 1965? Knock yourself out. Good luck automating that. No API? No positive or negative acknowledgement on command take? That's the model, network enterprise, network enterprise network administrators are used to. And unfortunately, I guess the saddest part of it is they're paying 70% enterprise margins on top of enterprise cost structure products, which then mean you can't run the service profitably. The large clouds aren't built that way. They're built on open source and commodity and stuff. So what's the outlook then? So the outlook is complete, rip and replace, what's the migration plan? I mean, I'll see, you know, a little biased with Arista, but we buy that story. Never biased. What is, we know we like the story. I mean, the story's good, the story's phenomenal, but like let's take that pain point. There is a gloom and doom, you know, you're in the stone age kind of mentality that people have faced it. And there's direct cost involved, right? So that at some point they're going to say, we got to start shifting. The apps are going to drive it, the things you mentioned, disruption. How do they move from that world? Is it a reconstruction? Is it rip and replace? It's a good question, John. I'm not sure that I have the perfect answer for you, but I'll tell you what I've been seeing for the most part is people looking at this and saying the enterprise model was build and spend money so that it never fails. The cloud and DevOps model is build it as fast as you can, learn from it, do it three times, and be better on the outcome of the second or third time than you ever would have been, you know, going with the build it to never fail model because when those fail, they fail in a complicated way. The introduction of that philosophy and that operating model into traditional enterprises is coming in areas like, you know, Hadoop is a great application for that, private clouds are great applications for that, and they're in niches. It's not in wholesale rip and replace my enterprise and stop doing things the way I've done it for 20 years. It's identify a new application, new deployment, profile and try it there, and if it works for you, start scaling that model out and start eating their own dog food on it. So I want to play the scenario back. You're talking about the million dollar refrigerator, you know, the storage boxes. So yesterday, I think. There are switches, too, from other companies. Switches, fine, so but I want to take a practical example of one that was announced, I think, yesterday or the day before. So NetApp is basically distributing HDFS and Cloudera's subscription service with it's, maybe it's not a million dollar box, but it's an expensive box, right? It's not off the shelf stuff. And the premises, they're going to go to their existing customer base and say, hey, you have this big data problem, we can help. And I actually think a lot of enterprises are going to go, hey, we're really not informed about what's going on with Hadoop. Sure, why not? We trust NetApp. And good company. They'll do some business for a while, right? But let's take that scenario through. Because this was the Ingenio box, right? Yeah, I'd say it's like, it's a hybrid between Ingenio and OnTap, you know, it's a good thing. So, okay, that's NetApp's play. I happen to believe that that's fine, they'll do some business, EMC will keep doing some business, but I think there is a big disruption here. I wonder what you guys think. We're over time, the cost of doing that relative to what a lot of the innovators are going to do is going to be so disparate that the guys who are just saying, okay, yeah, great, we'll go with our existing provider, are going to get hit in the head. And that's going to change. I mean, it's not like PCs replace the mainframes, but the work that we were doing was so much more productive, it just became more relevant. And is that what's going to happen here? And what do you think? I think you're right. I think there's going to be a short-term pop. I think EMC and NetApp are going to have sales channels, they have relationships. And you mentioned, you know, Switch, you got Cisco out there, you got Juniper. I mean, big data is a buzzword. Let's face it, for most people, Hadoop is really the platform, big data is just kind of like the phrase like web 2.0. I think if people know that this is inevitable, they've gotten some validation. But I think for the most part, no one really kind of knows what it is. So there's some generic nature of the word big data and they're going to go with people they trust or have been working with and or have been working with. Like EMC, so EMC sales force just on a straight brute force basis will gain traction in the short term, as will NetApp and others. So, you know, with that comes the risk of having alternatives. You mentioned open source, the kind of the benefits that are coming out of Hadoop world are amplifying the new generation of architecture, solutions and ultimately the value proposition. So to me, I think that's totally disruption in what will, again, my opinion from people I've talked to and my personal opinion is that at the end of the day, it's about the money. Value proposition drives business value. It comes down to who's making cash? That means I'm selling more product if I'm a product sales company. If I'm a service company, I'm doing more service. I'm a retail company, I'm doing more retail. If you have happy customers, and now you can instrument that. So to me, the big data thing is compelling because the analytics play gives you measurement. So ultimately, whoever gets there, you mentioned Dave, the prize is first place is big market share and big money. So I think if they risk to hold onto their market share and can't deliver the right solution, they're going to have unhappy customers. As long as there's alternatives, they'll lose in the long run. That's just a pure known formula. But yes, I think NetApp and EMC will win some business with their approaches. But they make tons of money off of spinning disk drives that are essentially artificially inflated. And that's the disruption that I think you're talking about ultimately. These disruptions don't just happen quietly. John nailed it though with the thought that in the short term, let's be frank, the bulge bracket, soft middle of the market will believe the sales message that they're given from their vendor. Because I hate to say this, and I don't want to knock too many people on it, but they've stopped being engineers. They're consumers. They're consumers of whatever their vendors tell them to buy. And I like to tell our customers that are engineers, don't trust us, don't trust any vendor. Take it, test it. When you hire an engineer to build a bridge, you don't tell them I want it wood, I want it metal, I want it stone. You say build the best bridge you can with whatever materials are available and then give me some price points on it and you make that decision, the best engineering decision. IT engineers need to live up to the latter part of that title. And it's, let's look at the best solutions and technology that's available to solve a business problem. And it's going to come down to the profitability component. And if you look at the outside of that bulge bracket on the right hand side of the equation, you have the largest network operators, the largest data center operators of the world. And those guys have already made and voted with their wallets because that's where profit comes in. And they said the commodity hardware route with intelligent software based on open source lets me build and run a more profitable service. If you want to get continuously out executed by them or you want your competitors to go use cloud services provided by them and beat you every time, go build it the old fashioned way. When I take lipstick and I put it on the pig and try to make it look good and I call it cloud or big data. It's not the same. So those cloud service providers, the new IT engineers? Yes. Okay, what's different about their buying criteria? You touched on some of them but let's talk about that a little deeper. What's different about their buying criteria than the traditional enterprise? They operate at scale. They test, they automate. I mean, look at the Windows Azure cloud which was touted as having, I think it's 45 people running a data center that's 100 megawatts with 250,000 servers. 45 people running the entire facility. You go to any enterprise shop. Okay, it's last week I was at the NIST conference with the government and I asked a question. How many of you put stuff in the data centers or operate data centers? About half the hands in the room went up. Said, if anybody here is running a data center that's over 30 megawatts, keep your hand up. Not one hand went up. Said, do me a favor. Do all of us taxpayers a favor. Turn it off. Consolidate all your facilities and something that's operating at a scale that enables you to be more efficient. Leverage those economies of scale and have a better business impact because of it. So what are the cloud guys doing different? They operate at scale, they test and they make the best technology decision. Not the best, not the, this is my vendor who takes me out and buys me drinks or plays golf with me decision. And you brought up the, that's the DevOps angle right there. What you just said is DevOps. Yeah. There's another angle here too, which is they look at IT as a business. I mean they're profiting. IT is a profit center, not a cost center. And you make different decision center. What are the, what are the, they must be looking at different metrics. What are the metrics that they're looking at that are different? Well, power is one and power efficiency defines a maximum profit envelope of any given facility you're operating within. So they look at the number of servers. Let's take a cloud. The number of servers I can put into a given footprint equals how much money I can make out of it. Every single thing you do that reduces the number of servers in that footprint cost you potential upside and top line. So the more power your network takes, the more power your, you know, management stuff takes, the less servers you get and less money you make. They look at it that way. Then they look at it and say, okay, you know, if you look at the larger clouds you're deploying between one and four or five hardware configurations. The enterprises are custom designing the hardware to the application. The cloud guys are saying, let's homogenize the hardware and then virtualize the applications. So I can have a smaller, look at Southwest. They fly one jet, 737-800. That way every crew can fly every jet. You never have an equipment issue. You never have to worry about a plane change changing your seating arrangement. It's that type of model. They're the most profitable airline out there. They use one piece of hardware. So a clear homogeneity and that's something a lot of these, the true cloud service providers are driving towards. A lot of the hosting companies that are cloudwashing are struggling with that dynamic. They invest in automation rather than investing in the headcount to operate. And they're looking at other metrics like profit per customer, revenue per customer. So we talked about this last week. The data center is an ATM. Like you said, the more capacity that they can put into that data center, the more efficient they're going to be, the more money they're going to be. I saw the smiles when I said that it clearly something resonated there. Yeah, we've been betting on that. We're at that HP announcement. Moonshot server, Arm, Calzada. 2,880 processors in Iraq. It's insane. 280 servers on a blade, on a slot. Unbelievable. And you can turn them on and off and turn off cores. Five watts per chip. So real revolution by HP. The Arm stuff is incredible what they've done. We love that. It's coming to the data center. And as those get faster, I mean the reality is the type of workload profile we've dealt with over the last decade, the requirements of that sort of normalized workload hasn't changed a lot. Yet, if you follow Moore's law, we're at eight cores coming out in the next three months. Eight cores per chip on, say, standard Intel. That means in two years, you're at 16. In four years, you're at 32. In six years, you're at 64. It's amazing. Before the end of this decade, we're at north of 128, three gigahertz cores per die. Yet, network capacity isn't bound to Moore's law. It's bound to the speed of the package, how many CERDs I can get per package. And so packaging hasn't grown at the same rate that Moore's law has. And then clock rate on that speed that you're clocking those CERDs is bound to the gigahertz CPU, or the gigahertz rating. And we're kind of limited around three gigahertz there. So we're already hitting upper bounds of what the IO plane can be until technology changes massively. So what's your take on that then? Now, I see network is the bottleneck. So we're seeing things like open flow. What do you think about this software-defined trend that's getting a lot of traction, open flow in particular? Well, I want to raise it up one level above open flow because that sort of came from an academic background. And in many cases, I was at some of the open flow things recently and we were discussing what are the actual use cases of it? What problem are we really setting out to solve? And the challenge I've seen in some cases is the sort of open flow pundits, I eat the people who want to throw conferences around open flow and therefore make money from it, are saying, oh, open flow will change the road and be the new way to do everything. Yeah, good luck, knock yourself out. 4,000 flows per second in a network that's moving terabits per second in millions of flows, it's not going to scale. What I think open flow will become is a consistent programmatic interface for network policy to be applied in a multi-vendor environment, which is somewhere between where we are today federated and where open flow was espousing, full centralization, there's a meet in the middle, which is consistent programmatic models in a multi-vendor environment. So dynamic policy. Let hardware do what hardware does well. So what you're saying specifically, what open flow is showing is that by basically dynamically setting policy based on certain conditions on the network, so an application can come in and essentially configure. The best application I've seen for it was one of the original design points of it, which was take a layer two network, identify a flow that is of interest and then redirect that flow to a tap to capture it. Allowing more cost effective network control and network mirror, network monitoring. That's still a great application. But the question I come back to is what are the other applications that it can solve? And they're somewhat limited today. I'm not saying they're not going to be there in three years, but I think as a technology it hasn't gone through that trough of disillusionment yet. Yet the concept of a software defined network, a consistent programmatic models, multi-vendor environments, programmatic APIs that are designed for machine to machine communication is absolutely where as an industry we have to go. I just don't want to predict right now that open flow is the only answer to that. There are multiple controller models and everybody who's been building a controller for open flow that I've seen has found that it doesn't do everything they need, so then they've all branched and wrote their own little versions off the top of it. Yeah, big switch, let's see how the one, they all got funding too, big time funding, like 30 million, some serious bank there. So Doug Gore-Lay, VP of Marketing at Arista Networks, industry legend, been on theCUBE multiple times on the cutting edge with Arista. We love your story over there. It's good, congratulations on all your success.