>> Narrator: Live from San Francisco. It's theCUBE, covering DevNet Create 2017, brought to you by Cisco. >> Welcome back, everyone. We're live in San Francisco for CUBE's special coverage, exclusive coverage, of Cisco Systems DevNet Create. It's an inaugural event for DevNet, a new extension to their developer program. DevNet, which is their classic developer program for the Cisco ecosystem, network guys, so on and so forth, moving packets around, hardware guys. DevNet Create is about developers and dev ops and cloud-native, all the goodness of application developers. Where apps meets infrastructure, certainly with the Cisco acquisition of AppDynamics, a new world order is coming down the pipe. Cisco's moving up the stack. I'm John Furrier, Peter Burris is my co-host, our next guest is Val Bercovici, CUBE alumni and also guest analyst in our studio in Palo Alto, also the cofounder of Peritus.ai, and now you can talk about it. Welcome to theCUBE. >> Thanks, John. We get to talk about it, finally. >> So before we get into your company, and I want to drill into it because the first public CUBE interview, drilling down on what you're working on. What's your take on Cisco's event here, because, I've known Cisco since I moved to Silicon Valley, 18 years, and even before then, and they scaled all the internet connecting networks. There's always been a discussion internally inside Cisco about moving up the stack. And it's always been kind of like a Civil War. Half the company wants to move up the stack, half doesn't, and now, you've been in NetApp, you know this world and its infrastructure, its hardware, its gear, its boxes, network packets. This is a seminal moment for Cisco. They've tried some open source before, but this seems like an all-in bet. Your thoughts? >> It is, and I was just telling Yodi Rahm, before we went live on stage that I think this is like Goldilocks event, right? It's my first. Apparently, it's the first one of its kind here at Cisco, and for me it's not too big. It's not too small. I find it really just the right size, and I find it very well-targeted, in terms of the fellow speakers, panelists that I was on with today in terms of, I see the right amount of laptops, the right amount of code, basically, amongst the attendees on the floor here. So my first impression, 'cause that's all I have so far, is it's a very well-targeted show, and it's not unique anymore. You'll notice Intel kind of pulled back from having one large event, one large annual event, and smaller more targeted events for developers, for operators, for other ISVs, and so forth. >> You're talking about the IDF Intel Developer Forum. >> The IDF, yeah, it's no longer a big, monolithic event. They split it up into more- >> And IBM has also collapsed their shows into one monster show. So little micro-events seem to be the norm. >> Yeah, I wouldn't even call it quite even a micro-event. It's a bit bigger than that, but it's not a VMworld . >> It's not a Dreamforce. >> It's not a COMDEX to VR sales. >> Interesting, I like they did their homework on the panels. So in terms of subject matter, the agenda looks great, but I do agree with you. I like how principals are here. It's not just staff here. It's both people in the trenches at Cisco, and the execs are here. Susie Wee and some other folks, they run Cisco a lot. They're all here. >> And their CTO, this morning, I caught the opening keynote livestream on the way over here. She did a fantastic job describing the role of the infrastructure developer, which is something that is a bit nebulous to nail down, at least it has been in the past, and I'm really glad that Cisco is echoing that, because I think it helps their entire ecosystem, their partner ecosystem, particularly former employers like NetApp of mine. >> I'm usually critical of big companies trying to put their toe in the water with some event that looks like a little cloud washing or you know, here or there, but I think Cisco's got a legit opportunity with programmable infrastructure. And I think, just in general, straight up, they do, because their infrastructure, and Peter and I talked about that. But I think IoT is really the big driver. They could really, that's a network connection. It's at the edge. It requires intelligence. That's a good angle for them. >> It's a great angle. The only beef I have, the gripe I have, is they still call it IoE, I think. If it's going to be Internet of Everything, and it's Internet of nothing, right? I really wish they'd kind of stick to the agreed term, and what they are doing of course is giving- >> But they were first with IoE. They were, you got to give Cisco, when they ran those commercials, what 10 years ago? >> Yeah. >> You know. >> It's a personal in for me. The commercials are fantastic. It's just the term bothers me. >> They got dogma with IoE, come on, get rid of it. Okay, tell me about your company? >> So Peritus.ai, we've realized now there's a chance to go beyond traditional digital disruption of existing industries to cognitive disruption. Let me explain what I mean by that. We're seeing a lot of increasing pace of change in data centers. The conference here, and all the technologies spoken about here, are very foreign to more traditional data center operators, and so the new environments, microservice architectures, or cloud-native apps or so forth. It's a pace of change that we haven't seen before. Agile business and agile software developer models can push code out realistically on a daily basis, whereas the waterfall model and the iCode models in most IT service practitioners practice, that's a manual or quarterly update cycle, with formal change managed practices. >> John: A more settled, structured. >> Yeah, yeah. >> Slow. >> Familiar. >> John: Reliable. >> You know, but it's the past, and the pace of change now is creating stress within IT organizations and stress within the product support organizations of the vendors that they choose to deploy. You couple that with increasing complexity of the environments we have here. We have a lot going on, the ethos of CNCF, which is container packaged, dynamically orchestrated, and micro services architected apps, cloud-native apps. The abstraction layers are masking a lot of complexity there, but the complexity is still there. And you have very good availability if you're able to write to cloud-native principles as a developer, but nevertheless, you still got that .001% of your outages so forth. And the last line of defense towards business continuity is still a human. You still got escalation engineers and support organizations that go through pretty contrived and complicated workflows to triage and diagnose problems, perhaps a case manager to assign a case or subject manager expert, get that back and forth information with the customer and finally resolve the case, and this is what we term cognitive disruption. The maturity of the AI platforms now have reached a point where you can take these complicated workflows that require nuance and inference, and actually apply true machine learning and deep learning to them. And if not entirely automate the resolution of these complex cases, better prepare a scarce resource, an escalation engineer with lots of experience, with more context up front when they encounter the case, so they can close it more quickly, and this has- >> So you're targeting, so if I understand this correctly, you're targeting the personnel in the data center. >> Val: The supportability space. >> Escalation engineers, the human labor, the last mile, if you will, or whatever, first mile, how you look at it. >> Correct. We see APM vendors in this space, we see ITSM vendors in the space. They're partners and even platforms for us. No one really is focused on supportability and automating those workflows using cognitive techniques. >> John: Give an example, give an example. >> The best example I can give actually is firsthand. I'll try and be as generic as I can to protect the innocent, but if you take a look- >> John: NetApp. >> (laughs) It's not even specifically a NetApp case. >> John: Okay, all right. >> If you look at the supply chain upstream, let's talk about electronic supply chain. If a particular manufacturer defect occurs upstream, that defect gets shipped in bundles, purchased by an equipment supplier vendor in bundles, and deployed by customers in bundles. So it's not like one of these one node outage situations is the best case scenario, traditional triple replication, you know. >> John: It's a bad batch basically. >> A bad batch. >> A lot of bad product. >> That can take out not just a node, it can take out a rack. It can take out multiple racks of storage gear, switching gear, server hosts, and so forth. In that case, again, your last line of defense is a human. You basically got to triage and diagnose the problem, could be hardware problem, could be a driver-software problem, could be an upstream OS or database problem. And it's a very stressful environment, a very stressful situation. You can take a look at prior case notes. You can take a look at machine logs and data. You can take a look at product documentation and bill of materials from suppliers, and you can pre-analyze a lot of that, and factor that into your diagnosis, effectively having it almost ready before the case is even opened, so that when the escalation engineer is assigned the case, they don't start from ground zero. They start from third base and almost they're rounding their way to home, and they're able to apply all the prior knowledge, algorithms never sleep. All the prior knowledge in terms of all the cases that have actually been dealt with that match that to a degree. They're never perfect matches, because that's just business process automation. There's a degree of inference required, and using AI techniques, we're able to guess that you know what? I've seen this before. It's very obscure, but it's actually going to be this resolution. >> So AI's technology that you're using in machine learning and data, what problem are you solving specifically? Saving them time, getting them faster resolutions? >> So we're improving the efficiency of support operations. There's always margin pressures within customer support operations. We're fundamentally solving complex system problems. We've reached a point now where business process automation can solve trivial support cases. >> John: Wait a minute, wait a minute, hold on. Expert system's supposed to do this. >> And they did in the past, and now we're evolving beyond the expert. >> Not really. Remember those expert system stays? >> Yeah, I remember LISP and all those early days, so yeah. >> So this kind of sounds like a modern version of an expert system to aid the support engineers to either have a predetermined understanding of options and time to solution. >> So we're able to do so much more than that, right? We're able to create what we call otologies. We're able to categorize all the cases that you've seen in the past, find out whether this new one fits an existing category, if so, if it matches other criteria, if not, defining a category. We're able to orchestrate. Resolution is not just a one-shot deal. Resolution is diagnose the problem, find out if you have some subject matter experts available to resolve the issue, assign it to them, track their progress, close the case, follow up on customer satisfaction. All those things are pretty elaborate workflows that can be highly automated today with cognitive approach-- >> Congratulations on launching. Thanks for spending the time to lay that out. What's next? You've got some seed funding? >> Val: We've got some seed funding. >> You got some in an incubator at the Hive in Palo Alto, which we know quite well. Rob is great, Rob is a great friend. He's done great, he's done great. How many people do have, what are you guys looking to do? What are some of the priorities? >> We are hiring. We're definitely looking to get more data scientists on staff, more full-stack engineers particularly with log experience. We're still looking for a CTO and leadership team. So there's a lot of hiring coming in place. >> John: How many in there now? >> We have about, less than 10 people working right now. >> It's a great opportunity for a classic early-stage opportunity. >> Yeah, early stage opportunity. We're addressing a hot space, and what I love is I personally shifted from being a provider of cloud-native solutions in this market to being a consumer. So I'm seeing exactly how a perfect storm is coming together of machine and deep learning algorithms, running on, orchestrated-- >> John: Both sides of the table. You should talk to Mark Sister. >> Yeah. He's been on both sides. What's it like to be on the other side now? >> It's everything I actually thought it would be, because at the end of the day, I always say, developers are the ultimate pragmatists. So it's not so much about brand loyalty at any particular vendors. What solution, whether it's an open source library, whether it's a commercial library, whether it's a propietary cloud service or something in between. What solution can solve my task, this next task? And composite applications are a very real thing right now. >> So we had a question I posted into the crowd chat, from this social net. I'm going to ask you the same questions. So Burt's watching and maybe you'll find that thread, and I'll add to it later. Here's the question. What challenges still remain as part of implementing DevOps, in your opinion? How did you see the landscape, and how are people addressing them? In your expert opinion, what's the answer to that question? What's your opinion? >> It's a two-faceted answer, at least. The first one, it's not a cliche. It's still a cultural challenge. If you want to actually want to map, it's not even a cultural challenge specifically, it's Conway's Law. Any product output, software output, is a function of your organizational structure that created it. So I find that whether you want to call it culture, whether you want to call it org structure, the org structure's rarely in place to incentivize entire teams to collaborate together throughout a full CICD pipeline process. You've still got incentive structures and org structures in place for people to develop code, unit test it, perhaps even integration test it, but I see more often than I'd like to, isolated or fenced off operations teams that take that and try to make it something real. They might call themselves SREs, and outside recovery engineers, but they're not integrated enough into the development process, in my mind. >> So you're saying the organization structures are also foreclosing their ability be agile, even though they're trying hard, that the incentives are too grounded in there. >> So I still see a lot of skunkworks projects as DevOps projects, and it shouldn't be that way anymore, right? There should be, where there's a legitimate business reason for more agile businesses, there should be a much more formal DevOps structure, as opposed to skunkworks DevOps structure. So that's one challenge, and it's not new, but it's also not resolved. And the other one really is this blind spot for the autonomous data center vision, this blind spot for operations being 100% automated and really just never having to deal with the problem. The blind spot is everything breaks. New technology just happens to break in new ways, but it does fundamentally break, and if your last line of defense is a human or a group of humans, you can expect a very, very different sort of responsiveness and agility as opposed to having something automated. >> Peter and I have been talking all morning the Ford firing of Mark Fields, which was announced yesterday. He quote retired by the Twitter handle of Ford, which is just code words for he got pushed aside. One, we're big fans of Mark Fields, before we covered Ford there in Palo Alto, doing some innovative centers over there, and also a Cloud Foundry customer. So I was actually, took notice of that. We were commenting on not so much the tech, but the guy got fired in less than three years into his journey as chief executive. >> Val: Yeah. >> Now the stock's down 39% so the hammer's coming down from either the family, Ford family, or Wall Street, Peter thinks Wall Street. But this brings up the question, how are you going to be a transformational leader, if you don't have the runway? Back to your org structure. This is, this is-- >> I'm like a broken record. I was thinking that yesterday as I was watching CNBC, and just thinking in my mind, processing what they were announcing. I'm realizing in my head, I bet why, because I don't know, but I bet why, I speculate why he got fired, because he wasn't able to put the org structure and incentives in place to run faster, and that's what the board asked his successor is run faster, and if his successor doesn't put the org structure and the incentives in place to be an agile business. That's the definition of insanity. It's banging your head against the wall. >> If I had to add one more thing to that comment, which by the way I agree with you. If you could configure an asset in a company besides the organizational structure, so you did that, what would your next asset be? More cloud, more data-centric, what would be? >> It might be cliche, but it's totally true, I would have a cloud-first approach to everything. So we don't remember this guy called Obama anymore, but really he did a pretty revolutionary thing, when he brought in a CIO eight, nine years ago, and he made every federal government department defend a capital purchase. And they basically have to go through a multi-hundred page document to defend a capital IT acquisition, but to actually go cloud first or cloud native, didn't require almost any pre-approval at all to get funding. >> So we made it easier incentives to go cloud. >> Created incentives, and I'm a big believer that cloud is not a panacea. >> That helped Amazon, not IBM, as the CIA case now. >> I'm a big believer in life cycles, so it's not like cloud is the rubber stamp solution for every problem, but the beginning innovation phase of every new product line or revenue stream really should be in the cloud right now. The amazing services, forget about IS and all that. Look at the machine language and APIs, IoT APIs, the entire CICD pipelines that are automated and simplistic, the innovation phase for everyone should be in the crowd. Then you got to take a step back, look at that bill, get over your sticker shock, and figure out whether you can afford to stay in a cloud using maybe some of those higher-level proprietary high-margin services and whether you want to re-factor. And that's where professional services kick in, and I think that might be the next great disruption for AI, is re-factoring apps. >> I think one of the things, final question I want to get your thoughts on. Pretend that we're at Cisco and we go back to the ranch, and someone says, "Hey, what's that DevNet Create?" What's our advice to our peers, if we had an opinion that people valued inside Cisco, doubled down on DevNet Create, continue, merge it DevNet? What would your advice be? >> I'm a long time James Governor fan. Developers are the new kingmakers. Actually I think we're in this situation that's not very well understood by business leaders right now, where developers are influencing all the technology infrastructure decisions we're making, but they don't necessarily write the checks. But if you want to run an agile business, a digital business today, you can't do it without happy developers and a good developer experience, so you have to cater to their needs and their biases and so forth, and at shows like this I think, bring Cisco's large ecosystem to bear, where we can figure out how Cisco can maximize the developer experience, how partners, and I'm soon to be a Cisco partner myself at Peritus.ai can maximize their developer experience and just drive more modern business. >> Bring the developer community in with the networking, get those margins connected. Val Bercovici, cofounder of Peritus.ai, this is theCUBE with exclusive coverage of the inaugural event of Cisco's DevNet Create. I'm John Furrier, Peter Burris, returning after this short break. (electric music) >> Hi, I'm April Mitchell, and I'm the senior director.