ServiceNow, Inc. (NOW) Earnings Call Transcript & Summary

Hello, everyone. Thank you so much for joining us for today's webinar on creating the next generation of enterprise software, as we navigate to the cloud. We're so excited that you're here. I hope everyone is having a great start or a great day so far. My name is Heather Archambault, I am a Senior Product Marketing Manager here at ServiceNow. So before we begin, just a quick safe harbor notice. This presentation may contain forward-looking statements that reflect the current beliefs of ServiceNow and are based on current information available. These forward-looking statements should not be relied upon in making purchasing decisions. So with that, what are we going to be talking about today? One, a little bit about navigating the shift to cloud. I'm sure a lot of you are experiencing some sort of shift to the cloud, and we're going to try to walk you through that and some good simple solves that ServiceNow can help provide you around how to scale and operate the cloud with ServiceNow and how to really double down and accelerate your cloud adoption with observability. So please feel free to submit any questions into the Q&A panel. At any time, we will have Q&A later in the webinar. And without further ado, let's get started. I'd like to introduce you all to the ServiceNow team for today. I'm Heather, we just met. And I'd like to hand it off to the other 2 speakers to introduce themselves.

Hi. My name is to Theo Simmons. Thank you, Heather. It's so exciting to be with everyone today and spend time with you, and so appreciative of you guys spending time with us. I've been with ServiceNow for 6 years. I'm part of our Technology Workflow Strategic Solutions team. Thank you. How about you, Ross?

Thanks, Theo. My name is Ross McDonald. I'm a Solutions Consultant here at ServiceNow, and I am part of the cloud observability team here. And so, I'll be doing the presentation and demo for that portion. I'm glad to be here and thank you all for joining.

Excellent. Thank you, both, and we look forward to seeing the great insights and product that you're going to display throughout this presentation. So with that, just kick it off something a little light. So today in the audience, what are you all looking forward to this coming winter? Is it a snow? The winter sports such as skiing, snowboarding, snowshoeing, the list can continue to go on forever, if you'd like, the holidays. Hockey or if you're like me, it's halfway to summer. Please take some time and submit your answers. Theo and Ross, what would yours be?

Definitely the holidays. I grew up on the beach. So anything with snow or winter sports aren't for me.

So I think you're probably a mix of holidays and summer.

Yes. That's good. Yes.

It would be winter sports to me.

Winter sports.

Yes. Yes. I'm looking forward to going to skiing next month.

Awesome. All right. Well, with that, let's see, we've got a good amount of the audience clicking in. So let's see what everyone had to say. The holidays it is. Yes. So I'm from New England and not looking forward to the snow especially since I saw some this morning. All right. So now let's just dig -- let's dig into the topic for today. So as noted, this is really about how we can create the next generation of enterprise software, as we're shifting to the cloud. But shifting to the cloud for many organizations, it's different in many ways. And today, organizations may be deploying a service operation solutions, which and that will deliver extraordinary experiences and keep their digital services running 24/7. But at the same time, they need to make sure they are building capabilities to manage governance, cost, risk and security. So for IT operations teams, if there's any on this call today, you may be managing complex enterprises, you'd have a lot of on-prem, internal employee-facing and customer-facing applications. Some of these applications are staying, where they are in the data center, but some are -- have or are beginning to transition to the cloud either to a SaaS provider or they are being lifted and shifted. So for example, moving to a SaaS provider might be -- have -- moving from an on-premise exchange environment to Office 365, where lift and shift might be moving more a fleet of servers and databases from on-prem to cloud. But to add a little bit more complexity, there's also this fourth category of application, which we will talk a bit about later on in this presentation, which is around cloud native. And while the lift and shift of workloads to the cloud is mostly about shutting down a data center. The motivation to move to cloud native is much more than that. It's more of a business standpoint with the goal being not just to move to the cloud, it's really about optimizing for parallel innovation. It also allow us for an organization to get the biggest [ gain ] for their buck out of cloud. It's you're fully utilizing, you're transforming, whether it's through distributed teams, Kubernetes, microservices, it's ultimately a new software development life cycle paradigm. So one of the questions becomes what is the interplay between cloud native software development life cycle and service operations. And in turn, it's actually very problematic. So to contend with the complexity, which I briefly mentioned before, the complexity within a dynamic and the [ referral ] nature of modern cloud and cloud native environments, enterprise organizations need technology that at a level that is unmet by tool design for a cloud transition era of just lift and shift. They needed a much larger scale than ever before. So with ServiceNow, we're able to help you connect all those dots and really supercharge your cloud-first strategy. We provide a unified solution, which we'll get in tune a little bit that allows you to achieve excellence in the cloud, letting you effectively plan application modernization, automate cloud processes, operate cloud services resiliently. You can create a robust foundation for both migration and ongoing innovation, unlocking the full potential of cloud, while maintaining consistency and control. And if you already use ServiceNow to manage your existing digital services outside of the cloud, so if you have on-prem and so on, you can now leverage this investment to create a unified framework that really spans both on-prem and in the cloud and connecting that all together with full visibility. So when it comes to moving to the cloud, what really is top of mind. Cloud technologies have become the foundation that enables organizations to transform, differentiate and gain competitive advantage. Adopting a cloud-first strategy allows for both modernization, innovation and improve the end user experience, while also reducing costs. So here on the left, you see modernize architecture. What we can do is really help plan for app modernization. Many CTOs, they want to modernize their apps, but also prove the ROI of their investment in the cloud. Since many organizational processes lack automation across enterprise visibility, they often see redundant apps running an on-premise and in the cloud, and ultimately, that does cost you. It is -- it does increase costs. They also fear not having the right risk metrics when transforming apps to the cloud. First step is to shut down apps that you don't need. This is also tried to underline infrastructure such as hardware and software. The next step is really around scaling cloud processes with automation. Organizations experienced a greater sense of urgency to automate software delivery processes and enable greater collaboration and alignment across the business. When it comes to scaling cloud adoption in the enterprise, the #1 question our customers ask us is how can we help provide self-service catalogs? Typically, developers have automated tools to create cloud environments, provision resources and compute and so on, but often they might not adhere to corporate policies. Organizations ultimately need automation of cloud request, intimate and change management processes without slowing developers down. And lastly is really -- people are really thinking about how can we continue -- we shift from modernizing, we've now scaled, but how can we continue to operate, innovate and transform in the cloud? And ultimately, the success in operating and transforming in the cloud is driven by standardization and automation. And it's not -- it not only simplifies the process, but also enables to be more agile and resilient and to innovate at scale. The growing frequency of software updates coupled with the increasing complexity of today's cloud architectures makes it easier for defects and vulnerabilities to go undetected and enter production. So a new approach for operating in the cloud is needed to keep up with the demand for faster, better and more secure digital experiences. And as we all know, everyone's journey is different. The people on this call, everyone is probably [ somewhere ] within their cloud journey and the way they got there is not the same as the next. Today, we will show you how ServiceNow can be your trusted partner on your cloud transformation regardless of where you are, whether you're moving from legacy processes and architectures to modern workflows that help you plan cloud adoption, scale talent, rationalize apps, create self-service catalogs for development and operate customer-facing services with central visibility. And just to note, the majority of today's call will be on the middle and end part, so scale and then operate within the cloud. But we're happy to answer any questions around modernization as well. So with that, I will have one last poll, and this is what are your biggest challenges you are currently facing in your cloud journey? You can select all that apply because I know there can be more than one. Is it difficulty with cloud migration and management, manual processes for changing cloud provisioning, lack of visibility to hybrid infrastructure and services, so that could be something spanning from on-prem cloud or cloud native, so your typical hybrid environment, lack of insights into what apps to modernize versus rationalize, cloud costs are surpassing what we forecasted or -- and/or difficult proving ROI of cloud outcomes. Theo and Ross, what have you all heard from customers you've spoken to with -- for cloud that the challenges that they're experiencing?

