>>Okay. We're back with Ari Basu, who is Cisco's resident philosopher, who also holds a master's in computer science. We're gonna have to unpack that a little bit and Najati chair he who's technical lead at Cisco. Welcome guys. Thanks for coming on the cube. >>Happy to be here. Thanks a >>Lot. All right, let's get into it. We want you to explain how Cisco validated the SBRI technology and the proof points that, that you have, that it actually works as advertised. So first Outre tell first, tell us about Cisco tech. What does Cisco tech do? >>So T is otherwise it's an acronym for technical assistance center is Cisco's support arm, the support organization, and, you know, the risk of sounding like I'm spotting a corporate line. The, the easiest way to summarize what tag does is provide world class support to Cisco customers. What that means is we have about 8,000 engineers worldwide, and any of our Cisco customers can either go on our web portal or call us to open a support request. And we get about 2.2 million of these support requests a year. And what these support requests are, are essentially the customer will describe something that they need done some networking goal that they have, that they wanna accomplish. And then it's tax job to make sure that that goal does get accomplished. Now, it could be something like they're having trouble with an existing network solution, and it's not working as expected, or it could be that they're integrating with a new solution. >>They're, you know, upgrading devices, maybe there's a hardware failure, anything really to do with networking support and, you know, the customer's network goals. If they open up a case for request for help, then tax job is to, is to respond and make sure the customer's, you know, questions and requirements are met about 44% of these support requests are usually trivial and, you know, can be solved within a call or within a day. But the rest of tax cases really involve getting into the network device, looking at logs. It's a very technical role. It's a very technical job. You're look you're, you need to be conversing with network solutions, their designs protocols, et cetera. >>Wow. So 56% non-trivial. And so I would imagine you spend a lot of time digging through through logs. Is that, is that true? Can you quantify that like, you know, every month, how much time you spend digging through logs and is that a pain point? >>Yeah, it's interesting. You asked that because when we started this on this journey to augment our support engineers workflow with zebra solution, one of the things that we did was we went out and asked our engineers what their experience was like doing log analysis. And the anecdotal evidence was that on average, an engineer will spend three out of their eight hours reviewing logs, either online or offline. So what that means is either with the customer live on a WebEx, they're going to be going over logs, network, state information, et cetera, or they're gonna do it offline, where the customer sends them the logs, it's attached to a, you know, a service request and they review it and try to figure out what's going on and provide the customer with information. So it's a very large chunk of our day. You know, I said 8,000 plus engineers, and so three hours a day, that's 24,000 man hours a day spent on long analysis. >>Now the struggle with logs or analyzing logs is there by out of necessity. Logs are very contr contr. They try to pack a lot of information in a very little space. And this is for performance reasons, storage reasons, et cetera, BEC, but the side effect of that is they're very esoteric. So they're hard to read if you're not conversant, if you're not the developer who wrote these logs or you or you, aren't doing code deep dives. And you're looking at where this logs getting printed and things like that, it may not be immediately obvious or even after a low while it may not be obvious what that log line means or how it correlates to whatever problem you're troubleshooting. So it requires tenure. It requires, you know, like I was saying before, it requires a lot of knowledge about the protocol what's expected because when you're doing log analysis, what you're really looking for is a needle in a haystack. You're looking for that one anomalous event, that single thing that tells you this shouldn't have happened. And this was a problem right now doing that kind of anomaly detection requires you to know what is normal. It requires, you know, what the baseline is. And that requires a very in-depth understanding of, you know, the state changes for that network solution or product. So it requires time, tenure and expertise to do well. And it takes a lot of time even when you have that kind of expertise. >>Wow. So thank you, archery. And Najati, that's, that's about, that's almost two days a week for, for a technical resource. That's that's not inexpensive. So what was Cisco looking for to sort of help with this and, and how'd you stumble upon zebra? >>Yeah, so, I mean, we have our internal automation system, which has been running more than a decade now. And what happens is when a customer attaches a log bundle or diagnostic bundle into the service request, we take that from the Sr we analyze it and we represent some kind of information. You know, it can be alert or some tables, some graph to the engineer, so they can, you know, troubleshoot this particular issue. This is an incredible system, but it comes with its own challenges around maintenance to keep it up to date and relevant with Cisco's new products or new version of the product, new defects, new issues, and all kind of things. And when I, what I mean with those challenges are, let's say Cisco comes up with a product today. We need to come together with those engineers. We need to figure out how this bundle works, how it's structured out. >>We need to select individual logs, which are relevant and then start modeling these logs and get some values out of those logs, using pars or some rag access to come to a level that we can consume the logs. And then people start writing rules on top of that abstraction. So people can say in this log, I'm seeing this value together with this other value in another log, maybe I'm hitting this particular defect. So that's how it works. And if you look at it, the abstraction, it can fail the next time. And the next release when the development or the engineer decides to change that log line, which you write that rag X, or we can come up with a new version, which we completely change the services or processes, then whatever you have wrote needs to be re written for that new service. And we see that a lot with products, like for instance, WebEx, where you have a very short release cycle that things can change maybe the next week with a new release. >>So whatever you are writing, especially for that abstraction and for those rules are maybe not relevant with that new release. With that being sake, we have a incredible rule creation process and governance process around it, which starts with maybe a defect. And then it takes it to a level where we have an automation in place. But if you look at it, this really ties to human bandwidth. And our engineers are really busy working on, you know, customer facing, working on issues daily and sometimes creating these rules or these pars are not their biggest priorities, so they can be delayed a bit. So we have this delay between a new issue being identified to a level where we have the automation to detect it next time that some customer faces it. So with all these questions and with all challenges in mind, we start looking into ways of actually how we can automate these automations. >>So these things that we are doing manually, how we can move it a bit further and automate. And we had actually a couple of things in mind that we were looking for and this being one of them being, this has to be product agnostic. Like if Cisco comes up with a product tomorrow, I should be able to take it logs without writing, you know, complex regs, pars, whatever, and deploy it into this system. So it can embrace our logs and make sense of it. And we wanted this platform to be unsupervised. So none of the engineers need to create rules, you know, label logs. This is bad. This is good. Or train the system like which requires a lot of computational power. And the other most important thing for us was we wanted this to be not noisy at all, because what happens with noises when your level of false PE positives really high your engineers start ignoring the good things between that noise. >>So they start the next time, you know, thinking that this thing will not be relevant. So we want something with a lot or less noise. And ultimately we wanted this new platform or new framework to be easily adaptable to our existing workflows. So this is where we started. We start looking into the, you know, first of all, internally, if we can build this thing and also start researching it, and we came up to Zeum actually Larry, one of the co co-founders of Zeum. We came upon his presentation where he clearly explained why this is different, how this works, and it immediately clicked in. And we said, okay, this is exactly what we were looking for. We dived deeper. We checked the block posts where SBRI guys really explained everything very clearly there, they are really open about it. And most importantly, there is a button in their system. >>So what happens usually with AI ML vendors is they have this button where you fill in your details and sales guys call you back. And, you know, we explain the system here. They were like, this is our trial system. We believe in the system, you can just sign up and try it yourself. And that's what we did. We took our, one of our Cisco live DNA center, wireless platforms. We start streaming logs out of it. And then we synthetically, you know, introduce errors, like we broke things. And then we realized that zebra was really catching the errors perfectly. And on top of that, it was really quiet unless you are really breaking something. And the other thing we realized was during that first trial is zebra was actually bringing a lot of context on top of the logs. During those failures, we work with couple of technical leaders and they said, okay, if this failure happens, I I'm expecting this individual log to be there. And we found out with zebra, apart from that individual log, there were a lot of other things which gives a bit more context around the root columns, which was great. And that's where we wanted to take it to the next level. Yeah. >>Okay. So, you know, a couple things to unpack there. I mean, you have the dart board behind you, which is kind of interesting, cuz a lot of times it's like throwing darts at the board to try to figure this stuff out. But to your other point, Cisco actually has some pretty rich tools with AppD and doing observability and you've made acquisitions like thousand eyes. And like you said, I'm, I'm presuming you gotta eat your own dog food or drink your own champagne. And so you've gotta be tools agnostic. And when I first heard about Z zebra, I was like, wait a minute. Really? I was kind of skeptical. I've heard this before. You're telling me all I need is plain text and, and a timestamp. And you got my problem solved. So, and I, I understand that you guys said, okay, let's run a POC. Let's see if we can cut that from, let's say two days a week down to one day, a week. In other words, 50%, let's see if we can automate 50% of the root cause analysis. And, and so you funded a POC. How, how did you test it? You, you put, you know, synthetic, you know, errors and problems in there, but how did you test that? It actually works Najati >>Yeah. So we, we wanted to take it to the next level, which is meaning that we wanted to back test is with existing SARS. And we decided, you know, we, we chose four different products from four different verticals, data center, security, collaboration, and enterprise networking. And we find out SARS where the engineer put some kind of log in the resolution summary. So they closed the case. And in the summary of the Sr, they put, I identified these log lines and they led me to the roots and we, we ingested those log bundles. And we, we tried to see if Zeum can surface that exact same log line in their analysis. So we initially did it with archery ourself and after 50 tests or so we were really happy with the results. I mean, almost most of them, we saw the log line that we were looking for, but that was not enough. >>And we brought it of course, to our management and they said, okay, let's, let's try this with real users because the log being there is one thing, but the engineer reaching to that log is another take. So we wanted to make sure that when we put it in front of our users, our engineers, they can actually come to that log themselves because, you know, we, we know this platform so we can, you know, make searches and find whatever we are looking for, but we wanted to do that. So we extended our pilots to some selected engineers and they tested with their own SRSS. Also do some back testing for some SARS, which are closed in the past or recently. And with, with a sample set of, I guess, close to 200 SARS, we find out like majority of the time, almost 95% of the time the engineer could find the log they were looking for in zebra analysis. >>Yeah. Okay. So you were looking for 50%, you got to 95%. And my understanding is you actually did it with four pretty well known Cisco products, WebEx client DNA center, identity services, engine ISE, and then, then UCS. Yes. Unified pursuit. So you use actual real data and, and that was kind of your proof proof point, but Ari. So that's sounds pretty impressive. And, and you've have you put this into production now and what have you found? >>Well, yes, we're, we've launched this with the four products that you mentioned. We're providing our tech engineers with the ability, whenever a, whenever a support bundle for that product gets attached to the support request. We are processing it, using sense and then providing that sense analysis to the tech engineer for their review. >>So are you seeing the results in production? I mean, are you actually able to, to, to reclaim that time that people are spending? I mean, it was literally almost two days a week down to, you know, a part of a day, is that what you're seeing in production and what are you able to do with that extra time and people getting their weekends back? Are you putting 'em on more strategic tasks? How are you handling that? >>Yeah. So, so what we're seeing is, and I can tell you from my own personal experience using this tool, that troubleshooting any one of the cases, I don't take more than 15 to 20 minutes to go through the zebra report. And I know within that time either what the root causes or I know that zebra doesn't have the information that I need to solve this particular case. So we've definitely seen, well, it's been very hard to measure exactly how much time we've saved per engineer, right? What we, again, anecdotally, what we've heard from our users is that out of those three hours that they were spending per day, we're definitely able to reclaim at least one of those hours and, and what, even more importantly, you know, what the kind of feedback that we've gotten in terms of, I think one statement that really summarizes how Zebra's impacted our workflow was from one of our users. >>And they said, well, you know, until you provide us with this tool, log analysis was a very black and white affair, but now it's become really colorful. And I mean, if you think about it, log analysis is indeed black and white. You're looking at it on a terminal screen where the background is black and the text is white, or you're looking at it as a text where the background is white and the text is black, but what's what they're really trying to say. Is there hardly any visual cues that help you navigate these logs, which are so esoteric, so dense, et cetera. But what XRM does is it provides a lot of color and context to the whole process. So now you're able to quickly get to, you know, using their word cloud, using their interactive histogram, using the summaries of every incident. You're very quickly able to summarize what might be happening and what you need to look into. >>Like, what are the important aspects of this particular log bundle that might be relevant to you? So we've definitely seen that a really great use case that kind of encapsulates all of this was very early on in our experiment. There was, there was this support request that had been escalated to the business unit or the development team. And the tech engineer had really, they, they had an intuition about what was going wrong because of their experience because of, you know, the symptoms that they'd seen. They kind of had an idea, but they weren't able to convince the development team because they weren't able to find any evidence to back up what they thought was happening. And we, it was entirely happenstance that I happened to pick up that case and did an analysis using Seebri. And then I sat down with the attack engineer and we were very quickly within 15 minutes, we were able to get down to the exact sequence of events that highlighted what the customer thought was happening, evidence of what the, so not the customer, what the attack engineer thought was the, was a root cause. It was a rude pause. And then we were able to share that evidence with our business unit and, you know, redirect their resources so that we could change down what the problem was. And that really has been, that that really shows you how that color and context helps in log analysis. >>Interesting. You know, we do a fair amount of work in the cube in the RPA space, the robotic process automation and the narrative in the press when our RPA first started taking off was, oh, it's, you know, machines replacing humans, or we're gonna lose jobs. And, and what actually happened was people were just eliminating mundane tasks and, and the, the employee's actually very happy about it. But my question to you is, was there ever a reticence amongst your team? Like, oh, wow, I'm gonna, I'm gonna lose my job if the machine's gonna replace me, or have you found that people were excited about this and what what's been the reaction amongst the team? >>Well, I think, you know, every automation and AI project has that immediate gut reaction of you're automating away our jobs and so forth. And there is initially there's a little bit of reticence, but I mean, it's like you said, once you start using the tool, you realize that it's not your job, that's getting automated away. It's just that your job's becoming a little easier to do, and it's faster and more efficient. And you're able to get more done in less time. That's really what we're trying to accomplish here at the end of the day, rim will identify these incidents. They'll do the correlation, et cetera. But if you don't understand what you're reading, then that information's useless to you. So you need the human, you need the network expert to actually look at these incidents, but what we are able to skin away or get rid of is all of the fat that's involved in our, you know, in our process, like without having to download the bundle, which, you know, when it's many gigabytes in size, and now we're working from home with the pandemic and everything, you're, you know, pulling massive amounts of logs from the corporate network onto your local device that takes time and then opening it up, loading it in a text editor that takes time. >>All of these things are we're trying to get rid of. And instead we're trying to make it easier and quicker for you to find what you're looking for. So it's like you said, you take away the mundane, you take away the, the difficulties and the slog, but you don't really take away the work, the work still needs to be done. >>Yeah. Great guys. Thanks so much. Appreciate you sharing your story. It's quite, quite fascinating. Really. Thank you for coming on. >>Thanks for having us. >>You're very welcome. Okay. In a moment, I'll be back to wrap up with some final thoughts. This is Dave Valante and you're watching the, >>So today we talked about the need, not only to gain end to end visibility, but why there's a need to automate the identification of root cause problems and doing so with modern technology and machine intelligence can dramatically speed up the process and identify the vast majority of issues right out of the box. If you will. And this technology, it can work with log bundles in batches, or with real time data, as long as there's plain text and a timestamp, it seems Zebra's technology will get you the outcome of automating root cause analysis with very high degrees of accuracy. Zebra is available on Preem or in the cloud. Now this is important for some companies on Preem because there's really some sensitive data inside logs that for compliance and governance reasons, companies have to keep inside their four walls. Now SBRI has a free trial. Of course they better, right? So check it out@zebra.com. You can book a live demo and sign up for a free trial. Thanks for watching this special presentation on the cube, the leader in enterprise and emerging tech coverage on Dave Valante and.

(upbeat music) >> Full stack observability is all the rage today. As businesses lean into digital, customer experience becomes ever more important. Why? Well, it's obvious, fickle consumers can switch brands in the blink of an eye or the click of a mouse. Technology companies have sprung into action and the observability space is getting pretty crowded in an effort to simplify the process of figuring out the root cause of application performance problems without an army of PhDs and lab coats, also known as endlessly digging through logs, for example. We see decades old software companies that have traditionally done monitoring or log analytics and or application performance management stepping up their game. These established players, you know, they typically have deep feature sets and sometimes purpose-built tools that attack one particular segment of the marketplace. And now they're pivoting through M&A and some organic development trying to fill gaps in their portfolio. And then, you got all these new entrants coming to the market, claiming end to end visibility across the so-called modern cloud and now edge native stacks. Meanwhile, cloud players are gaining traction and participating through a combination of native tooling combined with strong ecosystems to address this problem. But, you know, recent survey research from ETR confirms our thesis that no one company has it all. Here's the thing. Customers just want to figure out the root cause as quickly and as efficiently as possible. It's one thing to observe the stack end to end, but the question is who is automating the observers? And that's why we're here today. Hello, my name is Dave Vellante and welcome to this special Cube presentation where we dig into root cause analysis, and specifically, how one company, Zebrium, is using unsupervised machine learning to detect anomalies and pinpoint root causes and delivering it as an automated service. And in this session, we have two deep dives. First, we're going to dig into this exciting new field of RCaaS, Root Cause As A Service with two of the founders and technical experts behind Zebrium. And then we bring in two technical experts from Cisco, an early Zebrium customer who ran a POC with Zebrium's service, automating and identifying root cause problems within four very well established and well known Cisco product lines, including WebEx Client and UCS. I was pretty amazed at the results and I think you'll be impressed as well. So thanks for being here. Let's get started. With me right now is Larry Lancaster, who's a founder and CTO of Zebrium. And he's joined by Rod Bagg, who's the founder and vice president of engineering at the company. Gents, welcome. Thanks for coming on. >> Thanks. >> Okay. >> It's good to be here. >> It's good to be here >> All right Rod, talk to me. Talk to me about software downtime, what root cause means, all the buzzwords in your domain, MTTR and SLO. What do we need to know? >> Yeah, I mean, it's like you said. I mean, it's extremely important to our customers and to most businesses out there to drive uptime and avoid as much downtime as possible. So, you know, when you think about it, all of these businesses, most companies nowadays, either their product is software and it's running, you know, running on the web and that's how you get a point click. Or the business depends on, you know, internal systems to drive their business and to run it. When that is down, that is hugely impacting to them. So if you take a look, you know, way back, you know, 20, 30 years ago, software was simple. You know, there wasn't much to it. It was pretty monolithic and maybe it took a couple of people to maintain it and keep it running. There wasn't really anything complicated about it. It was a single tenant piece of software. Today's software is so complicated, often running, you know, maybe hundreds of services to keep that or to actually implement what that software is doing. So as you point out, you know, enter the sort of observability space and the tools that are now in use to help monitor that software and make sure when something goes wrong, they know about it But there's kind of an interesting stat around the observability space. So when you look at observability in the context or through the lens of the cost of downtime, it's really interesting. So observability tools are about a $20 billion market, okay? But the cost of downtime, even with that in place, is still hundreds of billions of dollars. So you're not taking much of a bite out of what the real problem is. You have to solve root cause and get to that fast. So it's all great to know that something went wrong but you got to know why. And it's our contention here that, you know, really, when you take a look at the observability space, you have metrics, that's a great tool. I mean, there's lots of great tools out there, you know, around metrics monitoring that's going to tell you when something went wrong. It's very rarely it's going to tell you why. Similarly for tracing, it's going to point you to where the issue is. It's going to take you through that stack and probably pinpoint where you're being, you know where it's happening or where something is running slow, potentially. So that's great. But again, the root cause of why it's happening is going to be buried in log files. And I can expand on that a little bit more but you know, when you're a software developer and you're writing your software, those log files are a wealth of information. It's just a set of breadcrumbs that are littered with facts about how the software is behaving and why it's doing what it's doing, or why it went wrong. And it's that that really gets you to the root cause very fast. And that's our contention, is that these software systems are so complex nowadays and that the root cause is lying in those logs. So how do you get there fast? You know, we would contend that you better automate that or you are just doomed for failure. And that's where we come in. >> Great. >> Getting to that root cause. >> Thank you, Rod. You know, it's interesting you talk about the $20 billion market. There's an analogy with security, right? We spend 80, $100 billion a year on securing our infrastructure, and yet we lose probably closer to a trillion dollars a year in breaches. And there's a similar analogy here. 20 billion could be 5X in downtime impacts or more. Okay, let's go to Larry. Tell us a little bit more about Zebrium. I'm interested always to ask a founder why you started the company. Rod touched on that a little bit. You guys have invented this concept of RCaaS. What does it mean? What problems does it solve, and how does it solve the problem? Let's get into it. >> Yeah. Hey, thanks, Dave. So I think when you said, you know, who's automating the observer, that that's a great way to think about it because what observability really means is it's a property of a system that means you can see into it. You can observe the internal state and that makes it easier to troubleshoot, right? But the problem is if it's too complicated, you just push the bottleneck up to your eyeball. There's only so much a person can filter through manually, right? And I love the way you put that. So that's a great way to think about it is automating the observer. Now, of course, it means that, you know, you reduce your MTTR, you meet your service level objectives, all that stuff, you improve customer experience. That's all true, but it's important to step back and realize like we have cracked a real nut here. People have been trying to figure out how to automate this part of sort of the troubleshooting experience, this human part of finding the root cause indicators for a long time. And until Zebrium came along, I would argue, no one's really done it right. So, you know, I think it's also important you know, as we step back, we can probably look forward five to 10 years and say, everyone's going to look back and say how did we do all this manually? You're going to see this sort of last mile of observability and troubleshooting is going to be automated everywhere because otherwise, you know, people are just... They're not going to be able to scale their business. So, you know, I think one more thing that's important to point out is, you know, I think Zebrium, you know, it's one thing to have the technology but we've learned we need to deliver it right where people are today. You can't just expect people to dive into a new tool. So, you know, we're looking at, you know, if you look at Zebrium, you'll put us on your dashboard and we don't care what kind of a dashboard it is. It could be, you know Datadog, New Relic, Elastic, Dynatrace, Grafana AppDynamics, ScienceLogic, we don't care. You know, they're all our friends. So we're more interested in getting to that root cause than trying to fight, you know, these incumbents and all that stuff. Yep. >> Yeah. So, interesting. Again, another analogy I think about. You know, you talked about automation. If we're to look back and say this is what... We're never going to do this again, it's like provisioning loans. Nobody provisions loans anymore, it's all automated. >> Larry: (chuckling) That's right. >> So Larry, I'll stay with you, then the skeptic in me says, this sounds amazing, but if I, you know... It might be too good to be true. Tell us how it works. >> Larry: (chuckling) Yeah. So that's interesting. So Cisco came along and they were equally skeptical. So what they did was they took a couple of months and they did a very detailed study. And they got together 192 incidents across four product lines, where they knew that the root cause was in the logs. And they knew what that root cause was because they had had their best engineers, you know work on those cases and take detailed notes of the incidents that had taken place. And so they ran that data through the Zebrium software. And what they found was that in more than 95% of those incidents, Zebrium reflected the correct root cause indicators at the correct time. Like that blew us away. When we saw that kind of evidence, Dave, I have to tell you, everyone was just jumping up and down. It was like, you know, it was like the Apollo command center, you know when they finally, you know, touchdown on the moon kind of thing. So, you know, it's really an exciting point in time to be at the company, like just seeing everything finally being proven out according to this vision. I'm going to tell you one more story which is actually one of my favorites, because we got a chance to work with Seagate Lyve Cloud. So they're, you know, a hyper modern, you know, SaaS business, they're an S3 competitor. Zoom has their files stored on Lyve Cloud, you know, to let you know who they are. So essentially, what happened was they were in alpha, their early access, and they had an outage, and it was pretty bad. I mean, it went on for longer than a day, actually, before they were completely restored. And it was, you know, fortunately for them, it was early access. So no one was expecting, you know, uptime, you know, service level objectives and so on. But they were scared, because they realized, if something like this happens in production, you know, they're screwed. So what they did was they saw Zebrium. They went and did some research, they saw Zebrium. They went in a staging environment, recreated the exact (indistinct) that they had had. And what they saw was immediately, Zebrium pops up a root cause report that tells them exactly the root cause that they took over a day to find. These are the kind of stories that let us know we're onto something transformational. >> Dave: Yeah. That's great. I mean, you guys are jumping up and down, I'm sure. We're going to hear from Cisco later. I bet you, they were jumping up and down too because they didn't have to do all that heavy lifting anymore. So Rod, Larry's just sort of implying that, or actually, you guys both talked about that your tool is agnostic. So how does one actually use the service? How do I deploy it? >> Yeah. So let me step back. So when we talk about logs right? Like, you know, all these bread crumbs being in logs and everything else? So, you know, they are a great wealth of you know, information, but people hate dealing with them. I mean, they hate having to go in and figure out what log to look at. In fact, you know, we had one of our... Or we've heard from several of our customers now prior to using Zebrium, when they, you know, have some issue, and they know there's something wrong, something on their dashboard has told them that something's wrong, maybe a metric has, you know, taken a blip or something's happened that they know there's a problem. We've heard from them that it can take like a number of hours just to get to the right set of logs, like figuring out over these hundreds of services where the logs are, to get to them, maybe searching in a log manager. Just to get into the right context, even, can take hours. So, you know, that's obviously the problem we solve but, you know, we don't want them just looking at logs. I mean, you know, we don't want to put them back in the thing they don't like doing because people don't do that. They don't like doing it. So we put it up on the dashboard. So if something is going wrong with your metrics and that's the indicator, or maybe it's something with tracing that you're sort of digging through that you know something's wrong, we will be right on that same dashboard. So we're deployed as a SaaS service. You send us your logs, you click on one of our integrations and we integrate with all these tools that Larry's talked about. And when we detect anything that is a root cause report, it will show up on your dashboard in the same timeline as those blips in your metrics. So when you see something going wrong and you know there's an issue, take a look at the portion of your dashboard that is us, and we're going to tell you why. We're going to get you to the why that went wrong. No other work could be... You can, you know, also click down and click through to us so that you land up in our portal, if you want to do some more digging around, if you need to or whatever, maybe to get some context what have you, but it's fair that if you ever need to do that, the answer should be right there on your dashboard. And that that's how we expect people to use it. We don't want them digging in logs and going through things, we want it to be right in their workflow. >> Great. Thank you, Larry. So Rod, we talked about Cisco. We're going to hear more from them in a moment in Seagate. I would think this is like a perfect solution for a SaaS provider, anybody doing AI ops. Do you have some examples of those types of firms leaning into this? >> Rod: Yeah, a couple of great ones. Well, I mean, we've got many of them, but a couple that I'll touch on. We have an actual AI ops company that was looking for, you know, sort of some complimentary technology and so on. And so they decided to just put us through our paces by having one of their own SREs sign up for our service in our SaaS environment, and send the logs from their system to us, you know, and just see how we did. So it turned out we ended up talking back to this SRE like a week after he had installed the product, you know signed up and then, you know, started sending us logs. And, you know, he was hewing and hawing, saying that he was busy, like every SRE is, and that he didn't have a chance to really do much with us yet. And, you know, we were just, you know, having this conversation on the phone, and he comes to tell us that, yeah I've been busy because we had this, you know, terrible outage, like, you know, five days ago. And we said like, "Okay did you actually look on the Zebrium dashboard?" (chuckles) And he goes, "You know what? I didn't even think to do it yet. I mean, I'd just been so busy and frazzled." So we have an integration with that company, he hadn't put that integration in, so it wasn't in his dashboard yet, but it was certainly on ours. So he went there, and he looks and he looks on the day, you know, on the time range of when he had had this incident. And right at the very top of the page on our portal was that incident with that root cause. And he was flabbergasted. It literally would've saved him hours and hours and hours. They had this issue going on for over 24 hours. And we had the answer right there in five minutes, and it was crazy. And we get that kind of stories. It's just like the Seagate one. If you use us and you have a problem, we're going to detect it. And you're going to hear from Cisco how successful we are at detecting things. I mean, it'll be there when you have a problem. In SaaS companies, you know, one of our customers is Alchera. They do cost optimizations for cloud properties, you know, for AWS optimization, Google, Google cloud, and so on. But they use our software, and they have a lot of interaction, obviously with these cloud vendors and the APIs of those cloud vendors. So, you know, in order to figure out your costing at AWS, they're using all those APIs. So it turned out, you know, they had some issue where their services were breaking. And we had that root cause report right on the screen, again within five minutes, that was pointing to an API problem with Google. And they had changed one of their APIs and Alchera was not aware of it. So their stuff was breaking because of a change downstream that we had caught. And I'll just tell you one last one because it's somewhat related to one of these cloud vendors. You know, it was a big cloud vendor who had an outage a couple of months ago. And it's interesting because, you know, a lot of our customers will set up shared Slack channels with us, where we're monitoring or seeing their incidents as well as they are. So we get a little Slack representation of the incident that we detected for them or the root cause that we detected for them, and that's in a shared community channel. So we could see this happening when that AWS outage happened. We could see our customers getting impacted by that AWS outage, and the root cause of what was going on there in AWS that was impacting our customers that was showing up in our incidents. Now we didn't obviously, you know, have the very root cause of what was going on in AWS, per se but we were getting to the root cause of why our customer's applications were failing. And that was because of issues going on at AWS. >> Very interesting. I mean, I think one of your biggest challenges is going to be getting people's attention because these SREs are so busy, their hair's on fire. >> Rod: That's it. Right. (chuckling). You know, when you say, hey, (indistinct). >> I tell you, if you get their attention, they love it. I mean, this AI ops company, I didn't even tell you the punchline there, but, you know, they had this incident that occurred that we found. And quite literally, the next week, they ended up signing up as a paid customer. So... >> Dave: that's great. And Larry, to give you the last word. I mean, you know, Rod was talking about, you know, changes in APIs and you know, there's still a lot of scripts out there. You guys, if I understand it correctly, run both as a service in the cloud and you can run on-prem, which is important because there's a lot of sensitive information in logs that people are trying not to leave. >> Larry: That's right. Absolutely. >> Dave: But close it out here. >> Yeah. I mean, that's right, you can run it on-prem. Just like we run it in our cloud, you can run it in your cloud or on your own infrastructure. Now that's all true. You know, I think the one hurdle now that we have left as a company is getting the word out and getting people to believe that this is actually possible and try it for themselves. You don't believe it, do a POC, try it yourself. And you know, people have become so jaded by the lack of, you know, real, sort of, innovation in the software industry for the last 10 years that it's hard to get people to... But guys, you got to give it a shot, I'm telling you. I'm telling you right now, it works. And you'll hear more about that from one of our customers in a minute. >> All right guys, thanks so much. Great story. Really appreciate you sharing. >> Thank you. >> Yeah. Thanks Dave. Appreciate the time. >> Okay. In a moment, we're going to hear from Cisco who is the customer in this case example and a company that has... Look, they have quite an impressive suite of observability tooling, and they've done a pretty compelling proof of concept with Zebrium using real data on some Cisco products that you've heard of, like WebEx. So stay tuned and learn about how you can really take advantage of this new technology called Root Cause As A Service. You're watching theCube, the leader in enterprise and emerging tech coverage. (upbeat music)

