>> (soft upbeat music) >> Announcer: From around the globe, it's the cube with digital coverage of Ansible Fest 2020, brought to you by RedHat. >> Hello, welcome to the cubes coverage of Ansible Fest 2020. We're not in person, we're virtual. I'm John Furrier , your host of theCube. We've got a great power panel here of RedHat engineers. We have Brad Thorton, Senior Principle Software Engineer for Ansible networking. Adam Miller, Senior Principle Software Engineer for Security and Jill Rouleau, who's the Senior Software Engineer for Ansible Cloud. Thanks for joining me today. Appreciate it. Thanks for coming on. >> Thanks. >> Good to be here. >> We're not in person this year because of COVID, a lot going on but still a lot of great news coming out of Ansible Fest this year. Last year, you guys launched a lot since last year. It's been awesome. Launched the new platform. The automation platform, grown the collections, certified collections community from five supported platforms to over 50, launched a lot of automation services catalog. Brad let's start with you. Why are customers successful with Ansible in networking? >> Why are customers successful with Ansible in networking? Well, let's take a step back to a bit of classic network engineering, right? Lots of CLI interaction with the terminal, a real opportunity for human error there. Managing thousands of devices from the CLI becomes very difficult. I think one of the reasons why Ansible has done well in the networking space and why a lot of network engineers find it very easy to use is because you can still see an attack at the CLI. But what we have the ability to do is pull information from the same COI that you were using manually, and showed that as structured data and then let you return that structured data and push it back to the configuration. So what you get when you're using Ansible is a way to programmatically interface and do configuration management across your entire fleet. It brings consistency and stability, and speed really to network configuration management. >> You know, one of the big hottest areas is, you know, I always ask the folks in the cloud what's next after cloud and pretty much unanimously it's edge, and edge is super important around automation, Brad. What's your thoughts on, as people start thinking about, okay, I need to have edge devices. How does automation play into that? And cause networking, edge it's kind of hand in hand there. So what's your thought on that? >> Yeah, for sure. It really depends on what infrastructure you have at the edge. You might be deploying servers at the edge. You may be administering IOT devices and really how you're directing that traffic either into edge compute or back to your data center. I think one of the places Ansible is going to be really critical is administering the network devices along that path from the edge, from IOT back to the data center, or to the cloud. >> Jill, when you have a Cloud, what's your thoughts on that? Because when you think about Cloud and Multicloud, that's coming around the horizon, you're looking at kind of the operational model. We talked about this a lot last year around having Cloud ops on premises and in the Cloud. What should customers think about when they look at the engineering challenges and the development challenges around Cloud? >> So cloud gets used for a lot of different things, right? But if we step back Cloud just means any sort of distributed applications, whether it's on prem in your own data center, on the edge, in a public hosted environment, and automation is critical for making those things work, when you have these complex applications that are distributed across, whether it's a rack, a data center or globally. You need a tool that can help you make sense of all of that. You've got to... We can't manage things just with, Oh, everything is on one box anymore. Cloud really just means that things have been exploded out and broken up into a bunch of different pieces. And there's now a lot more architectural complexity, no matter where you're running that. And so I think if you step back and look at it from that perspective, you can actually apply a lot of the same approaches and philosophies to these new challenges as they come up without having to reinvent the wheel of how you think about these applications. Just because you're putting them in a new environment, like at the edge or in a public Cloud or on a new, private on premise solution. >> It's interesting, you know, I've been really loving the cloud native action lately, especially with COVID, we're seeing a lot of more modern apps come out of that. If I could follow up there, how do you guys look at tools like Terraform and how does Ansible compare to that? Because you guys are very popular in the cloud configuration, you look at cloud native, Jill, your thoughts. >> Yeah. So Terraform and tools like that. Things like cloud formation or heat in the OpenStack world, they do really, really great at things like deploying your apps and setting up your stack and getting them out there. And they're really focused on that problem space, which is a hard problem space that they do a fantastic job with where Ansible tends to come in and a tool like Ansible is what do you do on day two with that application? How do you run an update? How do you manage it in the longterm of something like 60% of the workloads or cloud spend at least on AWS is still just EC2 instances. What do you do with all of those EC2 instances once you've deployed them, once they're in a stack, whether you're managing it, whatever tool you're managing it with, Ansible is a phenomenal way of getting in there and saying, okay, I have these instances, I know about them, but maybe I just need to connect out and run an update or add a package or reconfigure a service that's running on there. And I think you can glue these things together and use Ansible with these other stack deployment based tools really, really effectively. >> Real quick, just a quick followup on that. what's the big pain point for developers right now when they're looking at these tools? Because they see the path, what are some of the pain points that they're living right now that they're trying to overcome? >> I think one of the problems kind of coincidentally is we have so many tools. We're in kind of a tool explosion in the cloud space, right now. You could piece together as as many tools to manage your stack, as you have components in your stack and just making sense of what that landscape looks like right now and figuring out what are the right tools for the job I'm trying to do, that can be flexible and that are not going to box me into having to spend half of my engineering time, just managing my tools and making sense of all of that is a significant effort and job on its own. >> Yes, too many may add, would choke in years ago in the big data search, the tools, the tool train, one we call the tool shed, after a while, you don't know what's in the back, what you're using every day. People get comfortable with the right tools, but the platform becomes a big part of that thinking holistically as a system. And Adam, this comes back to security. There's more tools in the security space than ever before. Talking about tool challenges, security is the biggest tool shed everyone's got tools they'd buy everything, but you got to look at, what a platform looks like and developers just want to have the truth. And when you look at the configuration management piece of it, security is critical. What's your thoughts on the source of truth when it comes into play for these security appliances? >> So these are... Source of truth piece is kind of an interesting one because this is going to be very dependent on the organization. What type of brownfield environment they've developed, what type of things that they rely on, and what types of data they store there. So we have the ability for various sources of truth to come in for your inventory source and the types of information you store with that. This could be tagged information on a series of cloud instances or series about resources. This could be something you store in a network management tool or a CMDB. This could even be something that you put into a privilege access management system, such as, CyberArk or hashivault. Like those are the things and because of Ansible flexibility and because of the way that everything is put together in a pluggable nature, we have the capability to actually bring in all of these components from anywhere in a brownfield environment, in a preexisting infrastructure, as well as new decisions that are being made for the enterprise as I move forward. And, and we can bring all that together and be that infrastructure glue, be that automation component that can tie all these disjoint loosely coupled, or complete disc couple pieces, together. And that's kind of part of that, that security posture, remediation various levels of introspection into your environment, these types of things, as we go forward, and that's kind of what we're focusing on doing with this. >> What kind of data is stored in the source of truth? >> I mean... So what type of data? This could be credential. It could be single use credential access. This could be your inventory data for your systems, what target systems you're trying to do. It could be, various attributes of different systems to be able to classify them ,and codify them in different ways. It's kind of kind of depending, be configuration data. You know, we have the ability with some of the work that Brad and his team are doing to actually take unstructured data, make it structured, bullet into whatever your chosen source of truth is, store it, and then utilize that to, kind of decompose it into different vendors, specific syntax representations and those types of things. So we have a lot of different capability there as well. >> Brad, you were mentioned, do you have a talk on parsing, can you elaborate on that? And why should network operators care about that? >> Yeah, welcome to 2020. We're still parsing network configuration and operational state. This is an interesting one. If you had asked me years ago, did I think that we would be investing development time into parsing with Ansible network configurations? I would have said, "Well, I certainly hope not. "I hope programmability of network devices and the vendors "really have their API's in order." But I think what we're seeing is network containers are still comfortable with the command line. They're still very familiar with the command line and when it comes time to do operational state assessment and health assessment of your network, engineers are comfortable going to the command line and running show commands. So really what we're trying to do in the parsing space is not author brand new parking and parsing engine ourselves, but really leverage a lot of the open source tools that are already out there bringing them into Ansible, so network engineers can now harvest the critical information from usher operational state commands on their network devices. And then once they've gotten to the structure data, things get really interesting because now you can do entrance criteria checks prior to doing configuration changes, right? So if you want to ensure a network device has a very particular operational state, all the BGP neighbors are, for example before pushing configuration changes, what we have the ability to do now is actually parse the command that you would have run from the command line. Use that within a decision tree in your Ansible playbook, and only move forward when the configuration changes. If the box is healthy. And then once the configuration changes are made at the end, you run those same health checks to ensure that you're in a speck can do a steady state and are production ready. So parsing is the mechanism. It's the data that you get from the parsing that's so critical. >> If I had to ask you real quick, just while it's on my mind. You know, people want to know about automation. It's top of mind use case. What are some of these things around automation and configuration parsing, whether it's parsing to other configuration manager, what are the big challenges around automation? Because it's the Holy grail. Everyone wants it now. What are the couches? where's the hotspots that needs to be jumped on and managed carefully? Or the easiest low hanging fruit? >> Well, there's really two pieces to it, right? There's the technology. And then there's the culture. And, and we talk really about a culture of automation, bringing the team with you as you move into automation, ensuring that everybody has the tools and they're familiar with how automation is going to work and how their day job is going to change because of automation. So I think once the organization embraces automation and the culture is in place. On the technology side, low hanging fruit automation can be as simple as just using Ansible to push the commands that you would have previously pushed to the device. And then as your organization matures, and you mature along this kind of path of network automation, you're dealing with larger pieces, larger sections of the configuration. And I think over time, network engineers will become data managers, right? Because they become less concerned about the network, the vendors specific configuration, and they're really managing the data that makes up the configuration. And I think once you hit that part, you've won at automation because you can move forward with Ansible resource modules. You're well positioned to do NETCONF for RESTCONF or... Right once you've kind of grown to that it's the data that we need to be concerned about and it could fit (indistinct) and the operational state management piece, you're going to go through a transformation on the networking side. >> So you mentioned-- >> And one thing to note there, if I may, I feel like a piece of this too, is you're able to actually bridge teams because of the capability of Ansible, the breadth of technologies that we've had integrations with and our ability to actually bridge that gap between different technologies, different teams. Once you have that culture of automation, you can start to realize these DevOps and DevSecOps workflow styles that are top of everybody's mind these days. And that's something that I think is very powerful. And I like to try to preach when I have the opportunity to talk to folks about what we can do, and the fact that we have so much capability and so many integrations across the entire industry. >> That's a great point. DevSecOps is totally a hop on. When you have software and hardware, it becomes interesting. There's a variety of different equipment, on the security automation. What kind of security appliances can you guys automate? >> As of today, we are able to do endpoint management systems, enterprise firewalls, security information, and event management systems. We're able to do security orchestration, automation, remediation systems, privileged access management systems. We're doing some threat intelligence platforms. And we've recently added to the I'm sorry, did I say intrusion detection? We have intrusion detection and prevention, and we recently added endpoint security management. >> Huge, huge value there. And I think everyone's wants that. Jill, I've got to ask you about the Cloud because the modules came up. What use cases do you see the Ansible modules in for the public cloud? Because you got a lot of cloud native folks in public cloud, you've got enterprises lifting and shifting, there's a hybrid and multicloud horizon here. What's some of the use cases where you see those Ansible modules fitting well with public level. >> The modules that we have in public cloud can work across all of those things, you know. In our public clouds, we have support for Amazon web services, Azure GCP, and they all support your main services. You can spin up a Lambda, you can deploy ECS clusters, build AMI, all of those things. And then once you get all of that up there, especially looking at AWS, which is where I spend the most time, you get all your EC2 instances up, you can now pull that back down into Ansible, build an inventory from that. And seamlessly then use Ansible to manage those instances, whether they're running Linux or windows or whatever distro you might have them running, we can go straight from having deployed all of those services and resources to managing them and going between your instances in your traditional operating system management or those instances and your cloud services. And if you've got multiple clouds or if you still have on prem, or if you need to, for some reason, add those remote cloud instances into some sort of on-prem hardware load balancer, security endpoint, we can go between all of those things and glue everything together, fairly seamlessly. You can put all of that into tower and have one kind of view of your cloud and your hardware and your on-prem and being able to move things between them. >> Just put some color commentary on what that means for the customer in terms of, is it pain reduction, time savings? How would you classify their value? >> I mean, both. Instead of having to go between a number of different tools and say, "Oh, well for my on-prem, I have to use this. "But as soon as I shift over to a cloud, "I have to use these tools. "And, Oh, I can't manage my Linux instances with this tool "that only knows how to speak to, the EC2 to API." You can use one tool for all of these things. So like we were saying, bring all of your different teams together, give them one tool and one view for managing everything end to end. I think that's, that's pretty killer. >> All right. Now I get to the fun part. I want you guys to weigh in on the Kubernetes. Adam, if you can start with you, we'll start with you go in and tell us why is Kubernetes more important now? What does it mean? A lot of hype continues to be out there. What's the real meet around Kubernetes what's going on? >> I think the big thing is the modernization of the application development delivery. When you talk about Kubernetes and OpenShift and the capabilities we have there, and you talk about the architecture, you can build a lot of the tooling that you used to have to maintain, to be able to deliver sophisticated resilient architectures in your application stack, are now baked into the actual platform, so the container platform itself takes care of that for you and removes that complexity from your operations team, from your development team. And then they can actually start to use these primitives and kind of achieve what the cloud native compute foundation keeps calling cloud native applications and the ability to develop and do this in a way that you are able to take yourself out of some of the components you used to have to babysit a lot. And that becomes in also with the OpenShift operator framework that came out of originally Coral S, and if you go to operator hub, you're able to see these full lifecycle management stacks of infrastructure components that you don't... You no longer have to actually, maintain a large portion of what you start to do. And so the operator SDK itself, are actually developing these operators. Ansible is one of the automation capabilities. So there's currently three supported there's Ansible, there's one that you just have full access to the Golang API and then helm charts. So Ansible's specifically obviously being where we focus. We have our collection content for the... carries that core, and then also ReHat to OpenShift certified collection's coming out in, I think, a month or so. Don't hold me to the timeline. I'm shoving in trouble for that one, but we have those things going to come out. Those will be baked into the operator's decay that we fully supported by our customer base. And then we can actually start utilizing the Ansible expertise of your operations team to container native of the infrastructure components that you want to put into this new platform. And then Ansible itself is able to build that capability of automating the entire Kubernetes or OpenShift cluster in a way that allows you to go into a brownfield environment and automate your existing infrastructure, along with your more container native, futuristic next generation, net structure. >> Jill this brings up the question. Why don't you just use native public cloud resources versus Kubernetes and Ansible? What's the... What should people know about where you use that, those resources? >> Well, and it's kind of what Adam was saying with all of those brownfield deployments and to the same point, how many workloads are still running just in EC2 instances or VMs on the cloud. There's still a lot of tech out there that is not ready to be made fully cloud native or containerized or broken up. And with OpenShift, it's one more layer that lets you put everything into a kind of single environment instead of having to break things up and say, "Oh, well, this application has to go here. "And this application has to be in this environment.' You can do that across a public cloud and use a little of this component and a little of that component. But if you can bring everything together in OpenShift and manage it all with the same tools on the same platform, it simplifies the landscape of, I need to care about all of these things and look at all of these different things and keep track of these and are my tools all going to work together and are my tools secure? Anytime you can simplify that part of your infrastructure, I think is a big win. >> John: You know, I think about-- >> The one thing, if I may, Jill spoke to this, I think in the way that a architectural, infrastructure person would, but I want to try to really quick take the business analyst component of it as the hybrid component. If you're trying to address multiple footprints, both on prem, off prem, multiple public clouds, if you're running OpenShift across all of them, you have that single, consistent deployment and development footprint for everywhere. So I don't disagree with anything they said, I just wanted to focus specifically on... That piece is something that I find personally unique, as that was a problem for me in a past life. And that kind of speaks to me. >> Well, speaking of past lives-- >> Having me as an infrastructure person, thank you. >> Yeah. >> Well, speaking of past lives, OpenStack, you look at Jill with OpenStack, we've been covering the Cuba thing when OpenStack was rolling out back in the day, but you can also have private cloud. Where you used to... There's a lot of private cloud out there. How do you talk about that? How do people understand using public cloud versus the private cloud aspect of Ansible? >> Yeah, and I think there is still a lot of private cloud out there and I don't think that's a bad thing. I've kind of moved over onto the public cloud side of things, but there are still a lot of use cases that a lot of different industries and companies have that don't make sense for putting into public cloud. So you still have a lot of these on-prem open shift and on-prem OpenStack deployments that make a ton of sense and that are solving a bunch of problems for these folks. And I think they can all work together. We have Ansible that can support both of those. If you're a telco, you're not going to put your network function, virtualization on USC as to one in spot instances, right? When you call nine one one, you don't want that going through the public cloud. You want that to be on dedicated infrastructure, that's reliable and well-managed and engineered for that use case. So I think we're going to see a lot of ongoing OpenStack and on-prem OpenShift, especially with edge, enabling those types of use cases for a long time. And I think that's great. >> I totally agree with you. I think private cloud is not a bad thing at all. Things that are only going to accelerate my opinion. You look at the VM world, they talked about the telco cloud and you mentioned edge when five G comes out, you're going to have basically have private clouds everywhere, I guess, in my opinion. But anyway, speaking of VMware, could you talk about the Ansible VMware module real quick? >> Yeah, so we have a new collection that we'll be debuting at Ansible Fest this year bore the VMware REST API. So the existing VMware modules that we have usually SOAP API for VMware, and they rely on an external Python library that VMware provides, but with these fare 6.0 and especially in vSphere 6.5, VMware has stepped up with a REST API end point that we find is a lot more performance and offers a lot of options. So we built a new collection of VMware modules that will take advantage of that. That's brand new, it's a lighter way. It's much faster, we'll get better performance out of it. You know, reduced external requirements. You can install it and get started faster. And especially with these sphere seven, continuing to build on this REST API, we're going to see more and more interfaces being exposed so that we can take advantage. We plan to expand it as new interfaces are being exposed in that API, it's compatible with all of the existing modules. You can go back and forth, use your existing playbooks and start introducing these. But I think especially on the performance side, and especially as we get these larger clouds and more cloud deployments, edge clouds, where you have these private clouds and lots and lots of different places, the performance benefits of this new collection that we're trying to build is going to be really, really powerful for a lot of folks. >> Awesome. Brad, we didn't forget about you. We're going to bring you back in. Network automation has moved towards the resource modules. Why should people care about them? >> Yeah. Resource modules, excuse me. Probably I think having been a network engineer for so long, I think some of the most exciting work that has gone into Ansible network over the past year and a half, what the resource modules really do for you is they will reach out to network devices. They will pull back that network native, that vendor native configuration. While the resource module actually does the parsing for you. So there's none of that with the resource modules. And we returned structured data back to the user that represents the configuration. Going back to your question about source of truth. You can take that structure data, maybe for your interface CONFIG, your OSPF CONFIG, your access list CONFIG, and you can store that data in your source of truth under source of truth. And then where you are moving forward, is you really spend time as every engineer managing the data that makes up the configuration, and you can share that data across different platforms. So if you were to look at a lot of the resource modules, the data model that they support, it's fairly consistent between vendors. As an example, I can pull OSPF configuration from one vendor and with very small changes, push that OSPF configuration to a different vendor's platform. So really what we've tried to do with the resource modules is normalize the data model across vendors. It'll never be a hundred percent because there's functionality that exists in one platform that doesn't exist and that's exposed through the configuration, but where we could, we have normalized the data model. So I think it's really introducing the concept of network configuration management through data management and not through CLI commands anymore. >> Yeah, that's a great point. It just expands the network automation vision. And one of the things that's interesting here in this panel is you're talking about, cloud holistically, public multicloud, private hybrid security network automation as a platform, not just a tool, we're still going to have all kind of tools out there. And then the importance of automating the edge. I mean, that's a network game Brad. I mean, it's a data problem, right? I mean, we all know about networking, moving packets from here to there, but automating the data is critical and you give have bad data and you don't have... If you have misinformation, it sounds like our current politics, but you know, bad information is bad automation. I mean, what's your thoughts? How do you share that concept to developers out there? What should they be thinking about in terms of the data quality? >> I think that's the next thing we have to tackle as network engineers. It's not, do I have access to the data? You can get the data now for resource modules, you can get the data from NETCONF, from RESTCONF, you can get it from OpenConfig, you can get it from parsing. The question really is, how do you ensure the integrity and the quality of the data that is making up your configurations and the consistency of the data that you're using to look at operational state. And I think this is where the source of truth really becomes important. If you look at Git as a viable source of truth, you've got all the tools and the mechanisms within Git to use that as your source of truth for network configuration. So network engineers are actually becoming developers in the sense that they're using Git ops to worklow to manage configuration moving forward. It's just really exciting to see that transformation happen. >> Great panel. Thanks for everyone coming on, I appreciate it. We'll just end this by saying, if you guys could just quickly summarize Ansible fast 2020 virtual, what should people walk away with? What should your customers walk away with this year? What's the key points. Jill, we'll start with you. >> Hopefully folks will walk away with the idea that the Ansible community includes so many different folks from all over, solving lots of different, interesting problems, and that we can all come together and work together to solve those problems in a way that is much more effective than if we were all trying to solve them individually ourselves, by bringing those problems out into the open and working together, we get a lot done. >> Awesome, Brad? >> I'm going to go with collections, collections, collections. We introduced in last year. This year, they are real. Ansible2.10 that just came out is made up of collections. We've got certified collections on automation. We've got cloud collections, network collections. So they are here. They're the real thing. And I think it just gets better and deeper and more content moving forward. All right, Adam? >> Going last is difficult. Especially following these two. They covered a lot of ground and I don't really know that I have much to add beyond the fact that when you think about Ansible, don't think about it in a single context. It is a complete automation solution. The capability that we have is very extensible. It's very pluggable, which has a standing ovation to the collections and the solutions that we can come up with collectively. Thanks to ourselves. Everybody in the community is almost infinite. A few years ago, one of the core engineers did a keynote speech using Ansible to automate Philips hue light bulbs. Like this is what we're capable of. We can automate the fortune 500 data centers and telco networks. And then we can also automate random IOT devices around your house. Like we have a lot of capability here and what we can do with the platform is very unique and something special. And it's very much thanks to the community, the team, the open source development way. I just, yeah-- >> (Indistinct) the open source of truth, being collaborative all is what it makes up and DevOps and Sec all happening together. Thanks for the insight. Appreciate the time. Thank you. >> Thank you. I'm John Furrier, you're watching theCube here for Ansible Fest, 2020 virtual. Thanks for watching. (soft upbeat music)

