(bright upbeat music) >> Hey, friends. Welcome back to theCUBE's Live coverage of AWS re:Invent 2022 in Sin City. We are so excited to be here with tens of thousands of people. This is our third day of coverage, really the second full day of the show, but we started Monday night. You're going to get wall-to-wall coverage on theCUBE. You probably know that because you've been watching. I'm Lisa Martin and I'm here with Paul Gill. Paul, this is great. We have had such great conversations. We've been talking a lot about data. Every company is a data company, has to be a data company. We've been talking about developers, the developer experience, and how that's so influential in business decisions for businesses in every industry. >> And it's a key element of what's going on here on the floor at re:Invent is developers, the theme of developers just permeates the show. Lots and lots of boots here devoted to DevOps and Agile approaches. And certainly that is one of the things that the Cloud enables is your team to rethink the way they develop software, and that's what we're going to talk about next. >> That is what we're going to talk about next. We have two guests from Split. split.io is the URL if you want to check it out. Chris Demars joins us Developer advocate. Chris, great to have you and PaaS, VP of Engineering guys thank you so much for joining us on the program. >> Thank you for having us. >> Thank you for having us. >> Talk to us Pierre, we'll start with you. For the audience that might not know Split what does the company do? What's the value in it for customers? What are you all about? >> Sure. So in very simple terms, for those who are familiar, we do feature flags, feature management and experimentation. And essentially that two essential feature of the Agile transformation as you were mentioning and elements that really helps getting as much art we can from the team in term of productivity and in term of impact. And we basically help with those elements. And so that's a very short... >> 'Excellent, very nice. Chris, you were saying before we went live you do a lot of speaking at conferences, you're often in front of large audiences. As the developer advocate, what are some of the key requirements you're hearing from the developer community that organizations need to be encompassing? >> I think community is key. Like community is at the forefront of developer advocacy and developer relations. Like you want to go where the developers are and developers want to hear those stories in those personalized pieces of the puzzle. And when you're able to talk about modern Web and software technology and loop in product with that and still keep talking about those things and bring that to them, like that is on top of the list when it comes to developer advocacy and being embedded within the developer community. >> Lisa: Yeah. >> Tell us about feature flags, because I would assume that for our viewers who are not developers, who are not familiar with Agile technologies, the Agile approaches that might be, may be a new term, what are feature flags? How do you use them? >> Sure, I can start with that. So feature flag is a tool that you embed in your code that allows you to control the activation of your code essentially. And that's allows you to really validate things in a much better and solve way and also attach measurement to it. So, when you're writing your new feature, you just put essentially an if statement around it, if my feature flag is on, then I actually do all those things with soft, then I don't do any of those things and then within our platform, then you can control the activation. Do you want to turn it on for yourself just to try it out? Do you want your QA team to start validating it? Do you want 5% of your users 10%? And start seeing how they interacting with the product. That's what feature flag is. >> It's an amazing piece of any part of the stack, right? 'Cause I'm a Web accessibility and an UI specialist and being able to control the UI with a feature flag and being able to turn on and off those features based on percentage, locale, all of those things. It's very, very powerful. >> What are some of the scenarios which you would use feature flags? You have been testing? >> Yeah, yeah. We actually, you can imagine we use it for pretty much everything. So, as Chris was saying, in the front-end, everything you want to change, you basically can validate and attach measurements. So you can do AB testing, so you can see the impact, you can see if there is a change in performance. We use it also for a lot of backend services and changes and a lot of even infrastructure changes where we can control the traffic and where it goes. So we can validate that things are operating the way that they should before we fully done the market I think. >> 'It can be as small as, you know having a checkout button here and then writing an AB test and running an experiment and moving that checkout button somewhere else because then you can get conversion rates and see which one performed better to a certain amount of people and whatever performed better, that's the feature you would go with. >> Chris, talk about the value of the impact in feature flags for the developer from a developer experience perspective, a productivity perspective. >> So I think that having that feature and being able to write that UI, let's say that you have a checkout button, right? And there's specific content there's verbiage on that checkout button. And then let's say that another team within the organization wants to change that because the conversion is different. You can make those changes, still have it in production and then have it tested. So you don't have to cut specific branches or like test URLs to give to QA, you can do all of that behind that flag. And then once everything is good to go, push it out there and then based on those metrics and that data, see which one performs better and then that's the one that you would go with. >> One of the things with feature flag and it goes to like our main theme of 'What a Release, What a Relief' is that it gives autonomy to the teams and to the developers, enable them to move independently from others. So the deployment can go but their code is not activated until they decide to. And so, they are not impeding anybody else. It makes releases a lot safer, a lot simpler and it gives a lot more speed to everybody because when you do releases with five teams, 10 teams, pushing the code at the same time, you have such a high-risk of breaking something that it's you know... So it's a huge effort and it requires a lot of attention from a lot of people. If anything happens, all those teams needs to investigate. When you decouple all those things, the deployments are essentially not doing anything per se until every individual team activate those things independently. So if anything goes wrong, only them are affected and they don't have to depend on anybody else to get their thing out. So it really helps them making their life a lot safer and gives them a lot more speed because they have autonomy. >> So, why come to re:Invent? What do you get with this audience that you don't get elsewhere? >> Why to re:Invent? I think like re:Invent in the Cloud and AWS is a lot about getting speed to companies to build better product and faster. And essentially like the tool we provide and the technology and the platform we provide is really at the heart of that in itself. And so that's why we feel we have really great conversation with all the people on the floor. >> 'the people who have the right mindset for adopting... >> For me, it's very much community and networking, I love developer community and just community in general is my lifeblood. That's why I travel so much and I talk about these things and I'm with people and if it's not about the products, the story and the story is what gets people. That's why I love being here and being with my team and it's amazing. >> And what is that story? If you had an elevator pitch to give, what would you tell me? >> Hoo, if you were in a late release or deploy at night. I've been there, I'm sure you've been there, it doesn't matter what you're doing. We don't want be up until two, three in the morning doing those things, right? Our product helps alleviate those stresses. And you talking about accessibility, what I do, you know, a big piece of that are hidden impairments like anxiety will stress and anxiety go hand in hand and you want to alleviate that all across the board for everybody involved. >> As you see organizations shift Agile technologies and to parallel development and continuous release cycles, what are some of the biggest barriers they encounter in changing that mindset? >> Ooh, what do you think? >> It depends on where they are in the organization. The Agile transformation is a journey and it's also a change of mindset, it's a change of process. So depending on where they are then they might have some areas where they need a little bit more effort in those directions. What we see is that feature flag just the control of the layout. It's usually something that's fairly easily adopted. Thinking about measurement and attaching measurement to it is often something that requires a little bit more thinking. Like engineers are not really used to thinking about AB testing. It feels like more of a product management thing but AB testing is important also for performance informations like errors and all those things. There is a lot of risk management to be done. We do that through monitoring with APMs, but with feature flag and with Split, you can do that at a feature level and it really gives a great insight. And that's usually something that takes a little bit more digestion from the developers to really get their mind around it and get to it. But there's a lot of value to it. >> I'm looking at the split I/O website and I like the tagline shorten time from code to customer. As customers in any industry, as consumers, we have this expectation that we can get whatever we want anytime 24 by 7 and it's going to be a relevant experience. So it sounds to me like from a speed perspective, there's a lot of business impact that Split can help organizations make from getting releases faster, getting cut faster time-to-market, delivering what customers expect because we all expect real-time these days. Nobody wants to wait. >> Yeah, that's right. Yeah, I think that has to do with the going back to the decoupling of things that, you know... Not having to go through so many teams to have it tested and getting away from all the meetings about meetings to review the metrics, right? We all love meetings about meetings. >> No. (laughs loudly) >> Right, exactly, exactly. So being able to take that away and being able to push all of that stuff into production, getting it tested while it's in production and then being able to turn those features on, it's already there without having to do another deployment. And I think, like that's really powerful to me at least. >> Does your solution have value at the security level as well? >> Yes. So that's one of the particularity on the way we do things is like the way you control the feature flag, you have kind of two ways of doing it. Either the piece of code, the SDKs that we provide, the library we provide, you that you put in your code could come back to our platform and check. The way we do it is we send the rules back to the SDK so the whole evaluation is local. The evaluation is extremely fast and it's very secure because it's all happening within your environment. You never have to share any information, no PI whatsoever, contrary it to some of the other tools that you might find on the market. >> So the theme of the booth is 'What a Release, What a Relief'. What are some of the things that you're hearing as you're engaging folks on the show floor this week? >> Oh, what is Aura Photography and can I take a picture of. (everyone laughs loudly) I think just a lot of the stresses of... They're like the release cycle and you know, having to go through so many teams. I feel like that's a common theme that I've heard of. >> Yeah, we see a number of teams organization that still have like really big deployments with like a lot of teams basically coming together, pushing the code together, and there's a lot of pain in it. It's like, it's a huge effort by huge teams. You get 10, 20 people that have to have watch over it at always weird hours, and I think there is a lot of pain to that and that resonate a lot with people. And when we talk about monitoring at the future level, that also helps a lot. Like I was part of organizations before where we had a dedicated staff engineer to just monitor and fix performance on a daily basis because it's such a huge problem and it affects so much the performance of the company. And so essentially, you have this person that tries to look at is a performance being degraded today with the deployment of yesterday and what went out yesterday and you have so many things that went out. It's so hard to control. With what we provide, we tell you exactly which feature flag is responsible for the degradation. And so, you don't need that person to focus on that anymore. And you can focus on delivering value a lot better. >> I think it also might take away the need for extensive release notebooks and playbooks, right? 'Cause when you do bring all those teams together, it's certain people that are in that meeting and there's a PDF saying, all right, we check this off the list, we check this off the list. I think that might alleviate some of that overhead as well. >> Streamlining processes, process efficiencies, workforce productivity improvements, big impact. >> And that gets code quicker to the user. >> You talk about decoupling deploy from release. What do you mean by that? What's the value? >> So the deployment in my definition is essentially getting the code out to production. The release is activating the code in production. And often people do both of those things at the same time, right? But there's a huge risk when you do that because if anything goes wrong, now you need to revert everything which is not a short operation often and takes a lot of effort. And so now, if you can basically push your code to production but separate the activation of it, the release of it, then it goes a lot faster. It's a lot. You have a lot of autonomy and decoupling and if anything goes wrong, it's the click of a button and it's off. So like there's a lot of safety that comes with it and we know that any outages as a high cost for all the companies. So it's like, if you can reduce the outage to like five seconds... >> Right. >> It's a lot better than basically several hours. >> Can you talk about the value out of Split versus DIY and where are most of your customers in this process? Do they have a bunch of tools, a bunch of processes, a bunch of teams, and you're really helping them consolidate streamline? >> The one thing I hear a lot is we rolled our own AB testing and feature flagging system, but some of the issues I've seen and I've heard are that they don't have all those metrics or they have to work with a specific data team to get those metrics. And then you go back to having those meetings about meetings... >> Lisa: Dependencies. >> Right, you have a data team that's putting together a report that is then presented to you and then that's got to be presented to a stakeholder and then that stakeholder makes a decision whether to turn on feature A or feature B, right? Our product from my understanding is we have those metrics already built in and you can have that at your disposal. >> Yeah, the other thing I would add to that is like we see a number of people, they start on the feature flag journey just because they have a high risk thing that they need to put out. So they do the minimal thing to basically control it somehow, but it works only in one part of the stacks. They can't basically leverage it anywhere else and it's very limited in capability so that it just serve the purpose that was needed at that time. They don't have a dedicated team to manage it. So it just there, but it's very constrained and it's not supported effectively. The other thing is like for those companies is like they have a question to ask themselves. It's like do they want to invest resources in managing that kind of tool or is it not so core to their business that they want essentially to have vendor deal with it at a much lower price and they would have to invest resources for them to support it, and... >> Sounds like feature flags are kind of a team building. Have you have a team building dimension to them? >> Yeah. >> Yeah. >> It takes a team for sure. >> Yeah, and then once you add like AB testing and the feature flag, it's the collaboration between product management and engineering. It can go even further. Like two executives like to basically, you know, view the impact, understand the impact. So it goes from the control to the risk management to the product and to the impact and measuring the flow of delivery and the communication around it. >> Here we are at re:Invent, so many thousands of people as I mentioned, we're on the second full-day of the event. What have you heard from AWS that really excites you about being in their ecosystem? Any news in particular that jumps out at you that really speaks to improving that developer experience as if we've heard a lot of focus on the developer? >> Chris: Yeah, I haven't heard much, have you? >> So, I arrived yesterday, I haven't followed yet all the announcement, I'm just like, >> there's so many- >> on the news, yeah, yeah. >> So I'm on the booth at the same time. >> I stopped counting at 15 during the Keynote this morning. >> Many of them just can't keep up, there's so much happening at one time's so much. >> This event is a can of content, can of news re:Invent. It is hard. But yesterday they were spent so much time talking about data and how... And I always think every company today has to be a data company, have to be a software company, we were just talking with Capital One and they think of themselves as a technology company that does banking. And sometimes, I'll talk with retailers that think of themselves as technology companies that do retail and they love that but that's what companies like Split have to enable these days. It's companies to become technology companies, deliver code faster to customer because the customer's demanding it. We're not going to want less stuff slower. >> Yeah, I mean it's so essential I think for me like I joined Split because of that premises. Like every company now is a software company and every company has really to compete in innovation. You know all those banks, Capital One like we see it a lot in the financial industry where our message resonates extremely strongly is really in a high-competitive environment and they have to be innovative and innovation comes when people have speed and autonomy. And if you basically provide that to teams and the tools to basically get some signals and some quick feedback loop, that's how you get innovation. Like you can't decide what to build but you can basically provide the tools to enable them to think about. >> Right, you can experiment more flexibly right, faster. >> And developers have to be empowered, right? >> Yes. >> I think that's the probably one of the number one messages I've heard at all the shows we've done this year. How influential the developer is in the direction of the business. >> Autonomy and empowerment are two main factors 'cause I'm a front end developer at heart and I want to work on cool stuff and we're doing cool stuff. Like we are doing cool stuff. We can't talk about all of it, right? But I think we're doing a lot of cool things at Split and I'm really stoked to be a part of the team and grow developer relations, grow developer advocacy and be along for the journey. >> Yeah, I love that. Last question for both of you, same question. If you had a bumper sticker and you were going to put it on a fancy shiny new car, car of your choice about Split, what would it say? Pierre I'll start with you then Chris. >> Bumper sticker. >> On the spot question. >> On the question, (everyone laughs happily) I mean the easy answer is probably written on my t-shirt. Like, you know, 'What a Release, What a Relief'. I think that the first step for teams is like, you can have a message that's very like even further, you know, the Agile transformation is a journey and I basically tell people, you need to first crawl, walk and run and I think the 'What a Release, What a Relief' is a good step to like getting to the working. And I think like that would be the first bumper sticker before I get to the further one about AP testing and innovative. >> Love it. Chris, what would your bumper sticker say? >> It would say Split software, feature flags for the masses. Hard stop. >> Mic drop. >> Done. >> Awesome guys, thank you so much for joining Paul and me on the program. It's been outstanding introducing Split to our audience, what you do, how you're impacting the developer experience and ultimately, the business and the end customer on the backend who just wants things to work. We appreciate your insights, we appreciate your time. >> Thanks so much for having us. >> Appreciate it. >> Our pleasure. For our guests and Paul Gillin, I'm Lisa Martin. You're watching theCUBE, which you know is the leader in live enterprise and emerging tech coverage. (bright upbeat music)