2 things stand out in my conversations, one, seeing the return on investment, making a move into the cloud. And that kind of will spin off into, are we moving the right things fast enough? And are we accumulating technical debt, so all around costs?

Yes. From my experience, it's related to cost, obviously, but in addition, complexity is another factor that we see a lot that the processes that worked for on-prem or colo environments do not work in the cloud in a lot of cases. And so, there's a little bit of struggle to adopt the kind of the latest and greatest techniques and tools and processes on top of the immense amount of stuff that's in the cloud. So I'd put it complexity.

Perfect. All right. So it looks like the biggest would be the visibility into the hybrid infrastructure, great. We absolutely hear that a lot, as Ross was just saying, and we've been hearing this a lot from other webinars we've been doing as well. And Theo, you got your cloud costs right here, too, pretty high up on the totem pole. For the most part, it seems a lot of these are pretty split, which is great. So the reason we asked this question, there is a lot of these challenges, we will talk about how you can solve them with ServiceNow. So with that, I am going to hand it over to Theo, to walk you through how you can scale and operate cloud with ServiceNow.

Awesome. Thanks so much. I appreciate all that. And I appreciate everyone's response and participation this morning. So we're going to talk a lot, as Heather mentioned, we can help scale and operate on the ServiceNow platform and that's beyond just the -- maybe what you may consider normal kind of things. But first, I want to talk a bit about what maturity looks like for customers that we're talking to. So 1 and 2 years, they're kind of, hey, I don't who move my cheese, the business owners, the application owners, who do this business for you and your enterprise are a little bit hesitant to moving their things into the cloud. They are thinking, well, I won't be able to access it, I won't be able to people control things. How will things happen? What will I do when there's an outage. Well, I just saw the thing in the news here today about a huge outage. Then you're moving into, well, okay, it's starting to work for me. I'm starting to see things kind of move. I'm starting to see the benefit of moving my things to the cloud. I get to be able to improve performance actually. I am starting to see a lot of benefit from moving to the cloud. You're starting in your organization to create a cloud center of excellence. So as [ devs ] are starting to put things in the cloud, these early adopters in your enterprise, they have to put some formation around the governance and security within the cloud. And we see the vast majority of customers in this, hey, we're in this semi halfway in the cloud, we have one half -- one foot in the cloud, one foot still in the on-premise world. And then, we see a fairly small amount of customers, who are flying along their full cloud. And when I say full cloud, I really should mean -- should clarify that they moved everything to the cloud that they feel comfortable with moving to the cloud. So they do leave some things in an on-premise state, but we also run into customers that are 100% in the cloud, and ServiceNow would be one of those customers, where we run all of our business in the cloud across multiple AWS this year and some GCP as well. So we see the full gambit. And they're really into automating -- ServiceNow has automated something like 65% of the processes, as we've grown from a 5,000, 6,000 person or to a [ 20,000 plus ] or we have kept nearly flat on our service support tools. So we have automated so many great things inside of ServiceNow, as a consumer of our own software. So as you can see, with the level 1, it's really about the early -- the devs. They're using their tools that they love, whether those be GitHub, repos of all sorts, coding terraform, blueprints, et cetera, they're really trying to get things out the door. And they are starting to in year 2 or in the Level 2 starting to bottleneck because there's so many requests coming from the organization to -- into these devs, they are starting to slowly realize that we can't scale quick enough. We don't have enough cloud architects to help us realize the value. We're starting to realize that we need -- we need some good configuration and controls. The CDIO and CIO in the organization starting to realize, hey, I need to partner with my CISO to put some security and governments around all these requests that are coming in. And I need to start the catalog, what are the known good configurations that are important to us. And then in Level 3, it's all about shift and lift everything is, hey, let's -- let's make it cloud native, cloud-first, and Ross talk a bit more about that. And you're really understanding what is the microservices that you're providing any organization. And what we see is, hey, let's simplify what we need to do in the cloud. Let's have a shift mind -- shift-left mindset. We're really embedding security and [ known ] good configurations in all these requests. And then, we're really focused on how can we automate, how can we not just automate the request and automate [ known ] good configurations, whether that be a tag policy or a cloud security posture stance, but how do we automate the remediation. So when things break, as they're going through the pipeline, how do we go out and fix them quickly, so that we're not having a huge outage across the organization. So we're going to show that demonstration today. We're going to focus on scaling, using all the power of the platform within ServiceNow, one data model, one architecture, seeing things happen from, in this case, in the middle of how we scale in, to how we operate and support and then Ross is going to really dive in and look at how we can -- in that level 3, which already look at the logs, understanding how to troubleshoot that and do some really good root cause analysis. So without further ado, let me jump into a demonstration. Okay. Great. Good. Just a second for it to appear on everyone's screen. Here, we're looking at the employee center. This is ServiceNow central unified portal for all of your business. It's where your users come and trust. They know they're going to get the answers to the questions they're looking for, whether that be attestations for support that they have. I'm here as a business owner of applications. So I'm going to see lots of things that are important to me. I'm going to see popular topics that fluctuate based on how they're configured by the administration of the solution or how many times they've been submit request. All the information that's important to me, pops right here. It is contextual to who I am and what I want to do. But this part of our story, we're talking about I need to make a request for a new Azure resource. So if I am going to do that, I would just dive in because I could do -- because I'm allowed to do that. I can see the Azure request and AWS request available to me. As I click on those requests, I can start to fill out all this information that's important. These are known configurations that allow me to make my submission using the approved cloud center of excellence policies that are in place. It's going to put the right security posture. It's going to put the right tag governance on my request. I'm going to make a request for a new Azure system using the templates. So it integrates with all of the great JSONs and YAMLs and GitHubs and the Zipkins, all of the pipeline tools that your devs are used to using. I can make those requests here. It's going to be preapproved. It's going to go right through the flow system that underlines the platform. So it's going to show up in someone's queue, either approved or auto or swipe right and is approved. I will then know when that request is actually fulfilled. So ServiceNow will now push that request to the Azure cloud, through some automation. It will then spin it up. And as it spun up, it's going to automatically based on events, push that request back into the ServiceNow CMDB. And our AI and ML service mapping will attach it to the appropriate service. Now I think everyone on the phone has encountered as soon as you start doing something, people start changing it and putting things into it, and that often will lead to breakage. So in this case, I'm here listed as a NOC operator. My job is to keep all of these lights green, as best I can. I am taking alerts from a lot of disparate services. So Dynatrace's of the world, your SolarWinds, ServiceNow, we're taking all kinds of events from the world, bringing them into ServiceNow, and we're making sense of them. And what that does is it allows Amelia, who's the operator to make sense of the world and to prioritize for work and suppress all of the noise that can result from an outage. So in this case, you can see there's a group of alerts that are tied to Oracle issue. She can narrow that down and then she dives into start to -- and the system has actually done a couple of things. It's taken a bunch of alerts and groups them together. It's attached them to the appropriate services that are impacted, and thus, I would know, who to contact and who I need to work with. But it's also -- because it looked at the pipeline -- or the changes they went through the pipeline last night, it's identified a probable root cause. So I can actually go into and look at this [ change ]. Now Amelia, is not a coder. She's not often in solutions doing changes and configuration and co-changes, but DevOps config has linked this in, understand the scope and the impact is also taking a snapshot of the changes that went through the pipeline last night. Now what this allows Amelia to do is to see what changes were made, if you can look at the actual difference or the delta in the changes and help her make some decisions about what things she needs to do to remediate and resolve this problem. Some other important thing, she can do. She can go and look at the service map of all the things that have happened. It helps her develop a good sense of what's being impacted, again, what team member, she may need to work with to solve that problem. She can actually go and look at a history map of all the changes that have occurred in this business system, and she can see what alerts are related, she can go back and look at the history of changes, she can give a lot of really important contextual information about what she needs to do to solve this problem. And again, this is all built and maintained either through a number of mechanisms, we'll say, and creating service maps. But more importantly, our AI and ML will actually go ahead and any time there's a change, any time there's an update to the service map automatically put those into the map. But we're here to solve the problem. So we can actually go back and look at this group of alerts. And more importantly, we can actually automate the resolution solving the problem. Because we know what service was impacted, we know, who was impacted. We can actually [ make work ] for me today. We actually go into the actual service and run a remediation, it will actually push the change and update to the actual workload, but we'll actually get into that a bit more as Ross will want to show you the contextualized log tracing and all kinds of really cool things around observability. So she can actually push the change. She could push degradation. She can engage different team members if needs to. She can follow the standard operating procedures to ensure that she's solving the problem. Now we understand how we kind of scale out the request for cloud, we understand how we can predict and prevent issues. So I just showed you with our service operations, workspace. But here I am, as Carla, Carla is part of our security team here at ServiceNow and the story as everyone has encountered security and vulnerabilities is a 2-way street with public cloud providers. So if you're using Tenable, Rapid7 or using some of the vulnerability scan that the public cloud providers will take those vulnerabilities, as they occur, bring them in to ServiceNow, attach them to the appropriate CIs, attach them to the perfect business services. And then, it will automatically do a couple of things, depending on how you run your business, but we see 2 major things with most of our customers. One, it will assign those vulnerabilities of the impacted services to the business owners and asked them, hey, is this something that's a real vulnerability, how do you want us to approach it and give that power to the business owner to approve and run remediation because it is -- that is very common or 2, we see the vulnerabilities come in, "Hey, it looks like this is an approved patch level, let's go ahead and automatically prove it, push that vulnerability patching back to our preferred patching system and close the loop on doing the actual vulnerability patch. A couple of things that provides almost all of our customers regardless of the process. One, we track when the vulnerability came in, attach it to the CI, who approve this vulnerability is something needs to be worked on. When was it closed out and the change implemented and you can go through those pretty easily with our remediation process by following a 1, 2, 3 step process. As I do this, it will close -- it will create the remediation effort, depending on my process, it will automatically or through a manual process, create remediation depending on our business rules. And then, I can see this attached to all of the CIs when they were done, when it was completed. Last thing. As I mentioned, when I was talking -- when Heather asked the question, we see costing all the time with customers. And there's a couple of main things that they -- we are seeing from customers. One, when they're actually making the request, they're not -- if they don't use service catalog, the known good configuration, a lot of these customers are seeing their teams use contracts that not -- that are part of the overarching contract with the enterprise. So they're one-off thing updates or -- and not using the advantages that they've gained by this negotiation with Microsoft with GCP with AWS. But secondly, are you using the right size or the right resource in the cloud? Are you paying more for something that you're not using as much of. So ServiceNow will connect to your contract that you have with your provider and actually look at, okay, here is the request that or here are the resources that I'm using, it will break it down by spin, it will break it down by forecast and then actually give you, hey, here's a bunch of resources that aren't used appropriately right size them; and 2 -- [ or ] give you things that aren't used at all, and you can set the rules to be, hey, they haven't been used in 30 days. They haven't been used in 45 days. And we run automatically to reclaim or shut down those resources, pause those resources, so that you're not using part of your contract spend that you've negotiated with ServiceNow. And we -- again, we use all common business rules that the providers provide for you, as well in your contract. And again, this is based on your contract information. Not anything ServiceNow necessarily needs -- could be different for any customer. So we've talked about how as a business owner, I can scale my cloud request easily through our service catalog, use known good secure configurations that are approved by our CTO, our CCOE and our enterprise architecture team. I've talked about how we can then see those events -- event-driven discovery solutions, CIs or resources in my cloud, drive into my CMDB, attach to the mapping service maps and business maps that are important, how I can go through it and predict and prevent issues from happening because we're taking a lot of disparate events correlating them, suppressing the noise. And then security is a 2-way street. So how do we take vulnerabilities, for example, that are happening all the time. You see them in the news with CIs, attach them to the CIs and run a closed loop change or remediation on those. And then lastly, we've talked about how you really truly operate well in the cloud, you don't understand what you're spending? Are you using the right contract and ensuring that you're always fine-tuning the resources that you're using. So as I promised, Ross is going to talk a lot about diving in and doing some root cause analysis on logs. So I will now transfer it over to Ross.

