(Upbeat music) >> Hi everyone and welcome back to the Cube's coverage of Splunk.conf 2021, virtual. We are here, live in the Splunk studios here in Silicon valley. I'm John Furrier, host of the Cube. Spiros Xanthos VP of product management of observability with Splunk is here inside the cube, Spiros, thanks for coming on. Great to see you. [Spiros Xanthos]- John, thanks for having me glad to be here. >> We love observability. Of course we love Kubernetes, but that was before observability became popular. We've been covering cube-con since it was invented even before, during the OpenStack days, a lot of open source momentum with you guys with observability and also in the customer base. So I want to thank you for coming on. Give us the update. What is the observability story its clearly in the headlines of all the stories SiliconANGLE's headline is multi-cloud observability security Splunk doubling down on all three. >> Correct. >> Big part of the story is observability. >> Correct. And you mentioned CubeCon. I was there last week as well. It seems that those observability and security are the two most common buzzwords you hear these days different from how it was when we started it. But yeah, Splank actually has made the huge investment in observability, starting with the acquisition of Victor ops three years ago, and then with Omnition and Signalfx. And last year with Plumbr synthetics company called Rigor and Flowmill and a network monitoring company. And plus a lot of organic investment we've made over the last two years to essentially build an end-to-end observability platform that brings together metrics, traces, and logs, or otherwise infrastructure monitoring, log analytics, application monitoring. Visual experience monitoring all in one platform to monitor let's say traditional legacy and modern cloud native apps. >> For the folks that know SiliconANGLE, the Cube know we've been really following this from the beginning for signal effects, remember when they started they never changed their course. they've had the right They have the right history and from spot by spot, you guys, same way open source and cloud was poo-pooed upon, people went like, oh, it's not secure, they never were. Now it's the center of all the action. [Spiros Xanthos]- Yes >> And so that's really cool. And thanks for doing that. The other thing I want to get your point on is what does end-to-end observability mean? Because there's a lot of observability companies out there right now saying, Hey, we're the solution We're the utility, we're the tool, but I haven't seen a platform. So what's your answer to that? >> Yes. So observability, in my opinion, in the context of what you're describing means two things. One is that when, when we say internal durability, it means that instead of having, let's say multiple monitoring tools that are silent, let's say one for monitoring network, one for monitoring infrastructure, a separate one for monitoring APM that do not work with each other. We bring all of these telemetry in one place we connect it and exactly because actually applications and infrastructure themselves are becoming one. You have a way to monitor all of it from one place. So that's observability. But the other thing that observability also is because these environments tend to be a lot more complex. It's not just about connecting them, right? It's also about having enough data and enough analytics to be able to make sense out of those environments and solve problems faster than you could do in the past with traditional monitoring. >> That's a great definition. I've got to then ask you one of the things coming up that came out of CoopCon was clear, is that the personnel to hire, to run this stuff, it's not everyone can get the skills gap problem. At the same time, automation is at an all time high people are automating and doing AI ops, get outs. What do you want to call this a buzz word for that basically automating the data observability into the CICB pipeline, huge trend right now. And the speed of developers is fast now. They're coding fast. They don't want to wait. >> I agree. So, and that's exactly what's happening, right? We want essentially from traditional IT where developers would develop something a little bit deployed months later by some IT professional, of course, all of this coming together, But we're not stopping that as you say, right, that the shifting left is going earlier into the pipeline. Everyone expect, essentially let's say monitoring to happen at the speed of deployment. And I guess observability again, is this not, as a requirement. Observability is this idea. Let's say that I should be able to monitor my applications in real time and, you know, get information as soon as something happens. >> With the evolution of the shift left trend. I would say for the people don't know what shift left is you put security the beginning, not bolted on at the end and developers can do it with automation, all that good stuff that they have. But how, how real is that right now in terms of it happening? Can you, can you share some vision and ideas and anecdotal data on how, how fast shift left is, or is there still bottlenecks and security groups and IT groups? >> So there are bottlenecks for sure. In my opinion, we are aware with, let's say the shift left or the dev sec ops trend, whether IT and devs maybe a few years ago. And this is both a cultural evolution that has to happen. So security teams and developers have to come closer together, understand like, say the consensus of the requirements of each other so they can work better together the way it happened with DevOps and all sorts of tooling problem, right? Like still observability or monitoring solutions are not working very well with security yet. We at Splunk of course, make this a priority. And we have the platform to integrate all the data in one place. But I don't think is generally something that we'll have achieved as well as an industry yet. And including the cultural aspects of it. >> Is that why you think end to end is important to hit that piece there so that people feel like it's all working together >> I think end to end is important for two reasons. actually one is that essentially, as you say, you hit all the pieces from the point of deployment, let's say all the way to production, but it's also because I think applications and infrastructure, FMLA infrastructure with Kubernetes, microservices are in traditional so much more complexity that you need to step function improvement in the tooling as well. Right? So that you need keep up with the complexity. So bringing everything together and applying analytics on top is the way essentially to have this step function improvement in how your monitoring solution works so that it can keep up with the complexity of the underlying infrastructure and application. >> That is a huge, huge points Spiros. I got to double down on that with you and say, let's expand that because that's the number one problem, taming the complexity without slowing down. Right? So what is the best practice for that? What do people do? Cause, I mean, I know it's evolving, it's going faster than that, but it's still getting better, but not always there, but what can people do to go faster? >> So, and I will add that it's even more complex than just what the cloud, let's say, native applications introduced because especially large enterprises have to maintain their routine, that on-prem footprint legacy applications that are still in production and then still expand. So it's additive to what they have today, right? If somebody was to start from a clean slate, let's say started with Kubernetes today, maybe yes, we have the cloud native tooling to monitor that, but that's not the reality of most, most enterprises out there. Right? So I think our goal at Splunk at least is to be able to essentially work with our customers through their digital, digital transformation and cloud journey. So to be able to support all their existing applications, but also help them bring those to the cloud and develop new applications in a cloud native fashion, let's say, and we have the tooling, I think, to support all of that, right between let's say our original data platform and our metrics and traces platform that we develop further. >> That's awesome. And then one quick question on the customer side, if I'm a customer, I want observability, I want this, I want everything you just said. How do I tell the difference between a pretender and a player, the good solution and a bad solution? What are the signals that this is the real deal, that's a fake product >> Agreed. So, I mean, everyone obviously believes that original (laughing) I'm not sure if I will. >> You don't want to name names? Here's my, my perspective on what truly is a requirement for absorb-ability right? First of all, I think we have moved past the time where let's say proprietary instrumentation and data collection was a differentiator. In fact, it actually is a problem today, if you are deploying that because it creates silos, right? If I have a proprietary instrumentation approach for my application, that data cannot be connected to my infrastructure or my logs, let's say, right. So that's why we believe open telemetry is the future. And we start there in terms of data collection. Once we standardize, let's say data collection, then the problem moves to analytics. And that's, I think where the future is, right? So observability is not just about collecting a bunch of data and that bring it back to the user. It's about making sense out of this data, right? So the name of the game is analytics and machine learning on top of the data. And of course the more data you can collect, the better it is from that perspective. And of course, then when we're talking about enterprises, scale controls, compliance all of these matter. And I think real time matters a lot as well, right? We cannot be alerting people after minutes of a problem that has happened, but within a few seconds, if we wanted to really be pro-active. >> I think one thing I like to throw out there, maybe get your reaction to it, I think maybe one other thing might be enabling the customer to code on top of it, because I think trying to own the vertical stack as well as is also risky as a vendor to sell to a company, having the ability to add programming ability on top of it. >> I completely agree actually, You do? In general giving more control to the users and how, what do they do with their data, let's say, right? And even allowing them to use open source, whatever is appropriate for them, right? In combination, maybe with a vendor solution when they don't want to invest themselves. >> Build their own apps, build your own experience. That's the way the world works. That's software. >> I agree. And again, Splunk from the beginning was about that, right? Like we'll have thousands of apps built ontop of our platform >> Awesome. Well, I want to talk about open source and the work you're doing with open telemetry. I think that's super important. Again, go back even five, 10 years ago. Oh my God. The cloud's not secure. Oh my God, open source has got security holes. It turns out it's actually the opposite now. So, you know finally through the people woke up. No, but it's gotten better. So take us through the open telemetry and what you guys are doing with that. >> Yes. So first of all, my belief, my personal belief is that if there is no future where infrastructure is anything about open source, right? Because people do not trust actually close our solutions in terms of security. They prefer open source at this point. So I think that's the future. And in that sense, a few years ago, I guess our belief was that all data collection instrumentations with standards based first of all, so that the users have control and second should be open source. That's why we, at Omnition the company I co-founded that was acquired by Splunk. We we're one of the main tenders of open sensors and that we brought together open sensors and OpenTracing in creating open telemetry. And now , Open telemetry is pretty much the de facto. Every vendor supports it, its the second most active project in CNCF. And I think it's the future, right? Both because it frees up the data and breaks up the silos, but also because, has support from all the vendors. It's impossible for any single vendor to keep up with all this complexity and compete with the entire industry when we all come together. So I think it's a great success it's I guess, kudos to everybody, kudos to CNCF as well, that was able to actually create and some others. >> And props to CNCF. Yeah. CNC has done an amazing job and been going to all those events all the years and all the innovations has been phenomenal. I got to ask what the silos, since you brought it up, come multiple times. And again, I think this is important just to kind of put an exclamation point on, machine learning is based upon data. Okay. If you have silos, you have the high risk of having bad machine learning. >> Yes. >> Okay. That's you agree with that? >> Completely. >> So customers, they kind of understand this, right. If you have silos that equals bad future >> Correct >> because machine learning is baked into everything now. >> And I will add to that. So silos is the one problem, and then not being able to have all the data is another problem, right? When it comes to being able to make sense out of it. So we're big believers in what we call full fidelity. So being able to connect every byte of data and do it in a way that makes sense, obviously economically for the customer, but also have, let's say high signal to noise ratio, right? By structuring the data at the source. Overt telemetry is another contributor to that. And by collecting all the data and by having an ability, let's say to connect the data together, metrics, traces, logs, events, incidents, then we can actually build a little more effective tooling on top to provide answers back to the user with high confidence. So then users can start trusting the answers as opposed to they themselves, always having to figure out what the problem is. And I think that's the future. And we're just starting. >> Spiros I want to ask you now, my final question is about culture And you know, when you have scale with the cloud and data, goodness, where you have people actually know the value of data and they incorporate into their application, you have advantages. You have competitive advantages in some cases, but developers were just coding love dev ops because it's infrastructure as code. They don't have to get into the weeds and do the under the hood, datas have that same phenomenon right now where people want access to data. But there's certain departments like security departments and IT groups holding back and slowing down the developers who are waiting days and weeks when they want it in minutes and seconds for have these kinds of things. So the trend is, well there's, first of all, there's the culture of people aren't getting along and they're hating each other or they're not liking each other. >> Yes >> There's a little conflict, always kind of been there, but now more than ever, because why wait? >> I agree. >> How can companies shorten that cycle? Make it more cohesive, still decouple the groups because you've got, you got compliance. How do you maximize the best of a good security group, a good IT group and enables as fast as possible developers. >> I agree with you, by the way, this is primarily cultural. And then of course there is a tooling gap as well. Right. But I think we have to understand, let's say as a security group, instead of developers, what are the needs of each other, right. Why we're doing the things we're doing because everybody has the right intentions to some extent, right? But the truth is there is pain. We are me and myself. Like as we develop our own solutions in a cloud native fashion, we see that right. We want to move as fast as possible, but at the same time, want to be compliant and secure, right. And we cannot compromise actually on security or compliance. I mean, that's really the wrong solution here. So I think we need to come together, understand what each other is trying to do and provide. And actually we need to build better tooling that doesn't get into the way. Today, oftentimes it's painful to have, let's say a compliance solution or a secure solution because it slows down development. I think we need to actually, again, maybe a step function improvement in the type of tooling we'll have in this space. So it doesn't get into the way Right? It does the work it provides. Let's say the security, the security team requires, it provides the guarantees there, but doesn't get in the way of developers. And today it doesn't happen like this most of the time. So we have some ways to go. >> And Garth has mentioning how you guys got some machine learning around different products is one policy kind of give some, you know, open, you know, guardrails for the developers to bounce around and do things until they, until they have to put a new policy in place. Is that an answer automated with automation? >> Big time. Automation is a big part of the answer, right? I think we need to have tooling that first of all works quickly and provides the answers we need. And we'll have to have a way to verify that the answer are in place without slowing down developers.Splunk is, I mean, out of a utility of DevSecOps in particular is around that, right? That we need to do it in a way that doesn't get in the way of, of let's say the developer and the velocity at which they're trying to move, but also at the same time, collect all the data and make sure, you know, we know what's going on in the environment. >> Is AI ops and dev sec ops and GET ops all the same thing in your mind, or is it all just labels >> It's not necessarily the same thing because I think AI ops, in my opinion applies, let's say to even more traditional environments, what are you going to automate? Let's say IT workflows in like legacy applications and infrastructure. Getops in my mind is maybe the equivalent when you're talking about like cloud native solutions, but as a concept, potentially they are very close I guess. >> Well, great stuff. Great insight. Thanks for coming on the Cube. Final point is what's your take this year of the live we're in person, but it's virtual, we're streaming out. It's kind of a hybrid media environment. Splunk's now in the media business with the studios, everything great announcements. What's your takeaway from the keynote this week? What's your, you got to share to the audience, this week's summary. >> First of all, I really hope next year, we're all going to be in one place, but still given the limitations we had I think it was a great production and thanks to everybody who was involved. So my key takeaway is that we truly actually have moved to the data age and data is at the heart of everything we do. Right? And I think Splunk has always been that as a company, but I think we ourselves really embraced that and everything we do is everything. Most of the problems we solve are data problems, whether it's security, observability, DevSecOps, et cetera. So. >> Yeah, and I would say, I would add to that by saying that my observations during the pandemic now we're coming, hopefully to the end of it, you guys have been continuing to ship code and with real, not vaporware real product, the demos were real. And then the success on the open source. Congratulations. >> Thank you. >> All right. Thanks for coming on and we appreciate it >> Thanks alot _Cube coverage here at dot com Splunk annual conference. Virtual is the Cube. We're here live at the studios here at Splunk studios for their event. I'm John Farrow with the Cube. Thanks for watching. (joyful tune)