>> 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)

>> Announcer: Live from Orlando, Florida. It's theCube. Covering .conf18, brought to you by Splunk. >> We're back in Orlando, Dave Vellante with Stu Miniman. John Rooney is here. He's the vice president of product marketing at Splunk. Lot's to talk about John, welcome back. >> Thank you, thanks so much for having me back. Yeah we've had a busy couple of days. We've announced a few things, quite a few things, and we're excited about what we're bringing to market. >> Okay well let's start with yesterday's announcements. Splunk 7.2 >> Yup. _ What are the critical aspects of 7.2, What do we need to know? >> Yeah I think first, Splunk Enterprise 7.2, a lot of what we wanted to work on was manageability and scale. And so if you think about the core key features, the smart storage, which is the ability to separate the compute and storage, and move some of that cool and cold storage off to blob. Sort of API level blob storage. A lot of our large customers were asking for it. We think it's going to enable a ton of growth and enable a ton of use cases for customers and that's just sort of smart design on our side. So we've been real excited about that. >> So that's simplicity and it's less costly, right? Free storage. >> Yeah and you free up the resources to just focus on what are you asking out of Splunk. You know running the searches and the safe searches. Move the storage off to somewhere else and when you need it you pull it back when you need it. >> And when I add an index or I don't have to both compute and storage, I can add whatever I need in granular increments, right? >> Absolutely. It just enables more graceful and elastic expansiveness. >> Okay that's huge, what else should we know about? >> So workload management, which again is another manageability and scale feature. It's just the ability to say the great thing about Splunk is you put your data in there and multiple people can ask questions of that data. It's just like an apartment building that has ... You know if you only have one hot water heater and a bunch of people are taking a shower at the same time, maybe you want to give some privileges to say you know, the penthouse they're going to get the hot water first. Other people not so much. And that's really the underlying principle behind workload management. So there are certain groups and certain people that are running business critical, or mission critical, searches. We want to make sure they get the resources first and then maybe people that are experimenting or kind of kicking the tires. We have a little bit of a gradation of resources. >> So that's essentially programmatic SLAs. I can set those policies, I can change them. >> Absolutely, it's the same level of granular control that say you were on access control. It's the same underlying principle. >> Other things? Go ahead. >> Yeah John just you guys always have some cool, pithy statements. One of the things that jumped out to me in the keynotes, because it made me laugh, was the end of metrics. >> John: Yes. >> You've been talking about data. Data's at the ... the line I heard today was Splunk users are at the crossroads of data so it gives a little insight about what you're doing that's different ways of managing data 'cause every company can interact with the same data. Why is the Splunk user, what is it different, what do they do different, and how is your product different? >> Yeah I mean absolutely. I think the core of what we've always done and Doug talked about it in the keynote yesterday is this idea of this expansive, investigative search. The idea that you're not exactly sure what the right question is so you want to go in, ask a question of the data, which is going to lead you to another question, which is going to lead you to another question, and that's that finding a needle in a pile of needles that Splunk's always great at. And we think of that as more the investigative expansive search. >> Yeah so when I think back I remember talking with companies five years ago when they'd say okay I've got my data scientists and finding which is the right question to ask once I'm swimming in the data can be really tough. Sounds like you're getting answers much faster. It's not necessarily a data scientist, maybe it is. We say BMW on stage. >> Yeah. >> But help us understand why this is just so much simpler and faster. >> Yeah I mean again it's the idea for the IT and security professionals to not necessarily have to know what the right question is or even anticipate the answer, but to find that in an evolving, iterative process. And the idea that there's flexibility, you're in no way penalized, you don't have to go back and re-ingest the data or do anything to say when you're changing exactly what your query is. You're just asking the question which leads to another question, And that's how we think about on the investigative side. From a metric standpoint, we do have additional ... The third big feature that we have in Splunk Enterprise 7.2 is an improved metrics visualization experience. Is the idea of our investigative search which we think we are the best in the industry at. When you're not exactly sure what you're looking for and you're doing a deep dive, but if you know what you're looking for from a monitoring standpoint you're asking the same question again and again and again, over and again. You want be able to have an efficient and easy way to track that if you're just saying I'm looking for CPU utilization or some other metric. >> Just one last follow up on that. I look ... the name of the show is .conf >> Yes. >> Because it talks about the config file. You look at everywhere, people are in the code versus gooey and graphical and visualization. What are you hearing from your user base? How do you balance between the people that want to get in there versus being able to point and click? Or ask a question? >> Yeah this company was built off of the strength of our practitioners and our community, so we always want to make sure that we create a great and powerful experience for those technical users and the people that are in the code and in the configuration files. But you know that's one of the underlying principles behind Splunk Next which was a big announcement part of day one is to bring that power of Splunk to more people. So create the right interface for the right persona and the right people. So the traditional Linux sys admin person who's working in IT or security, they have a certain skill set. So the SPL and those things are native to them. But if you are a business user and you're used to maybe working in Excel or doing pivot tables, you need a visual experience that is more native to the way you work. And the information that's sitting in Splunk is valuable to you we just want to get it to you in the right way. And similar to what we talked about today in the keynote with application developers. The idea of saying well everything that you need is going to be delivered in a payload and json objects makes a lot of sense if you're a modern application developer. If you're a business analyst somewhere that may not make a lot of sense so we want to be able to service all of those personas equally. >> So you've made metrics a first class citizen. >> John: Absolutely. >> Opening it up to more people. I also wanted to ask you about the performance gains. I was talking to somebody and I want to make sure I got these numbers right. It was literally like three orders of magnitude faster. I think the number was 2000 times faster. I don't know if I got that number right, it just sounds ... Implausible. >> That's specifically what we're doing around the data fabric search which we announced in beta on day one. Simply because of the approach to the architecture and the approach to the data ... I mean Splunk is already amazingly fast, amazingly best in class in terms of scale and speed. But you realize that what's fast today because of the pace and growth of data isn't quite so fast two, three, four years down the road. So we're really focused looking well into the future and enabling those types of orders of magnitude growth by completely re imagining and rethinking through what the architecture looks like. >> So talk about that a little bit more. Is that ... I was going to say is that the source of the performance gain? Is it sort of the architecture, is it tighter code, was it a platform do over? >> No I mean it wasn't a platform do over, it's just the idea that in some cases the idea of thinking like I'm federating a search between one index here and one index there, to have a virtualization layer that also taps into compute. Let's say living in a patchy Kafka, taking advantage of those sorts of open source projects and open source technologies to further enable and power the experiences that our customers ultimately want. So we're always looking at what problems our customers are trying to solve. How do we deliver to them through the product and that constant iteration, that constant self evaluation is what drives what we're doing. >> Okay now today was all about the line of business. We've been talking about, I've used the term land and expand about a hundred times today. It's not your term but others have used it in the industry and it's really the template that you're following. You're in deep in sec ops, you're in deep in IT, operations management, and now we're seeing just big data permeate throughout the organization. Splunk is a tool for business users and you're making it easier for them. Talk about Splunk business flow. >> Absolutely, so business flow is the idea that we had ... Again we learned from our customers. We had a couple of customers that were essentially tip of the spear, doing some really interesting things where as you described, let's say the IT department said well we need to pull in this data to check out application performance and those types of things. The same data that's following through is going to give you insight into customer behavior. It's going to give you insight into coupons and promotions and all the things that the business cares about. If you're a product manager, if you're sitting in marketing, if you're sitting in promotions, that's what you want to access and you want to be able to access that in real time. So the challenge is that we're now stepping you with things like business flow is how do you create an interface? How do you create an experience that again matches those folks and how they think about the world? The magic, the value that's sitting in the data is we just have to surface it for the right way for the right people. >> Now the demo, Stu knows I hate demos, but the demo today was awesome. And I really do, I hate demos because most of them are just so boring but this demo was amazing. You took a bunch of log data and a business user ingested it and looked at it and it was just a bunch of data. >> Yeah. >> Like you'd expect and go eh what am I supposed to do with this and then he pushed button and then all of a sudden there was a flow chart and it showed the flow of the customer through the buying pattern. Now maybe that's a simpler use case but it was still very powerful. And then he isolated on where the customer actually made a phone call to the call center because you want to avoid if possible and then he looked at the percentage of drop outs, which was like 90% in that case, versus the percentage of drop outs in a normal flow which was 10%- Oop something's wrong, drilled in, fixed the problem. He showed how he fixed it, oh graphically beautiful. Is it really that easy? >> Yeah I mean I think if you think about what we've done in computing over the last 40 years. If you think about even the most basic word processor, the most basic spreadsheet work, that was done by trained technicians 30-40 years ago. But the democratization of data created this notion of the information worker and we're a decade or so now plus into big data and the idea that oh that's only highly trained professionals and scientists and people that have PHDs. There's always going to be an aspect of the market or an aspect of the use cases that is of course going to be that level of sophistication, but ultimately this is all work for an information worker. If you're an information worker, if you're responsible for driving business results and looking at things, it should be the same level of ease as your traditional sort of office suite. >> So I want to push on that a little if I can. So and just test this, because it looked so amazingly simple. Doug Merritt made the point yesterday that business processes they used to be codified. Codifying business processes is a waste of time because business processes are changing so fast. The business process that you used in the example was a very linear process, admittedly. I'm going to search for a product, maybe read a review, I'm going to put it in my cart, I'm going to buy it. You know, very straightforward. But business processes as we know are unpredictable now. Can that level of simplicity work and the data feed in some kind of unpredictable business process? >> Yeah and again that's our fundamental difference. How we've done it differently than everyone in the market. It's the same thing we did with IT surface intelligence when we launched that back in 2015 because it's not a tops down approach. We're not dictating, taking sort of a central planning approach to say this is what it needs to look like. The data needs to adhere to this structure. The structure comes out of the data and that's what we think. It's a bit of a simplification, but I'm a marketing guy and I can get away with it. But that's where we think we do it differently in a way that allows us to reach all these different users and all these different personas. So it doesn't matter. Again that business process emerges from the data. >> And Stu, that's going to be important when we talk about IOT but jump in here. >> Yeah so I wanted to have you give us a bit of insight on the natural language processing. >> John: Yeah natural language processing. >> You've been playing with things like the Alexa. I've got a Google Home at home, I've got Alexa at home, my family plays with it. Certain things it's okay for but I think about the business environment. The requirements in what you might ask Alexa to ask Splunk seems like that would be challenging. You're got a global audience. You know, languages are tough, accents are tough, syntax is really really challenging. So give us the why and where are we. Is this nascent things? Do you expect customers to really be strongly using this in the near future? >> Absolutely. The notion of natural language search or natural language computing has made huge strides over the last five or six years and again we're leveraging work that's done elsewhere. To Dave's point about demos ... Alexa it looks good on stage. Would we think, and if you're to ask me, we'll see. We'll always learn from the customers and the good thing is I like to be wrong all the time. These are my hypotheses, but my hypothesis is the most actual relevant use of that technology is not going to be speech it's going to be text. It's going to be in Slack or Hipchat where you have a team collaborating on an issue or project and they say I'm looking for this information and they're going to pass that search via text into Splunk and back via Slack in a way that's very transparent. That's where I think the business cases are going to come through and if you were to ask me again, we're starting the betas we're going to learn from our customers. But my assumption is that's going to be much more prevalent within our customer base. >> That's interesting because the quality of that text presumably is going to be much much better, at least today, than what you get with speech. We know well with the transcriptions we do of theCUBE interviews. Okay so that's it. ML and MLP I thought I heard 4.0, right? >> Yeah so we've been pushing really hard on the machine learning tool kit for multiple versions. That team is heavily invested in working with customers to figure out what exactly do they want to do. And as we think about the highly skilled users, our customers that do have data scientists, that do have people that understand the math to go in and say no we need to customize or tweak the algorithm to better fit our business, how do we allow them essentially the bare metal access to the technology. >> We're going to leave dev cloud for Skip if that's okay. I want to talk about industrial IOT. You said something just now that was really important and I want to just take a moment to explain to the audience. What we've seen from IOT, particularly from IT suppliers, is a top down approach. We're going to take our IT framework and put it at the edge. >> Yes. >> And that's not going to work. IOT, industrial IOT, these process engineers, it's going to be a bottoms up approach and it's going to be standard set by OT not IT. >> John: Yes. >> Splunk's advantage is you've got the data. You're sort of agnostic to everything else. Wherever the data is, we're going to have that data so to me your advantage with industrial IOT is you're coming at it from a bottoms up approach as you just described and you should be able to plug into the IOT standards. Now having said that, a lot of data is still analog but that's okay you're pulling machine data. You don't really have tight relationships with the IOT guys but that's okay you got a growing ecosystem. >> We're working on it. >> But talk about industrial IOT and we'll get into some of the challenges. >> Yeah so interestingly we first announced the Industrial Asset Intelligence product at the Hannover Messe show in Germany, which is this massive like 300,000 it's a city, it's amazing. >> I've been, Hannover. One hotel, huge show, 400,000 people. >> Lot of schnitzel (laughs) I was just there. And the interesting thing is it's the first time I'd been at a show really first of all in years where people ... You know if you go to an IT or security show they're like oh we know Splunk, we love Splunk, what's in the next version. It was the first time we were having a lot of people come up to us saying yeah I'm a process engineer in an industrial plant, what's Splunk? Which is a great opportunity. And as you explain the technology to them their mindset is very different in the sense they think of very custom connectors for each piece. They have a very, almost bespoke or matched up notion, of a sense to a piece of equipment. So for an example they'll say oh do you have a connector for and again, I don't have the machine numbers, but like the Siemens 123 machine. And I'll be like well as long as it's textural structural to semi structural data ideally with a time stamp, we can ingest and correlate that. Okay but then what about the Siemens ABC machine? Well the idea that, the notion that ... we don't care where the source is as long as there's a sensor sending the data in a format that we can consume. And if you think back to the beginning of the data stream processor demo that Devani and Eric gave yesterday that showed the history over time, the purple boxes that were built, like we can now ingest data via multiple inputs and via multiple ways into Splunk. And that hopefully enables the IOT ecosystems and the machine manufacturers, but more importantly, the sensor manufacturers because it feels like in my understanding of the market we're still at a point of a lot of folks getting those sensors instrumented. But once it's there and essentially the faucet's turned on, we can pull it all in and we can treat it and ingest it just as easily as we can data from AWS Kineses or Apache Access logs or MySequel logs. >> Yeah and so instrumenting the windmill, to use the metaphor, is not your job. Connectivity to the windmill is not your job, but once those steps have been taken and the business takes those steps because there's a business case, once that's done then the data starts flowing and that's where you come in. >> And there's a tremendous amount of incentive in the industry right now to do that level of instrumentation and connectivity. So it feels like that notion of instrument connect then do the analytics, we're sitting there well positioned once all those things are in place to be one of the top providers for those analytics. >> John I want to ask you something. Stu and I were talking about this at our kickoff and I just want to clarify it. >> Doug Merritt said that he didn't like the term unstructured data. I think that's what he said yesterday, it's just data. My question is how do you guys deal with structured data because there is structured data. Bringing transaction processing data and analytics data together for whatever reason. Whether it's fraud detection, to give the buyer an offer before you lose them, better customer service. How do you handle that kind of structured data that lives in IBM mainframes or whatever. USS mainframes in the case of Carnival. >> Again we want to be able to access data that lives everywhere. And so we've been working with partners for years to pull data off mainframes. Again, the traditional in outs aren't necessarily there but there are incentives in the market. We work with our ecosystem to pull that data to give it to us in a format that makes sense. We've long been able to connect to traditional relational databases so I think when people think of structured data they think about oh it's sitting in a relational database somewhere in Oracle or MySequel or SQL Server. Again, we can connect to that data and that data is important to enhance things particularly for the business user. Because if the log says okay whatever product ID 12345, but the business user needs to know what product ID 12345 is and has a lookup table. Pull it in and now all of a sudden you're creating information that's meaningful to you. But structure again, there's fluidity there. Coming from my background a Json object is structured. You can the same way Theresa Vu in the demo today unfurled in the dev cloud what a Json object looks like. There's structure there. You have key value pairs. There's structure to key value pairs. So all of those things, that's why I think to Doug's point, there's fluidity there. It is definitely a continuum and we want to be able to add value and play at all ends of that continuum. >> And the key is you guys your philosophy is to curate that data in the moment when you need it and then put whatever schema you want at that time. >> Absolutely. Going back to this bottoms up approach and how we approach it differently from basically everyone else in the industry. You pull it in, we take the data as is, we're not transforming or changing or breaking the data or trying to put it into a structure anywhere. But when you ask it a question we will apply a structure to give you the answer. If that data changes when you ask that question again, it's okay it doesn't break the question. That's the magic. >> Sounds like magic. 16,000 customers will tell you that it actually works. So John thanks so much for coming to theCUBE it was great to see you again. >> Thanks so much for having me. >> You're welcome. Alright keep it right there everybody. Stu and I will be back. You're watching theCUBE from Splunk conf18 #splunkconf18. We'll be right back. (electronic drums)

