>> Narrator: From around the globe, it's theCUBE, covering HPE Discover Virtual Experience brought to you by HPE. >> Hi, and welcome back to theCUBE's coverage of HPE Discover 2020 the virtual experience. I'm your host Stu Miniman. I'm really happy to be joined on the program two of our CUBE alumni, we have the Daves from Hewlett Packard labs. Sitting in the screen next to me is Dave Husak he is a fellow and general manager for the Cloudless Initiative. And on the other side of the screen, we have Dave Larson, vice president and CTO of the Cloudless Initiative. Dave and Dave, thank you so much for joining us again. >> Delighted to be here. >> All right, so specifically we're going to be talking a bit about security, obviously, you know, very important in the cloud era. And as we build our native architect, you know, Dave Husak, I guess, why don't you set the stage for us a little bit, of you know, where security fits into, you know, HPE overall and, you know, the mission that you know, last year a lot of buzz and discussion and interest around Cloudless. So just put that as a start and then we'll, get into a lot of discussion about security. >> Right yeah, last year we did, you know, launch the initiative and, you know, we framed it as, it composed of three components, one of which in fact, the most important aspect of which it was the trust fabric Cloudless Trust Fabric, which was you know, built on the idea of intrinsic security for all workload end points, right. And this is a theme that you see playing out, you know, a year later playing out, I think across the industry. You hear that language and that, you know, that kind of idea of being promoted in the context of zero trust, you know, new capabilities being launched by VMware and other kinds of runtime environments, right. And you know, the way I like to say it is that we have entered an era of security first in IT infrastructure. It's no longer going to be practical to build IT infrastructure and then, you know, have products that secure it, right. You know, build perimeters, do micro-segment or anything like that. Workload end points need to be intrinsically secure. And you know, the upshot of that really at this point is that all IT infrastructure companies are security companies now. The you know it, acknowledge it, like it or not, we're all security companies now. And so, you know, a lot of the principles applying in the Cloudless Trust Fabric are those zero trust principles are based on cryptographic, workload, identity, leverage unique aspects of HPs products and infrastructure that we've already been delivering with hardware and Silicon root of trust built into our reliance servers and other capabilities like that. And you know, our mission, my mission is to propel that forward and ensure that HP is, you know, at the forefront of securing everything. >> Yeah, excellent definitely, you know love the security first discussion. Every company we've talked to absolutely security is not only a sea level, but you know, typically board level discussion, I guess my initial feedback, as you would say, if every company today is a security company, many of them might not be living up to the expectation just yet So Dave Larson, let's say, you know, applications are, you know, at the core of what we've look at it in cloud native. It's new architectures, new design principles. So give us some, what is HPE thoughts and stuff, how security fits into that, and what's different from how we might've thought about security in the past the applications? Well, I think Dave touched on it, right? From a trust fabric perspective, we have to think of moving to something where the end points themselves, whether their workloads or services are actually intrinsically secure and that we can instantiate some kind of a zero trust framework that really benefits the applications. It really isn't sufficient to do intermediate inspection. In fact, the real, the primary reason why that's no longer possible is that the world is moving too encryption everywhere. And as soon as all packets are encrypted in flight, not withstanding claims to the contrary, it's virtually impossible to do any kind of inference on the flows to apply any meaningful security. But the way we see it is that the transition is moving to a modality where all services, all workloads, all endpoints can be mutually attested, cryptographically identified in a way that allows a zero trust model to emerge so that all end points can know what they are speaking to on the remote end and by authorization principals determine whether or not they're allowed to speak to those. So from a HPE perspective, the area where we build is from the bottom up, we have a Silicon root of trust in our server platform. It's part of our ILO five Integrated lights out baseboard management controller. We can actually deliver a discreet and measurable identity for the hardware and projected up into the workload, into the software realm. >> Excellent, Ty I heard you mentioned identity makes me think of the Cytel acquisition that the HPE made early this year, people in the cloud native community into CubeCon you know, SPIFFE of course, is a project that had gotten quite a bit of attention. Can give us a little bit as to how that acquisition fits into this overall discussion we were just having? >> Oh yeah, so we acquired Cytel into the initiative, beginning of this year. As you, understand Stu, right. Cryptographic identity is fundamental to zero trust security because we're no longer, like Dave pointed out we're no longer relying, on intermediary devices, firewalls, or other kinds of functions to manage, you know, authorize those communications. So the idea of building cryptographic identity into all workload endpoints, devices and data is sort of a cornerstone of any zero trust security strategy. We were delighted to bring the team on board. Not only from the standpoint that they are the world's experts, original contributors, and moderators and committers in the stewardship of SPIFFE and SPIRE the two projects in the CNCF. But you know, the impact they're going to have on the HPs product development, hardware and software is going to be outsized. And it also, you know, as a, I'll have to point this out as well, you know, It is the, this is the most prominent open source project that HP is now stewarding, right. In terms of its acceptance, of SPIFFE and SPIRE, or both poised to be I have an announcement here shortly, probably. But we expect they're going to be promoted to the incubating phase of CNCF maturity from the Sandbox is actually one of the first Sandbox projects in the CNCF. And so it's going to join that Pantheon of know, you know, top few dozen out of I think 1,390 projects in the CNCF. So like you pointed out Stu you know, SPIFFE and SPIRE are right now, you know, the world's leading candidate as, you know, sort of the certificate standard for cryptographic workload endpoint identity. And we're looking at that as a very fundamental enabling technology for this transformation, that the industry is going to go through. >> Yeah, it's really interesting if we pull on that open source thread a little bit more, you know, I think back to earlier in my career, you know, 15, 20 years ago, and if you talk to a CIO, you know, security might be important to them, but they keep what they're building and how their IT infrastructure, is something that they keep very understood. And if you were a vendor supplying to them, you had to be under NDA to understand, because that was a differentiation. Now we're talking about lifting cloud, we're talking about open source, you know, even when I talked to the financial institutions, they're all talking amongst themselves the how do we share best practices because it's not, am I secure? It's we all need to be secure. I wonder if you can comment a little bit on that trend, you know, how the role of open source. Yeah, this is an extension of Kerckhoffs's principle, right? The idea that a security system has to be secure, even if you know the system, right. That's it's only the contents of the ease in the communication letter, that are important. And that is playing out, at the highest level in our industry now, right. So it is, like I said, cryptographic identity and identity based encryption are the cornerstones of building a zero trust fabric. You know, one of the other things is, cause you mentioned that, we also observed is that the CNCF, the Apache foundation. The other thing that's, I think a contrast to 15 years ago, right back 15, 20 years ago, open source was a software development phenomenon, right. Where, you know, the usual idea, you know, there's repositories of code, you pull them down, you modify them for your own particular purposes and you upstream this, the changes and such, right. It's less about that now. It is much more a model for open source operations than it is a model for open source development. Most of the people that are pulling down those repositories unless they are using them, they're not modifying them, right. And as you also, I think understand, right. The framework of the CNCF landscape comprehensive, right? You can build an entire IT infrastructure operations environment by you know, taking storage technologies, security technologies, monitoring management, you know, it's complete, right. And it is, you know, becoming really, you know, a major operational discipline out there in the world to harness all of that development harness, the open source communities. Not only in the software, not only in the security space, but I think you know comprehensively and that engine of growth and development is I think probably the largest, you know manpower and brainpower, and you know, operational kind of active daily users model out there now, right. And, it's going to be critical. I think for the decade, this decade that's coming. That the successful IT infrastructure companies have to be very tightly engaged with those communities in that process, because open source operations is the new thing. It's like, you know DevOps became OpsDev or something like that is the trend. >> Yeah, and I'm glad you brought that up you know I think about the DevOps movement, really fused security, it can't be a bolt on it can't be an afterthought. The mantra I've heard over the last few years, is security is everyone's responsibility. Dave Larson, you know, the question I have for you is, how do we make sure, you know, policy is enforced you know, even I think about an organization everyone's responsible for it, you know, who's actually making sure that things happen because, you know, if everybody's looking after it, it should be okay. But, you know, bring us down a little bit from the application standpoint. >> Well, I would say, you know, first of all, you have to narrow the problem down, right? The more we try to centralize security with discreet appliances, that's some kind of a choke point, the explosion, the common editorial explosion of policy declaratives that are necessary in order to achieve that problem to achieve the solution becomes untenable, right? There is no way to achieve the right kind of policy enforcement unless we get as close to the actual workloads themselves, unless we implement a zero trust model where only known and authorized end points are allowed to communicate with each other, you know. We've lived with a really unfortunate situation in the internet at large, for the last couple of decades where an IP address is both a location and an identifier. This is problem because that can be abused. it's something that can be changed. It's something that is easily spoofed, and frankly the nature of that element of the way we connect applications together is the way that almost virtually all exploits, get into the environment and cause problems. If we move to a zero trust model where the individual end points will only speak with only respond to something that is authorized and only things that are authorized and they trust nothing else, we eliminate 95 to 99% of them problem. And we are in an automated stance that will allow us to have much better assurance of the security of the connections between the various endpoints and services. >> Excellent, so, you know, one of the questions that always comes up, some of the pieces we're talking about here are open source. You talk about security and trust across multiple environments. How does HPE differentiate from, you know, everything else out there and, you know, how are you taking the leadership position? I'd love to hear both of your commentary on that. >> Yeah, well, like I said, initially, the real differentiation for us is that HPE was the market leader for industry standard servers, from a security perspective. Three years ago in our ProLiant gen 10 servers, when we announced them, they had the Silicon root of trust and we've shipped more than a million and a half servers into the market with this capability that is unique in the market. And we've been actively extending that capability so that we can project the identity, not just to the actual hardware itself, but that we can bind it in a multi-factor sense, the individual software components that are hosted on that server, whether it's the operating system, a hypervisor, a VM, a container framework, or an actual container, or a piece of it code from a serverless perspective. All of those things need to be able to be identified and we can bring a multi-factor identity capability to individual workloads that can be the underpinning for this zero across connection capability. >> Great and David, anything you'd like to add there? >> No, like what he said I think HP is uniquely positioned you know, the depth and the breadth of our installed base of platforms that are already zero trust ready, if you will, right. Coupled with the identity technology that we're developing in the context of the Cytel acquisition and David, my work in a building, the cloudless trust fabric, you know, are the, like I said, the cornerstones of these architectures, right? And HP has a couple of unfair advantages here you know, okay breadth and depth of our, the customer base and the installed base of the system is already put out there. While the world is transitioning, you know, inevitably to these, you know, these kinds of security architectures, these kinds of IT infrastructure architectures, HP has a, you know, a leadership team position by default here that we can take advantage of. And our customers can reap the benefits of without, well, you know, without you know, rebuilding forklift upgrading, or otherwise, you know, it is, yeah as Dave talked about, you know, a lot will change, right. There's more to do, right? As we move from, you know, IP addresses and port numbers, as identities for security, because we know that perimeter security, network security like that is busted, right. It is, you know, every headline making, you know, kind of advanced persistent threat kind of vulnerabilities it's all at the root of all those problems, right. There are technologies like OPA, right you know, policy has to be reframed in the context of workload identity, not in network identity know. Like call this legal sort of the microsegmentation fallacy, right. You know that, you know, perimeters are broken, not a valid security strategy anymore. So the answer can't be, let's just draw smaller perimeters, especially since we're now filling them up with evermore, you know, dynamic evanescent kind of workload endpoints, you know, containers coming and going at a certain pace. And serverless instances, right. All of those things springing up and, and being torn down, you know, on, you know, very short life cycle that's right. It is inconceivable that traditional, you know perimeter based micro-segmentation based security frameworks can keep up with the competent tutorial explosion and the pace with which we are going to be where, you know, orchestration frameworks are going to be deploying these end points. There are, you know, there's a lot more to do, you know, but this is, the transformation story. This is of the 2020s, you know, infrastructure, IT infrastructure school is very different in two, five, 10 years from now than it does today. And you know that's you know we believe HP has, like I said, a few unfair advantages to lead the world in terms of those transformations. >> Excellent, well, appreciate the look towards the future as well as where we are today. Dave and Dave, thanks so much for joining. Thank you, Stu. >> Thanks, dude, pleasure. >> All right, we'll be back with lots more coverage. HPE Discover 2020 the Virtual Experience. I'm Stu Miniman and thank you for watching theCUBE. (upbeat music)