>>Hello, and welcome to the cubes presentation of the AWS startup showcase. This is season two, episode four, the ongoing series covering exciting startups from the AWS ecosystem to talk about cyber security. I'm your host, John feer. And today we're excited to join by a Mediatel Walker, CEO of Quin security and sub IER, vice president of product management of sequence security gentlemen, thanks for joining us today on this showcase. >>Thank you, John PRAs. >>So the title of this session is continuous API protection life cycle to discover, detect, and defend security. APIs are part of it. They're hardened, everyone's using them, but they're they're target for malicious behavior. This is the focus of this segment. You guys are in the leading edge of this. What are the biggest challenges for organizations right now in assessing their security risks? Because you're seeing APIs all over the place in the news, just even this week, Twitter had a whistleblower come out from the security group, talking about their security plans, misleading the FTC on the bots and some of the malicious behavior inside the API interface of Twitter. This is really a mainstream Washington post is reporting on it. New York times, all the global outlets are talking about this story. This is the risk. I mean, yeah, this is what you guys do protect against this. >>Yeah, this is absolutely top of mind for a lot of security folks today. So obviously in the media and the type of attack that that is being discussed with this whistleblower coming out is called reputation bombing. This is not new. This has been going on since I would say at least eight to 10 years where the, the bad actors are using bots or automation and ultimately using APIs on these large social media platforms, whether it's Facebook, whether it's Twitter or some other social media platform and messing with the reputation system of those large platforms. And what I mean by that is they will do fake likes, fake commenting, fake retweeting in the case of Twitter. And what that means is that things that are, should not be very popular, all of a sudden become popular. That that way they're able to influence things like elections, shopping habits, personnel. >>We, we work with similar profile companies and we see this all the time. We, we mostly work on some of the secondary platforms like dating and other sort of social media platforms around music sharing and things like video sharing. And we see this all the time. These, these bots are bad. Actors are using bots, but ultimately it's an API problem. It's not just a bot problem. And that's what we've been trying to sort of preach to the world, which is your bot problem is subset of your API security challenges that you deal as an organization. >>You know, IMIA, we talked about this in the past on a previous conversation, but this really is front and center mainstream for the whole world to see around the challenges. All companies face, every CSO, every CIO, every board member organizations out there looking at this security posture that spans not just information technology, but physical and now social engineering. You have all kinds of new payloads of malicious behavior that are being compromised through, through things like APIs. This is not just about CSO, chief information security officer. This is chief security officer issues. What's your reaction >>Very much so I think the, this is a security problem, but it's also a reputation problem. In some cases, it's a data governance problem. We work with several companies which have very restrictive data governance and data regulations or data residency regulations there to conform to those regulations. And they have to look at that. It's not just a CSO problem anymore. In case of the, the news of the day to day, this is a platform problem. This goes all the way to the, that time CTO of Twitter. And now the CEO of Twitter, who was in charge of dealing with these problems. We see as just to give you an example, we, we work, we work with a similar sort of social media platform that allows Oop based login to their platform that is using tokens. You can sort of sign in with Facebook, sign in with Twitter, sign in with Google. These are API keys that are generated and trusted by these social media platforms. When we saw that Facebook leaked about 50 million of these login credentials or API keys, this was about three, four years ago. I wrote a blog about it. We saw a huge spike in those API keys being used to log to other social media platforms. So although one social platform might be taking care of its, you know, API or what problem, if something else gets reached somewhere else, it has a cascading impact on a variety of platforms. >>You know, that's a really interesting dynamic. And if you think about just the token piece that you mentioned, that's kind of under the coverage, that's a technology challenge, but also you get in the business logic. So let's go back and, and unpack that, okay, they discontinue the tokens. Now they're being reused here. In the case of Twitter, I was talking to an executive here in Silicon valley and they said, yeah, it's a cautionary tale, for sure. Although Twitter's a unique situation, but they abstract out the business value and say, Hey, they had an M and a deal on the table. And so if someone wants to unwind that deal, all I gotta say is, Hey, there's a bot problem. And now you have essentially new kinds of risk in the business have nothing to do with some sign the technology, okay. They got a security breach, but here with Twitter, you have an, an, an M and a deal, an acquisition that's being contested because of the, the APIs. So, so if you're in business, you gotta think to yourself, what am I risking with my API? So every organization should be assessing their security risks, tied to their APIs. This is a huge awakening for them. Where should they start? And that's the, that's the core question. Okay. You got my attention risks with the API. What do I do? >>So when I talked to you in my previous interview, the start is basically knowing what to, in most cases, you see these that are hitting the wire much. Every now there is a major in cases you'll find these APIs are targeted, that are not poorly protected. They're absolutely just not protected at all, which means the security team or any sort of team that is responsible for protecting these APIs are just completely unaware of these APIs being there in the first place. And this is where we talk about the shadow it or shadow API problem. Large enterprises have teams that are geo distributed, and this problem is escalated after the pandemic even more because now you have teams that are completely distributed. They do M and a. So they acquire new companies and have no visibility into their API or security practices. And so there are a lot of driving factors why these APIs are just not protected and, and just unknown even more to the security team. So the first step has to be discover your API attack surface, and then prioritize which APIs you wanna target in terms of runtime protection. >>Yeah. I wanna dig into that API kind of attack surface area management, runtime monitoring capability in a second, but so I wanna get you in here too, because we're talking about APIs, we're talking about attacks. What does an API attack look like? >>Yeah, that's a very good question, John, there are really two different forms of attacks of APIs, one type of attack, exploits, APIs that have known vulnerabilities or some form of vulnerabilities. For instance, APIs that may use a weak form of authentication or are really built with no authentication at all, or have some sort of vulnerability that makes them very good targets for an attacker to target. And the second form of attack is a more subtle one. It's called business logic abuse. It's, it's utilizing APIs in completely legitimate manner manners, but exploiting those APIs to exfiltrate information or key sensitive information that was probably not thought through by the developer or the designers or those APIs. And really when we do API protection, we really need to be able to handle both of those scenarios, protect against abuse of APIs, such as broken authentication, or broken object level authorization APIs with that problem, as well as protecting APIs from business logic abuse. And that's really how we, you know, differentiate against other vendors in this >>Market. So just what are the, those key differentiated ways to identify the, in the malicious intents with APIs? Can you, can you just summarize that real quick, the three ways? >>Sure. Yeah, absolutely. There are three key ways that we differentiate against our competition. One is in the, we have built out a, in the ability to actually detect such traffic. We have built out a very sophisticated threat intelligence network built over the entire lifetime of the company where we have very well curated information about malicious infrastructures, malicious operators around the world, including not just it address ranges, but also which infrastructures do they operate on and stuff like that, which actually helps a lot in, in many environments in especially B2C environments, that alone accounts for a lot of efficacy for us in detecting our weed out bad traffic. The second aspect is in analyzing the request that are coming in the API traffic that is coming in and from the request itself, being able to tell if there is credential abuse going on or credential stuffing going on or known patterns that the traffic is exhibiting, that looks like it is clearly trying to attack the attack, the APM. >>And the third one is, is really more sophisticated as they go farther and farther. It gets more sophisticated where sequence actually has a lot of machine learning models built in which actually profile the traffic that is coming in and separate. So the legitimate or learns the legitimate traffic from the anomalous or suspicious traffic. So as the traffic, as the API requests are coming in, it automatically can tell that this traffic does not look like legitimate traffic does not look like the traffic that this API typically gets and automatically uses that to figure out, okay, where is this traffic coming from? And automatically takes action to prevent that attack? >>You know, it's interesting APIs have been part of the goodness of cloud and cloud scale. And it reminds me of the old Andy Grove quote, founder of, in one of the founders of Intel, you know, let chaos, let, let the chaos happen, then reign it in it's APIs. You know, a lot of people have been creating them and you've got a lot of different stakeholders involved in creating them. And so now securing them and now manage them. So a lot of creation now you're starting to secure them and now you gotta manage 'em. This all is now big focus. As you pointed out, what are some of the dynamics that customers who have to deal with on the product side and, and organization, let, let chaos rain, and then rain in the chaos, as, as the saying goes, what, what do companies do? >>Yeah. Typically companies start off with like, like a mayor talked about earlier. Discovery is really the key thing to start with, like figuring out what your API attack surfaces and really getting your arms around that problem. And typically we are finding customers start that off from the security organization, the CSO organization to really go after that problem. And in some cases, in some customers, we even find like dedicated centers of excellence that are created for API security, which go after that problem to be able to get their arms around the whole API attack surface and the API protection problem statement. So that's where usually that problem starts to get addressed. >>I mean, organizations and your customers have to stop the attacks. A lot of different techniques, you know, run time. You mentioned that earlier, the surface area monitoring, what's the choice. What's the, where are, where are, where is everybody? Is everyone in the, in the boiling water, like the frog and boiling water or they do, they know it's happening? Like what did they do? What's their opportunity to get in >>Position? Yeah. So I, I think let's take a step back a little bit, right? What has happened is if you draw the cloud security market, if you will, right. Which is the journey to the cloud, the security of these applications or APIs at a container level, in terms of vulnerabilities and, and other things that market grew with the journey to the cloud, pretty much locked in lockstep. What has happened in the API side is the API space has kind of lacked behind the growth and explosion in the API space. So what that means is APIs are getting published way faster than the security teams are able to sort of control and secure them. APIs are getting published in environments that the security completely unaware of. We talked about in the past about the parameter, the parameter, as we know, it doesn't exist anymore. It used to be the case that you hit a CDN, you terminate your SSL, you stop your layer three and four DDoS. >>And then you go into the application and do the business logic. That parameter is just gone because it's now could be living in multi-cloud environment. It could be living in the on-prem environment, which is PubNet is friendly. And so security teams that are used to protecting apps, using a perimeter defense plus changes, it's gone. You need to figure out where your perimeter is. And therefore we sort of recommend an approach, which is have a uniform view across all your APIs, wherever they could be distributed and have a single point of control across those with a solution like sequence. And there are others also in this space, which is giving you that uniform view, which is first giving you that, you know, outside and looking view of what APIs to protect. And then let's, you sort of take the journey of securing the API life cycle. >>So I would say that every company now hear me out on this indulges me for a second. Every company in the world will be non perimeter based, except for maybe 5% because of maybe unique reason, proprietary lockdown, information, whatever. But for most, most companies, everyone will be in the cloud or some cloud native, non perimeter based security posture. So the question is, how does your platform fit into that trajectory? And specifically, why are you guys in the position in your mind to help customers solve this API problem? Because again, APIs have been the greatest thing about the cloud, right? Yeah. So the goodness is there because of APS. Now you gotta reign it in reign in the chaos. Yeah. What, what about your platform share? What is it, why is it win? Why should customers care about this? >>Absolutely. So if you think about it, you're right, the parameter doesn't exist. People have APIs deployed in multiple environments, multicloud hybrid, you name it sequence is uniquely positioned in a way that we can work with your environment. No matter what that environment is. We're the only player in this space that can protect your APIs purely as a SA solution or purely as an on-prem deployment. And that could be a SaaS platform. It doesn't need to be RackN, but we also support that and we could be a hybrid deployment. We have some deployments which are on your prem and the rest of this solution is in our SA. If you think about it, customers have secured their APIs with sequence with 15 minutes, you know, going live from zero to life and getting that protection instantaneously. We have customers that are processing a billion API calls per day, across variety of different cloud environments in sort of six different brands. And so that scale, that flexibility of where we can plug into your infrastructure or be completely off of your infrastructure is something unique to sequence that we offer that nobody else is offering >>Today. Okay. So I'll be, I'll be a naysayer. Yeah, look, it, we are perfectly coded APIs. We are the best in the business. We're locked down. Our APIs are as tight as a drum. Why do I need you? >>So that goes back to who's answer. Of course, >>Everyone's say that that's, that's great, but that's my argument. >>There are two types of API attacks. One is a tactic problem, which is exploiting a vulnerability in an API, right? So what you're saying is my APIs are secure. It does not have any vulnerability I've taken care of all vulnerabilities. The second type of attack that targets APIs is the business logic. Use this stuff in the news this week, which is the whistleblower problem, which is, if you think APIs that Twitter is publishing for users are perfectly secure. They are taking care of all the vulnerabilities and patching them when they find new ones. But it's the business logic of, you know, REWE liking or commenting that the bots are targeting, which they have no against. Right. And then none of the other social networks too. Yeah. So there are many examples. Uber wrote a program to impersonate users in different geo locations to find lifts, pricing, and driver information and passenger information, completely legitimate use of APIs for illegitimate, illegitimate purpose using bots. So you don't need bots by the way, don't, don't make this about bot versus not. Yeah. You can use APIs sort of for the, the purpose that they're not designed for sort of exploiting their business logic, either using a human interacting, a human farm, interacting with those APIs or a bot form targeting those APIs, I think. But that's the problem when you have, even when you've secured all your problem, all your APIs, you still have to worry about these of challenges. >>I think that's the big one. I think the business logic one, certainly the Twitter highlights that the Uber example is a good one. That is basically almost the, the backlash of having a simplistic API, which people design to. Right. Yeah. You know, as you point out, Twitter is very simple API, hardened, very strong security, but they're using it to maliciously manipulate what's inside. So in a way that perimeter's dead too. Right. So how do you stop that business logic? What's the, what's the solution what's the customer do about that? Because their goal is to create simple, scalable APIs. >>Yeah. I'll, I'll give you a little bit, and then I think Subaru should maybe go into a little bit of the depth of the problem, but what I think that the answer lies in what Subaru spoke earlier, which is our ML. AI is, is good at profiling plus split between the API users, are these legitimate users, humans versus bots. That's the first split we do. The split second split we do is even when these, these are classified users as bots, we will say there are some good bots that are necessary for the business and bad bots. So we are able to split this across three types of users, legitimate humans, good bots and bad bots. And just to give you an example of good bots is there are in the financial work, there are aggregators that are scraping your data and aggregating for end users to consume, right? Your, your, and other type of financial aggregators FinTech companies like MX. These are good bots and you wanna allow them to, you know, use your APIs, whereas you wanna stop the bad bots from using your APIs super, if you wanna add so, >>So good bots versus bad bots, that's the focus. Go ahead. Weigh in, weigh in on your thought on this >>Really breaks down into three key areas that we talk about here, sequence, right? One is you start by discovering all your APIs. How many APIs do I have in my environment that ly immediately highlight and say, Hey, you have, you know, 10,000 APIs. And that usually is an eye opener to many customers where they go, wow. I thought we had a 10th of that number. That usually is an eyeopener for them to, to at least know where they're at. The second thing is to tell them detection information. So discover, detect, and defend detect will tell them, Hey, your APIs are getting traffic from. So and so it addresses so and so infrastructure. So and so countries and so on that usually is another eye opener for them. They then get to see where their API traffic is coming from. Let's say, if you are a, if you're running a pizza delivery service out of California and your traffic is coming from Eastern Europe to go, wait a minute, nobody's trying, I'm not, I'm not, I don't deliver pizzas in Eastern Europe. Why am I getting traffic from that part of the world? So that sort of traffic immediately comes up and it will tell you that it is hitting your unauthenticated API. It is hitting your API. That has, that is vulnerable to a broken object level, that authorization, vulnerable be and so on. >>Yeah, I think, and >>Then comes the different aspect. Yeah. The different aspect is where you can take action and say, I wanna block certain types of traffic, or I wanna rate limit certain types of traffic. If, if you're seeing spikes there or you could maybe insert header so that it passes on to the end application and the application team can use that bit to essentially take a, a conscious response. And so, so the platform is very flexible in allowing them to take an action that suits their needs. >>Yeah. And I think this is the big trend. This is why I like what you guys are doing. One APIs we're built for the goodness of cloud. They're now the plumbing, you know, anytime you see plumbing involved, connection points, you know, that's pretty important. People are building it out and it has made the cloud what it is. Now, you got a security challenge. You gotta add more intelligence, more smarts to it. This is where I think platform versus tools matter. Can you guys just quickly share your thoughts on that? Cuz a lot of your customers and, and future customers have dealt with the sprawls of all these different tools. Right? I got a tool for this. I got a tool for that, but people are gravitating towards platforms, but how many platforms can a customer have? So again, this brings up the point point around how you guys are engaging with customers. Can you share your thoughts on tooling platforms? Your customers are constantly inundated with the same tsunami. Isn't new thing. Why, what, how should they look at this? >>Yeah, I mean, we don't wanna be, we don't wanna add to that alert fatigue problem that affects much of the cybersecurity industry by generating a whole bunch of alerts and so on. So what we do is we actually integrate very well with S IEM systems or so systems and allow customers to integrate the information that we are detecting or mitigating and feed them onto enterprise systems like a Splunk or a Datadog where they may have sophisticated processes built in to monitor, you know, spikes in anomalous traffic or actions that are taken by sequence. And that can be their dashboard where a whole bunch of alerting and reporting actually happens. So we play in the security ecosystem very well by integrating with other products and integrate very tightly with them, right outta the box. >>Okay. Mia, this is a wrap up now for the showcase. Really appreciate you guys sharing your awesome technology and very relevant product for your customers and where we are right now in this we call Supercloud or now multi-cloud or hybrid world of cloud. Share a, a little bit about the company, how people can get involved in your solution, how they can consume it and things they should know about, about sequence security. >>Yeah, we've been on this journey, an exciting journey it's been for, for about eight years. We have very large fortune 100 global 500 customers that use our platform on a daily basis. We have some amazing logos, both in Europe and, and, and in us customers are, this is basically not the shelf product customers not only use it, but depend on sequence. Several retailers. We are sitting in front of them handling, you know, black Friday, cyber, Monday, Christmas shopping, or any sort of holiday seasonality shopping. And we have handled that the journey starts by, by just simply looking at your API attack surface, just to a discover call with sequence, figure out where your APIs are posted work with you to prioritize how to protect them in a sort of a particular order and take the whole life cycle with sequence. This is, this is an exciting phase exciting sort of stage in the company's life. We just raised a very sort of large CDC round of funding in December from Menlo ventures. And we are excited to see, you know, what's next in, in, in the next, you know, 12 to 18 months. It certainly is the, you know, one of the top two or three items on the CSOs, you know, budget list for next year. So we are extremely busy, but we are looking for, for what the next 12 to 18 months are, are in store for us. >>Well, congratulations to all the success. So will you run the roadmap? You know, APIs are the plumbing. If you will, you know, they connection points, you know, you want to kind of keep 'em simple, as they say, keep the pipes dumb and make the intelligence around it. You seem to see more and more intelligence coming around, not just securing it, but does, where does this go in your mind? Where, where do we go beyond once we secure everything and manage it properly, APRs, aren't going away, they're only gonna get better and smarter. Where's the intelligence coming share a little bit. >>Absolutely. Yeah. I mean, there's not a dull moment in the space. As digital transformation happens to most enterprise systems, many applications are getting transformed. We are seeing an absolute explosion in the volume of APIs and the types of APIs as well. So the applications that were predominantly limited to data centers sort of deployments are now splintered across multiple different cloud environments are completely microservices based APIs, deep inside a Kubernetes cluster, for instance, and so on. So very exciting stuff in terms of proliferation of volume of APIs, as well as types of APIs, there's nature of APIs. And we are building very sophisticated machine learning models that can analyze traffic patterns of such APIs and automatically tell legitimate behavior from anomalous or suspicious behavior and so on. So very exciting sort of breadth of capabilities that we are looking at. >>Okay. I mean, yeah. I'll give you the final words since you're the CEO for the CSOs out there, the chief information security officers and the chief security officers, what do you want to tell them? If you could give them a quick shout out? What would you say to them? >>My shout out is just do an assessment with sequence. I think this is a repeating thing here, but really get to know your APIs first, before you decide what and where to protect them. That's the one simple thing I can mention for thes >>Am. Thank you so much for, for joining me today. Really appreciate it. >>Thank you. >>Thank you. Okay. That is the end of this segment of the eight of his startup showcase. Season two, episode four, I'm John for your host and we're here with sequin security. Thanks for watching.