>>We're back at your storage service. Emil Stan is here. He's the chief commercial officer and chief marketing officer of open line. Thank you, Emil, for coming on the cube. Appreciate your time. >>Thank you, David. Nice. Uh, glad to be here. >>Yeah. So tell us about open line. You're a managed service provider. What's your focus? >>Yeah, we're actually a cloud managed service provider and I do put cloud in front of the managed services because it's not just only the scripts that we manage. We have to manage the clouds as well nowadays. And then unfortunately, everybody only thinks there's one cloud. But's always multiple layers in the cloud. So we have a lot of work in integrating, uh, it where a cloud manages provider in the Netherlands, focusing on, uh, companies who have a head office in the Netherlands, mainly in the, uh, healthcare local government, social housing logistics department. And then in the midsize companies between say 250 to 10,000 office employees. Uh, and that's what we do. We provide them with excellent cloud managed services, uh, as it should be >>Interesting, you know, lot early on in the cloud days, highly regulated industries like healthcare government were somewhat afraid of the cloud. So I'm sure that's one of the ways in which you provide value to your customers is helping them become cloud proficient. Maybe you could talk a little bit more about the value prop to customers. Why do they do business with you? >>Yeah, I think, uh, there are a number of reasons why they do business with us or choose to choose for our managed services provider. Tracy, of course, are looking for stability and continuity, uh, and, and from a cost perspective, predict predictable costs, but nowadays you also have a shortage in personnel and knowledge. So, and it's not always very easy for them to access, uh, those skill sets because most it, people just want to have, uh, a great variety in work, what they are doing, uh, towards, towards the local government, uh, healthcare, social housing. They actually, uh, a sector that, uh, that are really in between embracing the public cloud, but also have a lot of legacy and, and bringing together best of all, worlds is what we do. So we also bring them comfort. We do understand what legacy, uh, needs from a manager's perspective. We also know how to leverage the benefits in the public cloud. Uh, and, uh, I'd say from a marketing perspective, actually, we focus on using an ideal cloud, being a mix of traditional and future based cloud. >>Thank you. I, you know, I'd like to get your perspective on this idea of as a service and the, as a service economy that we often talk about on the cube. I mean, you work with a lot of different companies. We talked about some of the industries and, and increasingly it seems like organizations are focused more on outcomes, continuous value delivery via, you know, suites of services and, and they're leaning into platforms versus one off product offerings, you know, do you see that? How do you see your customers reacting to this as a service trend? >>Yeah. Uh, to be honest, sometimes it makes it more complex because services like, look at your Android or iPhone, you can buy apps, uh, and download apps the way you went to. So they have a lot of apps, but how do you integrate it into one excellent workflow, something that works for you, David or works for me? Uh, so the difficulty, some sometimes lies in, uh, the easy accessibility that you have to those solutions, but nobody takes into account that they're all part of a chain or workflow supply chain, uh, and, and, uh, they're being hyped as well. So what, we also have a lot of time in, in, in, in, in managing our customers, is that the tremendous feature push feature push that there is from technology providers, SaaS providers. Whereas if you provide 10 features, you only need one or two, uh, but the other eight are very distracting from your prime core business. Uh, so there's a natural way in that people are embracing, uh, SA solutions, embracing cloud solutions. Uh, but what's not taken into account as much is that we love to see it the way that you integrate all those solutions to it's something that's workable for the person that's actually using them. And it's seldomly that somebody is only using one solution. There's always a chain of solutions. Um, so yeah, there are a lot of opportunities, but also a lot of challenges for us, but also for our customers. >>Do you see that trend toward, as a service continuing, or do you actually see based on what you're just saying that pendulum, you know, swinging back and forth, somebody comes out with a new sort of feature product and that, you know, changes the dynamic or do you see as a service really having legs? >>Ah, that's very, very good question, David, because that's something that's keeps our busy all the time. We do see a trend in as a service looking at, uh, talk about pure later on. We also use pure as a service more or less. Yeah. And it really helps us. Uh, but you see, uh, um, that sometimes people make a step too, too fast, too quick, not well thought of, and then you see what they call sort of cloud repatriation, tend that people go back to what they're doing and then they stop innovating or stop leveraging. The possibilities are actually there. Uh, so from a consultancy guidance and architecture point of view, we try to help them as much possible to think in a SA thought, but just don't use the, cloud's just another data center. Eh, and so it's all about managing the maturity on our side, but on our customer side as well. >>So I'm interested in how you're sort of your philosophy and it relates, I think, in, in, in terms of how you work with pure, but how do you stay tightly in lockstep with, with your customers so that you don't over rotate so that you don't them to over rotate, but then you're not also, you don't wanna be too late to the game. How, how do you manage all that? >>Oh, there's, there's, there's a world of interactions between us and our customers. And so I think a well known, uh, uh, uh, thing that people, the most customer intimacy, that's very important for us to get to know our customers and get to predict which way they're moving. But the, the thing that we add to it is also the ecosystem intimacy. So no, the application and services landscape, our customers know the primary providers and work with them, uh, to, to, to create something that, that really fits the customers to just not look at from our own silo where a cloud managed service provider that we actually work in the ecosystem with, with, with, with the primary providers. And we have, I think where the average customers, I think we have, uh, uh, uh, in a month we have so much interactions on our operational level and technical levels, strategic level. >>We do bring together our customers also, and to jointly think about what we can do together, what we independently can never reach, but we also involve our customers in defining our own strategy. So we have something we call a customer involvement board. So we present a strategy and today, does it make sense? Eh, this is actually what you need also. So we take a lot of our efforts into our customers and we do also, uh, understand the significant moments of truth. We are now in this, in this broadcast, David there. So you can imagine that at this moment, not thinking go wrong. Uh, if, if, if the internet stops, we have a problem. And now, so we, we actually know that this broadcast is going on for our customers. And we manage that. It's always on, uh, uh, where in the other moments in the week, we might have a little less attention, but this moment we should be there in these moments of truth that we really embraced. We got them well described. Everybody working out line knows what the moment of truth is for our customers. Uh, uh, so we have a big logistics provider. For instance, you does not have to ask us to, uh, have, uh, a higher availability on black Friday or cyber Monday. We know that's the most important part in the year for him or her. Does it answer your question, David? >>Yes. We know as well. You know, when these big, the big game moments you have to be on your top, uh, top of your game. Yeah. Uh, you know, the other thing, a Emil about this as a service approach that I really like is, is it's a lot of it is consumption based and the data doesn't lie, you can see adoption, you know, D daily, weekly, monthly. And so I wonder how you're leveraging pure as a service specifically in what kind of patterns you're seeing in, in, in the adoption, >>Uh, pure as a service for our customers. It's mainly never visible. Uh, we provide storage services, provide storage solutions, storage job is part of a bigger thing of a server of application. Uh, so the real benefits to be honest of, of course, towards our customer, it's all flash, uh, uh, and they have the fast, fastest storage is available. But for ourself, we, uh, we use less resources to manage our storage. We have far more that we have a near to maintenance free storage solution now because we have it as a service and we work closely together with pure. Uh, so, uh, actually the way we treat our customers is the way pure treats us as well. And that's why there's a used click. So the real benefits, uh, uh, how we leverage is it normally we had a bunch of guys managing us storage. Now we only have one and knowing that's a shortage of it, personnel, the other persons can well be, uh, involved in other parts of our services or in other parts of an innovation. So, uh, that's simply great. >>You know, um, my takeaway Emil is that you've made infrastructure, at least, least the storage infrastructure, invisible to your customers, which is the way it should be. You didn't have to worry about it. And you've, you've also attacked the, the labor problem. You're not, you know, provisioning lungs anymore, or, you know, tuning the storage, you know, with, with arms and legs. So that's huge. So that gets me into the next topic, which is business transformation. That, that means that I can now start to attack the operational model. So I've got a different it model. Now I'm not managing infrastructure same way. So I have to shift those resources. And I'm presuming that it's a bus now becomes a business transformation discussion. How are you seeing your customers shift those resources and focus more on their business as a result of this sort of as a service trend? >>I think I do not know if they, they transform their business. Thanks to us. I think that they can more leverage their own business. They have less problems, less maintenance, et cetera, et cetera. But we also add new, uh, certainties to it, like, uh, uh, the, the latest service we we released was imutable storage being the first in the Netherlands offering this thanks to, uh, thanks to the pure technology, but for customers, it takes them to give them a good night rest because, you know, we have some, uh, geopolitical issues in the world. Uh, there's a lot of hacking. People have a lot of ransomware attacks and, and we just give them a good night rest. So from a business transformation, doesn't transform their business. I think that gives them a comfort in running your business, knowing that certain things are well arranged. You don't have to worry about that. We will do that. We'll take it out of your hands and you just go ahead and run your business. Um, so to me, it's not really transformation. It's just using the right opportunities at the right moment. >>The imutable piece is interesting because of course, but speaking of as a service, you know, anybody can go on the dark web and buy ransomware as a service. I mean, as it's, he was seeing the, as a service economy hit, hit everywhere, the good and the, and the not so good. Um, and so I presume that your customers are, are looking at, I imutability as another service capability of the service offering and really rethinking, maybe because of the recent, you know, ransomware attacks, rethinking how they, they approach, uh, business continuance, business resilience, disaster recovery. Do you see that? >>Yep, definitely. Definitely. I, not all of them yet. Imutable storage. So it's like an insurance as well. Yeah. Which you have when you have imutable storage and you have, you have a ransomware attack, at least if you part the data, which never, if data is corrupted, you cannot restore it. If your hardware is broken, you can order new hardware. Every data is corrupted. You cannot order new data. Now we got that safe and well. And so we offer them the possibility to, to do the forensics and free up their, uh, the data without a tremendous loss of time. Uh, but you also see that you raise the new, uh, how do you say, uh, the new baseline for other providers as well? Eh, so there's security of the corporate information security officer, the CIO, they're all fairly happy with that. And they, they, they raise the baseline for others as well. So they can look at other security topics and look from, say a security operation center that now we can really focus on our prime business risks, because from a technical perspective, we got it covered. How can we manage the business risk, uh, which is a combination of people, processes and technology. >>Right. Makes sense. Okay. I'll give you the last word. Uh, talk about your relationship with pure, where you wanna see that, that going in the future. >>Uh, I hope we've be working together for a long time. Uh, I, I ex experienced them very involved. Uh, it's not, we have done the sell and now it's all up to you now. We really closely working together. I know if I talk to my prime marketing, Marcel height is very happy and it looks a little more or less if we work with pure, like we're working with colleagues, not with a supplier, uh, and a customer, uh, and, uh, the whole pure concept is quite fascinating. Uh, I, uh, I had the opportunity to visit San Francisco head office, and they told me to fish in how they launched pure being, if you want to implement it, it had to be on one credit card. The, the, the menu had to be on one credit card, just a simple thought of put that as your big hair, audacious goal to make the simplest, uh, implementable storage available. But for, uh, it gives me the expectation that there will be a lot of more surprises with puring in near future. Uh, and for us as a provider, what we, uh, literally really look forward to is that, that for us, these new developments will not be new migrations. It will be a gradual growth of our services on storage services. Uh, so that's what I expect, and that was what I, and we look forward to. >>Yeah, that's great. Uh, thank you so much, Emil, for coming on the, the cube and, and sharing your thoughts and best of luck to you in the future. >>Thank you. >>You're welcome. Thanks for having me. You're very welcome. Okay. In a moment, I'll be back to give you some closing thoughts on at your storage service. You're watching the cube, the leader in high tech enterprise coverage.

(upbeat music) >> We're back with Steve McDowell, the Principal Analyst for Data & Storage at Moor Insights and Strategy. Hey Steve, great to have you on. Tell us a little bit about yourself. You've got a really interesting background and kind of a blend of engineering and strategy and what's your research focus? >> Yeah, so my research, my focus area is data and storage and all the things around that, whether it's On-Prem or Cloud or, you know, software as a service. My background, as you said, is a blend, right? I grew up as an engineer. I started off as an OS developer at IBM. I came up through the ranks and shifted over into corporate strategy and product marketing and product management, and I have been doing working as an industry analyst now for about five years at Moor Insights and Strategy. >> Steve, how do you see this playing out in the next three to five years? I mean, cloud got it all started, it's going to snowballing. You know, however you look at it percent of spending on storage that you think is going to land in as a service. How do you see the evolution here? >> IT buyers are looking at as a service and consumption base is, you know, a natural model. It extends the data center, brings all of the flexibility all of the goodness that I get from public cloud, but without all of the downside and uncertainty on cost and security and things like that, right, that also come with the public cloud and it's delivered by technology providers that I trust and that I know, and that I worked with, you know, for, in some cases, decades. So, I don't know that we have hard data on how much adoption there is of the model, but we do know that it's trending up, you know and every infrastructure provider at this point has some flavor of offering in the space. So, it's clearly popular with CIOs and IT practitioners alike. >> So Steve, organizations are at a they're different levels of maturity in their, their transformation journeys, and of course, as a result, they're going to have different storage needs that are aligned with their bottom line business objectives. From an IT buyer perspective, you may have data on this, even if it's anecdotal, where does storage as a service actually fit in and can it be a growth lever? >> It can absolutely be a growth leader. It gives me the flexibility as an IT architect to scale my business over time without worrying about how much money I have to invest in storage hardware. Right? So I, I get kind of, again, that cloud like flexibility in terms of procurement and deployment, but it gives me that control by oftentimes being on site within my premise, and then I manage it like a storage array that I own. So, you know, it's beautiful for for organizations that are scaling and it's equally nice for organizations that just want to manage and control cost over time. So, it's a model that makes a lot of sense and fits and certainly growing in adoption and in popularity. >> How about from a technology vendor perspective? You've worked for in the tech industry for companies? What do you think is going to define the winners and losers in this space? If you running strategy for a storage company, what would you say? >> I think the days of of a storage administrator managing, you know, rate levels and recovering and things of that sort are over, right? What these organizations like Pure delivering but they're offering is simplicity. It's a push button approach to deploying storage to the applications and workloads that need it, right? It becomes storage as a utility. So, it's not just the, you know the consumption based economic model of as a service. It's also the manageability that comes with that or the flexibility of management that comes with that. I can push a button, deploy bites to you know a workload that needs it, and it just becomes very simple, right, for the storage administrator, in a way that, you know kind of old school On-Prem storage can't really deliver. >> You know, I want to, I want to ask you, I mean I've been thinking about this because again, a lot of companies are, are you know, moving, hopping on the as a service bandwagon. I feel like, okay, in and of itself, that's not where the innovation lives. The innovation is going to come from making that singular experience from On-Prem to the clouds across clouds maybe eventually out to the edge. Do you, where do you see the innovation in as a service? >> Well, there's two levels of innovation, right? One, is business model innovation, right? I now have an organizational flexibility to build the infrastructure to support my digital transformation efforts, but on the product side and the offering side, it really is as you said, it's about the integration of experience. Every enterprise today touches a cloud in some way, shape or form. Right, I have data spread, not just in my data center, but at the edge, oftentimes in a public cloud, maybe a private cloud. I don't know where my data is, and it really lands on the storage providers to help me manage that and deliver that manageability experience to to the IT administrators. So, when I look at innovation in this space, you know, it's not just a a storage array and rack that I'm leasing, right, this is not another lease model. It's really fully integrated, you know end to end management of my data and yeah and all of the things around that. >> Yeah, so to your point about a lease model is if you're doing a lease, you know, yeah. You can shift CapEx to OPEX, but you're still committed to you have to over provision, whereas here and I wanted to ask you about that. It's an interesting model, right, because you got to read the fine print. Of course the fine print says you got to commit to some level typically, and then if, you know, if you go over you you charge for what you use and you can scale that back down and that's got to be very attractive for folks. I wonder if you we'll ever see like true cloud like consumption pricing, that has two edges to it, right? You see consumption based pricing in some of the software models and you know yeah, people like it, the, the lines of business maybe because they're paying in by the drink, but then procurement hates it because they don't have predictability. How do you see the pricing models? Do you see that maturing or do you think we're sort of locked in on, on where we're at? >> No, I do see that maturing, right? And when you work with a company like Pure to understand their consumption base and as a service and you know, when you work with a company like Pure to understand their consumption base and as a service offerings, it really is sitting down and understanding where your data needs are going to scale. Right? You buy in at a certain level, you have capacity planning. You can expand if you need to. You can shrink if you need to. So, it really does put more control in the hands of the IT buyer than, well certainly then traditional CapEx based On-Prem, but also more control than you would get, you know working with an Amazon or an Azure. >> Well the next 10 years, it ain't going to be like the last 10 years. Thanks Steve! We'll leave it there for now. Love to have you back. Look at, keep it right there. You don't want to miss this next segment where we dig into the customer angle. You're watching theCube production of At Your Storage Service, brought to you by PureStorage. One more. Okay, thanks Steve! We'll leave it there for now. I'd love to have you back. Keep it right there, At Your Storage Service continues in a moment. You're watching theCube. (upbeat music)

