 Live from the MGM Grand Convention Center in Las Vegas, Nevada, it's theCube at Splunk.conf 2014. Brought to you by headline sponsor, Splunk. Here is your host, Jeff Kelly. Welcome back everybody, I'm Jeff Kelly with Wikibon, you're watching The Cube and we are live at Splunk Conference 2014. Excuse me, I'm getting ahead of myself. Looking forward to next year's show as well. Joining me now in this segment, we've got Donnie Perkholz who's an analyst with the Red Monk and John Rooney who is director of developer marketing with Splunk. Guys, welcome to The Cube. Thank you. So, one topic we've been hearing about over and over on The Cube with the various Splunk customers have come on is this concept of DevOps and Splunk enabling those organizations to rapidly develop and deploy and redevelop applications to serve their customers. Why don't we start, John, with you and talk a little bit about Splunk's view of the DevOps movement and why that's important to kind of your customer base. Sure, well I think if you begin with some of the fundamental principles of DevOps and Donnie and Red Monk's done a lot of really great work in that space, the idea of in order to be more responsive, in order to kind of turn the feedback cycle very quickly. It's something that GE Capital talked about in the keynote here at the conference. What you essentially need to do is transform some of the traditional stovepipe roles between operations and development. So it's no longer the idea of, hey, it works in my dev environment, I'm trucking it over the fence and there's this very different set of responsibilities, different set of concerns. In many cases, different set of tools and systems between those roles. From a Splunk standpoint, now obviously there's a big part of that that's cultural, there's a big part of that that is practice-based, but ultimately there is now an emerging set, pretty varied set of tools and systems that are sort of driving these processes at our customers, whether it's a tiny startup or a gigantic enterprise. And from our standpoint, it's all machine data, it's still outputs machine data, it still provides the type of opportunities for us to correlate that data, provide insights, provide real-time analytics into seeing, okay, when this machine, when someone checked in code into a code repository here that kicked off a build on a build server, that's an event, that's a machine-driven event that you can put into Splunk and have that view overall. So we think about Splunk as being an enabling tool and it's something we've seen in our customers. So maybe we take a step back, Donnie. And again, welcome to theCUBE, thanks for coming on. So we hear about DevOps a lot. And as I mentioned, we've had a number of Splunk customers on that kind of talk about DevOps, but we've had a hard time really pinning it down. I mean, can you give us a little bit of a DevOps 101? I mean, from your perspective, how do you define DevOps? Sure, absolutely. So there's a lot of different ways to think about it. And I think John put a really nice summary in that they fall into two camps. You've got the tooling and then you've got the culture, right? The organizational side of it. How do you make it happen in a company? And there's a lot of disagreement within the DevOps community about which one of those should come first, which one should come second. Does the tooling catalyze the culture, which is my belief? Or do you have to change the culture first and then bring in the tooling? Which some other people believe. And I think the easiest way to just sum it up in one sentence is you take agile software development and you carry it through to production. You take that same idea of iterating rapidly over short cycles and just carry that iteration cycle a little bit farther down the road so that you're iterating not just from development to a completed build but from development through test to operations such that if you want to you could even deploy it to customers. And the bigger picture view though in my mind and where we start talking to some businesses about it instead of just talking about how technically fun it is is you think about, okay, who's on the other side of the developers and who's on the other side of production support? And it's the business and the customer. And so from the business level and if you hear Adrian Cockroft who used to be at Netflix talk about this, he'll tell you the real benefit of a DevOps approach using continuous deployment is you can iterate more rapidly than your competitors. You can ship features faster and you can learn based on the customer receipt of those features. So if you're being agile software and you build something but you still at the end you're not shipping it until 18 months later in many cases. You're just doing agile development and not agile delivery. And so you're not able to learn and iterate on the response to those features. So what's driving this? Is it the consumer side where consumers with their smartphones, we're expecting applications to be upgraded and updated frequently to when there's a bug found we want that fixed right away. Is that driving it or what are some of the things in the background that are pushing DevOps in the forefront? I think every time a new movement comes like this in technology it tends to be driven by changes in technology itself. If you look at configuration management for example which is one of the key tools behind DevOps what you see is that there's generations that come out in response to things. So CF Engine came out in 1993, it's 21 years old and yet DevOps was not an idea until 2008, right? So that came out but it never really picked up because there wasn't the requirement for transient scalable infrastructure. Then suddenly 2004, 2005 here comes the cloud and you have this whole new generation coming out to cope with high scale. You have to have everything maintained in code because you can't hire enough admins or you're hiring admins for peak instead of for typical use case and it just didn't work out financially. I think a lot of DevOps has been driven by the need to respond to what's happening out there in the marketplace from the point of view of the cloud in particular. So talk about the role of data and developers being data savvy in other words, all the data that's coming back to them from their applications that are out in production they've got to be able to sift through that, analyze it and determine where do we need to develop new solutions to fix these problems. Is that a new role for the developer and how are they adapting? I think what we've seen as developers have always loved data. We publish quite a bit of data driven analysis and every time we do a piece of data in it it gets orders of magnitude more traffic than anything else we do. So they've always loved data. The problem is they haven't always had the tooling to work with it and to understand it and a lot of that's changing with the whole data science thing, right? You've got Hadoop and Big Data but you're also empowering developers and this is I think something that John could talk about some which is splunks ability to empower developers to sort of democratize access to this data because the thing that's happened sort of in the pre DevOps days and even with companies that have shifted to a DevOps approach is the data is still very siloed and inaccessible so that developers want the data, they want to understand how customers are treating their code and production, what kinds of crashes are happening but in many cases that gets rooted back to ops and stops there and the developers never hear about it or maybe they don't even have the resources to deal with it because they're on to the next project. So the data is out there now, the tooling is starting to happen everywhere. It used to be that the web always had a lot of access to data. Mobile apps was much more challenging but that's changing, a lot more instrumentation exists so that you can get the data with DevOps tearing down all the silos, you can get access to the data and they've always wanted the data, the problem is doing something useful with it. Right, so John, expand on that a little bit if you could. The idea of breaking down these silos as Donnie put it. Yeah, and I think in all honesty I think we just happen to be luckily in the right place with the paradigm of working with Splunk, the initial paradigm of working with Splunk which actually predates the official birth of DevOps in 2008 or so was, oh well if the data's all in one place and the developers have access to it, you don't have to tie up SysAdmin to have to SSH in a machine and grab the logs. So the data's already there so the developers can have access to production logs without infringing on the security or access controls of a production system. That was something that was sort of just always built into the mental model of Splunk which just happens to dovetail really nicely into the notion of when there are shared responsibilities and there are shared tools between development, QA, operations, the flow is very different, the responsibilities are different and we just happened, that was always sort of built in so the developers don't have to nag somebody, the data's always right there and you can empower them with that data and again, the acceleration of things I'll go back to what Donnie said about the cloud and I think from my perspective and what I've seen, I think the cloud has been a huge driver of breaking down the barriers between ops and traditional development if for no other reason that kind of the canary in the coal mine for the cloud was in many cases developers bypassing IT to spin up instances in AWS or Rackspace or Azure or whatever it was so all of a sudden they're in the infrastructure game even if they're not in the infrastructure game that explicitly and then just the nature of cloud when all of a sudden you're architecting applications for the cloud instead of a past model where you're separating kind of the code layer with the data layer well then that's now all of a sudden as a production engineer you're now aware of application architecture so I think all of these things have contributed to sort of blur the traditional lines between those roles. So what steps are you taking to really cultivate the developer community? To attract them to Splunk, to reach out to them and kind of build that community momentum anytime you're trying to attract developers you need to get the community involved. I think there's sort of two ways we think about it and Stephen Sorkin who was here earlier I'm sure talked a lot about sort of our partner community and the kind of traditional when people think of a developer ecosystem that traditional sort of Apple, Microsoft I think Salesforce is doing a great job with the idea of having other people build apps and essentially run businesses off the platform and that's one thing Stephen's talked about where we're going to really ramp up our efforts there but I think kind of the first order place where we think about our developer community is our customer community, right? So one of the great things about Splunk is it really is a multi-purpose platform so when there's Splunk in an organization it can add value to security professionals, your IT and developers and all of a sudden as Splunk becomes more well understood and more adopted in an organization what we've seen traditionally is it moves upstream in the life cycle so maybe somebody buys some Splunk for a traditional troubleshooting hey, my site or my system is down I need to figure out at what layer of the stack there's a problem that's just kind of classic IT troubleshooting but as it moves up, becomes more proactive let's say you're applying some security use cases and all of a sudden well why not use this as part of release management? Why not use this to monitor our QA environment or to monitor outputs for soaking stress testing the things that really lead to the handoff between dev to production all the way to the beginning of the process I mean, ourselves at Splunk part of our regular cadence of our big product release process is we have a series of meetings every month or a meeting every month and the first part of every meeting every month is data that we Splunk out of JIRA basically say how are we progressing on at the task level how are we looking at in terms of tasks and bugs and displaying that data pulling on the JIRA in Splunk so as you can see because it's really a system of interconnected tools and systems that output machine data event and machine data it's very well suited for what we kind of the core of what we do at Splunk and among your customers you mentioned that kind of land and expand strategy that Splunk has and we've heard from pretty much every customer we've had on theCUBE talk about that but from a DevOps perspective and Diane talked about does the technology come first or is it the tools and the technology that comes first in terms of the culture what are you finding among your customers are there certain customer types that are more advanced when it comes to adopting a DevOps model and what's your take on Diane's questions of the tools that come first or the culture and how do you see that balance I mean I think it's I would you know I do think that the notion of culture and you see a lot of folks talking about you know you can't just say you're DevOps you have to live it you have to empower people in the right way and I would no way want to underscore through the importance of culture and certainly from what we see a lot of it is you know a lot of it is tooling based of all the sudden you're moving to continuous integration or continuous deployment or you start working with a puppet or a chef these things naturally lend themselves to you know to folks on both sides of kind of the Dev and Ops Isle and a lot of the Ops Isle they're familiar with Splunk they know how to get logs into Splunk they know how to you know they know how to get data into Splunk so it's just another view into that piece so I think for us we may have a little bit of a bias in identifying the tools fees but again I wouldn't want to underestimate the cultural the traditional you know throw stuff over the wall you know there's a lot of work that needs to be done there and you know we're seeing it again it's sort of like cloud or big data in some cases in some of our larger enterprise customers it's tops down it's like all right we need to figure out how we're going to DevOps it up and it's in a lot of cases we're just in the right place in the ward to facilitate that Yeah, Donnie what's your take on that getting that tops top down you know C level support for a DevOps approach I mean does C level get it I mean it sounds to me they would understand the value but do they even use the language DevOps I mean do they does there need to be more education in terms of you know C level to understand you know this is how you actually implement being extremely customer focused I think it's a spectrum right there's this William Gibson quote about everybody is somewhere on the spectrum some people are living in the future some people are living in the past some people are somewhere in the middle and it's the same thing with companies in that you know there are some C level people that absolutely get DevOps they know what the term is about they know how to do it but that's not where most of us are right most of us are somewhere in the middle where you know they've heard about this term they're not quite sure exactly what it's all about but you know the funny thing is outside of IT they have a very good grasp of the ideas as soon as you explain what's behind it you're like oh so we should be more collaborative we should cooperate on these things instead of being angry at the people over in finance all the time maybe we should bring one of them on our team and send one of our developers over there so we can start working on these things together so when we start talking about the ideas behind it people completely buy into it and they understand what's going on but DevOps the term itself is missing some of that implied meaning to people who aren't deeply inside of what's happening at sort of the new wave of IT yeah I mean it would seem to me the value that DevOps delivers being very focused on the customer providing on a regular recurring basis more value to them in the form of the applications that they're using and the services that you provide that to me would seem to resonate with the C level person they may not know the term DevOps but that to me should resonate with them and if you can get them on board that's one way to start moving the culture and then you've got to bring in the tools of course exactly and I mean in fact a lot of times the most challenging C level person to get to buy into this is the CIO because they're the one who understands what's actually got to happen down at the bottom level and so like wait so we're going to ship code 80 times a day but isn't that pretty risky you know isn't that going to mean like oh that means we could crash our customer systems 80 times a day and you really have to break it down and think about what the risk looks like and you know my point of view as you think about this all right imagine you're delivering to customers once every six months chances are good that there's one critical bug in there somewhere and you're going to have to roll it back and wait till the next delivery window for everything else that went along with it right it all comes in one big piece you get all or nothing whereas you think about it from a continuous delivery point of view and you can ship one little micro feature every day and make things a little bit better have a little bit you know more competitive solution than the other companies in your market and you've got the same overall level of risk but you're spreading it out such that you can get the benefits of the code that doesn't have critical bugs in it and you know you can roll back to little pieces that do and fix them and ship them the next day and you know that requires some this is a change management challenge as much as a technology challenge and an education challenge and John we're close on time I want to give you the last word so what is Splant's approach we talked a little bit about this about developing the developer community but you know going forward when we're at Splant conference 2015 where do you hope to be in terms of I mean DevOps perspective yeah I think you know as we you know we haven't talked a lot discreetly about the tooling I think you know one thing that you know Godfrey talked about in the keynote is the idea of it's a great platform it's widely extensible to platform I've been working on dev platform stuff my entire time here but it'd be great to also have some solutions so we know that there's a discreet set of tooling that lots of folks use that are really popular so it'd be great to have some you know whether we build them or our partners build them make them available to the community to say hey if you're using this as a build server if you're using this as a code repository here's a here's an app or here's an add-on or here's a connector for that to make it really easy because a lot of our customers that are doing really exciting cutting edge stuff from a DevOps standpoint they've you know they've really dug in and they've built it out themselves and we're great we're reporting that in a lot of ways but as in any sort of technology adoption curve you know sort of move up faster you need to make it a little bit easier so I think that's what you'll see from us I think you'll start to package some of this up package some of this up a little bit better and as more of our customers more of our organizations that we work with as they looked to sort of step in the DevOps we want to have stuff ready for them that's fully baked so I think that's where we'd like to go great well John Rooney from Splunk Donnie Burkholz from Redmont guys thanks so much for joining us on theCUBE important topic we're going to be keeping an eye on this over the next 12 months and you know we'll be back here next year and we'll see where we stand so keep it right there we're going to be right back we've got the rest of the day live coverage here at Splunk Conference 2014 in Las Vegas we'll be right back with our next segment