>> Announcer: Live from Santa Clara in the heart of Silicon Valley, it's The Cube, covering Cloud Foundry Summit 2017. Brought to you by the Cloud Foundry Foundation and Pivotal. >> Welcome back, I'm Stu Miniman joined by my cohost John Troyer. Happy to welcome to the program a first-time guest but a company we've had on the program before. Brian Gregory is the director of Cloud Strategy and Engineering at Express Trips, I'm sorry, Express Scripts, and Express Scripts booth is actually right behind us on the stage. Thank you so much for joining us. >> Thank you for having me. >> All right, you were giving us a little bit of background about, I believe it's been about three years you've been with the company. Why don't you share with our audience Express Scripts company that many of us have probably used, less likely that everybody knows who you are and your role there. >> Yeah, so my role today, again, is a Cloud Strategy Engineering director, but it's really focused on building out the next-gen platform, making infrastructure irrelevant, if you will, and making our developers go faster and making everything as streamless as possible. >> And Brian, just for our audience that doesn't know Express Scripts, give us, what's the brain of the company and what are you known for. >> We serve 85 million patients today, 3,000 contractor. We have, if you go look at what we do as a business, the pharmacy benefit management side, our goal is to basically make prescriptions safer, more affordable, for all of our patients. So if you think about what we're doing, that's really what we're doing, and we like to say pharmacy smarter. And for us, that's our major goal in everything we do. So my team, anybody's team, doesn't matter what you're doing in technology, that's your end goal, to deliver value to those patients and your clients and so that's what we focus on. >> Well, Brian, it's a good thing. IT's changing all the time, at least health care, nothing's been changing radically, changing all the time. So, bring us inside what you did when you came inside the company. Your role, as you said, infrastructure. Wanted to worry about that less, that's something we hear a lot. >> Right, and one thing I should clarify is that Express Scripts has always been a technology company. If you look at their grass roots and what they were built upon, in 30 years they grew to 100 billion dollar business, really by utilizing technology at the end of the day. When I came in, I was managing some infrastructure teams and database organizations and we decided that this was, the whole digital transformation, or cloud strategy, was a real thing, so my leadership asked me to take this on as an initiative, that was my background, that's where I came from, my grass roots, if you will, from Savs and Centurylink and that became a full-time role. It came to one point where you can't do both, this is taking off and it's being a real thing. Our main goal was to say, how are we going to step outside the box? We still have to run a 100 billion dollar organization. But we got to figure out what the new is, right, you're going to invent that next light bulb, and we've got to maintain the current one. And so, for us, we wanted a full-fledged platform. It wasn't about just spitting out BM's and delivering those, I think we'd had that covered. It was really about figuring out how we're going to figure out cloud, cloud in general. And then what about multi-cloud and how do we get a platform that could seamlessly integrate with all of those. >> And Brian, what was the underlying driver there in the business? Is it you needed to develop more software, you needed to move faster, what's the why, was it cost savings and things getting out of hand? >> Yeah, all of the above. I think specifically it's about delivering value, delivering value to patients as fast and seamless as possible. And so we wanted to figure that out. The old ways, if we all go back in our years of, there were days that I would get hardware and physically, I'm going to figure out how to put the drive so that they're getting more IO or whatever. Those projects have been solved, right, and if you look at companies 10 years ago, they were like, virtualization is scary, I can't do that, I have production workload. So the trend in the market is to keep moving up the stack, and so ultimately, that's where you end up focusing on. Where do we deliver value as an IT organization? That's not for us to go build a homebrewed system that does any of those things. You can go buy those things, integrate them and figure out how they can drive value in your business. So that's what we wanted to do, get a platform. The first goal we had was actually a really interesting story. We wanted to build a new mobile application that would allow consumers to go on and make a user experience much better than it had previously been. If you wanted to order prescriptions, you could go onto this app and say, not just, can I order that, but I can also see what the prices are at different places local to you, the distance to those, and then what would it take if you did a 90-day fill for our home-delivery program and you could sign up via that method. And that was really what we were going after, that end user experience to say, how do we change the experience for our consumers. Not necessarily the back-end stuff, the day-to-day batch processing that they don't really care about how that's done as long as it's done within the time threshold that that's supposed to be done. >> Brian, can you talk a little bit about the process of getting to where we are in terms of, you talked about trying to figure out cloud, and part of that is figuring out which platform to go with and then part of it is finding the people with the skills to, once you've decided on a direction, to help you figure it out. Can you talk just a little bit about maybe that learning journey for you, for Express Scripts? >> Sure, sure. Yeah, it's really interesting, 'cause when I talk, I feel like this was five years that I've been doing this specifically at Express Scripts, when really, it's 18 months that we've really stood up our internal hybrid cloud and got our platform installed. So, yeah, it's learning by doing but the nice thing about everything we're doing, and you hear this all the time, is that we can iterate, you can make changes. It's not like you have to wait three months and then you can't shift or can't course-correct. Learning, the team's been amazing, so I grabbed some people within, they got re-trained on this is the new stack. I also brought in some people that had previously worked with me that had some of the skill sets. Really, it's people that are curious in nature and want to learn. But then you go, that's a neat story, we can stand up a cloud or use an external one, you can stand up your pads. But at the end of the day, what do you do next, how do you start to engage developers? 'Cause when we opened the doors for business, it wasn't like we had everybody standing there waiting to get in. You had to convince them of, these are the features, not convince them, show them the features and the functionality and why it mattered to them. Why does it matter now, and then you go, okay, that's great, and you start to, I would say my team focuses probably 80% of their time on teaching people how to fish, hoping that the developers get better and the consuming of the platform, they help each other and we see a lot of that happening in our slack channels and hipchat and different things, communication tools where they're helping each other, so we're not even having to answer all the questions. But then you get the whole problem of, all right, well, now we've got release management we're going to start working with and that opens a whole new can and they're transforming as well and they're definitely changing their processes. But it gets hairy when you start looking at, well, we've got to keep the tourniquet over here 'cause we can't afford any disruption or outages for our patients. But these new guys, if they check all these boxes, they should be able to deploy whenever they feel like in the middle of the day and we should feel comfortable doing that because it's now micro-service, it's not some monolith thing that they don't understand. >> Brian, can you give us a little insight on the state of your application, so I think most people understand something like cloud foundry, oh, I wanted to build that new app, that's a great use case. How many applications have you moved over, do you have a percentage you measure? I heard the Liberty Mutual keynote was like, what percentage of workloads they have there, what percentage of people code, how fast they release code on this thing, what metrics do you use? >> Yeah, so I had this conversation last night. We don't have, I can tell you that we have over 1100 applications that have moved in 18 months, so I would tell you that, when it started out, we had specific goals of migrating existing lift and shift and refactoring and things like that. What we found was that there's all this net new coming in, not just what we're doing is blowing up within the company, but they're also doing that on the developer's side and they're doing a lot of new things so those new projects clearly migrate over or come in the door starting out with cloud-first strategy. Then you start to lift and shift, and you really have to start cherry-picking what makes sense. Some things you go, there's not really the value, there's no user experience behind this, it's literally just a monetary thing, maybe or maybe not. But you start taking the dollars that you're going to put towards migrating this, and then you're like, well, it's not really a win-win. So what we found was that allnet news coming this direction on the cloud foundry platform, and the workload that makes sense, and then we started cherry-picking things that we re-wrote in spring and they're slowly migrating. But today we're at 1100, we just hit 1100 apps, which is pretty good for 18 months. >> That's really impressive in 18 months. Any lessons learned there as to things you could do to move faster or mistakes that were made that you could tell your peers, hey, watch out for this? >> Yeah, I definitely have a lot of those but, at the same time, I feel like lessons learned are the best thing, the best thing we do is fail, literally, because then you learn something from it and you move forward. I think the one advice, some advice I would give to people is, don't get hung up on trying to be perfect. If there's a lift and shift opportunity and you only get 60 to 70% of the goodness of moving this thing, then just go ahead and do it, don't say, well, but it's not perfect, and we want to make this app completely different, 'cause that's where people get stuck on. I think once they realize they just try some things and then you can get over there and change it and make it perfect down the road. But some people are like, why would I move one to one, I should refactor this app and maybe have it multiple per one and those are great conversations but I think it keeps people, the old analysis paralysis conversation, and it's like, just try it, just go. I would say another good story we had is, we have an outcomes conference that we host, Express Scripts. We had, they were trying to come up with a new way to do basically a content management solution show a digital benefit guide, and they came in and they wanted to try one technology. Didn't work out, two weeks later they came back and were like, well, it doesn't deliver that, so we tried something else. And we tried four different things for this person and they got to where they wanted to be but the important part was that we could change on the fly. In the old days, it was like, you ordered hardware or you ordered BM's, you were stuck because he had dates to deliver and we basically, we can change things. If it doesn't work we'll try something else and you can move around and do things at scale where you couldn't before. >> It sounds like a set of outcomes that the business side, the executive side, leadership, can actually point to and recognize as helping transform the business. You're here at the conference, a sponsor of the conference, participating at the conference. And you're a pharmacy benefits company, so, that's an interesting position to be in. But it sounds like the business and management supports you and recognizes that this is helping move with velocity. >> Yes, so from the top down, we are a technology company at heart. This is what we do and the company has come a long way with, when I got there, the fact that we're here sponsoring it means a great deal to me because this is, after all, an open-source tech conference, which is amazing. It's nice to talk about, get some branding out there and talk about what we're doing so people know that, hey, there's a lot of really cool things happening. Maybe we recruit some people at the end of the day as a result, you never know. But yeah, it's really about just branding and then supporting the community and getting out the word of what we're doing and why it matters. >> Last question I have for you, Brian, is, a lot of discussion about multi-cloud and things like Kubernetes enable that. Can you share what public cloud or public cloud you use, how you look at that dynamic? >> Yeah, so we've got a few things in the works. So there's a few POC's happening, I would tell you that our internal cloud is where we have everything hosted today. We've built an internal hybrid cloud. >> So you have the data centers? >> Yeah, we have multiple data centers and we have our internal hybrid clouds built out. We are evaluating some external capabilities, we're also doing some partnerships, you can actually go read about. Our CIO just released a story about that. We're definitely looking for that, where's our burst-able capacity. With our data and with what we have going on, going external is a much different conversation than where my previous company, we're talking about Hippa compliance and a lot of different data issues that we've got to make sure we're protecting and our most important thing to do is protect that data from our patients. So there's no reason for us to go, we have to get out external at this point, but we do see that as an important part of our key going forward to say, this is part of our strategy, to say, we've got to get an external solution as well. >> Brian Gregory, always love the stories of how digital transformation are helping to impact everyone who uses prescriptions. I mean, no better way of helping people, so we'll be back with lots more coverage here of Cloud Foundry Summit 2017. Thanks for watching The Cube. (techno music) >> I remember when I had such a fantastic batting practice, I walked by a couple of sports writers in that era.