(bright intro music) >> The cloud has popularized many useful concepts in the past decade, working backwards from the customer to pizza teams and DevOps mindset, the shared responsibility model, and security, of course, the shift from CapEx to OPEX, and as a service consumption models. The last item is what we're here to talk about today. Pay for consumption is attractive because you're not over provisioning, at least not the way you used to. You'd have to buy for peak capacity events, but there are always two sides to every story, and while pay for use more closely ties IT consumption to business value, procurement teams don't always love the uncertainty of the cloud bill each month, but consumption pricing and as a service models are here to stay in software and hardware. Hello, I'm Dave Vellante and welcome to "At Your Storage Service" made possible by Pure Storage, and with me is Prakash Darji who's the General Manager of the Digital Experience Business Unit at Pure. Prakash, welcome to the program. >> Thanks Dave. Thanks for having me. >> You bet. Okay, we've seen this shift to as a service, the as a service economy, subscription models, and this as a service movement have gained real momentum. It's clear over the past several years. What's driving this shift? Is it pressure from investors and technology companies that are chasing the all important ARR, their annual recurring revenue stream? Is it customer driven? Give us your insights. >> Well, look, I think we'll do some definitional stuff first. I think we often mix the definition of a subscription and a service, but, you know, subscription is, "Hey, I can go for a pay up front or pay as I go." Service is more about, "How do I not buy something just by the outcome?" So, you know, the concept of delivering storage as a service means, what do you want in storage, performance, capacity, availability? Like that's what you want. Well, how do you get that without having to worry about the labor of planning, capacity management? Those labor elements are what's driving it. So I think in the world where you have to do more with less and in a world where security becomes increasingly important where standardization will allow you to secure your landscape against ransomware and those types of things, those trends are driving the SaaSification of storage, and the only way to deliver that is storage as a service. >> So that's good. You maybe thinking about it differently than some of the other companies that I talked to, but so you've made inroads here, pretty big inroads actually, and changed the thinking in enterprise data storage with a huge emphasis on simplicity. That's really Pure's raison d'etre. How does storage as a service fit in to your innovation agenda overall? >> Well, our innovation agenda started, as you mentioned, with the simplicity, you know, a decade ago with the Evergreen Architecture. That architecture was beyond the box. How do you go ahead and say, "I can improve performance or capacity as I need it." Well, that's a foundational element to deliver a service because once you have that technology, you can say, "Oh, you know what? You've subscribed to this performance level. You want to raise your performance level and yes, that'll be a higher dollar per gig or dollar per terabyte," but how do you do that without a data migration? How do you do that with a non-disruptive service change? How do you do that with a delivery via software update? Those elements of non-disruptive updates, when you think SaaS, Salesforce, you don't know when Salesforce doesn't update. You don't know when they're increasing something, adding a new capability. It just shows up. It's not a disruptive event. So to drive that standardization and SaaSification in service delivery, you need to keep that simplicity of delivery first and foremost, and you can't allow, like, if the goal was, "I want to change from this service here to that service here," and a person needed to show up and do a day data migration, that's kind of useless. You've broken the experience of flexibility for a customer. >> Okay, so I like the Salesforce analogy, but I want to jump out do a little side for a second. So I've got to make some commitment to Pure, right? Some baseline commitment, and if I do, then I can dial up and then pay for what I use, and I can dial it down, correct? >> Correct. >> Okay. I can't do that with Salesforce, all right? I could dial up, but then I'm stuck with those licenses. So you have a better model in Salesforce, I would argue. Okay. >> Yeah. I would agree with that. >> Okay, so, and I got to pay for everything up front. Anyway, let's go back to I was kind of pushing at you a little bit at my upfront, you know, about, you know, the ARR model, the all-important, you know, financial metric, but let's talk from the customer standpoint. What are the benefits of consuming storage as a service from your customer's perspective? >> Well, one is when you start your storage journey, do you really know what you need? And I would argue, most of the time, people are guessing, right? It's like, "Well, I think I need this. This is the performance I think I need or this is the capacity I think I need," and, you know, with the scientific method, you actually deploy something, and you're like, "Do I need more? Do I need less?" You find out as you're deploying. So in a storage as a service world, when you have the ability to move up performance levels or move out capacity levels, and you have that flexibility, then you have the ability to just to meet demand as you deploy, and that's the most important element of meeting business needs today. The applications you deploy are not in your control when you're providing storage to your end consumers. >> Yeah. >> They're going to want different levels of storage. They're going to want different performance thresholds. That's kind of a pay, you know, pay for performance type culture, right? You can use HR analogy for it. You pay for performance. You want top talent, you pay for it. You want top storage performance, you pay for it. You don't, you can pay less, and you can actually get lower performance tiers. Not everything is a tier one application, and you need the ability to deploy it, but when you start, how do you know the way your end customers are going to be consuming or do you need a dictated upfront? 'Cause that's infrastructure dictating business inflexibility, and you never want to be in that position. >> I got another analogy for you. It's like, you know, we do a lot of hosting at our home and you know, like Thanksgiving, right? And you go to the liquor store and say, "Okay, what should I get, should we get red wine? We got to go white wine, we got to get some beer. Should I get bubbles? Yeah, I get some bubbles." 'Cause you don't know what people are going to have, and so you over provision everything and then there's a run on bubbles and you're like, "Ah, we're running the bubbles," so you just over buy, but there's a liquor store that actually will take it back. So I got to do business with those guys every time 'cause it's way more flexible. I can dial up capacity or I can dial up performance, and dial it back down if I don't use it. >> Where you're going to be drinking a lot more the next few weeks. >> Yeah, exactly, like which is the last thing you want. Okay, so let's talk about how Pure kind of meets this as a service demand. You've touched upon your differentiators from others in the market. You know, love to hear about the momentum. What are you seeing out there? >> Yeah, look, our business is growing well largely built on, you know, what customers need. Specifically, where the market is at today is there's a set of folks that are interested in the financial transformation of CapEx to OPEX. Like that definitely exists in the industry around, "How do I get a paper use model?" The next kind of more advanced customer is interested in, "How do I go ahead and remove labor to deliver storage?" And a service gets you there on top of a subscription. The most sophisticated customer says, "How do I separate storage production with consumption and production of storage?" Being a storage producer should be about standardization so I could do policy based management. Why is that important? You know, coming back to some of the things I said earlier, in the world where ransomware attacks are common, you need the standardized security policies. Linux has new vulnerabilities every other day, like find two, three critical vulnerabilities a week. How do you stay on top of it? The complexity of staying on top of it should be, "Look, let's standardize and make it a vendor problem, and assume the vendor's going to deliver this to me." So that standardization allows you to have business policies that allow you to stay current and modern. I would argue in, you know, the traditional storage and appliance world, you buy something and the day after you buy it, it's worthless. It's like driving a car off a lot, right? The very next day, the car's not worth what it was when you bought it. Storage is the same way. So how do you ensure that your storage stays current? How do you ensure that it gets a like a fine line that gets better with age? Well, if you're not buying storage and you're buying a performance SLA, it's up to the vendor to meet that SLA so it actually never gets worse over time. This is the way you modernize technology and avoid technology debt as a customer. >> Yeah, I mean, just even though words you're using and the way you're thinking about this precaution, I think are different, and I love the concept of essentially taking my labor cost and transferring them to Pure's R&D. I mean, that's essentially what you're talking about here. So let's stick with the tech for a minute. What do you see as new or emerging technologies that are helping accelerate this shift toward the as a service economy? >> Well, the first thing is I always tell people you can't deliver a service without monitoring because if you can't monitor something, how you're going to know whether you're meeting your service level obligation, right? So everything starts with data monitoring. The next step layering on the technology differentiation is if you need to deliver a service level obligation on top of that data monitoring, you need the ability to flexibly meet whatever performance obligations you have in a tight time window. So supply chain and being able to deliver anywhere becomes important. So if you use the analogy today of how Tesla works or a IoT system works, you have a SaaS management that actually provides instructions that pushes those instructions and policies to the edge. In Tesla's case, that happens to be the car. It'll push software updates to the car. It'll push new map updates to the car, but the car is running independently. It's not like if the car becomes disconnected from the internet, it's going to crash and drive you off the road. In the same way, what if you think about storage as something that needs to be wherever your application is? So people think about cloud as a destination. I think that's a fallacy. You have to think about the world in the view of an application. An application needs data, and that data needs to sit in storage wherever that application sits. So for us, the storage system is just an edge device. It can be sitting in your data center it can be sitting in a Equinix. It can be sitting in hosted and MSP can run it. It can even be sitting in the public cloud, but how do you have central monitoring and central management where you can push policies to update all those devices, very similar to an IOT system? So the technology advantage of doing that means that you can operate anywhere and ensure you have a consistent set of policies, a consistent set of protection, a consistent set of, you know, prevention against ransomware attack regardless of your application, regardless of, you know, where it sits, regardless of what content in it you're on. That approach is very similar to the way the IoT industry has been updating and monitoring edge devices, nest thermostats, you know, Tesla cars, those types of things. That's the thinking that needs to come to storage, and that's the foundation on which we built Pure as a service. >> So that implies or, at least I infer, that you've, obviously, got control of the experience on prem, but you're extending that into AWS, Google, Azure, which suggests to me that you have to hide the underlying complexity of the primitives and APIs in that world, and then eventually, actually today, 'cause you're treating everything like the edge out to the edge, you know, maybe mini Pure at some point in time, but so I call that super cloud, that abstraction layer that floats above all the clouds on-prem and adds that layer of value and is a singular experience, what you're talking about pushing, you know, policy throughout. Is that the right way to think about it? And how does this impact the ability to deliver true storage as a service? >> Oh, that's absolutely the right way of thinking about it. The things that you think about from an abstraction kind of fall in three buckets. First, you need management. So how do you ensure consistent management experience, creating volumes, deleting volumes, creating buckets, creating files, creating directories like management of objects and create a consistent API across the entire landscape? The second one is monitoring. How do you measure utilization and performance obligations or capacity obligations or, you know, policy violations, wherever you're at? And then the third one is more of a business one, which is procurement because you can't do it independent of procurement, meaning what happens when you run out? Do you need to increase your reserve commits? Do you want to go on demand? How do you integrate it into company's procurement models such that you can say, "I can use what I need," and any, it's not like every change order is a request of procurement. That's going to break an as a service delivery model. So to get embedded in a customer's landscape where they don't have to worry about storage, you have to provide that consistency on management, monitoring, and procurement across the tech, and yes, this is deep technology problems, whether it's running our storage on AWS or Azure or running it on prem or, you know, at some point in the future, maybe even, you know, Pure mini at the edge, right? So, you know, all of those things are tied to our Pure as a service delivery. >> Yeah, technically, non-trivial, but hey, you guys are on it. Well, we got to leave it there, Prakash. Thank you, great stuff, really appreciate your time. >> All right, thanks for having me, man. >> You're very welcome. Okay, in a moment, Steve McDowell. For more insights and strategies, he's going to give us the analyst perspective on as a service. You're watching "theCUBE", the leader in high tech enterprise coverage. (bright outro music)

>>When AWS introduced the modern cloud in 2006, many people didn't realize the impact that it would have on the industry, but some did see the future of an as a service economy coming. I mean, SAS offerings came out several years before. And the idea of applying some of these concepts to infrastructure and simplifying deployment and management, you know, kinda looked enticing to a lot of customers and a subscription model, or, but yet a consumption model was seen as a valuable proposition by many customers. Why not apply it to infrastructure? And why should the hyperscalers have all the fun welcome to at your storage service? My name is Dave ante. And as an analyst at the time, I was excited about the, as a service trend early on. And one of the companies that caught my attention back in the beginning of last decade was pure storage. >>Pure not only was delivering cloud- simplicity, but it's no forklift approach to infrastructure was ahead of its time. And that's why we're here today to dig into what's happening with the, as a service trends that we see popping up all over the world today, we're gonna dig into three sessions with noted experts in the field. First pre Darie is the general manager of the digital experience business unit at pure storage. He's gonna join us. And then we bring in Steve McDowell, Steve's a senior analyst for data and storage at more insights and strategy, a well known consultancy and analyst firm. And finally, we close with Amil sta Emil is the chief commercial officer and chief marketing officer at open line, open lines, a managed service provider. They serve the mid-market and Emil's got a very wide observation space. He's gonna share what he's seeing with customers. So sit back and enjoy the show. >>The cloud has popularized many useful concepts in the past decade, working backwards from the customer two pizza teams, a DevOps mindset, the shared responsibility model in security. And of course the shift from CapEx to OPEX and as a service consumption models. The last item is what we're here to talk about today. Pay for consumption is attractive because you're not over provisioning. At least not the way you used to you'd have to buy for peak capacity events, but there are always two sides to every story and well pay for use more closely ties. It consumption to business value procurement teams. Don't always love the uncertainty of the cloud bill each month, but consumption pricing. And as a service models are here to stay in software and hardware. Hello, I'm Dave ante and welcome to at your storage service made possible by pure storage. And with me is Pash DJI. Who's the general manager of the digital experience business unit at pure Pash. Welcome to the program. >>Thanks Dave. Thanks for having me. >>You bet. Okay. We've seen this shift to, as a service, the, as a service economy, subscription models, and this as a service movement have gained real momentum. It's it's clear over the past several years, what's driving this shift. Is it pressure from investors and technology companies that are chasing the all important ARR, their annual recurring revenue stream? Is it customer driven? Give us your insights. >>Well, look, um, I think we'll do some definitional stuff first. I think we often mix the definition of a subscription and a service, but, you know, subscription is, Hey, I can go for pay up front or pay as I go. Service is more about how do I not buy something just by the outcome. So, you know, the concept of delivering storage as a service means, what do you want in storage performance, capacity availability? Like that's what you want. Well, how do you get that without having to worry about the labor of planning capacity management, those labor elements are what's driving it. So I think in the world where you have to do more with less and in a world where security becomes increasingly important, where standardization will allow you to secure your landscape against ransomware and those types of things, those trends are driving the ation of storage and the only way to deliver that is storage as a service. >>So that's, that's good. You maybe thinking about it differently than some of the other companies that I talked to, but so you, you, you've made inroads here pretty big inroads actually, and changed the thinking in enterprise data storage with a huge emphasis on simplicity. That's really pures rayon Detra. How does storage as a service fit into your innovation agenda overall? >>Well, our innovation agenda started, as you mentioned with the simplicity, you know, a decade ago with the evergreen architecture, that architecture was beyond the box. How do you go ahead and say, I can improve performance or capacity as I need it? Well, that's a foundational element to deliver a service because once you have that technology, you can say, oh, you know what? You've subscribed to this performance level. You want to raise your performance level and yes, that'll be a higher dollar per gig or dollar per terabyte. But how do you do that without a data migration? How do you do that with a non disruptive service change? How do you do that with a delivery via a software update, those elements of non disruptive updates. When you think SAS, Salesforce, you don't know when Salesforce doesn't update, you don't know when they're increasing something, adding a new capability just shows up. It's not a disruptive event. So to drive that standardization and sation and service delivery, you need to keep that simplicity of delivery first and foremost, and you can't allow, like, if the goal was, I want to change from this service tier to that service tier and a person needed to show up and do a day data migration, that's kind of useless. You've broken the experience of flexibility for a customer. >>Okay. So I like the Salesforce analogy, but I wanna jump out, do a little side for a second. So I I've gotta, I've gotta make some commitment to pure, right. Some baseline commitment. And if I do, then I can dial up and pay for what I use and I can dial it down. Correct? Correct. Okay. I can't do that with Salesforce. <laugh> right. I could dial up, but then I'm stuck with those licenses. So you have a better model in Salesforce. I would argue. Okay. Yeah, >>I would, I would agree with that. >>Okay. So, and I gotta pay for everything up front anyway. Um, let's go back. I was kind of pushing at you a little bit at my upfront, you know, about, you know, the ARR model, the, the all important, you know, financial metric, but let's talk from the customers standpoint. What are the benefits of consuming storage as a service from your customer's perspective? >>Well, one is when you start your storage journey, do you really know what you need? And I would argue most of the time people are guessing, right? It's like, well, I think I need this. This is the performance I think I need. Or this is the capacity I think I need. And, you know, with the scientific method, you actually deploy something and you're like, do I need more? Do I need less? You find out as you're deploying. So in a storage as a service world, when you have the ability to move up performance levels or move out capacity levels, and you have that flexibility, then you have the ability to just to meet demand as you deploy. And that's the most important element of meeting business needs today. The applications you deploy are not in your control when you're providing storage to your end consumers. >>Yeah. They're gonna want different levels of storage. They're gonna want different performance thresholds. That's kind of a pay, you know, pay for performance type culture, right? You can use HR analogies for it. You pay for performance. You want top talent, you pay for it. You want top storage performance, you pay for it. Um, you don't, you can pay less and you can actually get lower performance, tiers, not everything is a tier one application. And you need the ability to deploy it. But when you start, how do you know the way your end customers are gonna be consuming? Or do you need a dictated upfront? Cause that's infrastructure dictating business inflexibility, and you never want to be in that position. >>I, I got another analogy for you. It's like, you know, we do a lot of hosting at our home and you know, like Thanksgiving, right? And you go to the liquor store and say, okay, what should I get? Should we get red wine? We gotta go white wine. We gotta get some beer. Should I get bubbles? Yeah, I get some bubbles. Cause you don't know what people are gonna have. And so you over provision everything <laugh> and then there's a run on bubbles and you're like, ah, we run outta bubbles. So you just over buy, but there's a liquor store that actually will take it back. So I gotta do business with those guys every time. Cuz it's way more flexible. I can dial up capacity or can dial up performance and dial it back down if I don't use it >>Or you or you're gonna be drinking a lot more the next few weeks. >>Yeah, exactly. Which is the last thing you want. Okay. So let's talk about how pure kind of meets this as a service demand. You've touched upon your, your differentiators from others in the market. Um, you know, love to hear about the momentum. What, what are you seeing out there? >>Yeah. Look, our business is growing well, largely built on, you know, what customers need. Um, specifically where the market is at today is there's a set of folks that are interested in the financial transformation of CapEx to OPEX, where like that definitely exists in the industry around how do I get a pay use model? The next kind of more advanced customer is interested in how do I go ahead and remove labor to deliver storage? And a service gets you there on top of a subscription. The most sophisticated customer says, how do I separate storage production with consumption and production of storage. Being a storage producer should be about standardization. So I could do policy based management. Why is that important? You know, coming back to some of the things I said earlier in the world where ransomware attacks are common, you need the standardized security policies. >>Linux has new vulnerabilities every, every other day, like find 2, 2, 3 critical vulnerabilities a week. How do you stay on top of it? The complexity of staying on top of it should be, look, let's standardize and make it a vendor problem. And assume the vendor's gonna deliver this to me. So that standardization allows you to have business policies that allow you to stay current and modern. I would argue in, you know, the traditional storage and appliance world, you buy something and the day a, the day after you buy it, it's worthless. It's like driving a car off a lot, right? The very next day, the car's not worth what it was when you bought it. Storage is the same way. So how do you ensure that your storage stays current? How do you ensure that it gets like a fine line that gets better, better with age? Well, if you're not buying storage and you're buying a performance SLA, it's up to the vendor to meet that SLA. So it actually never gets worse over time. This is the way you modernize technology and avoid technology debt as a customer. >>Yeah. I mean, just even though words you're using in the way you're thinking about this precaution, I think are, are, are different. Uh, and I love the concept of essentially taking my labor cost and transferring them to pures R and D I mean, that's essentially what you're talking about here. Um, so let's, let's, let's stick with the, the, the tech for a minute. What do you see as new or emerging technologies that are helping accelerate this shift toward the, as a service economy? >>Well, the first thing is I always tell people, you can't deliver a service without monitoring, because if you can't monitor something, how you're gonna know what your, whether you're meeting your service level obligation, right? So everything starts with data monitoring. The next step layering on the technology. Differentiation is if you need to deliver a service level, OB obligation on top of that data monitoring, you need the ability to flexibly, meet whatever performance obligations you have in a tight time window. So supply chain and being able to deliver anywhere becomes important. So if you use the analogy today of how Tesla works or a IOT system works, you have a SaaS management that actually provides instructions that push pushes those instructions and policies to the edge. In Tesla's case, that happens to be the car it'll push software updates to the car. It'll push new map updates to the car, but the car is running independently. >>It's not like if the car becomes disconnected from the internet, it's gonna crash and drive you off the road in the same way. What if you think about storage as something that needs to be wherever your application is? So people think about cloud as a destination. I think that's a fallacy. You have to think about the world in the world in the view of an application, an application needs data, and that data needs to sit in storage wherever that application sits. So for us, the storage system is just an edge device. It can be sitting in your data center, it can be sitting in a Equinix. It can be sitting in hosted, an MSP can run. It can, can even be sitting in the public cloud, but how do you have central monitoring and central management where you can push policies to update all those devices? >>Very similar to an I IOT system. So the technology advantage of doing that means that you can operate anywhere and ensure you have a consistent set of policies, a consistent set of protection, a consistent set of, you know, prevention against ransomware attack, regardless of your application, regardless of, uh, you know, where it sits, regardless of what content in you're on that approach is very similar to the way the T industry has been updating and monitoring edge devices, nest, thermostats, you know, Tesla cars, those types of things. That's the thinking that needs to come to. And that's the foundation on which we built PI as a service. >>So that implies, or at least I infer that you've obviously got control of the experience on Preem, but you're extending that, uh, into AWS, Google Azure, which suggests to me that you have to hide the underlying complexity of the primitives and APIs in that world. And then eventually, actually today, cuz you're treating everything like the edge out to the edge, you know, maybe, maybe mini pure at some point in time. But so I call that super cloud that abstraction layer that floats above all the clouds on-prem and adds that layer of value. And is this singular experience? What you're talking about pushing, you know, policy throughout, is that the right way to think about it and how does this impact the ability to deliver true storage as a service? >>Oh, uh, that's absolutely the right way of thinking about it. The things that you think about from a, an abstraction kind of fall in three buckets, first, you need management. So how do you ensure a consistent management experience creating volumes, deleting volumes, creating buckets, creating files, creating directories, like management of objects and create a consistent API across the entire landscape. The second one is monitoring, how do you measure utilization and performance obligations or capacity obligations or uh, you know, policy violations, wherever you're at. And then the third one is more of a business one, which is procurement because you can't do it independent of procurement. Meaning what happens when you run out, you need to increase your reserve commits. Do you want to go on demand? How do you integrate it into company's procurement models, such that you can say, I can use what I need and any, it's not like every change order is a request of procurement. That's gonna break an as a service delivery model. So to get embedded in a customer's landscape where they don't have to worry about storage, you have to provide that consistency on management, monitoring and procurement across the tech. And yes, this is deep technology problems, whether it's running our storage on AWS or Azure or running it on prem or, you know, at some point in the future, maybe even, um, you know, pure mini at the edge. Right. <laugh> so, you know, tho all of those things are tied to our pure, a service delivery. >>Yeah, technically non-trivial but uh, Hey, you guys are on it. Well, we gotta leave it there. Pash. Thank you. Great stuff. Really appreciate your time. >>All right. Thanks for having me, man. >>You're very welcome. Okay. In a moment, Steve McDowell from more insights and strategies, it's gonna give us the analyst perspective on, as a service, you're watching the cube, the leader in high tech enterprise coverage. >>Why are customers making the change to pure as a service >>Other vendors, offering flexible consumption models will promise you the world on the surface. It's just what you need. But then you notice the asterisk that dreaded fine print. That turns just what you need into long-term commitments, disruptive upgrades and unpredictable costs, pure storage, launched pure as a service to provide the flexibility to respond to your ever changing needs. With clear per unit costs, no large upfront purchases and no asterisks. A usage based model should be simple, innovative, and adapt with the changing market. Unlike other vendors, pure is offering exactly that with options, for service tiers and short term contracts in a single unified subscription that allows you to improve your discounts over time. Pure makes sure you can grow and upgrade without ever taking your environment offline and without the constant worry of hidden costs with complete billing, transparency, unlike any other, you only pay for what you use and pure one helps track and predict demand from day to day, making sure you never outgrow your storage. So why are customers making the change to pure as a service convenient solutions with unlimited potential without the dreaded fine print? It's as simple as that, >>We're back with Steve McDowell, the principal analyst for data and storage at more insights and strategy. Hey Steve, great to have you on, tell us a little bit about yourself. You got a really interesting background and kind of a blend of engineering and strategy and what's your research focus? >>Yeah, so my research, my focus area is data and storage and all the things around that, right? Whether it's OnPrim or cloud or, or, or, you know, software as a service. Uh, my background, as you said, is a blend, right? I grew up as an engineer. I started off as an OS developer at IBM. Uh, came up through the ranks and, and shifted over into corporate strategy and product marketing and product management. Uh, and I've been doing, uh, working as an industry analyst now for about five years, more insights and strategy. >>Steve, how do you see this playing out in the next three to five years? I mean, cloud got it all started. It's gonna snowballing, you know, however you look at it, percent of spending on storage that you think is gonna land in as a service. How, how do you see the evolution here? >>I think it buyers are looking at as a service, a consumption based is, is, uh, uh, you know, a natural model. It extends the data center, brings all of the flexibility, all of the goodness that I get from public cloud, but without all of the downside and uncertainty around cost and security and things like that, right. That also come with a public cloud and it's delivered by technology providers that I trust and that I know, and that I've worked with, you know, for, in some cases, decades. So I don't know that we have hard data on how much, uh, adoption there is of the model, but we do know that it's trending up, uh, you know, and every infrastructure provider at this point has some flavor of offering in the space. So it's, it's clearly popular with CIOs and, and it practitioners alike. >>So Steve organizations are at a they're different levels of maturity in their, their transformation journeys. And of course, as a result, they're gonna have different storage needs that are aligned with their bottom line business objectives. From an it buyer perspective, you may have data on this, even if it's anecdotal, where does storage as a service actually fit in and can it be a growth lever >>Can absolutely be, uh, a growth leader. Uh, it, it gives me the flexibility as, as an it architect to scale my business over time, without worrying about how much money I have to invest in, in storage hardware. Right? So I, I get kind of, again, that cloudlike flexibility in terms of procurement and deployment. Uh, but it gives me that control by oftentimes being on site within my permit. And I manage it like a storage array that I own. Uh, so you know, it, it's, it's beautiful for, for organizations that are scaling and, and it's equally nice for organizations that just wanna manage and control cost over time. Um, so it's, it's a model that makes a lot of sense and fits and, and certainly growing in adoption and popularity. >>How about from a technology vendor perspective you've worked for in the, in the tech industry mm-hmm <affirmative> for, for companies? What do you think is gonna define the winners and losers in this space? If you were running strategy for, uh, storage company, what would you say? >>I, I think the days of, of a storage administrator managing, you know, rate levels and recovering and things of that sort are over, right, what would, what these organizations like pure delivering, but they're offerings is, is simplicity. It's a push button approach to deploying storage to the applications and workloads that need it, right. It becomes storage as a utility. So it's not just the, you know, the consumption based economic model of, of, uh, as a service. Uh, it, it's also the manageability that comes with that, or the flexibility of management that comes with that. I can push a button, deploy bites to, to, uh, you know, a workload that needs it. Um, and it just becomes very simple, right. For the storage administrator in a way that, you know, kind of old school OnPrim storage can't really deliver. >>You know, I wanna, I wanna ask you, I mean, I've been thinking about this because again, a lot of companies are, are, you know, moving, hopping on the, as a service bandwagon, I feel like, okay, in and of itself, that's not where the innovation lives, the innovation is gonna come from making that singular experience from on-prem to the clouds across clouds, maybe eventually out to the edge. Um, do you, do you, where do you see the innovation in as a service? >>Well, there there's two levels of innovation, right? One, one is business model innovation, right? I, I now have an organizational flexibility to build the infrastructure, to support my digital transformation efforts. Um, but on the product side and the offering side, it really is, as you said, it's about the integration of experience. Every enterprise today touches a cloud in some way, shape or form, right. I have data spread, not just in my data center, but at the edge, uh, oftentimes in a public cloud, maybe a private cloud, I don't know where my data is and it really lands on the storage providers to help me manage that and deliver that, uh, uh, manageability experience, uh, to, to the it administrators. So when I look at innovation in this space, you know, it's not just a storage array and rack that I'm leasing, right? This is not another lease model. It's really fully integrated, you know, end to end management of my data and, and, you know, and all of the things around that. >>Yeah. So you, to your point about a lease model is if you're doing a lease, you know, yeah. You can shift CapEx to OPEX, but you're still committed to, to, you have to over provision, whereas here, and I wanted to ask you about that. It's, it's, it's, it's an interesting model, right? Cuz you gotta read the fine print. Of course the fine print says you gotta commit to some level typically. And then if, you know, if you go over you, you charge for what you use and you can scale that back down and that's, that's gotta be very attractive for folks. I, I wonder if you will ever see like true cloud-like consumption pricing, that is two edges to it. Right. You see consumption based pricing in some of the software models and you know yeah. People like it, the lines of business maybe cuz they pay in by the drink, but then procurement hates it cuz they don't have predictability. How do you see the pricing models? Do you see that maturing or do you think we're sort of locked in on, on where we're at? >>No, I, I do. I do see that maturing. Right? And, and when you work with a company like pure to understand their consumption based and as a service offerings, uh, it, it really is sitting down and understanding where your data needs are going to scale, right? You, you buy in at a certain level, uh, you have capacity planning. You can expand if you need to, you can shrink if you need to. So it really does put more control in the hands of the it buyer than uh, well certainly then traditional CapEx based on-prem but also more control than you would get, you know, working with an Amazon or an Azure. >>Okay. Thanks Steve. We'll leave it there for now. I'd love to have you back. Keep it right there at your storage service continues in a moment. >>Some things are meant to last your storage should be one of them say hello to the evergreen storage program, say goodbye to refreshes and rebates. Forget planned downtime, performance impact and data migrations. Forget forklift upgrades. Evergreen storage starts with your agile storage architecture and covers the entire life cycle of the array from first purchase to ongoing use. And whenever it's time to modernize and grow, your satisfaction is covered with an evergreen subscription. You can get a full refund within 30 days for any reason, >>Our right size guarantee lets you buy just the storage you need never too much. Never not enough. Your array software is all inclusive. Even future releases and features maintenance and support costs remain constant throughout the life of your array. Proactive expert support is a true white glove experience. Evergreen maintenance ensures availability of any replacement components. Meet the demands of your business and protect your investment. Evergreen gold includes controller upgrades every three years. And if something unplanned comes up, evergreen gold provides upgrade flex the leading anytime upgrade feature to upgrade controllers whenever you need it. As you expand evergreen gold provides credits to consolidate storage with denser more modern flash. Evergreen is your subscription to continuous innovation for storage that lasts 10 years or more. Some things are meant to last make your storage. One of them >>We're back at your storage service. Emil Stan is here. He's the chief commercial officer and chief marketing officer of open line. Thank you Emil for coming on the cube. Appreciate your time. >>Thank you, David. Nice. Uh, glad to be here. >>Yes. Yeah. So tell us about open line. You're a managed service provider. What's your focus? >>Yeah, we're actually a cloud managed service provider and I do put cloud in front of the managed services because it's not just only the spheres that we manage. We have to manage the clouds as well nowadays. And then unfortunately, everybody only thinks there's one cloud, but it's always multiple layers in the cloud. So we have a lot of work in integrating it. We're a cloud manages provider in the Netherlands, focusing on, uh, companies who have head office in the Netherlands, mainly in the, uh, healthcare local government, social housing logistics department. And then in the midst size companies between say 250 to 10,000 office employees. Uh, and that's what we do. We provide 'em with excellent cloud managed services, uh, as it should be >>Interesting, you know, a lot early on in the cloud days, highly regulated industries like healthcare government were somewhat afraid of the cloud. So I'm sure that's one of the ways in which you provide value to your customers is helping them become cloud proficient. Maybe you could talk a little bit more about the value prop to customers. Why do they do business with you? >>And I think, uh, there are a number of reasons why they do business with us or choose to choose for our manage services provider that first of course are looking for stability and continuity. Uh, and, and from a cost perspective, predict predictable costs. But nowadays you also have a shortage in personnel and knowledge. So, and it's not always very easy for them to access, uh, those skill sets because most it, people just want to have, uh, a great variety in work, what they are doing, uh, towards, towards the local government, uh, healthcare, social housing. They actually, uh, a sector that, uh, that are really in between embracing the public cloud, but also have a lot of legacy and, and bringing together best of all, worlds is what we do. So we also bring them comfort. We do understand what legacy, uh, needs from a manager's perspective. We also know how to leverage the benefits in the public cloud. Uh, and, uh, I'd say from a marketing perspective, actually we focus on using an ideal cloud, being a mix of traditional and future based cloud. >>Thank you. I, you know, I'd like to get your perspective on this idea of as a service and the, as a service economy that we often talk about on the cube. I mean, you work with a lot of different companies. We talked about some of the industries and, and increasingly it seems like organizations are focused more on outcomes, continuous value delivery via, you know, suites of services and, and they're leaning into platforms versus one off product offerings, you know, do you see that? How do you see your customers reacting to this as a service trend? >>Yeah. Uh, to be honest, sometimes it makes it more complex because services like, look at your Android or iPhone, you can buy apps, uh, and download apps the way you want to. So they have a lot of apps about how do you integrate it into one excellent workflow, something that works for you, David or works for me. Uh, so the difficulty, some sometimes lies in, uh, the easy accessibility that you have to those solutions, but nobody takes into account that they're all part of a chain, a workflow supply chain, uh, and, and, uh, they're being hyped as well. So what we also have a lot of time in, in, in, in managing our customers is that the tremendous feature push feature push that there is from technology providers, SaaS providers. Whereas if you provide 10 features, you only need one or two, uh, but the other eight are very distracting from your prime core business. Uh, so there's a natural way in that people are embracing, uh, SA solutions, embracing cloud solutions. Uh, but what's not taken into account as much is that we love to see it is the way that you integrate all those solutions toward something that's workable for the person that's actually using them. And it's seldomly that somebody is only using one solution. There's always a chain of solutions. Um, so yeah, there are a lot of opportunities, but also a lot of challenges for us, but also for our customers, >>You see that trend toward, as a service continuing, or do you actually see based on what you're just saying that pendulum, you know, swinging back and forth, somebody comes out with a new sort of feature product and that, you know, changes the dynamic or do you see as a service really having legs? >>Ah, I, I think that's very, very good question, David, because that's something that's keeping our busy all the time. We do see a trend in a service looking at, uh, talk about pure later on. We also use pure as a service more or less. Yeah. And that really helps us. Uh, but you see, uh, um, that sometimes people make a step too, too fast, too quick, not well thought of, and then you see what they call sort of cloud repatriation, tend that people go back to what they're doing and then they stop innovating or stop leveraging. The possibilities are actually there. Uh, so from our consultancy, our guidance and architecture point of view, we try to help them as much as possible to think in a SA thought, but just don't use the, cloud's just another data center. Uh, and so it's all about managing the maturity on our side, but on our customer side as well. >>So I'm interested in how your sort of your philosophy and, and as relates, I think in, in, in terms of how you work with pure, but how do you stay tightly in lockstep with your customers so that you don't over rotate so that you don't and send them to over rotate, but then you're not also, you don't wanna be too late to the game. How, how do you manage all that? >>Oh, there's, there's, there's a world of interactions between us and our customers. And so I think a well known, uh, uh, thing that people is customer intimacy. That's very important for us to get to know our customers and get to predict which way they're moving. But the, the thing that we add to it is also the ecosystem intimacy. So no, the application and services landscape, our customers know the primary providers and work with them, uh, to, to, to create something that, that really fits the customers. They just not looked at from our own silo where a cloud managed service provider that we actually work in the ecosystem with, with, with, with the primary providers. And we have, I think with the average customers, I think we have, uh, uh, in a month we have so much interactions on our operational level and technical levels, strategic level. >>We do bring together our customers also, and to jointly think about what we can do together, what we independently can never reach. Uh, but we also involve our customers in, uh, defining our own strategy. So we have something we call a customer involvement board. So we present a strategy and say, does it make sense? Eh, this is actually what you need also. So we take a lot of our efforts into our customers and we do also, uh, understand the significant moments of truth. We are now in this, in this broadcast, David there. So you can imagine that at this moment, not thinking go wrong. Yeah. If, if, if the internet stops that we have a problem. And now, so we, we actually know that this broadcast is going on for our customers and we manage that. It's always on, uh, uh, where in the other moments in the week, we might have a little less attention, but this moment we should be there. And these moments of truth that we really embrace, we got them well described. Everybody working out line knows what the moment of truth is for our customers. Uh, uh, so we have a big logistics provider. For instance, you does not have to ask us to, uh, have, uh, a higher availability on black Friday or cyber Monday. We know that's the most important part in the year for him or her. Does it answer your question, David? >>Yes. We know as well. You know, when these big, the big game moments you have to be on your top, uh, top of your game, uh, you know, the other thing Emil about this as a service approach that I really like is, is it's a lot of it is consumption based and the data doesn't lie, you can see adoption, you know, daily, weekly, monthly. And so I wonder how you're leveraging pure as a service specifically in what kind of patterns you're seeing in, in, in the adoption. >>Uh, yeah, pure as a service for our customers is mainly never visible. Uh, we provide storage services to provide storage solutions, storage over is part of a bigger thing of a server of application. Uh, so the real benefits, to be honest, of course, towards our customer, it's all flash, uh, uh, and they have the fastest, fastest storage is available. But for ourself, we, uh, we use less resources to manage our storage. We have far more that we have a near to maintenance free storage solution now because we have it as a service and we work closely together with pure. Uh, so, uh, actually the way we treat our customers is that way pure treats us as well. And that's why there's a used click. So the real benefits, uh, uh, how we leverage is it normally we had a bunch of guys managing our storage. Now we only have one and knowing that's a shortage of it, personnel, the other persons can well be, uh, involved in other parts of our services or in other parts of an innovation. So, uh, that's simply great. >>You know, um, my takeaway the meal is that you've made infrastructure, at least, least the storage infrastructure, invisible to your customers, which is the way it should be. You didn't have to worry about it. And you've, you've also attacked the, the labor problem. You're not, you know, provisioning lungs anymore, or, you know, tuning the storage, you know, with, with arms and legs. So that's huge. So that gets me into the next topic, which is business transformation. That, that means that I can now start to attack the operational model. So I've got a different it model. Now I'm not managing infrastructure same way. So I have to shift those resources. And I'm presuming that it's a bus now becomes a business transformation discussion. How are you seeing your customers shift those resources and focus more on their business as a result of this sort of as a service trend? >>I think I do not know if they, they transform their business. Thanks to us. I think that they can more leverage their own business. They have less problems, less maintenance, et cetera, cetera, but we also add new, uh, certainties to it, like, uh, uh, the, the latest service we we released was imutable storage being the first in the Netherlands offering this thanks to, uh, thanks to the pure technology, but for customers, it takes them to give them a good night rest because, you know, we have some, uh, geopolitical issues in the world. Uh, there's a lot of hacking. People have a lot of ransomware attacks and, and we just give them a good night rest. So from a business transformation, does it transform their business? I think that gives them a comfort in running your business, knowing that certain things are well arranged. You don't have to worry about that. We will do that. We'll take it out of your hands and you just go ahead and run your business. Um, so to me, it's not really a transformation is just using the right opportunities at the right moment. >>The imutable piece is interesting because, because, but speaking of as a service, you know, anybody can go on the dark web and buy ransomware as a service. I mean, as it's seeing the, as a service economy hit, hit everywhere, the good and the, and the not so good. Um, and so I presume that your customers are, are looking at, I imutability as another service capability of the service offering and really rethinking, maybe because of the recent, you know, ransomware attacks, rethinking how they, they approach, uh, business continuance, business resilience, disaster recovery. Do you see that? >>Yep, definitely. Definitely. I tell not all of them yet. Imutable storage. So it's like an insurance as well, which you have when you have imutable storage and you have been, you have a ransomware attack at least have you part of data, which never, if data is corrupted, you cannot restore it. If your hardware is broken, you can order new hardware. Every data is corrupted. You cannot order new data. Now we got that safe and well. And so we offer them the possibility to, to do the forensics and free up their, uh, the data without tremendous loss of time. Uh, but you also see that you raise the new, uh, how do you say, uh, the new baseline for other providers as well? Eh, so there's security of the corporate information security officer, the CIO, they're all very happy with that. And they, they, they raise the baseline for us as well. So they can look at other security topics and look from say, security operation center. Cuz now we can really focus on our prime business risks because from a technical perspective, we got it covered. How can we manage the business risk, uh, which is a combination of people, processes and technology. >>Right. Makes sense. Okay. I'll give you the last word. Uh, talk about your relationship with pure, where you wanna see that that going in the future. >>Uh, I hope we've be working together for a long time. Uh, I, I ex experienced them very involved. Uh, it's not, we have done the sell and now it's all up to you now. We were closely working together. I know if I talk to my prime architect, Marcel height is very happy and it looks a little more or less if we work with pure, like we're working with colleagues, not with a supplier and a customer, uh, and uh, the whole pure concept is fascinating. Uh, I, uh, I had the opportunity to visit San Francisco head office and they told me to fish in how they launched, uh, pure being, if you want to implement it, it had to be on one credit card. The, the, the menu had to be on one credit card. Just a simple thought of put that as your big area, audacious goal to make the simplest, uh, implementable storage available. But for us, uh, it gives me the expectation that there will be a lot of more surprises with pur in the near future. Uh, and for us as a provider, what we, uh, literally really look forward to is that, that for us, these new developments will not be new migrations. It will be a gradual growth of our services or storage services. Uh, so that's what I expect. And that was what I, and we look forward to. >>Yeah, that's great. Uh, thank you so much, Emil, for coming on the, the cube and, and sharing your thoughts and best of luck to you in the future. >>Thank you. You're welcome. Thanks for having me. >>You're very welcome. Okay. In a moment, I'll be back to give you some closing thoughts on at your storage service. You're watching the cube, the leader in high tech enterprise coverage. >>Welcome to evergreen, a place where organizations grow and thrive rooted in the modern data experience in evergreen people find a seamless, simple way to leverage data through market leading sustainable technology, financial flexibility, and effortless management, allowing everyone to innovate with data confidently. Welcome to pure storage. >>Now, if you're interested in hearing more about Pure's growing portfolio of technology and services and how they're transforming the enterprise data experience, be sure to register for pure accelerate tech Fest. 22 digital event is also taking place as an in-person event. On June 8th, you can register at pure storage.com/accelerate, pure storage.com/accelerate. You're watching the cue, the leader in enterprise and emerging tech coverage.