(upbeat music) >> Hello, and welcome to The Great Cloud Debate. I'm your moderator Rachel Dines. I'm joined by two debaters today Corey Quinn, Cloud Economist at the Duckbill Group and Stu Miniman, Senior Analyst and Host of theCube. Welcome Corey and Stu, this when you can say hello. >> Hey Rachel, great to talk to you. >> And it's better to talk to me. It's always a pleasure to talk to the fine folks over at CloudHealth at by VMware and less of the pleasure to talk to Stu. >> Smack talk is scheduled for later in the agenda gentlemen, so please keep it to a minimum now to keep us on schedule. So here's how today is going to work. I'm going to introduce a debate topic and assign Corey and Stu each to a side. Remember, their assignments are what I decide and they might not actually match their true feelings about a topic, and it definitely does not represent the feelings of their employer or my employer, importantly. Each debater is going to have two minutes to state their opening arguments, then we'll have rebuttals. And each round you the audience gets to vote of who you think is winning. And at the end of the debate, I'll announce the winner. The prize is bragging rights of course, but then also we're having each debater play to win lunch for their local hospital, which is really exciting. So Stu, which hospital are you playing for? >> Yeah, so Rachel, I'm choosing Brigham Women's Hospital. I get a little bit of a home vote for the Boston audience here and was actually my wife's first job out of school. >> Great hospital. Very, very good. All right, Corey, what about you? >> My neighbor winds up being as specialist in infectious diseases as a doctor, and that was always one of those weird things you learn over a cocktail party until this year became incredibly relevant. So I will absolutely be sending the lunch to his department. >> Wonderful! All right. Well, is everyone ready? Any last words? This is your moment for smack talk. >> I think I'll say that for once we can apply it to a specific technology area. Otherwise, it was insulting his appearance and that's too easy. >> All right, let's get going. The first topic is multicloud. Corey, you'll be arguing that companies are better off standardizing on a single cloud. While Stu, you're going to argue the companies are better off with a multicloud strategy. Corey, you're up first, two minutes on the clock and go. >> All right. As a general rule, picking a single provider and going all in leads to the better outcome. Otherwise, you're trying to build every workload to run seamlessly on other providers on a moment's notice. You don't ever actually do it and all you're giving up in return is the ability to leverage whatever your primary cloud provider is letting you build. Now you're suddenly trying to make two differently behaving load balancers work together in the same way, you're using terraform or as I like to call it multicloud formation in the worst of all possible ways. Because now you're having to only really build on one provider, but all the work you're putting in to make that scale to other providers, you might theoretically want to go to at some point, it slows you down, you're never going to be able to move as quickly trying to build for everyone as you are for one particular provider. And I don't care which provider you pick, you probably care which one you pick, I don't care which one. The point is, you've got to pick what's right for your business. And in almost every case, that means start on a single platform. And if you need to migrate down the road years from now, great, that means A you've survived that long, and B you now have the longevity as a business to understand what migrating looks like. Otherwise you're not able to take care of any of the higher level offerings these providers offer that are even slightly differentiated from each other. And even managed database services behave differently. You've got to become a master of all the different ways these things can fail and unfortunate and displeasing ways. It just leaves you in a position where you're not able to specialize, and of course, makes hiring that much harder. Stu, fight me! >> Tough words there. All right, Stu, your turn. Why are companies better off if they go with a multicloud strategy? Got two minutes? >> Yeah, well first of all Corey, I'm really glad that I didn't have to whip out the AWS guidelines, you were not sticking strictly to it and saying that you could not use the words multicloud, cross-cloud, any cloud or every cloud so thank you for saving me that argument. But I want you to kind of come into the real world a little bit. We want access to innovation, we want flexibility, and well, we used to say I would have loved to have a single provider, in the real world we understand that people end up using multiple solutions. If you look at the AI world today, there's not a provider that is a clear leader in every environment that I have. So there's a reason why I might want to use a lot of clouds. Most companies I talked to, Corey, they still have some of their own servers. They're working in a data center, we've seen huge explosion in the service provider world connecting to multiple clouds. So well, a couple of years ago, multicloud was a complete mess. Now, it's only a little bit of a mess, Corey. So absolutely, there's work that we need to do as an industry to make these solutions better. I've been pining for a couple years to say that multicloud needs to be stronger than the sum of its pieces. And we might not yet be there but limiting yourself to a single cloud is reducing your access to innovation, it's reducing your flexibility. And when you start looking at things like edge computing and AI, I'm going to need to access services from multiple providers. So single cloud is a lovely ideal, but in the real world, we understand that teams come with certain skill sets. We end up in many industries, we have mergers and acquisitions. And it's not as easy to just rip out all of your cloud, like you would have 20 years ago, if you said, "Oh, well, they have a phone system or a router "that didn't match what our corporate guidelines is." Cloud is what we're doing. There's lots of solutions out there. And therefore, multicloud is the reality today, and will be the reality going forward for many years to come. >> Strong words from you, Stu. Corey, you've got 60 seconds for rebuttal. I mostly agree with what you just said. I think that having different workloads in different clouds makes an awful lot of sense. Data gravity becomes a bit of a bear. But if you acquire a company that's running on a different cloud than the one that you've picked, you'd be ridiculous to view migrating as anything approaching a strategic priority. Now, this also gets into the question of what is cloud? Our G Suite stuff counts as cloud, but no one really views it in that way. Similarly, when you have an AI specific workload, that's great. As long as it isn't you seriously expensive to move data between providers. That workload doesn't need to live in the same place as your marketing website does. I think that the idea of having a specific cloud provider that you go all in on for every use case, well, at some point that leads to ridiculous things like pretending that Amazon WorkDocs has customers, it does not. But for things that matter to your business and looking at specific workloads, I think that you're going to find a primary provider with secondary workloads here and they're scattered elsewhere to be the strategy that people are getting at when they use the word multicloud badly. >> Time's up for you Corey, Stu we've got time for rebuttal and remember, for those of you in the audience, you can vote at any time and who you think is winning this round. Stu, 60 seconds for a rebuttal. >> Yeah, absolutely Corey. Look, you just gave the Andy Jassy of what multicloud should be 70 to 80% goes to a single provider. And it does make sense we know nobody ever said multicloud equals the same amount in multiple environments but you made a clear case as to why multicloud leveraging multi providers is likely what most companies are going to do. So thank you so much for making a clear case as to why multicloud not equal cloud, across multiple providers is the way to go. So thank you for conceding the victory. >> Last Words, Corey. >> If that's what you took from it Stu, I can't get any closer to it than you have. >> All right, let's move on to the next topic then. The next topic is serverless versus containers which technology is going to be used in, let's say, five to 10 years time? And as a reminder, I'm going to assign each of the debaters these topics, their assignments may or may not match their true feelings about this topic, and they definitely don't represent the topics of my employer, CloudHealth by VMware. Stu, you're going to argue for containers. Corey you're going to argue for start serverless. Stu, you're up first. Two minutes on the clock and go. >> All right, so with all respect to my friends in the serverless community, We need to have a reality check as to how things work. We all know that serverless is a ridiculous name because underneath we do need to worry about all of the infrastructure underneath. So containers today are the de facto building block for cloud native architectures, just as the VM defined the ecosystem for an entire generation of solutions. Containers are the way we build things today. It is the way Google has architected their entire solution and underneath it is often something that's used with serverless. So yes, if you're, building an Alexa service, serverless make what's good for you. But for the vast majority of solutions, I need to have flexibility, I need to understand how things work underneath it. We know in IT that it's great when things work, but we need to understand how to fix them when they break. So containerization gets us to that atomic level, really close to having the same thing as the application. And therefore, we saw the millions of users that deploy Docker, we saw the huge wave of container orchestration led by Kubernetes. And the entire ecosystem and millions of customers are now on board with this way of designing and architecting and breaking down the silos between the infrastructure world and the application developer world. So containers, here to stay growing fast. >> All right, Corey, what do you think? Why is serverless the future? >> I think that you're right in that containers are the way you get from where you were to something that runs effectively in a cloud environment. That is why Google is so strongly behind Kubernetes it helps get the entire industry to write code the way that Google might write code. And that's great. But if you're looking at effectively rewriting something from scratch, or building something that new, the idea of not having to think about infrastructure in the traditional sense of being able to just here, take this code and run it in a given provider that takes whatever it is that you need to do and could loose all these other services together, saves an awful lot of time. As that continues to move up the stack towards the idea of no code or low code. And suddenly, you're now able to build these applications in ways that require just a little bit of code that tie together everything else. We're closer than ever to that old trope of the only code you write is business logic. Serverless gives a much clearer shot of getting there, if you can divorce yourself from the past of legacy workloads. Legacy, of course meaning older than 18 months and makes money. >> Stu, do you have a rebuttal, 60 seconds? >> Yeah. So Corey, we've been talking about this Nirvana in many ways. It's the discussion that we had for paths for over a decade now. I want to be able to write my code once not worry about where it lives, and do all this. But sometimes, there's a reason why we keep trying the same thing over and over again, but never reaching it. So serverless is great for some application If you talked about, okay, if you're some brand new webby thing there and I don't want to have to do this team, that's awesome. I've talked to some wonderful people that don't know anything about coding that have built some cool stuff with serverless. But cool stuff isn't what most business runs on, and therefore containerization is, as you said, it's a bridge to where I need to go, it lives in these cloud environments, and it is the present and it is the future. >> Corey, your response. >> I agree that it's the present, I doubt that it's the future in quite the same way. Right now Kubernetes is really scratching a major itch, which is how all of these companies who are moving to public cloud still I can have their infrastructure teams be able to cosplay as cloud providers themselves. And over time, that becomes simpler and I think on some level, you might even see a convergence of things that are container workloads begin to look a lot more like serverless workloads. Remember, we're aiming at something that is five years away in the context of this question. I think that the serverless and container landscape will look very different. The serverless landscape will be bright and exciting and new, whereas unfortunately the container landscape is going to be represented by people like you Stu. >> Hoarse words from Corey. Stu, any last words or rebuttals? >> Yeah, and look Corey absolutely just like we don't really think about the underlying server or VM, we won't think about the containers you won't think about Kubernetes in the future, but, the question is, which technology will be used in five to 10 years, it'll still be there. It will be the fabric of our lives underneath there for containerization. So, that is what we were talking about. Serverless I think will be useful in pockets of places but will not be the predominant technology, five years from now. >> All right, tough to say who won that one? I'm glad I don't have to decide. I hope everyone out there is voting, last chance to vote on this question before we move on to the next. Next topic is cloud wars. I'm going to give a statement and then I'm going to assign each of you a pro or a con, Google will never be an actual contender in the cloud wars always a far third, we're going to have Corey arguing that Google is never going to be an actual contender. And Stu, you're going to argue that Google is eventually going to overtake the top two AWS and Azure. As a constant reminder, I'm assigning these topics, it's my decision and also they don't match the opinions of me, my employer, or likely Stu or Corey. This is all just for fun and games. But I really want to hear what everyone has to say. So Corey, you're up first two minutes. Why is Google never going to be an actual contender and go. >> The biggest problem Google has in the time of cloud is their ability to forecast longer term on anything that isn't their advertising business, and their ability to talk to human beings long enough to meet people where they are. We're replacing their entire culture is what it's going to take to succeed in the time of cloud and with respect, Thomas Kurian is a spectacular leader internally but look at where he's come from. He spent 22 years at Oracle and now has been transplanted into Google. If we take a look at Satya Nadella's cloud transformation at Microsoft, he was able to pull that off as an insider, after having known intimately every aspect of that company, and he grew organically with it and was perfectly positioned to make that change. You can't instill that kind of culture change by dropping someone externally, on top of an organization and expecting anything to go with this magic one day wake up and everything's going to work out super well. Google has a tremendous amount of strengths, and I don't see that providing common denominator cloud computing services to a number of workloads that from a Google perspective are horrifying, is necessarily in their wheelhouse. It feels like their entire focus on this is well, there's money over there. We should go get some of that too. It comes down to the traditional Google lack of focus. >> Stu, rebuttal? Why do you think Google has a shaft? >> Yeah, so first of all, Corey, I think we'd agree Google is a powerhouse in the world today. My background is networking, when they first came out with with Google Cloud, I said, Google has the best network, second to none in the world. They are ubiquitous today. If you talk about the impact they have on the world, Android phones, you mentioned Kubernetes, everybody uses G Suite maps, YouTube, and the like. That does not mean that they are necessarily going to become the clear leader in cloud but, Corey, they've got really, really smart people. If you're not familiar with that talk to them. They'll tell you how smart they are. And they have built phenomenal solutions, who's going to be able to solve, the challenge every day of, true distributed systems, that a global database that can handle the clock down to the atomic level, Google's the one that does that we've all read the white papers on that. They've set the tone for Hadoop, and various solutions that are all over the place, and their secret weapon is not the advertising, of course, that is a big concern for them, but is that if you talk about, the consumer adoption, everyone uses Google. My kids have all had Chromebooks growing up. It isn't their favorite thing, but they get, indoctrinated with Google technology. And as they go out and leverage technologies in the world, Google is one that is known. Google has the strength of technology and a lot of positioning and partnerships to move them forward. Everybody wants a strong ecosystem in cloud, we don't want a single provider. We already discussed this before, but just from a competitive nature standpoint, if there is a clear counterbalance to AWS, I would say that it is Google, not Microsoft, that is positioned to be that clear and opportune. >> Interesting, very interesting Stu. So your argument is the Gen Zers will of ultimately when they come of age become the big Google proponents. Some strong words that as well but they're the better foil to AWS, Corey rebuttal? >> I think that Stu is one t-shirt change away from a pitch perfect reenactment of Charlie Brown. In this case with Google playing the part of Lucy yanking the football away every time. We've seen it with inbox, Google Reader, Google Maps, API pricing, GKE's pricing for control plane. And when your argument comes down to a suddenly Google is going to change their entire nature and become something that it is as proven as constitutionally incapable of being, namely supporting something that its customers want that it doesn't itself enjoy working on. And to the exclusion of being able to get distracted and focused on other things. Even their own conferences called Next because Google is more interested in what they're shipping than what they're building, than what they're currently shipping. I think that it is a fantasy to pretend that that is somehow going to change without a complete cultural transformation, which again, I don't see the seeds being planted for. >> Some sick burns in there Stu, rebuttal? >> Yeah. So the final word that I'll give you on this is, one of the most important pieces of what we need today. And we need to tomorrow is our data. Now, there are some concerns when we talk about Google and data, but Google also has strong strength in data, understanding data, helping customers leverage data. So while I agree to your points about the cultural shift, they have the opportunity to take the services that they have, and enable customers to be able to take their data to move forward to the wonderful world of AI, cloud, edge computing, and all of those pieces and solve the solution with data. >> Strong words there. All right, that's a tough one. Again, I hope you're all out there voting for who you think won that round. Let's move on to the last round before we start hitting the lightning questions. I put a call out on several channels and social media for people to have questions that they want you to debate. And this one comes from Og-AWS Slack member, Angelo. Angelo asks, "What about IBM Cloud?" Stu you're pro, Corey you're con. Let's have Stu you're up first. The question is, what about IBM Cloud? >> All right, so great question, Angelo. I think when you look at the cloud providers, first of all, you have to understand that they're not all playing the same game. We talked about AWS and they are the elephant in the room that moves nimbly as a cheetah. Every other provider plays a little bit of a different game. Google has strength in data. Microsoft, of course, has their, business productivity applications. IBM has a strong legacy. Now, Corey is going to say that they are just legacy and you need to think about them but IBM has strong innovation. They are a player in really what we call chapter two of the cloud. So when we start talking about multicloud, when we start talking about living in many environments, IBM was the first one to partner with VMware for VMware cloud before the mega VMware AWS announcement, there was IBM up on stage and if I remember right, they actually have more VMware customers on IBM Cloud than they do in the AWS cloud. So over my shoulder here, there's of course, the Red Hat $34 billion to bet on that multicloud solution. So as we talk about containerization, and Kubernetes, Red Hat is strongly positioned in open-source, and flexibility. So you really need a company that understands both the infrastructure side and the application side. IBM has database, IBM has infrastructure, IBM has long been the leader in middleware, and therefore IBM has a real chance to be a strong player in this next generation of platforms. Doesn't mean that they're necessarily going to go attack Amazon, they're partnering across the board. So I think you will see a kinder, gentler IBM and they are leveraging open source and Red Hat and I think we've let the dogs out on the IBM solution. >> Indeed. >> So before Corey goes, I feel the need to remind everyone that the views expressed here are not the views of my employer nor myself, nor necessarily of Corey or Stu. I have Corey. >> I haven't even said anything yet. And you're disclaiming what I'm about to say. >> I'm just warning the audience, 'cause I can't wait to hear what you're going to say next. >> Sounds like I have to go for the high score. All right. IBM's best days are behind it. And that is pretty clear. They like to get angry when people talk about how making the jokes about a homogenous looking group of guys in blue suits as being all IBM has to offer. They say that hasn't been true since the '80s. But that was the last time people cared about IBM in any meaningful sense and no one has bothered to update the relevance since then. Now, credit where due, I am seeing an awful lot of promoted tweets from IBM into my timeline, all talking about how amazing their IBM blockchain technology is. And yes, that is absolutely the phrasing of someone who's about to turn it all around and win the game. I don't see it happening. >> Stu, rebuttal? >> Look, Corey, IBM was the company that brought us the UPC code. They understand Mac manufacturing and blockchain actually shows strong presence in supply chain management. So maybe you're not quite aware of some of the industries that IBM is an expert in. So that is one of the big strengths of IBM, they really understand verticals quite well. And, at the IBM things show, I saw a lot in the healthcare world, had very large customers that were leveraging those solutions. So while you might dismiss things when they say, Oh, well, one of the largest telecom providers in India are leveraging OpenStack and you kind of go with them, well, they've got 300 million customers, and they're thrilled with the solution that they're doing with IBM, so it is easy to scoff at them, but IBM is a reliable, trusted provider out there and still very strong financially and by the way, really excited with the new leadership in place there, Arvind Krishna knows product, Jim Whitehurst came from the Red Hat side. So don't be sleeping on IBM. >> Corey, any last words? >> I think that they're subject to massive disruption as soon as they release the AWS 400 mainframe in the cloud. And I think that before we, it's easy to forget this, but before Google was turning off Reader, IBM stopped making the model M buckling spring keyboards. Those things were masterpieces and that was one of the original disappointments that we learned that we can't fall in love with companies, because companies in turn will not love us back. IBM has demonstrated that. Lastly, I think I'm thrilled to be working with IBM is exactly the kind of statement one makes only at gunpoint. >> Hey, Corey, by the way, I think you're spending too much time looking at all titles of AWS services, 'cause you don't know the difference between your mainframe Z series and the AS/400 which of course is heavily pending. >> Also the i series. Oh yes. >> The i series. So you're conflating your system, which still do billions of dollars a year, by the way. >> Oh, absolutely. But that's not we're not seeing new banks launching and then building on top of IBM mainframe technology. I'm not disputing that mainframes were phenomenal. They were, I just don't see them as the future and I don't see a cloud story. >> Only a cloud live your mainframe related smack talk. That's the important thing that we're getting to here. All right, we move-- >> I'm hoping there's an announcement from CloudHealth by VMware that they also will now support mainframe analytics as well as traditional cloud. >> I'll look into that. >> Excellent. >> We're moving on to the lightning rounds. Each debater in this round is only going to get 60 seconds for their opening argument and then 30 seconds for a rebuttal. We're going to hit some really, really big important questions here like this first one, which is who deserves to sit on the Iron Throne at the end of "Game of Thrones?" I've been told that Corey has never seen this TV show so I'm very interested to hear him argue for Sansa. But let's Sansa Stark, let's hear Stu go first with his argument for Jon Snow. Stu one minute on the clock, go. >> All right audience let's hear it from the king of the north first of all. Nothing better than Jon Snow. He made the ultimate sacrifice. He killed his love to save Westeros from clear destruction because Khaleesi had gone mad. So Corey is going to say something like it's time for the women to do this but it was a woman she went mad. She started burning the place down and Jon Snow saved it so it only makes sense that he should have done it. Everyone knows it was a travesty that he was sent back to the Wall, and to just wander the wild. So absolutely Jon Snow vote for King of the North. >> Compelling arguments. Corey, why should Sansa Stark sit on the throne? Never having seen the show I've just heard bits and pieces about it and all involves things like bloody slaughters, for example, the AWS partner Expo right before the keynote is best known as AWS red wedding. We take a look at that across the board and not having seen it, I don't know the answer to this question, but how many of the folks who are in positions of power we're in fact mediocre white dudes and here we have Stu advocating for yet another one. Sure, this is a lightning round of a fun event but yes, we should continue to wind up selecting this mediocre white person has many parallels in terms of power, et cetera, politics, current tech industry as a whole. I think she's right we absolutely should give someone with a look like this a potential opportunity to see what they can do instead. >> Ouch, Stu 30 seconds rebuttal. >> Look, I would just give a call out to the women in the audience and say, don't you want Jon Snow to be king? >> I also think it's quite bold of Corey to say that he looks like Kit Harington. Corey, any last words? >> I think that it sad you think Stu was running for office at this point because he's become everyone's least favorite animal, a panda bear. >> Fire. All right, so on to the next question. This one also very important near and dear to my heart personally, is a hot dog a sandwich. Corey you'll be arguing no, Stu will be arguing yes. I must also add this important disclaimer that these assignments are made by me and might not reflect the actual views of the debaters here so Corey, you're up first. Why is a hot dog not a sandwich? >> Because you'll get punched in the face if you go to a deli of any renown and order a hot dog. That is not what they serve there. They wind up having these famous delicatessen in New York they have different sandwiches named after different celebrities. I shudder to think of the deadly insult that naming a hot dog after a celebrity would be to that not only celebrity in some cases also the hot dog too. If you take a look and you want to get sandwiches for lunch? Sure. What are we having catered for this event? Sandwiches. You show up and you see a hot dog, you're looking around the hot dog to find the rest of the sandwich. Now while it may check all of the boxes for a technical definition of what a sandwich is, as I'm sure Stu will boringly get into, it's not what people expect, there's a matter of checking the actual boxes, and then delivering what customers actually want. It's why you can let your product roadmap be guided by cart by customers or by Gartner but rarely both. >> Wow, that one hurts. Stu, why is the hot dog a sandwich? >> Yeah so like Corey, I'm sorry that you must not have done some decent traveling 'cause I'm glad you brought up the definition because I'm not going to bore you with yes, there's bread and there's meat and there's toppings and everything else like that but there are some phenomenal hot dogs out there. I traveled to Iceland a few years ago, and there's a little hot dog stand out there that's been there for over 40 or 50 years. And it's one of the top 10 culinary experience I put in. And I've been to Michelin star restaurants. You go to Chicago and any local will be absolutely have to try our creation. There are regional hot dogs. There are lots of solutions there and so yeah, of course you don't go to a deli. Of course if you're going to the deli for takeout and you're buying meats, they do sell hot dogs, Corey, it's just not the first thing that you're going to order on the menu. So I think you're underselling the hot dog. Whether you are a child and grew up and like eating nothing more than the mustard or ketchup, wherever you ate on it, or if you're a world traveler, and have tried some of the worst options out there. There are a lot of options for hot dogs so hot dog, sandwich, culinary delight. >> Stu, don't think we didn't hear that pun. I'm not sure if that counts for or against you, but Corey 30 seconds rebuttal. >> In the last question, you were agitating for putting a white guy back in power. Now you're sitting here arguing that, "Oh some of my best friend slash meals or hot dogs." Yeah, I think we see what you're putting down Stu and it's not pretty, it's really not pretty and I think people are just going to start having to ask some very pointed, delicate questions. >> Tough words to hear Stu. Close this out or rebuttal. >> I'm going to take the high road, Rachel and leave that where it stands. >> I think that is smart. All right, next question. Tabs versus spaces. Stu, you're going to argue for tabs, Corey, you're going to argue for spaces just to make this fun. Stu, 60 seconds on the clock, you're up first. Why are tabs the correct approach? >> First of all, my competitor here really isn't into pop culture. So he's probably not familiar with the epic Silicon Valley argument over this discussion. So, Corey, if you could explain the middle of algorithm, we will be quite impressed but since you don't, we'll just have to go with some of the technology first. Looks, developers, we want to make things simple on you. Tabs, they're faster to do they take up less memory. Yes, they aren't quite as particular as using spaces but absolutely, they get the job done and it is important to just, focus on productivity, I believe that the conversation as always, the less code you can write, the better and therefore, if you don't have to focus on exactly how many spaces and you can just simplify with the tabs, you're gona get close enough for most of the job. And it is easier to move forward and focus on the real work rather than some pedantic discussion as to whether one thing is slightly more efficient than the other. >> Great points Stu. Corey, why is your pedantic approach better? >> No one is suggesting you sit there and whack the spacebar four times or eight times you hit the Tab key, but your editor should be reasonably intelligent enough to expand that. At that point, you have now set up a precedent where in other cases, other parts of your codebase you're using spaces because everyone always does. And that winds up in turn, causing a weird dissonance you'll see a bunch of linters throwing issues if you use tabs as a direct result. Now the wrong answer is, of course, and I think Steve will agree with me both in the same line. No one is ever in favor of that. But I also want to argue with Stu over his argument about "Oh, it saves a little bit of space "is the reason one should go with tabs instead." Sorry, that argument said bye bye a long time ago, and that time was the introduction of JavaScript, where it takes many hundreds of Meg's of data to wind up building hello world. Yeah, at that point optimization around small character changes are completely irrelevant. >> Stu, rebuttal? >> Yeah, I didn't know that Corey did not try to defend that he had any idea what Silicon Valley was, or any of the references in there. So Rachel, we might have to avoid any other pop culture references. We know Corey just looks at very specific cloud services and can't have fun with some of the broader themes there. >> You're right my mistake Stu. Corey, any last words? >> It's been suggested that whole middle out seen on the whiteboard was came from a number of conversations I used to have with my co-workers as in people who were sitting in the room with me watching that episode said, Oh my God, I've been in the room while you had this debate with your friend and I will not name here because they at least still strive to remain employable. Yeah, it's, I understand the value in the picking these fights, we could have gone just as easily with vi versus Emacs, AWS versus Azure, or anything else that you really care to pick a fight with. But yeah, this is exactly the kind of pedantic fight that everyone loves to get involved with, which is why I walked a different path and pick other ridiculous arguments. >> Speaking of those ridiculous arguments that brings us to our last debate topic of the day, Corey you are probably best known for your strong feelings about the pronunciation of the acronym for Amazon Machine Image. I will not be saying how I think it is pronounced. We're going to have you argue each. Stu, you're going to argue that the acronym Amazon Machine Image should be pronounced to rhyme with butterfly. Corey, you'll be arguing that it rhymes with mommy. Stu, rhymes with butterfly. Let's hear it, 60 seconds on the clock. >> All right, well, Rachel, first of all, I wish I could go to the videotape because I have clear video evidence from a certain Corey Quinn many times arguing why AMI is the proper way to pronounce this, but it is one of these pedantic arguments, is it GIF or GIF? Sometimes you go back and you say, Okay, well, there's the way that the community did it. And the way that oh wait, the founder said it was a certain way. So the only argument against AMI, Jeff Barr, when he wrote about the history of all of the blogging that he's done from AWS said, I wish when I had launched the service that I pointed out the correct pronunciation, which I won't even deem to talk it because the community has agreed by and large that AMI is the proper way to pronounce it. And boy, the tech industry is rific on this kind of thing. Is it SQL and no SQL and you there's various ways that we butcher these constantly. So AMI, almost everyone agrees and the lead champion for this argument, of course is none other than Corey Quinn. >> Well, unfortunately today Corey needs to argue the opposite. So Corey, why does Amazon Machine Image when pronounce as an acronym rhyme with mommy? >> Because the people who built it at Amazon say that it is and an appeal to authorities generally correct when the folks built this. AWS has said repeatedly that they're willing to be misunderstood for long periods of time. And this is one of those areas in which they have been misunderstood by virtually the entire industry, but they are sticking to their guns and continuing to wind up advocating for AMI as the correct pronunciation. But I'll take it a step further. Let's take a look at the ecosystem companies. Whenever Erica Brescia, who is now the COO and GitHub, but before she wound up there, she was the founder of Bitnami. And whenever I call it Bitn AMI she looks like she is barely successfully restraining herself from punching me right in the mouth for that pronunciation of the company. Clearly, it's Bitnami named after the original source AMI, which is what the proper term pronunciation of the three letter acronym becomes. Fight me Stu. >> Interesting. Interesting argument, Stu 30 seconds, rebuttal. >> Oh, the only thing he can come up with is that, you take the word Bitnami and because it has that we know that things sound very different if you put a prefix or a suffix, if you talk to the Kubernetes founders, Kubernetes should be coop con but the people that run the conference, say it cube con so there are lots of debates between the people that create it and the community. I in general, I'm going to vote with the community most of the time. Corey, last words on this topic 'cause I know you have very strong feelings about it. >> I'm sorry, did Stu just say Kubernetes and its community as bastions of truth when it comes to pronouncing anything correctly? Half of that entire conference is correcting people's pronunciation of Kubernetes, Kubernetes, Kubernetes, Kubernetes and 15 other mispronunciations that they will of course yell at you for but somehow they're right on this one. All right. >> All right, everyone, I hope you've been voting all along for who you think is winning each round, 'cause this has been a tough call. But I would like to say that's a wrap for today. big thank you to our debaters. You've been very good sports, even when I've made you argue for against things that clearly are hurting you deep down inside, we're going to take a quick break and tally all the votes. And we're going to announce a winner up on the Zoom Q and A. So go to the top of your screen, Click on Zoom Q and A to join us and hear the winner announced and also get a couple minutes to chat live with Corey and Stu. Thanks again for attending this session. And thank you again, Corey and Stu. It's been The Great Cloud Debate. All right, so each round I will announce the winner and then we're going to announce the overall winner. Remember that Corey and Stu are playing not just for bragging rights and ownership of all of the internet for the next 24 hours, but also for lunch to be donated to their local hospital. Corey is having lunch donated to the California Pacific Medical Centre. And Stu is having lunch donated to Boston Medical Centre. All right, first up round one multicloud versus monocloud. Stu, you were arguing for multicloud, Corey, you were arguing for one cloud. Stu won that one by 64% of the vote. >> The vendor fix was in. >> Yeah, well, look, CloudHealth started all in AWS by supporting customers across those environments. So and Corey you basically conceded it because we said multicloud does not mean we evenly split things up. So you got to work on those two skills, buddy, 'cause, absolutely you just handed the victory my way. So thank you so much and thank you to the audience for understanding multicloud is where we are today, and unfortunately, it's where we're gonnao be in the future. So as a whole, we're going to try to make it better 'cause it is, as Corey and I both agree, a bit of a mess right now. >> Don't get too cocky. >> One of those days the world is going to catch up with me and realize that ad hominem is not a logical fallacy so much as it is an excellent debating skill. >> Well, yeah, I was going to say, Stu, don't get too cocky because round two serverless versus containers. Stu you argued for containers, Corey you argued for serverless. Corey you won that one with 65, 66 or most percent of the vote. >> You can't fight the future. >> Yeah, and as you know Rachel I'm a big fan of serverless. I've been to the serverless comp, I actually just published an excellent interview with Liberty Mutual and what they're doing with serverless. So love the future, it's got a lot of maturity to deliver on the promise that it has today but containers isn't going anyway or either so. >> So, you're not sad that you lost that one. Got it, good concession speech. Next one up was cloud wars specifically Google. is Google a real contender in the clouds? Stu, you were arguing yes they are. Corey, you were arguing no they aren't. Corey also won this round was 72% of the votes. >> Yeah, it's one of those things where at some point, it's sort of embarrassing if you miss a six inch pot. So it's nice that that didn't happen in this case. >> Yeah, so Corey, is this the last week that we have any competitors to AWS? Is that what we're saying? And we all accept our new overlords. Thank you so much, Corey. >> Well I hope not, my God, I don't know what to be an Amazonian monoculture anymore than I do anyone else. Competition makes all of us better. But again, we're seeing a lot of anti competitive behaviour. For example, took until this year for Microsoft to finally make calculator uninstallable and I trust concerned took a long time to work its way of course. >> Yeah, and Corey, I think everyone is listening to what you've been saying about what Google's doing with Google Meet and forcing that us when we make our pieces there. So definitely there's some things that Google culture, we'd love them to clean up. And that's one of the things that's really held back Google's enterprise budget is that advertised advertising driven culture. So we will see. We are working hand-- >> That was already opted out of Hangouts, how do we fix it? We call it something else that they haven't opted out of yet. >> Hey, but Corey, I know you're looking forward to at least two months of weekly Google live stuff starting this summer. So we'll have a lot of time to talk about google. >> Let's not kid ourselves they're going to cancel it halfway through. (Stu laughs) >> Boys, I thought we didn't have any more smack talk left in you but clearly you do. So, all right, moving on. Next slide. This is the last question that we did in the main part of the debate. IBM Cloud. What about IBM Cloud was the question, Stu, you were pro, Corey you were con. Corey, you won this one again with 62% of the vote and for the main. >> It wasn't just me, IBM Cloud also won. The problem is that competition was oxymoron of the day. >> I don't know Rachel, I thought this one had a real shot as to putting where IBM fits. I thought we had a good discussion there. It seemed like some of the early voting was going my way but it just went otherwise. >> It did. We had some last minute swings in these polls. They were going one direction they rapidly swung another it's a fickle crowd today. So right now we've got Corey with three points Stu with one but really the lightning round anyone's game. They got very close here. The next question, lightning round question one, was "Game of Thrones" who deserves to sit on the Iron Throne? Stu was arguing for Jon Snow, Corey was arguing for Sansa Stark also Corey has never seen Game of Thrones. This was shockingly close with Stu at 51.5% of the vote took the crown on this King of the North Stu. >> Well, I'm thrilled and excited that King of the North pulled things out because it would have been just a complete embarrassment if I lost to Corey on this question. >> It would. >> It was the right answer, and as you said, he had no idea what he's talking about, which, unfortunately is how he is on most of the rest of it. You just don't realize that he doesn't know what he's talking about. 'Cause he uses all those fast words and discussion points. >> Well, thank you for saying the quiet part out loud. Now, I am completely crestfallen as to the results of this question about a thing I've never seen and could not possibly care less about not going in my favor. I will someday managed to get over this. >> I'm glad you can really pull yourself together and keep on going with life, Corey it's inspiring. All right, next question. Was the lightning round question two is a hot dog a sandwich? Stu, you were arguing yes. Corey, you were arguing no. Corey landslide, you won this 75% of the vote. >> It all comes down to customer expectations. >> Yeah. >> Just disappointment. Disappointment. >> All right, next question tabs versus spaces. Another very close one. Stu, what were you arguing for Stu? >> I was voting tabs. >> Tabs, yeah. And Corey, you were arguing spaces. This did not turn out the way I expected. So Stu you lost this by slim margin Corey 53% of the vote. You won with spaces. >> Yep. And I use spaces in my day to day life. So that's a position I can actually believe in. >> See, I thought I was giving you the opposite point of view there. I mistook you for the correct answer, in my opinion, which is tabs. >> Well, it is funnier to stalk me on Twitter and look what I have to there than on GitHub where I just completely commit different kinds of atrocities. So I don't blame you. >> Caught that pun there. All right, the last rounds. Speaking of atrocities, AMI, Amazon Machine Image is it pronounced AMI or AMI? >> I better not have won this one. >> So Stu you were arguing that this is pronounced AMI rhymes with butterfly. Corey, you were arguing that it's pronounced AMI like mommy. Any guesses under who won this? >> It better be Stu. >> It was a 50, 50 split complete tie. So no points to anyone. >> For your complete and utterly failed on this because I should have won in a landslide. My entire argument was based on every discussion you've had on this. So, Corey I think they're just voting for you. So I'm really surprised-- >> I think at this point it shows I'm such a skilled debater that I could have also probably brought you to a standstill taking the position that gravity doesn't exist. >> You're a master of few things, Corey. Usually it's when you were dressed up nicely and I think they like the t-shirt. It's a nice t-shirt but not how we're usually hiding behind the attire. >> Truly >> Well. >> Clothes don't always make a demand. >> Gentlemen, I would like to say overall our winner today with five points is Corey. Congratulations, Corey. >> Thank you very much. It's always a pleasure to mop the floor with you Stu. >> Actually I was going to ask Stu to give the acceptance speech for you, Corey and, Corey, if you could give a few words of concession, >> Oh, that's a different direction. Stu, we'll start with you, I suppose. >> Yeah, well, thank you to the audience. Obviously, you voted for me without really understanding that I don't know what I'm talking about. I'm a loudmouth on Twitter. I just create a bunch of arguments out there. I'm influential for reasons I don't really understand. But once again, thank you for your votes so much. >> Yeah, it's always unfortunate to wind up losing a discussion with someone and you wouldn't consider it losing 'cause most of the time, my entire shtick is that I sit around and talk to people who know what they're talking about. And I look smart just by osmosis sitting next to them. Video has been rough on me. So I was sort of hoping that I'd be able to parlay that into something approaching a victory. But sadly, that hasn't worked out quite so well. This is just yet another production brought to you by theCube which shut down my original idea of calling it a bunch of squares. (Rachael laughs) >> All right, well, on that note, I would like to say thank you both Stu and Corey. I think we can close out officially the debate, but we can all stick around for a couple more minutes in case any fans have questions for either of them or want to get them-- >> Find us a real life? Yeah. >> Yeah, have a quick Zoom fight. So thanks, everyone, for attending. And thank you Stu, thank you Corey. This has been The Great Cloud Debate.

