>>From San Francisco. It's the cube covering PagerDuty summit 2019 brought to you by PagerDuty. >>Hey, welcome back everybody. Jeff Frick here with the Q. We're a PagerDuty summit. It's the fourth year of the show. He's been here for three years. It's amazing to watch it grow. I think it's finally outgrown the Western Saint Francis here in lovely downtown San Francisco and we're really excited to be joined by our next guest. He's Alex Solomon, the co founder, co founder and CTO PagerDuty. Been at this over 10 years. Alex, first off, congratulations. And what a fantastic event. Thank you very much and thank you for having me on your show. So things have changed a lot since we had you on a year ago, this little thing called an IPO. So I'm just curious, you know, we have a lot of entrepreneurs. I watch a show as a founder and kind of go through this whole journey. What was that like? What are some of the things you'd like to share from that whole experience? >>Yeah, it was, it was incredible. I I, the word I like to use is surreal. Like just kind of going through it, not believing that it's real in a way. And adjoining by my, my lovely wife who came, came along for this festivities and just being able to celebrate that moment. I know it is just a moment in time and it's not, it's not the end of the journey certainly, but it is a big milestone for us and uh, being able to celebrate. We invited a lot of our customers, our early customers have been with us for years to join us in that, a celebration. Our investors who have believed in us from back in 2010. Right, right. We were just getting going and we just, we just had a great time. I love it. I love 10 year overnight success. 10 years in the making. >>One of my favorite expressions, and it was actually interesting when Jenn pulled up some of the statistics around kind of what the internet was, what the volume of traffic was, what the complexity in the systems are. And it's really changed a lot since you guys began this journey 10 years ago. Oh, it has. I mean back then, like the most popular monitoring tool is Nagios and new Relic was around but just barely. And now it's like Datadog has kind of taken over the world and the world has changed. We're talking about not just a microservices by containers and serverless and the cloud basically. Right. That's the kind of recurring theme that's changed over the last 10 years. But you guys made some early bets. You made bets on cloud. He made bets on dev ops. He made bets on automation. Yeah, those were pretty good. >>Uh, those, those turn out to be pretty good places to put your chips. Oh yeah. Right place, right time and um, you know, some, some experiential stuff and some just some raw luck. Right. All right, well let's get into it. On top of some of the product announcements that are happening today, what are some of the things you're excited to finally get to showcase to the world? Yeah, so one of the big ones is, uh, related to our event intelligence release. Uh, we launched the product last year, um, a few months before summit and this year we're making a big upgrade and we're announcing a big upgrade to the product where we have, uh, related incidents. So if you're debugging a problem and you have an incident that you're looking at, the question you're gonna ask is, uh, is it just my service or is there a bigger widespread problem happening at the same time? >>So we'll show you that very quickly. We'll show you are there other teams, uh, impacted by the same issue and we'll, we, we actually leveraged machine learning to draw those relationships between ongoing incidents. Right. I want to unpack a little bit kind of how you play with all these other tools. We, you know, we're just at Sumo logic a week or so ago. They're going to be on later their partner and people T I think it's confusing. There's like all these different types of tools. And do you guys partner with them all? I mean, the integration lists that you guys have built. Um, I wrote it down in service now. It's Splunk, it's Zendesk, it goes on and on. And on. Yeah. So explain to folks, how does the PagerDuty piece work within all these other systems? Sure. So, um, I would say we're really strong in terms of integrating with monitoring tools. >>So any sort of tool that's monitoring something and we'll admit an alert, uh, when something goes down or over an event when something's changed, we integrate and we have a very wide set of coverage with all, all of those tools. I think your like Datadog, uh, app dynamics, new Relic, even old school Nagios. Right. Um, and then we've also built a suite of integrations around all the ticketing systems out there. So service now a JIRA, JIRA service desk, um, a remedy as well. Uh, we also now have built a suite of integrations around the customer support side of things. So there'll be Zendesk and Salesforce. That's interesting. Jen. Megan had a good example in the keynote and kind of in this multi system world, you know, where's the system of record? Cause he used to be, you want it, everybody wanted it to be that system of record. >>They wanted to be the single player in the class. But it turns out that's not really the answer. There's different places for different solutions to add value within the journey within those other applications. Yeah, absolutely. I, I think the single pane of glass vision is something that a lot of companies have been chasing, but it's, it's, it's really hard to do because like for example, NewRelic, they started an APM and they got really good at that and that's kind of their specialty. Datadog's really good at metrics and they're all trying to converge and do everything and become the one monitoring solution to the Rooney rule them all right. But they're still the strongest in one area. Like Splunk for logs, new Relic and AppDynamics for APM and Datadog for metrics. And, um, I don't know where the world's going to take us. Like, are they, is there going to be one single monitoring tool or are, are you going to use four or five different tools? >>Right. My best guess is your, we're going to live in a world where you're still gonna use multiple tools. They each can do something really well, but it's about the integration. It's about building, bringing all that data together, right? That's from early days. We've called pager duty, the Switzerland monitoring, cause we're friends with everyone when we're partners with everyone and we sit on top right a work with all of these different roles. I thought her example, she gave him the keynote was pretty, it's kind of illustrative to me. She's talking about, you know, say your cables down and you know, you call Comcast and it's a Zendesk ticket. But >>you know then that integrates potentially with the PagerDuty piece that says, Hey we're, you know, we're working on a problem, you know, a backhoe clipped the cable down your street. And so to take kind of that triage and fix information and still pump that through to the Zen desk person who's engaging with the customer to actually give them a lot more information. So the two are different tracks, but they're really complimentary. >>Absolutely. And that's part of the incident life cycle is, is letting your customers know and helping them through customer support so that the support reps understand what's going on with the systems and can have an intelligent conversation with the customer. So that they're not surprised like a customer calls and says you're down. Oh, good to know. No, you want to know about that urge, which I think most people find out. Oh yeah. Another thing >>that struck me was this, this study that you guys have put together about unplanned work, the human impact of always on world. And you know, we talk a lot in tech about unplanned maintenance and unplanned downtime of machines, whether it's a, a computer or a military jet, you know, unplanned maintenance as a really destructive thing. I don't think I've ever heard anyone frame it for people and really to think about kind of the unplanned work that gets caused by an alert and notification that is so disruptive. And I thought that was a really interesting way to frame the problem and thinking of it from an employee centric point of view to, to reduce the nastiness of unplanned work. >>Absolutely. And that's, that V is very related to that journey of going from being reactive and just reacting to these situations to becoming proactive and being able to predict and, and, uh, address things before they impact the customer. Uh, I would say it's anywhere between 20 to 40 or even higher percent of your time. Maybe looking at software engineers is spent on the some plant work. So what you want to do is you want to minimize that. You want to make sure that, uh, there's a lot of automation in the process that you know what's going on, that you have visibility and that the easy things, the, the repetitive things are easy to automate and the system could just do it for you so that you, you focus on innovating and not on fixing fires. Right? Or if you did to fix the fire, you at least >>to get the fire to the right person who's got the right tone to fix the type. So why don't we just, you know, we see that all the time in incidents, especially at early days for triage. You know, what's happening? Who did it, you know, who's the right people to work on this problem. And you guys are putting a lot of the effort into AI and modeling and your 10 years of data history to get ahead of the curve in assigning that alerted that triage when it comes across the, the, uh, the trans though. >>Yeah, absolutely. And that's, that's another issues. Uh, not having the right ownership, get it, getting people, um, notified when they don't own it and there's nothing they can do about it. Like the old ways of, of uh, sending the alert to everyone and having a hundred people on a call bridge that just doesn't work anymore because they're just sitting there and they're not going to be productive the next day I work cause they're sitting there all night just kind of waiting for, for something to happen. And uh, that's kinda the, the old way of lack of ownership just blasted out to everyone and we have to be a lot more target and understand who owns what and what's, what, which systems are being impacted and they only let getting the right people on the auto call as quickly as possible. The other thing that came up, which I thought, you know, probably a lot of people are thinking of, they only think of the fixing guy that has to wear the pager. >>Sure. But there's a whole lot of other people that might need to be informed, be informed. We talked about in the Comcast example that people interacting with the customer, ABC senior executives need to be in for maybe people that are, you know, on the hook for the SLA on some of the softer things. So the assembly that team goes in need, who needs to know what goes well beyond just the two or three people that are the fixing people? Right. And that's, that's actually tied to one of our announcements, uh, at summit a business, our business response product. So it's all about, um, yes, we notify the people who are on call and are responsible for fixing the problem. You know, the hands on keyboard folks, the technical folks. But we've expanded our workflow solution to also Lupin stakeholders. So think like executives, business owners, people who, um, maybe they run a division but they're not going to go on call to fix the problem themselves, but they need to know what's going on. >>They need to know what the impact is. They need to know is there a revenue impact? Is there a customer impact? Is there a reputational brand impact to, to the business they're running. Which is another thing you guys have brought up, which is so important. It's not just about fixing, fixing the stuck server, it's, it is what is the brand impact, what is the business impact is a much broader conversation, which is interesting to pull it out of just the, just the poor guy in the pager waiting for it to buzz versus now the whole company really being engaged to what's going on. Absolutely. Like connecting the technical, what's happening with the technical services and, and uh, infrastructure to what is the, the impact on the business if something goes wrong. And how much, like are you actually losing revenue? There's certain businesses like e-commerce where you could actually measure your revenue loss on a per minute or per five minute basis. >>Right. And pretty important. Yeah. All right Alex. So you talked about the IPO is a milestone. It's, it's fading, it's fading in the rear view mirror. Now you're on the 90 day shot clock. So right. You gotta keep moving forward. So as you look forward now for your CTO role, what are some of your priorities over the next year or so that you kind of want to drive this shit? Absolutely. So, um, I think just focusing on making the system smarter and make it, uh, so that you can get to that predictive Holy grail where we can know that you're going to have a big incident before it impacts our customers. So you can actually prevent it and get ahead of it based on the leading indicators. So if we've seen this pattern before and last time it causes like an hour of downtime, let's try to catch it early this time and so that you can address it before it impacts for customers. >>So that's one big area of investment for us. And the other one I would say is more on the, uh, the realtime work outside of managing software systems. So, uh, security, customer support. There's all of these other use cases where people need to know, like, signals are, are being generated by machines. People need to know what's going on with those signals. And you want to be proactive and preventative around there. Like think a, a factory with lots and lots of sensors. You don't want to be surprised by something breaking. You want to like get proactive about the maintenance of those systems. If they don't have that, uh, you know, like say a multi-day outage in a factory, it can cost maybe millions of dollars. Right. >>All right, well, Alex, thanks a lot. Again, congratulations on the journey. We, uh, we're enjoying watching it and we'll continue to watch it evolve. So thank you for coming on. Alright, he's Alex. I'm Jeff. You're watching the cube. We're at PagerDuty summit 2019 in downtown San Francisco. Thanks for watching. We'll see you next time.