(upbeat music) >> Okay, we're back with Atri Basu who is Cisco's resident philosopher who also holds a master's in computer science. We're going to have to unpack that a little bit. And Necati Cehreli, who's technical lead at Cisco. Welcome, guys. Thanks for coming on theCUBE. >> Happy to be here. >> Thanks a lot. >> All right, let's get into it. We want you to explain how Cisco validated the Zebrium technology and the proof points that you have that it actually works as advertised. So first Atri, first tell us about Cisco TAC. What does Cisco TAC do? >> So TAC is otherwise it's an acronym for Technical Assistance Center, is Cisco's support arm, the support organization. And the risk of sounding like I'm spouting a corporate line. The easiest way to summarize what TAC does is provide world class support to Cisco customers. What that means is we have about 8,000 engineers worldwide and any of our Cisco customers can either go on our web portal or call us to open a support request. And we get about 2.2 million of these support requests a year. And what these support requests are, are essentially the customer will describe something that they need done some networking goal that they have that they want to accomplish. And then it's TACs job to make sure that that goal does get accomplished. Now, it could be something like they're having trouble with an existing network solution and it's not working as expected or it could be that they're integrating with a new solution. They're, you know, upgrading devices maybe there's a hardware failure anything really to do with networking support and, you know the customer's network goals. If they open up a case for testing for help then TACs job is to respond and make sure the customer's, you know questions and requirements are met. About 44% of these support requests are usually trivial and, you know can be solved within a call or within a day. But the rest of TAC cases really involve getting into the network device, looking at logs. It's a very technical role. It's a very technical job. You need to be conversed with network solutions, their designs, protocols, et cetera. >> Wow. So 56% non-trivial. And so I would imagine you spend a lot of time digging through logs. Is that true? Can you quantify that like, you know, every month how much time you spend digging through logs and is that a pain point? >> Yeah, it's interesting you asked that because when we started on this journey to augment our support engineers workflow with Zebrium solution, one of the things that we did was we went out and asked our engineers what their experience was like doing log analysis. And the anecdotal evidence was that on average an engineer will spend three out of their eight hours reviewing logs either online or offline. So what that means is either with the customer live on a WebEx, they're going to be going over logs, network, state information, et cetera or they're going to do it offline where the customer sends them the logs it's attached to a, you know, a service request and they review it and try to figure out what's going on and provide the customer with information. So it's a very large chunk of our day. You know, I said 8,000 plus engineers and so three hours a day that's 24,000 man hours a day spent on log analysis. Now the struggle with logs or analyzing logs is there by out of necessity, logs are very contrite. They try to pack a lot of information in a very little space. And this is for performance reasons, storage reasons, et cetera, but the side effect of that is they're very esoteric. So they're hard to read if you're not conversant if you're not the developer who wrote these logs or you aren't doing code deep dives. And you're looking at where this logs getting printed and things like that, it may not be immediately obvious or even after a little while it may not be obvious what that log line means or how it correlates to whatever problem you're troubleshooting. So it requires tenure. It requires, you know, like I was saying before it requires a lot of knowledge about the protocol what's expected because when you're doing log analysis what you're really looking for is a needle in a haystack. You're looking for that one anomalous event, that single thing that tells you this shouldn't have happened, and this was a problem right. Now doing that kind of anomaly detection requires you to know what is normal. It requires, you know, what the baseline is. And that requires a very in depth understanding of, you know the state changes for that network solution or product. So it requires time to near and expertise to do well. And it takes a lot of time even when you have that kind of expertise. >> Wow. So thank you, Atri. And Necati, that's almost two days a week for a technical resource. That's not inexpensive. So what was Cisco looking for to sort of help with this and how'd you stumble upon Zebrium? >> Yeah, so, we have our internal automation system which has been running more than a decade now. And what happens is when a customer attach log bundle or diagnostic bundle into the service request we take that from the Sr we analyze it and we represent some kind of information. You know, it can be alerts or some tables, some graph, to the engineer, so they can, you know troubleshoot this particular issue. This is an incredible system, but it comes with its own challenges around maintenance to keep it up to date and relevant with Cisco's new products or a new version of a product, new defects, new issues and all kind of things. And when I mean with those challenges are let's say Cisco comes up with a product today. We need to come together with those engineers. We need to figure out how this bundle works, how it's structured out. We need to select individual logs, which are relevant and then start modeling these logs and get some values out of those logs, using PaaS or some rag access to come to a level that we can consume the logs. And then people start writing rules on top of that abstraction. So people can say in this log I'm seeing this value together with this other value in another log, maybe I'm hitting this particular defect. So that's how it works. And if you look at it, the abstraction it can fail the next time. And the next release when the development or engineer decides to change that log line which you write that rag X or we can come up with a new version which we completely change the services or processes then whatever you have wrote needs to be re-written for the new service. And we see that a lot with products, like for instance, WebEx where you have a very short release cycle that things can change maybe the next week with a new release. So whatever you are writing, especially for that abstraction and for those rules are maybe not relevant with that new release. With that being said we have a incredible rule creation process and governance process around it which starts with maybe a defect. And then it takes it to a level where we have an automation in place. But if you look at it, this really ties to human bandwidth. And our engineers are really busy working on you know, customer facing, working on issues daily and sometimes creating news rules or these PaaS are not their biggest priorities so they can be delayed a bit. So we have this delay between a new issue being identified to a level where we have the automation to detect it next time that some customer faces it. So with all these questions and with all challenges in mind we start looking into ways of actually how we can automate these automation. So these things that we are doing manually how we can move it a bit further and automate. And we had actually a couple of things in mind that we were looking for and this being one of them being this has to be product agnostic. Like if Cisco comes up with a product tomorrow I should be able to take it logs without writing, you know, complex regs, PaaS, whatever and deploy it into this system. So it can embrace our logs and make sense of it. And we wanted this platform to be unsupervised. So none of the engineers need to create rules, you know, label logs, this is bad, this is good. Or train the system like which requires a lot of computational power. And the other most important thing for us was we wanted this to be not noisy at all because what happens with noises when your level of false positives really high your engineers start ignoring the good things between that noise. So they start the next time, you know thinking that this thing will not be relevant. So we want something with a lot more less noise. And ultimately we wanted this new platform or new framework to be easily adaptable to our existing workflow. So this is where we started. We start looking into the, you know first of all, internally, if we can build this thing and also start researching it, and we came up to Zebrium actually Larry, one of the co-founders of Zebrium. We came upon his presentation where he clearly explained why this is different, how this works and it immediately clicked in and we said, okay, this is exactly what we were looking for. We dive deeper. We checked the block posts where Zebrium guys really explain everything very clearly there. They're really open about it. And most importantly, there is a button in their system. And so what happens usually with AI ML vendors is they have this button where you fill in your details and a sales guys call you back and you know, explains the system here. They were like, this is our trial system. We believe in the system you can just sign up and try it yourself. And that's what we did. We took one of our Cisco live DNA Center, wireless platforms. We start streaming logs out of it. And then we synthetically, you know, introduce errors like we broke things. And then we realized that Zebrium was really catching the errors perfectly. And on top of that, it was really quiet unless you are really breaking something. And the other thing we realized was during that first trial is Zebrium was actually bringing a lot of context on top of the logs. During those failures, we worked with couple of technical leaders and they said, "Okay if this failure happens I'm expecting this individual log to be there." And we found out with Zebrium apart from that individual log there were a lot of other things which gives a bit more context around the root cause, which was great. And that's where we wanted to take it to the next level. Yeah. >> Okay. So, you know, a couple things to unpack there. I mean, you have the dart board behind you which is kind of interesting, 'cause a lot of times it's like throwing darts at the board to try to figure this stuff out. But to your other point, Cisco actually has some pretty rich tools with AppD and doing observability and you've made acquisitions like thousand eyes. And like you said, I'm presuming you got to eat your own dog food or drink your own champagne. And so you've got to be tools agnostic. And when I first heard about Zebrium, I was like wait a minute. Really? I was kind of skeptical. I've heard this before. You're telling me all I need is plain text and a timestamp. And you got my problem solved. So, and I understand that you guys said, okay let's run a POC. Let's see if we can cut that from, let's say two days a week down to one day, a week. In other words, 50%, let's see if we can automate 50% of the root cause analysis. And so you funded a POC. How did you test it? You put, you know, synthetic, you know errors and problems in there, but how did you test that, it actually works Necati? >> Yeah. So we wanted to take it to the next level which is meaning that we wanted to back test is with existing SaaS. And we decided, you know, we chose four different products from four different verticals, data center security, collaboration, and enterprise networking. And we find out SaaS where the engineer put some kind of log in the resolution summary. So they closed the case. And in the summary of the SR, they put "I identified these log lines and they led me to the root cause" and we ingested those log bundles. And we tried to see if Zebrium can surface that exact same log line in their analysis. So we initially did it with archery ourself and after 50 tests or so we were really happy with the results. I mean, almost most of them we saw the log line that we were looking for but that was not enough. And we brought it of course to our management and they said, "Okay, let's try this with real users" because the log being there is one thing but the engineer reaching to that log is another take. So we wanted to make sure that when we put it in front of our users, our engineers, they can actually come to that log themselves because, you know, we know this platform so we can, you know make searches and find whatever we are looking for but we wanted to do that. So we extended our pilots to some selected engineers and they tested with their own SaaS. Also due some back testing for some SaaS which are closed in the past or recently. And with a sample set of, I guess, close to 200 SaaS we find out like majority of the time, almost 95% of the time the engineer could find the log they were looking for in Zebrium's analysis. >> Yeah. Okay. So you were looking for 50%, you got the 95%. And my understanding is you actually did it with four pretty well known Cisco products, WebEx client, DNA Center Identity services, engine ISE, and then UCS. Unified pursuit. So you use actual real data and that was kind of your proof point, but Atri, so that sounds pretty impressive. And have you put this into production now and what have you found? >> Well, yes, we've launched this with the four products that you mentioned. We're providing our TAC engineers with the ability, whenever a support bundle for that product gets attached to the support request. We are processing it, using sense and then providing that sense analysis to the TAC engineer for their review. >> So are you seeing the results in production? I mean, are you actually able to reclaim that time that people are spending? I mean, it was literally almost two days a week down to you know, a part of a day, is that what you're seeing in production and what are you able to do with that extra time and people getting their weekends back? Are you putting 'em on more strategic tasks? How are you handling that? >> Yeah. So what we're seeing is, and I can tell you from my own personal experience using this tool that troubleshooting any one of the cases, I don't take more than 15 to 20 minutes to go through the Zebrium report. And I know within that time either what the root causes or I know that Zebrium doesn't have the information that I need to solve this particular case. So we've definitely seen, well it's been very hard to measure exactly how much time we've saved per engineer, right? Again, anecdotally, what we've heard from our users is that out of those three hours that they were spending per day, we're definitely able to reclaim at least one of those hours and what even more importantly, you know, what the kind of feedback that we've gotten in terms of I think one statement that really summarizes how Zebrium's impacted our workflow was from one of our users. And they said, "Well, you know, until you provide us with this tool, log analysis was a very black and white affair, but now it's become really colorful." And I mean, if you think about it log analysis is indeed black and white. You're looking at it on a terminal screen where the background is black and the text is white, or you're looking at it as a text where the background is white and the text is black, but what they're really trying to say is there are hardly any visual cues that help you navigate these logs which are so esoteric, so dense, et cetera. But what Zebrium does is it provides a lot of color and context to the whole process. So now you're able to quickly get to, you know using their Word Cloud, using their interactive histogram, using the summaries of every incident. You're very quickly able to summarize what might be happening and what you need to look into. Like, what are the important aspects of this particular log bundle that might be relevant to you? So we've definitely seen that. A really great use case that kind of encapsulates all of this was very early on in our experiment. There was this support request that had been escalated to the business unit or the development team. And the TAC engineer had really, they had an intuition about what was going wrong because of their experience because of, you know the symptoms that they'd seen. They kind of had an idea but they weren't able to convince the development team because they weren't able to find any evidence to back up what they thought was happening. And it was entirely happenstance that I happened to pick up that case and did an analysis using Zebrium. And then I sat down with a TAC engineer and we were very quickly within 15 minutes we were able to get down to the exact sequence of events that highlighted what the customer thought was happening, evidence of what the sorry not the customer what the TAC engineer thought was a root cause. And then we were able to share that evidence with our business unit and, you know redirect their resources so that we could chase down what the problem was. And that that really shows you how that color and context helps in log analysis. >> Interesting. You know, we do a fair amount of work in theCUBE in the RPA space, the robotic process automation and the narrative in the press when our RPA first started taking off was, oh, it's, you know machines replacing humans, or we're going to lose jobs. And what actually happened was people were just eliminating mundane tasks and the employees actually very happy about it. But what my question to you is was there ever a reticence amongst your team? Like, oh, wow, I'm going to lose my job if the machine's going to replace me or have you found that people were excited about this and what's been the reaction amongst the team? >> Well, I think, you know, every automation and AI project has that immediate gut reaction of you're automating away our jobs and so forth. And there is initially there's a little bit of reticence but I mean, it's like you said once you start using the tool, you realize that it's not your job, that's getting automated away. It's just that your job's becoming a little easier to do and it's faster and more efficient. And you're able to get more done in less time. That's really what we're trying to accomplish here. At the end of the day, Zebrium will identify these incidents. They'll do the correlation, et cetera. But if you don't understand what you're reading then that information's useless to you. So you need the human you need the network expert to actually look at these incidents, but what we are able to skin away or get rid of is all of is all the fat that's involved in our process like without having to download the bundle, which, you know when it's many gigabytes in size and now we're working from home with the pandemic and everything, you're, you know pulling massive amounts of logs from the corporate network onto your local device that takes time and then opening it up, loading it in a text editor that takes time. All of these things are we're trying to get rid of. And instead we're trying to make it easier and quicker for you to find what you're looking for. So it's like you said, you take away the mundane you take away the difficulties and the slog but you don't really take away the work the work still needs to be done. >> Yeah, great. Guys, thanks so much appreciate you sharing your story. It's quite, quite fascinating. Really. Thank you for coming on. >> Thanks for having us. >> You're very welcome. >> Excellent. >> Okay. In a moment, I'll be back to wrap up with some final thoughts. This is Dave Vellante and you're watching theCUBE. (upbeat music)

