 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 of network guys, so on and so forth, moving packets around hardware guys. DevNet Create is about developers and DevOps 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 pike, Cisco's moving up the stack. I'm John Furrier, Peter Burris, my co-host, our next guest is Val Burcivici, CUBE alumni, and also guest analyst in our studio in Palo Alto. Also the co-founder of Pyridus AI. And now you can talk about it, welcome to theCUBE. Thanks John, you can 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 mean I've known Cisco since I moved to Silicon Valley 18 years and even before then, and they scaled off the internet, connecting networks. There's always been a discussion internally with 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. I mean, it's infrastructure, it's hardware, it's gear, it's boxes, network packets. This is a seminal moment for Cisco. They've tried some open sources before, but this seems like an all in bet, your thoughts? It is, and I was just telling you earlier on before we went on live on stage that I think this is a 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 with the right amount of code, basically, amongst the attendees on the floor here. So my first impression, because 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? IDF, yeah, it's no longer a big monolithic event. They've split it up into, you know, more curated. 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, you know, a VM world. It's not a dream force. It's not a convex today ourselves, so. Interesting, I like they did their homework on the panel, so in terms of subject matter, the agenda looks great, but I do agree with you. I like how principles are here. It's not just staff here. It's both people in the trenches at Cisco and the execs are here. Susie, we, and some other folks that run Cisco Live, they're all here. And there's CTO this morning. I caught the opening keynote live stream on the way over here. She did a fantastic job describing the role of the infrastructure developer, which is something that is a bit, you know, 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, you know, former employers like NapoMind. I'm usually critical of big companies trying to put their toe in the water and with some, you know, 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 can really, that's a network connection. It's at the edge. They require some intelligence. So there is their, that's a good angle for them. It's a great angle, you know, the only beef I have, the gripe I have, is they still call it IOE, I think. And you know, it's just going to be internet of everything and it's internet of nothing, right? I really wish they kind of stick to the agreed term. And, you know, what they are doing, of course, is giving specific use cases. They were, you got to give Cisco in the area. And those commercials, what, 10 years ago, you know. It's a personal it for me. The commercials are fantastic. It's just the term bothers. They just, they got dogma with IOE. Come on, get it rid of it. Okay. Tell about your company. So paired with AI, we've realized now there's a chance to go beyond traditional digital disruption of existing industries to cognitive disruption. So let me explain what I mean by that. We're seeing a lot of, you know, increasing pace of change in data centers. The conference here and all the technology spoken about here are very foreign to more traditional data center operators. And so the new environments, you know, microservice architectures, more cloud native apps and so forth, it's a pace of change that we haven't seen before. Agile business and Agile software development models can push code out realistically on a daily basis. Whereas a waterfall model and the ITIL model is the most IT service practices, practitioners practice. That's an annual or quarterly update cycle with formal change management practices. I'm more settled, you know, structure, slow. Familiar. 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 the increasing complexity of the environments we have here. We have a lot going on. You know, the ethos of CNCF, which is container packaged, dynamically orchestrated and microservices 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 the cloud native principles as a developer, but nevertheless, you still got that 0.001% to your outage and so forth. And the last line of defense towards, you know, 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 matter expert, get that back and forth information when the customer finally resolved the case. And this is what we term cognitive disruption. The maturity of the AI platforms now have reached the 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 and 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, you know, the current- So you're targeting, so I understand this correctly, you're targeting the personnel in the data center. The supportability space. Escalation engineer, these human labor is the last mile, if you will, or whatever, first mile of it. And how you look at it. We see APM vendors in this space. We see ITSM vendors in this space. They're partners and even platforms for us. No one really is focused on supportability and automating those workflows using cognitive techniques. Give an example. So the best example I can give at you is, you know, is firsthand. I'll try and be as, you know, as generic as I can to protect the innocent. But if you take a look at it, it's not even a specifically a net app case. Okay, all right. If you look at the supply chain upstream, let's talk about electronic supply chain. If a particular manufacturing defect occurs upstream, that defect, you know, gets shipped in bundles, purchased by, you know, an equipment, you know, supplier vendor in bundles and deployed by customer in bundles. So it's not like one of these, you know, one note outage situations. It's a best case scenario in a traditional triple replication, you know. It's a bad batch basically. A bad batch. It's a lot of bad product. That can take out not just a note, it can take out a rack. It can take out multiple racks of storage gear, switching gear, you know, server hosts and so forth. In that case, again, your last line of defense is a human. You know, you basically got a triaging diagnosed a problem. Could be a 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 specific, you know, 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 open so that when the escalation engineer is assigned the case, they don't start from ground zero. They start from third base or almost rounding their way to home. And they're able to apply all the prior knowledge. You know, 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 are 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 and machine learning and data, what problem are you solving specifically? Saving them time, getting their professor resolutions. So we're improving the efficiency of support operations. There's always margin pressures, you know, within customer support operations. Fundamentally solving complex systems problems. We've reached the point now where business process automation can solve trivial support cases. Wait a minute, hold on. Expert systems supposed to do this. And they did in the past and now we're evolving beyond experts. Not really. Remember those expert systems days? Yeah, I remember Lisbon all those early days, so yeah. So this kind of sounds like a modern version of like 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 ontologies. We're able to categorize all the cases that you've seen in the past, find out whether this new one fits in existing category. If so, if it matches other criteria, if not defining a category, we're able to orchestrate, you know, resolution is not just a one shot deal. Resolution is diagnose the problem, find out, you know, if you have sub-chameter experts that's 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 approaches. Okay, so congratulations on launching. Thanks for spending the time to lay that out. What's next? You got some seed funding? We got some seed funding. You got some, you're in an incubator up the hive in Pellaulta, which we know quite well. You know, Rob is a great, T.M. Rob is a great friend. You guys done great, done great. How many people do you have? What are you guys looking to do? What are some of the projects? 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. How many in there now? We have about, you know, less than 10 people working right now. So great opportunity for this classic early-stage opportunity. Yeah, early-stage opportunity. We're addressing a hot space. And what I love is, you know, 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, you know, orchestrated by Kubernetes. Both sides of the table. She talked to Mark's sister. He's been on both sides. So what's it like to be on the other side now? It's everything I actually thought it would be, you know, 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 vendor is what solution, whether it's an open-source library, whether it's a commercial library, whether it's a, you know, proprietary cloud service or something in between. What solution can solve my task? What is 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 the social nets. I'm going to ask you the same question. So Bert's watching, maybe you can go find that thread, but I'll add to it later. Here's the question. What challenges still remain as part of implementing DevOps in your opinion now? Do you see the landscape? And how are people addressing them? And your expert opinion, what's the answers to that question? What's your opinion? So it's a too-faceted answer, at least. The first one, it's not a cliche, it's still a cultural challenge. You know, if you actually want to map it, it's not even a cultural challenge, specifically it's Conway's Law. Any, you know, product output, software output as 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 is 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 and make it, you know, something real. They might call themselves SREs, now Site Recovery Engineers, but they're not integrated enough into the development process in my mind. So you're saying that the organization structures are also foreclosing their ability to 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 the 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 a 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 there. Peter and I have been talking about all morning the Ford firing of Mark Fields, which was announced yesterday. It quote, retired by the Twitter handle of Ford, which is just code words for it, you got pushed aside. One were big fans of Mark Fields. Ford, we covered Ford there in Palo Alto, been doing some innovative centers over there. So, and also a Cloud Foundry customer. So I was actually just noticing that. But 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. 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- I'm going to be a broken record. I was thinking that yesterday as I was watching CNBC and just thinking in my mind processing what they were announcing. And I was realizing in my head this, I bet why, because I don't know, but I bet- 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 the successor doesn't put the org structure and the incentives in place to be an agile business, you know, it's the definition of insanity. It's bang ahead of you. It's about 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- Also, I 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. We brought in a CIO eight, nine years ago, and he made every federal government department defend the capital purchase. And they basically had to go through like a multi, you know, hundred-page document to defend the 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 he made it easier incentives to go cloud. Creating incentives, and I'm a big believer that cloud is not a panacea. That helps Amazon, not IBM, as the CIA case found. I'm a big believer in life-cycle. 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 IaaS and all that. Look at the machine language APIs, the IoT APIs, the entire CI-CD pipelines that are automated and simplistic. The innovation phase for everyone should be in the cloud. Then you got to take a step back, look at that bill, get over your sticker shock, and figure out where they can afford to stay in the cloud using maybe some of those higher level proprietary high-margin services of where they want to refactor. And that's where professional services hit in. And I think that might be the next great disruption for AI is refactoring 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? Double down on DevNet Create, continue, merge it with DevNet. What should your advice be? I'm a longtime James Governor fan, developer as a new king makers. I actually 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 that 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 Paratis AI, can maximize the developer experience and just drive more modern business. Bring the developer community in with the networking, get those margins connected. Valperge Avicii, co-founder of Paratis.ai. This is theCUBE with exclusive coverage of the inaugural event of Cisco's DevNet Create. I'm Chairman Furrier with Peter Burris. I'm returning after this short break. Hi, I'm April Mitchell and I'm the senior director.