>> Announcer: Live from Las Vegas, it's the Cube. Covering ServiceNow Knowledge 2018. Brought to you by ServiceNow. >> Welcome to day three of Knowledge18. You're watching the Cube, the leader in live tech coverage. Day three is when ServiceNow brings together its audience and talks about its platform, the creators, the developers, the doers get together in the room. Jeff Frick and I, my co-host, we've seen this show now, Jeff, for many, many years. I joked on Twitter today, it's not often you see a full room and this room was packed on day three. Unless Larry Ellison is speaking. Well, Larry Ellison is not here, but Pat Casey is. He's the Senior Vice President of DevOps at ServiceNow and a Cube alum, Pat, great to see you again. >> Absolutely, just glad to be back. >> So, my head is exploding. With all the innovation that's comin' out. I feel like I'm at a AWS re:Invent with Andy Jassy up on stage with all these features that are coming out. But wow, you guys are on it. And part of that is because of the platform. You're able to put out new features, but how's the week going? >> So far it's been great. But you're sort of right, we are super proud of this year. I think there's more new stuff that's valuable for our customers coming out this year than probably the three years prior to this. I mean you got the chat bot designer, and you got some great application innovation, you got Flow Designer, you've got the entire integration suite coming online, and then in addition to that you've got a whole new mobile experience coming out. Just all stuff that our customers can touch. You can go downstairs and see all that and they can get their hands on it. Super exciting. >> So consistent too with the messaging. We've been coming here, I this is our sixth year, with kind of the low-code and no-code vision that Fred had way at the beginning. To let lots of people build great workflows and then to start taking some of these crazy new applications like chat bots and integration platform, pretty innovative. >> Yeah, I think it's a mindset when you get down to it. I mean we, the weird failure mode of technology is technology tends to get built by by technologists. And I do this for a living. There's a failure mode where you design the tool you want to use. And those tend to be programmer tools 'cause they tend to get designed by programmers. It does take an extra mental shift to say no, my user is not me. My user is a different person. I want to build the tool that they want to use. And that sort of user empathy, you know Fred had that in spades. That was his huge, huge, huge strength. Among other things. One of his huge strengths. It's something that we're really trying to keep foreground in the company. And you see that in some of the new products we released as well. It's really aimed at our customers not at our developers. >> The other thing I think that's been consistent in all the interviews we've done, and John talked on the day one keynote one of his kind of three keys to success was try to stay with out of the box as much as you can as a rule, and we've had all the GMs of the various application stacks that you guys have, they've all talked consistently we really try to drive, even as a group our specific requests back into development on the platform level so we can all leverage it. So even though then the vertical applications you guys are building, it's still this drive towards leverage the common platform. >> Yeah, absolutely. And there is, what's the word I'm looking for? There's a lot of value in using the product the way it was shipped. For easiest thing is when it advances or when we ship you new features you can just turn 'em on, and it doesn't conflict with anything else you got going in there. There's always an element of, you know, this is enterprise software. Every customer's a little bit different. GE does not work the same way as Bank of America. So you probably never get away entirely from configuring, but doing the minimum that you can get away with, the minimum that'll let you put your business-specific needs in there, and being really sure of it, you need to do it, it's the right approach to take. The failure mode of technologists, the other one, is we like writing technology. So give me a platform and I'm going to just write stuff. Applying that only when it makes sense to the business is where you really need to be. Especially in this day and age. >> Well I wanted to ask you about that 'cause you guys talk about many applications one platform. But you used to be one platform one app. >> Pat: Yep. >> So as you have more, and more, and more apps, how are you finding it regarding prioritization of features, and capabilities? I imagine the GMs like any company are saying, hey, this is a priority. >> Sure. >> And because you have a platform there's I'm sure a lot more overlap than if you're a stovepipe development organization. But nonetheless you still got to prioritize. Maybe talk about that a little bit. >> Sure, you end up with two different levels of it though. At one level, you tend to want to pick businesses to go into, which you're aligned with the technology stack you have. I don't think we're going to go into video streaming business. It's a good business, but it's not our business. >> Too bad, we could use some of that actually. >> Well, maybe next year. (laughs) But when you get down to it we mostly write enterprise business apps. So HR is an enterprise business app, CSM, SecOps, ITSM, they're all kind of the same general application area. So we don't tend to have something which is totally out to lunch. But you're right in the sense that A, what's important to CSM might be less important to ITSM. And so we do prioritize. And we prioritize partly based on what the perceived benefit across the product line is. If something that a particular BU wants that five other BUs are going to benefit from that's pretty valuable. If only them, not so much. And part of it too is based on how big the BUs are. You know if you're an emerging product line you probably get few less features than like Feryl Huff. Like she has a very big product line. Or Pabla, he has a very big product line. But there's also an over-investment in the emerging stuff. Because you have to invest to build the product lines out. >> The other thing I think is you guys have been such a great opportunity is I just go back to those early Fred interviews with the copy room and the color paper 'cause nobody knows what that is anymore. >> Pat: Yep. >> But workflow just by its very nature lends itself so much to leveraging, AI, and ML, so you've already kind of approached it while trying to make work easier with these great workflow tools, but what an opportunity now to apply AI and machine learning to those things over time. So I don't even have to write the rules and even a big chunk of that workflow that I built will eventually go away for me actually having to interact with it. >> Yeah, there's a second layer to it too, which I'll call out. The workflows between businesses are different. But we have the advantage that we have the data for each of the businesses. So we can train AI on this is the way this particular workflow works at General Electric and use that bot at GE and train a different bot at maybe at Siemens. You know it's still a big industrial firm. It's a different way of doing it. That gives us a really big advantage over people who commingle the data together. Because of our architecture, we can treat every customer uniquely and we can train the automation for the unique workflows for that particular customer. It gives a much more accurate result. >> So thinking about, staying on the theme of machine intelligence for a moment, you're not a household name in the world of AI, so you've done some acquisitions and-- >> Pat: Yep. >> But it's really becoming a fundamental part of your next wave of innovation. As a technologist, and you look out at the landscape, you obviously you see Google, Apple, Facebook, IBM, with Watson, et cetera, et cetera, as sort of the perceived leaders, do you guys aspire to be at that level? Do you need to be? What's the philosophy and strategy with regard to implementing AI in the road map? >> Well if you cast your eyes forward to where we think the future's going to be, I do think there are going to be certain core AI services that they're going to call their volume plays. You need a lot of engineers, a lot of resources, a lot of time to execute them. Really good voice-to-text is an example. And that's getting pretty good. It's almost solved at this point. A general case conversational agent, not solved yet. Even the stuff you see at Google I/O, it's very specialized. It does one thing really well and it's a great demo, but ask it about Russian history, no idea what to talk about. Whereas, maybe you don't know a lot about Russian history, you as a human would at least have something interesting to say. We expect that we will be leveraging other people's core AI services for a lot of stuff out there. Voice-to-text is a good example. There may well be some language parsing that we can do out there. There may be other things we never even thought of. Maybe stuff that'll read text for you and give you back summaries. Those are the kinds of things that we probably won't implement internally. Where you never know, but that's my guess, where you look at where we think we need to write our own code or own our own IP, it's where the domain is specific to our customers. So when I talked about General Electric having a specific workflow, I need to be able to train something specific for that. And if you look at some other things like language processing, there's a grammar problem. Which is a fancy way of saying that the words that you use describing a Cube show are different than the words that I would use describing a trade show. So if I teach a bot to talk about the Cube, it can't talk about trade shows. If you're Amazon, you train your bot to talk in generic language. When you want to actually speak in domain-specific language, it gets a lot harder. It's not good at talking about your show. We think we're going to have value to provide domain-specific language for our customers' individualized domains. I think that's a big investment. >> But you don't have to do it all as well. We saw two actually interesting use cases talking to some of your customers this week. One was the hospital in Australia, I don't know if you're familiar with this, where they're using Alexa as the interface, and everything goes into the ServiceNow platform for the nurses. >> Yep. >> And so that's not really your AI, it's kind of Amazon's AI, that's fine. And the other was Siemens taking some of your data and then doing some stuff in Azure and Watson, although the Watson piece was, my take away was it was kind of a fail, so there's some work to be done there, but customers are going to use different technologies. >> Pat: Oh, they will. >> You have to pick your spots. >> You know we're, as a vendor, we're pretty customer-centric. We love it when you use our technology and we think it's awesome, otherwise we wouldn't sell it. But fundamentally we don't expect to be the only person in the universe. And we're also not, like you've seen us with our chat bot, our chat bot, you can use somebody else's chat client. You can use Slack, you can use Teams, you can use our client, we can use Jabber. It's great. If you were a customer and want to use it, use it. Same thing on the AI front. Even if you look at our chat bot right now, there's the ability to plug in third-party AIs for certain things even today. You can plug it in for language processing. I think out of box is configured for Google, but you can use Amazon, you can use Microsoft if you want to. And it'll parse your language for you at certain steps in there. We're pretty open to partnering on that stuff. >> But you're also adding value on top of those platforms, and that's the key point, right? >> The operating model we have is we want it to be transparent to our customers as to what's going on in the back end. We will make their life easy. And if we're going to make their life easy by behind the scenes, integrating somebody else's technology in there, that's what we're going to do. And for things like language processing, our customers never need to know about that. We know. And the customers might care if they asked because we're not hiding it. But we're not going to make them do that integration. We're going to do it for them, and just they click to turn it on. >> Pat, I want to shift gears a little bit in terms of the human factors point of all this. I laugh, I have an Alexa at home, I have a Google at home, and they send me emails suggesting ways that I should interact with these things that I've never thought of. So as you see kind of an increase in chat bots and you see it increase in things like voice-to-text and these kind of automated systems in the background, how are you finding people's adoption of it? Do they get it? Do the younger folks just get it automatically? Are you able to bury it such where it's just served up without much thought in their proc, 'cause it's really the behavior thing I think's probably a bigger challenge than the technology. >> It is and frankly it's varied by domain. If you look at something like Voice that's getting pretty ubiquitous in the home, it's not that common in a business world. And partly there frankly is just you've got a background noise problem. Engineering-wise, crowded office, someone's going to say Alexa and like nobody even knows what they're talking about. >> Jeff: And then 50 of 'em all-- >> Exactly. There's ways to solve that, but this is actual challenge. >> Right. >> If you look at how people like to interact with technologies, I would argue we've already gone through a paradigm shift that's generational. My generation by default is I get out a laptop. If you're a millennial your default is you get out your phone. You will go to a laptop and the same says I will go to a phone, but that's your default. You see the same thing with how you want to interact. Chat is a very natural thing on the phone. It's something you might do on a full screen, but it's a less common. So you're definitely seeing people shifting over to chat as their preferred interaction paradigm especially as they move onto the phones. Nobody wants to fill out a form on a phone. It's miserable. >> Jeff: Right. >> I wonder if we could, so when Jeff and I have Fred on, we always ask him to break out his telescope. So as the resident technologist, we're going to ask you. And I'm going to ask a bunch of open-ended questions and you can pick whatever ones you want to answer, so the questions are, how far can we take machine intelligence and how far should we take machine intelligence? What are the things that machines can do that humans really can't and vice versa? How will humans and machines come together in the future? >> That's a broad question. I'll say right now that AI is probably a little over-marketed. In that you can build really awesome demos that make it seem like it's thinking. But we're a lot further away from an actual thinking machine, which is aware of itself than I think it would seem from the demos. My kids think Alexa's alive, but my son's nine, right? There's no actual Alexa at the end of it. I doubt that one's going to get solved in my lifetime. I think what we're going to get is a lot better at faking it. So there's the classical the Turing test. The Turing test doesn't require that you be self-aware. The Turing test says that my AI passes the Turing test if you can't tell the difference. And you can do that by faking it really well. So I do think there's going to be a big push there. First level you're seeing it is really in the voice-to-text and the voice assistance. And you're seeing it move from the Alexas into the call centers into the customer service into a lot of those rote interactions. When it's positive it's usually replacing one of those horrible telephone mazes that everybody hates. It gets replaced by a voice assist, and as a customer you're like that is better. My life is better. When it's negative, it might replace a human with a not-so-good chat. The good news on that front is our society seems to have a pretty good immune system on that. When companies have tried to roll out less good experiences that are based on less good AI, we tend to rebel, and go no, no, we don't want that. And so I haven't seen that been all that successful. You could imagine a model where people were like, I'm going to roll out something that's worse but cheaper. And I haven't seen that happening. Usually when the AI rolls out it's doing it to be better at something for the consumer perspective. >> That's great. I mean we were talking earlier, it's very hard to predict. >> Pat: Of course. >> I mean who would have predicted that Alexa would have emerged as a leader in NLP or that, and we said this yesterday, that the images of cats on the internet would lead to facial recognition. >> I think Alexa is one example though. The thing I think's even more amazing is the Comcast Voice Remote. Because I used to be in that business. I'm like, how could you ever have a voice remote while you're watching a TV and watching a movie with the sound interaction? And the fact that now they've got the integration as a real nice consumer experience with YouTube and Netflix, if I want to watch a show, and I don't know where it is, HBO, Netflix, Comcast, YouTube, I just tell that Comcast remote find me Chris Rock the Tamborine man was his latest one, and boom there it comes. >> There's a school of thought out there, which is actually pretty widespread that feels like the voice technologies have actually been a bit of a fail from a pure technologies standpoint. In that for all the energy that we've spent on them, they're sort of stuck as a niche application. There's like Alexa, my kids talk to Alexa at home, you can talk to Siri, but when these technologies were coming online, I think we thought that they would replace hard keyboard interactions to a greater degree than they have. I think there's actually a bit of a learning in there that people are not as, we don't mandatorily, I'm not sure if that's a real word, but we don't need to go oral. There's actually a need for non-oral interfaces. And I do think that's a big learning for a lot of the technology is that there's a variety of interface paradigms that actual humans want to use, and forcing people into any one of them is just not the right approach. You have to, right now I want to talk, tomorrow I want to text, I might want to make hand gestures another time. You're mostly a visual media, obviously there's talking too, but it's not radio, right? >> You're absolutely right. That's a great point because when you're on a plane, you don't want to be interacting in a voice. And other times that there's background noise that will screw up the voice reactions, but clearly there's been a lot of work in Silicon Valley and other places on a different interface and it needs to be there. I don't know if neural will happen in our lifetime. I wanted to give you some props on the DevOps announcement that you sort of pre-announced. >> We did. >> It's, you know CJ looked like he was a little upset there. Was that supposed to be his announcement? >> In my version of the script, I announced it and he commented on my announcement. >> It's your baby, come on. So I love the way you kind of laid out the DevOps and kind of DevOps 101 for the audience. Bringing together the plan, dev, test, deploy, and operate. And explaining the DevOps problem. You really didn't go into the dev versus the ops, throwing it over the wall, but people I think generally understand that. But you announced solving a different problem. 500 DevOps tools out there and it gets confusing. We've talked to a bunch of customers about that. They're super excited to get that capability. >> Well, we're super, it's one of those cases where you have an epiphany, 'cause we solved it internally. >> Dave: Right. >> And we just ran it for like three years, and we kept hearing customers say, hey, what are you guys going to do about DevOps? And we're never like quite sure what they mean, 'cause you're like, well what do you mean? Do you want like a planning tool? And then probably about a year ago we sort of had this epiphany of, oh, our customers have exactly the same problem we do. Duh. And so from that it kind of led us to go down the product road of how can we build this kind of management layer? But if you look across our customer base and the industry, DevOps is almost a rebellion. It's a rebellion against the waterfall development model which has dominated things. It's a rebellion against that centralized control. And in a sense it's good because there's a lot of silliness that comes out of those formal development methodologies. Slow everybody down, stupid bureaucracy in there. But when you apply it in an enterprise, okay some of the stuff in there, you actually did need that. And you kind of throw the baby out with the bathwater. So adding that kind of enterprise DevOps layer back in, you still do get that speed. Your developers get to iterate, you get the automated tests, you get the operating model, but you still don't lose those kind of key things you need at the top enterprise levels. >> And most of the customers we've talked to this week have straight up said, look, we do waterfall for certain things, and we're not going to stop doing waterfall, but some of the new cool stuff, you know. (laughs) >> Well if you look at us, it's at the, if you take the microscope far enough away from ServiceNow, we're waterfall in that every six months we release. >> Dave: Yeah, right. >> But if you're an engineer, we're iterating in 24-hour cycles for you. 24-hour cycles, two-week sprints. It's a very different model when you're in the trenches than from the customer perspective. >> And then I think that's the more important part of the DevOps story. Again, there's the technology and the execution detail which you outlined, but it's really more the attitudinal way that you approach problems. We don't try to solve the big problems. We try to keep moving down the road, moving down the road. We have a vision of where we want to get, but let's just keep moving down the road, moving down the road. So it's a very, like you said, cumbersome MRD and PRD and all those kind of classic things that were just too slow for 2018. >> Nobody goes into technology to do paperwork. You go into technology to build things to create, it's a creative outlet. So the more time you can spend doing that, and the less time you're spending on overhead, the happier you're going to be. And if you fundamentally like doing administration, you should move into management. That's great. That's the right job for you. But if you're a hands on the keyboard engineer, you probably want to have your hands on the keyboard, engineering. That's what you do. >> Let's leave on a last thought around the platform. I mentioned Andy Jassy before and AWS. He talks about the flywheel effect. Clearly we're seeing the power of the platform and it feels like there's the developer analog to operating leverage. And that flywheel effect going from your perspective. What can we expect going forward? >> Well, I mean for us there's two parallel big investment vectors. One is clearly we want to make the platform better for our apps. And you asked earlier about how do we prioritize from our various BUs, and that is driving platform enhancements. But the second layer is, this is the platform our customers are using to automate their entire workflow across their whole organization. So there's a series of stuff we're doing there to make that easier for them. In a lot of cases, less about new capabilities. You look at a lot of our investments, it's more about taking something that previously was hard, but possible, and making it easier and still possible. And in doing that, that's been my experience, is Fred Luddy's experience, the easier you can make something, the more successful people will be with it. And Fred had an insight that you could almost over-simplify it sometimes. You could take something which had 10 features and was hard to use, and replace with something that had seven features and was easy to use, everyone would be super happy. At some level, that's the iPhone story, right? I could do more on my Blackberry, it just took me an hour of reading the documentation to figure out how. >> Both: Right, right. >> But I still miss the little side wheel. (laughs) >> Love that side wheel. All right, Pat, listen thanks very much for coming. We are humbled by your humility. You are like a rock star in this community, and congratulations on all this success and really thanks for coming back on the Cube. >> Thank you very much. It's been a pleasure meeting you guys again. >> All right, great. Okay, keep it right there, everybody. We'll be back with our next guest. You're watching the Cube live from ServiceNow Knowledge K18, #know18. We'll be right back. (upbeat music)

