 from the Wynn Resort in Las Vegas. It's theCUBE, covering .next conference 2016. Brought to you by Nutanix. Now, here are your hosts, Dave Vellante and Stu Miniman. We're back. This is theCUBE, and theCUBE is SiliconANGLE, a media's flagship product. We go out to the events, we extract the signal from the noise. Keith Adams is here, he's the chief architect of Slack, smoking hot company, fresh off another $200 million raise, $3.8 billion valuation. I thought software was supposed to be a capital efficient business. Well, I guess it is, but you need the money to compete these days and promote. Well, Keith, thanks very much for coming on theCUBE. That's a pleasure being here. And congratulations with all the progress, and I know you guys aren't done yet, but how do you feel? Feels less than 1% of the way to where we need to get to. So we're still just getting started. We're very proud of the 3 million users we have so far, but we think that's a very tiny drop in the bucket compared to the people that we could reach. And our goal is to affect the lives of every knowledge worker in the world. So we've got a long way to go. So as the chief architect, talk about how you spend your time. I mean, it is still early days, but you've been there since the early days, right? Sure, that's actually not the case, by the way. I've only been there about seven months. So my background's in software, I've been an engineer most of my career. I still write a little bit of code at Slack, but in practice, when I'm doing that, it's probably because I'm shirking my day job. And my day job at Slack is actually helping us make good technical decisions. And that's kind of a horizontal role that's across all the technical things that we're working on, operating the edge, mobile clients, the way that we use cloud infrastructure, our use of hardware and software, our spend, databases, storage. So we've got tons of brilliant people doing interesting work there. And every once in a while, they feel like they could use someone to break a tie and that's kind of my day job. So Keith, the first time, I had an interview with Dheeraj a few years back at VMworld, people thought of infrastructure as mostly boxes. And the discussion we had, we had like a 40 minute discussion, it was great talking about distributed architectures. And anybody doing software says, building distributed architectures really tough. Scaling is really difficult, but that was one of the kind of core foundations of what Nutanix did. Can you give us some of your foundational principles around what it means to build software and where you guys view it? Yeah, I mean, I'll do my best here. And my background here is for the previous seven years, I was at Facebook and we went through a lot of growth there and not trying to say that was in any sense sort of a small group of people. There was a lot of bright folks that contributed to that. But it was great to see and we learned a thing or two, I think. And Slack, in terms of scaling Slack, there's parts of Slack where it's relatively, I don't want to say textbook to scale, but there are parts of lessons that we've learned from other services that you can kind of hit, rewind and replay on. So for instance, the scale out web architectures are getting to be well understood. Even the storage part of Slack, the storage part of Slack is we're scaling out big master master replicas of my SQL and wrapping memcache around them. Colleagues of mine at Facebook have talked about that for many, many years now. And while it's very hard and very tricky to get right and takes a lot of operational intelligence to make it efficient to run, it's beginning to be an understood problem. I think the part of the technical stack that's brand new to Slack is actually scaling out real time messaging. So y'all are Slack customers, my understanding here, right? So one of the things that we strive to make happen in our messaging product that isn't a given in some of our competing in competitor messenger products is a sense of place, and that's a relatively subjective thing. But we're aiming to make it feel like these channels that you're making aren't just these empty walls of text that update every once in a while, but that they're a live place. And that if the four of us are in a room together, going back and forth, we wanted to feel somewhat seamless. And how that boils down into technical challenges is that it means, for instance, that it's latency sensitive, right? So the same way in a video conference, if you've got a ton of lag, you start having these lapses in communication where you have people saying, well, no, no, you go ahead. Oh, I was just about to say, and you kind of go back and forth like that, you get these kind of standing waves in miscommunication if the latencies don't get tightened to down enough with that part of our infrastructure. So the real time part of it is still an open problem, exactly how you scale it up to gigantic numbers of users. And we've got a few whiteboards covered in Post-it notes about how we think it's gonna go, and we'll see if it works out that way when we actually get there. Yeah, sorry, could you talk a little bit about how public cloud and cloud services fit into your architecture and what we want, look at, there's all, which provider they're using, whether they do it in-house, build that, so a lot of debate going on. Understand, yeah. So we don't run our own data centers. We're our consumers of IAS style cloud services. We use our cloud provider as a source of boxes and bandwidth and RAM and storage. We're not using sort of higher level pass style facilities very much. That's partly lock-in, that's partly to maintain flexibility. And also, I think it's, and this is controversial and there are smart people that think I'm wrong about this, it hasn't really been demonstrated that these past systems can achieve the kind of global reach that is our ultimate ambition. I mean, our ultimate ambition is to have the kind of penetration into people's daily lives, albeit their work lives, instead of their social and personal lives, that other behemoth, usually consumer brands have. And so, we naturally view our competition in this space as other companies that are comfortable building their own infrastructure and to the extent that it's not ridiculous economically to do so, we'd rather live fairly close to the metal and be able to control our own destiny that way. But of course, there are people at Slack that think I'm crazy for saying that too. I don't mean to make it sound like this is a unified voice. But for those sort of middleware Paz services, you're not relying on an out-of-the-box or I like to call it sometimes IAAS plus or SAS minus, you know, that's a package. And it's always been fuzzy to me, you know, sort of where those fit. But so, how are you achieving those? Are you just sort of building your own or are you like you said you're going? These are either the beholder things, by the way, and I don't mean to make it sound like this is sort of a cut and dried black and white thing. So for instance, things we do in our data warehouse or things that we do that are, you know, off the sort of main loop of actual serving customers in real time, different groups make different decisions and want to empower those groups to use the right tools for them. And if that's passed, awesome. And there's also kind of, you know, the tide of sort of what's essentially commodity is rising. So, you know, things like key value storage is essentially commodity these days. And if we use vendor Xs, we feel like we understand how we'd move to vendor-wise, you know, key value storage if we needed to, as long as we kind of understand the semantics there and understand what the changes would be. So it's not like it has to be, you know, disks all the way down and we know, and we can choose our hard drive vendor and so on and so forth. But we're trying to avoid, I guess, the differentiated frontier of past at some level, right? We're trying to avoid, you know, ending up sort of married to a past system where we end up being the only customer of it effectively because that's a bad position to get into for both of us, for both us and the past provider. A lot of people look at chat as a feature. You're sort of turning it into a platform. What makes it a platform? That's an interesting question. And that's a great observation, by the way. So, and, you know, we prefer the term persistent group messaging because chat has a sort of, sort of downmarked vibe when you say chat. Let's have a persistent group message. Yeah, exactly. But it's true that sort of traditionally, a chat's been treated as this little bag on the side of your product. And, you know, my life and probably most of y'all's lives still involves the occasional use of kind of a second thought, you know, help desk style chat service where, and I sit there now and say, my God, I wish this were in Slack. And it just turns out that it's something that can make a gigantic difference in when it's done well versus when it's done poorly. You know, there's this shaggy bog story of Slack's origin, which is that it used to be a game company. It actually didn't, you know, originally achieve the sort of venture funding that it did on the premise, hey, we're gonna productize chat. It originally was a massively multiplayer online game. The company's called TinySpec. The game is called Glitch. It's a really cool game, actually. I have friends of mine who played it at the time. But, you know, didn't achieve traction. Didn't achieve the kind of growth that VCs wanted. And instead of shuttering down entirely, they said, well, you know, we've got this set of integrations around our IRC server, right? We hacked some stuff on top of our IRC server so that it stores stuff so you can see things if you're not attached. You can go back and read the conversations you weren't there for. You know, we indexed it in a search engine, right? We kind of, so you can actually go and find the things that, you know, happened in this channel after the fact. And also, you know, we smoothed out some of the rough edges so that normal human beings are actually using it. And that part actually perks my ears up a little bit because I've been using IRC for a long, long time. You know, my previous employer, Facebook, uses IRC for operational stuff as a fallback, right? Facebook's broken, you're an IRC. And a lot of other places do historically as well. But one of the things that you could never do with IRC is get people who don't write code for a living into it for any amount of the day. Just too many rough edges, too many weird little things, too many quirky little things that are exactly the way they are. The story is, you know, they're this way because, well, you know, this RFC and this internet protocol and, you know, just go read this and so on. And nobody cares, right? Absolutely nobody wants to, you know, who doesn't sort of write code for a living and it can be bothered. And subjectively, it turns out that once you sit there and start using a tool like this for a while, you start to see kind of opportunities for value there that weren't obvious. And part of it is just that it's a very neutral medium for an integration, right? We're not very opinionated about what your integration has to look like. If it's good enough for you just to alert, great. You can just pipe text alerts somewhere and that's still a lot more useful for the people actually using Slack than, you know, just having it light up some dashboard or update some row in a database somewhere that nobody's actually looking at. If you want to do some richer thing and, you know, do a complicated bot that actually can parse a query or can, you know, attempt to do natural language understanding and so on, those tools are all there too. And there is an ecosystem of people trying to make value there and I'm, you know, waiting with bated breath to see what they discover. Not sure the killer app's been found there yet. But yeah, I mean, we're, we'll see. I think that to the extent that people are voting with their feet to use Slack and, you know, we don't have anything to compel them to pull out their credit cards and buy it, and yet they seem to. It turns out there's more value there than it looked like. Yeah, I mean, we tend to use Slack for internal communications and a bit of workflow. We were talking to Diraj last night and he was saying, oh no, we use it for like serious workflow and project management. And you were saying Keith, that's not uncommon. Yeah, so, you know, I mean, here we are at Nutanix.next and like the backstory for why, you know, why I'm here giving a talk and why I'm here at the conference is partly just that, you know, we're consumers of infrastructure, the way everybody else is here. We have a bunch of customers here too. But also, there's a kind of alignment with Nutanix and some of its peer companies around what people are calling the new enterprise. You know, there's a certain sense in which we're in the same business as the other vendors here, which is that we're making software that other people use to run their businesses. And in a particular case of places that are doing any kind of software development and especially operating services, the value of having a real-time group messaging product that works very, very well, right? That's smooth, that's pleasant to use, that's a tool that just fits nicely in the hand, right? That just is well-balanced and well-suited to its purpose is very, very high. You were... It's just, you know, one of the things we've looked at is companies that are going through digital transformation, whether they're becoming software companies or just, you know, going through some application migrations, those feedback loops are pretty critically important and how, you know, the email didn't cut it, but how do I get that operational change and the tools to help me along those lines? Right, right. And I think that's one of the areas where sort of real-time versus batch asynchronous as kind of the interaction paradigm ends up mattering a lot. People have tried to put synchronous layers on top of email for years and years and I understand the temptation email is this lingua franca, everybody does have an email address, but in practice it just hasn't proven very easy and it seems like for short feedback loops for things where we're talking about responding to something in seconds rather than minutes, you don't want to be relying on people checking their email or any other kind of batch communicate. You don't want to have them looking at message boards or anything else that involves a kind of polling workflow. You'd actually be able to have a fluid conversation without the jarring sort of interrupt driven style of notifications being the only way to get your attention. Yeah, I'm curious. It's one of the challenges we have with any communication tools. Once it gets prevalent, you get just overload with it. So that's why people hate emails because they got so much crap in there they can't extract the signal from the noise. I start to hear you guys have gotten popular enough now that I have friends that are like, ah, I'm on 20 Slack channels and I can't keep up and I can't do that. How do we help customers? Yeah, yeah. So to be clear, by the way, this is to some extent, the only reason I'm smiling is it's a real problem. But from our perspective, it is a nice problem to have. Kill me with that problem. It does mean that people are actually using your thing and that information they care about is flowing through it and they're worried they're missing it. So it is a good problem to have. I think the problem is inherently better than with email, but it's also a real problem. And I think it's something that, if we were entirely mindlessly speeding ahead without thinking about it, I'd be concerned with. We recently started an office in New York City under Noah Weiss who's a wonderful technical mind over there that we call SLI for Search, Learning, and Intelligence. And the broad charter that team is to make Slack better the more you use it. To a pretty surprising degree right now, Slack's a deterministic tool. There's not a lot of learning that happens in it. We don't use the words you type or the users that you pay attention to or the channels that you're in or the descriptions on the channels or what you star or what you react to or what you type or the emojis you're using and so on and so forth. There's not a lot of sort of customization flowing through those channels, but those channels are very rich signals for the kinds of ranking that we've seen be really successful in other kinds of decluttering information extraction applications like Facebook's ranked news feed, like Google search, like the smart inbox in Gmail and so on and so forth. And we're pretty sure there's gold in them in our hills. So watch this space. I'm not ready to make any announcements obviously, but I'm hopeful about it. But it's in the category of other ways that you're adding value. We talked about the platform earlier. That's a good example. You also talked about hardware integrations off camera. Oh, yeah, sure. So I mean, this is actually a little bit news to me and I don't want to mangle any of the vendors here. I'm probably poorly explaining what they're really doing. But from the point of view of the story that some people are telling now, they have boxes that can post a Slack when they're in trouble. Or they have boxes that can tell Slack that they just failed over to this channel or that they just changed the way that they're doing load balancing or what have you. And I'm sure that that's happening off box in some layer that's relatively higher up. But Slack is enough a part of the workflow of a lot of the people that are actually operating services these days that apparently that makes it onto the front of the box for a lot of vendors here. And that's a pleasant surprise for me honestly. Just treated about this right before coming over here that I'm pleased to see how many vendor integrations there are. And some of those vendor integrations are with hardware or with gear that you buy. So what's the reaction is you walk around the show and people find out you're some Slack? Is it, hey, yeah, yeah, you're Slack? I mean, it's got to be pretty incredible. Yeah, we have a ton of customers here it turns out. We expected that to be true, glad to see it confirmed. You know, I always ask people if it seems like it's working. And for the most part, people say it does seem like it's working. That's good. One of the things that I'll be talking about in my keynote about new enterprise is that one of the things that sort of enterprise software is having to learn from consumer is just that people's expectations about how well software works have been raised. And that doesn't necessarily mean that it's perfect. Far from it, in fact, if you've been in, you know, sort of seen how the sausage is made in the consumer world. But there's an expectation that you degrade gracefully in the presence of things working poorly. And you know, there was this sort of, in the world of enterprise, people often talk about dial tones, right? And just for any kids falling along at home, there used to be these things called landlines. And you'd pick up the hook of your phone and you know, it would hum at you and I forget two tones, one of them is 440 Hertz or something. And you'd know that the phone company was out there listening to your hook. And if you didn't hear that hum, you basically knew your phone was broke or that it wasn't connected to the wall. It didn't occur to you that sort of the zombie apocalypse had happened out there and you know, had sort of destroyed the telephone infrastructure because the telephone infrastructure actually worked. And I actually think that some consumer providers have gotten there, right? I think Google.com has gotten there, right? If you load Google.com on your piece of glass and it's not coming up, you assume that there's something wrong with your connection to the internet. You don't think, oh, there must be having a bad day down in Mountain View, Google.com's not loading, right? And I think a few other places have reached that threshold too. I think Facebook.com's certainly there. And I think that people in the enterprise who are operating real-time services are gonna find themselves in the same boat. And that's not because there's some magic, you know, this kind of way of, you know, this consumerization of IT term that people like using makes it sound like there's some sort of pendulum that's swinging and you know, maybe it'll swing back and will ITify a consumer or something like that. I think honestly it's just about the human beings out there who use technology getting trained to expect certain things. And we've all spent so many hours engaged with Google, engaged with Facebook, engaged with, you know, Instagram and increasingly Snapchat and all these other services that we expect to just work and that we expect to not be obtrusive, that we expect to be pleasant to use, that we expect designers have sat there and thought really hard about the visual look and feel and the easements and what's easy to do and what's hard to do. And I think that's increasingly just gonna be the oxygen that we breathe trying to make software for any kind of person whether that person's using it at work or at home or in their leisure time or their work time. Well, as a platform provider, I guess your party or true north has become critical infrastructure for this whole digital transformation that everybody talks about. You owe off in with, you know, LinkedIn, Facebook, Twitter, now Slack. Exactly, yeah. It becomes that piece of the horizontal layer that. Sure. There's synergy between platform and search too, which is just, you know, as you add these integrations, they become searchable, right? Right. So if you want to answer, you know, operationally at Slack in my day job, if I want to answer a question about the history of this web box, I know exactly what to do and I know sort of which integrations are gonna help me out in trying to understand its history and what's been going on with it lately. And so there's a kind of snowball that starts rolling there as you add more integrations. The search becomes more valuable, which makes it more attractive to integrate more things and so on. And we're starting to see a lot of our customers actually, you know, get that snowball pretty big, which is wonderful to see. So to put a bow on this discussion, tell us what we should be looking for, you know, as observers in the next, you know, 12, 18 months. As observers of new enterprise. Of Slack. In general or of Slack. So you're going to see more of the same and better and more reliability and better performance and more users. We're going to remain focused on persistent group messaging and the space that that opens up. So directly related areas. We're not going to be, I mean, or at least this is above my pay grade, right? Obviously Stuart could wake up tomorrow morning and decide otherwise. But I'd be really surprised to see us getting into, you know, boosted boards and, you know, consumer internet and so on. Yeah, and any message you'd like to give our audience is they're building kind of that new enterprise. What should they be doing different? What should they be looking for? Well, I think that they can trust their instincts about demanding the sorts of things that you demand from the software that you want to use. You should want your software to be pleasant, even though you're using it at work. And you should want it to engage with the fact that you're a human being who's sometimes playful and sometimes afraid of looking stupid and sometimes curious and all of those other things. You don't stop being those things just because you happen to be at work and pretending otherwise is just going to lead to bad decisions, especially in communication software, right? The communication software, we have a long history of letting technologists build it for us and them accidentally enabling really bad behavior, right? If you go back to Usenet in 1993 and try to imagine Facebook, it's impossible to get there from here. You'd be like, well, like, so wait, people have discussions, but they're just not crazy jerks to each other all the time? Like, how would that ever work, you know? And that's because that wasn't how that was designed to facilitate it. So you should demand the same things from the communication software. Absolutely, software should be pleasant. Hopefully the cube is pleasant for you. Keith, thanks so much for coming on today and sharing your insights. All right, keep right there. Keep right there, everybody. Stu and I will be back with our next guest. We're live from .next at the Wynn Hotel in Las Vegas. We'll be right back.