Live on ServiceNow: ITOM Academy - Cloud Discovery Strategic & Implementation Guidelines

already I guess we can get started. So

good morning, good afternoon or good evening everyone and welcome to another amazing session of our ITM Academy.

Today we're going to talk about a very very hot topic and that is cloud discovery in terms of the strategic directions and uh implementation

guidelines that we have to offer to you.

Now we have had definitely different webinars in the past that were covering these topics but today you're going to see the latest and greatest for uh of

course the different methodologies and different outcomes that you can achieve.

Of course, now this webinar is absolutely part of the uh live on service now webinars and it's an interactive event series that is really

designed to help you adopt our solutions better and really achieve better outcomes by really listening to the subject matter experts for each of the

different topics we'll be talking about.

Specifically, you can see the schedule of all the live on service now webinars by scanning this QR code right here or we're going to share the link in the

chat soon. Now, I inverted the order of

chat soon. Now, I inverted the order of these slides today. Uh but essentially, we want to make sure that if we're going to not mention anything that is uh a

forward-looking statement, yes, that is possible today. So we really encourage

possible today. So we really encourage you to please keep in mind uh that there's a safe harbor notice for uh some of the topics we might be covering today.

Now a few housekeeping items for today.

Um you should be already muted but if uh this is not the case, please ensure your line is muted. We have a Q&A feature that is designed for you as usual uh to

ask questions throughout the sessions.

We really encourage you to participate in the polls. We're going to have two polls today. And uh for those of you

polls today. And uh for those of you that want to watch the recording or even want to access these slides of today's webinar, those will be available in the

Service Now community page, the very same one that you possibly were redirected to in order to register for this webinar. And um so yeah, we

this webinar. And um so yeah, we encourage you to uh look for the recording and the slides on the community page about a week uh or uh a

few days either way after this webinar ends.

Another really important thing, please please remember to fill out the survey.

You'll be prompted out to right after uh this session. That's really important

this session. That's really important for us. We want to really hear more from

for us. We want to really hear more from you. We want to have um all of your uh

you. We want to have um all of your uh inputs, feedback. That's really

inputs, feedback. That's really important for us to make sure we keep evolving this series in the best possible way. Now, for those of you that

possible way. Now, for those of you that don't know me yet, my name is John Mario Luigi. I'm part of the outbound product

Luigi. I'm part of the outbound product management team for ITM. And together

with me today, we have the legends of Bran Queen and Will Halam. You guys can introduce yourselves.

Hello everyone. Brian Quinn. I'm a

product excellence uh technical director um uh focusing on cloud. So yeah, I work with all of our cloud products. I've

been working with Service Now for for over 11 years and uh focusing on cloud for for most of that. So uh yeah, happy to share some of my cloud discovery

knowledge with you all today.

>> Hi everybody. I'm Will Halum. I'm a

solution consultant focusing on ITM.

I've been at Service Now for four years.

Uh before that I was a Service Now customer for about six years and and use the platform to make my life as kind of owner of an AWS footprint easier and and

really excited to help other people do the same.

>> Awesome. Thank you guys for being with us here today. Now, we have a lot to cover today. You can see we have a very

cover today. You can see we have a very busy agenda. We want to make sure that

busy agenda. We want to make sure that we touch on all these important topics.

Maybe for some of them we won't have necessarily all the time to go really deep into the uh smallest details. But

really the main objective of today's session is to help you eventually get to choosing the right cloud discovery methods that you see here at the bottom.

Keep in mind that we'll have again the Q&A box for you. So, just keep those questions coming in and we're going to be more than happy to support you with uh any questions you may have. And of

course, we're going to have a Q&A at the end of this session.

But first, let's start from why you should get visibility into your uh cloud environments. Now uh

we talked about how service now in many previous webinars in different events etc. you may be familiar with these concepts but really the data that you

have in service now is really the engine that is powering AI and workflows to help you succeed in your business and

technological challenges. Effectively

technological challenges. Effectively having a uh business context uh on your CMDB is really important because it enables all of the different use cases

that we see here. And we're going to get a little bit more specific. I don't want to go through all of these use cases. Uh

but we're going to get a little bit more specific when it comes to cloud discovery. Just keep in mind that first

discovery. Just keep in mind that first of all having a well populated CMDB with business context is the best start you

can have to be successful in this world of AI and uh automated workflows.

We also want to make sure that the population of your data is smooth and it's automated. That's why we always

it's automated. That's why we always recommend you to start with the native service now approach to populate your CMDB that you can see here on the left

of the screen and then potentially using the service graph connectors to enrich your CNDB rather than natively populating it. We're going to cover this

populating it. We're going to cover this and more in the coming slides. But

before that, I want to make sure that we have a little of an a little bit of a nice breaker here. So I'm going to uh get started with the first poll today.

I'm curious to know what is your current level of visibility on your cloud environments as of today. Before we even get to the theory, right? And for those

of you that want to see all of the different options, you can just scroll in your uh window that will be popping up for you. You can scroll down to see

all the different options. And I see plenty of uh participation on the polls already. So I love the excitement here.

already. So I love the excitement here.

Um yeah, I see that definitely the um majority of you is um has discovered most of the uh cloud resources. We still