>> Live from Orlando, Florida, it's theCUBE, covering .conf 18. Brought to you by Splunk. >> We're back in Orlando, everybody, at Splunk .conf18, #splunkconf18. I'm Dave Vellante with my co-host Stu Miniman. You're watch theCUBE, the leader in live tech coverage. We like to go out to the events. We want to extract the signal from the noise. We've been documenting the ascendancy of Splunk for the last seven years, how Splunk really starts in IT operations and security, and now we hear today Splunk has aspirations to go into the line of business, but speaking of security, Gary Mikula is here. He's a senior director of cyber and information security at FINRA, and he's joined by Siddharta "Sid" Dadana, who's the director of information security engineering at FINRA. Gentlemen, welcome back to theCUBE, Gary, and Sid, first-timer, welcome on theCUBE. So, I want to start with FINRA. Why don't you explain, I mean, I think many people know what FINRA is, but explain what you guys do and, sort of, the importance of your mission. >> Sure, it's our main aspiration is to protect investors, and we do that in two ways. We actually monitor the brokers and dealers that do trades for people, but more importantly, and what precipitated our move to the Cloud was the enormous amount of data that we have to pull in daily. Every transaction on almost every US stock market has to be surveilled to ensure that people are acting properly, and we do that at the petabyte scale, and doing that with your own hardware became untenable, and so the ability to have elastic processing in the Cloud became very attractive. >> How much data are we talking about here? Is there any way you can, sort of, quantify that for us, or give us a mental picture? >> Yeah, so the example I use is, if you took every transaction that Visa has on a normal day, every Facebook like, every Facebook update, and if you took every Twitter tweet, you added them altogether, you multiplied it by 20, you would still not reach our peak on our peak day. >> (laughs) Hence, Splunk. And we'll talk about that but, Sid, what's your role, you got to architect all this stuff, the data pipeline, what do you... >> So, my role is basically to work with the webs teams, application teams to basically integrate security in the processes, how they roll out applications, how they look at data, how they use the same data that security uses for them to be able to leverage it for the webs and all the performances. >> So, your mission is to make sure security's not an afterthought, it's not a bolt-on, it's a fundamental part of the development process, so it's not thrown over the fence, "Hey, secure this application." It's built in, is that right? >> Yes. >> Okay. Gary, I wonder if you could talk about how security has changed over the last several years. You hear a lot that, well, all the spending historically has been on keeping the bad guys out the perimeter. As the perimeter disappears, things change, and the emphasis changes. Certainly, data is a bigger factor, analytics have come into play. From your perspective, what is the big change or the big changes in security? >> So, it's an interesting question. So I've been through several paradigm changes, and I don't think anyone has been as big as the move the Cloud, and... The Cloud offers so much opportunity from a cost perspective, from a processing perspective, but it also brings with it certain security concerns. And we're able to use tools like Splunk to be able to do surveillance on our AWS environments in order to give us the confidence to be able to use those services up there. And so, we now are actually looking at how we're going to secure individual AWS services before we use them, rather than looking to bring stovepipe solutions in, we're looking to leverage our AWS relationship to be able to leverage what they've built out of the box. >> Yeah, people oftentimes, Stu, talk about Cloud security like it's some binary thing. "Oh, I don't want to go the Cloud, because Cloud is dangerous" or "Cloud security is better". It's not that simple, is it? I mean, maybe the infrastructure. In fact, we heard the CIA, Stu and I were in D.C. in December, we heard the CIO of the CIA say, "The Cloud, its worse day is better than my client's server from a security perspective." But he's really talking about the infrastructure. There's so much more to security, right? >> Absolutely, and, so I agree that the Cloud gives the opportunity to be better than you are on PRAM. I think the way FINRA's rolled out, we've shown that we are more secure in the Cloud than we have been on traditional data centers, and it's because of our ability to actually monitor our whole AWS environment. Everything is API-based. We know exactly what everybody's doing. There's no shadow IT anymore, and those are all big positives. >> Yeah, I'm wondering how you've, what KPIs you look at when you look at your Splunk environment. What we hear from Splunk, you know, it's scalability, cost, performance, and then that management, the monitoring of the environment. How are they doing? How does that make your job easier? >> So, I think we still look at the same KPIs that Splunk advertises all the time, but some of the reasons, from our perspective, we kind of look at it in terms of, how much value can we give it to not just one part of the company, but how can we make it much more enhanceable part for everyone in the organization. So, the more we do that, I think that makes it a much better ROI for any organization to use a product like this one. >> You guys talk about the "shift left" movement. What is "shift left" and what is the relevance to security? >> Yeah so, "shift left" is a concept where, instead of looking at security as a bolt-on, or an add-on, or a separate entity, we're looking to leverage what are traditional DevOp tools, what are traditional SDLC pipeline roles, and we're looking at how we integrate security into that, and we use Splunk to be able to integrate collection of data into our CDCI pipelines, and it's all hands-off. So, somebody hits a button to deploy a new VPC and AWS, automatically things are monitored and into our enterprise search, I'm sorry, enterprise security SIM, and automatically being monitored. There's no hands-on that needs to be done. >> So, on a scale of one to five, thinking of a maturity model in terms of, in a DevOps context, five being, you know, the gold standard and one being you're just getting started. Where would you put FINRA on that spectrum, I mean, just subjectively? >> So, I'll never say that we're a five because I think there's always, >> You're never done. >> You're never done and there's always room for improvement, but I think we're at least a strong four. We've embraced those concepts, and we've put them into action. >> And so, I thought so, and I want to ask you from a skill standpoint how you got there. So, you've been around a long time. You had a Dev team and an Ops team before the term DevOps even came around, right? And we talk about this a lot, Stu. What did you do with the Ops guys and the Dev guys? Is it OpsDev or DevOps? Did you retrain them? Did you fire them all and hire new people? How did you go through that transition? >> Yep, that's a fair thing. I went to my CISO John Brady a couple of years ago and I told him that we were going to need to get these new skill sets in, and that I thought I had the right person in Sid to be able to head that up, and we brought in some new talent, but we also retrained the existing talent because these were really bright people, and they still had the security skills. And what Sid's been able to do is to embrace that and create a working relationship with the traditional DevOps teams so that we can integrate into their tools. >> So, it does include a little bit work even on our end to do where you kind of learn how the DevOps forces work, so you've got to do it on your own to first figure out things and then you can actually relate to the problems which they will go through and then you work through problems with them, rather than you designing up a solution and then just say, "Hey, go and implement it out." So, I think that kind of relationship has helped us and in the long run, we hope to do a bit better work. >> Yes, Sid, can you bring us in a little bit, when you look at your Splunk deployment, FINRA'S got a lot of applications, how do you get all those various applications in there? You know, Splunk talks about, you can get access to your data your way, do you find that to be the reality? >> Yes, to a certain extent, so... Let's take a step back here. So our design is much more hybrid-oriented. So, we use Splunk Cloud, but that's primarily for our indexers whereas we host our own sort of class receptor. All the data basically goes in from servers from AWS components, from on-prem, basically it flows into our Splunk Cloud indexers, and we use a role-based access management to actually give everyone access to whatever data they need to be looking at. >> Alright. The number of enhancements from 702, updates, the Cloud, Gar-Gar, is there anything that's jumped out that's going to architecturally help your team? >> So, I think one of the interesting things is the new data pipeline, and to be able to actually mangle that data before I get it into my Splunk indexers is going to be really really life-changing for us. One of the hard parts is that developers write code and they don't necessarily create logs that are event-driven. They don't have date-time stamps, they do dumps. So, I'm going to be able to actually massage that before it hits the indexers, and it's going to speed up our ability to be able to provide quick searches because the indexers won't be working on mangling that data. >> And how big of a deal is it for you? They announced yesterday the ability to scale storage and compute separately in a more granular fashion, is that a big deal for you? >> So, I actually, I remember speaking to Doug Merritt probably three years ago. >> You started this! (laughing) >> And I said, "Doug", I said, "I really think that's the direction that you need to go. You're going to have to separate those two, eventually, because we're doing a petabyte scale, we realized very early that that'd need to be done. And so, it's really really refreshing to see, because it's going to be transformative to be able to do compute-on-demand after that. Because now we can start looking at API brokers, and we can start looking at containers, and all those other things can be integrated into Splunk. >> Love having customers on like you guys, so knowledgeable. I have to ask, switch gears a little bit, I want to ask you about your security regime. We had a customer on yesterday, and it was the CISO who reported to him. He was the EVP, and he reported to the CIO. A lot of organizations say, "You know what? We want the CISO to be separate from the CIO. Cause it's like the, you know, the fox in the henhouse kind of thing. And we want that a little bit of tension in there." How do you guys approach it? What's the regime you have for... >> That is a fair question, and I've heard that from many other CISOs that have that same sort of complaint. And I think it's really organization-based. And I think, do you have the checks and balances in place? First of all, our CIO, Steve Randich, is extremely, he cares a lot about security, and he is very good at getting funding for us for initiatives to help secure the environment. But more importantly, our board of directors bring up security at every board event. They care about it, they know about it, and that permeates through the organization. So there's a checks and balances to make sure that we have the right security in place. And it's a working relationship, not adversarial at all, so, having our CISO John Brady report to Steve Randich, the CIO, has not been a hindrance. >> And I think that's a change in the last several years, because that regime that I described, which was, there was sort of a wave there, where that became common, and I think you just hit on it. When security became a board-level issue, and for every Fortune 1000, Global 2000 company, it's a board-level issue. They talk about it every board meeting. When that occurred, I think there was an epiphany of, "We need the CIO to actually be on this." And you want the CIO to be responsible for that. And the change was, it used to be, "Hey, if I fail, I get fired." And I think boards now realize that "failure" in security doesn't mean you got breached. >> Sure. >> You know. Breaches are going to happen. It's how you respond to them and, you know, how you react to them that is becoming more important. So there's much more transparency around security in our view. I wonder if you agree with that. >> I think there's transparency. And the other thing is is that you have to put the decision-making where it makes the most sense. Most of the security breaches that we're talking about are highly technical in nature, where a CIO is better able to evaluate some of those decisions, not all companies have a CEO that came from a technology train in order to be able to make those decisions. So, I think it makes more sense to have the CISO report to somebody in the technology world. >> Great, thank you for that. Now, the other question I have for you is, in terms of FINRA's experience with Splunk, did it start with SecOps and security, or was it, sort of, IT operations, or...? >> It did, it started with security. We were disenfranchised with traditional SIMs that were out there, and we decided to go with Splunk, and we made the decision that security was going to own it, but we wanted it to be a corporate asset from day one. And we worked our tails off to integrate, through brown bags, through training. So we permeated through the organization. And, on any given week, we pull about 35-40% of all of technology is using Splunk at FINRA. >> So, I'm curious as to, we heard some announcements today, I don't know if you saw them, about, you know, Splunk Next, building on that, Splunk for the line of business, the business flow, they did a nice demo there. Do you see, because security sort of was the starting point, and your mission was always to permeate the organization, do you see that continuing to other parts of the organization more aggressively now given this sort of democratization of data for the business lines, and... Will you guys be a part of that, directly? >> We hope so. We hope we are part of that change, too. I mean, the more we can use the same data for even business users that will help them, that would relieve a lot of, and they made this point again and again in the keynote, too, that, the It Ops and SecOps are already burdened enough. So, how do we make life easy for business users who actually leverage the same data? So we hope to be able to put these tools up and see if it can make any difference to business users. >> So, you guys have put a lot of emphasis on integrating with Splunk and AWS Cloud. You have a presentation later on today at .conf18 around the AWS Firehose that you have with Splunk. What's that all about? What's the AWS Firehose? How are you integrating it? Why is it important? >> So, it is streaming and it allows me to get information from AWS that's typically in something called the CloudWatch Logs, that is really difficult to be able to talk to. And I want to get it into the Splunk so I can get more value from it. And what I'm able to do is put something called a subscription filter on it, and flow that data directly into Splunk. So, Splunk worked with AWS to create this integration between the two tools, and we think we've taken it to a high level. We use it for Lambda, to grab those logs, we use it for VPC Flow Logs, we're using it for SaaS Providers, provide APIs into their data, we use it for that, and finally, we're going to be doing database activity monitoring, all leveraging this same technology. >> Love it, I mean, you guys are on the forefront of Cloud and Splunk integration, Cloud adoption, DevOps, you guys have always been great about sharing your knowledge, you know, with others, and we really appreciate you guys coming on theCUBE. Thank you. >> Thanks for having us. >> You're welcome. Alright, keep it right there, everybody. Stu and I will be back. You're watching theCUBE from .conf18, Splunk's big user conference. We'll be right back. (electronic music)