>> Announcer: Live from Las Vegas, it's the Cube, covering VMworld 2017, brought to you by VMware and its ecosystem partners. >> Welcome back everyone live, here in Las Vegas from VMworld 2017, I'm John Furrier of the Cube, live coverage of VMworld 2017 with my cohost Dave Vellante, next guest Dom Delfino, senior vice president of sales and systems engineering, Cube alum, great to see you, welcome back. >> Thanks guys, good to be here again. >> RAC are covering VMworld, the ecosystem has been a little tide goes out, tide comes in, real clarity this year, cloud, you want it on private cloud, public to private cloud or Amazon. >> Dom: Right. >> Any questions? >> Dom: Exactly. Clear. >> This is the vision coming to fruition. This is what you're seeing this year at VMworld. I think in particular when you talk to the customers, they're now in a state of cloud reality. There was sort of this big rush, I'm going to try to move as much to the public cloud as possible and then in terms of the scale they got there, they start to have then challenges on that side, they realize, I need to have a dual strategy. I need to have a private, a public, a hybrid strategy. I think you see all the announcements that we've made today, with DFC on AWS going live now, with more coming around the world in different zones as we progress throughout the rest of the year and into next year, as well as all the service offerings we just announced, Wave Run is a service, VRNI is a service, NSX is a service, app defense, which is our latest security strategy as well. Customers really see how it comes together now and they want to go down that journey with VMware. >> It's important too to clarify, I call the high level messaging, so it's got clarity, but also VMware and ecosystems has a lot under the hood and it can get very technical, so you got to balance the speeds and feeds to feed the red meat to all the practitioners and then the high level. I got to ask you the question because people that are sitting out there on this cloud reality that you mentioned, they don't have a lot of people sometimes. Someone's got to implement this stuff, automation's coming, okay I get that, but getting to the cloud is not easy. I still got to run my shop, what is that operational reality right now because cloud reality, okay I get it, but now I got to turn my on premise into a true private cloud with a new operating model, new practices, how are the VMware customers dealing with that? >> I think that's part of moving away from the legacy as fast as you can or at least where you have to keep it, you've got to sort of isolate it and put it in a corner because it's the legacy that's holding most of us back, right? Because I got to understand how to run the legacy, keep the lights on, that takes 20, 30, 40, 50% of my time, depending on the customer, depending on their infrastructure at the same time I've got to retool my skills, I've got to retool my tool kits that I use, my run books, my operational processes, but now they at least have a direction to build to. All the customer meetings we're having here today it's about software defined. How do I build this abstraction layer? Okay we've been doing this with VMware for years on the compute side, many of them have ventured down the journey with us on the NSX side, we see 10,000 customers roughly on the VSAN side as well and that's about putting together, putting the automation tool set around it and really building that same experience that they can get in the public cloud, which it's fast and it's easy on their on prem data centers as well. Sometimes there's many reasons to retain on the private side, data sovreignty, intellectual property, all of those things as well. I think that's where the customers are in the journey right now and it's now they feel comfortable with the direction and they're going to adopt quickly. >> I like this idea of cloud realities. We've been talking on the Cube today about configuring the cloud to the realities of your organization's data. You're talking about governance, security, data locality, etc. so it really comes back to a data challenge. You can't just take all your data and shove it up into the cloud. What are you seeing from customers in that regard? >> I think there's a regulatory component to that as well, particularly if you go overseas, to Europe and Asia, there's a lot more challenges around that as well. I think what you're seeing is that customers recognize the fact that not everything is going to go into the public cloud at this point, so they're really prioritizing, burstable work loads, temporary work loads, definitely a prime opportunity to put in the public cloud. New application development, definitely a primary opportunity to put in the cloud. If I'm in the health care business and I have to retain health care records for x number of years and I'm responsible for HIPPA compliance around them, maybe not something that I'm just going to shove up into the cloud today. It's use case specific depending on and application specific, depending on the vertical industry, the customer resides in and depending on where they are in their journey to the cloud as well. >> You've got a lot of momentum in your business right now. Basically you're on fire. We talked about the cloud realities, that's part of it. The AWS announcement last year, even though it was a year ahead of time, gave a lot of clarity to people. How much of the momentum is due to those factors? Again, the cloud reality, the fact that people are now more comfortable with your cloud strategy and saying okay, I'm willing to make maybe a multi-year commitment with VMware. Is that a factor? >> It is a factor, it is a factor and I think the two remaining components, accelerating and capturing momentum in the market of our SCDC strategy being VCN and NSX has also helped that reality come to fruition for customers as well. It is software defined, we've been talking about software defined data center for a long time, like everybody else in the industry, we talk about things sometimes a lot sooner than they come to fruition, but now that they put together VC ware with NSX with VSAN, and they say hey, I can actually build a private cloud that's fast and easy, which is the reason a lot of my IT people or my application developers were going around me, because the public cloud was faster and easier. Wasn't necessarily cheaper, but it was definitely faster and easier, now customers who've been on that journey with us for the last year realize they can offer the same thing on prem as well and take advantage of both. Does that make sense? >> Yeah. What's the biggest walk away for you right now, looking at VMware, if you had to talk to customers that are not here and looking at the online coverage, certainly Twitter you'll bump into a lot of Cube coverage and lot of pictures, lot of architectural slides. What's the big walk away so far, day one? >> I think tremendous innovation is the big walk away. In many different categories coming forward, you'll hear another big announcement tomorrow coming up in terms of what we'll be doing in conjunction with one of our sister companies in the application development world. But also about taking security to the next level with app defense, so microsegmentation has become fairly ubiquitously known within the industry now, how do I take that into the guest, into the operating system, into the application layer? How do I secure those things as well? You see a lot of customers getting hit with ransomware attacks this year, those are big reality checkers for you if you're the one sitting behind the keyboard that's got to defend your environment against that and rebuild it and I think they really see VMware continue to push the envelope to develop very innovative solutions to these approaches that are very cost effective and that are also very high performance. >> Personal question, as you're out in the field talking to customers, you've been in the industry for a while, you've seen the waves. What's the biggest thing that you notice, observe out there right now? What's happening? Share some color with the landscape in the marketplace. >> I think there's some good recognition from customers around the type of operational transformation that they're going to have to go through in this journey. It's not about the network independent from storage independent from security independent from computer anymore. Infrastructure is one entity, that's the way the application owners and the application developers view it and want to consume it, that's the way that infrastructure teams are going to have to deliver it. I think there's a lot of recognition of that. I think there's recognition that the security problem is bigger and badder and worse than ever and it's not going away any time soon and there's sort of no magic box. If there was, you'd pay a lot of money for it to make your problems go away, but it's really something that has to be ubiquitous. Infosect policy has to be aligned with infrastructure security implementation. I could have the greatest policy in the world, if I can't actually implement it, I'm not going to get the benefit to that security there. I think those are some of the things as well. I think sort of the container world is going through a little bit of the post high upcycle, what's the reality check of that environment as well right now, we saw this with open flow and SDN five and six years ago. >> John: Saw it on big data with Hadoub. It's so expensive to run, why even do it? At some point, it can be total cost ownership and ease of use, old school topics. >> We're well into production ready phase of software defined networking. We're well into the production ready phase of software defined storage and hyperconverge infrastructure we need to take containers into that next phase as well. >> Bottom line, what does cloud ready mean to an enterprise these days? >> Cloud ready means that application, that work load is portable and I can deliver the same level of availability, service and agility, whether it's in the public cloud or whether it's in my private data center. Or I move it back and forth between both. We're certainly excited about the momentum we see with our customers, I think you can see and hear the buzz around VMware going on this year and I think it's the best it's been in a few years. >> You run the SE team as well right? >> Dom: Yes I do. >> How does that work? SE's are like the Navy SEALS John always talks about on the beach, they, >> I like to call them the conscience of the sales force. >> There you go, right. Customer trusts them, but at the same time, they understand the customer requirements at a very deep level. How are they organized? How do they fit into the partner ecosystem, maybe you could explain that a little bit. >> Yeah I think traditionally we've organized our SE's, aligned them with product categories, so I've got networking and security SE's, I've got cloud management, automation, orchestration SE's and software defined storage SE's, but I think that sort of is the base line and then you start to build their skill sets toward solution, towards a solution. What types of solution? Is it containers on open stack? Is it VMware's STDC stack? Is it around particular vertical solutions? If you're an SE on my health care team, you're probably very focused on electronic health records and EPIC and Medtronic and different applications like that. How do you solve those customers' problems at the higher level and be able to drill down at the same time with the domain experts from those customers when they want to understand how OSPF works and NSX or they want to understand how lund creation works in VSAN. It's sort of an evolution in terms of building skills. You've got to start at the deepest levels and then you got to build to how those products and those technologies integrate together to provide the customer with a solution. >> So as you move toward this multi cloud word, throwing another buzz word, but is this cloud architect like SE role emerging? >> We'll call them a solution architect. That solution may be a cloud solution, it may be a vertical solution targeted at a specific customer base and make sure that we do what's appropriate to serve our customers. >> John: What's the coolest thing you've worked on this year? >> I've got to think that app defense is the coolest thing that we've got out this year. I think that we've solved a lot of problems with microsegmentation from a network security perspective. I think now going up into the guest and into the application layer and providing an analogous functionality there is going to be really a very very prevalent way of preventing breaches, malware, malware propagation, ransomware in the future as well. I'm a little bit of a security geek, it's attractive to me. I really see that as just an ongoing, it's not even a battle anymore, it's a war now for our customers. We want to help them win that war. >> John: Ransomware has been so brutal. >> Ransomware's been brutal and I mean, see customers almost going out of business. >> Well it's become a board-level topic overnight. It is a serious board-level topic, not just lip service. You're seeing that right? >> You will see in some circumstances boards actually pulling the chief information security officer out of IT and having them report directly to the board. >> Well it makes a lot of sense. >> John: The pressure is unbelievable. >> The pressure is unbelievable right? >> In a lot of regards you would think that the CSO certainly should not report to the CIO, it's kind of like the fox watching the hen house dynamic. Maybe that's not the best analogy, but there should be an inherent tension there number one, but number two is what's the right regime? Why is it IT's problem? It shouldn't be. >> Yeah I think it goes back to information security policy versus actual implementation and the gap that's existed between those two for years for many reasons, networking being a flagrant issue in that context, where I could say oh, this application, this user needs to talk to this application, this application needs to this set of data. How do we implement that? That's not the easiest thing with the tool set that customers who run legacy networks have had historically. I think now that we have some of those things, you'll see the scenario I just described where a few organizations are pulling the CSO out of IT and reporting to the board or some, we've seen board level mandates for segmentation initiatives within the technology area as well so I think this is going to be an ongoing battle that we face moving forward. >> This is the biggest problem I would say at the Cube all day long because part of the value proposition of cloud and dev ops and apps is having data in real time. To be liberal with the data, you run the risk of opening it up so you can't do it the old way. >> Part of the cloud adoption and the new wave of applications about moving these businesses forward, the security is one of those things that will move you backwards from where you are today. I think it's important that we be able to tackle all these battles on all different fronts at the same time. >> If I may, I know we got to go, but there's another dynamic as well which is the recognition that we are going to get penetrated and yet I think it was the third leg of Pat's slide today was response. Boards are saying it's not if, it's when. How do we respond? That's a critical part of the implementation. >> I think it's, we talk about IOT. Think about the number of new entry points you create into your infrastructure, every device you connect to the network itself. Keeping them out is a huge challenge. The question is what can you do as the owner/operator once they are inside? How do you limit, how do you restrict the level of risk that you have and exposure you have to your data, to your applications to your customer information, so on and so forth and I think that's what we've brought to the table in a substantial way with microsegmentation with NSX and I think you'll see that continue to really raise the game with app defense as well. >> Dom Delfino, great to have you, great color, great commentary, you're like a pro. He's just like a anchor with us, SportsCenter >> If Pat fires me am I in? No? >> John: You're in. >> All right. >> Pat fire him so we can hire him. >> John: Don't fire me, Pat, I like my job. >> Dom, thanks so much, good coverage, always great. >> Dave: Thank you, pleasure. >> Bringing a great attitude to the Cube, great energy. More come, day one as we continue down, wind down day one and three days of wall to wall coverage with the Cube VMworld two sets, double barrel shotgun of content here at the Cube, we'll be back with more after this short break. (electronic music)