(groovy music) >> From our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. >> Everyone, welcome to this special CUBE Conversation here in Palo Alto Studios for theCUBE. I'm John Furrier, host for theCUBE. We're here with special guest, Arijit Mukherji, who's the CTO of SignalFx, hot startup that's now growing very very fast in this cloud native world. Arijit, great to see you. Thanks for coming on. >> Great to see you too again, John. >> So cloud growth is changing the landscape of the enterprise. We're seeing it obviously, it's no real surprise, Cloud 1.0 has happened, public cloud. Cloud 2.0 as we're calling it is changing the game, where you're seeing enterprise cloud really the focus. We're seeing cloud native really move the needle. Kubernetes has kind of created that abstraction, kind of standard, defacto standard, if you will, people getting around. So you're seeing the game changing from how apps are built. >> Right. >> To security and everything in between. So a new set of services, web services at scale has certainly change the game. You guys are in the middle of this with monitoring and observability. And I want you to help us understand the core problem enterprises are having today because they know it's coming. They know it's here. They got investments out there. The cloud has changed the game for the enterprise, what's the problem? >> Yeah, so you're absolutely right, John. So everybody's moving to this sort of the new way of doing things, right. So monoliths are gone. Microservices are in, containers are in. And you're going to have to do that because we know if you don't do that, you're going to get lapped right, by the competition. And so the challenge right now is how do you make that successful? And the challenge there is these new environments are much much more complex as you mentioned. And the question is unless you understand how these systems behave, how will you be able to run them successfully? So the challenge as far as monitoring and observability is concerned is I think it's critical that it be there for it to be able to sort of do this cloud transformation successfully. But it's a far more complex and hard challenge than it used to be. >> We've seen the evolution. Yeah, we've been covering that for 10 years. It's the 10th year of theCUBE. We'll be celebrating that at VMworld this year. You've seen wave one, lift and shift, do some basic stuff, not a lot of heavy lifting. No tinkering with some of the tech in there. Monitoring is great. And then you've got rearchitect. Let's get some cloud native. Let's see some Kubernetes. And then the next path is this complete microservices. This is where everyone's really excited about. >> That's right. >> This is where the complexity is. So I got to ask you, that changes the notion of monitoring and observability. So given that this shift is happening, rearchitecting to full microservices, what is observability in that equation? >> Right, so there's a very interesting difference between I think, monitoring and observability that I think I would like to touch upon here. So you know, back in the days of the monolith, it was what we called classic monitoring. Monitoring is about looking at things, looking for things that you know might happen. So for example, if I know my server might fall down, I will run a probe to make sure that it's up or not, right? But when you move to this new world, I mean, have you, if you look at any cloud native environment with all the microservices and containers, for example Amazon's S3 has 120 different microservices powering it behind it. Now, if you were to go and ask an engineer like what is the map or how are the data flow happening in that environment? I guarantee you, no one person can probably do that well. So then, monitoring doesn't work because I don't even know what to look for. So what's important is I be able to gather telemetry, have the information available so that the unknowns, the kind of things that I'm not expecting because it's just too complex or just unanticipated. Like that data will allow us to figure out what went wrong. So observability is about gathering telemetry and information so that we can deal with that complexity, understand problems as they behave because the world is no longer simple anymore. >> So overall, observability is just monitoring in a dynamic environment, what you're saying. 'Cause monitoring used to be simple. You know it's going on. Static routes. >> That's right. >> Set policy, get some alarms. Network management, basic stuff. >> Exactly like Nagios checks and what not, yup. >> Now, you're saying there's unknowns happening, unexpected things going on around the services. What would that be just as an example? >> Yeah, so for example, again with microservices, why are we doing it? Because we want smaller teams to be able to innovate quicker, faster, right. So instead of my monolith, let's say I have whatever, SignalFx has 50 different microservices powering it. Now each of these teams, they are deploying software on their own because the whole idea of Cloud 2.0 is that we are able to move faster. So what that means is individual chunks of my overall service are adapting or changing over time or evolving. And so that's the complexity, like it's actually a changing landscape. Like my map does not stay the same on an ongoing basis. That is fundamentally a big challenge. The other challenge that I would mention too is that how ephemeral things are getting. So all these microservices that are themselves adapting, they're also being deployed in containers and by Kubernetes. Where these containers, they keep popping up and down all the time. Like even on infrastructure on which we are running it's extremely dynamic, right. Containers, Lambdas, sort of serverless is another great example of that. So it's a very shifting sands is what we're standing on, in some sense, right. >> And a lot of times, we cover a lot of real time. And you can't just throw in logs, you got to have that in there. This begs the question, okay, so I get the complexity. I'm a customer or I'm someone who wants to really go down this observability track with you. Why is it important? What's in it for me? >> So in the end, without it, how will you succeed? So it's almost like will a pilot with blinders on, will he be able to fly an aircraft? The answer is no. Similarly, I mean we may want to move to this modern awesome environment, which lets us move fast but unless you have visibility into it, unless you can find when problems are happening, unless you can, when those problems happen, be able to find the root cause and remediate them quickly, you're not really going to be successful. And so that's really why observability is important because it allows us to not only sort of run this well but it also allows us to understand the user experience because in the end, we are all service providers, we have users, right. And so understand what the user's experience is like. So that's important. Understand the key business metrics. If you look at a lot of the talk track that's been going around in the circuit around error budgets, and SLIs, and SLOs, which are sort of important things. The whole idea is that we want to measure and monitor what's important to the business, to the user. And that's kind of what observability allows us to get. >> You know gone are the days of a few application servers and a database. >> That's right. >> So on the why is it important, I got to follow up and say from an operations perspective, what is the new reality, okay? Because we know there's going to be a lot of databases out there, and a lot of different applications. You mentioned some of the containerization, dynamic microservices. But what's the impact and what's the importance to the operation side of the equation with observability? >> So what's happening now is again, back in the monolith days, the operators, the IT staff, who were running those infrastructure, they were the ones who would implement monitoring, right. But if you see the way now these environments are structured, these organizations are structured, it's the developers who are building tools. They are the ones who are also running them. And in order for an organization to be able to move fast, they need to give powerful tools to their developers to do their job. And because there is no one person who knows the right way of doing things. So it's really about sort of democratizing that capability. So you will need to give powerful observability tools to the developers, the operators, who are also the new operators, to sort of make with it what they will, in the sense that they are ones who best understand the meaning of the data that's being collected. Because it's all very specific to individual microservices. So that's really a powerful observability platform is one that allows you to easily collect a lot of information, allows you to analyze, visualize it, and sort of treat it in a way to sort of it helps you answer the questions you want to answer. >> So you're saying that okay, ops gets monitoring and observability. But a new persona, user is a developer. >> That is correct. >> And what do they care about? 'Cause they just want it to be abstracted away. They're not really probably wake up and say, "Hey, I can't wait to look at observability." So is it more of a use, so talk about the developer dynamic 'cause this is, that seems like a new trend. >> Yes, it totally is. So things are becoming less about black box testing, and more about sort of observability being an end-to-end process. So let me tell you what I mean. So back in the day, let's say, I implemented, I deployed a monolith. It was a Java server. There were standard ways to check them as a black box. I could run probes, et cetera, to run a health check end point and whatnot, life was great. But now, that's obviously not good enough. Because as I mentioned, because of interactions, because of complexity, a black box testing doesn't even work because like I said, the whole environment is very dynamic. So what the pattern now is that as I said, observability is an end-to-end process in the sense that developers care about observability when they're writing the software. It is not an afterthought anymore. So as I'm writing, as I'm developing software, I think about well, when this thing goes out into the wild, how will I monitor it? What are the things that I care about as a developer? Because I understand the system the best. And so you instrument, you build systems for observability is I think a big change that's happening. And once that happens, when you are the one person, who also is able to best read that data. >> So while they're developing, they get these benefits inherently right there on the spot. >> That is correct. >> This is kind of consistent with the live programming trend that's really popular in some languages. Rather than doing all the debugging, post event, coming back to it. >> That's right. >> So making it very efficient seems to be a use case. >> Yes, you are absolutely right. It's one of the things I'll actually talk about a lot actually is you know, observability, what is it for? Is it just for telling me when my production is not working well? The answer is no. Even when I'm developing, I may want to know well, did I have a performance degradation? How do I know that the code that I wrote is good? So I use again the same telemetry that I'm going to use later, even during the development process to make sure that the code that I wrote works well. We do the same thing during deployment. Again, I deploy a version or a canary or a few of them. Are they running well, right? So it is not just about what's happening in production, it's about end-to-end from development and deployment up to production. >> And that's what developers want. They want it in the moment, right when they're coding. >> That's right. >> Taken care of. >> It's instant gratification, like everybody else wants. >> And more efficiency. They know it's going to break, they know the consequences, they can deal with that. >> Yes. >> This is awesome, so the next question I have for you is how do you implement observability? >> That's a great question. So you can think of it as sort of in two ways. One is the means through which you get it. So you get observability through metrics, through logs, through traces, through probes, et cetera. That's one way. Another one is I think I alluded to a little bit earlier is what are your goals? Because everybody's goals are different, right? And if you think about in that sense, then the sort of the purpose of observability are a few. A, is it allowing your teams to move faster? So I spoke about some of the process just about earlier. Are they able to deploy code with confidence, faster? When problems happen, how quickly are we able to then triage them? So the whole incident review process. That's kind of important, observability better help me with that. The user experience is also something very important. As I mentioned, observability is going sort of more up the stack, so to speak. And so being able to understand what the user experience is, is very important. Similarly, understanding from the business point of view, what does the business care about? For example, when I had that outage, how much loss did I have? How many eyeballs did I miss on my side? So I think one way to think about it, you need to have good processes, good tools. At the same time, you need to be clear about what your goals are, and make sure that sort of whatever you're implementing, sort of furthers those to some extent. >> I'd like to play a little CUBE game here with you, and walk through the observability myths and reality. >> Sure. >> I'll say the myth, and you can tell me the reality. Myth number one, having observability reduces incidents. >> No, actually it might increase it. Let me put it that way, I'll tell you why. So it's almost like in a human, I may be measuring someone's temperature or pulse rate like every day. Does that make the person less or more prone to health problems? Chances are it's going to be the same. I might actually find things that I was not aware of, right. So in that sense, just having observability does not necessarily change anything about the process. But what it will do though is when a problem does happen, it I have this treasure trove of data, which I can then use to quickly isolate the problem. So what it does is it shrinks the outage time, which is in the end, what's very very important. So while it may not reduce your outages, it will definitely make them better from the end user point of view. >> Second myth, buying a tool means you have observability. Reality? >> No. Having a doctor doesn't mean I am healthy. In the sense that I think a tool is very important. It's a very very important step but the question is how well adopted is the tool? What kind of data am I sending to the tool? How are the users, my engineers, how well versed are they in using it, right? And so there's a lot of other stuff associated with it. So tool selection is very important but I think adoption and making it a success within the organization is also very very important. >> Okay, final myth, observability is free or cheap. >> I wish, so. >> Well you're a for-profit company. >> That's exactly right. No, I think, I really feel that observability is almost like a, it's an associated function. As I mentioned earlier, if I'm going to be successful flying this plane, I need commensurate amount of other services that sort of help me make that successful. So in a way, one way to think about it is it is it scales up as complex and as large as your environment gets and justifiably so. Because there's various other reasons too because in a way, adopting new technologies all the time. So tools are getting just more and more complicated. My requirements are getting more complicated. And then another thing I would add is the quality of my service like the level, the quality of service that I provide, the higher bar I want, I probably am spending more on observability. But it's a justified cost. So I think it's not a fixed cost obviously. It grows with your complexity and the kind of quality that you want to provide. >> Well, it's also, I mean I think the observability challenge with the complexity is there's a hidden cost though if you're not observing the right areas. >> Yes. >> The cost of not having that visibility, as a blind spot, could have business benefits, I mean not benefits, but consequences in a sense of outages, security, I mean there's a lot of different things that you got to have the observation space being enterprise. >> You totally have to do that. It's actually one thing we like to say is that instrument first, ask questions later. Now, coming from a for-profit vendor, it may sound sort of self-serving. But it's kind of not so too in the sense that I mean hindsight is 20-20. If I am stuck in a bad situation, I have no telemetry to sort of fall back on. Then where do I go with it? So I think we should be more conservative and sort of try and instrument the things that we think might be applicable, the kind of questions I may want to ask when a rainy day comes. So I think you're absolutely right. So it has to be something. It's a philosophy that developers, engineers, should sort of imbibe and they should then practice it as part of their sort of own workflows. >> I want to get into where company should invest in observability but I want to just throw a wildcard question at you, which is when you look at the big data space, even go back 10 years ago to now, cloud, there's always been they're talking about tool versus platform. And anything that's been data centric tend to be platform like conversations, not a tool. Tool can be like okay, it does a thing, does it really well, a hammer, everything's a nail with the hammer. But there's more dynamic range required 'cause you're talking about observation space, talking about cloud, horizontally scalable, hybrid on-premises. >> That's right. >> So again, it kind of feels like a platform technical challenge. >> You're absolutely right. So I think two factors at play if you ask my opinion. One is if you were interested in monitoring, a tool is perfect, right? Because you kind of know what you want. If a tool does that well, there's more power to it. But if you don't know what you want, if you are basically collecting stuff and you're depending on it as a way to answer questions on the unknown unknowns as Charity Majors like to say, then you do need a platform. Because that platform needs to be sort of inclusive. It must have data of different types, all be able to come into it. It's not really meant for a specific purpose. It's meant to be a generic tool. So we do see this trend in the industry towards more sort of a platform approach to this. Obviously, they will have tool-like capabilities because they're answering sort of particular use cases, et cetera. But the underlying platform, the more powerful it is, I think the better it is in the long run. >> Yeah and the argument there could be if it's an enabling platform, you can create abstraction layers for visualization. >> That's correct. >> Or APIs, other services. >> That's exactly right, yes. >> Okay, so now, I'm interested. I want to get started. How do I invest in good observability? I'm crossing the chasm, I'm going to full microservices. I've done a rearchitect, my team has got cultural buy-in. We're hiring, we're building our own stack, we're going to have on-premise, we'll be in the cloud. In some cases, fully cloud. What do I do, what do I invest? What's my play book? >> Sure, so I think we talked about the first one a little bit. So you have to choose the right tool. And the right tool in my opinion is not the one that does the best job now. When maybe I'm small, I'm not fully there yet. We have to think about what's the right tool or the right platform for when I'm, where for where I do want to go. Now, that may be commercial, that may be open source, that's not the point. But the point is that we need to have a very considered thought about what is it that we're betting the farm on, right. So that's number one. But that's not good enough. So as I mentioned, we need to make sure that there is a usage and understanding of the tool within the organization. So a big part of it is just around the practice and the culture of observability within the organization. So for example, good habits like every time we have an incident, you speak about these are the things that we measure, this is how we use our observability tool, here are the dashboards that we depended on. Sort of reinforcing those concepts over and over again so that those who are on board, they are obviously doing it right. Those who are not, they see the value and they start sort of using those good practices. That's kind of very important. The third thing I would say is start moving towards more higher level monitoring, observability. So measure the user experience, measure what's important to the business. Stuff like that are important. The fourth area that's sort of very very key is around sort of the whole incident management process. This is actually a very active topic. A lot of discussion going on out there right now is you know, it's great that I have this great tool, I have all this telemetry. I found there was a problem. But when that incident happened, there are a lot of again good practices. This is part of the whole culture and process of observability is how do we make that process smooth and standardized, and sort of become more efficient at it, right? And let's say you were to do that, the final sort of end goal is as we like to call is a self-running or a self-automated cloud, where do we really need humans in all of this? How can we sort of run remediation in a more and more automated fashion? At least for the stuff that maybe does not require a human intelligence, right? Actually, you'll find that 80, 90% of issues probably don't. If you think hard about it, don't require human. So I think this move towards automation is also another sort of very fantastic trend. I've seen that being very successful in the past. Some of my old companies. And I think that's going to be a trend in later stage. >> Yeah, for known processes, people and process. >> Yup. >> That's where problems come. Bad process or code and people mistakes. You can automate that. Mundane tasks or on differentiated kind of heavy lifting. >> That is exactly right because you know, there was this interesting study done that was commissioned by Stripe, where they found that among the CXOs, they value engineers and developers more than money. Because getting them, because they are such a scarce resource. So if you do get them, you probably don't want them to sort of run and do mundane things. That's not what you hired them for. So you want them to do the work of the business, and the more you can isolate them from sort of the mundane and they have automation come into play, I think it's just better across the board. >> Oh, they're investing more from the CSOs and the CIOs we talked to. >> Right. >> There's more investments in-house now for real development, real software development, real projects. And those top talent, they want to work on the toughest problem. >> That's exactly, that's why we're moving to a SASS future right? Because all the function that are not core to my business, I want to farm off and have somebody else take care of them. >> So you got me sold on observability, I'm a big believer in the observation space. And I certainly think cloud as they're horizontally scalable, elastic resource, and certainly, the Kubernetes trends with service measures and all the stuff going on, Kubeflow, and a bunch of other things. More and more services are going to be very dynamic. >> Yes. >> So you're going to have a lot of unknown and unusual patterns. >> That's right. >> That's just the way the internet works now. So you had me sold on that. Now, I need to get my team to the next level. They bought into devops. How do I take the temperature of where our IQ is in the life cycle of observability? Because I got to know where I am. Is there a way I can track my maturity or progress? >> Yes, yes, it's a topical question because I go out and I meet a lot of prospects and customers. And it's part of my job. And a lot of times, because sort of we are sort of in the leading edge, they will ask us, they look to us to tell them like are we doing it right? Or how did you guys do it? So just so that sharing of information, how can we get better? So as part of that, we actually, at SignalFx, we actually built a maturity model. It's a way for us to sort of evaluate ourselves across various dimensions to see how well are we doing? Not only, it's not just the score, it's also about how well are we doing? But how can we improve? Like if you wanted to go to the next level of maturity for example, like what are some of the things that we can do? And it spans multiple dimension. It starts with how are we even collecting data, right? How easy is it, in other words, for somebody starting a new service or using a new software to get to the business of observability? That's kind of important. You got the data, how will am I able to visualize it? Because effective visualization is as you can understand, very important. The next part comes with alerting. So well, things are running. I know how they're going. How well can I detect when problems are happening? How soon can I detect when problems are happening? What kind of items can I monitor? Can I monitor the low-level things? Or can I monitor the higher-level constructs? When the problem happen, let's talk about remediation. How quickly can I triage the problem to find out where it was? What kind of tools and slice-and-dice capabilities do I have? That's an important part of it. Let's say I did it. After that comes things like remediation. So I found the problem, how well can I remediate so like we talked about automation. So there is multiple different categories where we sort of, we talked about what, we've seen in the field in terms of what people are doing as well as some of the best practices. >> So you're going to make this tool available to customers? >> Yes, we have, it's actually available on our website. And if you come to our website, you'll be able to sort of run the assessment, as well as sort of see all of it yourself. >> Well, we've been following you guys since you launched. You've got a great management team, great technical chops, we've covered that. And this observability is a real trend as it moves into more complexity as we talked about. Most customers that are getting into this are trying to sift this from the signal, from the noise, and trying to think, decide who is the leader, and who is not. So how would you describe what a leader in enterprise observability looks like from a supplier's standpoint. You guys are one, you want to be the leader. You're the market leader. >> Right. >> What does a leader look like from a customer's standpoint? What are the things that have to be in place? What are the table stakes to be that leader? >> Sure, that's a great question. And yeah, so we did, SignalFx, we did build SignalFx to be a leader in this space, frankly. And there's a lot of different aspects that goes behind like what creates a good supplier in this space. One is I think you have to be open and flexible. Like you have to be, it's a platform play. You better be able to collect data from all the systems that are out there. The kind of the quality of the integration is very important. Another big thing we're finding is scale. A lot of these systems might not work when you move to sort of large numbers. And the problem that we are seeing is while I may have a hundred servers, I may be running 10,000 containers in those hundred servers. So now, everybody is a scale player, right. So the question is will your platform really be able to handle the complexity and the load? So that's an important one. Analytics as we mentioned is another very very important capability. I'll like to say that the ability to do analytics is not just good enough. How easy is it to use? Like are you developers and engineers, are they even using it? So the easy and the capability of analytics is important because that's kind of what allows us to measure those KPIs, those SLIs, those business metrics. And so that's kind of important. Slice-and-dice capability like how fast is the tool? Because when that outage happens, I don't want to run a five-minute query to sort of find some suspicion or you know to. And so the question is how quickly will it answer these ad hoc questions for me when the problem happens? So sort of the whole triage process that I talked about. The ability to support automation is one. The ability to, as I mentioned to take in different types of data, traces, metrics, be able to play with logs. All of those are sort of important aspects of it, yeah. >> Final question for you. If a customer says, "I'm going to cross the bridge "to the future with SignalFx." What's some of the head room? What's some of the futures that you would expect the customer to imagine or expect down the road as observability becomes more scalable? I can imagine the metrics are going to be all over the place. >> Yes. >> A lot of unusual patterns. New apps could come in that could be hits. And new data comes in. So as you take them today in observability, what's the next level, to cross that bridge to the future? >> Sure, sure. >> What's the next expectation? >> I think one thing will be to expect the unexpected. Because the world is changing so fast, I think you would probably be running things that you won't expect later. But a few things, I would say yes. So I think the proliferation of metrics and traces is like a big trend, where we see there used to be this dependence on sort of these monoliths and APM that sort of is transforming a little bit. There is this also this concept of using data science and artificial intelligence to come to bear on this space. So that's actually an interesting trend we see, where the idea is that it's hard because it's a complex system. It's hard for humans to define exactly what they want. But if the system can help them, can help identify things, that's actually really fantastic. Another one that we sort of briefly touched upon is automation or self-automated systems, where I think well, the time you're going to see that platforms like ours are going to help you automate much of this in a safe manner, because these are controlled systems, where if you, things can go awry and that's not a good position to be. So these are some exciting areas, where I think you will see some development down the road. >> And we've been seeing a lot of conversation around correlation and causation, and the interplay between those as these services are being stood up, torn down, stood up, torn down. You can look at the numbers all day long but you got to know causation, correlation. >> You bet, you bet because I think a lot of times, we naively think about this as a data problem, right? Where I find the kink in the graph, and if I go looking, I'll probably going to find a hundred different things that were sort of also correlated. Some of them may or may not be related to it. So I think a good tool is one that sort of gives you a sense. It sort of creates a boundary around the data set that it needs to look at, that is sort of relevant to your problem, and able to give you clues to causation. That you're exactly right because again, complexity is a hard problem to deal with. And anything that we can do to sort of help you short-circuit some of the pain is awesome. >> And I think you're on the right track with this developer focus because devops has proven that the developers want to code, build apps, and abstract away the complexity. And certainly, it's complex. >> That's right, that's right. It's fairly complex. >> Arijit, thanks for coming on. Arijit Mukherji, the CTO of SignalFx here inside the special CUBE Conversation breaking down the future of observability, where monitoring is going to the next level, certainly with cloud, impact to enterprise cloud. I'm John Furrier, here on theCUBE. Thanks for watching. >> Thank you. (groovy music)