>> Announcer: Live from Las Vegas, it's theCUBE, covering ServiceNow Knowledge 2018. Brought to you by ServiceNow. >> Hello everyone and welcome back to theCube's live coverage of ServiceNow Knowledge 18 here in Las Vegas. I'm your host Rebacca Knight along with my co-host Dave Vellante, and we are theCube. We are the leader in live tech coverage. We're joined by Sean Caron. He is the principal architect of Linium, at Linium. Thanks so much for coming on theCube again, you're welcome back. >> My second time, and thank you very much for the opportunity. I've really been looking forward to it all week. >> Awesome, Good to have you back. >> We love to hear that. So tell us about Linium and what you do as principal architect. >> Sure, so we are a gold services and sales partner of ServiceNow. Been in the ServiceNow space for about nine years total. And we specialize in helping organizations do digital transformations. So they want to take the platform and really get maximum value from that and that's both a technology discussion, but it's also a organizational change discussion, and you know can be a process discussion. All those kind of things are things that we help our customers with. >> We've been talking a lot about the technology but the organizational change is really what fascinates me. Can you tell, can you just talk about a lot of the organizational change challenges that customers are facing, and they come to you. >> You've got it right. So we've been in this business for 18 years. We started out as a Peregrine partner and also HP, when HP acquired Peregrine, and we noticed that we would get specs from customers and we would nail it. It would be a perfect technical delivery and then six months later when you talk to the customer, they weren't using the product. They didn't get any value from the investment that they made. So we started to engineer a process and we do that around, you know we look at the structure. Where is this project going to land? What's the structure around it? Who supports it? What's your culture? Do you have a culture of dedication to accuracy or customer service? If you don't have those kind of things, we can help build those in your organization. And of course that also gets to helping you find talent, right. So if you need the right people, we can help with that process. Helping you define business best practice process for your organization. Those are all things we work with customers every day and frankly we don't do technology projects. We only do a project where we know when we deliver the technology that that structure will be there to catch it and get value from it. >> So you were recently acquired by Ness Digital Engineering, >> Correct >> Which is really an interesting name for a company. Tell us more about the motivation for that acquisition and how things have changed, and what the future looks like. >> So for the first 17 years of our business we were a privately held company and we grew organically, and we did a great job at that. I mean we became several hundred employees across the U.S. and a couple in AMIA, and a couple in Canada. But to really take the next step right, we saw, we had a vision of what we wanted to do, to take that next step was going to require an equity investment of some type. So we started probably about this time last year, talking to organizations. Ness was one of the first ones that we met and it became immediately apparent that they were a great fit for us. So they have about, well with us about 4,000 people across the world. They're not a billion dollar company right. So their culture is very similar to our culture. They do digital engineering projects, industrial scale, you know hard core grade digital engineering projects, and they tend to focus on platforms that are front of the business, so customer touching. They own the platform under Standard & Poor's right, so they built that. So Standard Poor's ratings, all that information flows in, they do the ratings based on that. That's something they built. PayPal, they do a lot of work in the payments industry. But they didn't really do much on the backend right. The operations that keep all the lights on and obviously that's a great fit for Linium, where we would come in with the ServiceNow platform and help them with that process. So that really worked out well. It was a great fit for us. >> So how do you guys compete? What's your difference relative to, you've been here a while in this ecosystem. It's started to get crowded. How do you, what's your secret sauce? How do you guys compete? >> So our goal is always to try and stay 12 months ahead of where ServiceNow is going. In the past couple of years, that really has been around user experience. Really designing experiences with the platform that are intuitive, that don't require a lot of training, that allow people to approach the platform and get value from it very quickly. Whether that's end users, or our customer's customers. Those kind of things, really, and that's in our DNA. That's a big part of what we do is design these experiences and do them in a way that really help our customers get value. I would say, you know looking forward, so the buzzword that we've heard around here this week is DevOps right, and we see, and one of the things that Ness does very well is DevOps engineering. I think next year will be the knowledge of DevOps. It will be what everybody's talkin' about. ServiceNow will have a lot more throw-weight in that space. So really that's where we're going. We're helping people get that continuous integration, continuous deployment process using ServiceNow as a foundation. >> CJ Desai laid out the roadmap in more detail than I had seen publicly anyway, and we were talking to him and he said, "Look the motivation really came from the ecosystem." You know obviously the customers as well, but the ecosystem as well, wanted better visibility on what was coming, because you guys have to plan for that. You're tryin' to fill white space. You're tryin' to fill a vacuum. So I wondered if you could talk about that. It's a two-edged coin though right? I mean, but having that visibility has to be a godsend. >> Right and we found that when we are some number of months ahead of ServiceNow, we work very well with them. We, you know obviously, like any large ServiceNow partner, we're very plugged in to where they're going. Their roadmap sets our direction and the kind of things that we can do. But it enables conversations, especially DevOps, and user experience too, enabled conversations at new levels within the organization and that's a big differentiator for us. >> But so, what I'm trying to understand is you guys have to make a call on where to put your investments and your resources, and you don't want to, you've said a couple of times, you're ahead of ServiceNow by, let's say N months, six months, 12 months, 9 months, whatever it is. You don't want to develop something and put too much into something that they're just going to replace in a few months. >> Right. >> Dave: So how do you keep that innovation engine going on your end? >> That right, so it takes a lot of research. We have a person whose dedicated job at our organization is Chief Innovation Officer. She spends her entire day talking to customers, hearing what buzzwords are in the industry, looking and talking to ServiceNow, looking at where they're going. So how can we be positioned when ServiceNow gets there 'cause to deliver services, that's not an instant on right. If the technology shows up tomorrow in the next release, to be able to deliver services for that, you have to start well in advance to actually be able to do that, to understand the process, and the structure, and what's required. >> I see, okay so by being ahead of ServiceNow, what you mean is you're going to develop capabilities that plug in to their release when it hits. >> So that we can deliver to what they have, >> Not things that are duplicative, but things that are, add value when it hits. >> Yeah, I mean ServiceNow comes out with, let's say automated testing. That's something they want to really, they want to get into the automated testing market. That's a discipline. You can't be instant on with that and if you want to have credibility with customers, you have to have trained people. You've got to be six months ahead to be able to step into that world and get value from the platform. >> So take the DevOps example that we heard Pat Casey talk about yesterday. So you guys are preparing for that now obviously. >> Yes. >> And how will you go about it? How will that change your customers world? If can take us through an example. >> So obviously DevOps is, you know it's the big accelerator. It's the idea of we're going to do what we've always done and we're going to do it in timeframes that are minutes or hours, as opposed to weeks, or months, or even years right, so it's a big ramp up. So understanding how to put that in play is a big deal. If you're a startup, alright so one of the themes of DevOps is the two pizza team right. You should never have teams bigger than you can feed with a couple of pizzas. If you're a startup and you already got a two pizza team it's easy to do DevOps. You build it into your culture and away you go. But our customers, you know many of our customers, one we were talkin' about here, talking to here at the show, 130 year old firm and they want to do DevOps. So what's that on-ramp? How do you figure that out? One of our new colleagues from Ness, who has been in the DevOps world for a while says, "You know, it's all about unlearning stuff." Because in order to move into this world, you got to unlearn that old world. >> Well right, it is a mindset. >> It is, it's a culture. >> So how, and one that will be very tricky for a 130 year old firm that maybe doesn't order pizzas that often (chuckling) for it's team. So how do you do that? I mean that's a challenge. >> We're working diligently on having a roadmap to onboard DevOps into existing organizations. The secret really tends to be, start with a NET new project and introduce DevOps into those kind of projects. Build one, build two, build three now you've got a culture of DevOps and you can start then to do some of the unlearning and the retrofitting right. But it's very difficult. You can't really take an existing projects and transform how they do their work. Which is what DevOps is all about. >> No, but in a lot of the companies that I've talked to that have, you know hundred plus year old companies that want to do DevOps right. A lot of times, and I wonder if this has been your experience, it's the Ops guys learning Dev, as opposed to the Dev guys learning Ops. I mean the Dev guys like, "Yeah, yeah we can do infrastructure as code, that's fine", but then you've got all these Ops guys runnin' around. So it's a urgency to retrain the Ops guys, who are eager to learn, most of 'em. The ones that aren't probably in trouble. >> Will do something else. >> So I often joke about OpsDev versus DevOps. What's your experience? >> So I think the big difference is Ops guys are trained from the day they take that job to, you know shun failure right. Failure of a system is a big problem. In DevOps it's going to happen. Not only is it going to happen but the best DevOps practitioners create failure. >> Break stuff (laughing) >> Yeah, you know Netflix kind of has this famous program called Chaos Monkey, when it runs running, turn stuff off right, and how do you respond to that. And that's a big leap culturally and structurally for the Ops guys to get over that. You know the idea is we break stuff, but we learn from that, and not only do I learn from that, but I spread that knowledge across the organization. And that's where ServiceNow steps in right, because they know when things are broken, 'cause they're tied to monitoring, and they got this great knowledge capability to hook up the information we learn from how that broke. So what better testing could we have done so that we could have avoided that break? Or if it's a enforced break, what could we have learned about how to respond to that more quickly? You know the classic example is when AWS lost their east availability center and Netflix kept tickin' because they had lost their east availability center through Chaos Monkey a half a dozen times. >> Right >> It was old hat, and everybody else kind of went dark right. So that idea, and enabling that with the ServiceNow platform is a great opportunity. We really see ServiceNow as the context, the engine with all the knowledge about when things happen, how to fix them, and how to record the knowledge that you learn. >> Give us an example of a company, I mean you're talking about simple, streamlined, intuitive tech, no-training required, so give us some examples of some of the most creative uses. >> I'll give you a great example. So, we have a center in Atlanta. We have some folks in Atlanta. And of course if your in Atlanta, you love Chick-fil-a, and maybe if you're anywhere else you love Chick-fil-a. And they had an issue, which was they have franchisees, and their franchises are different from McDonald's, where you might have one franchisee at McDonald's that owns 200 restaurants. They have a lot of power, market power, and they don't share information with any other franchisee, 'cause that's differentiating for them. Chick-fil-a doesn't do that. The maximum number of restaurants you can own as a Chick-fil-a franchisee I believe is three. It's a number like that. So their franchisees are incented to talk to each other and share information. "Hey I found a better way to clean the ice cream machine", or something like that or to fix a problem. So they were looking to build a portal that they could use to both answer questions from the organization to the franchisees, but allow the franchisees to talk to each other. That kind of a thing has to be zero training right, because the people who are on that might be store managers, but it could be, you know the teenager who runs the point of sale terminal and is havin' a problem with that, so it's really got to be intuitive. So we spent a lot of time with them. We actually, it was we brought one of our designers, so we have UI, UX designers, experience designers, and we were in the sales meeting, and we're having a discussion about what they need, and he's kind of heads down typin' on his computer. And they're kind of lookin' at him like, what's up with this guy right, he's not payin' attention. >> He's designing the interface. >> These guys pay attention to everything. He's lookin' at the logo as we're walkin' in, the colors that are on the wall, the way they talk about themselves. So about an hour into the meeting we got a pause and he just kind of picks his head up and goes, "You mean like this?" And turned his computer around and he had a prototype that he built in the meeting of this really easy to use process. >> Very cool. >> Sean: So that was our intro to Chick-fil-a. >> Your sales guy must'a hated that. (hosts laughing) >> No, no, it was, I'll tell you what, so it was competitive, we have multiple competitors, who were going for that business, when he turned that computer around, the sale was done. >> Dave: Boom. >> We were done, right. They looked at that and said, This is, you know it's not perfect clearly, but this is what we need. >> This is the kind of company we want to work with. >> Exactly, well and that, you know part of that is there are partners in the ecosystem who come in and say, "We can do anything. "Tell us what you want." We are much more consultative and we'll come in and be prescriptive and say this is what you should do, and it's a differentiator for us. It's something we do differently. >> Well Sean that's a great note to end on. Thanks so much for coming on theCUBE again. >> It's been great, I really enjoyed my time. >> We'll look forward to having you back at Knowledge 19. >> Terrific, I will certainly be here. >> Great, I'm Rebecca Knight for Dave Vellante. We will have more of theCUBE's live coverage of ServiceNow Knowledge 18 in just a little bit. (electronic 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 Las Vegas, it's the CUBE covering HPE Discover 2017. Brought to you by Hewlett Packard Enterprise. >> Okay, welcome back everyone. We are live here in Las Vegas for SiliconANGLE Media's theCUBE's three-day exclusive coverage of Hewlett Packard Enterprise, HPE Discover 2017. I'm John Furrier with my co-host, Dave Vellante. Our seven-years covering HPE, and we have our next guest whose been on the job for seven weeks, Parvesh Sethi, Senior Vice-President of HPE Pointnext Consulting. Industry veteran of cloud. You understand what's going on. Appreciate you coming in and sharing-- >> Thank you for having me. >> Your talking points with seven weeks on the job, but you're new to HPE, welcome to theCUBE. So fresh in to HPE, got a fresh eye. You've been around the industry for a while. What is the hybrid journey for HP? Because you were just in the Q&A with Meg and Antonio with the press and the analysts, and still people are trying to put it together. Like, with no cloud, how do you guys fit in this? So, hybrid cloud, simplifying hybrid IT. They're not saying simplifying hybrid cloud, simplifying hybrid IT, which implies cloud. >> Exactly, I think the approach that I would take is if you look at the role of the IT, it's really changing. I mean, you can consider IT to be the strategic sourcer now. It's no longer we built it, we own it, we run it, because now they're really managing a supply chain. So, you're looking at the private cloud, public cloud, and people having the highly-automated infrastructure, or software-defined infrastructure, and legacy b-spoke systems. The job of the IT is really getting very complex. When you heard Meg talked about making hybrid IT simple, so for Pointnext Consulting standpoint, it's really working with the clients about making that journey much more simpler, and making sure it's not just simple, but the speed is there. Also we'll ask that we are focused on the workloads to really moving the workload securely. Because, at the end of the day, the whole journey is really centered around the workload-side of the house. >> And your role is, am I correct, is tip-of-the-spear consultant? Is that right, and strategy consulting? >> That's correct. It includes the consulting and the professional service portfolio. >> So, help us understand, because when EDS went to CSE with the spin-merge, all of the sudden you're seeing Accenture, Deloitte, and others come out of the woodworks. And this is their wheelhouse, in strategic consulting, so where do you pick up, and how do you relate to those guys? >> Yeah, no, it's a great question. In fact, it's with the spinoffs, it's also given us a great opportunity to really work with number of the SIs, and so we're have a close work relationship with number of them, and the way I look at the strategic consulting, where we add value is really more around the technology consulting piece of it. And because that's where we feel that we can really add differentiation. And partnering with some of our SIs, that's where they can help us from the verticalization piece of it, the business process side of it, because that's not really our core strength. Our core strength is really around the technology consulting, and also being around, and dealing with, and doing 11,0000 plus engagements every year. From Pointnext perspective, that's lot of experience that we bring to the table partnering with the ecosystem, we truly bring some of these outcome-based solutions that we keep referring to. >> Dave's team at Wikibon has put out some pretty seminal research. I think it's very unique. I don't think any other research firm has actually documented this, even captured the numbers. But, they just did a report called The True Private Cloud Report, go to wikibon.com for the folks watching, but really what it illustrates is that IT is not declining, it's only increasing in its capabilities. So, yes, server shipments might be declining, but, at the end of the day, IT is changing and growing with cloud. But one of the points in that survey is the TAM is 260 billion plus in true private cloud. And that doesn't include hybrid. But, the other statistic besides the TAM is the fact that the labor costs are undifferentiated, and being automated away with cloud, which is a good opportunity. And then the shifting of those resources to differentiated apps or services is the focus. That's business transformation. That's what you guys are doing. Share with us your thoughts, and how you guys look at that. Obviously, you're only seven weeks in from an HP perspective but you been in the industry. How are you guys going to attack that trend, and ride that wave of shifting that to differentiated capabilities? >> Yeah, I think so one of the things you always hear about from a technology standpoint, lot of folks focus on just the technology piece of it. What we're finding is when we engage with the clients, it's really taking a look at, even before the technology, it's what is the strategic framework. Why do so many digital transformation projects stall, or fail? Because there's no interned alignment in terms of business, IT, and OT side of the house, so what you're seeing is from the consulting side of the house is kind of making sure that we bring these things together. And we have a methodology called Unified Transformational Framework, UTF, which has seven key domains, and one of the first things we do when we engage with the client, we bring them together, business side of it, the IT side of it, and we assess where they're at today in each one of those domains, and assess the gaps. We actually put together a strategic framework with them in terms of what is the desired state where they want to be, where they're at today, and how do we map out that cloud journey together with them. And, more importantly, what are the key outcomes they are really seeking. And so if they are looking at focusing on achieving certain cost-efficiency, or launching new services faster, or securing information network, or from an IOT perspective, what are the specific use cases, like for oil and gas, you may have heard some of the examples here with Tech Smart on refinery of the future. What are some of the outcomes they're looking for, and then kind of working backwards to make sure that we can take them on that journey roadmap, and accelerate that whole journey. It's the time to value equation. >> So it would seem like the hybrid IT message that you guys provide is the foundational infrastructure for a digital transformation. Okay, sounds good, now, let's peel that back a little bit. Because, if I'm an executive in a board, I'm saying, "Okay, great, how do we get started, "how do we pay for it?" You come in with your maturity model, here's where you guys are at. How much of that conversation is around the data? And data, data value, how to monetize data, how it contributes to whatever objective, raise revenue, cut costs, et cetera. How much of the conversation do you anticipate is going to be around that data? >> No, it actually is quite a bit of floor discussion on the data as well. So, I'll take it in steps of there's two main types that come up. One is really around the workloads as to enterprises have hundreds, thousands of applications running but not every application, not every workload needs to move to a public cloud or private cloud. Some of them may be more suited towards just a dedicated infrastructure that they already have. One of the first things we focusing on through the tool, we do an inventory, as well as through the interviews. Because one path doesn't give you all the information that you seek. Synthesizing the two really gives you the full picture. And, then on top of it, more and more data is getting generated at the edge, and so in terms of what do you do with the data, how can you help them drive a real-time action, and then what can you do to monetize on that data, just like the example with the M1GD team that's been showcased here, that's not just change the fan experience, it's also helping them taking the look at the data, the loyalty, and everything else, and then increasing opportunities to drive top-end growth from the revenues in the concession stand, or promotional material, your absolutely right, the focus is more about not just guarding the data, the data production, data consumption, it's how do you monetize on that piece of it. >> And does HPE focus more on the IT transformation, and your partners like the big SIs on the business transformation, or no, is it not that simple, it's not that clear? >> Yeah, I mean, it's hardly just kind of say, okay, those are in their silos because there's that intersection point that really drives additional transformation. That's one thing that I think we are uniquely positioned, because number of these solutions you see on the demo floor here who are jointly partnered up with our ecosystem, and that really drives that value up from the business outcome standpoint, it's not just what the technology is able to do, it's not just, yeah, if we're able to have a faster server, this then that, it's really more about what will that enable. In turn, what is the business outcome that's enabling. >> But I would imagine your partners are deep experts in some healthcare business process that HPE doesn't possess, then you guys, from a technology standpoint, can go much deeper than they can. My question is how much of the conversation from your partners has been, or do you expect it to be, "Hey, you know what, if you could do this, you know, "with the technology, you know, we can really "help this company, and win a large deal," for example, which is a semi-custom, you know, and it requires a deep technological expertise to marry with that business process. >> No, absolutely, in fact, I was with a partner earlier, and actually what you just called out was very similar discussion with him. From a healthcare perspective, one of the things we can do, and we have done, where the picture in archiving communication system, we can package what one of the other providers does along with computing and for storage, package that up, and where the configuration provisioning time is reduced dramatically when they show up on site, everything is preconfigured. But, then jointly with a partner who has more knowledge about the patient experience. Marrying the two, you can actually see not just how the healthcare provider and the patient are going to interact, but how also the information that's generated there, how can that be analyzed at a remote location through a specialist. So it's that whole value chain that you can do with a partner that you're just not able to do yourself. >> Am I correct that you run a PNL, right, this is not a free-beat. >> That's correct, no. >> Okay. >> Yes, so from that standpoint we do work with the ecosystem where there is some investment made on the solution of it, but then, obviously, you take a look at does the solution make sense, is there a market for it, can you do the repeatability aspect of it, and, if the answer is yes, then certainly both starts get much more happily engaged. >> Parvesh, talk about the dynamic in digital transformation, specifically, around as companies really transform from being analog to digital. That basically makes them cloud service providers. >> Right. >> So if you have a sass-ification, that's kind of a shift, this is the shift in IT we're talking about, yeah, keeping the lights on, running servers in the data center, old way, classic enterprise. Portions of their operations now have to be shifted to this new way of doing IT to be a service provider, yet they're not service providers, but they're becoming one, or the end-user customer might buy from a partner that's becoming a service provider, either building their own cloud. Is that how you guys see it at Pointnext, and how are you nurturing this, or working with this mega-trend that's the cloud is enabling? >> Couple of things happens. I was with a client very recently, and they've been actually doing number of use cases, fifty plus use cases in the labs, and on the whole use cases around digital transformation. Each use case theoretically can generate millions of savings for them. By the same token, they haven't been able to take it out of the lab and mainstream it, so this goes back into the alignment piece of it, and then also the cultural and the organizational aspect always gets overlooked. Because if the focus is just on the solution piece of it, or digitalization of the workflow, and you have not the trends from the workforce in terms of how they should evolve, how the skillsets should evolve, and if certain roles are getting combined, how should they be dealing with that piece of it. We are talk about DevOps or OpsDev. It's really the whole notion around how they should be working differently than before. If that aspect of it hasn't been put a lot of focus on, most of these transformations literally stall or fail. >> You mean on the cultural piece of it. >> On the cultural piece of it, absolutely. This is another area that we put lot of focus on, and, in fact, one of the offers we rolled out, the management of change, is actually getting lot of traction just because of that reason. >> You know, one of the challenges that the companies that I talk to have is actually funding the digital transformation. The incentive to do it is well, if we don't do it, we're going to get uber-ized, okay. So people get that, but, at the same, then the CFO's are, "Okay, that's fine, "but how are we going to make money at this, "how are we going to actually pay for this?" And, really, for organizations that can show that type of path to profitability, if I may, it seems like it gets more traction, and has staying power. I wonder if you could comment on that. >> Well said. In fact, a number of the engagements we start off with, that discussion always comes up that we don't have any extra funds to go do this thing, but we have to do this thing in order to stay relevant. >> John: What do we do. >> Yeah, so one of the things we focus on is safe-to-invest initiatives. For example, you heard the example of ALDO Group, one of the large global retailers. The federate structure, and then moving towards where it can be had they can move towards a centralized as well as a global centers architecture that can help them drive more speed, cut down the provisioning time, cut down on the operating cost. When you have initiatives like that, the enterprises can then take those savings and then show the CFO that this is how we can apply those savings into these key initiatives that can continue to make us more relevant, and also transform the end-user experience, or their end-customer experience. So, I think as you do this on prioritized use cases, that gives you more credibility in the organization to go do lot more and much faster. >> So, final question for you. Observations, new to HPE, now, Pointnext, New to HPE Discover here, as an employee, what's your observation about HPE Discover, their position in the marketplace, vis-a-vis, the industry scope and trends that are out there? >> First of all, I think coming out here, this is my first Discover so I see a lot of excitement here, and I think up to the point that you made earlier, Dave, with the spun-offs, I think that has really opened up a lot of the doors where a lot of the partners say, "Look, this is something we can do more together of." So, every meeting that I've been with a customer since we're partners, they see us kind of where we're the top stack, who are not biased towards that, right, because this is not where we play, but we play more for roll out the solution aggregation, plus also bring lot that experience to really guide them on their journey. One of the things I constantly hear is if you can help us accelerate time to value, and you can help us drive the acceleration, because a lot of these initiatives stalling, help us on that journey, there's tremendous opportunity for both sides. So that's what we see lot of excitement here. Parvesh Sethi, Senior Vice-President, Pointnext, welcome to theCUBE, thanks for your commentary and insight. >> Thank you for having me. >> Appreciate it, good luck with your journey. This theCUBE bringing you all the digital transformation and conversations here at HPE Discover 2017. I'm John Furrier with Dave Vellante. We'll be right back. (upbeat music)