>>Live from Las Vegas. It's the cube covering UI path forward Americas 2019 brought to you by UI path. >>Welcome back to Las Vegas. Everybody, you watching the cube, the leader in live tech coverage. We go out to the events, we extract the signal from the noise. Ahmed Zion, he is here, he's the chief automation officer at accelerate a specialist service provider in this area of RPA in Armando Lambert is the vice president of enterprise optimization governance and risk guys. Oh sorry. At Bayview asset management in Miami. Welcome to the cube criminal. Thank you for that. So Bayview, you've got a good view of the Bay and Miami, is that kinda where the name comes from or the beautiful place to work happening with UI path forward to was in Miami at the Fontainebleau back here in Vegas. But um, so let's get into it. I met um, chief automation officer. That's kind of a cool title. I don't see that a lot. What's that entail? And tell us about accelerate. >>So accelerate at accelerated where one of the largest nice providers is the only thing that we do a process automation and AI company. And our sole focus has been process automation since our inception and our past lives were generalists. We did well and wanted to do it again. Uh, so when we started accelerate, we wanted to make sure that we focused on a very specific vertical niche and process automation was just starting up the uptick about mid 2016 ish. >> So there's gonna be some interesting conversations around process automation is like had an analyst on yesterday, they predicted RPA is dead, you know, process automation lives. You know, it's kind of a tongue in cheek thing. So maybe we can talk about that a little bit, but Amando tell us about your role and a little bit about Bayview. So Bayview is an asset management company, primarily whole loans, mortgage back securities, mortgage servicing rights. >>We offer service advisory as well as investment vehicles. My role basically is to strategize, innovate, look at new technologies, new ways of streamlining the business. Um, and you know, about in 2016, you know, we were faced with the challenge and the challenge was we have a lot of road swiveled to chair type work, back office, operational work. Um, and I went in there just trying to look at people, processes and systems and trying to figure out a way to make things more efficient. And you know, RPA is one of those vehicles. Okay. So smart. You started with people in process, you didn't start with the technology. Yeah, absolutely. Right. So what did you learn? I mean, take us back to 2016 when you started to do the investigation, you started unpack the processes and the people. What did you see and then what led you to RPA? >>Yeah, I mean, I think inherently you're, you're, there's a lot of business processes that are just brought down through years of just being kind of entrepreneurial and doing a lot of business. So a, of these prices of processes early on we felt like we can just go in and automate and we realized that just needed a level of process optimization first. Um, so in doing that, it just kind of directs the vehicle right into what type of automation you need to do. It's not always RPA. RPA is big, a big component for us. Um, it works for us. Early on we wanted to put a strong governance structure. I strongly believe that, you know, and it's worked out so far for us. >> So you, you brought in accelerate, you brought in an outside firm to help you with that process automation, is that right? Absolutely. >>So tell us more about how that all went down. So that was, that was an interesting, um, interesting time, right? The, these products were coming up. Nobody really knew how well they work. And so we went in and we actually did proof of value, right? We said, Hey, this is all well and good. Let's do a proof of concept that a proof of value at that time, proof of concepts really were a thing. I don't, I don't think we should do them anymore. We should only do proof of values. But we went in, looked at the various systems they had, tried it out so he could demonstrate it to his management that this thing works. And as soon as that was over, I think I'd given to her, Armando, here we went all in, right? We said, all right, let's look at the highest value things. >>Let's deliver this. Um, let's figure out a governance model. Let's, let's not, let's not hold it back like we, like we have done in the past. It project spinning up. So let's get the infrastructure up and running very quickly. Let's get, let's get a few automations out there. Some of the business sees the value right away, right? Crawl, walk, run. We can do this. You know, what are we going to automate and what do we need from it and how are we going to govern this? These are the three pillars that I see that I suggest everybody look at it. And we did that in parallel parallel streams and all three of them. And within a few months he was able to return a significant value back to the business, which has led to adoption. I think, I think that has been a very big reason why he's been able to scale because he was able to show early value back to the business very quickly focusing on value rather than the technology or the underlying solution. >>Right? It's um, a lot of times we see folks going into RPA saying, what can RPA do for me? I think that is the wrong question. Um, the question really is what do you do? Let's classify what you do in manual mechanical work, intelligent work and wasteful work, right? And then look at your toolbox. I have RPA, I have AI, I have other technologies that within an enterprise folks are working on, and then apply those to it. RPA becomes the glue for most of these things. You have API as SDKs. You have AI technologies, be it cloud or on prem. RPA becomes the glue and it becomes easy to deploy once you figured out what all the different pieces are. But it's important to look at the process first and say, what? What do you do? So when the business comes back and say, what can you do for me with RPA? >>I said, no, I don't know. What can you do for, with the, I don't know. Tell me what you do and then I'll tell you what the solution is. So mono, given that you started with the value, did that ease some of those potential friction that you sometimes see with change management or change in general? Or did you still see that resistance? And I'm interested in where you started, what were some of those high value areas that you attack but, but the cultural piece first if you will. Yeah, I mean a lot of marketing, you know, it's really what it comes down to trying to prove to the Csuite and managing director areas. Like this is a value proposition. You know, early on, you know, we did a lot of presenting roundtables, luncheon learns with the business. You know, because there is some resistance early on. >>I think everybody has a misconception that it's going to take their jobs where I believe it's gonna create a lot more jobs in the future. Um, for me it was always a scalability play. You know, how can our business do more for less? And that's really what we really wanted to get to. Throughout that journey. We realized there's a lot of benefit, especially for companies that have a heavy back office operations. Um, and we just started, like I mentioned there, we started slow. I didn't want to boil the ocean. I knew I needed to prove to leadership that this works. And I think about three years ago, we all kind of felt, is this going to stick? You know, we've seen technology, I've been in technology for over 20 years and you know, some things fly, some things don't. Right? So we wanted to prove that it worked. >>And you know, the industry just kind of surrounded itself around that. And look where we are now. I think everybody's putting a lot of money in their budgets for, you know, intelligent automation, not just RPA. So the initiative was kind of middle up to the C suite and then top down. Is that how it, absolutely. I'm a firm believer the tone needs to come from the top. It has to come from the top. And you know, luckily for me, I have great leaders in our company. Um, they understood the vision, they understand what, what it could potentially mean for their business. They just needed someone to help execute it. So what kinds of things did you start with? There was a lot of sort of manual form filling out or some of that, uh, you know, data extraction from PDFs using, utilizing OCR, you know, RPAs great to gather and collect data so that they can put it in their models and make more informed decisions. >>Uh, claims processes, you know, dealing with different agencies. So, you know, early on in adopting UI path, there were some limitations. We worked around that. Now it's pretty much limitless and they could touch any system, any technology, any process. So yeah, it's growing tremendously. And in terms of just ensuring governance and compliance as you scale, you have robots doing that. Um, how do you tell me what we're working more and more. I mean, I think regulators now realize, okay, you're removing the human element, right? So, you know, that's a big value as well. Or sampling. Now you're not limited to what you can sample. You can sample 100%, you know, so those are big values and when you speak to regulators, they really understand that I would say five years ago, I'm not so sure. Um, but now they welcome it. And I think a lot of the government agencies now are, are adopting RPA. >>Uh, so it's, it's a good story. Well, automation kill sampling is that I think it is absolutely right. The point actually interesting point that you made, right? Uh, the regulators or the auditors or for that matter, the security and the compliance guys inside the enterprise have this. So this term of the bot, right has this connotation of Terminator and I keep telling him, no, this is that thing. You buy a target that does this. I press the right button, it goes right up, press the left button, mil goes left. It just doesn't think on its own. And I think that conversation is very important, right? Once you have that conversation with the security and the compliance guys to say, this is a bot, it only does what you ask it to do. You could put a social security number in front of this guy all day long in front of this user ID all day long. >>It just doesn't know what to do with it. Won't ever read it. And once they realize that they, the, the conversation changes, um, you know, especially when it in compliance and audit, right? Uh, the compliance officers would love this. Once you tell them there's a lot of decision making that happened in people's heads or Excel spreadsheets that never made it to systems and was never logged. So you'd get something in you massage that, you did that, and you put that in the system. That decision making is now auditable. So you can go back and say, here was the input, here was the massaging of it. Here's what went into the system of record after it came in. So that I think, I think those conversations early on really helped this scale in an age old problem and tribal knowledge. Exactly. You know, Joe has his spreadsheet and Fred knows the Joe has the spreadsheet. >>So when Joe leaves, he has to get the spreadsheet back. And that's kind of this perpetual thing. How much of what you guys did, Armando was processed re-engineering versus just applying automation at some low hanging fruit. Um, I think looking back now it's about a 50, 50 split. Um, you know, there are some areas that have robust processes and that makes our life easier. We can just kind of go in, map it out, look at the automation future state and deploy, develop and deployed. Uh, you know, some areas, you know, they inherit processes and they don't always just so busy doing their day jobs and they don't always realize there's, there's room for efficiency in their process. So, you know, early on when we priced out how much this would cost, how much development it would be, we didn't always factor in that it would be a 50, 50 split and doing a lot more process improvement in the beginning. >>Um, we've now counted for that. So absolutely. It's about a 50, 50 split. Craig LeClaire this morning said something that, you know, I was an analyst and he says, very, you know, very analyst's sort of savings. You've got to stop worrying about the ROI, you know, focus on the more strategic stuff. Every analyst sort of says that. But yeah, there weren't a lot of CFOs too. And they're like, where's the ROI? So you know, you're in the services business, you know, you have to have ROI dollars matter. Absolutely. So you obviously measure ROI. How do you look at it? You know what you said earlier, you're not cutting jobs, right? But so what do you tick? How do you measure kind of the, the value, the ROI? I mean, you know, giving the end user a little more to think about, right? Giving them the opportunity to, you know, do more, be more thoughtful in what their day to day job is rather than doing the swivel chair type work. >>So, you know, the measurement, the beauty around RPA is it's very quantifiable. You know, unlike some traditional it systems, you really can, the data doesn't always kick back. You know, all our, our, our own bots, all our processes kickback, they give us data that we can quantify, um, metrics on, on, on volume versus man hours. This is all information you capture early on. You need to do this at the discovery stage and we train. We have a robust training program for our business analysts and program managers and developers and they're always, that's the question they ask every time. It's not just about what is your process, your cute future, current state, future state, and it's like, how many limit? Let me look at your historical trending. What are their volumes look like? You know, our business is very cyclical. It goes up and down, and when I mentioned I want them to be scalable and have more capacity, that's really the play for me. >>For me, it's never been an FTE. I get it. It may come from the Csuite, but like I said, the tone from the top has been solid. Their vision is more about, Hey, when it's cyclical and it goes up and down, we need to be able to do more. We need to be able to scale. Have you been able to measure productivity improvement? Absolutely. Absolutely we have. If you had a Mulligan, what would you do differently? A good question. I mean, I think we factored early on, I mentioned this early on how much process improvement was needed. I think we undervalued that. And um, you know, every business faces the same challenges, right? They, you know, everyone feels like they're doing the right thing. These processes are inherited. You know, regulations change, investors change. There's new business rules every day, you know, and you kind of need to sit back as a business user every now and then and refresh that. >>And um, you know, we didn't account for that early on. We're helping the business do that. Our business is fantastic. They bought into the program and it's like having additional workforce working on your side. You know, Daniel Dienes in his keynote last night, basically sending them pick up on something you guys said is, is, um, he really appreciates those customers who took a chance early on. He goes, because frankly, our product wasn't, you know, fully, fully baked out. And I was like, wow, what an honest statement from a CEO. You don't usually hear that. My sense is that they got it right. You path. And I'd love your comments. In the sense that they attack, they went after simplicity and said, okay, make it easy to adopt and then we'll figure it out. And then, you know, bringing in the functionality is that, is that kind of what happened or picking up on Daniel? >>And by the way it was, it's amazing. Humility really comes through, right? So I saw him 2016 standing on stage and when my partner came to us for the idea of saying, Hey, we're going to do, we should do this RPA thing. Now I'm giving away my age. But 1998, my first job, I was sitting in front of the computer and Prudential and they put this software in front of me. It was called SQA robot. It was a test automation tool. It was called SQL robot. Uh, why that relates to Daniel is he's had a, came on the stage in the IRPA conference in 2016 if remember, I love this presentation just to blues black thing and few words on it. He goes, let's not kid ourselves. We have this very traditional, you know, QA automation technology that we think can do something really super. >>And I have built a product on top of that, but there's, there's not a lot of magic in here yet. Right. So that's, but, but I think the, the, the great thing about you I've had has been the vision, right? The vision has been, and if you saw yesterday they started with the core and unlike some of the other vendors, they said, we're just going to do RPA really well. We're not going to go into the OCR market. We're not going to try to build AI things. Let's make sure that our core RPA, so you know, you want to go, you're an enterprise, you want to do OCR, you're not going to buy it from an RPA company. You want to buy it from somebody who's been doing it for 30 years or we just has that sole focus. I think you'll have had had that sole focus. >>But as I've seen in the past three, four years, they've just done a great job with the, with the full vision, right. Starting from, they started with the middle of the core of the product and they said, okay, let's go towards the business and see what the business needs with, you know, planning of their, um, of their automations on and so forth and going further to the right to say, let us enable the technology guys who actually implement this to give them the tools and the integrations they need to, to actually make this routed to full product. Um, I think it's a very good question when people say, what can you do with RPA for me? So I said that answer was very different three years ago than it is today. Right? Some of the things are coming out of the box with these. So I, I, I predict that in the next few years, document understanding and natural language and all of that will just be built in today's still very sort of clunky in terms of how you do it. >>But I think those things are coming, coming together. So looking at processes that way is really important. It's a lot of runway for this. Margaret, Armando, I'll give you the last word. Where do you see are RPA or intelligent automation going in, in your organization? Is it still early days you had a lot more adoption or you're pretty much, you know, settled? No, definitely not settled. Um, I think it's, you know, RPA is just one of the tools in the spectrum of intelligent automation. So more integration, more API APIs, a lot of machine learning, uh, eventually some AI. Um, so yeah, we are not slowing down. There's a lot of opportunity. My mandate as I mentioned before, is just scale, scale, scale. So you know, the process is working. We have a good program in place. We'll continue marching forward. Great guys, thanks so much for coming. Thank you for sharing your story. Thank you for watching. From right back with the cube. Live from UI path forward three in Las Vegas. Right back.