(upbeat music) >> From Washington, DC, it's theCUBE, covering ScienceLogic Symposium 2019. Brought to you by ScienceLogic. >> I'm Stu Miniman, and this is theCUBE's coverage of ScienceLogic Symposium 2019, here at the Ritz-Carlton, in Washington, DC. Have about 460 people, it's a good mix of enterprise users, of course there's government agencies, as well as a lot of service providers, which is really where ScienceLogic started and has, many of their customers are in that space. And happy to welcome to the program, coming to us from Europe, a first time guest on the program, Luc Horee, who's RCloud and innovation Manager at Realdolmen, who's, as I said, a service provider. Thanks so much for joining me. >> Thank you, no problem. >> So, you're based in Belgium, you're a service provider, tell us a little bit about Realdolmen, a little bit about the size, scope, number of users, and we'll take it from there. >> Realdolmen is an Belgium company, around 1,500 people in an country that is small compared to the U.S. So we have an total of 11 million people. One of the biggest service providers in Belgium, but we also do reselling, and we also do service integration. Our customers it's Belgium, it's what we call SMB market. But we have around, in total, I think three thousand customers in Belgium. Some only are buying products or licenses, others are in fact in full manage service operations. >> Okay great, yeah, the SMB market, as you call it, we understand, especially for service providers, really important market, help them, I don't want to have to manage my IT, I want to be able to go to experts that can do this. >> That's one of the reasons, yeah. >> RCloud and Innovation Manager, it's an interesting title, tell us a little bit about your role inside the company. >> I already worked for more than 36 years in the company, so I had a lot of jobs within the company. In the previous job I was a Operations Manager, and now I am RCloud and Innovation Manager. RCloud is our private cloud that we are using for hosting customers and serving customers. It's and active-active data center where we can do disaster recovery, set up, and so on. So for customers that are no longer interested in building their own data centers, that's what we doing. And it's for some of them also an in between on-premise data center and public clouds. So we have customers moving to Azure and AWS, and sometimes they just stay for specific reasons in our RCloud. Innovation Manger is about how do we set up, how do we improve our tooling, and how do we improve our processes in helping and unburdening our customers. >> You mentioned the public clouds like Azure and AWS, do you have relationships with them, do you have connections into some of those public clouds? >> We are Microsoft partner, so most of our customers are going to Azure, but it's also building up in Amazon, and we did receive some questions also about Google. >> Okay, great. So when we talk about operations, service providers, very rapid change environment, typically you have a lot of customers to be able to deal with, give us a little bit about what's changing in your business, the infrastructure management and the tooling space. >> In the tooling space, IT is moving, IT in motion is what we heard in the keynote this morning. Customers are expecting a lot, about dashboarding, they want to see how their business is behaving not about what is a device doing. We need to monitor more and more applications, and the business lines. So that's why we are implementing ScienceLogic, or had an implementation of ScienceLogic, and now we doing the second phase in building more runbook automations, more dashboarding, more experience levels instead of SLS or XLS. >> Great, I want to get to the automation, but first, you've only been using ScienceLogic for a couple of years now, bring us back to, was it a bunch of in-house tooling that you had created for managing before that drove us there, paint us a picture of kind of the before and how you ended up with ScienceLogic. >> We had Microsoft Systems Center Operations Manager, we had Nagios, we had some plugs-in on this tooling, so it was I think in total six or seven tools, and we did some interfacing about it. But yeah, seven tools interfacing, not easy to run, a lot of management, a lot of people involved, a lot of skills required, so the reason was simplify it. >> So did you completely eliminate those seven previous tools? >> Yup, as of the 1st of April this year they are gone. >> All right, so there was a little bit of a journey, can you walk us through a little bit about there, was it prying it away from certain people, was it maturity from your side or from a product standpoint, what were some of those points that took a little while to get there. >> It took a while just to convince everybody in the company, set up an organization, it's not only the tooling it's also the organization need to be involved, a lot of communication, there's a change process going on, and we implemented, the first customers were in November 2017 on the system, and since then every month we added sometimes two, sometimes five, sometimes seven, sometimes one, as customer, so the people internally and externally need to get used to the product, so that's step-by-step, keep it simple, do it slowly but fast, and with a deadline. >> So, you talk a little bit about your organization operationally, what's the impact then to your ultimate end user, do they see anything, has it changed how, has it improved cost? >> It's changed certainly for the customers, because the old tools, there was no multi tenancy, there was not easy logon, so they had no access to the dashboards, they were just waiting for the monthly reporting and say, okay, it was up, okay we were, now they can have access, we use single sign-on to do that, so the customers are happy that they can see, they can see line of business dashboarding, and so on. And certainly internally it did improve a lot of cost savings, because a lot of the things we are doing now is automation, and we started the integration with our ITSM tool, and that will go live, normally next week. >> Okay, what ITSM tool are you-- >> It's a German tool, it's from a company called OMNINET, and the tool is called OMNITRACKER. >> Great, talk now about that automation, where have you come so far, where do you see it progressing in the future? >> We started first with some task automation, we have an 24/7 operation team, first-line, and they were doing a lot of manual tasks, so where we can, and what we first did was automate some manual tasks. And now we are progressing with ITSM integration, bi-directional integration, and then we will start with removing from old mailboxes, where we can do some restart automatically, so we will take a look at the incidents, see what we can do, see if we can do some automation with that, and we will certainly progress very far, as far as possible to do more and more automation and less manual work. >> Great, tell us, you've attended this event before, what brings you back to the event? >> First of all I want to see a lot of the demos, what's coming, because we are today, 8.12 version was announced, we are on 8.9, we will move next week to 8.10, so what is coming, so I have to talk internally to people, okay, what's coming, I need to convince all program managers, service delivery managers, I can talk to customers what is coming, what they can expect, so that's one of the reasons. The other reason is to talk to other customers of ScienceLogic, what are you doing, what's helping you, what's not, and so on. >> Yeah, I noticed one of the things they talked about is making it easier to upgrade from versions, when you think about the cloud world, as we talk about it, is, if your customers are in Azure, you don't ask them what version of Azure they're running, you're running whatever version Microsoft has it, they patch it, they update it, if security fix happens it goes there, when you talk about moving from 8.9 to 10 to 12, that process of when do I do it, how do I do it, how's ScienceLogic doing it, keeping things easy to upgrade, were there things in the keynote that you were ready to jump on? >> We started with, the first version 8.3 or 4 I think, and we always try to be in good shape in the newer releases. So we already had some experience with upgrading, and it's going smooth. And whatever I heard from the system engineers, it's going better and better and better. So normally we have only a very small outage to do that, in fact it should be minimal, sometimes they switch over or something like that, when a database is changed, but normally operations is always running 24/7, and there is no interruption for operations. >> Has there been anything at the show that you've seen so far, either through the demos, talking to some of the experts, or in the keynote, that you want to highlight? >> One of the things that I have seen is the connection with the application, with the APM tools, that's what our customers also are requesting more and more, the integration of infrastructure and application, and the multi cloud of course. >> Yeah, that's definitely something we've heard. All right Luc, I want to give you the final word, things to take away, for people that haven't come to a ScienceLogic event, what you think that they should take away from an event like this. >> For me the greatest take-away is come here to learn. Come here to see what is possible, what the future is, what AIOps will mean in the future, prepare yourself for the next three to five years, that's the main reason. >> Great, well thank you so much, preparing for the next three to five years, we know the pace of change isn't slowing down at all, so it's great to be able to talk to a practitioner that's helping to manage and deal with so many of those environments, thanks so much for joining me. >> Thank you. >> All right, and we'll be back with more coverage here, be sure to check out thecube.net for all interviews, I'm Stu Miniman, and thanks so much for watching. (upbeat music)