(lively techno music) >> Hello, everyone, I'm John Furrier with theCUBE. We are here in Palo Alto to showcase a brand new relationship and technology partnership and technology showcase. We're here with Niel Viljoen, who's the CEO of Netronome. Did I get that right? (Niel mumbles) Almost think that I will let you say it, and Nick McKeown, who's Chief Scientist and Chairman and the co-founder Barefoot Networks. Guys, welcome to the conversation. Obviously, a lot going on in the industry. We're seeing massive change in the industry. Certainly, digital transmissions, the buzzword the analysts all use, but, really, what that means is the entire end-to-end digital space, with networks all the way to the applications are completely transforming. Network transformation is not just moving packets around, it's wireless, it's content, it's everything in between that makes it all work. So let's talk about that, and let's talk about your companies. Niel, talk about your company, what you guys do, Netronome and Nick, same for you, for Barefoot. Start with you guys. >> So as Netronome, our core focus lies around SmartNICs. What we mean by that, these are elements that go into the network servers, which in this sort of cloud and NFV world, gets used for a lot of network services, and that's our area of focus. >> Barefoot is trying to make switches that were previously fixed function, turning them into something that those who own and operate networks can program them for themselves to customize them or add new features or protocols that they need to support. >> And Barefoot, you're walking in the park, you don't want to step in any glass, and get a cut, and I like that, love the name of the company, but brings out the real issue of getting this I/O world if there were NICs, it throws back the old school mindset of just network cards and servers, but if you take that out on the Internet now, that is the I/O channel engine, real time, it's certainly a big part of the edge device, whether that's a human or device, IoT to mobile, and then moving it across the network, and by the way, there's multiple networks, so is this kind of where you guys are showcasing your capabilities? >> So, fundamentally, you need both sides of the line, if I could put it that way, so we, on the server side, and specifically, also giving visibility between virtual machines to virtual machines, also called VNFs to VNFs in a service chaining mechanism, which has what a lot of the NFV customers are deploying today. >> Really, as the entire infrastructure upon which these services are delivered, as that moves into software, and more of it is created by those who own and operate these services for themselves, they either create it, commission it, buy it, download it, and then modify it to best meet their needs. That's true whether it's in the network interface portion, whether it's in the switch, and they've seen it happen in the control plane, and now it's moving down so that they can define all the way down to how packets are processed in the NIC and in the switches, and when they do that, they can then add in their ability to see what's going on in ways that they've never been able to do before, so we really think of ourselves as providing that programmability and that flexibility down, all the way to the way that the packets are processed. >> And what's the impact, Nick, talk about the impact then take us through like an example. You guys are showcasing your capabilities to the world, and so what's the impact and give us an example of what the benefit would be. I mean, what goes on like this instrumentation, certainly, everyone wants to instrument everything. >> Niel: Yes. >> Nick: Yeah. >> But what's the practical benefit. I mean who wins from this and what's the real impact? >> Well, you know, in days gone by, if you're a service provider providing services to your customers, then you would typically do this out of vertically integrated pieces of equipment that you get from equipment vendors. It's closed, it's proprietary, they have their own sort of NetFlow, sFlow, whatever the mechanism that they have for measuring what's going on, and you had to learn to live with the constraints of what they had. As this all gets kind of disaggregated and broken apart, and that the owner of the infrastructure gets to define the behavior in software, they can now chain together the modules and the pieces that they need in order to deliver the service. That's great, but now they've lost that proprietary measurement, so now they need to introduce the measurement that they can get greater visibility. This actually has created a tremendous opportunity and this is what we're demonstrating, is if you can come up with a uniform way of doing this, so that you can see, for example, the path that every packet takes, the delay that it encounters along the way, the rules that it encounters that determines the path that it gets, if it encounters congestion, who else contributed to that congestion, so we know who to go blame, then by giving them that flexibility, they can go and debug systems much more quickly, and change them and modify them. >> It's interesting, it's almost like the aspirin, right? You need, the headache now is, I have good proprietary technology for point measurement and solutions, but yet I need to manage multiple components. >> I think there's an add-on to what Nick said, which is the whole key point here which is the programmability, because there's data, and then there's information. Gathering lots and lots of telemetry data is easy. (John chuckles) The problem is you need to have it at all points, which is Nick's key point, but the programmability allows the DevOps person, in other words, the operational people within the cloud or carrier infrastructure, to actually write code that identifies and isolates the data, the information rather than the data that they need. >> So is this customer-based for you guys, the carriers, the service providers, who's your target audience? >> Yep, I think it's service providers who are applying the NFV technologies, in other words, the cloud-like technologies. I always say the real big story here is the cloud technologies rather than just the cloud. >> Yeah, yeah. >> And how that's-- >> And same for you guys, you guys have this, this joint, same target customer. >> Yeah, I don't think there's any disagreement. >> Okay. (laughs) Well, I want to get drilling to the whole aspirin analogy 'cause it's of the things that you brought up with the programmability because NFV has been that, you know, saving grace, it's been the Holy Grail for how many years now, and you're starting to see the tides shifting now towards where NFV is not a silver bullet, so to speak, but it is actually accelerating some of the change, and I always like to ask people, "Hey, are you an aspirin or you a vitamin?" One guest told me, "I'm a steroid. "We make things grow faster." I'm like, "Okay," but in a way, the aspirin solves a problem, like immediate headaches, so it sounds like a lot of the things that you mentioned. That's an immediate benefit right there on the instrumentation, in an open way, multi-component, multi-vendor kind of, benefits of proprietary but open, but the point about programmability gives a lot of headroom around kind of that vitamin, that steroid piece where it's going to allow for automation, which brings an interesting thing, that's customizable automation, meaning, you can apply software policy to it. Is that kind of like, can you tease that out, is that an area that you guys talking about? >> I think the first thing that we should mention is probably the new language called P4. I think Nick will be too modest to state that but I think Nick has been a key player in, along with his team and many other people, in the definition and the creation of this language, which allows the programmability of all these elements. >> Yeah, just drill down, I mean, toot your own horn here, let's get into it because what is it and what's the benefit and what is the real value, what's the upshot of P4? >> Yeah, the way that hardware that processes packets, whether it's in network interface cards, or in switching, the way that that's been defined in the past, has been by chip designers. At the time that they defined the behavior, they're writing Verilog or VHDL, and as we know, people that design chips, don't operate big networks, so they really know what capabilities to put in-- >> They're good at logic in a vacuum but not necessarily in the real world, right? Is that what you (laughs). >> So what we-- >> Not to insult chip designers, they're great, right? >> So what we've all wanted to do for some time is to come up with a uniform language, a domain-specific language that allows you to define how packets will be processed in interfaces, in switches, in hypervisor switches inside the virtual machine environments, in a uniform way so that someone who's proficient in that language can then describe a behavior that can then operate in different paths of the chained services, so that they can get the same behavior, a uniform behavior, so that they can see the network-wide, the service-wide behavior in a uniform way. The P4 language is merely a way to describe that behavior, and then both Netronome and Barefoot, we each have our own compilers for compiling that down to the specific processing element that operates in the interfaces and in the switches. >> So you're bridging the chip layer with some sort of abstraction layer to give people the ability to do policy programming, so all the heavy lifting stuff in the old network days was configuration management, I mean all the, I mean that was like hard stuff and then, now you got dynamic networks. It even gets harder. Is this kind of where the problem goes away? And this is where automation. >> Exactly, and the key point is the programmability versus configurability. >> John: Yeah. >> In a configurable environment, you're always trying to pre-guess what your customer's going to try to look at. >> (chuckles) Guessing's not good in the networking area. That's not good for five nines. >> In the new world that we're in now, the customer actually wants to define exactly what the information is they want to extract-- >> John: I wanted to get-- >> Which is your whole question around the rules and-- >> So let me see if I can connect the dots here, just kind of connect this for, and so, in the showcase, you guys are going to show this programmability, this kind of efficiency at the layer of bringing instrumentation then using that information, and/or data depending on how it's sliced and diced via the policy and programmability, but this becomes cloud-like, right? So when you start moving, thinking about cloud where service providers are under a lot of pressure to go cloud because Over-The-Top right now is booming, you're seeing a huge content and application market that's super ripe for kind of the, these kinds of services. They need that ability to have the infrastructure be like software, so infrastructure is code, is the DevOps term that we talk about in our DevOps world, but that has been more data-centered kind of language, with developers. Is it going the same trajectory in the service provider world because you have networks, I mean they're bigger, higher scale. What are some of those DevOps dynamics in your world? Can you talk about that and share some color on that? >> I mean, the way in which large service providers are starting to deliver those services is out of something that looks very much like the cloud platform. In fact, it could in fact be exactly the same technology. The same servers, the same switches, same operating systems, a lot of the same techniques. The problem they're trying to solve is slightly different. They're chaining together the means to process a sequence of operations. A little bit like, though the cloud operators are moving towards microservices that get chained together, so there are a lot of similarities here and the problems they face are very similar, but think about the hell that this potentially creates for them. It means that we're giving them so much rope to hang themselves because everything is now got to be put together in a way that's coming from different sources, written and authored by different people with different intent, or from different places across the Internet, and so, being able to see and observe exactly how this is working is even more critical than-- >> So I love that rope to hang yourself analogy because a lot of people will end up breaking stuff as Mark Zuckerberg's famous quote is, "Move fast, break stuff," and then by the way, when they 100 million users and moved, slogan went for, "Move fast, be reliable," so he got on the five nines bandwagon pretty quick, but it's more than just the instrumentation. The key that you're talking about here is that they have to run those networks in really high reliability environments. >> Nick: Correct. >> And so that begs the challenge of, okay, it's not just easy as throwing a docker container at something. I mean that's what people are doing now, like hey, I'm going to just use microservices, that's the answer. They still got stuff under the hood, but underneath microservices. You have orchestration challenges and this kind of looks and feels like the old configuration management problems but moved up the stack, so is that a concern in your market as well? >> So I think that's a very, very good point that you make because the carriers, as you say, tend to be more dependent, almost, on absolute reliability, and very importantly, performance, but in other words, they need to know that this is going to be 100 gigs because that's what they've signed up the SLA with their customer for. (John chuckles) It's not going to be almost 100 gigs 'cause then they're going to end up paying a lot of penalties. >> Yeah, they can't afford breakage. They're OpsDev, not DevOps. Which comes first in their world? >> Yes, so the critical point here is just that this is where the demo that we're doing which shows the ability to capture all this information at line rate, at very high speeds in the switches. (mumbles) >> So let's about this demo you're doing, this showcase that you guys are providing and demonstrating to the marketplace, what's the pitch, I mean what is it, what's the essence of the insight of this demo, what's it proving? >> So I think that the, it's good to think about a scenario in which you would need this, and then this leads into what the demo would be. Very common in an environment like the VNF kind of environment, where something goes wrong, they're trying to figure out very quickly, who's to blame, which part of the infrastructure was the problem? Could it be congestion, could it be a misconfiguration? (John laughs) >> Niel: Who's flow-- >> Everyone pointing finger at the other guy. >> Nick: The typical way-- >> Two days later, what happened, really? >> Typical way that they do this, is they'll bring the people that are responsible for the compute, the networking, and the storage quickly into one room, and say, "Go figure it out." The people that are doing the compute, they'll be modifying and changing and customizing, running experiments, isolating the problem. So are the people that are doing storage. They can program their environment. In the past, the networking people had ping and traceroute. That's the same tools that they had 20 years ago. (John chuckles) What we're doing is changing that by introducing the means where they can program and configure, run different experiments, run different probes, so that they can look and see the things that they need to see, and in the demo in particular, you'll be able to see the packets coming in through a switch, through a NIC, through a couple of VMs, back out through a switch, and then you can look at that packet afterwards, and you can ask questions of the packet itself, something you've never been able to-- >> It's the ultimate debugger. Basically, it's the ultimate debugger. >> Nick: That's right. Go to the packet, say-- >> Niel: Programmable debugger. >> "Which path did you take? "How long did you wait at each NIC, "at each VM, at each switch port as you went through? "What are the rules that you followed "that led you to be here, and if you encountered "some congestion, whose fault was it? "Who did you share that queue with?" so we can go back and apportion the blame-- >> So you get a multiple dimension of path information coming in, not just the standard stovepiped tools-- >> Nick: That's right. >> And then, everyone compares logs and then there's all these holes in it, people don't know what the hell happened. >> And through the programmability, you can isolate the piece of the information-- >> So the experimentation agile is where I think, is that what you're getting at? You can say, you can really get down and dirty into a duplication environment and also run these really fast experiments versus kind of in theory or in-- >> Exactly, which is what, as Nick said, is exactly what people on the server side and on the storage side have been able to do in the past. >> Okay so for people watching that are kind of getting into this and people who aren't, just give me in order maybe through of the impact and the consequences of not taking this approach, vis-a-vis the available, today's available techniques. >> If you wanted to try and figure out who it was that you were sharing a queue with inside an interface or inside a switch, you have no way to do that today, right? No means to do that, and so if you wanted to be able to say it's that aggressive flow over there, that malfunction in service over there, you've got no means to do it. As a consequence, the networking people always get the blame because they can't show that it wasn't them. But if you can say, I can see, in this queue, there were four flows going through or 4,000 flows, and one of them was really badly behaved, and it was that one over there and I can tell you exactly why its packets were ending up here, then you can immediately go in and shut that one down. They have no way that they go and randomly shut-- >> Can I get this for my family, I need this for my household. I mean, I'm going to use this for my kids. I mean I know exactly the bad behavior, I need to prove it. No, but this is what the point is, is this is fast. I mean you're talking speed, too, as another aspect-- >> Niel: It's all about the-- >> What's the speed lag on approach versus taking the old, current approach versus this joint approach you guys are taking? What's the, give me an estimate on just ballpark numbers-- >> Well there's two aspects to the speed. One is the speed at which it's operating, so this is going to be in the demo, it's running at 40 gigabits per seconds, but this can easily run, for example, in the Barefoot switch, it'll run at 6 terabits per second. The interesting thing here is that in this entire environment, this measurement capability does not generate a single extra packet. All of it is self-contained in the packets that are already flowing. >> So there's no latency issues on running this in production. >> If you wanted then change the behavior, you needed to go and modify what was happening in the NIC, modify what was happening in the switch, you can do that in minutes. So that you can say-- >> Now the time it takes for a user now to do this, let's go to that time series. What does that look like? So current method is get everyone in a room, do these things, are we talking, you know. >> I think that today, it's just simply not possible. >> Not possible. >> So it's, yes, new capability. >> I think is the key issue. >> So this is a new capability. >> This is a new capability and exactly as Nick said, it's getting the network to the same level of ability that you always had inside the-- >> So I got to ask you guys, as founders of your companies because this is one of those things that's a great success story, entrepreneurs, you got, it's not just a better mousetrap, it's revolutionary in the sense that no one's ever had the capability before, so when you go to events like Mobile World Congress, you're out in the field, are you shaking people like, "You need me! "I need to cut the line and tell you what's going on." I mean, you must have a sense of urgency that, is it resonating with the folks you're talking to? I mean, what are some of the conversations you're having with folks? They must be pretty excited. Can you share any anecdotal stories? >> Well, yup, I mean we're finding, across the industry, not only in the service providers, the data center companies, Wall Street, the OEM box vendors, everybody is saying, "I need," and have been saying for a long time, "I need the ability to probe into the behavior "of individual packets, and I need whoever is owning "and operating the network to be able to customize "and change that." They've never been able to do that. The name of the technique that we use is called In-band Network Telemetry or INT, and everybody is asking for it now. Actually, whether it's with the two of us, or whether they're asking for it more generally, this is, this is-- >> Game changer. >> You'll see this everywhere. >> John: It's a game changer, right? >> That's right. >> Great, all right, awesome. Well, final question is, is that, what's the business benefits for them because I can imagine you get this nailed down with the proper, the ability to test new apps because obviously, we're in a Wild West environment, tsunami of apps coming, there's always going to be some tripwires in new apps, certainly with microservices and APIs. >> I think the general issues that we're addressing here is absolutely crucial to the successful rollout of NFV infrastructures. In other words, the ability to rapidly change, monitor, and adapt is critical. It goes wider than just this particular demo, but I think-- >> It's all apps on the service provider. >> The ability to handle all the VNFs-- >> Well, in the old days, it was simply network spikes, tons of traffic, I mean, now you have, apps could throw off anomalies anywhere, right? You'd have no idea what the downstream triggers could be. >> And that's the whole notion of the programmable network, which is critical. >> Well guys, any information where people can get some more information on this awesome opportunity? You guys' sites, want to share quick web addresses and places people get whitepapers or information? >> For the general P4 movement, there's P4.org. P, the number four, .org. Nice and easy. They'll find lots of information about the programmability that's possible by programming the, the forwarding being what both of us are doing. In-band Network Telemetry, you'll find descriptions there, P4 programs, and whitepapers describing that, and of course, on the two company websites, Netronome and Barefoot. >> Right. Nick and Niel, thanks for spending some time sharing the insights and congratulations. We'll keep an eye for it, and we'll be talking to you soon. >> Thank you. >> Thank you very much. >> This is theCUBE here in Palo Alto. I'm John Furrier, thanks for watching. (lively techno music)