>> from San Matteo. It's the Cube covering scaler. Innovation Day Brought to You by scaler. >> Welcome to this Special Cube Innovation Day. Here in San Mateo, California Scale is headquarters for a coast of the Cube. We're here with two great guests. Claudia Carpenter co founder Andy McAlister, Who's Dev evangelist? Uh, great to have you guys here a chat before we came on. Thanks for having us >> Great to be >> so scaler. It's all about the logs. The answer is in the logs. That's the title of the segment Them. I'll see the log files with a lot of exhaust in their data value extracting that, but it's got more operational impact. What's what's the Why is the answer in the locks? >> Because that's where the real information is. It's one thing to be able to tell that something is going around when your systems, but what is going wrong as engineers, what we tend to do is the old print. If it's like here's everything I can think of in this moment and leave it as breadcrumbs for myself to find later, then I need to go and look at those bread crumbs >> in a challenge. Of course, with this is that logs themselves are proliferating. There's lots of data. There's lots of services inside this logs, so you've gotta be able to find your answers as fast as possible. You can't afford Teo. Wait for something else. T lead you to them. You need to deep dive >> the way you guys have this saying it's the place to start. What does that mean? Why? Why is that the new approach? >> What We're trying to differentiate because there's this trend right now in the Dev Ops world towards metrics because they're much smaller to store it, pre digesting what's going on in your systems. And then you just play a lot of graphs and things like that. We agree with that. You do need to be able to see what's going on. You need to be able to set alerts. Metrics are good, but they only get you so far. A lot of people will go through. Look at metrics, dig through and then they stop, switch over and go to their logs. We like to start with the logs, build our metrics from them, and then we go direct to >> the source. I think a minute explain what you mean by metrics, because that has multiple meanings. Because the current way around metrics and you kind of talked about a new approach. Could you just take a minute? Explain what you meant by metrics and how logs are setting up the measures. The difference there. >> So to me, metrics is just counting things right? So at log files of these long textual representations of what's going on in my system and it's impossible to visually parce that I mean literally 10,000 lines. So you count. I've got five of this one in six of this one, and it's much smaller to store. I've got five of this one and six of this one, but that's also not very much information, so that's really the difference. >> But, you know, we have customers who use their metrics to help them indicate something might be wrong inside of here. The problem is, is that modern environments where we have instant gratification, needs and people you know, we'd be wait five seconds. Basically, it's a law sale online here. You need to know what's went wrong, not just where we went wrong or that something went wrong. So building for the logs to the metrics allows you to also have a perfect time back to that specific entrance ancient entrance that lets you be you out. What was wrong? >> He mention Claudia Death ops. And this is really kind of think of fun market because Dev Ops is now going mainstream and see the enterprise now started to adopt. It's still Jean Kim from Enterprise. Debs estimates only 3% of enterprise really there yet. So the action's on the cloud Native Public Cloud side where it's, you know, full blown, you know, cloud native more services. They're coming to see Cooper Netease things of that nature out there. And these services are being stood up and torn down while the rhythmically like. So with who the hell stores that data? That's the logs. The nature of log files and data is changing radically with Dev ops. I'm certainly this is going to be more complications but developers and figuring out what's what. How do you see that? What's your reaction to that trend? >> Yeah, so Dev Ops is a very exciting thing. At were Google. It was sort of like the new thing is the developers had to do their own operations, and that's where this comes from. Unfortunately, a lot of enterprise will just rename their ops people devil apps, and that's not the same thing. It's literally developers doing operations, Um, and right now that it's never been so exciting as as it is right now in the text axe, because you could get so much that's open source. Pre built glue this all these things together. But since you haven't written the code yourself, you've no way deal which going on. So it's kind of like Braille. You've got to go back and look and feel your way through it to figure out what's going on. And that's where logs come into play. >> The logs essentially, you know, lift up, get people eyesight into visibility of things that they care about. Absolute. So what's this red thing? Somebody read what is written? Rennes. >> One of the approaches. You'll hear things like golden signals. You'll hear youse, and you'll hear a red Corvette stands for rates, a rose and duration. And ready is a concept that says, How do you actually work with some of these complex technologies working with you're talking about and actually determined where your problems are. So if you think about it, rate is kind of how much traffic's going through a signal for this as a metric, it's accumulative number. So to back to Claudia's point, it's just number here. But if you're trapping goes up, you want to know what's going wrong here is self explanatory. Something broke, fix it, and then duration is how long things took. You talked about communities, Communities works hands in hands with this concept of micro services. Micro services are everywhere, and there were Khun B places that have thousands of little services, all serving the bigger need here. If one of them goes slow, you need to know what went slow as fast as possible. So rate duration and air is actually combined to give you the overall health of your system. While at the same point logs elect, you figure out what was causing >> the problem we'll take. I'm intrigued by what Claudia said. They're on this. You know, Braille concept is essentially a lot of people are flying blind date with what's going on, but you mentioned micro services. That's one area that's coming. Got state full data. Stateless data. They were given a P I economy. Certainly a state becomes important for these applications. You know, the developers don't may or may not know what's happening, so they need to have some intelligence. Also, security we've seen in the cloud. When you have a lot of people standing up instances whether it's on Amazon or other clouds, they don't actually have security on some of their things. So they got it. Figure out the trails of what the data looks like they need the log files to have understanding of. Did something happened? What happened? Why? What is the bottom line here? Claudia? What what people do to kind of get visibility So they're not flying blind as developers and organizations. >> Well, you gotta log everything you can within reason. They always have to take into account privacy and security. But logs much as you can and pull logs from every one of the components in your systems. The micro services that day was just talking about are so cool. And as engineers, we can't resist them way. Love, complexity >> and cool things. >> Things especially cool things and new things. >> New >> green things. Sorry, easily distracted. But there they are, harder to support. They can be a really difficult environment. So again it's back to bread crumbs, leaving that that trail and being able to go back and reconstruct what happened. >> Okay, what's the coolest thing about scaler since we thought about cool and relevant? You guys certainly in the relevant side thing. Check the box there. What's cool? What's cool about scaler telling us? >> That's great. Answer What isn't. But you know, honestly, when I came to work here, I no idea I was familiar with Log Management was really with long search and so forth. And the first time I actually saw the product, my jaw dropped. Okay, I now go to a trade show, for instance, and I'm showing people to use this. And I hit my return button to get my results. And you showed band with can be really bad and it stalls for 1/10 of a second, and I complain about it now. No, there is nothing quite as thrilling as getting your results as fast as you can think about them. Almost your thought processes the slow part of determining what's going on, and that is mind boggling. >> So the speed is the killer. >> The speed is like what killed me. But honestly, something that Chloe's been heavily involved in It takes you two minutes to get started. I mean, there's no long learning curve there. You get the product and you are there. You're ready to go >> close about ease of use and simplicity, because developers are fickle, but they're also loyal. Do you have a good product? They loved to get in that love the freebie. You know, the 30 day trial, They'll they'll kick the tires on anything. But the product isn't working. You hear about it when it does work. This mass traffic to people you know pound at the doorstep of the product. What's the compelling value proposition for the developer out there? Because they >> don't want to >> waste time. That's like the killer death to any product for development. Waste their time. They don't want to deal with it. >> So we live in the TL D our world right now. Frankly, if I have to read something, I usually move on on DH. That's the approach we take with scaler as well. Yes, we have some documentation, but I always feel like I have failed with the user interface design. If I require you to go read the documentation. So I try to take that into account with everything that we that we put out there making it really easy and fast it just jumping in, try stuff. >> How do you get to solve the complex complexity problem through attraction software? What's the secret sauce for the simplicity of this system? >> For me, it's a complete lack of patients. It's just like I wouldn't put up with that. I'm not gonna ask you to. Frankly, I view this sounds a little bit trite, but I've you Software's a relationship, and I view whoever is looking at it as a peer of mine, and I would be embarrassed if they couldn't figure it out if it wasn't obvious. But it is. We do have this sort of slope here of people who really know what's going on and people wanna optimize. This is your 80 20 split on people that don't know what just want to come in. I want both of them to be happy, so we need to blend those >> to talk about the value proposition of what you guys have because we've been covering you know log file mentioned Lock Management's Splunk events. We've gone, too. There's been no solution that I think may be going on 10 years old, that were once cutting edge. But the world changes so fast with Amazon Web services with Google Cloud with azure. Then get the international clouds out there as well. It's it's here. I mean, the scale is there, you got compute. You got the edge of the network right around the corner in the data problem's not going away. Log files going be needed. You have all this data exhausted, these value. >> If anything, there's always going to be more data that's out there. You're going to have more sources of that data coming in here. You're talking a little bit about you have the hybrid cloud. Where's part on prom? Part in the cloud. You could have multi clouds where across his boundaries. You're gonna have the wonderful coyote world where you have no idea when or where you're going to get an upload from too. This too and EJ environment. And you've got to worry about those and at the same time time, the logging, everything, the breadcrumbs. You have ephemeral events. They're not always there, and those are the ones that kill you. So the model is really simple and applaud Claudia for conning concept wise. But you're playing with concept of kiss, right? We'll hear its keep it simple and sophisticated at the same time. So I can teach you to do this demo in two minutes flat, and from there you can teach yourself everything else that this product's capable of doing it. That simple >> talk about who? The person out there that you want to use his product and why should they give scale or look what's in it for them. >> So for me, I think the perfect is to have Dev ops use it. It's developers. We really have designed a product less for ops and more for engineers. So one of the things that is different about scaler is you have somebody come in and set it up, parsed logs that ingestion of logs, which is different than splunk and sumo on DH. Then it's ready to use right out of the box. So for me, I think that our sweet spot, his engineers, because a lot of our formulations of things you do are more technical you're thinking about about you know what air the patterns here. I'm not going to say it's calculus, because then that wouldn't be simple. But it's along. Those >> engineers might be can also cloud Native is a really key party. People who were cloud native. We're actually looking at four in the cloud or cloud migration, >> right way C a lot. For instance, in the Croup. In any space from the Cloud Native Compute Foundation, we're seeing a tremendous instrument interest in Prometheus. We're seeing a lot of interest in usto with service mesh. The nice thing is that they are already all admitting logs themselves. And so, from our viewpoint, we bring them in. We put them together. So now you can look at each piece as it relates to the very other piece >> Claudia share with the folks who, watching this just some anecdotal use cases of what you guys have used internally, whether customers that give him a feel for how awesome scaler is and what's the what could they expect? >> Well, put me on the spot here. Um, >> I'll kick off. So we have a customer in Germany there need commerce shop, They have 1,000 engineers for here. When we started the product we replace because it was on a charge basis that was basically per user. They came back and they said, Oh my God, you don't understand our queries Air taking 15 minutes to get back By the time the quarry comes back, the engineer's forgotten why he asked the question for this. And so they loaded up. They rapidly discovered something unique. It's that they can discover things because anyone can use it. We now have 500 engineers that touch the log files every day, I will attest. Having written code myself, nobody reads log files for fun. But Scaler makes it easy to discover new things and new connections. And they actually look at what house >> discoveries of real value, proper >> discovery is a massive value proposition. Uh, where you figure out things that you don't know about back to that events thing that Claudia started about was, you can only measure the events that you can already considered. You can't measure things that didn't happen >> close. It quickly thought what the culture on David could chime in. What's the culture like here scaler? >> It is a unique culture and I know everyone probably says that about their startup, but we keep work life balance as a very important component. We're such nerds and unabashedly nerds. Wait, what we do. It's a joyful atmosphere to work in. Our founder, Steve Newman, is there in his flat, his flannel shirt, his socks cruising around. Um, and we are very much into our quality barcode. We have a lot of the principles of Google sort of combined into a start up. I mean to say it's a very honest environment, >> Sol. Heart problems make it a good environment. >> Yeah, and I value provide real values, are critical >> for me and have fun at the same point in time. The people here work hard, but they share what they're working on. They share information. They're not afraid to answer the what are you working on? Question. But we always managed to have fun. We are a pretty tight group that way. >> Well, thanks for sharing that insight. We have a lot of fun here in Innovation Day with the Q p. I'm John Furia. Thanks for watching

