 Live from Las Vegas, it's theCUBE. Covering VMworld 2017, brought to you by VMware and its ecosystem partner. Hi, I'm Stu Miniman joined by John Troyer and we're at VMworld 2017. This is SiliconANGLE Media's production of theCUBE, the worldwide leader in live tech coverage. It shows hashtag is VMworld. There's also a lot of sub-hashtags. So if I was going to make this one, the VMworld three word, it's developers, developers, developers. Happy to bring on to the program. First time guest, Byron Schaller, who is the DevOps Practice Lead at Round Tower and Rebecca Fitzhugh, who's technical marketing engineer at Rubrik. Thank you both so much for joining us. Thank you for having us. All right, Byron, want to start with you. Both of you, I've known through the community for a bunch of years, but tell you, how long have you called yourself a developer and tell us a little bit about what you do these days? These days are more of a friend to developers, I think, than actual real developer myself, but I started writing code professionally 20 years ago, then to have kind of went into an ops role, then back into dev, and now I try to help really bridge that gap and get folks to write better code and get dev folks to have some of more sympathy and empathy, I guess, for the ops side as well and try to get them to play nice together. Yes, Byron, those of us have been in tech in a while. It's the last time I was coding. We called it programming. So I thought that shift happened like 15 years ago. Rebecca, tell us a little bit about your background, how you fit into the DevOps community. So I would say I am more of dev adjacent. So I work in technical marketing as an engineer at Rubrik. So while I do write some code and help with some of the integrations, I am primarily public facing, helping evangelize our software and work hand in hand with the developers as well. Yeah, absolutely. I mean, maybe talk a little bit about that. We know the virtualization community. What's different about the developer community versus in DevOps versus kind of the traditional administrators? One of the things that I've noticed, in my opinion is the difference between like the events, like comparing like VMworld to say like a DevOps day is, VMworld is very technically focused a lot of time. And when I go to DevOps days, I always notice that they make an effort to show sessions on culture, right? And to talk a lot about the culture of development and what we can do better as a community. Well, what's the connection here between VMworld and the developer community, right? We're the VMworld as, I don't know what, how many VMworlds have there been stew? There's 15 of them or something, at least. So very operationally focused, IT people who call themselves IT operators maybe, but even broader than enterprise architects. And now, we've been talking about DevOps for a few years. So I mean, maybe Byron, what's the relationship of DevOps to the VMware community? Really comes down to the API integration. And at what point do you stop being an ops person if you're writing a bunch of API code and become a developer? And that's become a lot fuzzier lately. Are you saying that the ops people have to become developers? They don't have to, but a lot of them are going that way. There's API explorers now that make it really easy to write rest calls and things like that to kick off jobs. And it just makes their lives easier to adopt that trend. It's not that they have to, but if they want to, it's definitely there and more so than ever has been. I definitely think that we're seeing more and more large enterprises, Microsoft VMware and so on, moving away from kind of this proprietary model and more into an open model where they want their APIs to be consumed. They want you to help improve their product and they want you to write code that integrates with their software. I have another question about DevOps, right? So developer plus operations and breaking down that wall, can you do DevOps if you don't dev, right? There are IT shops that just consume package software and they run them and they do things in the cloud and they do everything else, but that particular company doesn't make bespoke software. At least they don't think they do. So can you do DevOps without dev? No, okay. So it really comes down to the fact of most everyone writes code whether they think they do or not. They may not write core business apps, but they could write a lot of other integrations or they have like off the shelf software that they write customized reports for or whatever, but there's something going on. There's something being created. And as long as you have that thing being created, you can have a DevOps model. But I think it's a lot broader than just in house applications at this point. I mean, if you're writing a script, you're writing code, right? If you're creating Power CLI scripts or PowerShell scripts to automate something in your environment, that's code and that would absolutely fall into that DevOps mindset. Speaking of the show itself, I know a couple of years ago they had a little breakout with keynotes and they've done some sessions. My understanding there isn't a dedicated developer track or mini dev show inside of it. So what are the developers or people doing DevOps? What's attractive to them here at the show? There's always the hallway track, right? And then there's the side events like the V Brown bag and things like that where you see a lot of people talking about Ansible and other things like that that you won't see on the show floor itself. And I think with the hackathon tonight and lots of stuff like that, there's a lot of adjacent activities that are very much worthwhile. Yeah, you mentioned the hackathon. You participated last year. If I remember right, you won? Yes, I did. Your team won the hackathon. So tell us a little bit about that experience. It's the third year they're doing it. It was great. I mean, it was just nice to see a lot of folks in the community come together to build interesting things out of nothing in like three hours. And that's doing that itself is just really kind of amazing to me. But then those projects, a lot of them have carried on and got an adoption and now there's going to be some, you know, things created long-term because of this one interaction. I think that's just really special. When I've loved to seeing the difference between last year and this year's, I felt while last year was amazing and seeing the people write these scripts and these codes, it felt like it was a lot of kind of shooting from the hip. And what I've noticed this year is that there's been a lot of pre-work done by these teams, these groups, that they've been talking and communicating for weeks, planning what they're going to code tonight. That's very exciting. The code program code by VMware, or I think they call it, it actually is expanding. They're doing a lot. They're doing a lot to touch both developers and kind of the API side of the IT and what traditional IT side. Rebecca, one way to characterize DevOps or one element that I'd say part of DevOps would be time to value. Rapid time to value. We don't plan for a year, sit in a war room and hope we don't lose our jobs when we push the button to launch the next generation of whatever we're about to launch. We've recognized that that's kind of a hard way to go about launching something. So instead we're more iterative, smaller bytes, faster time to value. As you go out and talk with IT pros, like again in your commercial side, you have a product that has fast time to value. I mean, how much of a mind shift is having to happen inside IT where you can go, oh no, I could set this up in an afternoon and then maybe I could write some code around over the next couple of weeks rather than I got to plan this out for a year before I do anything. Yeah, so I mean, I think we're definitely moving from kind of a bureaucratic type of development to more of an agile where we have to iterate. And so like in my experience, like prior to joining Rubrik, I was very involved with VMware and did lots of virtualization stuff. And you would have like one major release a year, right? And then a couple of updates. And there was a lot of planning that would go into it and involved. And that gave a lot of lead time. And now like working with Rubrik, we're on like basically a quarterly release cycle. And so we're just constantly, so I think of a lot of it's mindset. So I don't want to say it's shooting from the head because it's not, but it's just adopting and moving forward and then getting ready for the next thing. There's not time to question and plan. It's we're doing this and let's do it now. Yeah, the thing I'd notice is just in conversations and in the keynote, APIs were brought up more this year than I remember in previous years. You know, you brought up the VMware code team. They've been doing the flings now for a couple of years. So even if it might not be developer centric, it seems like they're adopting some of the things that are attractive to what the developer community would do. Yeah, and there's a lot of really good marketing going on there too, especially on flings. Flings are great. And there's so many useful tools there that people just don't know about until they get the press. Now that they're talking about it, there's a really great community built up around it, especially with VMware code, I think is a great initiative. There's an awesome Slack channel that they have and just getting the word out and more than word-of-the-mouth and getting that into keynotes is so key to helping reach everybody else who's not already there, right? And it's, word-of-the-mouth only goes so far, but when you have the CEOs getting up there and talking about this as a core initiative, that's really important when you see more of that. Anything specific around the flings that you could highlight, like this one was really cool and turned into something or? The HTML5 client was a fling forever and it was so much better than the actual web client. And now it's becoming the actual official-supported client and the older clients going away, finally. Everyone's happy about that. It's very, and there's stats feeder. It's a super cool one that not many people know about, but you can get all this information out of your vCenter, pump it into some kind of no-SQL database and make these really creative reports that there wasn't a way to do that before that existed. It's something that's really cool. Byron, as you go out and talk to IT pros and IT departments, you're trying to be a trusted advisor, you're bringing along a team from your company. Are there elements of cultural change or kind of adaptability that when you go into a conference room and start giving your first presentations and the questions that get asked, do sometimes you go, what are the signs that you're going to go, oh, this is going to go well, versus, oh boy, these folks are not ready yet. So we tried to ask some probing questions to kind of pick a fight to be totally, not really pick a fight, but see who's going to take the bait, right? And then how that communication resolves itself. And seeing that pattern happen, you know, okay, there's something missing or something as far as how the team constructed that leads to this animosity, right? And finding that out as fast as possible and then finding out a way to remediate that is how you get that cultural change. But until you actually see it organically, it's hard to say, well, you know, just be more empathetic and hug it out. That all sounds nice, but you've got to really find, you know, what the dynamic is that's causing like the tension or breakdown. Are there any particular signs or a good point too? Yelling is a good one. And that's a positive sign or a negative sign? Both sometimes. That group's not invited to this meeting, right? It's just a lot of finger pointing. It's a lot of you can tell they don't talk. And a lot of it starts with just having a conversation on a daily basis of what do you do? What's your job? How can I understand that and have that empathy? Because until you have that empathy, no one's going to care. And once you build up that and get this understanding that, oh, what you do is valuable to the business as well, then people start to actually, you know, work what, I don't know, be friends or something at work. I don't know. It's really important to build that up. Byron, your title has DevOps in it because you're addressing a function. But should there be people inside IT groups with the DevOps in their title? If you're here at VMware and you're kind of Cody and you're a little bit interested in that, should you be looking for something, a title of DevOps? I think anybody can do DevOps. And I think that's something that we need to change our mindset on. Because I hear a lot of people say, well, why would I join the VMware Code community? I don't write code. And it's anybody can write code, right? It doesn't have to be the most beautiful, elegant code in the world. You just creating a script, you've done it. Now contribute, right? Put your work on GitHub. Let other people use it. You consume from other people. It's a community of sharing. Share. That's great. It's all about contribution, right? And it doesn't have to be code. You can write documentation. You can, you know, work on bug reports. There's so many things you can do that are not code related that people can give back with. And that's the important thing there. It reminds me a lot of just some of the discussions we've been having about community in general for a while. Rebecca, we're here at a big show, 20,000 plus people. Do you spend all your time at meetups though? How do you deal with reaching kind of a broad community? And is it kind of smaller, more intimate things? I try and balance both. Because I have obviously work obligations and I have speaking obligations. But I do try and spend time one-on-one with people as well as group functions. And I personally like to get out of my comfort zone. So that was one of the big reasons like I attend certain events, especially like the hackathon last year is, my code is rudimentary. I don't want to pretend like I am some amazing developer. But that was me getting out of my comfort zone and interacting with that community because I knew that was a community I wanted to be more a part of. Yeah, I guess the question is too from like your marketing role. Do you have to go reach out to those thousands of meetups or how do you balance that kind of small versus large? Yeah, yeah. So yeah, I think like in a large group it becomes sort of an echo chamber in a way where it's more of you talking at them than talking with them. I personally prefer to be in smaller type sessions as well as one-on-one type discussions. I think we get more out of it that way. Well, you mentioned DevOps days. That's a group independently organized all over the world. Kind of a meetup user group on steroids all day. You've been to some of those, you said. Yes, so one of the things I noticed from like DevOps days that's different than a lot of user groups is a lot of user groups will jam pack the schedule and you might have a 15 minute break there and then you have lunch and then that's it. Maybe a social hour afterwards. DevOps days, a lot of them create free spaces of an hour or two hours. And sometimes I think the one, I'm attending one in Detroit in September and I was looking at the schedule and I think there's a three hour block of just get, talk to people. Go and find your little community of people, talk to them, spend time with them and then move on to another community and get to know each other. If I were anything on the open source community and how it is different than a little bit maybe than this one here? So the V community, if you want to call it that or this has been built up is very unique from an enterprise software standpoint. No other enterprise software company has what VMware has with that. And it's a lot like the open source community. I mean, if you go to something like Oskan or something there's the same kind of interactions, the same kind of feel that we have here. Helping each other. Yes, I mean, it's all about reaching out, saying, I don't know how to do this. Someone help and people are saying, okay, this has worked for me, this hasn't. And just that feedback loop. And then once you pay that forward to five more people, that's just really, really great. And you see it with the hang space here, the community sessions and things here. There's just so many people that want to volunteer and give back, but there's not enough time to have them all speak. And that's awesome. That's why we have things like V Brownback, right? Yeah, right. The tribute there. Yeah, so there's so many different aspects of what's going on at the show. I'm curious if you have any, if you were talking to VMware and say, hey, next year, VMworld, you should do this. Anything you'd like to add? That's a really good question. It is a very good question. I mean, personally I'd love to see more developer track type items, especially as VMware is moving towards more consumable APIs in our platform. So I'd like to see more in that realm. Yeah, there can always be more work around that. I think I'd like to see more interaction from the VMware devs themselves. Talking about stuff going on inside VMware as much as they can, I guess. That'd be super interesting. You don't see a lot behind the curtain stuff here. And I think that would be neat to see more of that. I always love to look at the similarities and differences between those communities. We've done Red Hat Summit for a number of years. I'm going to beat the open source summit coming up soon. We're at Amazon re-invent where the enterprise folks and the developers always argue about which keynotes for them versus the other person, and it's striking that balance is always tough. Well, Byron, Rebecca, thank you so much for joining us here. Really appreciate your insights onto what's happening in the community, and thanks for all you're doing there. For John Troyer, and I'm Stu Miniman. We've got lots more coverage here in three days of theCUBE at VMworld 2017. Thanks for watching theCUBE.