>> Narrator: From around the globe, it's theCUBE, with digital coverage of IBM Think 2021 brought to you by IBM. >> Welcome to theCUBEs coverage of IBM Think 2021. I'm Lisa Martin. Exciting conversation coming up about in vaccine cloud management. I've got two guests with me, Tim Elcott is here, the sales and delivery director of IBM services for Salesforce and Fran Thompson joins us as well, the CEO of the Health Service Executive in Ireland. Gentlemen, welcome to the program. >> Hi, there. >> Hi. >> Good to be here. >> So we're very socially distance, Northern California, UK. Glad to have you guys here. We're going to talk about what the Health Service Executive or HSE in Ireland has done with IBM and Salesforce to facilitate vaccine management. But Fran, let's go ahead and start with you, talk to us a little bit about HSE. >> Well, the HSE provides public health and social services to everyone living in Ireland, okay. We got Acute hospitals, community services nationally. We directly employ about 80,000 people and we formed a farther about 40,000 people. And our annual budget is slightly North of 21.6 billion a year. We are the largest employer in the state and the largest organizations in the state. And, you know, we provide a huge range of services right across the whole spectrum. And we also formed other organizations who provide those services as well. So we would fund some voluntary and charity organizations and we would also buy services from the likes of say GP and other organizations as well. >> So talk to me about a year or so ago when the pandemic hit what were some of the challenges that HSE faced? And then when it came time to, we have a vaccine, we have multiple vaccines that rollout capability what were some of the challenges that you faced initially? >> So from an organizational perspective, there were huge challenges in that we were like every other health service worldwide facing an enormous pandemic that was impacting on people. And this is all about people, it's all about people's lives at the end of the day. People can talk about numbers and they can talk about costs and they can talk about other elements but at the end of the day this is about individual, people's lives, their families and their communities. And for the HSE, our challenge was really about how do we manage to protect the totality of the population in Ireland, as much as we can from the ravages of the virus. And the initial challenge we had was around contact tracing and managing that before a vaccine became available. And once the vaccine became available it was then how do we stand up a national vaccine solution that we would be able to deliver and record vaccines to the totality of the population who were getting a vaccine. >> Yeah, so there was no preexisting vaccination program of course, probably in most places you needed to get healthcare workers vaccinated ASAP and it's also needed to be a national program. So what did you do next after determining all right, we need to work with some partners to be able to build technology to facilitate equitable efficient rollout of the vaccine? >> So we did have regional vaccine systems and we do have a number of vaccine programs out there that were managing flu vaccine, Hep C vaccine, but we didn't have a national program and we needed to vaccinate people immediately. And we also wanted to make sure that vaccine program was not dependent on the HSE infrastructure, because we want to be able to vaccinate people in non HSE sites, and we wanted non HSE staff to be able to vaccinate. And we didn't want a huge pre-dependence on our existing infrastructure. So the first thing we did, we looked at a number of vendors and we chose IBM as our partner with Salesforce. And that partnership is really a strategic partnership and it's a partnership that we worked to all the bumps and all the lumps through the program together and there have been challenges but like it's still working with Tim and his team and to our team that we've overcome some of those challenges. And like, when we started off I remember the very first conversation I had with Tim he said, "Look, we need to vaccinate healthcare workers now, okay? And you've got two weeks to start and we need to configure a system, get it up and running and to be able to roll it out to the hospitals and very quickly then to all of our nursing care homes now" and that was the challenge. >> And let's bring Tim in, and this is a radically quick project from MPV to roll out in two weeks. Tim talk to us first about the IBM partnership with Salesforce and what you're building together. >> Absolutely, it's great and Fran it's interesting to hear you speaking about the running into this, 'cause from my perspective a week before we all started this we had a simple conversation called into the Health Service Executive they're talking about some vaccination program how can we help? And then within a week, we've gone from zero to having how many calls with Fran and team just to understand and with the Salesforce team to really understand how the three parties can bring the best of IBM, the best of Salesforce and the best of HSE in terms of the adaptability and what we need to get done to get those vaccinations up and running for the healthcare workers now. When Fran said to me, "We need something in two weeks." There was absolutely clarity, if you can't do it in two weeks there's the door, right? So we knew exactly the challenge and that's the kind of thing right before Christmas that we were so fortunate to really bring in the team, like everyone you think about this, everyone has probably the 14th of December was thinking of winding down, thinking of having their Christmas holidays and vacation time. And everybody from the Irish team and from the English team said, "No, we will cancel Christmas, we will cancel everything." So is it really Christmas came early and Christmas was canceled all at once. So, and the key bit here, the strategic partnership is IBM and Salesforce have been working together for years and years and years growing out a partnership. We know their products really well, we've got huge capability in that space. But actually with the new health cloud part of it the vaccine management parts are quite new to Salesforce as well only launched back in sort of the August, September time. So it's quite new. So we had to go in together as a sort of a partnership there to say, "Did you get this done?" So we had the best people from Salesforce who know the product, the best people from IBM all turning up on the 14th of December and saying, "Right, we've got to get this done by the 29th, with Christmas holidays in the way, the vacation time in the way." I think we had 36 hours of time off to eat turkey and fill ourselves before getting back to the wheel and really getting this done. And to get I think it was four acute hospitals we went into as of the 29th to start the vaccination program. So trying to do that, understanding everything is a compromise at that point. Yeah, but it has to be secure, you know this is personal data going into these systems. So you can't forget about all the aspects it's got as minimum, but minimum with those kinds of constraints as a health system. So it needs to be secure, it needs to also be that national platform going forwards as well. So basing on a great platform like Salesforce, you know you can scale out, you know you've got those options to grow in the future, but yeah, not without a lot of challenge and then working out what's now getting to know each other, but if we only talked about twice before we ever know each other pretty well now. But just trying to work out how we then structure what's going to happen every two weeks afterwards, how's that going to move forward? We're going live every two weeks and we have done that now for the last three months, so, good fun. >> So, yeah, good fun. But so much work to get done and accord a huge coordinated effort in a very short time period during a very challenging time. Talk to me a little bit about Fran but you launched this Vaccine Cloud Management in January, 2021. And to date, I think you told me 1 million people have been vaccinated so far. Talk to me about what the IBM, Salesforce solution enables you to deliver to the HSE and to the Irish citizens. >> So we have delivered a million vaccines, okay in two stages. The dose one, the dose two for most people in Ireland. And there's about 720,000 people got their dose one and the balance have got the dose two. That's about sort of just about one in five of the population that has to be vaccinated. And one of things we were very conscious of is that as an organization like that we need to take a risk based approach to this. So we need to look at the most vulnerable groups there were lots of people who were dying from this. And a lot of people were elderly groups, and people who were vulnerable with pre medical conditions. So our challenge was how do we vaccinate those people quickly and effectively and also vaccinate healthcare workers who are going to care for these people. And that's where we prioritize the work. So we have to go into 50 acute sites about 600 or so care homes, we set up a lot of what we call pop-up clinics literally a tent in a location, or we took over a sports hall or whatever we did. We rolled it out to the GP so about two and a half thousand GP sites. And all of that was being done while we were building the system. So we were building the system and designing a system on two week sprints. We have to be agile, we have to be quick, we had to make huge compromises and we know that. Though I hate to admit it everyone wants a perfect system, which will make the compromise and look into what do you need to do now to keep the program running? And how you manage that with about 3,000 users all to be set up fairly quickly or a little over half thousand users. So you have to manage all that as you're going through everything. >> I think agile is the name of the game here. Tim, talk to us about how you're delivering the agility in such a tenuous time. >> Well, we're all virtual, which is added to the mix. But the funny thing with that agility we've got a span of people across all the countries and everywhere that we can bring in to that party. And yeah, we're running what I would call a normal agile project, except normally it would take two, three months to really get that team working effectively, getting to know each other and we just not had time to do that. So there's been a core team here and we're bringing in the experts around it but really just everything is working with Fran, worked very hand in glove trying just to work out, what we need to do here, to look at the next sprint to look at the next go live, to look at the compromise. How do we compromise for two weeks? What can we live with for two weeks? What's in the backlog for now and Fran and I have many conversations. What do we need to do this week and then what's next week? And that's level of fluidity and that's in part because of the way the pandemics and the response of pandemic is mapping out. As we saw the vaccines are changing, availability is changing, the rollout plan is changing. None of us have worked through a pandemic before. So agility is the name of the game at the highest level. I think we're all now very used to being, sorry there's a problem something's changed, can we adapt the system too, you know, and normally in a sprint I'll be thinking, I've got some fixed requirements for two weeks, I'll build that and then do the next two weeks. Everything is up for grabs and we're just having to maintain quality at the pace, the responsiveness and balancing it all as an IBM team and you think. And whilst we're also doing that on a platform that it takes time to configure and build these things as well. So it's some of it is you're going to have to wait a few days. So we're sorry, you know, a few days is really the probably sometimes the maximum amount of time that can be you can defer, but as Fran and everyone in the HSE and the National Immunization Office, everyone's pragmatic about realizing we're all in this together and it's really just being one single team, one unit working out and very open and transparent about the odds that are possible. >> And when doing something... Go ahead, Fran. >> We had a phrase there like there was a pieces we just had, "Just do it now." And we did a lot of that, okay? You know, where there were things that were prioritized were in the middle of a sprint, there were changes in the program or there were changes in how the vaccination was going to be delivered. And we couldn't waste the week just wasn't available. So we have the thing just got to do it now. And Tim and the team they'll drop what they were doing you know, made the changes, we tested them fast and we pulled them in and then gave us an extra time to actually then deliver the rest of the sprint. We have to do that several occasions, several very, very late night delivers. >> And I imagine that's still going on, but to wrap here guys, an amazing work that you've done together so far with the Salesforce Vaccine Club Management rolling out across the HSE you said 1 million vaccinations delivered many hundreds of thousands in the queue. I'm sure more iterative work and sleepless nights but what you're doing for the country of Ireland is literally as Fran said in the beginning, lifesaving. Gentlemen, thank you so much for joining me today on the program. >> You're welcome, thank you. >> You're very welcome. Thank you. >> From Tim and Fran I'm Lisa Martin. You're watching theCUBEs coverage of IBM Think 2021. (upbeat music)

>>Hello, everyone. This is Dave Volonte with the Cube. On December 9th, the cube 3. 65 will be hosting Green Lake Day. Brought to you by Hewlett Packard Enterprise. Now Green Lake is H P E S. As a service initiative, it's designed to bring a cloud like experience to your I t environment, regardless of physical location. Now let me give you my take on what's happening here. Look, if you're a company that has relied primarily on selling hardware and infrastructure software on premises for decades, and you >>don't own a public cloud public cloud, well, you'd better have a strategy that supports the single most important trend in the business over the >>past decade. And that's cloud computing. HP formally announced Green Lake a year ago and really was the first to do so in the modern era. We're seeing others follow suit, and why not? The infrastructure World is taking a page out of the SAS business from a transaction and pricing standpoint where SAS models are being applied toe large portfolios of companies that sell and service, compute storage and networking gear and associated software. Now, like sass, these models generally require customers toe lock into a term >>of a least a year or mawr, and they'll require the customer to commit to a minimum threshold of capacity. So it's not a perfect replica replica of the pure paid by the drink. Cancel anytime public cloud model. But as I've said, neither is most SAS. For instance, when you buy from workday and salesforce and service now and many others, you have to commit to a term now with infrastructure. It's even more complex because the vendor has to install capacity and commit that to the customer. If you so choose, you can scale up or down and Onley pay for what you use as long as you commit to the term and pay for a certain minimum. So it's a shared risk model, which is a big step in the right direction. Now I will tell you that initiatives like Green Lake involves much more than playing financial games. I mean, that technique has been around forever since the mainframe days. No, true as a service, models require entirely new thinking around product design, salesforce, compensation, tooling to provide transparency and predictability, etcetera, for example, technology vendors they gotta get out of the mindset of selling boxes. They have to think about packaging services. When you sell a box, you drop it on the loading dock. You make sure it's delivered and deployed. You sign the customer up for a maintenance contract and you go on to the next one. In a model like Green Lake, the renewal process starts when the contract is signed. You have to earn the customers loyalty every day. Not that you don't have to do so in the old model, but it's different in and as a service context because it's not just >>the services organization has to worry about the customer renewing its everyone from the CEO down to the support specialist look churn is the silent killer oven. As a service model, an entirely new incentive and metric system has to emerge to support this change. The company also has to think about its portfolio not as products, but is a suite of services turning their product portfolio into a set of services with a P I s and an ecosystem that can plug into that. It's a completely different mindset now. Also share that. I think the infrastructure guys are playing catch up and It's high time we've seen this model emerge. Catch up to the SAS folks, that is, but I predict that it will continue to evolve. Let me give an example. We're now seeing software companies challenged the traditional SAS Model two examples, or snowflake and Data dog who's selling a consumption basis. It's a true cloud model where the customer can leave anytime. And I predict that over time, as SAS companies and eventually infrastructure >>players get more and more data, they're gonna be forced to look at similar pricing strategies. And as they get MAWR this data and can better predict usage, they'll >>increase their confidence and deploying such a consumption model. Now back to HP Green Lake H P E. By being first and committing the entire company to this approach from the top. Antonio Neary He's like the the CEO. He's a champion of this change. By being first, HP believes that it has an advantage. The company also believes that it has some innovations that will keep it ahead of the competition. So I encourage you to check out the link in the description of this video, register for Green Lake Day and decide for yourself I'll be there with a number of HP experts and customers to share what the future of as a service will look like and what it means to you. So look, if you're a CEO and infrastructure pro, ah, partner in the in the HP ecosystem, an existing customer or someone who is following these trends and wants to learn mawr, register for Green >>Lake Day and participate in the conversation, you'll have the opportunity to interact, live with experts, ask questions and hopefully get answers that will help you plan for the future. We'll see you there.

hello everyone this is dave vellante with thecube on december 9th the cube 365 will be hosting green lake day brought to you by hewlett packard enterprise now green lake is hpe's as a service initiative it's designed to bring a cloud-like experience to your it environment regardless of physical location now let me give you my take on what's happening here look if you're a company that has relied primarily on selling hardware and infrastructure software on premises for decades and you don't own a public cloud public cloud well you'd better have a strategy that supports the single most important trend in the business over the past decade and that's cloud computing hpe formally announced green lake a year ago and really was the first to do so in the modern era we're seeing others follow suit and why not the infrastructure world is taking a page out of the sas business from a transaction and pricing standpoint where sas models are being applied to large portfolios of companies that sell and service compute storage and networking gear and associated software now like sas these models generally require customers to lock into a term of at least a year or more and they'll require the customer to commit to a minimum threshold of capacity so it's not a perfect replica replica of the pure pay by the drink cancel anytime public cloud model but as i've said neither is most sas for instance when you buy from workday and salesforce and servicenow and many others you have to commit to a term now with infrastructure it's even more complex because the vendor has to install capacity and commit that to the customer if you so choose you can scale up or down and only pay for what you use as long as you commit to the term and pay for a certain minimum so it's a shared risk model which is a big step in the right direction now i will tell you that initiatives like green lake involve much more than playing financial games i mean that technique has been around forever since the mainframe days no true as a service models require entirely new thinking around product design sales force compensation tooling to provide transparency and predictability etc for example technology vendors they got to get out of the mindset of selling boxes they have to think about patch packaging services when you sell a box you drop it on the loading dock you make sure it's delivered and deployed you sign the customer up for a maintenance contract and you go on to the next one in a model like green lake the renewal process starts when the contract is signed you have to earn the customer's loyalty every day not that you don't have to do so in the old model but it's different in an as a service context because it's not just the services organization has to worry about the customer renewing it's everyone from the ceo down to the support specialist look chern is the silent killer of an as a service model an entirely new incentive and metric system has to emerge to support this change company also has to think about its portfolio not as products but as a suite of services turning their product portfolio into a set of services with apis and an ecosystem that can plug into that it's a completely different mindset now also share that i think the infrastructure guys are playing catch up and it's high time we've seen this model emerge catch up to the sas folks that is but i predict that it will continue to evolve let me give an example we're now seeing software companies challenge the traditional sas model two examples are snowflake and datadog who sell on a consumption basis it's a true cloud model where the customer can leave any time and i predict that over time as sas companies and eventually infrastructure players get more and more data they're going to be forced to look at similar pricing strategies and as they get more of this data and can better predict usage they'll increase their confidence in deploying such a consumption model now back to hpe greenlake hpe by being first and committing the entire company to this approach from the top antonio neri he's like the ceo he's a champion of this change by being first hpe believes that it has an advantage the company also believes that it has some innovations that will keep it ahead of the competition so i encourage you to check out the link in the description of this video register for green lake day and decide for yourself i'll be there with a number of hpe experts and customers to share what the future of as a service will look like and what it means to you so look if you're a cio an infrastructure pro a partner in the in the hpe ecosystem an existing customer or someone who's following these trends and wants to learn more register for green lake day and participate in the conversation you'll have the opportunity to interact live with experts ask questions and hopefully get answers that will help you plan for the future we'll see you there

>> Thank you, everyone for joining. I'm here today to talk about ingress controllers, API gateways, and service mesh on Kubernetes, three very hot topics that are also frequently confusing. So I'm Richard Li, founder/CEO of Ambassador Labs, formerly known as Datawire. We sponsor a number of popular open source projects that are part of the Cloud Native Computing Foundation, including Telepresence and Ambassador, which is a Kubernetes native API gateway. And most of what I'm going to talk about today is related to our work around Ambassador. So I want to start by talking about application architecture and workflow on Kubernetes and how applications that are being built on Kubernetes really differ from how they used to be built. So when you're building applications on Kubernetes, the traditional architecture is the very famous monolith. And the monolith is a central piece of software. It's one giant thing that you build deploy, run. And the value of a monolith is it's really simple. And if you think about the monolithic development process, more importantly is that architecture is really reflected in that workflow. So with a monolith, you have a very centralized development process. You tend not to release too frequently because you have all these different development teams that are working on different features, and then you decide in advance when you're going to release that particular piece of software and everyone works towards that release train. And you have specialized teams. You have a development team, which has all your developers. You have a QA team, you have a release team, you have an operations team. So that's your typical development organization and workflow with a monolithic application. As organizations shift to microservices, they adopt a very different development paradigm. It's a decentralized development paradigm where you have lots of different independent teams that are simultaneously working on different parts of this application, and those application components are really shipped as independent services. And so you really have a continuous release cycle because instead of synchronizing all your teams around one particular vehicle, you have so many different release vehicles that each team is able to ship as soon as they're ready. And so we call this full cycle development because that team is really responsible not just for the coding of that microservice, but also the testing and the release and operations of that service. So this is a huge change, particularly with workflow, and there's a lot of implications for this. So I have a diagram here that just tries to visualize a little bit more the difference in organization. With the monolith, you have everyone who works on this monolith. With microservices, you have the yellow folks work on the yellow microservice and the purple folks work on the purple microservice and maybe just one person work on the orange microservice and so forth. So there's a lot more diversity around your teams and your microservices, and it lets you really adjust the granularity of your development to your specific business needs. So how do users actually access your microservices? Well, with a monolith, it's pretty straightforward. You have one big thing, so you just tell the internet, well, I have this one big thing on the internet. Make sure you send all your traffic to the big thing. But when you have microservices and you have a bunch of different microservices, how do users actually access these microservices? So the solution is an API gateway. So the API gateway consolidates all access to your microservices. So requests come from the internet. They go to your API gateway. The API gateway looks at these requests, and based on the nature of these requests, it routes them to the appropriate microservice. And because the API gateway is centralizing access to all of the microservices, it also really helps you simplify authentication, observability, routing, all these different cross-cutting concerns, because instead of implementing authentication in each of your microservices, which would be a maintenance nightmare and a security nightmare, you've put all of your authentication in your API gateway. So if you look at this world of microservices, API gateways are a really important part of your infrastructure which are really necessary, and pre-microservices, pre-Kubernetes, an API gateway, while valuable, was much more optional. So that's one of the really big things around recognizing with the microservices architecture, you really need to start thinking much more about an API gateway. The other consideration with an API gateway is around your management workflow, because as I mentioned, each team is actually responsible for their own microservice, which also means each team needs to be able to independently manage the gateway. So Team A working on that microservice needs to be able to tell the API gateway, this is how I want you to route requests to my microservice, and the purple team needs to be able to say something different for how purple requests get routed to the purple microservice. So that's also a really important consideration as you think about API gateways and how it fits in your architecture, because it's not just about your architecture, it's also about your workflow. So let me talk about API gateways on Kubernetes. I'm going to start by talking about ingress. So ingress is the process of getting traffic from the internet to services inside the cluster. Kubernetes, from an architectural perspective, it actually has a requirement that all the different pods in a Kubernetes cluster needs to communicate with each other. And as a consequence, what Kubernetes does is it creates its own private network space for all these pods, and each pod gets its own IP address. So this makes things very, very simple for interpod communication. Kubernetes, on the other hand, does not say very much around how traffic should actually get into the cluster. So there's a lot of detail around how traffic actually, once it's in the cluster, how you route it around the cluster, and it's very opinionated about how this works, but getting traffic into the cluster, there's a lot of different options and there's multiple strategies. There's Pod IP, there's Ingress, there's LoadBalancer resources, there's NodePort. I'm not going to go into exhaustive detail on all these different options, and I'm going to just talk about the most common approach that most organizations take today. So the most common strategy for routing is coupling an external load balancer with an ingress controller. And so an external load balancer can be a hardware load balancer. It can be a virtual machine. It can be a cloud load balancer. But the key requirement for an external load balancer is to be able to attach a stable IP address so that you can actually map a domain name and DNS to that particular external load balancer, and that external load balancer usually, but not always, will then route traffic and pass that traffic straight through to your ingress controller. And then your ingress controller takes that traffic and then routes it internally inside Kubernetes to the various pods that are running your microservices. There are other approaches, but this is the most common approach. And the reason for this is that the alternative approaches really require each of your microservices to be exposed outside of the cluster, which causes a lot of challenges around management and deployment and maintenance that you generally want to avoid. So I've been talking about an ingress controller. What exactly is an ingress controller? So an ingress controller is an application that can process rules according to the Kubernetes ingress specification. Strangely, Kubernetes is not actually shipped with a built-in ingress controller. I say strangely because you think, well, getting traffic into a cluster is probably a pretty common requirement, and it is. It turns out that this is complex enough that there's no one size fits all ingress controller. And so there is a set of ingress rules that are part of the Kubernetes ingress specification that specify how traffic gets routed into the cluster, and then you need a proxy that can actually route this traffic to these different pods. And so an ingress controller really translates between the Kubernetes configuration and the proxy configuration, and common proxies for ingress controllers include HAProxy, Envoy Proxy, or NGINX. So let me talk a little bit more about these common proxies. So all these proxies, and there are many other proxies. I'm just highlighting what I consider to be probably the three most well-established proxies, HAProxy, NGINX, and Envoy Proxy. So HAProxy is managed by HAProxy Technologies. Started in 2001. The HAProxy organization actually creates an ingress controller. And before they created an ingress controller, there was an open source project called Voyager which built an ingress controller on HAProxy. NGINX, managed by NGINX, Inc., subsequently acquired by F5. Also open source. Started a little bit later, the proxy, in 2004. And there's the Nginx-ingress, which is a community project. That's the most popular. As well as the Nginx, Inc. kubernetes-ingress project, which is maintained by the company. This is a common source of confusion because sometimes people will think that they're using the NGINX ingress controller, and it's not clear if they're using this commercially supported version or this open source version. And they actually, although they have very similar names, they actually have different functionality. Finally, Envoy Proxy, the newest entrant to the proxy market, originally developed by engineers at Lyft, the ride sharing company. They subsequently donated it to the Cloud Native Computing Foundation. Envoy has become probably the most popular cloud native proxy. It's used by Ambassador, the API gateway. It's used in the Istio service mesh. It's used in the VMware Contour. It's been used by Amazon in App Mesh. It's probably the most common proxy in the cloud native world. So as I mentioned, there's a lot of different options for ingress controllers. The most common is the NGINX ingress controller, not the one maintained by NGINX, Inc., but the one that's part of the Kubernetes project. Ambassador is the most popular Envoy-based option. Another common option is the Istio Gateway, which is directly integrated with the Istio mesh, and that's actually part of Docker Enterprise. So with all these choices around ingress controller, how do you actually decide? Well, the reality is the ingress specification's very limited. And the reason for this is that getting traffic into a cluster, there's a lot of nuance into how you want to do that, and it turns out it's very challenging to create a generic one size fits all specification because of the vast diversity of implementations and choices that are available to end users. And so you don't see ingress specifying anything around resilience. So if you want to specify a timeout or rate-limiting, it's not possible. Ingress is really limited to support for HTTP. So if you're using gRPC or web sockets, you can't use the ingress specification. Different ways of routing, authentication. The list goes on and on. And so what happens is that different ingress controllers extend the core ingress specification to support these use cases in different ways. So NGINX ingress, they actually use a combination of config maps and the ingress resources plus custom annotations that extend the ingress to really let you configure a lot of the additional extensions that is exposed in the NGINX ingress. With Ambassador, we actually use custom resource definitions, different CRDs that extend Kubernetes itself to configure Ambassador. And one of the benefits of the CRD approach is that we can create a standard schema that's actually validated by Kubernetes. So when you do a kub control apply of an Ambassador CRD, kub control can immediately validate and tell you if you're actually applying a valid schema and format for your Ambassador configuration. And as I previously mentioned, Ambassador's built on Envoy Proxy, Istio Gateway also uses CRDs. They can be used in extension of the service mesh CRDs as opposed to dedicated gateway CRDs. And again, Istio Gateway is built on Envoy Proxy. So I've been talking a lot about ingress controllers, but the title of my talk was really about API gateways and ingress controllers and service mesh. So what's the difference between an ingress controller and an API gateway? So to recap, an ingress controller processes Kubernetes ingress routing rules. An API gateway is a central point for managing all your traffic to Kubernetes services. It typically has additional functionality such as authentication, observability, a developer portal, and so forth. So what you find is that not all API gateways are ingress controllers because some API gateways don't support Kubernetes at all. So you can't, they can't be ingress controllers. And not all ingress controllers support the functionality such as authentication, observability, developer portal, that you would typically associate with an API gateway. So generally speaking, API gateways that run on Kubernetes should be considered a superset of an ingress controller. But if the API gateway doesn't run on Kubernetes, then it's an API gateway and not an ingress controller. So what's the difference between a service mesh and an API gateway? So an API gateway is really focused on traffic into and out of a cluster. So the colloquial term for this is North/South traffic. A service mesh is focused on traffic between services in a cluster, East/West traffic. All service meshes need an API gateway. So Istio includes a basic ingress or API gateway called the Istio Gateway, because a service mesh needs traffic from the internet to be routed into the mesh before it can actually do anything. Envoy Proxy, as I mentioned, is the most common proxy for both mesh and gateways. Docker Enterprise provides an Envoy-based solution out of the box, Istio Gateway. The reason Docker does this is because, as I mentioned, Kubernetes doesn't come package with an ingress. It makes sense for Docker Enterprise to provide something that's easy to get going, no extra steps required, because with Docker enterprise, you can deploy it and get going, get it exposed on the internet without any additional software. Docker Enterprise can also be easily upgraded to Ambassador because they're both built on Envoy. It ensures consistent routing semantics. And also with Ambassador, you get greater security for single sign-on. There's a lot of security by default that's configured directly into Ambassador. Better control over TLS, things like that. And then finally, there's commercial support that's actually available for Ambassador. Istio is an open source project that has a very broad community, but no commercial support options. So to recap, ingress controllers and API gateways are critical pieces of your cloud native stack. So make sure that you choose something that works well for you. And I think a lot of times organizations don't think critically enough about the API gateway until they're much further down the Kubernetes journey. Considerations around how to choose that API gateway include functionality such as how does it do with traffic management and observability? Does it support the protocols that you need? Also nonfunctional requirements such as does it integrate with your workflow? Do you offer commercial support? Can you get commercial support for this? An API gateway is focused on North/South traffic, so traffic into and out of your Kubernetes cluster. A service mesh is focused on East/West traffic, so traffic between different services inside the same cluster. Docker Enterprise includes Istio Gateway out of the box. Easy to use, but can also be extended with Ambassador for enhanced functionality and security. So thank you for your time. Hope this was helpful in understanding the difference between API gateways, ingress controllers, and service meshes, and how you should be thinking about that on your Kubernetes deployment.