>> live from Boston, Massachusetts. It's the queue covering your red. Have some twenty nineteen brought to you by bread hat >> and welcome back to the Red Hat Summit. We're live in the B, C, E C, the Boston Convention and Exposition Center, along with two metal men. I'm John Walls were joined by Stephanie Cheer us. Who is the vice president? GM and Red had Enterprise. Lennox? Yes. Good to see here. >> Nice to see you teach >> back in Boston, right back >> in Boston. Home turf. >> You feel at home here? I would give you a big day for you. Right. Relic comes out generally available now a big impact on the marketplaces. Talk about that baby that you've given birth through here today. >> Wear so excited and, you know, having put in all the time. Part of this is representing all the work the team has done and the communities have done. When you think about all the work that goes into a Lennox distribution, it is everybody. It's the communities, It's the partners. So we released the Red Hat Enterprise Lennox eight beta in November mid November. We've had forty thousand downloads of that beta since November. People who have provided feedback and comments, suggestions, all of that fed into what we've released today as the Red Hat Enterprise Lennox eight. General availability. So it's a big day, and part of it is we're just so proud of how we've done it and what we've done. And we've really redefined what are not the value of an operating system with Red Hat Enterprise on its eight >> Dannic students, even saying earlier. Excuse me still, but you're saying there's many years in the making, right? Twenty fourteen It was That was the last was when. Seven. >> That's right. It's been five years. >> And so Hobart Theatre, editor of Process That You went through especially, you know, through that beta stage of a little interested in that are a lot interested in that. In terms of of the changes that were still made at that time that once you heard from users and actually put it into practice, >> yes, so we one of the things that part of our subscription model is getting feedback from customers. It's critical for us and tow advocate for those asks upstream because, of course, everything we do is done upstream. So this is part of the way we build, I would say relate was quite different in the sense that I focus all the features and functions we put into it into two pockets. We wanted to make sure that it helped customers with all the changes that have happened in the industry, helped them run their business better. So things like, Is it hard to find Lenox skills? How did we build a Web console to make that easier? Is it hard to orchestrate a data center? We put in a new capability that's a rules based engine, as a software is a service offering in every rail subscription that takes all that we have learned in the market to how to run an efficient Lennox data center. And it sends that out an assassin offering toe every rail subscription owner right that helps them be more efficient. And then there's the whole set of features and functions we put in to help customers grow the business things like container tooling so they can take that one step into containers right from the operating system. Application streams pull in new versions, so I look at everything we've done. Is it relate, really focuses on running the business better, more efficiently and helping grow the business. It's combination of those two things, and the feedback has been great, right? The relic Beta was great. Some tweaks, some tuning. Some. I like how this is too hard. Take out the friction. That's what we were working on since November. >> Stephanie. It is fascinating to me because, you know, I remember last year Saturn with the right hat team. They talked about just that. The amount of change that goes in tow. Lennox, you know, talk about, you know, it's twenty one point six million lines of code. Over the last two years, a third of the code base has changed, and it's something that you know, since it's open source. There's a lot of visibility by the community has been coming for years, yet something you've been working on for five years. We know how much change there's been in the industry. You just talk a little bit about how you balance those dynamics of, you know, that the caves of released cycle. I understand there's going to be a very systematic approach going forward, as how releases are how right that looks at things >> and and one of the roles that we see that we play in the industry is sitting between all the innovation and the outlook work that's being done in the communities and the enterprise, customers who need to know that they're going to run this hardware and it's gonna work. They're going to run this application and it's going to work, and we serve to bridge that gap in between. We advocate for our customers upstream. We make sure that innovation has tried true and tested by the time it reaches them in rail and we sit in that bridge. So to your point, we're constantly getting input from customers about things that are critical to them, things like life cycle capabilities. Now in an upstream community, they probably don't care about a ten year life cycle. But if you're running it on the floor of a data center, they do and we bridge that gap, feeding that back and forth, and it is a bit of a balance. We need to make sure we're pulling in the next generation of things that are important. But we're also protecting what's important to accustom, earthy, enterprise level and honestly stew. It's a constant given take and a constant balance. But, you know, there are a few things that we hold on principle one, it will always be upstream first to it will always serve our customers. In the enterprise. We do it on their behalf. So you know, the beauty of open source is everyone can play in the three million communities that exist in all of that innovation, the challenges everyone can play. So now how do you take that and run your business on it? That's where we come in. So this is why it's so important in this subscription, we constantly get that input from customers. >> Yeah, absolutely way. When we look at this face in the cloud world, I'm kind of used tto running on the latest and greatest on platform. Takes care of it. And as we you know, customer state, they're living in that hybrid and multi cloud world, and we need to bridge from the old. Okay, I'm running in minus two because I haven't finished testing it yet. I want to make sure I've got the latest security one of Les trois and care of the latest features. So I need to be ableto balance both of those, and it's challenging. >> It is challenging and to your point balancing, that is, you know, we had focused on relate because we really wanted to change the >> value. >> Um, but now moving forward, What we've heard from customers is it's a real business advantage for them to know when they're going to get a new release so they can time it with their hardware updates and their eyes. V update. So, as you mentioned as we head into rally, much more predictable life cycle will have minor releases every six months, major releases every three years. And, you know, as an engineer, you always say what I want to have this and I want to have this and and then sometimes it can divert your schedule. What we've heard from our customers is No, no, no. My schedule is really important. I need to plan. I need to predict. So now we put the schedule first. Going forward will put in everything we can into that version and prioritize what we can. But schedule became very important customers. So, to your point, predictable life cycle is important in relative, >> so huge impact in the business that way, you're giving them stability and certainty and predictability. Let's talk about the economic impact, if you will, because you did a fascinating study. I DC did it for you about this global economic impact that's being realised by rail. And the figures are there beyond impressive. They're staggering in terms of positive economic contributions. Wouldn't talk about that a little bit. >> Yeah, absolutely. You know, when I when I think about what we all want to do every day, we all want to have impact. It's not always easy to measure impact. And so when we worked with I D. C. And we asked them to go off and do this study, it really was about measuring and economic impact in the world, and I was even flabbergasted at the numbers. But if you look at all the applications and the software that run on rent had Enterprise Lennox, collectively, it will touch ten trillion dollars of business revenue this year. That's amazing. I think partly partly that speaks to several things. It speaks to the importance of Lennox and the market and where it stands with respect to being running core business and mission critical work made what dollars in sense touch, as well as where the new applications are being written. That's the importance of Lennox. I think it's also an astounding statement to say Lennox is built around an ecosystem. It's built by communities, and when you start to make that self sustaining, that's the kind of impact that it can have. But it's incredible. >> Yeah, I loved we had one of the customers we had already was DBS Bank, and they talked about the financial industry on DH. You know, security and innovation and helping to become a technology company themselves. And it's not sitting in a silo. And they had insourced rather than outsourced, and its partnership with Red Hat that that helps enable a lot of that transformation for, you know, company that people don't necessarily think of, you know, banking as you know, that driver of technology innovation, >> right? And when they looked at when they looked at for customers, for customers who use it just is, you say, because they kind of are now technology companies. How do they look at the value of rail? Roughly, it was about a fifty fifty split between savings and productivity, which feeds into savings and growth right, new revenue being driven. So it really ties back to clinics being Yes, what we run and how do we maximize efficiency for it? And yet how do we grow our business? So it's it's It's absolutely, I mean the use of the software that's being run on Red Hot enterprise Lennox will will reach economic benefits for those customers of a trillion dollars a year. That's huge. That's huge. So it's great. >> Yeah, So out of that ten trillion, I don't know if you could put it in the buckets if you can, but just or maybe the most impressive buckets, if you will, is it through efficiency is the truth time say, visit through better higher production? Uh, I mean, where are those big chunk gains being realised? >> So they provided a breakout of productivity and cost savings in the center and then revenue growth. And honestly, it's a fifty fifty split between savings and growth, and I think that's a huge statement, right about not only what can be done to do cost savings, because that starts to change the way you know everyone starts to think of. A commodity is no once I get into a commodity, I'm going to just save money, and I'm going to pull every cent out. But when its strategic, that's when you grow. And so to me, seeing a fifty percent split pea to and what I can save with it and what I can grow with it. The operating system is anything but a commodity, right? It's a complete strategic decision for a company. So it was great, >> right? So Stephanie would talk. Talk about economic impact. Something I always loved to talk about at this show is what's happening with jobs. Six year we've been doing this show in the early years. It was that Lennox operating model is just becoming pervasive. You look at what happened in the cloud, lookit what topping and software to find, whether it be networking or other piece of the environment. If you understand Lennox, chances are those operating models or what they're using in your that time to get up to speed on those new skills is going to be smaller, can talk about what you're seeing kind of thie ecosystem of jobs, not just, you know, red hat. You know the customers using it, but but even beyond. >> Yeah, so we see that. I mean that this study will show that but nine hundred thousand jobs are being driven by the rail ecosystem. That's massive. That's massive. And and while many of those companies air global, a lot of that is domestic. So I think that as we look at the skills group, that air moving forward and you look at even the operating system adoption and they're operating system adoption of Lennox and those skills customers right now are saying Lennox skills are hard to find. We're working to make it easier. But nine hundred thousand jobs, that's all. That's a lot of work being driven by this ecosystem alone. >> Well, you said jobs where you just talked about difficulty in some respects. What about educating the modern workforce or or an updated workforce? I mean, what kind of impact can you have on that? Or do you want tohave on that in terms of finding the right people in order to keep driving you forward? Because I think a lot of people share that concern is just coming up with that, that brain power, if you will, that that firepower to keep this innovative cycle to keep it rolling like it like it is. Where you going for that? How you doing that? >> You know, I think I think there's a couple. There's clearly things we can do in the product we added in something called Web Console. It's built off the upstream called cockpit, but it comes in and it is. You know, you can run your Lennox service now from your phone off of a Web portal, and it'Ll be shown in a demo tomorrow morning, which is is just the coolest toe Launch up your system Jets grade, and we worked very closely to make sure that the gooey and the feel and the way it was done with similar toe windows. Because many companies certainly have Windows installations, they have Lennox installations. The more we can make the most of the skills that customers have and be able to have that be cross compatible is really important, and clearly we have. The market has recognized the importance of developers not only as influencers but developed, but developing the next applications. What will come down the pipeline in? Let's face it, many customers, we're seeing all. I didn't know my developer was doing this, but they're coming in with real, you know, growth opportunities for the business. So we have really put in a play for developers. We have developer subscriptions that they can use. So a very focused effort with our team to reach out to the developers, make sure they have the tools they need, the capabilities they need. We've put in build a pod, man and scope eo right into the rail sub so that, you know, they can start to build their containers right from the OS. >> All right, So, Stephanie, we've talked a bunch about relate. And I know that Hunza session you're going to be in the keynote today. >> Yes. Give us >> a You know, a key nugget or two that, you know, it might be overlooked if if if you didn't shine a light on it, you know, love to get your take on what you're geeking out on when it comes to relate. >> Yeah, So I'm actually one of the things and and I know you'LL have a deep dive on this later. One of the things that I love about it is we have pulled in This relate launch is very much to me. A Portfolio launch Redhead is a portfolio company of enterprise software. It's not a product company. We're not just an OS company, although that's important. We're portfolio company. So what you'LL see in the relative announcement is really how it ties to the rest of the portfolio. Red Hat Enterprise Lennox Core OS As part of feeding into open shift, that's important. Having universal base image be the way we allow developers. We allow eyes ves to build containers that are ready to deliver that well experience on open shift Iran. Well, that's huge for us. Pulling in capabilities like management within sites, pulling that directly into every sub. Every rail. Six seven eight sub. Right to me, we've taken Rail eight is the first real step where we launch a product, but it's a portfolio launch. And, uh, and that's partly why it makes me so excited, right? I mean, being in relics like being being in all the products, that red hat, because where the foundation of it, that's what I hope people walk away feeling right that the OS is important and its core to the whole portfolio that red hat can deliver, >> but we look forward to the keynote tonight. Yes. You're gonna knock it out of the park as you always do. Thanks for joining us. And maybe if you have a little expertise on the side, give Brad Stevenson call Celtics coach. I think you could use a win right now. Every celtics on thin ice right now, but Red Hat very much Bruins once. All right? Okay. All right, >> I'll take it. >> It's a win, right, Stephanie? Thank you. Thanks, Joe. It's a pleasure to have you back with more for the redhead summit. You're watching the cue. >> How well