have margins for improvement um for those that are discovering specific cloud resources when needed.

And um that some of you have very poor cloud uh resources visibility. Um so

it's uh I I also see plenty of answers here for folks that are also a little bit more advanced in their journey. So

we have a really well m well uh well mixed audience I would say for today's uh webinar. So I'm going to end the poll

uh webinar. So I'm going to end the poll here. Thanks all for the participation.

here. Thanks all for the participation.

Um, we're going to get to the most important concept of today's webinar.

Essentially, I've been having multiple conversations with uh many of you and with different customers out there. And

the conversation always comes down to, okay, what cloud discovery method I need to choose uh among the different ones that are available? Well, the most important point is always what do you

want to do with the data that you're currently discovering? So what are the

currently discovering? So what are the business outcomes that you're looking to achieve when it comes to cloud visibility? And there are different

visibility? And there are different options really that you can cover starting from regulatory and compliance.

Well, you may be uh having specific needs um maybe even industry specific mandates from a regulatory perspective that are mandating you to discover and

have a complete inventory of your cloud resources or having ownership establishing how they are impacting your services or even understanding which

sensitive data you have in there. Um you

could have needs from a software asset management perspective uh because you want to manage uh the software in your cloud environments in a more effective

way or you may be thinking of your Phops use cases. You want to optimize cloud

use cases. You want to optimize cloud spend across providers, organizations or even cost centers.

How about secops? Especially nowadays

secops is definitely one of the most important business outcomes you want to achieve there. um because you want to

achieve there. um because you want to make sure your cloud resources are secure and compliant with your internal security policies. Certificate

security policies. Certificate management is another very important and related to the previous one. Uh we know that many of you have experienced certificate related outages and you want

to make sure that you avoid that. So

certificate management is definitely another outcome that you might be willing to achieve and AI ops in general. You want to keep your business

general. You want to keep your business running by preventing outages. Now,

these are of course some of the I would say most important business outcomes.

There's more out there and if you have more, please put them in the Q&A box.

Um, we'll definitely make sure to answer your your uh questions by the way throughout this presentation. So, uh

thanks to our amazing panelists that uh are already helping to do that today.

I want to make sure we get into the second uh poll for today because we also want to better understand um what use

cases among the ones that we just cited in there are you most interested in. So

um are you interested more in the regulatory and compliance use cases software asset management phops secops certificate management aops you let us

know that's very important for us and in the meantime that you guys insert your uh answers in there it's very important to understand why are we

talking about these specific use cases in a context of cloud discovery. Now

today we're going to cover uh the different categories of uh methodologies that you see here starting from the differentiation between cloud topology

discovery and OS level discovery. But

for each one of these methods um you're going to definitely have different use cases that you want to address. I'm not

going to cover necessarily all of the use cases that are enabled by each one of these methodologies, but just keep in mind this is the first thing that you need to do today understanding from the

previous slide and based also of course on your answers uh that are coming through the chat which use cases you want to address and then you're going to

go for a specific route or maybe a mix of different uh discovery methodologies based on what kind of level of discovery you're doing. I see plenty of answers in

you're doing. I see plenty of answers in there. So, uh, thanks Saul for answering

there. So, uh, thanks Saul for answering uh the polls in there. It's really

important for us to to get more information from your side.

Now, I'm going to end the poll. So,

thanks all for that again. And we're

going to get into a little bit more of a detail when it comes to cloud discovery methods. Starting from the

methods. Starting from the differentiation between cloud metadata discovery and OS level discovery. Here

you can see that uh even from a sort of dependency view, right? When we talk about cloud metadata discovery, we're discovering everything from the availability zone all the way to the

data centers uh cloud management network all the way up to the virtual machine layer. And then if you want to do a

layer. And then if you want to do a deeper discovery, the OS level discovery discovers everything above that. So your

servers, your uh uh web sphere, you can have your uh databases uh your Apache web server etc. all the way up to your

business services. That is why we have a

business services. That is why we have a differentiation uh between the two.

Trying to understand a little bit more about what you discover and what considerations you need to make for both of those levels of discovery is really

important. So whenever you're starting

important. So whenever you're starting to discover your cloud metadata, we help you discover across these different clouds that you see right here and to

help populate your CNB. Now you can discover across here infrastructure as service, platform as service, uh function as service or even container as

service. We have ample uh support for

service. We have ample uh support for all these. And the key questions you

all these. And the key questions you need to ask yourself are essentially about security considerations um u in order to select the best method

uh because you may need the of course uh service account um and uh the cloud provider specific am but especially what do you want to discover. So with cloud

metadata discovery, you're essentially uh ingesting the cloud metadata to get that topology view that we saw before.

Um you're ingesting tags in terms of keys and values that can help you start to get a business aware CNB with tag based service maps. Um we can discover

Kubernetes and containerized resources and also configuration changes. So how

your cloud resources are changing over time if you're um basically leveraging event-driven discovery. Now, keep in

event-driven discovery. Now, keep in mind if you're going to decide to go for cloud metadata discovery with servicecraft connectors, uh there are some restrictions that apply uh that you

