>> Live, from Las Vegas, it's theCUBE, covering AWS re:Invent 2018, brought to you by Amazon Web Services, Intel, and their ecosystem partners. >> Welcome back to AWS re:Invent, along with Justin Warren, I'm John Walls, we are live here in Las Vegas. Day two of our three days of coverage of this event, seventh time we've been here and, as we've been saying all along, this show is getting bigger and better than ever. About 40,000 attendees this year. Joined now by Abbas Haider Ali, CTO of xMatters, and Chris Crocco, who is the lead solutions architect at Viasat. Gentlemen, thanks for being with us, good to see you. >> Thanks for having me. >> Thanks for having us on. >> All right, tell us a little bit about your respective endeavors and then why the two of you are here together, and Abbas I'll let you lead off. >> Sure, I'm CTO at xMatters, as you described, and our company is basically a digital service availability platform which, outside the marketing speak, and from a technical perspective, means, when bad things happen with technology, and all technology's great but, inevitably, things go wrong-- >> Bad things happen. >> Bad things happen and we're in the business to helping companies get those things fixed as quickly as possible, ideally before they become business-impacting. And basically, I asked Chris here to join me because you can have technology but you need someone to put it into practice and Chris has done a great job of bringing it in to real world at Viasat. >> Good transition, thanks Abbas. My role at Viasat, Viasat's a satellite-based technology and communications company, and my role is to help administer and deploy some of our automations for orchestration monitoring performance and incident management. A lot of that has to do, as it relates to xMatters, with notifying people when they eventually have to go hands-on-keyboard and minimizing the amount of administrative burden that they have so they can just focus on fixing a problem. >> You mentioned before that everyone who was traveling here on an airplane, if they were using the wifi, they're probably running over your service? >> Right, yeah, so one of our-- >> I am astounded that that even works at all, speaking of technology breaking all the time. Maybe explain to us a little bit about how xMatters helps you keep that thing actually functioning. >> Yeah, that's a great question. One of the things that we monitor very, very tightly is our customer experience, both on aircraft, and residential broadband, and so when we're starting to see things where those planes are passing through beams and maybe not handing off the internet connectivity well, if we're seeing people trying to get on the internet and they're either having a slow time or just not getting on at all, one of the things that we want to do is get that to the right people quickly. So, one of the things that we do is we have our customer care elements of commercial mobility in xMatters so that they can report that to the engineering level for that same area of business. When they do that it's opening up a sales force case, it's notifying a Hipchat room, it's getting hold of the on-call resource, and it's also administrating all of that stuff back to the originator of the problem, so that they can keep them informed of "this is what the engineer found, "this is how long it's going to take to get fixed, "this is what you need to tell the customers." So it's enabling a lot of communication while reducing some of the traditional operational elements that go along with incident management. >> Yeah, it's something that we've been hearing quite a bit this week here at AWS, is the importance of that operations side of things. It feels like the whole industry has moved from this being a new technology that we should start doing brand new things with, and it's matured a little bit, where we're actually relying on this stuff to run real multi-billion dollar businesses and operations starts to become really, really important so, as you said, when things break, we want to fix them as fast as possible, so that customers can keep using our services. >> Right, and kind of in the path, when you look at all the companies that are here, they're building fantastic new products, builders are a big part of this event, it's all about building their services and you hear a lot about automation and tool change and the CI/CD pipeline. Well, the CI/CD pipeline really ends at delivery. And that's kind of where our product picks up. So it's in the operations and support realm of it is, once it's out there, things inevitably will go wrong and a lot of the companies you see here are all about detecting that very, very quickly. You'll hear conversations about one-second resolution in detect issues, and those things have to be handled. And really, one of the things that we're seeing a big trend in is going through and saying, "How do we remove the manual process, "and administrative overhead, and the toil "in actually operating these services, "when, inevitably, something goes wrong." And it starts off small and can grow very quickly, so a lot of people use our product, to essentially tie those alerting systems directly into xMatters, it goes out, gathers a lot of the information that people would typically do by hand, the manual effort, delivers it to the right on-call person and arms them with the action and move them through. And really, that cycle of steps, if you think of it as every individual team and service has a series of flows that they go through when things go wrong. It's about taking those steps and putting them all together in the right order and swapping them out as you need to as your service matures and grows. And as your innovation is successful and as you grow in scope, those steps may change, but the flows across the teams remain remarkably-- >> Is there-- >> The same. >> You talk about flows, different avenues, different opportunities, or problems, is there one that tends to stand out amongst the crowd as "That's our biggest headache," whether, for Chris's business, or just, in general, for any of your clients, is there one that leaves you scratching your head? >> If we go around and just interview all the various enterprises, who are consumers and builders of a service and we ask them, saying, "Hey, what's the single biggest thing that's kind of a pain when things go wrong?" One of the biggest problems that we see is that a lot of these organizations have built kind of a distributed operation model. And one of the biggest problems we see is, if you think of it as, you've got a whole series of things, a series of, kind of spokes, and one thing goes wrong, other people are consumers of it, and other people are impacted. All get engaged, saying my thing is also sending me a signal saying "My work has gone sideways," but it's very difficult to figure out where the actual responsibility lies and how do you engage just the people who could actually fix the issue and then let everyone else who is impacted by it be informed, but told to stand down, so they don't waste their cycles on resolving that. And that's a very complicated problem that there is no magical solution for so if anyone's listening and looking for "Okay, "that's what I've got, give me an answer," I don't have a solution for you (laughing) but I can tell you that a lot of these sorts of operational tasks we're putting in place are designed to minimize the effort of figuring out what that is and really speeding up that information cycle so you waste as little time as possible. >> Does that sound familiar, Chris? >> Very familiar, yeah. Viasat's company motto is "Always a better way" and so one of the things we do with xMatters and other tools in our incident response chain is take what we learn when we do have an incident, when we do have a problem, and find a better way of approaching that. It allows us to refine our integrations into xMatters. It allows us to communicate more effectively to the right people. It allows us to really kind of harness our DevOps model and that company credo to our advantage and constantly perform better for our customers. >> We were talking before we went live here, this is dealing with issues at the scale of space, so these sort of problems, and it's a theme that we've been hearing over the last couple of days, that the amount of complexity on these kinds of systems, and something at the scale of a space-based platform. This is something which isn't really tractable for the human mind to deal with unaided, so we really do need tools like xMatters to actually cope with this. But what has putting in something like xMatters done for the business of Viasat? What does that actually change, that you're now able to do that you weren't able to do before? >> Again, xMatters enables a lot of opportunity for our DevOps teams to constantly improve. One of the things that I personally like about xMatters a lot is it's not a centralized tool. A lot of tools in this space are intended for you to be constantly looking at a dashboard or have an incident captain that's always, their life is that tool. >> A single glass of pane. >> Right, but all of these teams have their own single pane of glass that they consume, so we can plug in xMatters where it's appropriate and allow those tool chains and those automation flows to include xMatters but not have it be the end all, be all of their process, so it helps them improve on all of the other parts of incident management and monitoring and xMatters is just there to facilitate those transactions and those workflows. So, a lot of value there, a lot of learning opportunities and a lot of enablement for all of our DevOps teams. >> So you can improve the way that you're doing things without having to rip out everything else and replace it with one new tool. >> Exactly, one of the things that you don't want to do in any organization is throw the baby out with the bathwater, so to speak. There are tools that can be refined and we see a lot of this in the trend toward micro-services, right? Instead of having vendor lock-in, this huge one-stop shop for everything, you can pull and replace all of the smaller pieces in that chain without affecting your availability or your ability to respond to an event. >> And one really interesting thing about these distributed models is you still have places where information needs to wind up, so if I'm working on a particular part of my application and I've got a customer service team that uses Salesforce as their system of choice, I have to get information to Salesforce so they can consume it. It's not okay for me to hoard information, I actually want to make sure that I'm minimizing the friction and moving information along to where it needs to wind up, along that process. If I am a developer, my kind of world view of my tasks are Jira, I want to make sure the information winds up there. If I'm in a service management team and I use something like ServiceNow, kind of track information there, I have to make information wind up there. We collaborate in Slack, I have to make sure that it's available within that world as well. So the key thing that we're really focused about is every team picks their own flows, they pick their own tools, but the steps along the way are very similar. Something goes wrong, you pull in the information, you need help, you need a collaboration step, and you need a basic information delivery stage to put information back in the right places because after it's done, to Chris's point, if you just solved the problem very effectively and learned nothing, you've done a bad job. We have to be clear about that, right? Learning and improvement is a key part of a successful DevOps transition, and when you're running things at the scale we're talking about at re:Invent, you have to learn. And a key part is making sure information winds up in the right places so you're able to do that. >> Getting them halfway happy won't cut it, right? >> Right, I would fully expect that Chris and other customers in Viasat's position would be like, "Yeah, that's great, we did it great this time, "but when it happens again, we would have learned nothing." >> What do we do next? >> Right, exactly. >> Right. >> Gentlemen, thank you for the time. We appreciate you sharing your story and wish you success. >> Thanks very much for having us on. >> For the rest of this week, enjoy the show. >> Thank you very much. >> Off to a great start, that's for sure. >> Thank you. >> Back with more from AWS re:Invent, with Justin Warren, I'm John Walls, and you're watching theCUBE. (upbeat music)