All right. Thank you, Theo. So just like Theo mentioned, so we're going to be transitioning more over to the cloud observability portion of the discussion today, and so how you can transform in the cloud with observability. And so -- and just to clarify real quick as well. So observability really is just monitoring. And really, there's a few different kind of things that really kind of separate us from kind of more traditional monitoring vendors, which I'll touch on here during the demonstration. But really, when any time you hear observability, you can think monitoring, you can think understanding how your systems are performing, why they're performing, the way they are. And more specifically, the 3 telemetry types that you see over here. So we integrate and we have actually helped co-found an open-source project called OpenTelemetry, which exists within the CNCF, which is the Cloud Native Computing Foundation, which governs things like Kubernetes [indiscernible] of the Kubernetes. All right. And within the telemetry realm, so the kind of the observability realm monitoring all the data that comes into the platform fits into these 3 categories.

Apologies, Ross. This is Jessica. I'm so sorry, Theo, can you stop [ your share ] so that we could see the slides? And so, we could see Ross on screen.

No problem. Sorry about that.

Go ahead, Ross.

Okay.

You might just need to restart from the beginning of the slide, so we can see everything. Thank you.

Sure. Yes. Yes. No problem. Yes. Thank you. And so, yes, apologies for that. So here in the middle is the cloud observability portion. So this is again a kind of a high-level overview of where we sit within the broader ServiceNow portfolio. And so, cloud observability is a monitoring solution. We're highly performing, highly scalable, very cost effective. And when we think observability, we think monitoring, we think these 3 telemetry types up here in the left, which I'll get to OpenTelemetry here in a second. But we have the metrics, we have the logs, and we have the trace data. [ Where ] metrics are is really any kind of number, so it could be a CPU utilization. It could be the number of requests over a given period of time, it's usually something you want to chart any time series type fashion. Below that is logs. Hopefully, everyone is familiar with logs. But any kind of text or structured and then be structured -- be structured or unstructured kind of textual information about what a process or a server or application is doing at any given time. And then we have trace data. And trace is probably the most sophisticated out of the 3, but the trace data is the applications themselves, self-reporting, who they're talking to, what they're doing at any given time. And so, it gives -- allows you to see very granular information about, for example, the request life cycle for a transaction that entered your ecosystem into your digital estate, and I'll show what the trace data actually looks like here within the platform. But that certainly probably the most sophisticated out of all 3 there. And OpenTelemetry is really the common standard for these telemetry types. And so instead of every vendor or tool or agent having its own format for metrics and logs and traces, OpenTelemetry has really just kind of created a common substrate for these data types, and so it's a little bit more than that. There's an open-source project structured around it. But more generally, when we think OpenTelemetry, it's really just a common schema for these telemetry types. And as they go into the platform, we have workflows that can keyed off of each individual telemetry type, as well as workflows that allow you to query and utilize the telemetry types in a unified fashion. And so instead of having to look only at metrics data and then look and then have to go to a different pane or a different screen to look at the log data, and okay, a different screen for the trace data, you can visualize all the data and replace, you can chart it, you can dashboard it, you can create alerts off of it. And so, it's, again, very efficient, cost-effective and scalable way to ingest this data into the platform. It really understands the heart of why your systems are performing, what they're doing at any given time and especially when it comes to root cause analysis, which I'll show here during the demo. As far as how we fit is the larger portfolio here, so we have alerts that can flow into the event management workflow that Theo had shown previously. And so, you can have that data flow into the events that can be bound to CIs, can key off of all the great work that has been done on the AIOps and the ITOM Health portion of the product here. And so that includes alerts duplication. You can -- you get [ on map ] grouping and so on and so forth. And so, there's a lot of great. And then, of course, the automatic remediation and the workflows that can be key off of the alerts is also very important. And then second, we have the very bottom there is the Service Graph Connector for OpenTelemetry. And so, the Service Graph Connector really is -- it suits 2 different purposes. The first is for importing service maps from the trace data. And so, as applications are traced, they report -- I'm service A, I talk to service B, I talk to service C, I talk to X, Y Z, thing, not only services, but also applications or other third-party services or applications and you [ go in a ] SaaS service that also you'd like to incorporate into a service map. All that rich data can be then imported into the CMDB into ServiceNow and visualized in this topological map format, that Theo has shown before, but you see here over here on the right. And so, it allows you to very quickly see at a glance, who's upstream, who's downstream, which ones are having issues, which ones are not? What does my state look like in a more graph like format. And so, with the trace data as well, this is not static. It's not something that was set before hand by an admin and now it's going to fall in that data drifted from reality a little bit. It is guaranteed to be accurate because it's derived from the live application data, which makes it very effective again. So it's effectively real time in that sense. It also allows you to automatically import the services from the trace data automatically. So you don't need to go and like pre-create them or anything like that. And so, you can discover all the services and the applications that your services rely on, again, whether that's upstream or downstream dependencies and especially when it comes to looking at issues, that's where you can understand [ blast radius ] very quickly. So I can see who's impacted by any particular outage or incident that I may be looking at. These are tied to this -- the relevant CIs as well. And so, you can understand again that from top to bottom, the entire impact of a particular incident, you can understand, which services rely on other services, as part of their applications. And so, if you're looking at transitioning services from different clouds from an on-prem data center to a cloud data center, anything like that, makes it very, again, very easy to understand who's going to be impacted by a particular change, by particular alert. So again, from top to bottom, from the macro level view, looking at the [ 10,000-foot ] views here of the hundreds or thousands of services within our purview as an organization, all the way down to the very microlevel view. So looking at an individual request that entered our estate. So that covers the service map portion. The second portion is related to Kubernetes CIs. And so Kubernetes CIs historically have been difficult to import into the CMDB. And so, this may provide a very easy way to do that. So just by looking at the metric data, we'll automatically import the Kubernetes CIs. So that includes things like the Kubernetes nodes, the clusters, the pods, the deployments, any kind of workload, as well as all the way down to the container level view. And then, allows you to unify the service maps, as well as the infrastructure, the Kubernetes infrastructure level view. And so, if I want to look at it and say, okay, this is the service that I'm running, but where does it sit in my actual Kubernetes cluster, which is going to fit kind of the larger cloud estate that you may have under your management that allows you to integrate those 2 together. And so instead of having a look again, just the infrastructure view and then having to kind of think about how that may impact the application level view, you now have them under one map, one place and then bound on the back end within the CI data there. So upstream, downstream dependencies, both the application infrastructure would be viewable and available, and then, of course, tied into the context as whether it's an operator or a support person or IT operations that's handling any kind of incident like that. And it's really the goal of both the Service Graph Connector here as well as the cloud observability product more generally is a little bit more on that shift-left mindset that Theo mentioned earlier. So the developers and SRE teams, the site reliability engineers are usually the folks that are kind of more engaged on the very low level details, while service operations, IT operations folks are high level and the ability to bridge those gaps and understand, okay, here's the high level overview, all the way down to the very minutia of how a system or service is performing is really critical for ensuring uptime, as well as handling incidents, as they come up. And this is an overview of how we fit into, again, the larger AIOps work stream within ServiceNow. And so over here on the left, where it says telemetry data there, you have metrics, logs, traces, events, config. This is really where the cloud observability portion sits, and this is the applications that are emitting metrics. They are emitting logs, emitting traces. And this flows into the broader platform in the form of both the telemetry types itself, as well as things like alerts. So as they come up, they feed into the platform. The platform learns from them. We do the predictive analytics on that. There's also anomaly detection out of the box, and we'll show a little bit of what the alert grouping and things like that can look like. And then, there's all these great workflows that can really [ keyed off ] of that as well. And so automatic remediation, of course, there's all sorts of great workflows. You can respond to customers, notify customers, reassign, even go and restart machines or kick off certain different workloads. So there's a lot of great things that can be included, as part of the entire stack here, not just one individual component. All right. Let me jump now to [indiscernible]. Okay. And so, here is the service operations workspace within ServiceNow. And so, from here, this is the 50,000-foot view. I see all the services that I'm responsible in a single location. I get this nice red-green view, so I can understand what needs my intention, what does not. Regardless, I could be an operator, I could be someone responsible for these services. I could be someone, who's really just under managing the entire service portfolio, not any individual's fixed service or I could be someone in support that's looking and looking to triage or understand what are the alerts that are going on here. If I look at one of these alerts, we can see this is an alert group, and this was created from 11 different alerts. And so, we need to refer to that kind of the alert grouping or deduplication, really, this is the AIOps functionality here at play. So we can see that instead of having to go and respond to have 11 different incidents that may have come from different platforms or products that we may have integrated with, they are now collapsed into a single alert, and so instead of having to deal with 11 different alerts or incidents, I now have just a single one to view. And in this case, we can see we have sort of high service log, we're seeing high latency, we're seeing large number of error logs, high latency for a particular service or application. And so all this being deduplicated into one, very beneficial. We can see the impact on the relevant CIs, the impacted services. And then, of course, we also have the probable root cause surface tiers. So again, if I'm someone, who's trying to impact -- understand the impact of this particular incident or understand if there's actually an incident going on at all. I have got all this data at my fingertips here. Within this, we can see the applications, so that one of the -- this is one of the services that was involved. [ Only ] from here, we can see the actual service map and this is derived from that live application data. Again, so it's guaranteed to be accurate. This is not something that was set based on some tags or set statically that could have drifted from reality. This is all guaranteed to be accurate with the nice color coding here to show us, which ones need our attention. From here, you can also see, of course, the history map that Theo had mentioned earlier. And so, this shows the relevant changes, make -- allows you to time travel, look at particular incidents over time. And so really good for understanding, again, in the context of a particular issue, as I'm looking at it. The other thing I wanted to highlight here is this is a dependency view for this application. And so, this is where you can visualize the upstream service app impact. So I can see which services depend on which -- on this one. But I can also see the more infrastructural [ look ] components here. So these are deployed within Kubernetes. I can see the deployments. I can see the cluster within that cluster. I can also see pods, workloads, namespaces and so on and so forth. And so being able to visualize and understand, where the applications sit at the application level, so I can see that the -- which applications depend on this application, and then all the way -- way down to the infrastructure level. So I can see where this application is actually sitting within Kubernetes cluster, which could be fit within our broader cloud portfolio or digital estate, so on and so forth. And so, being able to see and understand, do we have an issue with the application level? Is it at the infrastructure level? Having all that information surface to us is very important, as part of understanding how we're going to solve this problem. By looking at one of the alerts because we have a lot of the great links here that are included. One of those would be to jump directly into the cloud observability product itself, which I'll do now. And so this is a cloud observability dashboard. So this is a dashboard for the product catalog service that we were just looking at within ServiceNow. Here, we can see the dependency view again. So this shows the yellow here signifies latency. The red signifies errors. So it makes it very easy to, again, at a glance to understand, which ones are the slowest services that depend on, and which ones are the ones that are experiencing errors. And so again, if I'm trying to understand, is this an issue upstream, is this an issue downstream. Where am I? Can I need to be oriented within the broader context of the applications that sit within our purview. This is a very easy way to do that. All the charts and panels and visualizations that you see here are also derived from metric log and trace data. And so, in this case, we have, for example, some trace application data, which is charting latency -- or this -- sorry, this is the rates, the request rate for a particular application, over here is the latency. We have the deployment markers here showing when deployments occur. And so just like we'd already seen within ServiceNow, actually, there was a change that was recorded. So that's most likely the issue that we're seeing here, but potentially not. And so, this allows us again to see in one place, we have relevant CI data. We've got the change markers here. We can have lots of different visualizations. We can even use things like container memory metrics, as opposed to relying on trace data, on the log data, having it all in one place makes it very easy to see if there's patterns that split between -- between the log data, the metric data and so on and so forth. From here, we can do things like views of correlations. And so, the platform is sitting on a large amount of data. And so there's thousands of requests that are entering the system in every given second that and on top of that, there's the metrics, there's the log data that's flowing into the platform. And so, we can make the platform do work for us by saying what we're doing up here, which is show me the difference between over here, which is where we're seeing this kind of spike in memory. This is not look good, not a good sign, especially when it kind of goes down like this kind of sawtooth pattern. And then over here, where things were normal. So we have normal. We have something that we want to potentially have a deviation or an issue that we're trying to look at. And the platform, we'll look at all the elements of the trace data that came into the platform from any given period of time and surface the relevant information to us. And so, we can see that there was a gRPC version, library upgrade. We had a deployment upgrade. We had a service version upgrade. And so again, confirming things that we may have already known. And if I'm an operator, I can now take this back to the development team and say, we need to roll back this change, [ find and support ]. I now have more information to take to the development team to understand or to help them understand what the issue is, as well as its broader impact on the ecosystem here. And so again, making it very easy to take action on the large amounts of data flowing into the platform at any given time. For any chart as well, so I actually chose view correlations here. But if -- for a log chart, you can also do search logs for a particular point in time, and this will bring you to the log screens. This is a log explorer view. So if I wanted to look at the actual logs, I can do so here. And so, from here, I can see the log body. So we -- an error [ fetching ] product ID here. And then, all the great metadata associated where this log was originated is also attached here. And all the metadata you see here it's entirely arbitrary. It can be sliced and diced and filtered and [ group on ]. So if I want to only look at, for example, this particular cluster, I can do that, and you can see it's building the query for me up here. So it makes it very easy to understand within the broader context of all the log data flowing into the platform, finding that needle in the haystack, so to speak. So if I'm trying to look for a particular message, trying to understand its context. This is the way to do it. While looking [Technical Difficulty] also [ you see in ] context button, like we see here, to show the bringing it to that specific log line within the broader context of the entire log stream. And so, what that means is, that I can go -- then start from here. And then, if there's tens or hundreds of different services that are sending logs or emitting data into the platform, I can then work backwards and see, okay, I need to understand what happened here. I see resource exhausted, and I continue my investigation this way as well. And so, there's a lot -- I get a lot of great context that can be derived, makes it very easy to filter search and find that needle in a haystack, while we're investigating an incident. And then the last thing, I want to show here is the open link trace option. And so, since we have trace applications here, but the open link traces would allow us to integrate the log data with the actual trace data. And so, if we click on the open link trace view, I'll open this one here, and this is what we refer to as a trace waterfall view. And so, we've gone from all the logs that are entering the platform could be dozens or hundreds of different services and applications that are -- they are sending logs every second or every minute to an individual request transaction that is into the platform. And so, from here, we can see we had a front-end server that responded to an HP [indiscernible]. [ We had gRPC call ] within the front-end client, which talk to the recommendation service, which talk this and this and this and this and so on and so forth. And so, it makes it very easy to see both who's talking to who, and this is what is used for deriving those application maps, the service maps that we had seen before, so understand the topology of the requests. And then even looking at this, we can see the timing how much time was spent at any particular service or application. Each one of these lines referred to as the spans. We have the trace and then the trace is composed of multiple spans. And so, I can click down into the individual spans and see this is -- this one took 163 milliseconds. This is the blocking time here. And so, we can see that this is probably the slowest application within the list of applications here. And so, if I'm trying to understand why something is slow if maybe I'm a developer, and I'm trying to understand why was that request is slow? This is a very easy way to do that. I can see this and immediately understand, okay, this is why it was so slow. We spent a high -- this much time here at the recommendation service. I can see exactly what the different attributes, as well as, where this application service took place, I can see the language, I can see the library. I mean, a lot of great metadata associated with it here as well that I can then chart and filter and [ group on ] and alert on. So it's not just for the visualization here. And then this data, so we saw before there was an alert -- or I'm sorry, an error that was tied to this. And so, we can see that we referred -- respond with the 500 service code from this library. Again, all the great metadata associated here makes it very easy to tie all these components together, both from the dashboard level view. So looking at across thousands of requests that have entered the platform down to the loggable view. So understanding what a particular application is doing in a particular time, understanding why an application is logging the way it is and working backwards from that, using the same context? And then using the open link trace view, to actually look at the log from the trace view. So from that log that was only limited to that one service, to that one application at any one point in time. I can now see the entire request transaction. So I could -- and included here, we do see customers that embed more helpful metadata like customer IDs, so on and so forth. So I can even then go in a group [ by ] and filter and understand who was impacted by a particular outage. We understand why the service is performing so slowly based on the waterfall view here. What the error was? And then the great context surrounding that error, which I can then take back into ServiceNow, go through the playbooks and understand it goes through auto remediation or any kind of other workflow that I might need to, as part of the resolution for this particular incident. And that is where I will stop the screen share here.