>> Announcer: Live, from Las Vegas, it's the Cube. Covering ServiceNow Knowledge 2018. Brought to you by ServiceNow. >> Welcome back to ServiceNow Knowledge18 the Cube's live coverage. We are the Cube, the leader in live tech coverage. I'm your host, Rebecca Knight, along with my co-host, Dave Vellante. We're joined by Jason Scott-Taggart. He is the head of Business Technology Support at WorldPay. He's in direct from London. So welcome, Jason, to the show. >> Thank you, it's good to be here. >> So first lay the scene for our viewers. Tell us a little bit about what WorldPay is and what you do. >> So WorldPay is the largest payments company in the world. So it's a hidden gem that not a lot of people know about. So recently we merged with Vantiv, which is huge in domestic US. And WorldPay is very large in the rest of the world. So a marriage made in heaven. We're what's technically known as a merchant acquirer, which is a fancy way of saying that we take credit card payments. And we do that for both online or in the store, putting your card in a machine. So billions of transactions a year. >> And what's your relationship with the banking infrastructure around the world? How does that all work? >> Sure, so the banks issue credit cards and your relationship as an individual is with the bank. So you pay your bills to the bank and have that transaction. We look after the merchants. So we're the ones that do the services for the, we quaintly call the merchants still, so for the shops and the traders, we have that relationship. And basically the transactions then go between the two. So individuals to the bank, bank to us, us to the merchants. And we just aggregate that because if you're, even if you're a large company like Costco or Google, you don't want to have to have a relationship with every one of the credit cards let alone every one of the banks. So we aggregate that. >> So tell us about your ServiceNow journey. When did you start using the platform? >> So ServiceNow, we're on our third year now I think with ServiceNow. And it's been explosive. It was a quite seamless transition. We were really pleased with the previous platform we were on, how we moved over. And we slowly added to it. We slowly turned on other modules, other functionality. And it's just become ingrained in our day-to-day IT operations. >> It was simpler because you had had other processes in place? You didn't have to rip and replace those processes and skill sets? >> We took it as an opportunity to do best-of-breed. So there were some things that we carried over. But we took the opportunity for a clean start as well. Even before a lot of the buzz here is back to basics and staying out of the box, and we did that for a lot of it, and that was quite refreshing, and it was quite cathartic in a way that we could make that change. But then there were some bits that weren't really well and were ingrained in our business process so we had to carry those over. But we found it easy to do a mixture of both. >> And you carried those over in the form of custom modifications? >> Some, not a lot. We tried to stay as much out of the box as possible. >> So how does that having some custom mods affect your ability to go to subsequent releases? >> I think it's fair to say that ServiceNow is one of the easier platforms to upgrade. I probably shouldn't say that. They should be doing more work to make it easier for me. (laughing) >> Dave: Do a better job of upgrades. >> But compared to some other platforms we have even Cloud ones, it's not the hardest. It's not the worst. However, we've tried to stay close to the box to make it even easier. We want to stay N plus one no more, and when you're coming out with a major upgrade twice a year, that means we've got to factor that into our road map. But we do. We make sure that we try and stay up to date. >> So where are you now? You're in, are you? >> We're in Jakarta. >> Jakarta, okay. >> Yeah. >> So you're pretty current. >> Yeah, only just though, so. >> Okay, but we heard a lot about Madrid today. >> Yeah. >> Which is Q119. And a lot about DevOps. So talk about, it was very good that the DevOps 101 that Pat Casey gave. I'll give my version of DevOps 101 if I can. (laughs) Back in the day, the developers would write some code, maybe on their laptop or whatever, they'd throw it over the fence to the ops guys, and say, here, deploy this. And the ops guys would go to deploy, and they say, ah, this thing doesn't meet up to our enterprise standards. It doesn't have the security and the governance. So they go in and they hack the code, invariably break it, and then they go to deploy it, and it doesn't work. And they go back to the developers and your code doesn't work. And the developers say, well it worked when I gave it to you. And you get this back and forth, back and forth, back and forth. So DevOps consolidates that into a single programming environment. >> That's good, I appreciate this. >> Infrastructure is code. And so that's my version. Pat Casey gave a much more eloquent description, but what is DevOps to you guys and how are you applying it? >> So we've got two major competitive drivers in the market. One is scale. So we're the largest payments company in the world so we need to leverage that. We can operate in most countries of the world, take most currencies, so that's a scale thing that we try and leverage. Scale tends to lend itself more to waterfall kind of traditional projects. (laughs) The other competitive pressure that we face is from small fintech startups that are nibbling away at our ankles for niche products and new services or disrupting the whole way we do payments. Will there be banks tomorrow? Who knows. The whole way could be disrupted. That innovation lends itself more to a DevOps kind of, or at least an agile form of development. You want rapid prototyping, trying things, seeing what works. So one of the things we've been struggling with at WorldPay is how can we foster more of the DevOps whilst not endangering the traditional kind of waterfall that we need to do. The vast majority of our development is done agile, but hardly any of it is DevOps. And a lot of people confuse agile for being DevOps. And agile is just the dev part of it, it isn't the ops bit of it. So where's the ops in DevOps? What we did, you just outlined classic reasons why people might want to do that, and having a single team owning something all the way through the life cycle. What we've done is we've tried to separate out different layers and kinds of services to allow that to happen. So with scale, you have to have one level one. You have to have a front door for IT that everybody comes to. Whether you're a squidgy resource, a human needing to phone someone or your tin and wires, there's got a problem and alerting an event. So you have one front door. What you need to do is you need to try and have a high first-time fix. That's cheapest and that's most best experience for the end user. So we aim for 60, 70% of issues to just be killed at that front door. That's the aim. After that, we then put a lot of work and effort to make sure that we had a business-oriented, service-oriented CMDB. So we worked with the lines of business to describe WorldPay and what we do in a way that they understood and the IT understood, and then we translated that into a service management language in the CMDB. Once you go past that level one, the level one know they can't fix it, they know what's broken, or they're pretty certain what's broken, they will put it into the right service line. That level two is still run only. So we split, the dev and the run at that level two. You're aiming for 25% of things to stop there. That leaves only about 5% of things that would ever go wrong needing to go to a third line. That third line we refer to as technical services. So you've got business services in the middle of that level two, that the business would recognize and they consume or our merchants would. The technical services at the third line are the components. They're the building blocks that we use to make those business services. And those are where we start doing the DevOps. Another word for it is microservices. So microservices, we have components, sensors of excellence, in both infrastructure, so a virtualized platform, or applications. So a fraud module or a billing module, or a authorization module. And those teams, because they're only getting 5% of things coming through to them that are wrong, they can cope with being small teams that do both the dev and the ops. And that makes it feasible, and we're fostering that. And we're starting to get live services that are being supplied in that DevOps manner, and that means that that can grow as it succeeds or fail as it doesn't, and it's not endangering the huge machine that is the rest of the organization. >> So the huge machine, the core piece of your systems, you still apply waterfall, is that right? >> Jason: Yes. >> And then in the new stuff where you don't mind breaking things, you're applying agile and DevOps. >> Exactly. And that's what we're seeing is that that then what succeeds and what the ways of working or the particular needs that that microservices is addressing, if they're successful it feeds it, awards it, and they do more. So the teams that are going live with some of these microservices, if they put enough effort into making it resilient, doing the non-functional as well as the functional requirements, which is a DevOps thing as well, so you make something and you get it right first time, so it's not breaking all the time, they can then have spare cycles to go and do other sprints where they're building the next thing. And what we hope to see over time is that we will have a larger and larger proportion of the components that make those business services being supplied in the DevOps way. And that is also complementary with going to Cloud services 'cause they're just other building blocks. They're just components that you use to put together something. >> You saw Pat Casey and C. J. Desai, they showed a little leg today on Madrid. They basically developed a DevOps capability for their own purposes and they're going to release it in Madrid. The problem they're trying to solve if I understood it was you've got 500 DevOps tools out there and there's complexity, did that resonate with you? Is that something you'll adopt? Or are you comfortable with your DevOps tools? >> No we're keen and eager to adopt. Well, I'm an IT ops guy by trade. That's what I've been doing for the last 20, 30 years, but I'm not afraid of DevOps. I love DevOps. DevOps means faster delivery with more control. It's automated ITIL. And what the ServiceNow road map is giving me is a way that I can continue to be the air traffic control for IT. I want people to come to me and my team and say, where are we at? What's moving where? And if we get the hooks into ServiceNow into all of those DevOps tools, the names are up there, the Jenkins, the Chef, the Puppets, if we get the hooks in, then it expands more of the PMO work that we almost do as well. So instead of talking about just a single change ticket or a release that's happening here, we can go, that train in the safe framework or this, that sprint over there, they've got to this point. They're in testing. They're about to release this. Actually I can tell you the features that they're proposing will come with this. Because that's hooked in. So that's the dream. That's where we want to get. Because we want to facilitate more of this happening within our development community. >> So from a legacy talent standpoint, are you more DevOps or are you OpsDev? (laughs) >> Rebecca: Oh, I like that. >> Me personally I'm OpsDev. >> Well right, but I mean for your organization was it kind of retraining the ops guys to think more like devs or was it kind of jamming the ops piece into-- >> We've got challenged with both. And the real success that we've had so far has mainly been greenfield. We've set up teams from scratch with the purpose of testing out DevOps as a theory. And it's worked brilliantly. Now though, the bigger struggle is how do you get existing teams? We've got hundreds of developers in our own squad, so working on agile, but they do pure dev. They build it and they hand it over and then they're off, they're onto the next thing. How do we mix those teams? How do you get multi-disciplinary teams that have both the operational knowledge as well as the development? And that's a cultural thing as well as the tooling. Tooling helps. If you get nice tooling that makes it easier for them to operate in a particular way, that's a big important thing, but it's only half the battle. You've got to get people thinking in a slightly different way. And that's true of the ops people have got to think more of the life cycle. How do they feed back what's working and what's not into the next development cycle. And the development people have got to think about what happens once they let it go. And they've got skin in the game now. It's going to come back and bite them. If they didn't do it well, if they didn't put the dashboards for the support people to see how well it's working, then the support people are going to be banging on their door to get it. So it's a cultural thing as well. >> It's a cultural thing. >> So I'm going to ask you a business question. You referred a little bit to disruption before. You talked about banks and the future of banks. Do you think, and you're very tied into the banks, obviously, do you think, and I wonder if this is a discussion inside the organization that banks, traditional banks will lose control of today's payment systems? >> Well, arguably they're not fully in control of it today anyway. (laughs) And so that's not to mean that they're not in control of what they are to do, but they don't own the payment process end-to-end. >> But they own the consumer. >> They own the consumer relationship, yeah. And that's going to be disrupted in the same way the way that we take payments at the other end of the life cycle is disrupted as well. Contactless, block chain, these kind of things mean that it's not going to be the same. However, you're not going to get rid of large organizations overnight. Because what is also increasing day-by-day, is regulation, security requirements. You want to know that your card's going to be safe. You don't want, if you're going to use Apple Pay, or a new contactless technology, you're only going to do that if you know there's no danger of you losing money by doing it. To have that certainty and to meet the regulators' requirements you need organizations like WorldPay looking after the merchants' interests, you need organizations like banks looking after the individual's interests. So I think, unfortunately, it's not as sexy an answer, but I'm afraid that they're not going to disappear overnight. They're adding valuable service. >> A lot of barriers to entry to those Fintech startups that are nibbling at your ankle. >> However though, it's changed dramatically in the last five years, 10 years, so what on earth it's going to look like in the next five or 10 years, bringing it back, that's why I think innovation is so important. We need to be trying to stay ahead of the curve. We need to meet the needs of our merchants so that they can get as many transactions as possible successfully. And we need to do that at the lowest cost possible. So that's all about innovation. Innovation is hard to do top-down. You've got to find ways of fostering it bottom-up. We have have great leadership top-down. This is where we're going. But actually the way that we're going to get there is down to the troops. It's down to the people on the coal face, so. >> When did you buy your first Bitcoin? >> My first Bitcoin? I bought Bitcoin about four years ago. >> Awesome. >> So yeah, I've done all right. It's paid for a holiday. >> There you go. (laughing) That's good for you. That's great. >> Well, Jason, thanks so much for coming on the show. >> Jason: Thank you. >> It's great talking to you. I'm Rebecca Knight for Dave Vellante. We will have more from ServiceNow Knowledge18 just after this. (upbeat music)

