we'll do a deep dive on tag based service maps of kubernetes infrastructure and how to make them look as nice as possible so um let's walk through kind of why we're here and what what's the goal why did why did Will and I to start it decide to start this whole process so um really the goal of this is to bring together customers in the servicenow ecosystem that are all kind of in the same spot in the cloud native journey to talk about how we're doing things and what's working well together and to really get some kind of best practices out there because there's just not enough conversation about this going on so who we are right um uh Mike Gallagher uh I am the Enterprise application platforms manager at drw um I have been I I lovingly joke that if it has a one or a zero I have probably Managed IT at some point in my career um but you know really um right now I'm focused in pretty heavily on kubernetes and Automation and just kind of General nerdy things um and today uh I am going to be drinking if you can see this it is called a dark abyss black cult style ale which like little plug I got this from The Lazy Dog beer Club um where they like deliver you like packs of of different beers it's actually really cool um so yeah black dark abyss we'll go ahead hi everybody will Hallam I'm an advisory solution architect at servicenow I spent most of my 30 plus years in in it working as a a practitioner spent six years as a service now customer before coming over to servicenow about two years ago I really heavily focused on automation especially in the cloud native space and been doing a lot of things with kubernetes and and serverless Cloud resources and that's what's um uh lart that played a large part in leading me to play around with with tag based service Maps and um come up with the the topic for today's session so during the session I will be drinking spare parts hazy IPA from Crossroads Brewing Company okay so kind of diving into today's topic uh servicenow can really do a lot of deep discovery of services that are running in a traditional you know on-prem or even you know any where is hosted doesn't matter so much is what it's hosted on if something's hosted on traditional servers Windows Linux um you know rack and stack load balancers that kind of thing our Discovery mechanisms are really great at enumerating all the TCP connections that are connecting those in disparate pieces of it kit and then from that especially given our new service mapping plus offering which feeds all of that into a machine learning engine we can elicit a lot of insights into what quote-unquote services what kind of groups of I.T assets are talking to each other and offering up some piece of functionality unfortunately when you're in a cloud native environment and that's things like you know Cloud databases Cloud functions certainly kubernetes you don't have that same access where you can just establish an SSH session or a power Powershell session to a server and list all the processes list all the TCP connections and then kind of follow the chain from there you have a lot less of that visibility most of what you can see is in the form of metadata either via kubernetes API calls or cloud provider API calls the the the quality or the type of data you're pulling in just isn't the same and that presents a challenge for both our horizontal Discovery mechanisms as well as top-down discovery which is our kind of heavily automated and very very detail-rich process of mapping a service or multiple services a solution to that challenge is relying on the tag metadata that resides inside our public Cloud resources inside our kubernetes clusters and at a high level just to kind of you know level set people on what tag-based service mapping does it starts by collecting tag keys or um so when we say tags in cloud parlance like AWS and and Azure those are literally called Tags in kubernetes they're they're actually called labels and and so when we're talking about in this in this kind of discussion when we say tags we're referring to either public Cloud established tag metadata or labels within a kubernetes cluster so the first thing we do is uh collect those common tag keys which are present within the environment and pull them together into servicenow tag categories and the reason for that is to basically account for the fact that nothing no environment is clean and when you started out you may have established we're going to have a an app Tag app and that's going to point to what the application is for this piece of cloud um compute and then six months down the road perhaps somebody said you know we really should call that app code and so then resources that were created from that point forward got a tag named app code but at the end of the day they're both telling you the same thing they're both providing the value side of that key value pair is telling you the same thing and we provide tag categories as a way to pull those together to normalize those without having to go through and boil the ocean and modify things on the tag side if you don't if you don't want to so once we've got our tag categories we pull those into what's called service families and service family is an expression of what tags you want to concatenate together in what order to then generate a service name and we'll be running through a couple examples of this to make it easier to to visualize after we kind of go through the the high level bullet points once we've got those in place the instance will on a routine basis or it can be triggered manually it will scan through all Ci's for those matching the layout of tag keys that you establish in your service families and it'll present you with tag based service candidates which you can then select and say Yes I want to map those um that allows you to kind of onboard new application services at your own pace it also lets you filter out any kind of noise or you know aberrations that maybe match the naming convention but for whatever reason aren't actual bona fide Services it doesn't kind of uh open The Floodgate and pull them all in that's completely controlled by the by by you once candidates are promoted to a full-fledged service then the instance performs what's called a a calculation where it essentially does what's on this next slide so it reads a table called service traversal rules to kind of it basically pulls them into a hash uh and based on those rules which say which relationships between what CI classes you're interested in it will basically draw lines draw spans within a service map between those to parent and child CI classes and it does just that by looping through each relationship that's in the cmdv Rel CI table corresponding to those uh those config items so what that means is for something like kubernetes cluster where you've got a fairly robust kubernetes Discovery pattern which is establishing relationships between things like odds and containers deployments and replica sets replica sets and pods where that hierarchy already exists in order to kind of instantiate that in a service map all you have to do is pick and choose which traversal rules you you uh want to focus on which ones are important to you and that can allow you to have some control over the the appearance of your service map and then as a as kind of a backstop after it runs through that Loop if it encounters or if it's got uh configuration items which don't relate to some other configuration item within that list of uh of it objects that fall into that service it just ties them back to the to the root service and this is a great start it it allows you to take data that's already in your environment in many cases because most companies have uh some type of tag governance around their Cloud native items because that's a key that's a key way to kind of to to make sense of them to sort them out and say you know how many containers are running that have this app tag on them or how many Lambda functions contribute to this application service so in in many cases this is data that's already out there and this is a way to leverage that get even more value out of it by pulling those things together and creating application services with your in your instance and then when you do that you've got the benefit of answering the question why do I care when somebody wants to do a change record against a Lambda function or against uh kubernetes node they can uh very clearly draw the line between that that kind of um ephemeral I.T uh you know piece of it kit to all the way to a a an actual business service because the application service is what gives you that kind of connective tissue between pieces of I.T stuff and some kind of business value or user facing um functionality so it's a great it's a great start the the one kind of challenge is that if you especially if you've seen a top-down service map the service maps that come from TAG based service mapping by default tend to be kind of flat they don't tend to arrange the the stuff in tiers that give you an idea okay this is kind of the primary endpoint that's getting hit and then from there it tends you know the the dependency or the um the data the interaction flows to this set of things like uh you know a load balancer and then to this set of things which is you know potentially some um app server containers or Cloud functions and so what we'll kind of talk about is is how to take that next step and add some more uh visual enrichment to the maps that you get out of the box so this is just a an example of uh kubernetes application and what you get just out of the box without doing anything other than saying Hey I want to pull a couple tag values together and generate a service from them so the top up here is the the app service entry point itself and then it branches out into the various kind of second-tier kubernetes objects and and this would be things like a kubernetes service basically you know the record that defines what port or ports are being listened to whether it's uh behind a load balancer or uh you know a cluster IP deployments pods replica sets Damon sets staple sets they all end up kind of in this this middle row and then the one dependency that you that kind of the downstream reflection that you get out of the box is where it ties a pod such as this redis cart pod to the containers that are within in this case I've got an istio proxy sidecar and the actual redis container image itself and it's the the utility there is still pretty good because it's ultimately still collecting all of those things into an application service which then can be referenced by things like incidents or changes and identify that kind of spider web effect where you say well I'm going to touch the pet clinic service and you can see oh under the covers it's going to spread out into all of these kubernetes items so for example these are you know things we would want to mute in the monitoring system while this change is going on to make sure that we're not getting false alerts or if you're using event management event management could handle that for you by detecting you know there's downtime records lodged against all of these Ci's so we know not to run any kind of escalations if we get events in during that change window similarly with an incident record somebody says Hey pet clinics down this would immediately say well here's a list of everything that comprises Tech clinics so here's what you need to look at whoops another another important thing to call out there is this more closely resembles the model of the data model that kubernetes uses internally right once you build out this tag-based service map initially right it doesn't really bear much resemblance to the data model and the the relationships within the components Within kubernetes once you go through and do this process it looks much more like what a you know a standard kubernetes operator would expect to see in how the components are laid out that's true and it you know because it's configurable um you know if there's specific conventions where you kind of want to have a certain set of Precedence between how that top-down appearance looks um you'll see that that can be that can be tailored with using these mechanisms so at a high level the way we do this um is depending on what the depending on what the configuration items are we may or may not go into the cmdb Rel CI table and add additional relationships and that's pretty quick question sorry well no go ahead so like one of the things like we do is from a cluster standpoint it's provided as a service so we'll say kubernetes is a service right and the Clusters are owned by one group but the nodes themselves underneath it or at least the kind of member servers are owns maybe by the same group or a different group but then the the VIPs or the virtual IPS or the the load balancer or cluster piece may be owned by a different group and so is it are you able to tag some resources but it doesn't necessarily include their parent resources as that same service map or would it automatically if you said a node belongs to one group it would automatically assign that cluster to the same service no it's granular you can you can support it off that way um one of the things I've seen in the the csdmy paper that talks to that kind of to a certain degree like in other words where you'll have like one team that kind of owns the infrastructure piece and then you'll have one or more app teams that own the actual you know workloads that are running within one of the things that sometimes works is you can actually use uh a CI group to tie together things like kubernetes nodes and then have have that's because that's another valid way to define a service is via a CI Group which just um the advantage to that is as soon as that CI shows up that matches your filter um then it it immediately gets pulled into that to that service um yeah there's there's pretty good it's fairly granular and you can when um when we kind of jump into the instance and I'll point out where you can actually that's you can also say like even if you want to use tags for that for example if you tag a node with um or you know label label a node or a cluster with oh this is supported by team A then you can actually break out and have a specific app family a service family that ties to not just the kind of support team tag but only the ones where the value is team a and then you can have a second one for Team B um so that's an option as well because part of what the problem we have is when we get vulnerability assignments when they come through we need to understand who owns what's running right on the Node less so much about who owns the node and is managing it as an infrastructure so yeah okay awesome thanks so adding or adjusting relationships that that's optional depending on the type of asset the the type of resources you're talking about kubernetes has a the kubernetes pattern throws in a bunch of relationships where in I mean and we'll take a look at a dependency view to kind of illustrate that so if you've already got a bunch of relationships and you just want to reflect that in your service map um then you can kind of skip to the Second Step which is just add traversal rules and that's where you pick and choose um I want to see the relationship between a kubernetes deployment and the pods that it is responsible for that it that it Provisions you add a rule that corresponds to that and you'll get those lines drawn uh in your service map and we'll show you that in a minute really important by default for whatever reason probably probably just to be conservative on performance when these um maps are being calculated there's this property service by tags Max reversal rules active is set to five by default and you'd most likely want or need to increase that if you're going to kind of build out this capability beyond what you get by default I think there's um I think there's three rules that when I just fresh pristine system got it provisioned there were three rules uh that were set to active and so you're going to run out of Runway real quick if you don't boost that pad that property and then um kind of after you've set the table the the way you put it into action the way you make it um take effect is uh that recalculate service related link that's on the tag based app Service uh record page and so here's an example of what happens when you add some additional traversal rules and or some relationships and I'll have I'll click through the live version of this but it's just it just provides a more kind of visually visually pleasing and illustrative service map as opposed to kind of putting everything across that middle tier and then only branching down to show you the underlying containers that are running inside because ultimately you know we get a lot of feedback that people don't really care about how many containers there are or even how many pods there are they're really concerned about you know the the operator structures that are in the cluster and telling it to spin up this application or this micro micro service and that's so that really speaks to kind of these top tiers where the way this is currently set up and it's not strictly uh dependency based it's more kind of conceptual uh flow of database so it goes from the application entry point down to uh the service so that's you know the ports that the um that that particular service is listening on and then it goes down to the deployment which ultimately I mean service isn't talking to the deployment but it's just a downstream flow where the service is going to talk to the pods which are ultimately controlled the the provisioning of which and the and the um restarting of which the migration of which all that stuff is determined by this dep by this deployment and then in between the deployment and the Pod is the the set so I'm not sure if it's off my head if this is a replica set Damon set staple set but whatever that is in servicenow parlance that all falls under the kubernetes workload table whatever that is that's got kind of that's kind of the downstream product or artifact out of the deployment okay so now some uh some live examples of that so just to kind of again just to kind of quickly level set here's the record for an example um kubernetes service and what I did to kind of prepare this environment was I took an example kubernetes based application and I applied some labels to it and those are reflected down here in the key values related related list and we discover this for all the public Cloud stuff all the kubernetes stuff uh pretty sure even VMware has tags that that we can pull in as well so if you're running Discovery in those kinds of environments you've got all of this tag data in your instance already and all we're doing is just focusing in on the bits that kind of tell the story of this is the application environment geography that ties all of these like components or kind of like purposed components together so in this example I defined a uh in the kubernetes example I've I've kind of honed in on this key value here which I called service and this key value here which ties back to an environment designation so this is a my make-believe QA environment for the boutique application uh the reason I kind of broke out I named this service was just because it just so happened that this example set of kubernetes manifests already had an app tag but it used that for kind of the micro service level and um while you can certainly you know map out each micro service into kind of a mini map and then tie those together with dependencies it doesn't you have to kind of Click between them it doesn't really produce that that kind of visually meaningful here's everything that rolls up to this kind of larger primary service which is called Boutique and so that was why I chose to do that but the good news is it's completely up to you whatever kind of tag taxonomy you want to put in place you can you can use it and all of this functionality will work exactly the same so picture if you will I've got a whole lot of kubernetes pieces that make up this Boutique service this Boutique application and I've just applied these common tag values and and we do get asked a lot what are you know Greenfield what tags should I put on my stuff that lend itself to effective tag-based service Maps the top two are definitely application or some kind of an app code um you know a lot of places have you know portfolio management where when a new application or service gets onboarded it gets assigned a unique code so that's also um you know something that categorizes describes the application or the the functionality which is being provided by this group of stuff and that environment is definitely kind of the most common the second most common thing that gets uh called out it's it's ubiquitous there's there's you know every I don't think there's net I don't think there's ever been anybody I've talked to who doesn't have at least a prod and one or more non-prod environments right I mean there's always that that's just kind of a ingrained separation that we do as I.T practitioners and and so the concept of having an environment tag is is extremely prevalent and then on top of that um I would say the third most common tacky is is geography where or and by that not necessarily like country or state but if you've got multiple campuses or multiple um data centers codes that you know some type of a code or designation that ties things to one of whichever location type um Paradigm is being used okay so I've got all this kubernetes stuff and it's all got similar similar tags set up and so just to really quick walk through what I kind of covered on the slides um I also see in cases where things are being automatically provisioned requester or owner um are also kind of similar tags that we see um but that's more in the case of like Hey we're automatic provisioning all of these components and we know who is requesting this or who is the owner at the outset sorry continue no worries there's yeah there's a lot of diversity there and there's no there's kind of no limitation um I think there is a property that defines like the maximum number of tag categories that you concatenate together um I think that's also set to five by default um I would say just from a cleanliness perspective or in a length perspective that's probably not a bad shout for most shops but you can tweak that if you need to concatenate you know six or seven tag values together for whatever reason so as I mentioned uh in reviewing this when we were reviewing the slides the tag category just provides a way to normalize your tag keys without having to remediate your tag your actual tag metadata and not the service now can't help you do that as well we've got a great offering with tag governance but we're not you know there's no requirement that you have normalized or standardized tag keys if you've got a few variations you can this is where you implement those so if you've got app and also application as a tag key that ultimately ties back to which application a piece of cloud native stuff Maps back to you just capture that all here and so I've got one that ties back to something called app whoops I guess it should save but I don't need to save that I was just it was just for instance saying so we've got a couple other ones and the tag category name is really just the Handle by which servicenow knows that list of tag keys so here's where I Define my environment tag key and then I did the same thing for that um for that service tag key here and so once I do that I assemble those into tag based service families and so for my kubernetes based example I'm saying take my the value of my service tag and you can specify that you specify the order that they get concatenated by the service naming order value here so I'm saying take the service label and take the environment label concatenate them together this standard delimiter is a double colon as you can see by this one map service that it lists down here once you create the service and and so um you can also specify specific tag values so this would be where uh you know if you had a support group label and you wanted to pull you know just a list of all the app Services together into a family that were supported by a given a given team that would be how you did that you would have this you know BX service Dash team a and then you would say um you know support team as the tag category here and then you would say you know here are the values that I want to filter on and again these are all just records so you can also if you've got like a an Excel workbook that ties you know like standard tag values to standard you know support teams or um you know whatever hot you know Financial hierarchies you could write a flow and just ingest that and generate these tag-based service families um accordingly so if I was setting stuff for the first time and if I didn't want to wait for the scheduled job that runs once a day to generate service candidates I could click this link here to manually update service candidates and then I could click this button here to view those service candidates and in this case the only candidate has already been mapped so I don't see any candidates but if I had any candidates which hadn't already been accepted as a service they would show up here excuse me and then there's a there's a check box and a UI action down at the bottom that will instantiate saying map these services and that's how they end up in this related list down here and then I can click view map and it will show me the map that was generated and if I'm on a vanilla system this is the kind of thing that I would get it's basically um let me go to the boutique you know this is just a live version of what I had in that one slide it it's going to be fairly flat it's going to take all of the different kubernetes parts except for the containers and place them in a kind of a middle tier of of kubernetes objects so for example this here is the service this is also a service this will be the pod and so it's good in that it's collecting everything and and you'll be able to use it to assess impact on changes in incidents or alerts um but it's not as visually pleasing as if you could get a visualization like this and in this in the context of kubernetes all it's doing if I look at a dependency view is it's just kind of mining these existing dependencies which are already sitting in your cmdb if you're discovering your kubernetes clusters and that flatter map is much harder to read right and it doesn't again like I was mentioning earlier it doesn't really follow the kubernetes kind of object hierarchy um whereas the the more customized tag based map does so I've always found dependency maps to be kind of cool and kind of take them or leave them in that it's definitely cool to see this kind of spider web effect of all the dependencies that are present in your um you know in your I.T estate but at the same time it's just too busy you can't make sense of it it's really just a good illustration of here's all the relationships that we're Gathering under the covers behind the scenes but it's really with service Maps where you could kind of distill out the pieces that you're predominantly interested in and so that's I think uh a big part of the value statement Behind These behind service Maps like this where you can basically say okay we've got the boutique it relies on all these micro services and you know especially in this case where we've got both an external and an internal service endpoint for the front end that's you know kind of useful to know when you're talking about planning changes perhaps you know you're touching an external load balancer and you need to know that you're gonna have to validate external traffic as well as internal traffic as part of your kind of change validation plan okay and so how did I how did I do this it all comes down in its in the space of kubernetes in the context of kubernetes it's it's all done the uh traversal rules and so if I clean up this traversal rule list to just show what's active and then I filter just on kubernetes stuff right and so by way of comparison let me go to a vanilla system and just show you what you've got out of the box filter out okay so out of the box you have three traversal rules uh one ties Hardware back to a VM one ties an application back to a hardware record and then one ties a kubernetes pod back to the container and that's why when we look at the vanilla kubernetes based map kubernetes tag based map we see that you know it does break out the containers running inside the pod so what I created well that I just added three rules uh one rule that ties a kubernetes service back to the deployment and this is an existing relationship that the pattern provides so I didn't have to go in and tweak any relationships I I just discovered my kubernetes cluster and added that rule uh then I added a rule saying hey if when I see a kubernetes deployment which owns uh anything in the workload table so workload is staple said Damon set replica set and anything else kubernetes comes up with they seem to come up with new operators or new set types all the time and then kind of the the kind of the bottom tier the ties That set to the pods is accomplished via this rule here which says anything in the workload table that has an instantiates instantiated by relationship with a pod I want you to draw a line to reflect that and so we do have a the ability when creating these rules to reverse them and so the best way I can describe the reverse option when you're doing traversal rules is if if the object that you're seeing in your flat map is actually the child then you need to hit reverse in order for it to pull the parent into the map so what I was seeing for example was um if I created a rule that tied if I created a rule that tied a pod to a deployment without hitting without um setting that reverse to true it was it wasn't connecting them it was leaving them kind of on the same on the same level in the map and so that kind of black boxing it and changing you know tweaking rules and seeing what it does that's my best explanation of what that reverse um what that reverse flag is used for it's kind of used to bring if if the thing you're trying to bring to the foreground is in the parent position and you're already seeing the child in your map as it is then you set that to reverse and that kind of locks them together and creates that that kind of waterfall appearance where they kind of flow down from top to bottom so the the one um the the other example that kind of speaks a little bit to when you don't have the relationships already pre-baked into your uh into your Discovery pattern is if you've got uh for example some a cloud-based application which uses Cloud functions a cloud load balancer a cloud database on the back end perhaps then what you get out of the box with that is going to be something like this so in this case I've got some AWS components that are tied together by Common tags um basically at AWS load balancer over here which then ties into a couple Lambda functions which are these two guys here and then the Lambda functions are using uh an AWS RDS instance Cloud database as the back end and so out of the box what you get looks like this it's all very flat these other items are just um these are RDS snapshots that are automatically taken by by AWS of the cloud database so it's kind of pulling those in as part of the application since they live on that database instance which is tagged as part of this pet clinic QA environment and so when I look at when I look at the dependency view for this kind of stuff it doesn't really capture any relationship by default between the um between the database and those Lambda functions other than they live in the same AWS account so if I look at the cloud database here it's got a lot of relationships but it's kind of it's contained in this availability Zone this relationship talks about it's contained in this um it's going off the screens probably cloud service account there it owns this IP address here anyway there's not a lot of useful out of the box relationships in there that we can capture and use for a service map so what I did in that case I created a little scoped app uh which I call Tag enhancement and I just generated a Json file for each of my apps and I just failed out here here's the relationships that I want to establish between the different pieces of my application and so the idea here is you know if it's an internal application that's a cloud native construct it's probably going to be built via some CI CD pipeline you can capture the relationships between the different components in a Json a yaml file whatever as part of your CI CD process and then whenever you build or do a build or an update you can feed that into your servicenow instance in my case what I did was I just created some I just created a quick table and I just uploaded that Json file as an attachment so I could just do a little demonstration flow like this that just goes through it parses that Json file and it establishes those relationship records inside the cmdb CI relation table and then because I've done that when I look at my map on my enhanced servicenow instance I should see a little more layering that kind of shows a more visually impactful depiction of what this Cloud native service is doing and so this is that same service but you can see now it's a lot more hierarchical I've gone from my entry point I still got my RDS snapshots here off to the side which is fine um but here's my load balancer it's talking to the two lambdas and they're talking to this back end Cloud database couldn't you potentially also create a traversal rules to tie those snapshots to the RDS database yes yes so what I did um I I did have to create some um traversal rules just two uh created one saying hey if I see a load balancer connecting to a cloud function I want to know about that in my service map I see a cloud function connecting to a database I want to know about that in my service map um one piece of Errata or just something to watch out for I I um been working to try and get Cloud functions to have multiple levels and by that I mean ideally I would want this front end function to be kind of on its own level and then cart function to kind of be down underneath that because in my imaginary pet clinic application everything flows through the front end and then underneath that it would have things like the cart service the currency conversion service the order status service that kind of thing um I haven't quite figured that out yet so stay tuned if I figured out before we send the wrap-up notes I'll certainly make a note in there or I'll do a community post once I finally kind of get that nailed down so I I did kind of what I would have thought would have caused that behavior uh in other words I created a relationship between front end and cart and then I created a traversal rule saying if a cloud function uh depends on use by a cloud function then I want to know about that but somewhere in there the calculation doesn't seem to pick that up and I end up having you know the cloud function the dependent Cloud function ends up kind of up at this this top tier with the snapshots right now so more to comment on that as I kind of make further progress but other than that it's been fairly straightforward in kind of pulling these things together it's really a matter of getting of prioritizing what are the important kind of Upstream Downstream tiers that you want to reflect in these service maps to make them more useful than they are just with a kind of a flat topology being being depicted it will add one other question for you I was gonna say the hierarchical piece is important we have a similar use case so if you figure that out I would definitely like to know about that the the other question I have is how uniformly is this implemented across the uh different Cloud providers and so we're kind of hybrid multi-cloud and part of the problem we're going to have is um some whether we can uniformly manage tags across the different Cloud platforms but um are you able to distinctly say this applies to AWS in some hopefully easy way versus you know gcp of how we apply it and are some things able to be applied across both so I've personally played with Azure and AWS so far and this isn't this is basically the same app um in Azure and other than kind of the lack of snapshots being pulled in for the cloud database down here it looks fairly similar and that's all with the same set of traversal rules and tag families and tag categories so at least firsthand within those uh between those two providers I haven't had to like make allowances where I do tweaks to kind of deal with the foibles of azure or um or AWS I think if any if if anywhere the place where you you might run into kind of different slightly different Behavior is in the CI classes so I did run into a weird thing with Cloud databases in Azure where Azure is migrating away from um like their single server cloud databases like you can't even provision them with the console anymore you can do it with a CLI or an API call right now but they're phasing it out and so in order to pull this in which was a flexible server I had to I did have to kind of um go down to the pattern level and kind of adjust something in order for this database to show up um I think that's actually been handled that particular thing I ran into has been handled by a a pattern update they've just made a big jump I don't know if anybody's noticed but uh they did a fresh drop of the patterns app this month and it went from version 1.0.99 to 1.3.0 so I'm expecting big things big improvements in Discovery patterns including you know Cloud Discovery um when I finally get my demo instances updated to that latest store release of the patterns app but so maybe there's a way to tell the difference between VMS versus on-prem and cloud and different clouds and tell which type of VM machine instance it is rather than having to drive drive it back to a data center to a subscription yeah you should be yeah you should be able to um I know it it does depend a little bit on how you're doing your Discovery because I noticed for example like when you go in here there are some cloud provider specific you know um views in filter Navigator so if you put in AWS for example it does kind of break down where you can get individual views and all these tables are actually kind of general purpose tables like storage volumes is not yeah some of them are still database views where they're doing the the lookup behind the scenes so they're not the VM you're right the VM machine instance yeah right table still just has the generic data and the only way to differentiate those is like you're saying is either to use the newly created database view or to figure out to add an attribute or a tag so that you can manage it yourself but it was a kind of a shortcoming of showing all of those VM instances in that same table without any kind of device type or right delineation or attribute of where they came from or which type they were so yeah okay yeah I don't mean to derail it I was just um it's one of those things we had run into so yeah well and and basically I ran into this when I was doing some work with um the service graph connector for AWS it it doesn't whatever this view is filtering on the source graph connector didn't populate that attribute so the first time I ran it it said it discovered a bunch of VMS but then I went to this AWS virtual machine instances yeah they're all empty yep that's how we found it the same exact thing yep yeah and so then they pointed us to the to the left nav thing and then well my boss asked a question and I was like oh that's a database View and here's what it's based off of and even that because it got weird for one of the other tables isn't populated correctly and it's putting it into a a parent's table or a child table and so even the view by default doesn't work for the at least the older version of the AWS service graph connector so yeah anyway sorry no no worries that's a that's a good opportunity to give a plug for our next session which is going to cover some updates on the service graph connector for AWS they're going to version 2.0 it's got some major updates as well as um talk about the first iteration of the gcp service graph connector um also since we're getting close to our official time and Mike and I generally both just hang out for as long as people want to should the you know what but um before before we reach the official time I do want to announce we've just found out that we've been kind of approved and funded and all that stuff to have a live beers with Engineers uh session at knowledge in May so if anybody's on the fence or was considering not going to knowledge um please reconsider so you can join us for some actual live beers and actual live Engineers um in Vegas in May yeah Count Me In I'll be there nice we're excited yep awesome so as always um this recording the slides I'm also going to try and um I ran into a little snack because there's some hierarchy um in these traversal rules but I'm sure I can figure out how to pull these traversal rules into an import set just as a useful example hopefully um include all those in our wrap up emails that will come out shortly after you know shortly following today's session um at this point I'll just open it up and let me I will shut down the recording and then just open it up to open Forum whatever questions or topics people would like to discuss for however long