can see at the bottom of this slide because you will essentially also be affecting the ability of um essentially uh being then uh more or less effective

with the OS level discovery.

And that's exactly the next step. Next

step is how do you go about uh discovering what's beyond the virtualized layer the virtual machines.

We'll we'll definitely go ahead with the servers server OS discovery. In this

case the security considerations vary even more based on the OS level discovery method you'll be choosing and what you discover as well. You can

go to discover your software installation and metering, Oracle class discovery, your certificates, you can do file-based discovery and you can go

ahead uh with uh service mapping both from a top-down perspective and uh machine learning based uh perspective.

So you have really many options and more that you can achieve with OS level discovery.

I would say now that we have seen an introduction to the different methodologies, let's see a little bit more of each one of them. So, I'm going to hand it over to Brian and Brian if

you're ready.

I'm going to stop sharing and you can get started on your end.

All right. So, hello everyone. So, yeah,

so we'll get started. Um, John had just talked about the kind of the two different things. There's the OS level

different things. There's the OS level discovery and the cloud metadata discovery. Uh so we'll get started here

discovery. Uh so we'll get started here talking about cloud discovery which will discover the the metadata side of things.

Uh so here we have the kind of the overall architecture of cloud discovery.

Basically you have your your standard uh cloud discovery schedule and that's going to kick off uh patterns. Uh each

of those patterns will be processed by the midserver and that's what's going to make the actual API requests into each of the cloud providers. Um, now I know I even through the Q&A I saw some

questions coming up about midservers. So

the nice thing about cloud discovery is you really only require a single midserver or maybe a couple for load balancing purposes and failover purposes that is able to reach the public

internet, right? Because we're just

internet, right? Because we're just making REST API calls out to the public cloud provider. Um it's not like

cloud provider. Um it's not like horizontal discovery on prem where you may need multiple mid servers in each of your your sub uh subnets. Uh so really

all we need is a couple of mids with public internet access. Um and they can be really uh for Azure and for GCP they can really be located anywhere. Uh for

AWS uh we'll talk about credentialists here in a minute. uh we do recommend having it in AWS, but it is also possible to have it uh outside of AWS.

Um so yeah, so once the midserver makes those API requests, we'll get that data back from the cloud provider and uh populate the CMDB. Uh now the data we're getting back is very similar to what you

would see if you go into um the the cloud provider console and what you're looking at there, right? It's just the metadata uh of those virtual virtual objects.

Um now one advantage of cloud discovery is we can discover entire uh cloud providers all at once. So with AWS you may have an entire AWS organization uh

set up with uh a single billing account or a management account and then a ton of member accounts under it. We only

need one discovery schedule to discover that entire organization. Uh similarly

with Azure you have management groups uh where you can discover the entire Azure tenant. Um the so the root management

tenant. Um the so the root management group is just the tenant. Uh or if you wanted you have if you have multiple management groups broken up beneath that you could do individual schedules for

each of those management groups. Um but

typically unless you have a a um tremendous number of Azure subscriptions, uh discovering at the tenant group is the easiest way uh to

discover that entire uh all of these subscriptions uh all with one schedule.

And then similarly with GCP, you have the ability to discover uh all of the uh GCP projects that a an account uh has permissions for or you can do it by

folder. So GCP provides folders to help

folder. So GCP provides folders to help organize uh GCP projects. Uh so you can do discovery a single discovery schedule for a folder or for the entire

organization. Uh if that service account

organization. Uh if that service account was granted permissions across the whole um organization.

Uh so just taking a quick uh look at what an Azure management group setup might look like. Uh so you have the tenant root group here. you have a service principle um that would then uh propagate permissions to all the

subscriptions beneath it. So then you have your choice of having a discovery schedule for this tenant root group and discovering everything or if you wanted to break it up and discover individual management groups with multiple

schedules uh that's possible as well. Uh

but like I said, unless you're talking about a tremendous number of uh subscriptions, I would lean towards doing the tenant uh root group so you

get everything in one shot.

Uh for GCP, it'd be very similar. You

have an organization level. So if you have the service account permissions applied at that level, that propagates down to all of the GCP projects below there. Um and it would enable

there. Um and it would enable discovering everything in one shot. Um,

but if you do have folders that you want to discover, we offer that flexibility as well. Uh, being able to set up a

as well. Uh, being able to set up a discovery schedule per GCP folder.

Now, for AWS, we'll talk a little bit here about uh credential versus credentialist discovery.

Uh, so the most basic way to authenticate into AWS is the AM user, but that is a you uh an access key and a secret key. That's a a fixed credential.

secret key. That's a a fixed credential.

So that's essentially the same as having a fixed username and password.

Obviously, it can be rotated. Uh but a lot of cloud security teams uh won't allow it at all or discourage the use of IM users and the fixed credentials. Uh

even AWS uh when you go to create a um uh credential for the IM user, uh it does recommend other methods. Uh so AWS does

provide the ability to grant permissions directly to an EC2 VM. So if you have a midserver running on that EC2 instance uh that midserver can leverage those

permissions uh without needing any kind of credentials. So in this case this is

of credentials. So in this case this is where we we do recommend having a the midserver that's doing AWS cloud discovery within AWS so that you can