>> Live from Las Vegas. It's the cute covering knowledge sixteen Brought to you by service. Now here your host, Dave, Alon and Jeffrey. >> Welcome back to knowledge. Sixteen. Everybody, This is the Cube, Cuba Silicon Angles Flagship program. We go out to the events and we extract the signal from the noise We're here. This is Day two for us. Will be going wall to wall for three days. That knowledge sixteen hashtag No. Sixteen. Chris Beatty is Here's the CEO. Relatively new CEO. It's service now. Chris, Thanks for coming on the Cube. It's going to be here. So you are hosting the CEO Decisions event Yesterday >> I was an event. We had a lot of CEOs, a lot of energy in the room, you know, one of the main main themes. Wass. You know, technology change happens all the time, but really one of the leadership challenge is right and what courage is required of leaders to really break through the status quo and get to that next level. We talked a lot about the importance of getting the right culture right within it, and that's a and what it really means to have a service mindset right throughout the enterprise. And as our vocabulary becomes the same inside it and across all the departments, right, as a leader, how do you enact that change so really a lot about the human element, as opposed to, you know, the technology part of it? >> Yes. So a lot of discussions over the past several service now knowledge comes in one year, Frank said. He sort of threw down the gauntlet and CEOs. They have to be business leaders. No longer Is that just a technology roll? Others have come on. The Cuban said. Well, you know, CEOs role. They gotta choose. They're gonna choose a technical path or a business path or data path. Even Chief Date officer. What do you thoughts on the >> I mean, >> there's a >> lot of press about the role. The CEO, right? And if you go back years and anything from Seo's dead, it is a relevant right. It's going the way of the dodo bird. Teo CEOs Morse strategic than ever, disrupting and creating new business models. I think the answer is somewhere in between, and it's probably changes, you know, depending on the day of the week. Right. So CEOs have a base job which is running, you know, the technology infrastructure of any company running the applications. But I do agree with Frank in terms of CEOs up, leveling their responsibilities and taking on the responsibility for more. I could tell you what I take responsibility for, right And yes, it's I t. But the overall velocity of our business. How fast can we run with everything Hiring employees, closing our books. Every single process in the company is powered by an IT platform, right? And so high tea is really in a unique position, and it has a bird's eye view of the organization to really help. Dr Velocity and Velocity is everything. How can you outflank your competition? The other thing I see think CEOs need to take responsibility for is maximizing the productivity of every single employee in the company. Right now, if you take that on, you start to look at things a little bit differently. It's not about projects, it's really about outcomes. And you know what measurable things are we delivering? And last and certainly not least, I think, the responsibility for customer experiences again. Customer experiences are powered by platform CEOs have the ability that influence every single one of those experiences and make it great and more and more as we look towards the future with things like automated bots and augmented reality customer. Your actions are going to become human to platform, and that's going to increase its relevance in that >> so and thinking about CIA imperatives of, you know, the bromide of eighty percent of the dollars we spend is on keeping the lights on twenty percent of innovation of That's a real number, No, but nobody seems to argue with it. Yeah, you >> hear that number a lot, but I think the good organizations actually do measure that number so they actually they will know what their number is and that service. Now we've done a lot of work, so our ratio is actually sixty percent run the business forty percent on innovation, and we're driving that down. So it's uneven. Fifty fifty split. I think that where you don't want to go is spending too little time on what I call the utility computing because that's the fabric that gets work done right. It's everything from networking and email and all those basic services you still need to have. Those aren't going anywhere collaboration services. >> I'd like to split it up into a little finer grain. I wonder if you could comment run the business grow the business transformed the business. Now maybe you're maybe you're always transforming your business, I don't know. But in >> terms of have to be >> in terms of but specific spending on initiatives to transform the business is that a reasonable, reasonable way to look at your portfolio was >> absolutely right. And I think if you're not doing things that transform your business, you're you're not acting with enough urgency. So my view on it is identify the big rocks right that we need to knock down, make sure we make room for those, even if it's at the cost of the grow or run part of the budget. Because if you're not getting those things done again, back to that getting left behind things were moving too quick. You got to keep pace. So make room for the transformation somehow, and that means squeezing every bit of automation that you can. How did the run part of the business, which is something I've used service now for in my past. I used to be a customer. I bought the platform twice over before I joined the company, and we did it a lot, and I'm doing it now, now that I'm at service now, >> that's one of Frank's requirements to become a CEO. I think. How >> do you >> measure that? That split. You said you're sixty today. Like to be a fifty, a lot of CEOs going. I have no idea how to measure that. I look at my projects are, but guess how do you do it? >> And it's tough we actually use. Not surprisingly, are Ownit Financial Management module to do that. And so technology's technology would we take all of our G L data and we map it to a taxonomy of business services in certain business services we know are not transformative, but they're a run part of the business, and we do that mapping once than every month. We can look at actuals against it. We can look at our unit costs, but the other begin put his projects right, which is again also in our platform, so able to look at those two things together and data driven segmentation of our spend too many times I see ninety organizations. They do it as one time exercise as part of annual planning. Then they don't look at it again until the next year. Annual planning. But there's a lot of runway in between and decisions we're making every day, which you should be making based upon data. But instead you're doing on perhaps nine months ago information. >> So you essentially categorize the business process, the business services as run or Growler training farm and on an ongoing basis. >> Absolutely. And you do the math and the most dynamic part of it, his projects. So every one of our projects, when we look at our portfolio, we look at our project portfolio by business areas, the sales marketing HR finance so on. But then we also do categorize our portfolio by Is this just sort of keep the lights on activity? But it's a project we still need to dio, or is it growing the business in somewhere? Is it truly helping us transform the way we operate >> on reasonable people? Khun, sit down and agree on sort of what those look like and >> short, and we also adjust accordingly. Also, do a top down allocation of what percentage do we want to go into each bucket, and that's not the same for each area because different parts of our business are different maturity cars, different pressures on them. I wouldn't want to be very transfer meitiv with RGL, right? That's not an area I want to innovate on. But with our sales and marketing organization, absolutely. We want to be in high innovation. Hi, experimentation, whatever we can do to help dry. >> So that's a top down bottom up exercise with the executive team says Okay, >> sideways inputs from everywhere. You know, one of the things I think CEOs it is a coming to fund CEOs to dio is manage spend. But more importantly, where people spending their time right, that's inarguably a fixed costs. We have a set of people where they spending their time and are they spending their time on the right things? And if you get that right, the rest could get a lot easier. >> So Secretary Gates last night speaking Teo, you know, maybe roughly one hundred CEOs and your your CEO decisions Conference gave the thumbs down on consensus management, and I sense just a little bit of discomfort in the room because CEOs is a hard job. But you serve a lot of different masters if you will, and as well you've got heads of application development you got, you know, architects, you got the business to serve, and so there's a lot of consensus building. And so he got questions on How do you do it? What was your reaction to that? Your colleagues, You know, which >> one was your science? They asked him a question. And because he said Consensus building doesn't work into an outside person looking in, it would seem like by nature. Everything in the government is consensus oriented. He had a lot of examples actually, where he did things against his own team's conviction, but he felt like that change was necessary. So it's two things I think Dr Gates has dealt with monumental organizations, right? Texas A and M is the smallest organization of those the CIA and the D. O D. Department of Defense has three million people, so the scale is unlike what most enterprise CEOs are leaders have seen. So when when he talked about not being consensus oriented, he viewed it as a requirement, and I actually agree with him. If you're trying to disrupt the status quo, you can't be consensus oriented. I don't think you'LL move fast enough, and most of time you won't get very far. So I think it's incumbent upon leaders to be the ones that break the status quo and say, We've got to change. And But what? What Dr Gates did describe is that if people are informed about why, from their leader enough, even if they disagree, they can get on board. And he brought up numerous examples of where he had conversations with Congress and people within the d. O d about change. He wanted to drive, and even though they were very opposed to it, they got on board because they intellectually could understand why. And over time, he won over hearts and minds >> about your priorities. So you come in relatively new tow service now. So first of all first impressions, any any surprises, pleasant or unpleasant? And what your priorities. >> So coming in no surprises. I had had a lot of admiration for the company as a customer, and now that I'm here, I love the culture. The culture is very execution oriented, get stepped on, very customer focused. You know, when we when we talk about our go to market, we really talk a lot about what's going to be most important for our customers. What pressures are customers under what problems can be solved for him? It's really not a discussion around squeezing. You know, the maximum margin out of each customer, which I think is fantastic way drive pretty hard. But but we're also very team oriented culture, so that's been great. My priorities at service. Now, when I think about my six strategic themes that I'm focused on growth eyes hugely important that service now. Right now, it's a lot of time I spend, fails and marketing effectiveness and innovation. And what can we do to drive, help, drive growth from a night perspective? Working with our partner organization, helping our partners? I do business with us easier things like partner portals and things like that. Ah, velocity. I mentioned earlier driving velocity through every department at the Enterprise at service now and really maniacally going after business process automation. And the great thing is, we have a platform that makes it easy, right and Ivax full access to that platform. So self service catalogs and knowledge base, but really going department by department saying, How do we do that? Analytics. Obviously we want to continue to measure and improve our business. But we're starting to do a lot more with Predictive Analytics, right? And how can we use data to really predict next best actions in a variety of arenas? Uh, security is the gift that keeps on giving for every CEO never ending. It's >> just one of those things that'll Teo you got, you >> got, you got to accept it and then really focus on team, right? I think talent and team and culture hugely important. You could have the best plans, you know, on paper. But if you don't have the right talent and culture within your team to get it done, I don't think you're getting very far operational. Rigor is a big one for me and a Metrix based approach to managing our business and driving outcomes. So when I look at projects that I execute for the organization on time and on budget, that's fine. That's table stakes. Really. What I'm after is on benefit, right? Are we delivering the benefits that we said we were going to get? And last, but certainly not least a part of my job is now on now. What? What we mean by now? On now is me being our best in first customer. And that's a very strategic level, working with product management to help them, you know, with roadmap features and things like that that I think all of our CEO's would need also upgrading early. So hopefully we can iron out the bugs before all of our customers and then consuming our own your products and implement it internally, learning the lessons within our four walls that we can inform our fields they could help our customers. >> How about on benefit? What percentage of projects are on benefit? That's another one of these things. Seventy percent of the projects fail. It was a number one on the market research, even >> that even that's a problem that fail is identified as not being on time or on. But right now, I view that is interesting but not compelling. Are you delivering the outcome? And so we're early. I've only been at service now six months, but I know in the past, through rigor and even making it a metric that's important have gotten to an eighty five percent hit rate on benefit. Certainly you could do better, but some of the benefits we have realised, with our platform eighty three percent increase in productivity. Leveraging R R R R application, but examples outside of Ice D, where we've eliminated forty five hundred hours of work from our financial close by putting email and manual checklist on your platform. Eighty five percent reduction in time that we spent hours spent on on boarding new employees. I mean, the list goes on and on, but it's a requirement in my organisation. When you're doing a project, you gotta have an outcome and set an aspirational outcome. Because if you talk about ten percent improvement and anything, that's sort of easy to get it. If you tell yourself I need to get a seventy percent improvement, it forces you to really rethink things and think differently. And I think that's our job. Is leaders to set those set the bar really high and then sharp teams have the resources to go after it. >> So even if you're late and over budget, if you get that, I didn't say that I later over, but I was asked, so that's got three. So that's a that's a prerequisite to be on time and on budget, >> and we're not perfect, but our target is to be ninety five percent on time, ninety five percent on budget, knowing you're gonna have five percent, you know, wiggle room and ninety five percent on benefit. >> What is on. So when you talk to the board, switch topics about security, what should be on the CEO's checklist for communicating to the board about security? So So >> I think it's really about risk, right? And what risks do we think we have? What's the likelihood of those risks? And what's the plan to mitigate those risk? I don't think security should be talked about in a This is Donner. That's done because you're never really done right. It's risk management, and the bad guys continue to innovate faster than the good guys. So what's your current security posture? What's the state of your risks and how are you mitigating them and in what time frame you know the stuff about? You know, we have a deal. P. We have ideas. We have I ps. I mean, the list of acronyms is interesting at a more tactical level, but at a board level, I think it's really risk management. >> So I promise I wanted before Ortiz talk about mitigating risk. But is there a place for a narrative that says you'd only mitigate so much? You're going to get penetrated. It's how you respond absolutely is critical. And I can I, as the CEO can lead that response or whomever is the >> appropriate person? I think you you have to do everything you possibly can Teo secure your perimeter. But it's known that you are going to get breach. Just a fact. So then it really becomes How quickly can you identify the fact that you have anomalous activity happening on your network of data? How quickly can you mitigate it? And in the past, when I was at various sign JD issue, a lot of that was manual right You have. You know, you have a piece of bad malware on the Enterprise. You may even know what assets. Um, it's on where you think you know. Usually I think you know, and then you really find out later where it's gone. But tying those assets to risk meaning what? Business services, it is it my CFO's laptop? Or is it? You know, the the you know, the person in AP. So you treated a little bit differently. And is it the infrastructure that supports our badge reader? Or is it our ear piece system? Right, So that's the missing piece. And I do thank our security organization and our our business unit, Shawn, because they've actually built a solution. Help solve that where you can go from security incident. Piece of Alberto Asset to Business service to employ within minutes, which that used to be half a day, at least half a day is a long time in a security incident. >> Yeah, so there's that magic number of whatever it is two hundred five days to detect a penetration? Yes, very. Do you feel like your organization can compress that? Is that a viable metric to be focused on? >> It's certainly a viable metric to focus on in terms of knowledge, off again anomalous activity. I don't think we're near two hundred five days, but absolutely we are focused on it because we need to secure not only our data but the data that our customers in trust without trust, >> meaning you feel as though you could detect much in a much shorter time frame, and they have some interesting. You haven't depending >> on the wrist right? Without getting into a lot of the details. >> Yeah, So we'll see you. But implicit in that is that you have a sense of the value of your data, your assets your I p what you're saying you've got a pretty good visibility on. >> Is that right? Yeah, we d'Oh. We spent a lot of time making sure our security posture is solid again customers and trust us with their data. We take that responsibility very seriously. >> Not speaking for service now, but just general knowledge of your colleagues Do you feel as though the lack of ability to value data assets negatively affect people's ability? T appropriately spend resources >> on security? It's tough because one of the first things you need to do in security say, what do I need to secure first? And then you say, OK, well, that's my core. I pee. Where's my core I pee stored? I would argue that a lot of companies don't even know because it's scattered on different file shares and different servers, and then you don't know whether people are putting it on box or drop box or one of the many storied sites out there so keep key. First step, I think for a lot of organizations is really just getting a handle on where their I P is. >> Right? All right, Count Chris, Thank you very much. Appreciate you coming on last. Give the last word. Uh, knowledge sixteen for you. What's the kind of bumper sticker? Is the truck's pulling away from its been awesome. I mean, >> just talking with customers and fellow CEOs. You know, we're all in this journey together towards this service enabled enterprise, but it is about leadership and just courage to bust through this current status quo that were in within the enterprise to get to that next level of efficiency. >> Thanks a lot of fun. Well, congratulations on the new role on DH hosting at a hostel conference just caught the tail end of it. But it looked like great energy >> because a lot of >> had some really good discussions with some of your colleagues. So really great coming on. Thank you. Alright. Keep right there, buddy. That's the Cuba bit back from knowledge. Sixteen, Las Vegas. Right after this >> every once in a while.