 Hello everyone, welcome to a special CUBE on the ground at VMware's corporate headquarters in Palo Alto, I'm John Furrier with the host of the CUBE and we are here with Guido Appenzeller who's the Chief Technology Strategy Officer of the Networking Security Business Unit at VMware. We're going to talk about cross-cloud security, networking, NSX, all the above. Welcome to our special- It's great to be here today, thanks. We had great conversations with a lot of the folks here today at the special CUBE on the ground at VMware. But one of the things that's coming up over and over again is the same theme that we've been hearing over again. The Amazon web service is a relationship deal that Andy Jassy and Pat Gelsman said highlights, puts the public light on your cloud strategy which has been kind of in motion with cross-cloud for a while, IBM deal earlier. But also at VMworld, Pat Gelsman was highlighting a lot of the success of NSX. Can you like tie all this together? Now where are we right now? You have on-premise, you have AWS with VMware. How is it all fitting together right now to customers? What's the current pitch? Absolutely. So look, the cloud I think is the biggest structural transformation we've seen in IT for a long time. It's probably the second time in the history of IT that we're really fundamentally changing how we operate IT. We're at the good old days from workstations when took to client server and now we're going to a cloud model. And when I talk to our customers, they have a huge set of challenges when you move to the cloud. I mean, an average VMware customer at this point, I think is in 4.5 clouds if I remember our survey data correctly. And then you suddenly, you're on Amazon, you're in Azure, you're maybe on Google, on IBM, you have VMware on-premises data center. And how do you connect them? How do you make sure that you don't get new silos? Because the risk here is that you build an Amazon team, they go to a re-invent, they carry the Amazon backpack, and they understand the Amazon APIs. And then there's a second team that is the same thing for Azure, it goes to the Microsoft conference and knows their APIs. And if you ever want to move an application across or move a team member across, it's really, really hard because it's a completely different methodology and functionality. And one of the hardest problems there is networking because we had one customer, they basically said, look, we're now in 4 different clouds and we have an audit for a firewall policy and we don't really know how to start because how do you configure a firewall or similar functionality in these different clouds is completely different. The capabilities are completely different. And thinking about this a little bit, we realized that's a real opportunity for us at VMware because today what NSX allows you to do, it allows you to essentially span a network across heterogeneous hardware. It can take a Cisco switch or an Arista switch or any other switch underneath and NSX can create a virtual network across. So why can't we do the same thing with public clouds? Well, why can't you? It's so hard, isn't it? I mean, it's hard. I haven't heard one person said, I'm moving workloads between Azure, Google and AWS. I haven't heard one person. So moving them is hard and it's primarily hard because of the services, right? If you're just going in Amazon, many companies, they want to use the Amazon services. They have great services, their databases, their message queues and so on. But they all have proprietary interfaces. Once you use them, you pretty much can't switch around anymore. Now there's other companies that are a little more disciplined about that. They're basically saying, look, we have a white list of services. We have some abstraction layers in between. And I know one customer that started out in Amazon then moved to Google. So it's certainly possible. I think it'll be the minority. I think most customers, if they build an application on one cloud, they'll stay there. But the interesting thing is that even if you stay in one cloud, you have the problem of how to create networks across these clouds or how do you get consistent policy, consistent compliance? I think that's why NSX really shines. It's not about moving around workloads, it's about giving the IT team powerful tools that can manage these workloads across all these clouds in the same way without getting the way of the developer. So as a technologist, this is what I always like to look and squint through all the vendor talk from the different clouds, specifically Microsoft. Microsoft just seems like they've cobbled together their cloud. Google seems a little bit more pure on the technology side when they have their weaknesses but also strengths there. And AWS just is just great. But again, if you use AWS, then you got to go over here. Where, I mean, where's the hard, just technical problem? Is it the database? Is it the middleware? I mean, where is that line where something's gonna be completely abstracted away as a service? So at some point, you have to have services that work together. So some sort of standardization, where's that hard on top? How far up the stack does that go? Is it the database? Is it just containers? Kubernetes, all this action? I think we're looking at the future here. So here's my best guess, right? I mean, it certainly feels like the base virtualized server abstraction that's getting commoditized to some degree. So very basic storage is getting commoditized. At the same time, we see huge differentiation to this in terms of services on top, right? I mean, the Amazon has by far the largest catalog. Google has cheap storage. Microsoft is very aggressive about licensing their own products on top of Azure. So I think what this will lead to is that the way I think we're seeing is that customers are using different clouds for their specifics of best-of-breed properties, right? And the result is you're in multiple clouds and that's, I think, where in the next years, that'll be where many of these challenges come from, right? It's a little bit like the days from HP Unix where Solaris was AIX, I'm probably dating myself here, right? But where you have silos, right? And how do you break up these silos? Well, then those silos were disrupted by Linux. I mean, AIX and some of these Unix proprietary mechanisms. Exactly, but at X86, we suddenly had one common platform and then with virtualization, you could go across. All right, so now, if I'm a CXO, I got to look to the future as well. And the good news is I don't have to make these big upfront investments like he used to in the past, but I still got to make some sort of directionally correct decision. But I don't want to make a decision where I'm going to foreclose benefits downstream. What advice would you give your friend who's a CTO or CXO at a company in terms of current move on the table? How do they, what's the next step? So, look, the cloud is here and I think you should use it, there's no question. It's going to be a long transition. It's going to keep us busy for many years, right? I mean, there's various predictions, but even the most optimistic ones, the majority of workloads will still be on-prem, you know, five years from now, possibly longer. The, I think, when you move into the cloud, do it in a thoughtful way, right? Experiment, but then think about how do you scale this? How do you make sure that, in order to get your real production applications running up in the cloud, right? You have all the same compliance requirements, security requirements, you know, operational requirements, cost requirements, you have on-premises. I think that the biggest challenges for a CIO are probably in the people organizations, right? How do I change my classic silos? How do I, you know, get people? So, personnel is a big persona at the. I'm a techie, but I always think it's easier to change technology than to change people, right? And really, leveraging clouds to the fullest potential means you have to change processes, you have to change. I quit, I was dating myself on theCUBE, certainly this past week was my birthday, so that's one of the reasons why. Congratulations. We were talking about the mainframe days, because I was breaking into the business in the late 80s when, you know, we, the emerging technology was, you know, the OSI model, mini computers and LANs, and as you saw, PCs. The mainframe guys were the old school guys clutching on to their budgets, and ultimately didn't go away, but reduced significantly down footprint-wise. And some people just would never give up. But some people were smart and said, hey, I better get on this networking protocol for the bandwagon. I'm not just gonna use SNA for your IBM or Decnate if you were a deck. You got onto TCPIP, which then the rest is to run. We're in kind of a similar shift. I think it's true, yeah. What, if TCPIP was a disruptive enabler back then, what's the disruptive enabler today from your mind? Is there one? That's a great question. Containers? I don't see containers a little bit. I mean, the big difference I think between TCP is that TCP just connected existing infrastructure. Well, containers is really an infrastructure to build a different type of application. The hard part about containers is not that it's difficult to learn. It's not, they're very easy to learn. It's that if you have a classic high availability on-premises app and you want to move it to containers, you probably have to change your app. You have to get away from a high availability model more to a distributed model that's more fault tolerant. So you have to retrain your people to build applications in a different way. Well, I guess the question that I'm just kind of riffing out a lot with you on this one is a good conversation, is that, okay, I just don't want to get locked in. I'm a customer. Because you don't want to get locked into, back then the networking protocol was the lock-in spec. So I'm trying to kind of tease out, how do I get the maximum choice, but yet the flexibility to do multiple class? Because if I want to switch from Amazon to Azure, or Azure to Amazon or vice versa, I want to be able to do that pretty quickly. So if, I mean, so first of all, I'm not sure that there's two philosophies there, right? If you want to be able to switch between clouds, then yes, I would containerize things as much as I can, right? I would use abstraction layers for services as much as I can, right? If you do all these things, you're leaving a fair amount of functionality on the table though, right? I mean, it's like, you know, the other approach I've seen is that people are saying, look, I'm going to go to Google because I want to use Google Translate for this application. And I'm going to go to Amazon because I like their, you know, next generation relational database. Or IBM because they got Watson. IBM, they got Watson, exactly, right? And maybe Google for cheap storage or something like that. I mean, there's this of best of breed applications. And if you do that, right, then you sort of, so it's as much about how do you connect as it is about? So APIs or tokens or whatever mechanism. So if I take that example, Google Translate, IBM Bluemix, that's clearly the differentiation that they're doing. Correct. So now how do I connect in? To, I mean, I think you're going to place at least some of your compute resources in each of these clouds, right? I think if I talk to customers, every customer tells me they want to be in more than one cloud, right? It's a very consistent message. And, you know, my prediction is a typical large enterprise in the future will be five or six clouds because it's best of breed, because, you know, once you're in, it's hard to have to switch. Their differentiation is unique to what they need. The differentiation, and once you're in there, once you start using Google Translate, it's hard to switch, right? It's hard to get on. All right, so here's a tough question on that one. So let's just take that forward. So you're, you've got a customer that wants to be in multiple clouds, makes total sense to me. Now, where's the data? Where's the data set? Because now with real-time mobility, we just had the end-user computing guys on. Great. Now I've got to get the data from Azure. Is there a latency? So then it comes up the whole data architecture. Is that where the whole NSX thing comes in? Where is it? It does. I mean, I think the short answer is, look, moving data is much harder than moving code in the age of cloud, right? So the data is probably going to sit where it was close to where it was generated. Or, you know, it's great. You have all your clickstream from online advertising. It's probably going to sit in a Google server, because that's where, you know, it's easiest to get it from, you know, from your AdWords account. And so you do some processing there. And maybe your customer database is still sitting on-prem, you know, and you have your, some web-facing app on Amazon. Again, it comes back to how do you connect these? Right? And it's, if you look at what was happening- How do they connect? How does a customer connect them today? Today? Yeah. Today it's mostly VPNs. You know, you have tunnels. I mean, I've talked to customers that have hundreds of tunnels that there's one. I think 600 is the record I've heard. 600 individually managed tunnels to different cloud apps. It's a complete nightmare, right, in terms of management. So we need tools to structure that in a better way. And that's, you know, something where we think we can help with that. So tell me about where VMware is at now. What's your roadmap? And as you look within the organization, as you look at cross-cloud, which you can argue that if you believe what we just talked about, there will be a cross-cloud architecture. Yes, absolutely. Where is the state-of-the-art today? What's shipping? What's available? What's the real? What's kind of future? So at this point, everything you've seen in our tech previews, like we haven't announced any ship dates yet for cross-cloud offering. You know, what we've demoed is a couple of different products. I mean, we're starting with NSX, as you mentioned it. So basically, it's a SaaS version of NSX. And by the way, there's a similar functionality coming for on-prem version. So you can have either. If you want to install it yourself here, you can still do that. And basically, it allows you to stretch networks across clouds. So I can say, you know, I have a couple of workloads on Amazon, a couple of workloads in Azure, and now on a private network. Or, you know, a couple of networks on-premises and now on a private network. And we can not only, you know, have your own layer, two-layer, three-networking and load-brancing firewall, and we can actually encrypt these networks, right? So even if somebody hypothetically would break into Amazon's network, they could no longer get access to the data. It's an additional layer of security to make your applications more resilient. So you guys can create kind of that overlay, if you will, between the networks, and then control the transit across? Exactly. I mean, the same way how we create overlay networks in the data center today, in the future, we're doing it across clouds. All right. What's the coolest thing that you're working on right now? Yeah, look, I am super excited about the cross-cloud services. They have the network and product, right? We have a costing and monitoring product, you know, which is very cool. We sort of a migration service. It actually allows you to move a workload across clouds. Yeah, we have, I'm a huge fan actually of Arcane, which is network monitoring. So it gives you a nice visualization of all the traffic flows, or at least you understand what's happening, right? This whole transition of VMware from, you know, on-prem to providing SaaS services for the public cloud. I mean, this to me is the future, but I'm very excited about it. Yeah, I mean, we've always been talking about inter-cloud and kind of a goofing on the internet working, and this really seems to be the interoperability question comes on the table. One of the interesting things I want to get your thoughts on, Tuesday night at, in Vegas last week, during James Hamilton's presentation, James is the infrastructure guy over at, great guy. He talked about a bunch of different things, one in particular that I want to get your thoughts on. As you can see, Amazon's essentially putting their own data center in the cloud at large scale. One of the things he mentioned says, when people touch the packet, you want to reduce the number of people touching the packet, mainly because latency and QoS like stuff. Do you believe in the same concept and does VMware take that kind of approach to managing how many people touch the packet? I think it actually makes sense to me, right? I mean, if you have a complex network architecture, we have many hops in between, right? You know, your latency is going to go up, your transfer rates are going to go down. I mean, I think that the philosophy we have at VMware is to say, look, aim for very simple networks underneath. I create a simple ECM layer three fabric, right? You know, it's cheap, so over provision, you know, to the max, they use your low latency, it gives you a high throughput, right? And then the only other point where you touch it is either in the hypervisor or in the instance, right? And in this one touch point in software, right, you do all your firewalling, load balancing and so on, right, unless you have, if you have specifics of high security needs and you may have put a power out or a five in between, but in many cases, you can just do that sort of on the shortest path, right? So I think we're aligned there. I think this is the architecture of the future. What's your thoughts on the misconceptions that most people, when you look at some of the press articles out there or just common conventional wisdom around cloud, and what do you see that people should take note of that's either not true or a misconception around the reality of what's happening? Is there anything that jumps out at you? Yeah, I mean, is it whether it's cloud washing or some sort of, you know, debunk something? I mean, help us identify something. That's not true. Look, it's in these so big transitions, right? What always happens is the future is here, it's not equally distributed yet, right? So people are in completely different pages in terms of, you know, to what extent they've embraced it, understand it and so on, right? I think, you know, one thing is, I'm probably projecting here, you know, when I started, I got started with the cloud. I mean, my first thought was, look, if a customer moves to the cloud, all of the IT problems disappear, right? You know, everything is managed, you don't need to update things anymore. The IT department is useless, right? And, you know, boy was I wrong, right? You know, once you start to actually people who've run cloud applications at scale, right? I mean, they still have to worry about security, about compliance, you know, they have to manage cost. You know, there's legacy apps, right? I mean, nobody's thinking about this right now, but, you know, everything is new and shiny. But, you know, after a couple of years, an app is in legacy mode and the IT department will support it, right? And now you can't patch it anymore because you don't have developers, you need to have put other compensating controls around it. All these things, they're still there. You're debunking the fact that IT goes away with the cloud. In fact, it becomes more relevant to your point. You know, I think it's just as relevant as before, right? The challenges, in fact, are mostly the same. You probably need less people to plug hardware, but that's about the only difference. How's that? And one of my goals I'd reinvent this year is to understand what's going on in the startup community. So I went to all the VC after-hours parties where all the information comes in. But here's a quote I heard from one of the VCs when I asked him, hey, how is your infrastructure investments going these days? Of course, he's rolling his eyes because it's not a good environment for infrastructure. And he says, yeah, it's a bummer, but the plumbers are turning into machinists and plumbers meaning network guys, right? And machinists becoming their operating stuff. So, and again, do you agree with that statement? I mean, it's a shift. I think it's true. I mean, currently a lot of what we do is way too manual. We need to automate this. We need to move this to a higher level. If it always shocks me, you know, when I was a grad student 20 years ago, I was doing network configuration, you know, and it was like enable, configure, and then you hand configure every switch, you know, within your VLAN. And today, we're still often doing exactly the same thing, right, this hasn't changed. And this has to change. We need to get to a point where it's more automated, where, you know, things are scripted, you know, where things are managed at a higher level. So I think- If I dev-assure was to solve all this. To some degree, yes. I mean, it gets us closer. I mean, I think actually it's interesting for networking. I think there will be some ops, there'll stay ops, but it'll be automated ops, right? I mean, it's dev ops in the sense that you have somebody who has a bit more of a developer mindset, and you know, it's not a PhD in computer science, but you know, it knows Python and like scripting, right? And, you know, but it's fine. I don't, there's this many challenges in networking that I think will never be completely absorbed into dev, just because networking is, apart networking is justifications, there's a second layer of defense, right? In case something goes wrong with the application, you have a second layer that'll detect exploits and so on. But I think in terms of skillset, yes, dev ops is the future. Kind of make things addressable. Final question for you, 2017, what are you looking for next year? What do you think is going to evolve on the tech landscape and the tech, as a technologist as you look out over 2017? What's going to become more clear to folks what might change for a positive? Okay, I think we'll see a lot more cloud everything, right? I think we'll see enterprises move to the cloud, gain experience with the cloud, some enterprises move back, you know, just because reality is setting in, you know, but by and large, I mean, it'll be a net movement to the cloud and it'll be a lot more sophisticated on how they use the cloud. I think enterprises will start to really understand the complexity of managing the cloud or several clouds, right? I think IT teams as a result will start pulling back some control from the business unit and saying, okay, guys, you know, and it was all fun and games when, you know, there was no vision critical apps, but give us a data breach or two, and then, you know, we're back in business here having to protect everything that's running up there. I mean, and the other thing is containers, I think containers will be, will continue to be a huge problem. Yeah, I mean, I agree with you. I think it's still going to be an engineering game. You've still got to engineer the solution, whether it's in the cloud or on, and certainly the hybrid points of that. We as software companies, we have a lot of product to build, right? What we have right now does not solve all of our customers' needs. And I'll keep up the good work. Guido, thanks for spending some time here. We are on the ground here at VMware's Corporate Headquarters. It's a beautiful Palo Alto, great campus. Talking tech, talking about cross-cloud. I'm John Furrier, your host of On the Ground here at theCUBE. Thank you for watching.