leverage this credentialist option. Um

whereas the others don't have that credentialist option so that they can those midservice can be placed uh anywhere.

Um so for AWS organization discovery so you're going to have lots of accounts within your AWS organization but those AM users or EC2 instances if you're doing credentialists only exist in one

account. Uh so obviously creating one in

account. Uh so obviously creating one in each account really isn't uh a scalable solution. Uh so to solve for that AWS

solution. Uh so to solve for that AWS provides um assume role which allows us to generate uh temporary credentials uh from the MIDI server or from using that

IM user uh to access all the other accounts within the organization.

Uh now this can this setup can be um uh have a little bit to it. Uh so this is kind of our recommended uh configuration. Uh so basically what you

configuration. Uh so basically what you have is an accessor account. So this can be any AWS account within your AWS organization. uh with uh an EC2 instance

organization. uh with uh an EC2 instance and the midserver installed on that EC2 instance to allow the credentialist uh authentication. Uh from there we uh

authentication. Uh from there we uh would configure a role in the master or management account. Um and then the

management account. Um and then the midserver is allowed to do an assume role into that management account. Uh

and that that role uh from there to discover all the other member accounts we do a second level of assume ro. So

now from the management account we're doing an assume role into all of the other member accounts. Um and then within those member accounts they you would create a role that uh grants

discovery the permissions um to to do discovery. Um now there are a lot of

discovery. Um now there are a lot of details for setting this up creating the roles the trust permissions um making sure um the right policies are attached.

Uh so I do have a three-part uh video series uh that covers all this setup in detail. Uh so if there are any questions

detail. Uh so if there are any questions on uh exactly what needs to be set up both on the cloud provider side um or on the instance side uh this video series

kind of walks through that setting up the accessor account uh setting up the management account and then all the other member accounts as well. Uh so

hopefully this will help um answer any questions about that setup. uh if you run into any uh problems setting that up.

All right. Uh moving on to some other uh best practice items. So talking about some properties, some migration, and some store apps that you'll want to take a look at when setting up cloud

discovery. Uh first we have the CPG or

discovery. Uh first we have the CPG or patterns to uh CPG or Cappy to patterns migration. Uh this on Zurich is now uh

migration. Uh this on Zurich is now uh out of box. But if you have an older instance um you may have to go through this migration process. Uh basically

this is uh turning off our old copy based cloud discovery and enabling the patterns. Uh moving forward all the

patterns. Uh moving forward all the development is on patterns. Uh we have a whole slew of new um patterns that are generated by Gen AI. Uh so these new

patterns should be coming out on a more frequent basis. So definitely make sure

frequent basis. So definitely make sure that this migration is completed. Uh if

you have an older instance where you haven't set up cloud discovery before, we also have a hardware type uh model migration. Uh so this is uh particularly

migration. Uh so this is uh particularly important for uh anyone who has a lot of uh cloud accounts uh across any of the

providers really. um the the old um CMDB

providers really. um the the old um CMDB model for hardware types uh resulted in a large number of CIS uh that looked

very identical. Uh so this new model

very identical. Uh so this new model will create only one CI um per uh one CI instead of one CI per region per

account. Uh so this these CIS track uh

account. Uh so this these CIS track uh basically the different models of the different sizes within a cloud provider.

Um, so yeah, so going doing this migration before you even set up cloud discovery will help make sure your CMDB doesn't grow too fast. Um, like I said, this is really critical if you have

hundreds or thousands of accounts that you're discovering. Uh, it'll really

you're discovering. Uh, it'll really keep that CI count down.

Uh, another property to to look at is this um auto refresh sub accounts. So we

previously we were talking about discovering an entire uh organization with one discovery schedule. Uh so you still have the uh problem of after you

set up your discovery schedule what happens when a new account is created.

uh by enabling this property and making sure this property is turned on. Uh

every time cloud discovery is run, uh we'll also go out and do a uh a check to see what accounts new accounts may have been created and we'll automatically add that to the discovery schedule. Uh so

that way when as new accounts are created uh there's no work that's needed uh on the service now side uh everything's automatically added to that schedule and your CMDB will

automatically be populated uh with that new account.

Uh and finally we have the cloud discovery workspace. Uh so this is a a

discovery workspace. Uh so this is a a store app that you should make sure that is uh installed. um just an easy place to go manage uh your discovery your

cloud discovery schedules. It lets you look at the uh cloud resources that are discovered uh kind of looking at them by provider by region. Um it also has um an

area to look at your Kubernetes uh discovery as well. Um now as we move towards the future um there will also be work um there's planned work to enhance

the discovery admin workspace to bring um the management of cloud discovery schedules there as well. Um so that's something to also consider adding uh now

to help you manage your your on-remise discovery schedules and looking at um some of the errors and um recommendations for on-prem discovery.

Um but then in the future that discovery admin workspace will also uh work with the cloud discovery schedules as well.

All right. So that covers kind of the metadata um side of cloud discovery. Uh

Jean also talked about uh the discovering the OS right and the importance of discovering uh all the data populating the CMDB the hardware

side of the CMDB with the um uh using either horizontal discovery agent-based uh or service graph connector. Uh so