>> Narrator: Live from Washington D.C., it's theCUBE. Covering .conf2017. Brought to you by Splunk. >> Well welcome back here on theCUBE. We continue our coverage of .conf2017, we're in Washington D.C. Along with Dave Vellante, I'm John Walls. And Dave, you know what time it is, by the way? Just about? >> I don't know, this is the penultimate interview. >> It's almost five o'clock. >> Okay. >> And that means it's almost happy hour time. So I was thinking where might we go tonight, so-- >> There's an app for that. >> There was, and so I looked. It turns out that the Penny Whiskey Cafe is just two tenths of a mile from here. And you know how I knew that? >> How's the ratings on that? >> We got four. >> Four and half with 52. >> 52 reviews? >> Yeah, I feel good about that. >> Yeah, that's pretty good. That's a substantive base. >> I feel very solid with that one. We'll make it 53 in about a half hour. Of course I found it on Yelp. We have a couple of gentlemen from Yelp with us tonight. I don't have to tell you what Yelp does, it does everything for everybody, right. Zach Musgrave, technical lead, and Chris Gordon, software engineer at Yelp. Gentlemen, thanks for being here. And U can join us, by the way, later on, at the Penny Whiskey if you'd like to. First off, what are you doing here, right, at Splunk? What's Yelp and Splunk, what's that intersection all about? Zach, if you would. >> Sure, well Yelp uses Splunk for all sorts of purposes. Operational, intelligence, business metrics, pretty much any sort of analytics from event driven data that you can really think of, Yelp has found a way, and our engineers have found a way to get that into Splunk and derive business value from it. So Chris and I are actually here, we just gave a breakout session at .conf, talking about how we find strong business value and how we quantify that value and mutate our Splunk cluster to really drive that. >> Okay. >> So, so how do you find value then, I mean, what was? >> It's hard. Chris was one of the people who really, really drove this for us. And when we looked at this, you know I once had an engineer who came up to our team, we maintain Splunk amongst other things, and the engineer said can I ingest 10 terabytes of data a day into Splunk and then keep it forever? And I said, um, please don't. And then we talked a bit more about what that engineer was actually trying to do and why they needed this massive amount of data, and we found a better way that was much more efficient. And then where we didn't need to keep all the data forever. So, by being able to have those conversations and to quantify with the data you're already ingesting into Splunk, being able to quanitfy that and actually show how many people were searching this, how's it being used, what's the depth of the search look like, how far back are they looking in time. You can really optimize your Splunk cluster to get a lot more business value than just naively setting it up and turning it on. >> So you weren't taking a brute force approach, you were smarter about that, but you weren't deduping, you were identifying the data that was not necessary to keep, did I get that right? >> Correct. Yeah, we essentially kind of identified what are highest cost per search logs, which we basically just totaled up how many times each log was searched, and then tried to quantify how much each logs was costing us. And then this ended up being a really good metric for figuring out what we'd want to remove or something that was a candidate for dislodging the data somehow. >> So, you guys gave a talk today. We were talking off camera about pricing, that's not something you guys get involved in, but I would categorize this as sort of how do you get the most out of that asset, called Splunk, right. Is that sort of the >> Exactly. >> theme of your talk, right? >> Yeah. We talk a lot about expected value amongst our team, and in the talk we just gave. And we don't ever think about this as, oh do this so that you can spend less money on Splunk or on your infrastructure that's backing Splunk. Think about is more as we have this right now and we can utilize it more effectively. We can get more value out of what we already have. >> Okay, so, I wonder if we could just talk a little bit about your environment. We know you run on AWS. How does that cloud fit in with Splunk, paint a picture for us, if you would. What does it all look like? >> Yeah, so we have two clusters actually. One is the high value, high quality of service cluster, it's the larger generic, we call it generic prod, and then we have another one, where we kind of have our more verbose, maybe slightly less valuable per log cluster. And this runs on a D2, which is just instant storage. And then the higher performance cluster runs all on a GP2. So it's basically just SSDs. And we also do, we also have four copies of each log and we have two searchable copies of each log, so it's pretty well replicated. >> Dave: Okay, so that's how you protect the data. >> Yeah. >> Is to make copies, in what, in different zones, or? >> Yeah, we have two copies of each log in each availability zone, and then one searchable copy of each log in each availability zone. >> And you guys are cloud natives, all cloud, just out of school and graduate school. So you talked about infrastructure as code. You don't do any of that on-prem stuff, you're not like installing gear. And so it's not part of your lexicon, right? >> No. >> Okay. So I want to do a little editorial thing. Kristen Nicole, our managing editor, sent the note around today saying 101s get the best traffic on the website. So I want to do a little DevOps 101, okay. Even though, it's second nature to you, and a lot of people in our audience know what it is. How do you describe DevOps? Give us the 101 on DevOps. >> Okay so, DevOps is a complicated thing, but and occasionally you see it as like a role on like a job board or something. And that always strikes me as odd, because it's not really a role. Like it's a philosophy moreso. The way that I always see it, is it used to be like pre DevOps, was the software developers make a thing, and then they throw it over the fence, and operations just picks it up. And they're like well what do we do with this, and deploy it, okay, good luck. And so with this result in a sort of an us against them mentality, where the developers aren't incentivized to really make it resilient, or really document it well, and operations and the sys admins are not incentivized to really be flexible and to be really hard charging and move quickly, because they're the ones who are going to be on call for whatever the developers made. DevOps is a we, instead of an us verses them. So for example, product teams have an on-call rotation. Operations and sys admins write code. There are still definitely specializations, but it all comes together in a much more holistic manner. >> Okay, and the ops guys will write code, as opposed to hacking code, messing up your code, throwing it back over the fence, and saying hey your code doesn't work. >> Exactly. >> And then you say well it worked when I gave it to you. And then like you said that sort of finger pointing. >> We are totally done with works on my machine, it's over. No more. >> Okay, and the benefits obviously are higher quality, faster time to market, less food fighting. >> Yup, exactly. In the old model you'd have a new deployment of like a website like maybe once a week or maybe even once a month. Yelp deploys multiple times everyday over and over again. And each one of those is going to include changes from a dozen different engineers. So we need to be agile in that manner, just like with our Splunk cluster. >> I mean you guys are relatively new, four years and two years, perspectively. But these days it's a long time. How would you describe your Splunk journey. Where did it start and where do you want to take it? >> I would say it started, you actually had Kris Wehner on here last year, and he talked a lot about it. He was the VP of engineering at SeatMe. And he kind of got Yelp onto the whole Splunk train. And at that point it was used mostly by SeatMe and everyone at Yelp was like oh this is fantastic, we want to use this. And we started basically migrating it to our VPC. And have generally, we're starting to now get everything going, get all the kinks worked out, and really now we're trying to see where we can provide the most value and make things as easy as possible for our developers to add logs and add searches and get what they need out of it. >> So what kind of use cases are you envisioning, and where are you getting value out of it? >> So we have our operations teams get a lot of value out of it when there's some outage happening. And it's really useful for them to be able to just look at the access logs and see what's going on. And Splunk makes that very easy. And we also get a lot of value out of Yelp's application logs. Splunk has been great for figuring out when something's not right. And allowing us to dig in further. >> So yeah, at the end of the day, as consumers, what does this mean to us, ultimately? Like our searches are faster, searches are more refined, searches are more accurate? What does it mean to me at the end of the day that you're enabling what activity through this technology. >> Dave: Yeah, it'll be more secure? >> Yeah, what does it mean? >> As an end user of Yelp? >> Yes. >> So, I'll give you one example that always sticks out in my mind. So I don't know if you all know this, but you can actually do things like order food via Yelp, you can make appointments via Yelp, even with like a dentist. You can beauty appointments, all sorts of personal services. >> Hair salon came up today actually, when I was looking for a bar. >> Absolutely. That's not supposed to happen. >> Dave: Well that was the Penny Whiskey Cafe. >> You never know, but what ever's next door I don't know. >> Can you get a haircut while you drink? >> Hair salons in the District are pretty impressive. >> I wasn't planning on it, no. But anyway, I'm sorry. >> Anyway, so we work with a lot of external partners to enable all these different integrations, right. So you press start order, and then eventually you see the menu, and then you add some stuff to your cart, and then you have to pay. And so if you haven't given us your credit card information yet, then you have to enter that, and that has to go to a payment processor, the order of course has to go out to the partner who's going to fulfill your order, and so on. So there's this pipeline of many different micro services plus the main Yelp application, plus this partner who's actually fulfilling your order, plus the payment processor, and so on, and so on. And it ends up with this really complicated state machine. So the way that actually works under the hood, to be very simplistic, is there's a unique order identifier that is assigned to you when you start the order. And then that passed through the whole process. So at every step in this process a bunch of events are emitted out of the various parts of the pipeline and into Splunk, where they're then matched to show that your order is progressing. And the order didn't get stuck. Because you know what's really sad is when you order food and it doesn't show up. So we really have to guard against that. >> Yeah, we hate that. >> Yeah, everybody does. So it's really important that we're able to unify this data, from all these different places, Splunk's really great for that, and to be able to then alert on that and page somebody and say hey, something's not quite right here, we have hungry folks. >> So while I have the smartest guys that we've interviewed all week here, you mentioned, >> Please. You mentioned, aw shucks, I know. You mentioned state machine. Are you playing around with functional programming, so called server lists, probably don't like that word either, but what are you doing there? Are you finding sort of new applications in use cases for so called server lists? >> I would say not so much. I don't know, is anyone at Yelp doing that? >> Yeah, there's some Lambda stuff going on. Like core back end is doing that work right now. A lot of our infrastructure is actually build up before the AWS Lambdas were a thing. So we found other ways to do that, and we have this really cool internal platform as a service, it's a docker, and some scheduling stuff on top of that. So a lot of things, like it's really easy to just launch a batch job in there. And it takes away some of the need for the true server lists. >> Well the reason I ask is because people are saying a lot of the state list IoT apps are going to use that sort of Lambda or homegrown stuff. And I'm not sure what the play is for Yelp in Internet of Things. I would imagine there's actually a play there for you guys though, and I'm curious as to the data angle, and maybe where Splunk might fit in. >> I'm certain that we're going to be using Splunk to read data from all of those different components as they're being launched. I know that there's been a couple early forays into the Lambda space that I've seen go by in code reviews and everything. But of course, with Splunk itself we can get data out of those. So as that happens, like we already have all our pipe lining set up. And it'll be pretty easy for them to analyze their self with Splunk. >> What gets you young folks excited these days? What keeps you enthralled and passionate? What do you look for? >> I don't know I think just in general anything that empowers you to get a lot done without having to fight it constantly. And general DevOps tools have been getting really good at that recently. And yeah, I would say anything that empowers you, gives you the feeling that you can do anything really. >> Yeah, all of the infrastructure is code stuff that's going on right now. So one of the pipelines that we use to get data out of Amazon S3, but it passes notifications through this S3 event notifications to Amazon SNS, to Amazon SQS, to our Splunk forwarders. And so that's a very complicated pipeline. And you have to set it all up, it works really well, but here's the cool part. That's all defined in code. And so this means that if you set up a new integration there's a code review. And we have some verification and validation that it's correct. And furthermore, if anything goes wrong with it, we can just hit a button and it recreates itself. That's what gets me happy. When tools get in my way that's not so good. >> Well and it just leaves more time for higher value activities and that's exciting. the transformation in infrastructure over the last five years has just been mind boggling. So, thanks you guys. >> It does. It does give me a lot of pleasure when something can go catastrophically wrong, and then just like, oh wait, it's self healing, all it can take is give three plays fine. And we're all dandy. >> Well to Dave's point, while I was off camera I did a search on the two smartest guys in the room. And it said one is six feet away the other one is seven feet away, so Yelp works, I mean it really does. But thanks for the time. It's been interesting. Next generation, right? So far over us. >> Yeah, I know. It's kind of depressing, but I love it. (laughing) >> Very good, thanks guys. >> Thank you so much. >> Back with more, here on theCUBE at .conf2017. We are live, Washington D.C. >> Dave: I've kind of had it with millennial. (upbeat music)