>>thank you everyone for joining. I'm here today to talk about English controllers. AP Gateways and service mention communities three very hot topics that are also frequently confusing. So I'm Richard Lee, founder CEO of Ambassador Labs, formerly known as Data Wire. We sponsor a number of popular open source projects that are part of the Cloud Native Computing Foundation, including telepresence and Ambassador, which is a kubernetes native AP gateway. And most of what I'm going to talk about today is related to our work around ambassador. Uh huh. So I want to start by talking about application architecture, er and workflow on kubernetes and how applications that are being built on kubernetes really differ from how they used to be built. So when you're building applications on kubernetes, the traditional architectures is the very famous monolith, and the monolith is a central piece of software. It's one giant thing that you build, deployed run, and the value of a monolith is it's really simple. And if you think about the monolithic development process, more importantly, is the architecture er is really reflecting that workflow. So with the monolith, you have a very centralized development process. You tend not to release too frequently because you have all these different development teams that are working on different features, and then you decide in advance when you're going to release that particular pieces offering. Everyone works towards that release train, and you have specialized teams. You have a development team which has all your developers. You have a Q A team. You have a release team, you have an operations team, so that's your typical development organization and workflow with a monolithic application. As organization shift to micro >>services, they adopt a very different development paradigm. It's a decentralized development paradigm where you have lots of different independent teams that are simultaneously working on different parts of the application, and those application components are really shipped as independent services. And so you really have a continuous release cycle because instead of synchronizing all your teams around one particular vehicle, you have so many different release vehicles that each team is able to ship a soon as they're ready. And so we call this full cycle development because that team is >>really responsible, not just for the coding of that micro service, but also the testing and the release and operations of that service. Um, >>so this is a huge change, particularly with workflow. And there's a lot of implications for this, s o. I have a diagram here that just try to visualize a little bit more the difference in organization >>with the monolith. You have everyone who works on this monolith with micro services. You have the yellow folks work on the Yellow Micro Service, and the purple folks work on the Purple Micro Service and maybe just one person work on the Orange Micro Service and so forth. >>So there's a lot more diversity around your teams and your micro services, and it lets you really adjust the granularity of your development to your specific business need. So how do users actually access your micro services? Well, with the monolith, it's pretty straightforward. You have one big thing. So you just tell the Internet while I have this one big thing on the Internet, make sure you send all your travel to the big thing. But when you have micro services and you have a bunch of different micro services, how do users actually access these micro services? So the solution is an AP gateway, so the gateway consolidates all access to your micro services, so requests come from the Internet. They go to your AP gateway. The AP Gateway looks at these requests, and based on the nature of these requests, it routes them to the appropriate micro service. And because the AP gateway is centralizing thing access to all the micro services, it also really helps you simplify authentication, observe ability, routing all these different crosscutting concerns. Because instead of implementing authentication in each >>of your micro services, which would be a maintenance nightmare and a security nightmare, you put all your authentication in your AP gateway. So if you look at this world of micro services, AP gateways are really important part of your infrastructure, which are really necessary and pre micro services. Pre kubernetes Unhappy Gateway Well valuable was much more optional. So that's one of the really big things around. Recognizing with the micro services architecture er, you >>really need to start thinking much more about maybe a gateway. The other consideration within a P A gateway is around your management workflow because, as I mentioned, each team is actually response for their own micro service, which also means each team needs to be able to independently manage the gateway. So Team A working on that micro service needs to be able to tell the AP at Gateway. This this is >>how I want you to write. Request to my micro service, and the Purple team needs to be able to say something different for how purple requests get right into the Purple Micro Service. So that's also really important consideration as you think about AP gateways and how it fits in your architecture. Because it's not just about your architecture. It's also about your workflow. So let me talk about a PR gateways on kubernetes. I'm going to start by talking about ingress. So ingress is the process of getting traffic from the Internet to services inside the cluster kubernetes. From an architectural perspective, it actually has a requirement that all the different pods in a kubernetes cluster needs to communicate with each other. And as a consequence, what Kubernetes does is it creates its own private network space for all these pods, and each pod gets its own I p address. So this makes things very, very simple for inter pod communication. Cooper in any is, on the other hand, does not say very much around how traffic should actually get into the cluster. So there's a lot of detail around how traffic actually, once it's in the cluster, how you routed around the cluster and it's very opinionated about how this works but getting traffic into the cluster. There's a lot of different options on there's multiple strategies pot i p. There's ingress. There's low bounce of resource is there's no port. >>I'm not gonna go into exhaustive detail on all these different options on. I'm going to just talk about the most common approach that most organizations take today. So the most common strategy for routing is coupling an external load balancer with an ingress controller. And so an external load balancer can be >>ah, Harvard load balancer. It could be a virtual machine. It could be a cloud load balancer. But the key requirement for an external load balancer >>is to be able to attack to stable I people he address so that you can actually map a domain name and DNS to that particular external load balancer and that external load balancer, usually but not always well, then route traffic and pass that traffic straight through to your ingress controller, and then your English controller takes that traffic and then routes it internally inside >>kubernetes to the various pods that are running your micro services. There are >>other approaches, but this is the most common approach. And the reason for this is that the alternative approaches really required each of your micro services to be exposed outside of the cluster, which causes a lot of challenges around management and deployment and maintenance that you generally want to avoid. So I've been talking about in English controller. What exactly is an English controller? So in English controller is an application that can process rules according to the kubernetes English specifications. Strangely, Kubernetes is not actually ship with a built in English controller. Um, I say strangely because you think, well, getting traffic into a cluster is probably a pretty common requirement. And it is. It turns out that this is complex enough that there's no one size fits all English controller. And so there is a set of ingress >>rules that are part of the kubernetes English specifications at specified how traffic gets route into the cluster >>and then you need a proxy that can actually route this traffic to these different pods. And so an increase controller really translates between the kubernetes configuration and the >>proxy configuration and common proxies for ingress. Controllers include H a proxy envoy Proxy or Engine X. So >>let me talk a little bit more about these common proxies. So all these proxies and there >>are many other proxies I'm just highlighting what I consider to be probably the most three most well established proxies. Uh, h a proxy, uh, Engine X and envoy proxies. So H a proxy is managed by a plastic technology start in 2000 and one, um, the H a proxy organization actually creates an ingress controller. And before they kept created ingress controller, there was an open source project called Voyager, which built in ingress Controller on >>H a proxy engine X managed by engine. Xing, subsequently acquired by F five Also open source started a little bit later. The proxy in 2004. And there's the engine Xing breast, which is a community project. Um, that's the most popular a zwelling the engine Next Inc Kubernetes English project which is maintained by the company. This is a common source of confusion because sometimes people will think that they're using the ingress engine X ingress controller, and it's not clear if they're using this commercially supported version or the open source version, and they actually, although they have very similar names, uh, they actually have different functionality. Finally. Envoy Proxy, the newest entrant to the proxy market originally developed by engineers that lift the ride sharing company. They subsequently donated it to the cloud. Native Computing Foundation Envoy has become probably the most popular cloud native proxy. It's used by Ambassador uh, the A P a. Gateway. It's using the SDO service mash. It's using VM Ware Contour. It's been used by Amazon and at mesh. It's probably the most common proxy in the cloud native world. So, as I mentioned, there's a lot of different options for ingress. Controller is the most common. Is the engine X ingress controller, not the one maintained by Engine X Inc but the one that's part of the Cooper Nannies project? Um, ambassador is the most popular envoy based option. Another common option is the SDO Gateway, which is directly integrated with the SDO mesh, and that's >>actually part of Dr Enterprise. So with all these choices around English controller. How do you actually decide? Well, the reality is the ingress specifications very limited. >>And the reason for this is that getting traffic into the cluster there's a lot of nuance into how you want to do that. And it turns out it's very challenging to create a generic one size fits all specifications because of the vast diversity of implementations and choices that are available to end users. And so you don't see English specifying anything around resilience. So if >>you want to specify a time out or rate limiting, it's not possible in dresses really limited to support for http. So if you're using GSPC or Web sockets, you can't use the ingress specifications, um, different ways of routing >>authentication. The list goes on and on. And so what happens is that different English controllers extend the core ingress specifications to support these use cases in different ways. Yeah, so engine X ingress they actually use a combination of config maps and the English Resource is plus custom annotations that extend the ingress to really let you configure a lot of additional extensions. Um, that is exposing the engineers ingress with Ambassador. We actually use custom resource definitions different CRTs that extend kubernetes itself to configure ambassador. And one of the benefits of the CRD approach is that we can create a standard schema that's actually validated by kubernetes. So when you do a coup control apply of an ambassador CRD coop Control can immediately validate and tell >>you if you're actually applying a valid schema in format for your ambassador configuration on As I previously mentioned, ambassadors built on envoy proxy, >>it's the Gateway also uses C R D s they can to use a necks tension of the service match CRD s as opposed to dedicated Gateway C R D s on again sdo Gateway is built on envoy privacy. So I've been talking a lot about English controllers. But the title of my talk was really about AP gateways and English controllers and service smashed. So what's the difference between an English controller and an AP gateway? So to recap, an immigrant controller processes kubernetes English routing rules and a P I. G. Wave is a central point for managing all your traffic to community services. It typically has additional functionality such as authentication, observe, ability, a >>developer portal and so forth. So what you find Is that not all Ap gateways or English controllers? Because some MP gateways don't support kubernetes at all. S o eso you can't make the can't be ingress controllers and not all ingrates. Controllers support the functionality such as authentication, observe, ability, developer portal >>that you would typically associate with an AP gateway. So, generally speaking, um, AP gateways that run on kubernetes should be considered a super set oven ingress controller. But if the A p a gateway doesn't run on kubernetes, then it's an AP gateway and not an increase controller. Yeah, so what's the difference between a service Machin and AP Gateway? So an AP gateway is really >>focused on traffic into and out of a cluster, so the political term for this is North South traffic. A service mesh is focused on traffic between services in a cluster East West traffic. All service meshes need >>an AP gateway, so it's Theo includes a basic ingress or a P a gateway called the SDO gateway, because a service mention needs traffic from the Internet to be routed into the mesh >>before it can actually do anything Omelet. Proxy, as I mentioned, is the most common proxy for both mesh and gateways. Dr. Enterprise provides an envoy based solution out of the box. >>Uh, SDO Gateway. The reason Dr does this is because, as I mentioned, kubernetes doesn't come package with an ingress. Uh, it makes sense for Dr Enterprise to provide something that's easy to get going. No extra steps required because with Dr Enterprise, you can deploy it and get going. Get exposed on the Internet without any additional software. Dr. Enterprise can also be easily upgraded to ambassador because they're both built on envoy and interest. Consistent routing. Semantics. It also with Ambassador. You get >>greater security for for single sign on. There's a lot of security by default that's configured directly into Ambassador Better control over TLS. Things like that. Um And then finally, there's commercial support that's actually available for Ambassador. SDO is an open source project that has a has a very broad community but no commercial support options. So to recap, ingress controllers and AP gateways are critical pieces of your cloud native stack. So make sure that you choose something that works well for you. >>And I think a lot of times organizations don't think critically enough about the AP gateway until they're much further down the Cuban and a journey. Considerations around how to choose that a p a gateway include functionality such as How does it do with traffic management and >>observe ability? Doesn't support the protocols that you need also nonfunctional requirements such as Does it integrate with your workflow? Do you offer commercial support? Can you get commercial support for this on a P? A. Gateway is focused on north south traffic, so traffic into and out of your kubernetes cluster. A service match is focused on East West traffic, so traffic between different services inside the same cluster. Dr. Enterprise includes SDO Gateway out of the box easy to use but can also be extended with ambassador for enhanced functionality and security. So thank you for your time. Hope this was helpful in understanding the difference between a P gateways, English controllers and service meshes and how you should be thinking about that on your kubernetes deployment

(funky music) >> From our studios in the heart of Silicon Valley, Palo Alto, California, this is a Cube Conversation. >> Hi, welcome to another Wikibon digital community event, this one sponsored by BMC Software. Every organization faces the challenge of how to do service management and operations management better. The ideal is to start bringing them together, but traditionally, they've been undertaken by different groups, often utilizing different tools. And that's what we're going to talk about today in today's digital community event. What can we do to improve our digital business operations, competitiveness, and customer experience, by doing a better job of bringing together those core resources that handle service management and operations management activities. As with all digital community events, this one's going to feature some upfront conversations with a number of thought leaders in this crucial space, and then we're going to run a crowd chat, which will be your opportunity to share your insights, ask your questions, and ultimately, communicate with others like you in the community that focuses on this important issue. So stay through to the end and help us participate in that digital community event. Now, recently, I had an opportunity to attend BMC Helix's Immersion Day, and while there, theCUBE was able to conduct a number of different interviews. One of the best ones we had was a great conversation with Nayaki Nayyar, who is the president of service management and operations management at the BMC Helix division, and Mihir Shukla, who is the CEO of Automation Anywhere. Let's hear what they had to say about the potential of bringing service management and operations management together. >> So, Nayaki, I want to start with you. A year ago, we started on this journey of how this new digital services platform is going to evolve to do more types of work for people. How has BMC's Helix platform evolved in that time? >> So, if you remember last time, it was almost a year back when we launched Helix, which was all around taking the service management capability that we had on prem, made it available in Cloud, containerized, so customers can run in cloud of their choice, and provided experience through various channels, bought as a channel of that customer experience. This is what we had released last time, we call it the three C's for Helix, everything in cloud, containerized, with cognitive capabilities, so customers can transform their experience. In this version, what we are extending Helix is with the operations side, so all the ITOM capabilities that we have in our platform are now a part of Helix, so we have one end-to-end platform, so that customers can discover every asset that they have on prem and cloud, monitor those assets, detect any anomalies, service both for lines of business and for IT, remediate any issues that happen, vulnerabilities that are there in the system, and automatically optimize capacity and cost and holistically, this whole closed loop of operations and service coming together is what this next wave of innovations that we are launching with BMC Helix. >> So, Mihir, Nayaki's talked about, very successfully, and Helix has been a very successful platform for improving user experience, but up front I noted that we're not just talking about human beings as users anymore, we're now talking about software as users. RPA, robotic process automation, is a central feature of some of these new trends. Tell us a little bit about how robotic process automation is driving an increased need for this kind of digital service in operations management capability. >> Sure, think in a high level, you have to think of the new organization as augmented organization that are human and bots working side by side, each doing what they're best at. And so in a specific example of a service organization, where BMC Helix is taking this is, think of this as a utility, where the way you plug it into an electricity outlet and switch on the light and you get the electricity, you plug into the BMC Helix, and behind it you have augmented workflows of chart bots, RPA bots, human beings, each doing what they're best at, and giving a far superior customer experience, unlike any other. That is happening now, and that's the future of service industry. >> But when you plug a human, so to speak, metaphorically, into that system, there's a certain amount of time, there's a certain amount of training, and as a consequence you can have a little bit more predictable scale. That doesn't mean that you don't end up with a lot of complexity, but RPA seems, the potential of RPA seems that you're going to increase the rate at which these users, in this case, digital users, are going to enter into the system, you don't have a training regimen you can attach to them, they have to be tested, they have to be discovered, they have to be put in operation with reliability, how is that ultimately driving the need for some of these new capabilities? >> I think if you think of these bots as digital workers, you almost have to go through the same process that you would go through human beings. You onboard them, in terms of, you configure them, you train them with cognitive capabilities, and then the one difference is they monitor themselves, without any bias, they can give their own performance rating card. But the beauty of this is when human and bots work together, because there are some functions that the bots can do well and then at some point they can hand off to the human beings, and human beings do some of the more interesting work that is based on judgment call, customer service, all of that. So that the combination is the end goal for everybody. >> And to add to what Mihir said, right, that customer experience, whether you're providing an experience to employees or consumers or end customers, that is the ultimate goal, that's the ultimate result of what you want to get, and the speed at which you provide that experience is the accuracy at which you provide experience, the cost at which you provide that experience becomes a comparative differentiation, which is where all this automation, this augmentation that they're doing with humans and bots, is what enables us to do that, right? For all large enterprise customers, major service organizations trying to transform into that future goal. >> But increasingly it seems as though the things that we have to do, to orchestrate and administrate, more users, digital and human, undertaking more complex tasks where each is best applied, is really driving a lot of new data, as I mentioned upfront, an enormous amount of new software, and you said new experiences, but those experiences have to be reliable, have to be secure, they have to be predictable. So that suggests this overwhelming impact of all of these capabilities. You talk about a digital tsunami. What are some of the key things that you think enterprises are going to have to do to start engaging that? >> Yeah, and whether we call it revolution, whether we call it digital transformation, I think what we all are experiencing is a tsunami, tech tsunami, right, tsunami of clouds where you have professional clouds, private clouds, hybrid clouds, managed clouds. Tsunami of devices, not just the mobile devices, but also as everything is getting connected, IoT devices. Tsunami of channels, as an end user, I want to experience that in the channel of my preference, Slack as a channel, SM as a channel. A tsunami of bots, of conversation bots and RPA bots, so in this tsunami, I think what everyone is trying to figure out is, how do they manage this explosion? It's humanly impossible to do it all manually you have to augment it, with of course, intelligence AIML, but then of course bots become a big part of that augmentation to orchestrate all of that back to back process. >> I would say that this is no longer nice to have, because if you look at it from a more consumer's perspective, last 20 years of digital technologies from Amazons and Googles of the world, Netflix and others, they have created this mindset of instant customer gratification. And we all been trained for it, so what was acceptable five years ago is no longer acceptable in our own lives. And so this new standard of instant result, instant outcome, instant respond, instant delivery, we just expect it, right? Once your end consumer begins to do that, we as a business no longer have a choice, that's writing on the wall. And so what these new platforms are doing, like with BMC Helix and Automation Anywhere, is delivering that instant gratification, right? And when you think about it more and more of the new customers that are millennials, they don't know any other way. So for them, this is the only experience they will relate to, so again, this is not nice to have. It is the only way world will operate, right? >> We're going to turn back to the conversation that I had with Nayaki and Mihir shortly, but first, let's see what BMC's actually doing as they try to bring together service management and operations management, by watching a quick demo that they've prepared. (techno music) (music continues) >> Great demonstration of how these technologies are coming together in a real world sense. Now let's hear more of the conversation I had with Nayaki and Mihir about bringing together service management and operations management, but specifically focusing on how this class of technology is going to be extended, and made even more powerful for business as they think about not just IT, but other classes of automation. Let's hear what they had to say. >> So if you look at large organizations, they have vast amount of applications. Sometimes 400, 800, few thousand. And what we have been doing historically is using people as a human bridges between these applications, and we have operated that way for too long, and that's the world today. >> So humans are the interface, they're the system interfaces. >> Humans are the bridges between applications, and we often call it a swivel chair operations, that's an easiest way to describe it. So what Automation Anywhere does, is it offers this technology platform, robotic process automation, AI in an RTX platform, that integrates all of it together into a seamless automation bot that can go across, and with AI it can make intelligent choices. And so now we can take that, combined with the BMC Helix, and you have a seamless service platform that can deliver a superior experience. >> So we've got now the swivel chair users, now being software, which means that we can discover them more easily, we can monitor them more easily, and that feeds Helix. >> Absolutely, so you know in our consumer world, in our day to day life, we are used to a certain experience of how we consume data or consume experiences with our TVs and all the channels. That experience that we have in our day to day life is what people expect when they walk into the company, right, walk into the enterprise, which every IT organization is trying to figure out how do they get to that level of maturity. So this is what the combination of what we are doing with Helix and Automation Anywhere, brings that consumer grid experiences into an enterprise world. >> So Mihir, when we think about RPA, we're applying it in interesting and innovative ways, no question about it. But there are certain patterns of success, give us some visibility into what you are seeing leads to success, and then what's the future of RPA, how's that going to evolve over the next few years? >> Sure, so RPA has been deployed across virtually every industry and virtually every department. So there are many ways to get started and all of them are right. But often we find is that you can either start in a central organization wherein that organization is doing everything centrally. It is a great way to get started, but eventually we learn that the federated way's the best way to end. Where hundreds of offices all over the world, if you're especially a large organization, each business unit is doing it with IT providing governance and central security and policies, and actual bots running and being implemented all over the world. Eventually for a large-scale transformation, there is a common pattern we have seen among successful customers. >> And where do you think this pattern going to evolve, as enterprises gain more familiarity with it, innovate in new and interesting ways, and as Automation Anywhere and others advance the state of the art, where do you think it's going to end up? >> The rate it's going is, is I define it as an app store experience or a Google Play experience. So if you think about how we operate our mobile devices today, if you want something on your device, you will look for an app that does that. We are getting to a point where there is bot for everything, and a digital worker for everything, so if you need certain job done, you first go to a bot store, that is an Automation Anywhere website, look for a bot that does something, hire or download that bot, get the work done, and it comes prebuilt like many there are works with BMC Helix, and many others. So that is your first way you will look for getting your work done in a new bot economy, and if there's no bot available, then you look for other options. It will transform how we work and how we think of work. >> In many respects, it's the gig economy with perfect contractor, right? And it leads to some very interesting challenges, ultimately, when we start thinking about services. So Nayaki, based on what Mihir just talked about, where does digital services go as RPA joins other classes of users in creating those new experiences at new profit points and new value propositions? >> It becomes a compare of how you provide that service, can become a big competitive differentiation for financial institutions, for Telcos, which is a service industry, right, you provide that service, and like to Mihir's point, when the user hits that switch, they expect the light to come on, so if I'm an end user, the consumer, wanting a service from my Telco provider or from my financial institution, I expect that service to be instantaneous, and the highest accuracy, accuracy at which you provide is going to start driving competitive differentiation from financial institution to financial institution, Telco to Telco, and that's how I see companies differentiating and really surviving or thriving in the long term. >> Now let's hear from a really important partner, a CDO, someone who's thinking about how these technologies are going to be applied to the front lines of business change. Sanjay Srivastava is the CDO at Genpact, and he and I had a great conversation at BMC Immersion Days about what this means to digital business transformation. How will service management and operations management in combination accelerate and make more successful businesses' efforts to transform digitally. Let's hear what Sanjay had to say. >> So tell us a little bit about, what is a digital service outcome and why is it so important? >> Yeah, well I think the reality is that what technology is doing is it's disintermediating the ecosystem, so many of the industries are clients-operated, and they have to go back and reimagine their value proposition at the core of what they do with the use of new, innovative technologies, and it's that intersection of new capabilities, of new innovative business models that really use emerging technologies, but intersect them with their business models, with their business processes, and the requirements of their clients, and help them rethink, reimagine, and deliver their new value proposition. That's really what it's all about. >> So a digital service outcome would then be the things that the business must do and must do well, but ideally, with a different experience or with a different degree of flexibility and agility, or with a different cost profile, have I got that right? >> Correct. >> So when we think about that, what are some of the key elements of a digital service success? >> We like to think about three critical success factors in driving any digital transformation. The first one is the notion of experience, and what I mean by that is not user interface for a piece of software, but the journey of a customer, an employee, a provider, a partner, in engaging with you and your business model. When we think about journey mapping that scientifically, we think about design, thinking on the back of that, and we think about re-imagining what the new experience looks like. One of the largest things we've got in the industry is digital transformation on the back of cost take out of productivity or efficiency is insufficient drive and optimize the value that digital can bring. And using experience as the compass, as sort of the north star in that journey is a meaningful differentiator and driver of business benefit, so that's number one. I think the second area that's become increasingly apparent is the intersection of domain with digital. And the thinking there is that to materialize the benefit of digital in an enterprise, you have to intersect it with the specifics of that business, how users interact, what clients seek, how does business actually happen? We talk about artificial intelligence a lot, we do a lot of work in AI as an example, and the key thing about machine learning is goal orientation, and what is goal orientation? It's about understanding the specifics of the environments, you can actually orient the goal of the machine learning algorithm to deliver high accuracy results. And it's something that can often easily get overlooked, so indexing on the two halves of the whole, the yin and the yang, the piece around digital, and the innovative technologies, and being able to leverage and take advantage of them, but equally, be founded in domain, understand the environment, and use that knowledge to drive the right materialization of the end outcome. And that's the second critical success factor, I think, to get it right. I think the third one is the notion of how do you build a framework for innovation? You know, it's not the sort of thing where a large fortune company, Fortune 500 companies can necessarily experiment and it's a little bit of a go happy go lucky strategy, doesn't really work, you have to innovate at scale, you have to do it in a fundamental fashion, you have to do it as a critical success factor. And so one of the biggest things we focus on is how do you innovate at the edge? Innovation must be at the edge, this is where the rubber meets the road. But governance has to be at the core. >> Well let me build on that for a second, 'cause you said innovation's at the edge, so basically that means where the brand promise is being enacted for the customer, and that could be at an industrial automation setting or it could be in just making a recommendation, it could be any number of things, but it's where the value proposition is realized for the customer. >> Correct, that's exactly right, and that's where innovation must happen. So as a large corporation, you must be able, it's important to set up a framework that allows you to do innovation at the edge, otherwise it's not meaningful innovation if you, "Well, it's just a lot of busy work." And yet as you do that, and as you change your business model, as you bring new components to the equation, how do you drive governance, and it's increasingly becoming more important, you think about, we're going to be in a AI first world increasingly, more and more that's the reality of the world we're going in, and in that AI first world, I work here in Palo Alto, walk into my office, a couple of hundred people any given day. If tomorrow morning I walked in and 100 people didn't show up for work, I would know right away, because I can see them. Now fast forward to an environment where we have digital workers, we have automation bots, we have conversational AI Chatbots. And in that world, understanding which of my AI components are on, which ones are off, which ones showed up for work today, which ones fell sick, and really being able to understand that governance, and that's just the productivity piece of it. Then you think about data and security, AI changes complete dimensions on that. And you think about bias and explainability, it just become increasingly important, a notion of a digital ethics board, and thinking about ethics more pervasively. So I think that companies and clients we serve that do really well in digital transformation are those that key in on those three things, the notion of experience is the true compass for how you drive transformation. The ability to intermix domain and digital in a meaningfully intersecting fashion. And to be thoughtful, proactive, and get governance right up front in the journey to come. >> So let me again build on that a little bit, 'cause people are increasingly recognizing that we're not going to centralize with cloud, we're going to greater distribute. We're going to distribute data more, we're going to distribute function more, but you just added another dimension, that some of us have been thinking about for a long time, and that's this notion of distributing authorities so that an individual at the edge can make the decision based on the data and the resources that are available, with the appropriate set of authorities, and that has to be handled at a central, in a overall coherent governant way. So that leads to the next question. >> And just before you go there, I mean I think the best example of that, is we do that, most corporations do that really well in the financial scheme of things. Businesses at the edge make decisions on a day to day basis on pricing and relationships and so on and so forth, and yet there's a central other committee that looks through the financials and makes sure it meets the right requirements and has the right framework, and much in the same way, we're going to start seeing digital ethics committees that become part of these large corporations as they think about digitizing the business. >> Governance at the end of the day is how do you orchestrate multiple divergent claims against a common set of assets, and being able to do that is absolutely essential, and it leads to this notion of we've got these ideas of digital business, digital services and operations management. How are we going to weave them together utilizing some of these new technologies, new fabrics that are now possible to both achieve the outcomes we're talking about at scale and at speed? >> Yeah, well the technology capabilities are improving really well in that area, and so the good news is they're the set of tools that are now available that give you the ingredients, the components of the recipe that's required to make dinner, if you will. The work that needs to happen is actually how to orchestrate that, to figure out which components need to come in, and how do you pull together a vertical stack that has the right components to meet your needs today, and more importantly, to address the needs of the future, because this is changing like no other time in history. >> You want options with everything you do now, you want to make sure that you have a string of options for the future, and it's especially important here. >> That's right, that's exactly right. And the quick framework we've established there is sort of the three-legged stool of, how do you integrate quickly, how do you modularize your investments and then how do you govern them into one integrated whole, and those become really important. I'll give you examples, much of the work we do, we'll work with a consumer bank for instance, and they'll want to do a robotic process automation engagement, we'll run them for nine months, they'll get 1800 robots up and running. And the next question becomes, well now we have all this data that we didn't really have, because now we have an RPA running, how do I learn some machine learning insights from there, and so we then work with them to actually derive some insights and get these questions answered. And then the engagement changes to, well now that we have this pattern recognition then we understand more questions are going to be asked, how do I respond to those questions, A, automatically, and before they get asked, this notion of next best action. And so you think about that journey of a traditional client, the requirements change from robotics to machine learning to conversational AI to something else, and keeping that string of investments, that innovative sort of streak true, and yet being able to manage, govern, and protect the investments, that's the key role. >> We want to thank all the thought leaders that participated in preparing their thoughts for this digital community event, especially the folks at BMC Software. But now here's your opportunity to weigh in on how you see service management and operations management coming together in your business. How's it going to affect your IT organization, your IT organization's ability to serve your business, and your business overall? This is your opportunity to participate in a crowd chat where the community comes together and shares insights, asks each other questions, and engages with these thought leaders to try to get the answers that you need to move forward on the journey to bring together service management and operations management in your shop. Let's crowd chat!