many of you are probably already familiar with horizontal discovery where uh we need credentials to um a VM or a server. All right, we also

need network connectivity between the midserver. Uh so we need those firewalls

midserver. Uh so we need those firewalls open or the multiple midservers within in the subnet. So that's always been a problem with the in the cloud environment uh because of uh network

isolation uh in the cloud or uh tight control of credentials. Um being able to do horizontal discovery on cloud VMs has uh been a struggle with a lot of

customers. Um so with the zer patch one

customers. Um so with the zer patch one so when that that becomes GA there's um a new functionality is uh AWS discovery

with the SSM agent. Uh so what this allows for is running the same horizontal discovery patterns uh without credentials and without the need for

that network connectivity. Um, so

instead of the midserver going out to the VM using credentials to run commands, now we can leverage uh AWS SSM to run those commands instead. So when

the pattern executes, we have a bunch of commands that we need to execute. Uh so

for each of those commands, uh the midserver will now use the a rest API calls to the AWS SSM and that will request certain commands to be run on

the instance.

uh on the EC2 instance. The EC2 instance will then uh put that data into an S3 bucket and then the midserver can retrieve that data from the S3 bucket.

Um now for uh application patterns, we also have the ability to store applicative credentials into AWS KMS and um SSM would be able to retrieve those

applicative credentials and use those in the pattern execution as well. Uh so now this gives us the ability to run all of those OS specific patterns uh without those credentials without that network

connectivity. Um so that allows us to

connectivity. Um so that allows us to support the the more complex software asset management use cases. Um now this is very similar to what AWS service

graph connector is does. Uh AWS service graph connector can use the same SSM agent uh to get very similar data. Um

but this with cloud discovery it allows us to do it credentialist service connector does require a credential um and it allows that full pattern

execution versus just a limited amount of data being brought back by SSM.

Uh so just uh some some facts about the the SSM agents uh for setting this up.

Uh once you're on Zurich patch one, you'll have to install some some apps, making sure those are up to date, enable some properties. Uh there is a a bit of

some properties. Uh there is a a bit of setup on the AWS side. So you have to make sure the SSM agent is installed, IM roles are configured properly for all

your VMs. uh having an S3 bucket set up and making sure cloud discovery has uh the additional permissions to to talk to SSM and S3.

Um so like I talked a little bit about compared to uh service graph connector it's using that very similar SSM configuration but now you're getting full pattern execution. You're getting

more comprehensive CIS because we're doing the full pattern uh support for that credentialist. Uh but it does

that credentialist. Uh but it does require a midserver. But again, this is like the cloud discovery midserver where it can um it doesn't have to be like one

per subnet like uh onrem discovery. Uh

it's really just one midserver that needs to be able to talk to public rest API endpoints. Uh compared to the the

API endpoints. Uh compared to the the IPbased discovery, obviously the biggest benefits here are the no network, no credentials and no network connectivity.

uh the pattern execution with SSM agents is going to be slower since we do have to interact with SSM and S3 uh and it does require that agent to be installed um and there is some some limitations

right we don't have full support for everything horizontal discovery uh has um with the SSM agent at this time um so

if you needed all of the data horizontal is still kind of IP based horizontal is still the gold standard um but the AWS SSM does get you a lot uh if you can't

get those credentials and network connectivity. Uh and finally compared to

connectivity. Uh and finally compared to to ACC um ACC also requires that MIDI server to get the full functionality out

of that the ACC agent. Um

and this but this agent uh a lot of times is already deployed uh in your AMIs that you're using to spin up your AWS VMs. Uh so this agent may already be

deployed in your environment. Um so

there might be less work to get that deployed across uh all of your VMs. Um so yeah, I think that covers it for what I want. Oh, and here just a couple

screenshots. So on the instance, uh

screenshots. So on the instance, uh really once you have everything set up in AWS and you've got the properties set, uh really when you set up the discovery schedule, it's just a matter

of flipping on the use AWS SSM agent. Uh

this will automatically create a discovery schedule where the the agent is set to AWS SSM. Um and then when the pattern runs, you'll be able to see all of the same commands are being executed.

Uh you'll see the the AWS command ID that's associated with that. Uh so you can tell that your patterns are running using the AWS SSM. Uh and then the data you get back will will be very similar

to what horizontal discovery uh brings back since we're running the exact same patterns.

All right, that covers it for what I want to talk about with the cloud um metadata and um SSM based OS discovery.

I pass it over to Will now for for agent-based discovery.

>> Awesome. Thanks, Brian.

So a as as Brian mentioned, we've got this capability to leverage the existing AWS systems manager agent which AWS kind

of makes available to its customers. And

so if if you already have that, that's going to be a great way to get that deep discovery data without having to stand up uh mid servers with access to all of

your uh your VPCs and subnets within your um within your AWS cloud.

Um we have a similar approach using our agent client collector which can be leveraged across um across any of the cloud providers.

And again, it lets you complement that cloud meta data with actual uh OS level data.

And so just some kind of key points around this approach. So in terms of kind of setup rigor, it sits somewhere between using if you have an existing

SSM investment on AWS, it sits somewhere between that and going the full route of setting up horizontal discovery. And

