(upbeat music) >> Hi, everyone. Welcome to today's session of theCUBE presentation of AWS Startup Showcase, the new breakthrough in DevOps, data analytics, cloud management tools, featuring OpsRamp for the cloud management migration track. I'm John Furrier, your hosts of theCUBE Today, we're joined by Jordan Sheer, vice president of corporate marketing and Michael Fisher, director of product management in OpsRamp. Gentlemen, thank you for joining us today for this topic of challenges of delivering availability for the modern enterprise. >> Thanks, John. >> Yeah, thanks for having us. >> Hey, so first of all, I have to congratulate you guys on the successful launch and growth of your company. You've been in the middle of the action of all this DevOps, microservices, cloud scale, and availability is the hottest topic right now. IT Ops, AI Ops, whoever you want to look at it, IT is automating a way in a lot of value. You guys are in the middle of it. Congratulations on that, and congratulations on being featured. Take a minute to explain what you guys do. What's the strategy? What's the vision? What's the platform. >> Yeah, I'll take that one. So I would just kind of take a step back and we look at the broader landscape of the ecosystem of tools that all sits in. There's a lot of promises and a lot of whats and features and functionality that are being announced. Three pillars of durability and all these tools are really trying to solve a fundamental problem we see in the market and this problem transcends the classic IT ops and it's really front and center, even in this modern DevOps market, this is the problem of availability. And so when we talk about availability, we don't just mean the four nines for an uptime metric, availability to the modern enterprise, is really about an application doing what it needs to do to serve the users in a way that works for the business. And I always like to have a classic example of an e-commerce site, right? So maybe you can get to an e-commerce sites online, but you can't add an item to a cart, right? Well, you can't do something that is a meaningful transaction for the business. And because of that, that experience is not available to you as a user and it's not available to the business because it didn't result in a positive outcome. So the promise of OpsRamp is really around this availability concept and the way we rationalize this as a three pillar formats. And so we think the three pillars of availability are the ability to observe data, this is the first piece of it all. And from a problem perspective, what we're really trying to say is do we have the right data at any given point in time to accurately diagnose, assess, and troubleshoot application behavior? And we see it as a huge problem with a lot of enterprises, because data that can be often siloed, too many tools, many teams, and each one has a slightly different understanding of application health. For example, the DevOps team may have a instance of Prometheus or they may have some other monitoring tool, or the IT team may have their own set, right? But when you have that kind of segmented view of the world, you're not really having the data in a central place to understand availability at the most holistic level, which is really from an end-user to that middleware, to the databases, to underlying microservices, which are really providing the end-user experience. So that observed problem is that first thing OpsRamp tries to solve. Secondly, this is the analyze phase, right? So analyze to us means are we giving the proper intelligence on top of the data to drive meaningful insights to this operator and user? And the promise here is that can we understand that baseline performance and potentially even mitigate future instance from happening? How often do we hear a cloud provider going down or some SaaS provider going down because of some microservice migration issue or some third party application or networking they're relying on? I can think of dozens on my head. So that's kind of the second piece. And then lastly is around this act. This is an area of a lot of investment for ops because we think this is the final pillar for nailing this availability problem. Because again, IT teams are not getting larger, they're getting smaller, right? Everyone's trying to do more with less. And so from a platform perspective, how do we enable teams to focus on the most business critical tasks, which are your cloud migrations, adopting microservices to run your modern applications, innovative projects. These are the things that IT and DevOps teams are tasked with. And maintaining availability is not something people want to do, that should be automated. And so when you think of automation, this is a big piece for us. So again, the key problem is how can we enable these IT or DevOps teams to focus on those business critical things, and automate it with the rest. And so this is the OpsRamp's three pillars of availability. >> John: Talk about the platform, if you don't mind. I know you've got a slide on this. I want to jump into it because this comes up a lot, availability's not just throughout uptime, because you know, uptime, five nine reliability is an old school concept. Now you have different kinds of services that might be up but slow, would cause some problems, as applications and this modern era have all these new sets of services. Can you go through and talked about the platform? >> Yeah, absolutely. So OpsRamp has a very... We address this availability problem pretty holistically, like I mentioned. From a platform perspective, there that two core lines that are comprising a product. One is this hybrid monitoring piece. This is that data layer. And the next one is event management, it's more of the we'll talk about that analysis. And so we treat the monitor as a direct feed into this event management. We're layering that on top, or layering machine learning and AI to augment the insights derived from that first pillar. And so this is where we see a really interesting intersection of data science and monitoring tools. We invest a lot in this area because there's a lot of meaningful problems to solve. In particular alert fatigue, or potentially root cause analysis, things that can take an operator or a developer a long time to do on their own, OpsRamp tries to augment that knowledge of your systems and applications so that you can get to the bottom of things faster and get on with your day. And so it's not just for the major outages, it's not just for the things that are on Twitter or CNN that's for daily things that can just distract you from the ability to do your job, which is to be a core innovator for a business. >> I will really say John, that we are already seeing some couple things here. Number one, we're already actually seeing fundamental transformations in the marketplace. Customers who have seen reduction in alert volumes of up to 95% in some cases, which is as you can imagine, that's completely transformational for these businesses. And number two, I think one of the promises of hybrid of observability working in tandem with event and incident management is the idea of finding unknown unknowns within your organization and being able to act upon them. All too many times nowadays, monitoring tools are there to just surface issues that you may know that you're looking for and then help you find it and then take action on them. But I think the idea of OpsRamp is that we really using that big data platform that Michael talks about is to really surface all the issues that you might not be able to see, identify the root cause, and then take action on those root causes. So in our world, application availability is a much more proactive activity where the IT operations team can actually be proactive about these incidents and then take action on them. >> Yes. Jordan, if you don't mind, I'm following up on that real quick. Talk about the difference uptime versus availability, because something could be up and reliable but not available and its services get flaky. Things may look like they're up and running. Can you just unpack that a little? >> So to me, I mean the really key aspect of availability that I think the old definition of uptime doesn't address is performance. That something can be up, but not performing, but still not really be available. And his e-commerce example, I think is a great one. Let's take, for example, you get on Amazon, right? The Amazon e-commerce experience is always available. And what that means is that at any given moment, when I want to click through the e-commerce experience, it performs. It's available. It's always there and I can buy it at any given time. If there's a latency issue, if the application has a lag, if it takes 30 seconds to really perform an activity on that application, in the alternative definition, that's not available anymore. Even though the application may be up, it's not performing, it's not providing a frictionless end customer experience, and it's not driving the business forward, and therefore it's not available. The definition of availability in OpsRamp is creating a meaningful customer experience that actually drives the business forward. So in that definition, if a service is up but it's latent, but it's not providing excellent customer experience that the business wants to promise to its end-user, it's not available. So that's really how we're redefining this whole notion of availability and we're urging our customers and people in the marketplace to do the same. Ask yourself the hard question, is your application available or is it just up? >> Yeah, and I think that the confluence of the business logic around what the outcome is, and I think this is the classic cliche, "Oh, it's all about outcomes." Here, you're saying that the outcome can be factored into the policy of the tech, meaning this is the experience we want for our users, our customers, and this is what we determined as acceptable and excellent. That's the new metric, so that's the new definition. You can almost flip the script. It feels like it's being flipped around. Is that the right way to think about it? >> Well, yeah, I think that's actually absolutely correct that an application needs to be business aware, especially in the modern day because all of the businesses that we work with, their applications are really the stock and trade of the business. And so if you create an application that is not business aware, that is just there for its own sake or is not performing according to the revenue goals or the targets of the business, then it's no longer available. >> I mean, it could be little things. It could be like an interface on the UI, it could be something really small or a microservice that's not getting to the database in time or some backup or some sort of high availability. Really interesting things could happen with microservices and DevOps, can you guys share some examples of what people might fall into from a trap standpoint or just from a bad architecture? What are some of the things that they might see in their environment that would say that they need help? >> Yeah, I can probably take that one. So there's a lot of, I call them symptoms of a bad availability experience. And I wouldn't even say it's a pure microservice specific thing. I would say it's really any application that's end-user phasing. I see similar pitfalls. One is a networking issue. I see the number one thing usually with these kinds of issues that networking or config changes that can cause environments to go down. And so when we talk to organizations get to the bottom of this is usually a config wasn't thought through thoroughly, or it was a QAed, they didn't have the proper controls in place. I would say that's probably the number one reasons I see applications go unavailable. I think that's some majority of DevOps teams that can empathize with that is someone did something and I didn't know, and it caused some applications servers go down and it causes cascading event of issues. That's like modern paradigm of issues. On old school days, it's a layer zero issue, someone unplugged something. Well, modern times it's someone pushed something I don't have an idea of what we're doing opposing a downstream effect it would have been and therefore my application went unavailable. So that's again, probably the number one pitfall. And again, I think the hardest problem in microservices still around networking, right? Enterprise level networking and connecting that with many data center applications. For example, Kubernetes, which is the provider or the opera orchestrator of any microservice is still getting to the level, many organizations are still getting a level of comfort with trusting production applications to run on it because one is a skill gap. There's not many large organizations have a huge Kubernetes application team, usually they're fairly small agile units. And so with that, there's a skill gaps, right? How do you network in Kubernetes? How do you persist in storage? How to make sure that your application has the proper security built into it, right? Because that these are all legacy problems kind of catching up with the modern environments, because just because you're modernizing, it doesn't mean these old problems go away. It just take a different form. >> Yeah. That's a great point. Modernization. You guys, can you guys talk about this modern application movement in context to how DevOps has risen really into providing value there? Certainly with cloud scale and how companies are dealing with the old legacy model of centralized IT or security teams who slow things down? Because one of the things that we're seeing in this market is speed, faster developer time to market, time to value. Especially if you're an e-commerce site, you're seeing potentially real-time impact. So you have the speed game on the application side that's actually good, being slowed down by lack of automation or just slow response to a policy or a change or an incident. I mean, this seems to be a big discussion. Can you guys share your thoughts on this and your reaction to that? >> I can tell you that one of the places that we are displacing, one of the markets that we are displacing is the legacy ITOM market, because it can't provide the speed that you're talking about, John. I think about a couple of specific examples. I won't necessarily name the providers, but there are several legacy item providers that for example, require an appliance. They require an appliance for you to administer IT operations management services. And that in and of itself is a much slower way of deploying item. Number two, they require this customized proof of value, proof of concept operation, where companies, enterprise organizations need to orchestrate the customization of the item platform for their use. You buy separate management packs that would integrate with different existing applications on your stack. To us, that's too slow. It means you have to make a bunch of decisions upfront about your item practice and then live with those decisions for years to come, especially with software licenses. So by even moving that entire operation to SaaS, which is what the OpsRamp platform has done, has accelerated the ability to drive availability for applications. Number two, and I'd like to pitch this over to Michael, because I think this is really fundamental to how OpsRamp is driving availability, is the use of artificial intelligence. So when we think about being proactive and we think about moving more quickly, it takes machine learning to do a lot of that work to be able to monitor alert streams and alert floods, especially with the smaller scale down IT teams that Michael has mentioned before. You need to harness the power of artificial intelligence to do some of that work. So those are two key ways that I see the platform driving additional speed, especially in a DevOps environment. And I'd love to hear as well from Michael, additional enhancements. >> Michael, if you don't mind, I'll add one thing. First of all, great call out there, Jordan. Yeah. So the legacy slow down, it's like say appliance or whatever that also impacts potentially the headroom on automation. So if you could also talk about the AI machine learning, AI piece, as well as how that impacts automation, because the end of the day automation is going to have to be lock step in with the AI. >> Yeah. And this kind of goes back to that OpsRamp three pillars of availability, right? So that's the what we do, but again, it's all goes back to the availability problem. But we see that observe, analyze, and act as a seamless flow, right? To have it under the same group or the same tent provides tremendous opportunity and value for our DevOps or IT Ops teams that trust the OpsRamp platform because I'm a big believer that garbage in, garbage out. Having the monitoring data in native or having this data native to your tool provides a lot of meaningful value for customers because they have their monitoring data, which is coming from the OpsRamp tool. They have the intelligence, which is being provided by their ops cube machine learning. And they have our process automation and workflow to feed off that directly. And so when I think of this modernization problem, I really think about modern DevOps teams and the problems they face, which is around doing more with less, that's kind of the paradigm of many teams, each one is trying to learn, how do I do security for Kubernetes? How do I observe my security in the Kubernetes' cluster? How do I make sure my CI/CD pipeline is set up in such a way that I don't need to monitor it, or I don't need to give it attention? And so having a really seamless flow from that observe, analyze, act enables those problems to be solved in a much more seamless way that I don't see many legacy providers be able to keep up with. >> Awesome. Jordan, if you don't mind, I'd love to get your definition of what modern availability means. >> Yeah. So, you know, as I've gone through a little bit previously, so modern availability to me is availability uptime. It's also performance, right? Is the app location marks set down by both the application team, but also by the business. And number three is it business aware. So a truly modern available application is being able, is driving an excellent customer experience according to the product roadmap, but it's also doing it in a way that moves the business forward. Right? And if your applications today are not meeting those benchmarks, if they're performing but they're not driving the business forward, if they're not performing, if they're not up, if they don't meet any one of those three core tenants, they're not truly available. And I think that what's most impactful to me about what the platform, what OpsRamp in particular does in today's environment is operating under that modern definition of available is more difficult than ever. It is more difficult because we are living in a hybrid, distributed, multi-cloud world with tons of software vendors that are being sold into these organizations today that are promising similar results. So when you're an IT operator, how do you drive availability in light of that kind of environment? You have reduced budget. You have greater complexity, you have more tools than ever, and yet your software is more impactful to the bottom line than ever before. It's in this environment that we took a hard look at what's going on in the world, and we say these operators need help driving availability. That's the germination of the OpsRamp platform. >> That's a great point. We're going to come into the culture. And the second Emily Freeman's keynote about the revolution in DevOps talks about this, multiple personas and multiple tools that drive specialism, specialties that actually don't help in the modern era. So I'm going to hold that for a second. We'll come to the cultural question in a minute. Michael, if you don't mind to pivot off that definition, what are the metrics? With all those tools out there, all these new things, what are the new metrics for modern availability? It's more than MTTR. >> Yeah. This whole metrics that I think people spend a lot of time on, I think it's actually people thinking in the wrong direction if you ask me. So I've seen a lot of work. People say that the red metrics, that rate error duration or its views, utilization, saturation errors, or it's these other more contrived application metrics. I think they're looking at a piece of the stack, they're not looking at the right things. Even things like mean time to resolve and critical and server response time, mean time to tech, those are all downstream indicators. I like to look at much more proactive signals. So things like app deck score, your application index, or application performance index, these are things that are much more end-user facing or even things like NPS score, right? This has never really been a classic metric for these operations teams, but what a NPS score shows you is are your users happy using your applications? Is your experience giving what they expect it to be? And usually when you ask these two questions, even if you ask the DevOps team do you know what your Atlas score is? And you use NPS score, but what are those, right? Because it's just never been in that conversation. Those have been more maybe on the business side or maybe on the product management side. But I think that as organizations modernize, we see a much more homogenous group forming among these DevOps and product units to answer these kinds of questions. That's something we focus a lot on OpsRamp it's not seeing the silo of DevOps product or Ops. We're each thinking of how do you have a better NPS and how do we drive a better app decks? Because those are our leading indicators of whether or not our applications available. >> So I want to ask you guys both before, again, back to the own cultural question I really want to get into, but from a customer standpoint, they're being bombarded with sales folks, "Hey, buy my tool. I got some monitoring over a year. I got AI ops. I got observability." I mean, there's a zillion venture back companies that just do observability, just monitoring, just AI Ops. As the modern error is here, what's going on in the psychology of the customer because they want to like clear the noise. We saw it in cybersecurity years ago. Right? They buy everything, and next thing you know, they're going to fog of tools. What's the current state of the customer? What do they need right now as to be positioned for the automation, for the edge, all these cool cloud-scale next gen opportunities? >> Yeah. So in my mind, it's basically three things, right? Customers, number one, they want a vision. They want a vision that understands their position in the enterprise organization and what the vision for application development is going to be moving forward. Number two, they don't want to be sold anymore. You're absolutely right. It's harder and harder to make a traditional enterprise sale nowadays. It's because there's a million vendors. They're just like us. They're trying to get people on the phone and it can be tough out there. And number three, they want to be able to validate on their own with their own time. So in light of that, we've introduced a free trial of our cloud monitoring. It's a lightweight version of the OpsRamp platform, but it is a hundred percent free right now. It is available for two weeks with an unlimited number of users and resource count. And you come in and you can get started on your own using preloaded infrastructure from us if you want, or you could bring your own infrastructure. And we can tell you that customers who onboard through the free trial can see insights on their infrastructure within 20 minutes of onboarding. And that experience in and of itself is a differentiator and it allows our customers to buy on their own terms and timelines. >> Sure. And that's a great point. We brought this up last quarter in the showcase, one of the VCs brought up and says he was an old school VC, kind of still in the game, but he was saying in the old days in shelf where you didn't know if it was going to be successful until like downstream, now it's SaaS. If a customer doesn't see the value immediately. It's there. I mean, there's no hiding. You cannot hide from the truth of value here in the modern era. That's a huge impact on how customers now are evaluating and making decisions. >> Absolutely. And you know, I don't think any customer out there wants to read it on the white paper on the state of enterprise IT anymore. We recognize that and so we are hyper-focused on driving value for our customers and prospects as fast as possible, and still providing them the control that they need to make decisions on their own terms. >> Michael, I've got to ask you, since you have the keys to the kingdom on the product management side, what's the priorities on your side for customers, obviously the pressure's there, you guys are doing great, customers try it out for free. They can get, see the value and then double down on it. That's the cloud way. That's what's DevOps all about. You have to prioritize the key things, what's going on with your world. >> Yeah. And I would say of course prod has their own perspective on this. Our number one goal right now is to accelerate that time to value. And so when we look at one who we're targeting, right? So there's DevOps user, this modern application of operator, what are their core concerns in the world? One is, again, that data problem. Are we bringing the right type of data to solve meaningful problems? And two, are we making insights out of that? So from my priority's perspective, we're really driving more focus on this time to value problem and reduced time to there's some key value metrics we have and I'll go to that, but it's all an effort to make sure that when they hit our platform and they use our platform, we're showing them their return on investment as fast as possible. And so, what a return on investment means (indistinct) can slightly vary, but we try to narrow focus on our key target persona and market and focused on them. So right now it definitely is on that modern DevOps team enterprise, looking to provide modern application availability. >> Awesome. Hey guys, for the last two minutes, I'd love to shift now to the culture. So Jordan, you mentioned that appliance, the item example, which is I think indicative of many scenarios in the legacy old world, old guard school, where there's a cultural shift where some people are pissed off, they're going to go and they slowing things down, right? So you see people that are unhappy, the sites having performance of an e-commerce sites, having five second delays or some impact to the business, and the developers are moving fast with DevOps. The DevOps has risen up now where it's driving the agenda. Kind of impacting the old school departments, whether it's security or IT, central groups that are responding in days and weeks to requests, not minutes. This is a huge cultural thing. What's your thoughts on this? >> I absolutely think it's true. I think the reason were options differ slightly on that is we do see the rise of DevOps culture and how it starts to take control and rest the customer experience back from the legacy providers within the organization, but we still see that there's value in having a foot in the old and a foot in the new, and it's why that term hybrid, we talked about hybrid observability is really important to us. It's true, DevOps culture has a lot of great reasons why it's taken over, right? Increases in speed, increases in quality, increases in innovation, all of that. And yet the enterprise is still heavily invested in the old way. And so what they are looking for is a platform to get them from the old way to the new way fast. And that's where we really shine. We say we can enable, we can work with the existing tool set that you have, and we can move you even more in the future of this new definition of availability. And we can get you that DevOps state of play even quicker. And so you don't have to make a heavy lift and you don't have to take a big gamble right now. You can still provide this kind of slow moving migration plan that you need to feel comfortable, and it doesn't force you to throw away a bunch of stuff. >> And if you guys can comment on whole day two operations, that's where the whole ops reliability thing comes in, right? This is kind of where we're at right now, Dev and Ops. Ops really driving the quality and reliability, availability and your definition. This is key, right? This is where we're starting to see the materialization of DevOps. >> It's why we have guys like Michael Fisher who are really driving our agenda forward, right? Because I think he represents the vision of the future that we all want to get to. And the platform that the product team in OpsRamp is building is there, right? But we also want to provide a path for day two, right? There are still some companies are living in day one and they want to get to day two. And so that's where we drive out here. >> And Michael, the platform with the things like containers really helps people get there. They don't have to kill the old to bring in the new, they can coexist. Can you quickly comment your reaction to that? >> Yeah, absolutely. And I talked to a lot of, I won't name any but large scale web companies, and they're actually balancing this today. They have some infrastructure or applications running on bare metal that somebody's got Kubernetes, and there's actually, it's not so much, everything has to go one direction. It actually is what makes the business, right? Even for migrating to the cloud, there has to be a compelling business reason to do so. And I think a lot of companies are realizing that for the application side as well. What runs where and how do we run it? Do we migrate a legacy monolith to a microservice? How fast do we do it? What's the business impact of doing it? These are all critical things that DevOps teams are engaged with on a daily basis as part of the core workflows, so that's my take on that. >> Guys. Great segment. Thanks for coming on and sharing that insight. Congratulates the OpsRamp, doing really extremely well, right in the right position on ramp for operations to be DevOps, whatever you want to call it, you guys are in the center of it with a platform. I think that's what people want, delivering on these availability, automation, AI. Congratulations and thanks for coming on theCUBE for the Showcase Summit. >> Thanks so much. >> Thank you so much, John. >> Okay, theCUBE's coverage of AWS showcase hottest startups in cloud. I'm John Furrier, your host. Thanks for watching. (relaxing music)