and II just think about how data could be customer experience value propositions operations that improve profitability and strategic options for the business as it moves forward but that means openly either we're thinking about how we embed data more deeply into our operations that means we must also think about how we're going to protect that data so the business does not suffer because someone got a hold of our data or corrupted our data or that a system just failed and we needed to restore that data very quickly now what we want to be able to do is we want to do that in a way that's natural and looks a lot like a cloud because we want that cloud experience in our data protection as well so that's we're going to talk about with Klum you know today a lot of folks think in terms of moving all the data into the cloud we think increasingly we have to recognize a cloud is not a strategy for centralizing data but rather distributing data and being able to protect that data where it is utilizing a simple common cloud like experience it's becoming an increasingly central competitive need for a lot of digital enterprises the first conversation we had was with pooja Kumar who John is a CEO and co-founder of Kaleo let's hear a pooja I had to say about data value data services and Kumi Oh poo John welcome to the show thank you Peter nice to be here so give us the update in clue so comeö is a two year old company right we just recently launched out of stealth so so far you know we we came out with innovative offering which is a SAS solution to go and protect on premises you know VMware and BMC environments that's what we launched out of style two months ago we won our best of show when we came out of stealth in in VMware 2019 but ultimately we started with a vision about you know protecting data irrespective of where it resides so it was all about you know you know on-premises on cloud and other SAS services so one single service that protects data irrespective of where it resides so far we executed on on-premises VMware and BMC today what we are announcing for the first time is our protection to go and protect applications natively built on AWS so these are applications that are natively built on AWS that loomio as a service will protect irrespective of you know them running you know in one region or cross region cross accounts and a single service that will allow our customers to protect native AWS applications the other big announcement we are making is a new round of financing and that is testament to the interest in the space and the innovative nature of the platform that we have built so when we came out of stealth we announced we had raised two rounds of financing 51 million dollars in series a and Series B rounds of financing today what we are announcing is a Series C round of financing of 135 million dollars the largest I would say Series C financing for a SAS enterprise company especially a company that's a little over two years old Oh congratulations that's gonna buy a lot of new technology and a lot of customer engagement but what customers as I said up from what customers are really looking for is they're looking for tooling and methods and capabilities that allow them to treat their data differently talk a bit about the central importance of data and how it's driving decisions of Cluny oh yes so fundamentally you know when we built out the the data platform it was about going after the data protection as the first use case on the platform longer term the journey really is to go from a data protection company to a data management company and this is possible for the first time because you have the public cloud on your side if you truly built a platform for the cloud on the public cloud you have this distinct advantage of now taking the data that you're protecting and really leveraging it for other services that you can enable the enterprise for and this is exactly what enterprises are asking for especially as they you know you know make a transition from on-premises to the public cloud where they're powering on more and more applications in the public cloud and they really you know sometimes have no idea in terms of where the data is sitting and how they can take advantage of all these data sources that ultimately protecting well no idea where the data is sitting take advantage of these data sources presumably facilitate new classes of integration because that's how you generate value out of data that suggests that we're not just looking at protection as crucial and important as it is we're looking at new classes of services they're going to make it possible to alter the way you think about data management if I got that right and what are those new services yes it's it's a journey as I said right so starting with you know again data protection it's also about doing data protection across multiple clouds right so ultimately we are a platform even though we are announcing you know AWS you know application support today we've already done VMware and BMC as we go along you'll see us kind of doing this across multiple clouds so an application that's built on the cloud running across multiple clouds AWS ashore and GCP or whatever it might be you see as kind of doing data protection across in applications in multiple clouds and then it's about going and saying you know can we take advantage of the data that we are protecting and really power on adjacent use cases you know there could be security use cases because we know exactly what's changing when it's changing there could be infrastructure analytics use cases because people are running tens of thousands of instances and containers and VMs in the public cloud and if a problem happens nobody really knows what caused it and we have all the data and we can kind of you know index it in the backend analyze in the backend without the customer needing to lift a finger and really show them what happened in their environment that they didn't know about right so there's a lot of interesting use cases that get powered on because you have the ability to index all the data here you have the ability to essentially look at all the changes that are happening and really give that visibility to the end customer and all of this one-click and automating it without the customer needing to do much I will tell you this that we've talked to a number of customers of Cuneo and the fundamental choice the clue Meo choice was simplicity how are you going to sustain that even as you add these new classes of services that is the key right and that is about the foundation we have built at the end of the day right so if you look at all of our customers that have you know on boarded today it's really the experience we're in less than you know 15 minutes they can we start enjoying the power of the platform and the backend that we have built and the focus on design that we have is ultimately why we are able to do this with simplicity so so when we when we think about you know all the things we do in the back end there's obviously a lot of complexity in the back end because it is a complex platform but every time we ask ourselves the question that okay from a customer perspective how do we make sure that it is one click and easy for them so that focus and that attention to detail that we have behind the scenes to make sure that the customer ultimately should just consume the service and should not need to do anything more than what they absolutely need to do so that they can essentially focus on what adds value to their business takes a lot of technology a lot of dedication to make complex things really simple absolutely whoo John Kumar CEO and co-founder of coolio thanks very much for being on the cube Thank You bigger great conversation with poo John data value leading to data services now let's think a little bit more about how enterprises ultimately need to start thinking about how to manifest that in a cloud rich world Chad Kenney is the vice president and chief acknowledges of Cuneo and Chad and I had an opportunity to sit down and talk about some of the interesting approaches that are possible because of cloud and very importantly to talk about a new announcement that clue miios making as they expand their support of different cloud types let's see what Chad had to say the notion of data services has been around for a long time but it's being upended recast reformed as a consequence of what cloud can do but that also means that cloud is creating new ways of thinking about data services new opportunities to introduce and drive this powerful approach of thinking about digital businesses centralized assets and to have that conversation about what that means we've got Chad Kenny who's a VP and chief technologists of comeö with us today Chad welcome to the cube thanks so much for having me okay so let's start with that notion of data services and the role the clouds going to play Kumi always looked at this problem this challenge from the ground up what does that mean so if you look at the the cloud as a whole customers have gone through a significant journey we've seen you know that the first shadow IT kind of play out where people decided to go to the cloud IT was too slow it moved into kind of a cloud first movement where people realize the power of cloud services that then got them to understand a little bit of interesting things that played out one moving applications as they exist were not very efficient and so they needed to react attack certain applications second SAS was a core way of getting to the cloud in a very simplistic fashion without having to do much of whatsoever and so for applications that were not core competencies they realized they should go SACEM for anything that was a core competency they needed to really reaaargh attack to be able to take advantage of those you know very powerful cloud services and so when you look at it if people were to develop applications today cloud is the default that you'd go towards and so for us we had the luxury of building from the cloud up on these very powerful cloud services to enable a much more simple model for our customers to consume but even more so to be able to actually leverage the agility and elasticity of the cloud think about this for a quick second we can take facilities break them up expand them across many different compute resources within the cloud versus having to take kind of what you did on prim in a single server or multitudes of servers and try to plant that in the cloud from a customer's experience perspective it's vastly different you get a world where you don't think about how you manage the infrastructure how you manage the service you just consume it and the value that customers get out of that is not only getting their data there which is the on-ramp around our data protection mechanisms but also being able to leverage cloud native services on top of that data in the longer term as we have this one common global index and platform what we're super excited today to announce is that we're adding in AWS native capabilities to be able to date and protect that data in the public cloud and this is kind of the default place where most people go to from a cloud perspective to really get their applications up and running and take advantage a lot of those cloud native services well if you're gonna be cloud native and promise to customers as you're going to support their workloads you got to be obviously on AWS so congratulations on that but let's go back to this notion of user word powerful mm-hmm AWS is a mature platform GCPs coming along very rapidly asher is you know also very very good and there are others as well but sometimes enterprises discover that they have to make some trade-offs to get the simplicity they have to get less function to get the reliability they have to get rid of simplicity how does qu mio think through those trade-offs to deliver that simple that powerful that reliable platform for something as important as data protection and data services in general so we wanted to create an experience that was single click discover everything and be able to help people consume that service quickly and if you look at the problem that people are dealing with a customer's talked to us about this all the time is the power of the cloud resulted in hundreds if not thousands of accounts within AWS and now you get into a world where you're having to try to figure out how do I manage all of these for one discover all of it and consistently make sure that my data which as you've mentioned is incredibly important to businesses today as protect it and so having that one common view is incredibly important to start with and the simplicity of that is immensely powerful when you look at what we do as a business to make sure that that continues to occur is first we leverage cloud native services on the back which are complex and and and you know getting those things to run and orchestrate are things that we build on the back end on the front end we take the customer's view and looking at what is the most simple way of getting this experience to occur for both discovery as well as you know backup for recovery and even being able to search in a global fashion and so really taking their seats to figure out what would be the easiest way to both consume the service and then also be able to get value from it by running that service AWS has been around well AWS in many respects founded the cloud industry it's it's you know certainly Salesforce and the south side but AWS is that first company to make the promise that it was going to provide this very flexible very powerful very a a July infrastructure as a service and they've done an absolutely marvelous job about it and they've also advanced the state of your technology dramatically and in many respects are in the driver's seat what trade offs what limits does your new platform face as it goes to AWS or is it the same Coolio experience adding now all of the capabilities of AWS it's a great question because I think a lot of solutions out there today are different parts and pieces kind of clump together well we built is a platform that these new services just get instantly added next time you log into that service you'll see that that available to you and you can just go ahead and log in to your accounts and be able to discover directly and I think that the vow the power of SAS is really that not only have we made it immensely secure which is something that people think about quite a bit with having you know not only data in flight but data at rest encryption and and leveraging really the cloud capabilities of security but we've made it incredibly simple for them to be able to consume that easily literally not lift a finger to get anything done it's available for you when you log into that system and so having more and more data sources in one single pane of glass and being able to see all the accounts especially in AWS where you have quite a few of those accounts and to be able to apply policies in a consistent fashion to ensure that you're you know compliant within the environment for whatever business requirements that you have around data protection is immensely powerful to our customers Chad Denny Chief Technologist plumie oh thanks very much for being on the tube thank you great conversation Chad especially interested in hearing about how klum EO is being extended to include AWS services within its overall data protection approach and obviously into Data Services but let's take a little bit more into that Columbia was actually generated and prepared a short video that we could take a look at that goes a little bit more deeply into how this is all going to work enterprises are moving rapidly to the cloud embracing sass for simplified delivery of key services in this cloud centric world IT teams can focus on more strategic work accelerating digital transformation initiatives for when it comes to backup IT is stuck designing patching and capacity planning for on-premise systems snapshots alone for data protection in the public cloud is risky and there are hundreds of unprotected SAS applications in the typical enterprise the move to cloud should make backup simpler but it can quickly become exponentially worse it's time to rethink the backup experience what if there were no hardware software or virtual appliances to size configure manage or even buy it all and by adding Enterprise backup public cloud workloads are no longer exposed to accidental data deletion and ransomware and Clube o we deliver secure data backup and recovery without any of that complexity or risk we provide all of the critical functions of enterprise backup d dupe and scheduling user and key management and cataloging because we're built in the public cloud we can rapidly deliver new innovations and take advantage of inherent data security controls our mission is to protect your data wherever it's stored the clew mio authentic SAS backup experience scales on demand to manage and protect your data more easily and efficiently and without things like cloud bills or egress charges luenell gives you predictable costs monitoring global backup compliance is far simpler and the built-in always-on security of Clue mio means that your data is safe take advantage of the cloud for backup with no constraints clew mio authentic SAS for the enterprise great video as we think about moving forward in the future and what customers are trying to do we have to think more in terms of the native services that cloud can provide and how to fully exploit them to increase the aggregate flexible both within our enterprises but also based on what our supplies have to offer we had a great conversation with wounds Young who is the CTO and co-founder of Clue mio about just that let's hear it wound had to say everybody's talking about the cloud and what the cloud might be able to do for their business the challenges there are a limited number of people in the world who really understands what it means to build for the cloud utilizing the cloud it's a lot of approximations out there but not a lot of folks are deeply involved in actually doing it right we've got one here with us today woo Jung is the CTO and co-founder of Cluny Oh woo and welcome to the cube how they theny here so let's start with this issue of what it means to build for the cloud now loomio has made the decision to have everything fit into that as a service model what is that practically mean so from the engineering point of view building our SAS application is fundamentally different so the way that I'll go and say is that at Combe you know we actually don't build software and ship software what we actually do it will service and service is what we actually ship to our customers let me give you an example in the case of Kumu they say backups fail like software sometimes fails and we get that failures >> the difference in between chromeo and traditional solutions is that if something were to fail we are the one detecting that failure before our customers - not only that when something fails we actually know exactly why you fail therefore we can actually troubleshoot it and we can actually fix it and operate the service without the customer intervention so it's not about the bugs also or about the troubleshooting aspect but it's also about new features if you were to introduce our new features we can actually do this without having customers upgraded code we will actually do it ourselves so essentially it frees the customers from actually doing all these actions because we will do them on behalf of them at scale and I think that's the second thing I want to talk about quickly is that the ability to use the cloud to do many of the things that you're talking about at scale creates incredible ranges of options that customers have at their disposal so for example AWS customers have historically used things like snapshots to provide it a modicum of data protection to their AWS workloads but there are other new options that could be applied if the systems are built to supply them give us a sense of how kkumeul is looking at this question of no snapshots versus something else yeah so basically traditionally even on the on print side of the things you have something called the snapshots and you had your backups right and there they're fundamentally different but if you actually shift your gears and you look at what they Wis offers today they actually offers the ability for you to take snapshots but actually that's not a backup right and they're fundamentally different so let's talk about it a little bit more what it means to be snapshots and a backup right so let's say there's a bad actor and your account gets compromised like your AWS account gets compromised so then the bad actor has access not only to the EBS volumes but also to the EBS snapshots what that means is that that person can actually go ahead and delete the EBS volume as well as the EBS snapshots now if you had a backup let's say you actually take a backup of that EBS volume to Kumu that bad actor will have access to the EBS volumes however they won't be able to delete the backup that we actually have in Kumu so in the whole thing the idea of Kumi on is that you should be able to protect all of your assets that being either a non-prime or AWS by setting up a single policies and these are true backups and not just snapshots and that leads to the last question I have which is ultimately the ability to introduce these capabilities at scale creates a lot of new opportunities that customers can utilize to do a better job of building applications but also I presume managing how they use AWS because snapshots and other types of servers can expand dramatically which can increase your cost how is doing it better with things like native backup services improve a customer's ability to administer their AWS spend and accounts so great question so essentially if you look at the enterprise's today obviously they have multiple you know on-premise data centers and also a different card provide that they use like AWS and Azure and also a few SAS applications right so then the idea is for cumin is to create this single platform where all of these things can actually be backed up in a uniform way where you can actually manage all of them and then the other thing is all doing it in the cloud so if you think about it if you don't solve the poem fundamentally in the cloud there's things that you end up paying later on so let's take an example right moving bytes moving bytes in between one server to the other traditionally basically moving bytes from one rack to the other it was always free you never had to pay anything for that certainly in the data center all right but if you actually go to the public cloud you cannot say the same thing right basically moving by it across aw s recent regions is not free anymore moving data from AWS to the on premises that's not fair either so these are all the things that any you know car provider service provider like ours has to consider and actually solve so that the customers can only back it up into Kumu but then they actually can leverage different cloud providers you know in a seamless way without having to worry all of this costs associated with it so kkumeul we should be able to back it up but we should be able to also offer mobility in between either AWS back at VMware or VNC so if I can kind of summarize what you just said that you want to be able to provide to an account to an enterprise the ability to not have to worry about the back-end infrastructure from a technical and process standpoint but not also have to worry so much about the back-end infrastructure from a cost and financial standpoint that by providing a service and then administering how that service is optimally handled the customer doesn't have to think about some of those financial considerations of moving data around in the same way that they used to I got that right I absolutely yes basically multiple accounts multiple regions multiple providers it is extremely hard to manage what Cuneo does it will actually provide you a single pane of glass where you can actually manage them all but then if you actually think about just and manageability it's actually you can actually do that by just building a management layer on top of it but more importantly you and we need to have a single data you know repository for you for us to be able to provide a true mobility between them one is about managing but the other thing is about if you're done if you're done it the real the right way it provides you the ability to move them and it leverages the cloud power so that you don't have to worry about the cloud expenses but kkumeul internally is the one are actually optimizing all of this for our customers wound jeong CTO and co-founder of columbia thanks very much for being on the cube thank you thanks very much moon I want to thank chromeo for providing this important content about the increasingly important evolution of data protection and cloud now here's your opportunity to weigh in on this crucially important arena what do you think about this evolving relationship how do you foresee it operating in your enterprise what comments do you have what questions do you have of the thought leaders from clew mio and elsewhere that's what we're going to do now we're gonna go into the crowd chat and we're gonna hear from each other about this really important topic and what you foresee in your enterprise as your digital business transforms let's crouch at you [Music] [Music] [Music]