that's because you don't have to do go through the same um the same kind of jump through the same hoops with regard to setting up network connectivity

across all of your cloud subnets. Um,

and the way it works is the OS and host level discovery is driven via the ACC, the standard ACC plugin. When you

install agent client collector and have the agent client collector visibility content on your instance, it's automatically going to be pulling the

same type of OS detail that you get when you run a horizontal discovery against one of those servers.

And then what we've added to that is the ability to discover applications that are running on that virtual server using

the same patterns that we've been using for years in horizontal discovery.

And as far as a best practice is concerned, uh we definitely recommend having that allow list functionality

enabled. So that's one of the that's

enabled. So that's one of the that's probably kind of the biggest um task involved in enabling this is out of the

box the allow list that tells the agent what commands it's allowed to run are configured for just that base visibility. And then if you layer on any

visibility. And then if you layer on any of the monitoring capabilities, the monitoring checks are added to the allow list as well. But it's it is left as an

exercise for the customer. And there's a there are community articles around the specific actually it's a support knowledgebased article with specific

information on what needs to be added to that allow list in order to perform u execution of application discovery

patterns. And so in kind of a PC or an

patterns. And so in kind of a PC or an experimental mode, there's this uh there's this uh temptation to completely

disable the allow list that uh gen basically lets the agent client collector run whatever command the instance asks it to. And so that's

definitely not best practice from a uh you know compliance and security perspective. So we do heartily recommend

perspective. So we do heartily recommend that you leverage the allow list and just use whatever kind of uh configuration management framework that

was used probably to deploy a agent client collector in the first place to then just update that allow list to contain the appropriate commands that

are required to execute the application patterns. I actually did this in my own

patterns. I actually did this in my own little test environment using Anible and it was it was relatively straightforward. The juice is definitely

straightforward. The juice is definitely worth the squeeze there. And then I'll just uh I'll just sit on this page.

You'll you'll get all these links after the fact as well, but if somebody's chomping at the bit to see some ACC uh pattern support information, these QR

codes are going to take you to uh last month's specific webinar on the topic.

In addition, uh it'll take you to the standard doc page as well as the knowledgebased article on the uh uh which includes the example allow list

content that's required.

I'll give that another 10 seconds for anybody who wants to screenshot it and start reading immediately after the webinar.

And now I'll just do a quick demo of what this looks like in practice. And

you know, full full transparency, it's it's not flashy. It's really just discovery but um without having to set

up credentials and midserver connectivity and and all the uh additional trappings that come with

so this is an example of a an endpoint a Windows server that's running agent client collector and it can be discovered on demand using the

collect host data button which without pattern support is just pulling that base OS level data similar to what a server discovery is going to pull using

horizontal discovery.

And then once pattern uh execution is enabled, we add a couple things to this

experience. The first is a a view

experience. The first is a a view called discovery. And so when you change

called discovery. And so when you change to the discovery view on your agent, you then have this new tab called application pattern logs. And that shows you which application patterns were

executed on that agent. And then if we click into one of those, you'll get, if you're if you've ever looked at a pattern log, this should be very

familiar. You'll get the pattern log for

familiar. You'll get the pattern log for that uh discovery that occurred. And

then you can just kind of see here that every time it's running a command, it'll tell you that it's using the ACC collection. And that's that's really all

collection. And that's that's really all there is to it. It just swaps the SSH or the Windows remote connectivity for leveraging that existing

agent client collector.

Okay. Uh so my next topic is event driven discovery. And what event driven

driven discovery. And what event driven discovery is is a complimentary feature which fills those gaps between when your scheduled service graph connector

imports or your cloud discoveries are running. And so we have that for the the

running. And so we have that for the the big three providers AWS, Azure, and GCP.

And a little overview of how it works.

um it's either going to push or pull events from those cloud providers that are tracked when a new resource is created or destroyed and those will hit

either a specific API endpoint on the platform or it'll be a pull using scheduled jobs that are present on the platform and kind of that initial payload data from the provider comes

into a staging table and then there's jobs that scrape through the staging table and actually submit the payload to the identification and reconciliation

engine to be incorporated into the CMDB based on your existing uh class manager rules that you've got around those CI classes.

And so a quick overview of the just the differences between the three uh the three types Azure we've uh we've gone to a pull-based approach called Azure

change processing. there was an older

change processing. there was an older alertdriven kind of a push approach that had some issues around scale and um

authentication. So, we're recommending

authentication. So, we're recommending that people go to the Azure change um that that new Azure change processing uh

approach as opposed to the older one.

They're both still documented, but that right at the top of the older section, it says, "Hey, you should be using Azure change processing now." uh because of the way the ACL's are set up, it does

require that service count records are created by either a discovery admin role or the CMP cloud admin role. So that's

just something to be aware of. If you've

got kind of brownfield um service account records that aren't picking up events, that's something to check. Uh on the Azure side, it

check. Uh on the Azure side, it populates CMDB using the response payload. In other words, it's not

payload. In other words, it's not triggering a pattern execution when one of those events occurs.

And it's so like I that kind of ties into my last point on Azure which is it's meant to work with Azure discovery.

It kind of creates or updates the record specific attributes within the record and then the expectation is your next discovery schedule will provide the more

