 Great, we are back live here in, was formerly Sonny Las Vegas, Jeff, it's not Sonny Las Vegas anymore, Stormy Las Vegas. I've just checked the Twitter feed, people are saying there are flood advisory, so everyone take care of yourself, watch out for small pets and dogs. So I'm Jeff Frick with Silicon Angle, we're here at Splunk Comp 2012, we've been going at it all day, a lot of really interesting companies that are using Splunk to change the way they do business, getting a lot of data out, not just data anymore but really information, actionable information. So it's a lot of excitement. I'm here with my co-host, Jeff from wikibon.org, the preeminent big data analyst in the industry. Is that what... Well, that's what... I won't dispute that if you want to say it, but thank you so much. You're very welcome, Jeff Kelly. Welcome back everybody, having a great day here at dot com, thanks of course to Splunk, our sponsor for bringing us here, what are you going to give you this great content. We've got another great guest, we've got Ken Cheney, Chief Revenue Officer, enjoyer me Latras, co-founder CEO, message bus, welcome guys. Thanks. Welcome to the queue. Thanks for having us. So you guys are, we're telling us a little bit before we went on, you guys aren't just a Splunk customer, you kind of run your whole business with Splunk, so tell us a little bit about what you guys do and then we can kind of dig into some of the details. That's right, so message bus is a cloud native application that provides messaging services across email application push notification and various other message types that you could think of that branch out into the entire world. So we send lots of messages for various different customer types, some of these are receipts for financial transactions or password reset notifications, others are marketing messages or newsletter notifications, and they have different sort of tiers of priority classification and things like that. So we do that for a broad range of our customers. We have relationships with our customers based on their volume. So one of the key ways that we've implemented Splunk initially in our company outside of the normal sort of IT monitoring and notification filtration, things like that, is that we allow our customers to see into their billing profile on a regular basis and actually correlate charges directly to log lines coming straight out of the machine code that's being generated as we send their messages. We can see not just the billing information as well, but we can also see response codes from feedback loops that are subscribed to and also we can see full stream information, message by message, user by user, so that they can really do a deep dive on the data on their own time whenever they want. We also give them canned reports which come straight out of Splunk. But those are some novel ways that we're using it. There are some other very novel ways that are. Yeah, I mean it's the typical customer type that we're dealing with is pretty comfortable with the types of tools like Splunk that we're using. What we encounter is that folks are actually looking to remove CapEx from their environment. And so they come to us and we allow them, if they're an app dev, to quickly bootstrap that app and get it up and running with messaging services or an enterprise may be sending, as he was saying, critical announcements, things like that. But the point being is that at the end of the day, these customers, when they interact with us, they're actually, we eat our own dog food. We leverage Splunk heavily across multiple business processes and we expose where appropriate to our customers the information that Splunk provides. And like you said, so as folks are trying to reduce CapEx in the 21st century sort of compute model, they all want to get away from owning their own servers, from owning licenses for software that they'll go put on a shelf somewhere. And when we started dreaming about how we were going to provide a cloud native application to folks, we knew that we had to be in multiple clouds. So one thing that's kind of interesting to talk about with our, with regard to our Splunk story as well as just our general business story is that we have a presence in every major cloud provider in their public cloud. And then we also have various types of private cloud and hybrid pieces to our own business. So we're in rack space right now. We're in Amazon. We're in joint. We're working with the Azure crew to figure out how we best fit into that, that environment. But that allows our customers to be, to choose their own provider. And we're right there native to that. Now, how does that play into the Splunk story? Well, we have a Splunk instance in each and every cloud. And you can imagine that collecting data in each cloud and then trying to figure out how to piece it all together is a pretty difficult thing. But it's so simple with Splunk because we just say, okay, these are your forwarding nodes and this is your master node. And we can do a master node that's actually replicated in each cloud so that every cloud gets everybody else's roll up data, not necessarily the deep dive, but there's enough data there that you can go back and figure out sort of the important pieces of your business across the entire logging infrastructure and across the entire data collection infrastructure. Yeah, I was gonna say, there's not that many vendors out there yet who are really delivering kind of truly cloud-native application services. And when you start thinking about running across multiple clouds, it's an issue of not every cloud is the same, right? You look across Rackspace or Joints or AWS and you have specific strengths and weaknesses. So it's not that your workload is running spread evenly across those clouds. You actually are leveraging the strengths within each, right? And so our Splunk deployments are really, as you point out, you dive deep when needed for troubleshooting, but we aggregate kind of key critical metrics across that let us understand the total workload that is across all those systems at any given time. But at any given time, different parts of our workload are sitting in different spots. So are you delivering across those multiple clouds because your customers are distributed? Some in Cloud A and some in Cloud B? Or are you actually delivering kind of the cloud-specific benefit to that customer during that process that they're executing and shifting that work appropriately? So it's both. And third, it's utility or cost, right? Our ability to leverage, depending on the type of workload, the advantages of each particular vendor. So you can imagine that your customers want you to be sort of native to their environment, just defective. So you can feel their pain and sort of get in there. So that's great for us. Second, when we are going out to our customers and telling folks that we want to help automate tough business problems for them, we can prove that we know how to do that because we've automated, the entire process of going to multiple clouds is 100% automated on our side. We use OpsCode Chef to manage all those different pieces for us. So we can prove it right there. So that's the first one. The second one, survivability. If one of our cloud providers has an area, or like a geographic outage, we don't have to participate in that, right? We can bounce workload over to another cloud or another geography based on what's available. Additionally, what's fastest, what's most cost effective? That's a third thing, right? So what's most cost effective is often not a question of whether or not they've got high speed IO available in AWS today, right? With a quality of service guarantee and an SLA and blah, blah, blah. We don't necessarily want to have those conversations all the time. And we don't really want to think about what's most cost effective all the time. We do in very specific occasions. So we can set up relationships, long-term relationships with folks, to get the guarantees at the best cost where it's actually important to us and not just sort of on an, across the board basis. So- But to tie it back to Splunk, right? Splunk's giving us that visibility from a utilization perspective. Right. And we're able to pull kind of key metrics out. Right, so in this world with that much data, you're in hybrid environments, you're working across clouds. So you've got a lot of moving parts, a lot of data coming in from different sources. So prior to a tool like Splunk, would it even be possible to do what you guys are doing? Absolutely not. One of my favorite experiences at Twitter was actually finding out the hard way that when you get to the high hundreds of machines, you lose all capacity for introspection. So when you want to introspect all the way down to which disk drive is going to fail, at 500 machines, you can't really do that, that type of introspection. The data volume rolling off the machines is so high and there is so much noise, you can't detect any kind of signal at all. It's just a bunch of jagged graph lines that all confuse you. So, we feel like additionally, the fact that you can do all these natural language queries against Splunk data and against machine data and get back really effective information. That's one of the things that we presented here earlier today. One of our use cases is that we have customer questions that normally would require a developer to try and answer. We have account managers who are not technical people who don't write code for living, who have never written a database query in their lives and they assemble and create their own Splunk queries to save, make their own dashboards and dashboards that they share with customers without ever interacting with a developer. So, very technical interactions with no technical knowledge required. Those kinds of things are absolutely not possible in an assist log world, right? Absolutely, absolutely. So, tell us a little bit more about, let's take into some really kind of unique insights maybe you guys have uncovered using Splunk and some of the things, add some real color to how it's really translated into business value for you and your customers. Sure, so we have... Maybe we should cover from a process perspective. Like if you look at it from a life cycle perspective we're using it across our life cycle. So, our developers are trained up and are actively leveraging Splunk to help us from an application testing, application troubleshooting perspective. So, in terms of how we instrument, so we're leveraging essentially key value pairs to throw alerts. So, you don't actually have to have, you know, English language written in there to throw those alerts for us. So, we're leveraging Splunk heavily in that kind of dev test cycle. Actually, in our integration tests. So, as we deploy new code, our integration tests go and run the new code through with a bunch of test data and Splunk provides all the feedback from that test. What's important here is, and we should have backed up and covered this earlier, but we are a true agile dev ops environment, okay? Our developers sit with our ops folks, right? And some of them are one in the same. They're interchangeable people. Yeah, interchangeable. So, in terms of how we use Splunk and think about Splunk, we do think about it from a life cycle perspective. We think about, you know, as you're coding, how what you're coding is gonna impact our operations. And so, you know, that example we gave about how we're using it for unit testing, how that translates over then into production. It's all very real. We also use it to measure the velocity of our development team. So, we kind of carry the agile ideal of velocity around as a number of complexity points that are developed, that are delivered to the production site or the production application in a week. And that gives us some time to introspect and figure out whether or not the features that we're trying to deliver are likely to occur in the next week or two. Or should we push that delivery date out and that's actually gleaned from the code check-ins that happen. There's a log analysis that happens via Splunk at our GitHub. So, it provides us with graphs that are relevant to our operations. So, we've got the coders. We've got the account managers. And then, of course, it's the same story everyone wants to tell you about their IT implementation, right? Where we didn't know the machine was going to die until we saw this spike, right? And we've actually got that set up in such a way that we'll actually receive pages to a mobile phone if things go horribly wrong. And that's all done with canned scripts. So, I have two questions. Sure, we don't have a ton of time. But one is, I'm just curious what the business value is that you've been able to extract through all these processes. The fact that you can build a company so you guys are getting paid, your investors are going to want to get paid at some point in time and you must be saving your customers' money on the front end. I mean, what type of an ROI value proposition can you go into your customers if they switch their messaging or portions of their messaging platform? That's a great question, right? I mean, the market today that we compete in, the vast majority of customers out there that we talk to are deploying on hardware where their capacity constrained, right? So they have a huge amount of CAPEX that goes into it. Along with that, there's a tremendous amount of expertise that has to be part of the equation, understand email, understand messaging in general, manage the relationships with all the big receiver ISPs. And we remove all of that, right? And Splunk lets us remove all of that, right? It is an enabler to our business, right? It's core to what we do. And so for customers who come to us, they're able to easily move their existing messaging traffic over to us. They're able to support new, exciting applications. So we work with a lot of social media, game developers, other types of companies like that who are looking to do very interesting types of use cases. They're able to do that very quickly with us and they're able to ensure the deliverability, meaning it's one thing to just catapult messages out. It's another thing to actually make sure messages are delivered. And to that end, across our business, Splunk is helping with that, right? So if there's message problems we know, Splunk lets us know, right? That's close to real time as possible. And the question, the answer you're really looking for is that when we talk to customers who know a lot about the actual sunk costs that they have in sending large volumes of messages or just how important it is to their business as a bottom line value, they're looking at between 60 and 70% capex savings just by switching to this because you don't have to buy the machines, the network bandwidth, the co-location facilities, and then the expertise, the humans, to go and service all of those pieces. So it's a significant amount of savings to switch over to our process. And we would absolutely not have the capability to do that without the current iteration of software as it is now. The other question I wanted to ask, which is kind of interesting, let's read your Twitter background. Is there a lot of talk here at the show about machine-generated data, right? Log files and sensors and this, that and the other. But clearly, at least from the outside, looking in, the explosive growth, which may or may not be accurate, is then people turning into machine-generated data on Facebook threads and Twitter feeds and this, that and the other. So I'm just kind of curious from your perspective, kind of being there at ground zero in terms of zero to big, really fast and explosive. You know, kind of, you know, what does that really mean to you? What have you kind of, have you seen this thing go from nothing to giant? I'll tell you, the reason I built this business of sending email is because a lot of people thought that Facebook and Twitter and SMS were gonna kill email and yet year on year email keeps growing by tens of percentage points and the reason is very simple. People wanna have conversations and they wanna have relevant conversations and there are various forms, various media to get your conversation out there and Twitter and Facebook are great ways to have various types of conversations and email is still a valid form of a conversation medium and so we wanna be part of that story and watch it grow. And you're part of the founding team there at Twitter. So tell us a little bit about, you know, having you kind of transition from your role there at Twitter to this job here and how did that kind of inform working at Twitter and kind of the lessons learned there and form what you're doing now? Well, I didn't sleep for about four years. So it was probably time for it to take a little rest. In 2010. So what better way than want to start up, right? That's right. So in 2010 I decided to get some sleep. I took a long sabbatical and decided that I just wanted to go do something a little bit different. Now, about a year and a half before that, one of the people, we had an open desk policy at Twitter when we first founded it and we had a bunch of people who rented desks from us and one of those people was Narendra Roshal who was an original founder of WebShots. Great story there. He and his partner Nick Wilder were doing this incubator project and they wanted me to come help them set up email servers for their incubated companies and as we got closer and closer to automating that process we realized that what we had was a multi-tenant cloud solution and we said, wow, this might be something fun to play with. We got roped into taking some funding from True Ventures and made a real business out of it. Today we're up to 31 employees. We've got some great customers and some great stories. My friends that helped, you know, my friends that founded Twitter with me are now some of our best customers. So we're dealing with Obvious Corporation's company Lift. We're trying to work our way into Medium right now with some great folks there. They've figured out that email's now important part of that and we've got a bunch of other stories that we're going to be really excited to tell later this year. So, you know, our goal is the same way that people equate Amazon to CPU with AWS and they equate Dropbox or Box to storage. We want to be that for cloud messaging, right? When people think about cloud messaging and the requirements around that, they turn to us. We're at the messaging layer. All right, really interesting story. I mean, we're hearing some really great customer stories about the different ways, I mean, it just runs a gamut. The different ways customers of Splunk are using the tool, using the product, you know, startups. Then we're seeing larger enterprises that are kind of trying to modernize the way they handle things. DevOps you mentioned earlier, I mean, we've heard that a couple of times today about how Splunk kind of enables that more iterative approach as opposed to the old kind of a little more static silo model. Absolutely. Yeah. And just really extracting enough business, enough business value to build the business on and give business value back to the customers and continue to grow. Absolutely. It's terrific. Okay, Ken and Jeremy from Message Bus. Thanks so much for being here. Appreciate it. Thanks for coming on by the queue. Thanks, John. And we're, of course we're here at .conf. 2012 Splunk's user conference here in Las Vegas. Thanks to Splunk, our sponsor for bringing us here. Really appreciate it. Giving you this great coverage all day today and tomorrow. So we'll be right back after a quick message.