(upbeat techo music) >> Covering Kubecon and CloudNativeCon North America 2018 brought to you by RedHat, The Cloud Native Computing Foundation, and its ecosystem partners. (upbeat techno music) >> Okay welcome back everyone, we're live here in Seattle for KubeCon 2018, CloudNativeCon, I'm John Furrier with theCUBE coverage, three days. Our next guest is Chris Rosen who's the Program Director for Offering Management, for Kubernetes, IBM's Kubernetes Service. Chris, welcome to theCUBE thanks for joining us. >> Thank you very much, glad to be here. >> We always love covering IBM. Think is coming up this year. It's going to be in San Francisco. Want to get that out there because we're psyched it's in our backyard. It's always been in Vegas. We've been covering IBM's events for a long time. We've seen the evolution of Cloud, you know, Bluemix, SoftLayer all coming together. Kubernetes, actually the timing of Kubernetes couldn't have been better. >> Absolutely. >> With all the software investments in Bluemix, all the customers that you guys have, now with scale and choice with CNCF. Kind of a perfect storm for you guys, explain kind of what's going on, your role and how it's all kind of clicking together. >> Sure, so it is, you're exactly right it's an exciting time to be there. There's a lot of change. Everyone here at the conference, so excited there is so much new going on. About 2 1/2 years ago, IBM went all in on Kubernetes for our Cloud as well as for on-prem offerings to leverage and provide flexibility, portability, eliminating vendor lock-in, all those things that our customers asked us for and then adding capabilities on top of it. So, we are really excited to kind of grow and participate in the ecosystem. >> So, I hear a lot of people talk about Kubernetes. First of all, we love covering it, but the language around what is Kubernetes, they're even doing children's books, stories, trying to break it down. The rise of Kubernetes kind of has gone mainstream, but I hear things like the Kubernetes stack, the CNCF stack. I mean, it's not necessarily a stack per se. Could you break down, 'cause a lot of people are going to CNCF for a variety of other things. >> Right. >> With Kubernetes, at the core, describe how you talk to customers, how do you explain it. Unpack the positioning of Kubernetes at the core, and the CNCF offerings, or what do people call it? The stack, the CNCF stack? Or, how does this all break down? >> Yeah, so you're right. It's a very complex stack and that's where the complexity comes in that we're trying to eliminate for our customers is to simplify managing that stack. So, at the top of the stack, of course we've got Kubernetes for the orchestration layer. Below that, we've got the engine. We're using containerd now but we also have Prometheus, Fluentd, Calico, it's a very complex stack. And, when you think about managing that and a new version comes out from Kubernetes, how does that effect anything else in that stack? >> Chris, wonder if you can explain a little bit what IBM's doing here because some people I've heard, they've said, ah, there's like over 70 different you know, platforms with Kubernetes, oh they're all trying to sell me a Kubernetes distribution. >> Right. >> I don't believe that's the case. So, maybe you just explain what bakes into your products, what IBM bakes into the community. >> Right. >> And your role, yeah. >> Well, you're exactly right. So we're not forking and doing anything IBM-esk with Kubernetes. >> Right We have core maintainers that live out there. That's their job, is to focus upstream. We think that's very important to be agnostic and to participate in these communities. Now, what we do is, we build our solutions on top of these open source projects, adding value, simplifying the management of those solutions. So, you think about the CNCF conformance testing, IBM participates. We typically are the first public cloud to add support for a new version of Kubernetes. So we're really excited to do that, and the only way we can do that is by actively participating in the community. >> The upstream dynamic is important. Just talk about that for a second because this is, I think why one of the reasons it's been so successful is the upstream contribution is not your IBM perspective, it's just pure contribution for the benefit of the community then downstream, you guys are productizing that piece. >> Right. >> That is kind of, that is the purpose of open source. >> Exactly, exactly, and you hear time and time again at these conferences that the power of the community is so much greater than one individual company. So, let's work together as a community, build that solid foundation at the open source level and then IBM's going to add things that we think are differentiating and unique to our offering. >> What's the number one end-user conversation, problem that's being solved with the evolution of CNCF and Kubernetes at the core? Obviously, choice is one, but when specifically as you talk to customers, what is the big nead? What's the conversations like? Can you share some input into, insight into the customer equation? >> Probably the biggest request is around security, and that's a couple of fronts. One, maybe this is my first step into public cloud, so how do I ensure, in a multi-tenant world, that I am secure in isolation and all of those things. But then also, thinking about maybe I'm just starting with containers and microservices. So, this is a completely different mental paradigm in how I'm developing code, running code, and to explain to them how IBM is helping simplify that security aspect along that entire journey. >> So talk about the auto-scaling security piece, because, again, the touch points, it's interesting about Cloud, the entry point is multiple avenues for a customer could be workload, portability. It could be for a native application in the Cloud. Where's the scale come in? How do you guys see the scale picture developing? >> Right, so again, scaling comes kind of two factors. One, Pod Autoscaling from Kubernetes. So, you can define, let your application scale out when it needs to, but then there is also the Infrastructure side. So, I need to be able to set parameters to scale up when I need to and then scale back down to kind of meet my requirements as well as managing my cost. >> Well IBM Think's coming up on February 15th, just a plug for theCUBE. We'll be there, obviously register but IBM Think is a big conference. How much of Kubernetes will be at the center of IBM Think? >> Kubernetes will be a huge part at Think. We encourage everyone listening to come sign up and join us. There will be a range from hands-on for your Developer focus or your Operators. We'll have much larger business benefits for our C-level participants. So, a lot of activities, a lot of fun, a lot to learn at IBM Think 2019 in San Francisco. >> What's the biggest story here at KubeCon, CloudNative conference for the folks not here, or watching, or maybe are wait-listed in the lobby-con (Chris laughs) that's happening in Seattle? What's the biggest story? >> The biggest story is the vibrant ecosystem. When you look at the amount of people that are here, the chatter, the booths are packed, the sessions are packed, the keynotes are packed. It's great, everyone wants to share a story, learn from each other. It's a fantastic community to be a part of. >> I got to ask you the programmability piece, because, one of the things that people look for is virtual private networks, they're using VPNing, they want to take VPNs to the next level, SD-WAN, super-hot trend that's kicking back up, people want to program networks. >> Right. >> They don't want to have to actually provision networks anymore. this is DevOps but now it's also the network layer. Storage and compute looking good? >> Right. >> Network is evolving, how do you guys see that picture? Can you comment on that, it's a hot area. I just want to get your perspective. >> Yeah, definitely evolving just like the rest of the space. So, we are excited to work with various vendors here. IBM has our own point of view of what virtual private cloud means supporting, bring your own IP, private end-points, private cluster, so that way, if I only want connectivity inside my backbone network, I can configure my networks that way, creating a VPN tunnel back to my resources on-prem, and just have it completely isolated from the rest of the world. >> You see a lot of on-premises activity, Azure stack, Amazon announces this Outposts Cloud Sys supposed to be about a year away, and their whole message is latency. >> Right. >> Workloads need certain things, some of them need low-latency. >> Right. >> Some need more security. Just a, is that just a course of business now, that customers have to have these diverse sets of needs met? >> Absolutely, so IBM has two offerings, IBM Cloud Private for on-prem with multi-cloud manager that's really focused at managing in that hybrid or multi-cloud world. How do we simplify resources that are running on-prem, IBM Cloud, other Clouds, and how do we do so efficiently? So, we definitely see a lot of hybrid, hybrid architectures, whether that's on-prem to IBM Cloud, IBM Cloud to other Clouds, and latency really becomes a minimal factor. >> And what's your to do list on Kubernetes as you look at this event, obviously continuing to grow, the international piece is pretty compelling as well, growth in China, we're seeing that. What's your plans for IBM Kubernetes offering, what's the roadmap look like, what can you share some insight into what's next for you guys? >> Absolutely, so we're definitely focused on security, continues to be paramount, even though we think we are a very secure offering already, but continuing to expand on that. The private endpoints that I mentioned, the private connectivity, isolating network traffic is a huge piece of it, staying compliant and up to date with Kubernetes versions as they come out, making sure that they're scalable, performant, upgradeable, and then making those available to our users. >> IBM continuing to transform obviously the big news we saw with the RedHat acquisition, you know, obviously you've been in the Cloud for a while, everyone knows that with Bluemix, maybe not get to know as much work that went into Bluemix for instance, a lot of great stuff. You guys have built, you know, the Developer side within Cloud. IBM Think is February 15th, it's going to be in San Francisco. theCUBE will be there. Check these guys out. They're going to have a lot of workshops we're excited to see how the evolution of IBM and IBM Cloud continues. Chris coming on theCUBE, appreciate it. >> Thank you very much. >> theCUBE coverage, I'm John Furrier, Stu Miniman, stay with us for more coverage, here in Seattle, after this short break. (upbeat techno music)

>> From the Aria Resort in Las Vegas, it's theCUBE. Covering AWS Marketplace. Brought to you by Amazon Web Services. >> Hey welcome back everybody, Jeff Frick here with theCUBE, we're at AWS re:Invent in Las Vegas, I don't know, 50,000, 60,000. I can't wait 'til the number comes in, there's a lot of people at this event. Been coming for years, we actually have nine days of coverage here spread out over three sets in four different locations, but we're kickin' it off tonight, at the AWS Marketplace and Service Catalog event here at the Aria. Come on by there's no lines over here. I'm sure there's giant lines over at the Sands. We're excited to see an old friend and make a new friend, and talk about the service catalogs from some of the experts and Dave Wright, Chief Innovation Officer from ServiceNow, has been on many, many times. >> I have. >> Dave great to see you. >> No, good to be here. >> And our new friend MaSonya Scott, she's Senior Business Development Manager, at AWS Service Catalog. >> Hi, how are you? >> Welcome. >> Thank you. >> So there's a lot of talk about service catalog. We know about the ServiceNow Service Catalog. We got the AWS Service Catalog. But now you guys have brought these two things together. >> Yes. >> Why did you bring it together? How did it happen? How did we get here today? >> So, AWS, 95% of our features are based on what customer feedback. And so we were listening to our customers tell us that, hey it's your innovation in AWS Service Catalog, where you provide the governance, the guardrails, the launch constraints is great but we already have a service catalog with the ideas and tools such as ServiceNow and how can federate that ingest the details and information into ServiceNow so that we can do it in one place? So our developers don't have to swivel chair between two different systems. >> Right. >> So we listened to that feedback. Got requirements, started a proof of concept, and then we built on it and we're now on our third iteration. >> And Dave, what were you hearing your side of the chair? >> So we were getting, customers were coming to us saying they wanted a similar experience they were getting using regular service catalog. So they wanted a unified experience. They wanted the ability to have governance and control over what was happening. But most importantly they wanted us to integrate because they'd say, hey, you two are both strategic platforms for us. We don't want to go to the last mile after to aid the integration so you guys need to work together and sort it out. So, it was very much customer driven. It was customers that were saying, We want you guys to work together more closely. >> I love it. I just love the customer-centric nature because we hear it over and over again. >> Yes. >> And this is kind of a great example of a real instance. And you didn't really care, per se, whose was kind of on top. What are the logging into initially. >> Right. >> You just wanted to get the integration done. >> Yes. >> And it sounds like today, right now it's a ServiceNow log in and then it integrates with the AWS Service catalog-- >> Yes. >> Underneath. >> Right. So for the AWS Service Catalog we state the source of truth for all the resources, the products and the portfolios. And then we sync to ServiceNow Service Catalog through their scheduled job process and we expose products that the ServiceNow administrator wants their end-users to see. So they can order an iPhone and now they can order a web server. >> And where's the identity? Is that in the ServiceNow platform now in terms the rights and access that an individual person has inside of your catalog. >> So we have a scoped app in ServiceNow where you correlate the identities in AWS to a role in ServiceNow. >> Okay. >> So that's that. And then the best thing about the app is that the ServiceNow end users doesn't have direct access to the AWS console. >> Right. They just order what is a compliant, secure product product that they need to have. And then even in the AWS console, the connection only gives the end user role that's assumed access to the AWS Service Catalog. So not even direct resources to EC2 or S3. And so what that enables is that segregation of duty. >> Right. >> And so we put the permissions on the launch constraints and then they deplore products and then you can give the evidence in an audit to what you've provisioned. >> Okay. And then where is this in the life cycle? You said, I think we're kind of past POCs getting into production? >> Yeah our customers are starting to move to production, doing POCs, giving us feedback and as they give us more feedback, we're creating more releases. We've launched our third iteration of features last Monday, the 19th and what we did was we integrated not only just AWS Service Catalog but the ability through AWS Systems Manager to do SSM actions so if you provision a web server, now you can start, stop, reboot it. And so, then once you do that we create a change in ServiceNow's IT change management. So we're moving more from provisioning as well as into operational actions as well. >> So that's what was great for us was if you've got that point of initiation where you know something's happening, we can then update the CMDB in real time, we can start looking at software asset management so we can see what's deployed. And then we've also found this great use cases where we can look at how we actually map the service to then be able to use Amazon's cloud migration products to be able to speed up migrations as well. >> Yes. Yes, and so customers are not only just provisioning storage or EC2's but anything from a cloud formation template workspace, an Amazon workplace. >> Right. >> We can also send those requests through ServiceNow we got a lot of feedback on that. >> Right. >> We have sessions and builder projects today at re:Invent that are showing how that works. >> So it begs the question obviously down the road, you know will kind of the priority switch from the customer perspective? You know, will ServiceNow be integrated in through the marketplace of the service catalog and people access it through that way? >> I think there's no reason why it couldn't be at some point. The only challenge we have at the moment is obviously people using the service catalog to provision all kinds of things as well as AWS components >> Right, right. >> But if you're a core AWS shopper and that's what you're using everything for there's no reason why you couldn't flip that around. >> Right, I was just thinking you know what screen are you on all day, right? You know everybody wants your attention. They want that screen and if that's your work screen, that's your work screen so know you're opening this up, really adds a whole lot of power to the ServiceNow work screen that wasn't there before. >> We've always focused on can it change what the employee experience is like to just try and give them, ironically an Amazon-like experience. >> Yeah. (laughs) >> Before we said it's easy for me to order stuff in the real world for me to just get something from Amazon why couldn't I have exactly that same experience when I wanted to order any piece of IT equipment whether it be physical, virtual, peripherals, whatever. So that's why we're trying to change the experience but it's funny that it's come through that full circle of them going, oh, it would be good if it was like that, and then we end up working with these guys anyway. >> So did you get a cake? (laughing) >> Did I get a cake? I've seen many cakes in my career. But no, I think you need to send me a cake. >> We need to do it, get a go live cake. >> I know, I know >> Yeah you got to get a Go Live cake once you get that first one up and official and ready to roll. >> We ought to do that, take a picture. >> See your product manager. >> It's a huge tradition. It's one of the coolest things of the ServiceNow culture I have to say. >> Yes, yes, yes. >> All right. So any final words on this partnership beyond just continuing to make the improvements getting closer to production and build more functionality? Anything you want to highlight as you turn the calendar on 2018 and 2019's just around the corner? >> So we're looking to get feedback on not just provisioning but going through other management tool services and trying to see what the customers are looking for. So that's one of those key features is just building bigger not just AWS Service Catalog but a connector between the two platforms so that we can continue to create that synergy. >> Excellent. All right, well thanks for taking a few minutes of your day and we'll see you I think in May. (laughing) Is usually when we see you. And we see AWS, I think we had six shows this year. You guys just keep rolling. >> Yes. >> So thanks for taking a few minutes and have a terrific show. >> No great to be here. >> Thank you. >> All right, she's MaSonya, he's Dave and I'm Jeff, you're watching theCUBE. It's the AWS Marketplace Service Catalog Enterprise at the Aria, come on by. Thanks for watching. (upbeat music)

>> Announcer: Live, from Atlanta, Georgia it's theCUBE covering IFS World Conference 2018. Brought to you by IFS. (upbeat pop music) >> Rebecca: Welcome back to theCUBE's live coverage of IFS World Conference 2018 here in Atlanta, Georgia, I'm your host Rebecca Knight, along with my co-host Jeff Frick. What you're seeing right now are the hordes of people here at IFS World, and we are here to talk to our two guests Sumair Dutta, who is an analyst at the Service Council, and Mark Brewer, who's the Global Industry Director of Service at IFS. Thanks so much for joining us! >> Well thanks for having us. >> Thanks for having us, yeah absolutely. >> Jeff: How did we draw you away from the cappuccino machine of there? The-- >> I know, I know. >> Jeff: The baristas are workin' hard. >> Rebecca: It's very buzzy, it's very exciting. So talk to us a little bit about FSM six which is, which is going to be released at the end of this year. What's new, what's exciting? Right, so IFS field service management six, you know I think the first point to make is that we already have what is recognized as the most complete solution in field service management, so this release was really focused on improving the user experience. It's a common theme throughout this conference, I think you'll hear. So how do, not only our customers, but our customers customers, their partners, all stakeholders get the most intuitive user experience out of this solution, to derive the value that encapsulated in there. I think another thing that goes along with that is, we're moving to a zero customization goal. That is to say, you'll still have, you know, ultra levels of configurability in this product from a workflow perspective, from a user interface perspective, from a business rule perspective. But instead of doing that through customization, you're doing that through configuration. Which means, you can sit on an evergreen model, you're not restricted on your upgrades. You can start on the latest and greatest, in other words, our customers are able to encapsulate an excellent experience and their business rules all within a standard offering. >> Field service management you don't really necessarily think of as inside the ERP suite, right? Kind of a hang off, I dunno what the right term is. So how does that make this offering different within all the offerings that IFS has? >> Mark: Yeah, it's a great question. So one of the uniques about the IFS FSM solution, is that it is complimentary to whatever back-end systems you already have, so let's say you have something from one of our peers in the business, so you're not runnin' IFS apps for your ERP, you're runnin' somethin' else, that doesn't matter. You can still derive best in class field service management from the FSM solution, it integrates with pretty much any other back-end. So if you truly are a service focused operation of which many companies, you know, 70% of their revenue derive from service, you can get that, if you like best-in-class service capability, without throwin' anythin' out that you're already got. And that's why FSM is somewhat different to the majority of other portfolio applications at IFS. >> So talk a little bit about how closely you work with your customers, I mean that is a real point of pride for IFS is how customer focused, how customer centered you are. So describe your process, in how you collaborate with customers, in terms of what they want the end product to look like. >> Really glad you asked that question, and it's incredibly timely for this event because, when the event closes on Thursday, we actually have a day dedicated to what we call our customer advisory council. So we have 12 of our strategic field service customers gathering in Atlanta to effectively help plan the roadmap. So we're not talkin' about tomorrows feature functions, we're talkin' about a three to five year strategy from their business. So this is not, if you like, the users asking for features, it's actually C-level, and executive management level from our customers that are actually giving us insights into where their taking their service operation in the future. Not really a technology discussion, but a business strategy discussion. We can then take that away, that involves our R&D organization as well, by the way, we take that away, we augment that with our own roadmap goals, technology that is obviously, you know, within the field service space already, AI, AR, IOT, and so forth, and, you know, bringin' those three things together, that's how we ensure that we are building applications, not just for today, but for what's next, as per the conference tag-line, you know? So heavily customer centric. Just on Friday, all those customers in the room, tellin' us where they want to go. >> Sumair, what are you seeing as sort of trends in this field service market, and how are you seeing IFS responding to those? >> Yeah that's a great question. You know field service as a whole wasn't something that was talked about previously, and we see so much more interest in the field of field service and the overall equation of aftermarket service and support. You know, previously that was a bi-product of being a business, we have a product, we need to support it, so we need to maybe throw some resources, but let's do that at the lowest cost. Now you'll see more and more companies talk about you know, service as a profit center, that we need to make money as a service. And this is primarily being driven by three major themes, three major disruptors: you have technology of course, and all of the new tools, AR, AI, augmented reality, artificial intelligence, IOT, and that's driving companies to figure out what is there story in each one of those solutions? We're not all there, no one's solved the problem, but we're all trying to figure out where do those fit into the way we deliver service, and the way our customers consume service? Then you have in field service specifically, workforce related challenges, disruptions. In our research we find about 70% of companies are going to face a talent shortage in the next five to 10 years. And this is research that's done across manufacturing and other disciplines as well. So your capacity in the sense of the number of workers you have is not going up, and you have to bring in new workers, you have to attract new talent, but then you have that outgoing flow of workforce and knowledge that's leaving your organization. So you're trying to balance all of those needs. And then eventually customers are demanding more, and you might say what does that mean you know, in an industrial setting? Well we're all consumers in some form, and we have consumer experiences, you know, the Amazons of the world, the Ubers of the world, who give us an element of convenience and access to information. And that is beginning to translate more and more so into the B to B service environment. So as a service organization you're balancing: customer needs which are rising, you've got a talent pool or a labor pool that's probably declining, and all of these disruptive technologies that you have to incorporate into your business, and so as a company as IFS that has been very customer centric, IFS has done a lot around field service management to improve some of the workforce capacity challenges with their solutions around FSM, they are taking a greater stake in some of the customer engagement solutions, with the acquisitions of MPL systems, and potentially future acquisitions down the road, and then from a technology point of view, I like IFS' approach, they've been, they're not quick to jump to the end, to say, you know, here's our AI solution per se, but they're essentially trying to establish those steps for companies to get from point A to point B to point C, to say here's where analytics can help you, here's where mobility can help you, it's a little bit more of a pragmatic approach as opposed to a marketing first approach, and so IFS has done a really good job in terms of the workforce elements, the technology elements, and now moreso on the customer engagements side as well. >> You know what really strikes me, as we're having this conversation is: the way that customers engage with companies has changed dramatically, right? Certainly on a consumer side, and a business side, so much now the engagement is via an electronic interface. And I can see where the increasing importance of the field sales person in that truck is actually the face of the company, and probably quite often the only person that the customer actually engages. So that's a really different type of service level requirement not to meet an SLA delivery because of a contractual obligation, but in terms of actually being the face in the engagement, in the touch point of your company, with an actual customer. It's probably happening more and more in the field as a percentage of the total than it ever has. >> That's a great observation, you know we actually, many of our customers today regard that field engineer as the trusted advisor of the customer, he's the trusted advisor, you know. They don't see him as a salesperson, they see him as their, you know confidant, their trusted advisor. He's not only going to be the hero to fix their problem, he's actually going to tell them how they can prevent such a problem in the future, and he's also going to try and offer them, you know, I can fix this problem today, but actually if you bought into a wider service contract, you wouldn't need to care about how many visits, and how many parts you consume, it will actually cover you completely with a gold contract. He upsells and cross-sells at the same time as becoming the hero, so, perfect observation. >> So are they actively, you know, kind of retraining those folks to really start to think of themselves more as a kind of a customer engagement representative versus just a field service person? You see that in the real world? >> Most definitely, most definitely. Because more and more, we've got an educated buyer, the buyer's savvy, you know, he's done a lot of his own work before actually committing to a purchase these days, much the same in this space, so, you know, rather than be sold to, they want to be advised. And it's a different experience again, to use that phrase, from a technology perspective, you know, that mobile application that used to be about, here's your jobs, go visit these locations, it actually now is when you're there, maybe you should talk about this particular offering, we have a promotion on that particular unit, these customer uses X, Y, and Z features, talk to them about another incremental gain from that, so the intelligence has moved from just fix the problem, to actually become their trusted advisor, like I said. >> And I would add to that, it's not just about training, it's about hiring, so it's the profile of who you bring in as a field service technician, you're not only bringing someone who's technically savvy, or mechanically savvy, or digitally savvy, you're bringing someone who can communicate with customers, someone who can work as a team, so internally, your internal customers and then your external customers who can communicate, who can provide solutions, who can provide guidance. We've done some studies of field service engineers, and they say, you know, our work is 10% fixing things, and 90% of solving customer problems. So it's having that empathy, having that knowledge of what the customer's going through, and potentially what the customer might go through in the future and being able to preempt some of that with advice, potentially selling, potentially guiding your customers with information, and so it is a much more wholistic experience because they are the face of the organization. >> And as a consequence, expectations have raised in the customer base. They want more than just a fix. >> It's so wild right, this whole, this conversation about machines taking our jobs, and yet everyone that we talk to, there's not enough people to do the jobs, and so it just: A reinforces that we need the help, but B, more importantly, that it's the combination of a machine helping do the scheduling, helping decide where to go, helping to know what the opportunity is for that particular engagement with the person who's empathetic, has history with the company, history with the problems. That actually is a much better solution than either one, or the other. >> Yeah, to talk about artificial intelligence again, you know, we see, there's a couple of things: one it allows scaling of the human, if you will, not replacement of the human, we won't have sufficient, no skilled employees, secondly I think it all bends the human experience, because, I'll give you an example. We got to customer that's in, like the, breakdown recovery service for vehicles, in the US in fact, today a call center agent in their contact center they'll take a call, but the virtual assistant is actually listening to the conversation, kind of like a Siri in the background, and they pick up on phrases like tow-truck, automatically pops up on the agents screen, the nearest tow truck is 10 miles away, it's Steve, you know, in this location to the customer. They'll pick up on emergency, we can get there with a closer engineer, we can pull him off another job. That's actually going in the ear of the agent, and it's going on the screen of the agent, they are providin' a level of service, you know, that the customer is pretty, you know, impressed by, as a consequence. That's a great example of: it's not just the human experience, or the AI experience, it's a combined experience. >> It's the human empathy along with the automated knowledge that you're combining there, that's great. Well Mark and, thank you so much for joining us Mark and Sumair, I really appreciate it, it's been a great conversation. >> Sumair: Well thank you very much. >> Mark: Thank you, thanks. >> Jeff: Thanks! >> I'm Rebecca Knight for Jeff Frick, we'll have more from IFS World Conference just after this. (gentle dance beat)