Thanks, Ross. Much appreciated, and thank you, Theo for going over the scale and operate section as well. So with that, I'm going to open it up to Q&A. Just a reminder, you can provide us your feedback on today's session by filling out the survey on the right side of your screen or by clicking the icon that looks like a [ clipboard ]. After the Q&A session, you'll be able to download any of the resources we have as well. So with that, I will kick it off with. I think Theo, this one would be for you. What kind of dev pipeline tools do you integrate with?

I think all -- [ Kurt, you should ] hear me. Absolutely, all of them. Once we see most frequently our Azure ADO, Zipkins pipeline tools, Jaeger pipeline solutions. I have not encountered when we do not link with [ yes ].

Perfect. Okay. Next question. Actually, I think this might be for both of you, but Theo, [ I'll leave ] you answer first. What kind of logging do we support?

Logging from all types. We can -- most often, we -- I mean, I think there's 20 different types of logs that I can kind of list through. But most often, we answer that question by saying, we don't replace big, huge data lake functions in the market like Splunk or Snowflake or other ones. We provide that Tier 0 for those logs before they go in. I mean, Ross has a much more specific answer here. But as logs are -- if you're flowing a lot of logs into those big data lakes, we act as a Tier 0 before they enter there. We don't hold on to data for many perabyte -- petabytes. We generally hold on to the data for around 10 to 15 days, and we get to know your system based on those logs. So as logs are flowing through, we determine what is normal behavior. So every day at [ 2:00 ], you see a spike of activity, that's because people coming back from lunch are doing things. What we do differently as we're acting as that Tier 0 is to say, "Hey, every day at 2:00, we saw something, all of a sudden, we don't see something, that anomalous behavior that in this case, that sounded silence, those data lake solutions [ were ] necessarily fine. They'll tell you when the error is and programmatically, you can ask them to do a lot of things. But we use AI and ML to determine what's normal behavior through these log rates. Ross probably has more [indiscernible] logging.

Yes. So to -- and just to specifically referring to the cloud observability logging feature, we do have more flexible retention time periods for logging than previously provided. And so, we can do anything from 30 to 60, 90 days of log retention and log search and functionality. It is really focused on observability use cases though, or application performance use cases. So it's not to replace Splunk or SIM or any other kind of components that [ live out ] within the infrastructure today. And that the most common inputs we see are really kind of the elastic search format, OpenTelemetry, obviously, that's what we recommend those customers adopt. So we do support a variety of different ingest formats for the logs, but our specialty is on the application logs.

Great. And Theo, while we have you, is it possible to connect a log to a trace?

Well, that's a good Ross question.

Sorry, Ross.

Yes. Yes. No problem. Yes. The answer -- yes, the answer, and I showed this certainly in the demo, but the -- that what you can do is, you can expose the trace ID and the span IDs within the log message itself. And what that allows you to do is to make that connection. And so, it makes it very easy to jump from a log to a trace and then vice versa. So you can -- if you land on the trace view, and you're looking at a particular request and wanting to understand what happened, there's a little option on the [indiscernible] there to jump back to the log for that particular trace. And so, you can see, okay, this is what trace C look like, here are the logs and you can continue your investigation that way.

Perfect. And Theo, I think you should be able to answer this one. We had a question around if we could talk a little bit more about our generative AI solution, Now Assist, as it relates to cloud, around automatically generated content for responses, notes, knowledge base and so on and what is generally available?

Yes. So as of this November release of Now Assist, you can do a couple of things with Now Assist in terms of service operations. You can summarize a chat. So if you are in the employee center and you're requesting something for cloud, or you have something cloud-specific, generative AI will take a knowledge article and surmise it for you in kind of normal speak. So if it's something [ this is ] cloud or not. You can take a virtualized chat. And then, I was saying, you take your virtualized chat, have a conversation with the bot or go through a number of bloggers, excuse me, knowledge-based articles and so forth, whatever happened in that long chat when you transfer to a live agent, it will surmise all of that chat, so that you don't have to repeat it for the service operations, workspace person and the service desk. We will take case summarization. So if you've gone through 45 steps and, say, a P1 response and lots of people are filling up the logs with different things, now it says we'll surmise those -- all those things in easy and natural language steps up here, the things we've tried coming in the future. We didn't do the safe harbor notice that [indiscernible]. But in the future, we will take all that information and create knowledge articles for you in the ServiceNow database. There are a lot of operational features that are kind of in flight, like taking obscure errors that you get from logs or obscure error you get from event monitoring solutions and using our now large language model, taking all that information and creating say, hey, have you tried this or relating it to knowledge articles and then creating an easy step by step process is things you would need to try. Lots of information, lots of things happening around analysis.

Perfect. And last question before we end for today. Theo, can we automatically provision infrastructure -- automatically provisioned infrastructure be made immutable in any capacity?

Correct. Yes. You can auto spin up whatever infrastructure any which way immutable, unchangeable, any way that you want, any time that you want based on any number of criteria like you can with any other service request workflow from the -- within the platform.

Excellent. Well, thank you, Ross, and Theo for taking us down this journey on how we can scale, operate and really transform in the cloud. I want to thank everyone today for joining and spending the last hour with us. Feel free to sign up for the knowledge digital experience. There will definitely be a lot more on cloud and kind of talking through AI-powered service operations and observability and how we can really help you accelerate that along with a handful of other products that fall within the cloud transformation portfolio solution. Also, please remember the items available to you in the resource list below. And if you would like to take a few minutes to complete our survey, we would appreciate any feedback you have. The survey is in the window at the right of your screen. Thank you so much for joining, and hope you all have a great day.