comprehensive meta data update.

And now actually uh before I kind of walk through the rest of these bullets, I'm just going to do a quick aside over here. and go into AWS and Azure and shut

here. and go into AWS and Azure and shut down a couple VMs and uh pray to the demo gods that by the time I'm done with

the slides, I can go back to my CMDB and show that they have been updated within a couple minutes as opposed to having to wait for the um

wait for the next planned schedule. So,

I'll start start the shutdown there and then I'll look at my uh just take a quick quick look at my virtual machine

instances to show their current state in the CMDB.

And so I've just operated on these top two VMs, one in Azure and one in AWS.

And you'll see they both show a state of on. And so now returning to our regular

on. And so now returning to our regular program, uh AWS AWS uses a pushbased approach which combines AWS config notifications

with simple notification services.

It does not require AWS discovery.

There's no dependence on patterns. It's

actually configurable. So it can either just populate the CMDB based solely on the payload that comes from that config notification or it can trigger a focused

pattern execution. And that's

pattern execution. And that's configurable via these properties down here. This first property saying use

here. This first property saying use response mapping. If that's true, then

response mapping. If that's true, then it doesn't trigger a pattern. If it's

false, then it will trigger a pattern execution. And then you can control the

execution. And then you can control the parallelism with the parallel count property.

Uh on the GCP side, uh the GCP event processing is pullbased via this scheduled job, GCP events job.

Uh it does require GCP discovery though because you've got to discover your GCP data centers uses the stack driver and the cloud logging APIs and the kind of

the activator for it to actually do something is a checkbox on the cloud service account record uh which is labeled should pull events a and then

just for anybody who's using domain seep all of this is supported uh under domain separation. So if you discover a domain

separation. So if you discover a domain separated cloud account, it'll put all those CIS under that applicable domain.

But when an error occurs, you can point if you if you don't want it to go to the global, you can point uh kind of those

errors to a default domain other than what you know out of the box instance is going to want to do.

Uh again, another screenshot moment. If

you're super anxious to start reading up on these topics, uh these are uh QR codes and and when you get the actual slides, there's full-on links uh down at

the bottom to take you to the pertinent documentation for these three approaches.

I'll linger on that for another five seconds.

>> Yeah, Will. I'm going to post the link again for uh everyone's benefit via chat. So,

chat. So, >> thank you.

>> Uh I want to make sure that basically everyone is aware the recording and the materials of course the presentation that we're sharing today will be shared

at this link.

So the community >> Thank you, John.

>> Thanks.

And so now I've just done a refresh of my VM list and you can see at the top it recorded the change in state uh within you know the time it took me to go over the slides. So that's obviously a a much

the slides. So that's obviously a a much smaller gap than you would experience if you only got updates on your cloud metadata every time your discovery

schedule were executing.

Moving on to some comments about service graph connectors. So

graph connectors. So um over time the gap that the gaps that service graph connectors kind of

addressed initially uh versus patternbased discovery have been closing. And so based on that, coupled

closing. And so based on that, coupled with the fact that with the emergence of Gen AI, we're now able to generate new discovery patterns much more quickly

than we used to be able to. Uh it used to be to add a new pattern to onboard a new cloud service a person would have to

develop that code. Now internally we've been able to spin up requisite AI powered tools such that we can generate those patterns on a much more rapid

fashion with minimal uh kind of with a minimal touch from a from a human. It's

really more of a downstream QA function as opposed to having to create brand new code at this point.

And so because of that, um, we're recommending that you just very carefully qualify that decision to pursue a service graph connector

strategy. Uh, the big one that comes up

strategy. Uh, the big one that comes up in my discussions with customers is that they get, you know, kind of a a veto on a midserver and and it's still certainly

that's still a very valid reason to look towards service graph connectors. The

one thing that I would say there is just really perhaps doubleclick into that no mid requirement and make sure that it's actually no mid full stop as opposed to

well we don't want to spin up a mid in Azure AWS GCP etc because that is not required. There are ways with all

three of those cloud providers to discover using cloud discovery with an on-prem mid or you could discover AWS with a mid that resides in Azure and

that relationship kind of goes uh it's fully uh reciprocal. Um,

so just kind of make extra sure that it's not um it that it's not a no mid anywhere requirement. And if it's a, you

anywhere requirement. And if it's a, you know, we don't want to spin up additional mids or we don't want to put a MIDI in this cloud provider, there are ways to still use cloud discovery and

get advantage the advantages of the rich kind of cornucopia of patterns that we have available to discover those cloud resources. Now, um, with the SSM support

resources. Now, um, with the SSM support being added to AWS Discovery, it's it's kind of like the one that SG AWS has had, but on steroids. It's going to be even more powerful because it can run

patterns, not just specific uh, handful of commands. Um so yeah just um

of commands. Um so yeah just um definitely be very deliberate as you're walking down your selection and make sure that service graph connector is

absolutely the best way to go and that there are you know very tangible blockers towards um going with just traditional cloud discovery which is

kind of the most provides the the richest set of data.

Okay, that's it for my prepared content. Uh,

John, I think you're going to go over uh how how how to how to choose.

