IT service management (ITSM) has been around for a long time, but its relationship to DevOps has been nebulous at best. In this DevOps Chat, we explore the connections between DevOps and ITSM with Prashant Darisi, vice president of Product at Everbridge.
Everbridge is swiftly making a name for itself in the alert management space as a pure cloud company whose roots are firmly planted in DevOps. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Alan Shimel: Hello, everyone, this is Alan Shimel, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Prashant Darisi, VP of Product at Everbridge. Prashant, welcome to DevOps Chat.
Prashant Darisi: Thank you very much, Alan. Thanks for having me.
Shimel: Oh, it’s our pleasure. So, Prashant, you know, just let’s get off the bat, many of our listeners may not be familiar with Everbridge. Everbridge is not quite your usual startup in that it didn’t announce funding last week or something like that. So, why don’t you give your listeners just a quick kinda corporate background on Everbridge?
Darisi: Absolutely. Now, in the simplest single sentence, I would say Everbridge is the global leader for integrated critical event management solutions. We are a publicly traded company and we were founded following the tragic events of 09/11, where we realized that whether it is cross-team collaboration, cross-department collaboration, cross-city collaboration—there wasn’t a system out there that can connect all the dots to make sure that most important and pertinent information about safety of people, safety of enterprise, IT systems, physical assets and non-physical assets can easily ________.
And so, that’s how this company got started. We are truly born in the cloud. So, the good news for our cloud customers is that we were not a bunch of on-prem companies that we pushed into one of the cloud platforms and said, “Hey, here we come, adopting the cloud.” From day one, a pure SaaS company. [Cross talk] Today we have more than 5,000 global customers, and we serve about 9 out of the 10 largest U.S. cities, nine out of the 10 largest U.S. investment banks, seven out of the 10 largest U.S. software companies, 6 out of the 10 largest global consulting firms, 6 out of the top 10 U.S. universities, 5 out of the top 10 pharmaceutical companies, all the 4 large global accounting firms, right, and 25 of the 25 busiest North American airports use our SaaS platform to ensure critical communications for anything that affects public safety, enterprise IT outages, cyber attacks, or even terrorist attacks and severe weather conditions. So, that’s who Everbridge is.
Shimel: Excellent. And that’s very impressive, Prashant. Thanks for the background. You know, certainly, alert management alerting is in and of itself something that is not foreign to our DevOps audience, right? There are several sort of alert management, event management players who have really—I mean, they are sort of your traditional startups, right? They’re not public. I think one was actually acquired yesterday for $120 million.
Darisi: That’s true.
Shimel: But—you know, but they don’t, frankly, they don’t have the scale and the girth that Everbridge has, right? So, Everbridge was doing this before there was this DevOps movement and we were all excited about continuous delivery and continuous integration and that kind of thing.
So, but now, you know, what—I guess my question is, Prashant, what has made the DevOps market interesting to Everbridge?
Darisi: Yeah, for multiple reasons. One is, we have the platform that can support it, right? So, when we talk about how do we go and reach people—well, DevOps, for us, is more of a cultural change, right? I don’t want to pretend here, saying, “Hey, we looked at DevOps, this was the most exciting thing on planet Earth, and we start calling ourselves DevOps.” So, we are a critical event management company, but the beauty of this is that we drink our own champagne. When we talk about continuous integration and continuous delivery, we have, from a pure enterprise perspective, over 3,800 customers, and all of them get our new releases on the same instance, right? We offer it through ________ as well.
Now, we could not, obviously, do any of this using a traditional waterfall method, either in terms of the velocity, or in terms of quality. So, when we talk about, do you guys use Datadog, do you use Jenkins, Drone, do you use GitHub, do you put your artifacts in JFrog—any of the popular tools that are out there. We’re not trying to promote any one product. We live, breathe, and die by these processes day in and day out. That’s a survival issue, because we’ve never had what we call an on-prem piece. This is the only way we deliver value.
Now, if that’s what we’re doing and that’s the platform that helps people communicate and collaborate, why wouldn’t we naturally go into the world of DevOps? Traditionally, of course, we started into the ITSM piece of the world, right? This is where the ServiceNow, Remedies, and the HP SM worlds came into the picture. But, as organizations started shifting, Alan, I remember, I think you wrote—what, two, three years ago, that all the CIOs said 88 percent of them will adopt DevOps in the near future? That’s when even we started pivoting—how can we help these folks bring these solutions together?
So, the reason why we’ve gone here is, we can obviously help folks communicate with each other. We have about, what, 100-plus communication devices, and one of the advantages we have is, why DevOps is great—companies are also starting to spread their development centers across the world. You know, I’ve done development for—what, two decades, as an engineering guy? But I never was on call, right? But look at where the world stands today.
And so, if, just like technical support, engineers are starting to follow the sun model where you have a communication system that can cut across countries and do language translation, can you have collaboration tools like Slack, Tribe, HipChat, put it all together? Can you help customers do them with automation? Can you do language processing on who said what, what kind of diagnostic scripts were run? Last time when you patched the system, what were the results of it?
The analytics of those things—we have the platform, and the fact that we manage 210 million contacts worldwide, and the fact that we can send 2 billion messages, that’s the number we delivered in 2017, and we have access to 100-plus communication devices—it became a very natural fit for us from a domain expertise from within the organization, what a customer that’s doing CI/CD needs, and from a platform perspective of what kind of scale and geographic reach you need to have to bring the two worlds together.
So, I don’t want to pretend that we are born a DevOps delivery company, but we certainly are a born DevOps product company that today is public.
Shimel: Got it. So, Prashant, you mentioned a couple things, there, Prashant. The first thing is, there’s a very common fact pattern that I’ve observed in talking to many vendors in the DevOps space, and that is that their involvement in the DevOps market started with their own use of DevOps, right? They started using tools like Jenkins and JIRA and some of the others you mentioned, and that their own use and adoption of these tools allows them to kinda see the benefits, right, of using DevOps, and also then allows them, frankly, to have some credibility when they’re talking to DevOps teams in the marketplace, because you yourself are a DevOps team yourself, right? You understand what it’s about.
Darisi: Yeah.
Shimel: Understand? Yeah?
Darisi: Yeah, absolutely—completely understand. And, I think it’s, for us, just look at our own organization, right? And I don’t know how many of your listeners will agree. We have offices in Los Angeles, right here in Burlington where I’m sitting, Lansing, Beijing, London and Stockholm. Now, not all of them are development organizations, because we have grown organically. But we need to scale down that framework and true DevOps practices to keep ourselves, have some semblance of sanity. Otherwise, you know, we go nuts.
So, I do agree that, because we live and breathe these systems, I hope we are able to deliver our solutions with a credibility both from a domain expertise perspective, but also, a very natural alignment with the tools that the customers are using, right?
Shimel: Yep. Excellent. And then, Prashant, you brought up another kinda topic that we have been kinda running into and writing about more recently here at DevOps.com, and that is the whole relationship between ITSM and DevOps, right?
I think initially, you know, we started DevOps.com back in 2014, there was this feeling of sort of ITSM goes with waterfall, if you will, or it’s from that generation, and that somehow DevOps and ITSM were mutually exclusive. But the fact is, what we’ve seen in real life is that that’s not the case, right? That there are—ITSM, there is a bridge from DevOps to ITSM and back. And that there are, there’s—you know, I always like to tell people, Prashant, there’s only one truth. I don’t really care what you call God or, you know, we’re talking about religion, right? Good is good, bad is bad, and truth is truth.
So, the right things that we’ve learned to do in ITSM shouldn’t become wrong things in DevOps, right?
Darisi: Yeah. [Laughter] Yeah. So, since you used the word God, I will say amen—you hit the nail on the head, right?
Shimel: Yeah. [Laughter] Okay.
Darisi: I’ll give you a simple, Alan, here’s the analogy, right? I need to go from here, Burlington downtown, a lot north of Boston downtown, and I need to go from here to there. I could walk, I could take a small car, or I could take a BMW. Now, if my GPS is wrong, a BMW will only take me to the wrong place faster, right? It’s, in the end, whatever we use—tools, methodologies, anything—they’re a means to efficiency. It starts with a cultural change, right? Putting the right processes in place, and then automating these processes for efficiency reasons.
So, I would argue that—like I said, I just came back from meeting this very large priced customer, oil, and you could feel that the DevOps team thinks ITSM or ITIL or COBIT or any of these things—these are dinosaur practices. It’s not. Actually, you can use the elements of DevOps principles within ITSM. And you’re not going to solve everything using DevOps, because if you look at our shadow IT, there are some systems and infrastructures that are still being held traditionally in data centers that need to be highly secure. Then there is this concept of business driven apps where folks like to use Salesforce.com for their pipeline management. You’re not in control of that any more.
So, somehow, you have to be able to figure out what’s the dependency of the so-called shadow IT system sitting in the cloud, completely managed by a third party vendor through an SLA agreement, and you’re on prem in your own private cloud enterprises.
And so, I think the reason why people thought or still think, I think, ITSM is waterfall is this whole notion that, culturally, ITSM or ITIL or COBIT practices are all about who controls, right? Well, rather than talking about who controls, if the same principles can be applied within an IT organization to start enabling the business, start empowering the business to say, “Okay, you are in the better position to make the judgment call on something simple like access request, or what are the things that you need to look for when you deploy a patch or upgrade, and we will take care of the security aspects of it, and if something goes wrong, we will ensure proper communication and collaboration”—I don’t see any friction between the two worlds.
There’s a tremendous difference in lexicon, for sure, but many, many banks and many, many organizations which are true IT organizations are saying, “Prashant, do you follow the agile model?” Right? “We are doing project management doing agile now. Oh, you’re coming here to do an implementation and integration of DNC Committee or ServiceNow or HP SM? Can your PS implementation team help us break it down across our sprints?”
So, everybody has now started looking at the value of agile frameworks and beginning to see that, you know, the two worlds are coming together. And obviously, they’re embedding, from an HR perspective, people into each other’s team as well. So, then we talk about site reliability engineer, DREs, ________ operation folks, development folks, and perhaps even infrastructure folks all sitting in a standup or around a standup table. It’s all coming together.
So, I think this is a little artificial, whether we’re trying to drive this line or a hard line between it, there are definitely different lexicons, but I think there is an easy way to bring these people together from a process perspective.
Shimel: I agree 100 percent. And I think we’re seeing that kinda play out, right before our eyes in real time now. You know, we’ve seen, for instance, ServiceNow come out with a DevOps related system, right, that brings a lot of this together as well. I’m also involved and one of the co-founders of DevOps Institute, the DevOps Institute, and we have a drill down class on the bridge DevOps to ITSM.
So, I think that’s all there. But Prashant, as much as there’s a bridge being built and we’re learning how ITSM and DevOps works together, another thing we’re learning is how critical event management works with so many of these DevOps tools—and you mentioned some earlier on, but can you share with our audience, give us an idea, you know, we talk about automation and stuff like that—how does Everbridge help with that?
Darisi: Yeah. So, we’ll take it at the, let’s say, 10,000-foot level, and I’ll quickly and rapidly try to bring it down to a simple tool. But when we talk about critical event management, for us at Everbridge, a critical event or a disruption is a disruption is a disruption.
And so, since I gave the example of a tornado approaching a building in Oklahoma City, let’s stick with that. Now, whenever such an event occurs, we know what is going to get impacted, but I’m not sure people do get that. For example, clearly, we know some people will be affected from purely an evacuation perspective. We know that the buildings and the physical assets within the buildings will get affected, and then we also know that we might be hosting a data center or a set of services that are going to get impacted.
So, how can we help our customers figure out what we have coined as a consequence map. What is the consequence of a critical event or a disruption to a company’s business, both from a people perspective, physical assets perspective, and enterprise IT operations perspective?
And this is where automation starts becoming very critical. How do you understand, from a CMDB integration, what are the components out there, or which business units are affected, right? So, Everbridge, from our perspective, we do CMDB integration on a very lightweight basis. We obviously don’t want to get into the CMDB business, but our job is response correlation, right? We are not in the business of reading logs and packets and telling you about events. We are not a log miner company, we are a response correlation company. When a critical event occurs, there are a lot of connectors and automated tools that will tell us something is not right. Now, there could be a direct correlation from a response perspective on a denial of service attack that goes and impacts the performance of a website.
How do we make sure that we are helping our customers correlate their responses, right? How are we able to look at the product and location, the services that are impacted both upstream and downstream and trying to figure out, from a communication and collaboration perspective—Alan, you; Prashant, you—both of you are working on this critical event. One came through an item system, a new relic, or somebody telling you, and the other thing comes from a QRadar or a Resilient kind of a system saying denial of service underway. How do you know that you need to combine forces?
So, Everbridge wants to be in the business of response correlation, far less about event correlation. So, our automation platform or the smart orchestration platform starts picking up data from these disparate sources, integrates with stuff like the CMDB and looks at the CIs and says, “Hey, I see that these critical events are related,” right? For example, a fire in a building can—it’s police, it’s ambulance, and it’s the IT systems that are sitting there—how do we correlate this? That’s the business we are in. And, for that, you need a smart orchestration platform that is looking at data or alerts coming from these different places.
And then, when it comes to the pure IT pieces of it, right, how do we help from a DevOps perspective? Well, let’s start with the communication part of it. Can we reach out to these people, whether it is on call calendars, making sure that we follow the proper escalation procedures? I heard something else, Alan, you were talking to somebody, saying, “Hey, people still prefer e-mail,” or that’s still the number one choice. Well, in our Everbridge platform, for certain types of events, based on the criticality, we do not give the choice, even though every individual can pick 100 different types of modalities in which they can receive an alert, but for certain critical events, we will override that. We will wake you up during the morning—because guess what? An e-mail cannot wake you up, right?
So, it depends on those business policies and rules, and that’s the kinda of work Everbridge wants to do. And then, once you have communicated with these people, how do we bring them together? I mean, just today, right, we had to start GoToMeeting, and if I had used the phone, I would put in a 10 digit number, then a 9 digit code, then an audio PIN. Well, the way we help our customers is, when you receive that SMS text, all you do is press 1, and you’re on the Smart Conference page. No numbers to type, no nothing. And if you are sitting somewhere in Europe, somewhere in the Philippines, India, China, U.S., each one of them will receive a local code. So, nobody’s on an international call. If there is a language translation that needs to get done of the same, exact trigger, we help our customers do that, too.
So, now that you have a bunch of developers who are all responsible for taking care or of the resolution process, people typically will say audio is great, right, and oh, by the way, recording the audio is great as well. Can you enable us through a collaboration tool? So, this is where the second aspect of it comes, right? Whether it is using Slack, using HipChat, Tribe, Cisco Spark—we bring these people together.
And all of this is recorded or, as long as the customer prefers, they’re all associated with the IT incidents, and then we want to leverage this data for knowledge transfer, for blameless root cause analysis, a post mortem of the events that happened so that next time when a similar pattern of incidents occur, we should be able to say, “Hey, last time when this happened, go and look at that Slack channel or the HipChat channel. We ran these two diagnostics ________. Have you seen this? Do you want to try this again?” And then, our connectivity on the remediation side, people could say, “Hey, I think we should move to Apache server,” right?
And the way our infrastructure is set up, you can pick a certain set of Runbook procedures that are automated or, Alan, you could get a call and say, “The team that’s presently on call has decided that they need to reboot the server. Alan, you have been determined as the security architect that needs to approve this. Press 1 to approve an automatic reboot of the server, press 2 to join the conference bridge, or press 3 to enter the Slack channel.”
This whole process is automated, right? Whether it is smart conferencing or the on call schedule or integration with these collaboration tools or the Runbook automation tools and the recording for archival knowledge base and analytics purposes—everything is done with our platform today.
So, it can take various shapes and forms, but these are some of those key macro cases, Alan, of how our customers are using our product.
Shimel: Got it, got it. Alright. Prashant, I told you when we started, Prashant, the times goes so quick here. We’re way over time already, but—so, we’re gonna have to call a wrap. Maybe we can come back and revisit and talk more about this within the larger kinda landscape of what we see today in IT as well.
But for now, let’s call it a day. Prashant Darisi, VP Product for Everbridge, thanks for being our guest on DevOps Chat today, and we hope to have you back soon.
Darisi: Alan, thank you very much for having me. Looking forward to another conversation. Thank you.
Shimel: Okay. This is Alan Shimel for DevOps.com, and you’ve just listened to another DevOps Chat.