>> Awesome. Awesome. Thank you so much, Will and Brian. That was a >> great session. I would say, are there any questions that are outstanding you would like to bring up uh live maybe or

some that have been already answered?

And uh we want to highlight before we go through the last uh part of today's presentation.

If not I will just select okay.

Can you see my screen?

>> Yes.

>> Awesome.

Yeah, that was a lot of content indeed, but especially we saw a lot of questions coming our way. So, thank you all for being so engaging and really interested

in these topics. We're super delighted to see all the excitement around it. And

these decisions are definitely important to make sure you're achieving uh the most out of your uh service now uh item

deployments for sure. Now you are all going to be potentially a little bit uh somewhat overwhelmed, somewhat excited about everything that we've

seen. So yes, I'm not going to go

seen. So yes, I'm not going to go through each single of the combinations you'll be seeing in the next three slides. Just want to give you all the

slides. Just want to give you all the opportunity to at least have a look at the way we want to provide some guidance when it comes to

essentially uh selecting what is the right approach for you for the use cases that you want to cover. And in these matrixes that we provided for all three

major cloud vendors, you'll have what are the requirements in terms of mitserver credentials um you know various permissions or what are the use

cases that are being supported. In this

case you will see that for the various methods will provide you with a comprehensive guidance for uh again AWS,

Azure and GCP. Now keep in mind that as we highlighted already throughout the presentations uh the service graph connectors are uh

potentially some of the um methods you'll be thinking of you if you want to have quick wins. However, you always need to think longer term. What are the

broader outcomes you want to drive for your organization? what level of depth

your organization? what level of depth you want to get into the information you're populating into your CMDB and ultimately

why are you trying to bring that data in what other functions of your organization you want to enable. So

these are all great questions to ask before choosing the right method. And

also keep in mind that as we have seen uh there has been an evolution not only in terms of the content that has been developed we've introduced uh just in

the latest release the um SSM agent integration for AWS but also we'll be directionally moving ahead with even a brother shift when it comes to allowing

you to have a single place uh from where you can manage your cloud discovery posture and that is likely going to be inside the discovery admin workspace.

Now, uh we'll cover more of that as soon as the uh actual features will be delivered. So, please stay tuned and

delivered. So, please stay tuned and make sure that you check out our item events pages. Um that is uh of course

events pages. Um that is uh of course hosted in the community. So, uh um just want to make sure that everybody's aware. Every quarter we'll be hosting

aware. Every quarter we'll be hosting the what's new sessions for ITM and specifically that's where you'll hear about the latest and greatest innovations. Those are part of the live

innovations. Those are part of the live service now events as well. So please

make sure that you leverage the link that I'm just pasting right now in the chat.

Now I know that uh we're almost at time but I just want to make sure to cover um the questions. So, where can we get the

the questions. So, where can we get the matrix for Azure? And the matrix for Azure is here. And for anyone that wants to access all these slides, make sure

that you get to the webinar chat and you check the community page link. After a

few days, we'll be posting the recording for this session and the slides as an attachment in that very same community

page. So that's another advantage of um

page. So that's another advantage of um u keeping that under um you know uh under control as in to make sure you

constantly check that out.

So, um I don't know maybe uh some final considerations for you will and Brian.

Anything that we haven't talked about yet?

Anything last minute you would like to cover?

>> Oh boy. I mean, this is just, you know, as as people have probably picked up on, this is just a it's a rich landscape.

Lots of options, lots of decisions.

Hopefully some of the kind of best practice bullets that we brought out will be helpful, but um you know it's it's certainly an elephant that you have

to eat one bite at a time and leverage your accounting because you know we can engage directly with accounts to talk about this same kind of

content and also we run you know in-person workshops around a lot of this same content for example. So there's a lot of other resources that you can use.

Don't feel like just because your specific question or line of inquiry didn't come to resolution on this webinar that that's the end of it till the next one. There's loads of resources

in service now is you know we want we want to help help everybody get to their desired end state.

>> Yeah absolutely will and I would also say you can start small perhaps from you know a single account and you can try to achieve different use cases with one

single account. So you just start small,

single account. So you just start small, you have full control. So you can showcase the broader value of the outcomes uh to the broader organization.

I would really encourage you to scan this QR code for the previous ITM Academy um webinars. We already shared via chat some other links here. This is

another really important uh QR code we would like you to um uh basically scan because the Mers engineers are led by

Will and his great friend. They're

basically bringing really uh deep dive um specific item topics to you and you'll be able to uh attend those. You

have the link to the micro site as well.

In here you'll find all these links even uh of course in the final presentation.

Make sure you check out the service now impact our training and certifications and the expert services. Again, you'll

get all these links with the presentation. And that was it for today.

presentation. And that was it for today.

So, a big thank you for everyone that supported via chat. So, to Steve, uh, Sakshi, Ram, uh, thank you so much for your support. Will and Brian, amazing

your support. Will and Brian, amazing presentation, but especially thank you all for making another, um, session be so successful. We are really looking

so successful. We are really looking forward to see you in the next month's webinar. Please, please make sure that

webinar. Please, please make sure that you fill out the survey. You'll be

prompted to right now. And yes, we're going to see you soon.