all right so welcome to the fifth session of days with engineers um will and i are super excited today to share the stage with the illustrious rap dev team here to talk about the now.yaml service we'll we'll kind of kick things off in the same normal process as we always do um what we're talking about today is may or may not include some forward-looking statements especially as we start getting into the workshop and q a section so we will remind you not to go and make stock purchasing decisions about anything that we've made here today right so just keep that in mind we'll do the normal usual agenda as always we're pretty informal here if you have questions feel free to raise your hand i'll go through and unmute or allow everyone to unmute themselves as well so if you have questions feel free to just jump off mute and and ask whatever comes to mind as as the team is going through and doing the discussion so um we'll talk through kind of why are we here right the goal of this and why we started dealing with engineers is really to get together um a group of servicenow customers who are a similar place in their you know kind of cloud native journey and kubernetes adoption and so that we can all kind of get better at a how we're doing that and what that looks like as well as share ideas around things that have been successful for us and for other customers as well so who we are if you haven't uh joined before i'll give you the quick rundown uh mike gallagher i am an itom architect here at servicenow um we'll let the rap dev team introduce themselves in their section but my background i've done you know 25 plus years in tech i always joke that if it has a one or a zero in it i've probably touched it at some point in my career um i have a propeller head i love to solve business problems with tech and i'm super focused right now on kubernetes cloud-native technology as it relates to servicenow's i.t operations management solution my side things that i do i'm actually in brazil right now with my family and have been training brazilian jiu jitsu and playing board games so i got all of that wrapped up in like the last couple of weeks here so um will if you want to go ahead yes sir uh will hallum uh itom architect uh teammate of mikes focusing on automation automation automation especially in cloud native areas cloud functions kubernetes serverless infrastructure as code all nine yards in my personal time i enjoy spending time with my family playing some pickup hockey and uh playing video games and um given our title i feel obligated to uh just uh share that i'll be enjoying a cold zombie dust pale ale from uh three floyds brewery in munster indiana in this great gel filled uh glass that one of my sons bought me for father's day and you actually stick this in the freezer and it keeps your beverage at the optimal temperature while you drink it nice and and i was remiss and forgot to introduce my beer right so uh a because i'm in brazil right now i um and b because it was actually a gift from a good friend of mine um there's a i got a brazilian beer called holeta hoosa which is um portuguese for russian roulette uh it is a new england style ipa um and it's from the oh they call them yeah cervezas extremas which it means extreme beers uh in portuguese so i'll be enjoying that today while i listen to the rap dad team talk that being said i think we're ready to hand it off to them yo yeah thank you for the intro mike um um and uh will a uh a you know there's a poll jumping off so before we start off we actually wanted to see just a quick check and how many of you are already or are looking to or being pressured to add microservices into this cmdb uh just so we can kind of get an understanding of where you are and how useful it is that we're going to talk about um and maybe if you're not yet it's probably going to come up um so let that run for a few seconds while i do my own intro i'm joshin harden i'm a solutions engineer repdev i've been in that role for uh just over a year i've been in itsm servicenow and other products for about 22 years i am not the biggest fan of beer so i will be drinking a little bit of this which is my classical reposado tequila now i'm a big fan of tequilas so that's just kind of what my default would be going into so i figured like take out the big special bottle for this session if you have any questions about tequila after the session feel free to ask me anything um i have a few more other people resources as well so um that out of the way i think we'll do intros first john you want to pick it up and just interview yourself for a sec yeah hey everyone my name is john guyra i'm a servicenow architect over here at wrap dev um here at wrap dev you know i lead a lot of our cloud native itom and devops implementations been in the servicenow space for around uh seven years i was a little lame today i only have water with me so that's unfortunate but and i'll do i'll go real quick uh anthony earnest head of sales at rap dev i won't probably hear from me again today unless there's a question that that i could potentially answer uh really here for for moral support and to enjoy the beer uh i have the fridge is a little bit light so it's kind of a standard pick but it's a harpoon ipa fro out of boston thanks for having us yeah nice little segue so just as a quick two second intro and web dev um we are a boston-based firm i'm not sure that influences the decision in beers but we've been uh in this space we started about three some years ago very focused on devops and from there we've expanded in anything that's cool engineering-wise um which includes things like the devops module itself integrations around it making servers now in general work in a cloud-native environment i think the thing we want to talk about today what we've done with what we call the narrow yaml solution so i think is a good example of our engineering approach and mindset and i'd love to take your feedback or any questions you have on it as well is it's going to be mostly a technical session so some demo john will walk you through it some of the stuff so how we configured it and why it's there having said that two seconds on the intro i don't know john if you want to share we have we have one slide and i apologize for that it was the anyway to um to bring that up so as we segue so this is kind of the decomposition of the things we're going to talk about today um and judging by the poll i think we're with exception of two people this might be a really good topic hopefully stop sharing there we go um so what you see here is just the decomposition so where the the design that we have that drives this is we want to be able to from any code repository whether it's a product orientation product orientation a product orientation or project get up with a bucket as you repost wherever this lives will define have teams define their services the things that they are working on their microservices and their relationships in their repo standard yaml file we ingest that we suck it into service now we do validation against this so depending on how risk averse or tolerant your organization is and how much is predefined or not so how much control and governance there is we do validation against that file that leads to output output being it's great it's not great this failed this is great or this is good and also the creation of um the uh seem to be entry so for those that know the csdm 4.0 uh model was released or sort of semi-released has a whole space for the development camps or the sdlc components so what we have done here as well is that the ability to define those components and relationships with the existing or the pre-existing ones like the business application the business service the application service etc and also on the back of that because of the definition automatically generate application services tag-based application services that start working and basically creating the service mapping view for that as soon as we've successfully ingested that file um that's the slide that's the intro so from here it's all tech and server is now hands on so i'll hand it off to john if you have any questions we have a qa and i think people are able to unmute themselves as well so feel free to do that and looking forward to a good interactive session all righty thanks josh all right so i'm going to be walking through the demo um so in here i have a code repository up and i'm actually going to be committing uh two actual two different files to this code repository and just before we get going i just want to show you over here we have two business applications that we're going to be dealing with wrap dev dot io wrap dev oop chat bot um currently there's no sdlc components and there are no tag-based application services just to show that we're not faking anything over here um so first off so let me go ahead and get up this sample file that i have and let me put it in here and then i'll talk about it so i'm just going to create a new file okay so this is our base now.yaml schema there's a couple different things in here that will go ahead and map to the different components that we have inside of your cstm the first thing we have over here are the business applications um here and this is where josh had mentioned before depending on how flexible your organization is you know we have the flexibility of either dynamically creating things on the fly or having certain validations in it where the things that you denote here have to already exist inside of the cmdb and we're able to update them you know etc etc it all depends on the level of control you want in your organizations but it's easily flexible you know we can make the appropriate amount of changes um and you can see here we were able to update you know certain fields um as as we put in the yaml file the main thing is the microservice each yaml file inside of each now.yaml file inside of the code repository represents a microservice the one here that we have is we're just calling it wrap devweb and with it this is where the business applications tie in we put in there what business applications consume the micro service that way inside of servicenow we can go ahead and map them up to the business application taking advantage of you know the actual csdm hierarchy using the correct relationships we also you know put some ownership information here around microservice as well and then down below is where we list out all the different environments in which the microservice has been deployed in what this will do is create different tag-based application services based off of each environment that you denote here and what we also do is you know we have a place where you can denote the tags for what we can expect to make up that service so for example when and this is because it ties into tag-based service mapping so when we go out and discover your cloud infrastructure you know whether it's hosted in aws azure gcp kubernetes whatever it is if we go ahead and find whatever tags that you denote here we can then automatically map those up to for example the wrap dev web prod microservice and this is just you know the out of box capabilities of tag-based service mapping but here we're able to do this automatically through the yaml file ingestion and no one has to set any of this up inside of servicenow which is currently the case of you know most people have to do so what i'm going to do now is so we have the file here i'm just going to go ahead and commit this and just give it a couple seconds and we'll see it popped yep we already see it populated over here so you can see this went ahead and got created we have the proper ownership fields there on the business application you can see owners either populated or changed beforehand over here i had them as josh but with the yaml file i went ahead and changed them and you can see there were three different tag-based application services that were created um because those were the three different environments that we specified but let me actually go into this sdlc component because i think it looks a little bit better when we see it in dependency views so here we have that sdlc component which was our microservice and you can see upstream we have the two business applications where you know it contains the microservice and then downstream from the microservice we have you know the actual you know the logical representation of each environment for wrap dev web you know we have development test and production now all these relationships down below is what i was talking about a little while ago where based off the tags that were there the service was rap dev web the environment was production so using the tag-based service mapping capabilities of servicenow all of these relationships were automatically linked to that tag-based application service so you can see here there's different kubernetes components we can see some kubernetes pods i think over here it was to the left yeah over here we can also see this is actually an ec2 that came out of aws so you know based off of what you're actually discovering and where your infrastructure is hosted you know we're able to bring in you know a lot of different technology stacks under the same solution so in terms of the validation you know that we were talking about how do we know things got properly processed were there any errors with it you know we want to have that feedback loop to the developers so that they know you know if they have to make any changes et cetera so what we have here is an integration into slack so right up above here we have you know basic information about the commits where it came from who made it and you also can see each different element broken down to what happened so you can see for this respective business applications you know their ownership information was updated it was changed we can see the wrap dev web my microservice was created we can see the application services were successfully processed and we can see the relationships were properly created for the said entities so and you can see here it is you know a very clean data structure uh so that we can easily consume it in a lot of different areas you know we can do it via slack email we can even have it pushed up to um aws s and eventbridge you know there's a lot of different capabilities that were able to go around here so you know this was an example where there were no errors at all but i just want to show you really quick what would happen if you know there were some errors inside of the yaml processing so i'm just going to create another file really quick and with this one you can see because again this goes back to how flexible you know your organization is if you want to create things on the fly for you need validations so for here you can see here it's just a typo i fat fingered it instead of doing draftdev.io i did wrapdev.ip this will throw an error because in our system currently we have a rule that you can't just create business application on fly they have to already exist for this micro service uh you will see that it goes ahead and get will get created but one of these environments here is not a valid environment for you know in our organization so we also do that type of validation as well so i'll go ahead and commit this and here we go over here and so we have the wrapped up shard and you also see that it doesn't have ownership information here so just say if someone's looking to start sound seeing what's going on let's go and over to the slack channel let's give it a second over here to fire off and here we go so now we can actually see you know what was actually going on with us so here we can clearly see okay the business application didn't exist all right the business application was not updated obviously there's no relationships created for it because it doesn't exist um and we also do proper validation too with users or groups right because those are the ones that really describe the ownership of the said entities so for here um that actual user the email that we specified for that user didn't exist so we can't populate it there the um there's no active group so there's no user group and servicenow that wasn't there again like i was saying for the visit it's not valid environment so there was no tag-based application service created for that as well and again this is where it gets into the flexibility where in our use case we wanted to be able to process as much as possible and not do uh you know one little thing was wrong to completely fail the entire process we wanted to you know ingest what we could but then communicate back out those errors to you know that the people who are either committing the file or you know subscribe to whatever event bus you know where this information is being sent um all right so that concludes our demo um josh i'm not sure if you um have anything to add before we turn it over to some q a uh no i think the definitely q a i also want to see if we can show some of the variation the only thing i wanted to call that just more going into the engineering and john kind of touched on it so the the the reason why we built narrative obviously we saw that there was a there was a need but also in the design and that's something i want to give everybody on this call as well to contemplate is the general trend is right you need to incorporate your devops teams your app dev teams or whatever you're calling your digital or dtc incorporate them into the process that run on servicenow but ideally keeping them away from standard servicenow ui interface keep them in their environment keep them working on the stuff that they're familiar with but empower them to interact so this is one example where developers or product owner whoever defines this yaml file in the repo they put all the stuff they care about in there and everything on the back of that is automated away from them so they don't leave their ide they don't leave their repos they don't leave the environments they care about and on top of that you can think of ways of automating that like a pipeline to build new pipelines when you do project initiation or new product initiation right where the pipeline builds or creates the repo creates the core files in there it creates all the setup for the users this is a perfect set of including that so that's kind of the step up and we do some other initiatives but i won't go into that but the essence here is that shift left move away from do everything yourself and include these teams empower them um or as a team claim the empowerment say i know what's going on the best in my environment let me define what's important and then you ingest it and do with it on the back of it what you will i see that um christopher raised his hand i think you cannot yeah yeah quick question well hopefully um so you know your output to slack and whatever message bus that's pretty uh cool um just wondering you know included in that do is it kind of built in the way that you've set it up or you know obviously someone could make changes but to be able to kick off let's say a flow or a workflow in the background to be able to then uh you know assign an incident out to the team to remediate some particular thing etc etc is that yeah definitely that that is definitely possible um and that is actually something that we've had some customers do um sometimes um there's actually one customer i'm actively working on where you know for them it was a more of a strict you know everything had to be right in order for everything to get in but if there was a dynamic incident created from that and it was you know go ahead and assign to you know the appropriate parties we knew the the committer we know what repository came in you know we went knew when it was committed because we have all that metadata about the commit so then they're able to go back be like okay this actually didn't make it into the seem to be i have to go look at my yaml file and make the appropriate changes and it lists out very you know very specifically what went wrong it's not just saying you know like like you saw in the slack um channel that i had open it says very specifically what was wrong so that they're able to go ahead and rectify it and all that they need to do is just make another commit it'll get reprocessed you know whatever the file then is and you know if it's good then we're good to go is there any way included in that to uh verify the file before you actually attempt to do anything with it like i commit it and pre-process it essentially checking it for errors yeah so and that's what we do at least on the servicenow side that's what we do for this one specific customer that i was talking about so nothing actually makes it into the cmdb there's a bunch of validation that happens beforehand and if we see you know again there's there's a bunch of different validation rules that could be into place but we check all the different validation you know possibilities if there's any sort of error you know we go ahead and put those you know into our proper list and communicate it out and we don't add anything to the steamdb right i i maura was wondering like as a developer i want to commit my ammo file and say you know i don't actually want to do anything right now but i want to make sure that it's going to work when i push it in it's kind of like a dry run option like a you got it yeah dry running or a lint yeah the capability for sure is there yeah cool [Music] get your connections to go mike so i think the the question is that chatted uh you put it in chat what's the state after this error relating command so what went in what didn't and how do you make it right so i think in the current in the current approach and the current setup and and there's different variations but the way we default uh position it is that the the update itself as it comes in we process it in line so to speak so we don't give it a it's a stateless stateless processing with a feedback on what was success or failed and you can have the hard level where you say everything needs to be good before i process or like we show by default we process the pieces that we can um so between that that will generate that output um but once that output is generated we are not keeping track of previous versions or iterations of that file that is in the repo that sits there um one thing to consider right we in this example we're just pulling it from the repo but you are you can apply things like devops config to this file you can apply additional testing or pipeline based validations to this file so it's not a we do it we drop it somewhere in a location and we pull it into service now and that's it it's you can now make this file subject to your regular devops processes in your as part of your build processes and validation processes so you're not tied to doing everything in service now the file itself has a life cycle within the repo and you can do things in that context that precede ingesting it into servicenow as well so that's um that's maybe i think a key thing also to remember we're not trying to solve everything on the platform we're trying to solve for how do we get data in a certain state to do all the things that we needed to do in service now to remove that burden or the toil on the admin signal service now and to remove the overhead for the developers i hope that made sense i had a question about your what's your um what's your end point for triggering the you know the the piece that occurs on service now is it just like standard web hook that you can figure into your pipeline um so whenever commit goes in you just hit uh end point on the instance or yeah it's a very good question so they are web hook based um in terms of the end points that exist so we have two different flavors of the now.yaml one that you know it ties very ties into the actual devops product that servicenow offers because with that product we are already ingesting all of the commit data so we piggyback off of that endpoint that is already there and you know we make the the proper callouts we also have a non-devops product version in which case we have created our own endpoint um very similarly you know we ingest the push events that are coming into servicenow whenever a commit is made so in terms of you know how to trigger on the appropriate file because you know you can have hundreds thousands of commits right against any sort of repo in your org so what we go ahead and do is we have two different properties that are configurable one of them is for the file name so we say that the file name has to match a certain regex you know by default we just say now.yaml but you know it's configurable whatever the naming convention you want to be for these files the other one is the branch because you know developers are probably you know making changes in whatever sort of feature branches they have um you know a lot of times and what we have is default we have it as being you know only when it is committed against your main or master branch but again it's going to differ based off the use case and the organization it's very flexible can be configured so in essence what happens is developer makes a commit they you know for a particular file in a certain branch we get that webhook payload event inside of servicenow which we check the file name we check the branch and if it matches you know those properties we go ahead up into the the git repo we retrieve the contents and it's it's a yaml file right so we actually have to then convert that to json and then because you know you can't really work with yaml inside of servicenow so we convert it to a json object we can very easily work with that and then we go ahead with the validation and the processing and the yaml to json is actually an application that rap dev built it's actually available on the servicenow store for free that is good to know because i faced that ammo challenge myself yep so just to reiterate because it's kind of an important point i think you guys don't have a dependency on the service now devops config module functionality whatever if we you know if a customer has it then great you tie into that but it's not a requirement on your part to take advantage of this functionality correct cool let me uh i think uh zach posted an update so let's uh update question follow-up question so i'll try and continue a little bit i think it's a valid question the question is if pieces fail right um then why am i still ingesting something um i think this short it's a short summary i think the the question there is also has to do with fault tolerance of the organization right there is from when we implement and when we when we look at the how servers not going to be deployed just having a let's say an sdlc component with an uh with a tag-based application service underneath it that can be used to identify events that are coming in into event management use that for correlation and suppression finding the right assignment group or identifying that service relationship that by itself can already be valuable so depending on how structured the organization is having some or all of these pieces processed by itself will constitute value the same as let's say the business application is correct or some other information is missing if we can process ownership change automatically even though that maybe the primary support group change didn't come through we still have a valuable piece of information that we're progressing so it's in that sense more of an eventual consistency right yeah if you give me the leeway there but it's like we're processing the data we can because that is truest to the nature of the of the push that we're getting right the information update that happened um failures are communicating back and can be corrected by the developer the same as when you have a bad line of code it fails a test the test tells you this failed or this piece failed depending on the type of failure or errors that come out of your testing there's always a choice right so in our case we still process it and it goes back for next iteration or updates if it fails but again if you if an organization doesn't like that because they're more strict in their definition they just flip the switch all the way to the left any failure leads to complete rejection and it still gets the same output so you still see the pieces that are good or bad but the entire file is not getting processed so you still have granularity but we want to make sure that you can facilitate anything right just in time or just enough or some good information can be better than no information um so there's a and i think that kind of touches we'll go into too much of the uh of the the principles there but it kind of touches on to some extent the the the balance you need to strike between traditional um cmdb controls and management but also the we need to get code out into production fast and it needs to work and that's the key component some working or good working is better than best working if that takes more cycles so it's in that same same nature that we do allow and we want to keep allowing that ability to toggle between just process which you can and don't process anything so how are those um how are those knobs adjusted is it tables properties how is that managed within the service instance as far as how tolerant to um deviation the processes yeah so that's just a property as well um so you know currently we only have you know two but again if once you know doing an actual implementation you're actually trying to do this more you can actually put it more into the code because you know it's kind of hard to control more than just you know the one or two where it's you know process as much as you can or you know any sort of failure go on or you know maybe it's like a count again because then you get really into the weeds in which case it's more of an entire solution that you're trying to develop for the actual set organization in which case you know they're going to be setting it up you know for everyone to consume and they would have to go by the same standards in which case then you can just have it you know inside the code itself um because again what we have what we have is especially what we showed is just a base um depending on the organizations they may want to provide more information about the you know the said microservice or update more about the business application stuff about criticality or you know whether something touches pci you know sensitive information um so it's it's just a base it's a starting point and then we just map it over to what they actually want to track inside of the cmdb and christopher updated a message i'll read it up you know it's uh it's the question is can different projects have different standards for that risk tolerance or is it across the applications the parser at the application level that's a great question yeah it um yeah it could be you know if a customer wanted to if an organization wanted to do that that's something that would definitely be doable right um in that case you would probably you know we would have some sort of custom table mapping you know where we have you know whether it's a repo or just like a team structure where we can say okay this one is you know everything has to be right this one you know it's a little bit more convenient but yeah no something like that is definitely doable john we have a few more minutes could you talk because we've done a similar thing right for a customer reason where we had different definitions of that now.yaml with some different requirements could you maybe talk about that a little bit yeah for sure yeah so um if you guys remember i showed the yaml file and actually let me share my screen for this get a little bit more visual so this is one iteration of our yaml file that we have we like to call this a quote-unquote non-governed solution we also have a governed solution so the main difference between those two is the governed solution you don't have to provide all your information about your tags because your organization already has a tag governance in place in in which case we know everything you know all your resources are tagged a certain way so for example if we had a governed solution here we would actually remove everything from line 25 down and this would be because we know that the resources will be tagged with a service and they will be tagged with an environment and we can dynamically you know as these resources come in via discovery or you know the first time that this is registered because you know we also do have like a regularly recurring scheduled job just to make sure you know anything changes but we are able to then look okay are any of my discovered resources tagged where you know the service is what i denoted up here and is there some environment tag is there one already created for it um if so great but if not if there isn't one let's go ahead and create it so that way you know this is more dynamic someone doesn't have to update this file as much they don't have to provide as much input and we can do it as soon as we see see it there so just say that raptive web you know it's been deployed to three different environments so far and they you know the organization introduces a new environment discovery picks that up we can automatically create that you know tag based application service without someone actually having to go in here and updating the yaml file josh do you have anything else to to add on top of that yeah i was thinking because i do actually wanted to act with that so from a design perspective and this is um this is something that i think might be cool for other types of things as well not just what we do here in yemen but is the the the dependency right across the organization and and what john just touched on as well right if we have a tagging standard and you know what tags exist and you empower and trust your teams to work towards the same goals of success and quality right then you don't need to do the validation you can just assume that if a tag comes in with an environment xyz and an application reference of one two three that that information means that it exists and you should support it right instead of saying oh no it needs to be validated we need upfront controls you ingest it you create it because that's the reality that you find it in right that's the basis of discovery driven or discovery based cmdb it's the same thing what's out there is reality that's what you're reporting and that's what you're reacting on so we take what we find and then you can put reporting and validation on the back of that saying does it make sense to me from a governed or oversight perspective is my second process honored monitor all that traditional ips and stuff but the key on this as well driving it this way is don't don't stop reality from coming into your cmdb just because maybe a process or a step must miss right knowing what's really out there knowing how it works knowing how it's tagged is most of the times for the things we care about here like event management and instant tagging and instant creation more important than that it follows a certain process and we know that enterprise architecture has signed off on it i'll get off my soapbox but that's kind of what i do wanted to get on the back of that right is reality is ultimately especially when it comes to the cmd the most important thing is it actually showing me what i care about still and they're abstracts or entities but doesn't work is it what i care about so what's that do we have i don't think we have other questions anybody who wants to jump in with a question i do um so how does a customer or a servicenow architect who wants to promote this to his customers actually use this functionality or you know last i looked you can't just go to the store and put it now.yaml and and start running it in your instance right what's what's the front door process for finding out more and you know potentially seeing this work inside an actual you know a customer's environment it's uh it is still currently wrapped as a services engagement i think to the point that john raised and that we kind of articulated there's a lot of choices you can make and putting those programmatically in a way that you could be a store app is we haven't found a good way of doing that right without creating a lot of maintenance overhead so it's still wrapped into services a lot of it is is ipcos it's just code that we bring with us um but there is a services component so like any services engagement we have anthony but reaching out to wrap up saying hey i'm interested would be the starting point for that where we can demo we can look at whether the environment is relevant um although you can probably do it yourself right and then from there either do a ideally a pilot setup we've got we find that showing that it works in production with a few teams maybe very controlled use cases but get it to work and show the value to them and show the value to your itsm teams but that's the best way forward so um obviously any questions is welcome we have a i think a sales rep right anything yep i just uh thanks josh i just dropped it into the chat to everyone you can reach out to sales rep dev.i oh and the the right person will reach out to you or you can just reach out to me directly and i'll get the right people involved yes and uh do we i forgot if this was 45 or an hour we'll is this do we have sometimes today okay cool yeah i don't want to break your timelines um because zach just updated and i think there's definitely uh zach just posted that might be cool to add some commands to yaml file or things that we can process um to uh to validate or control it's it's um that's definitely the case for us the let's say the journey around the now.yaml solution is is also continuous right as we work with new clients new requirements new ideas come up new ways of processing or implementing come up this is definitely an idea that that i would like to also extend say how much more can we shift left if you will into the deaf community where they take control of stuff that happens in servicenow within an automated scalable fashion so definitely a topic that we can we can set up and and and drive into because i think there's a lot of opportunity there to uh and maybe it's not just now the yml but other types of solutions that use a similar model where we can we can actually offer a great platform for appdev and devops teams to interact with servicenow in a way that there's no overhead for them there's value to them across the board both in validation keeping things up today but also the value like in event management things automatically getting assigned to them back into the jira right so there's a hands-off type approach but also for idsm to move away from we want to control every step to we're setting the we're setting the principles and the guidelines we're setting the processing rules like we do with devops right we set the policies for the change approval but we're not doing hands-on processes which frees up time reduces admin overhead so there's definitely a bunch of opportunities and and on that specific point i'd like to see yeah what we can do there too because that might actually be a pretty cool next step so mechanically once the solution's in place how does the customer generally work through things like platform upgrades um do they have basically a support relationship ongoing with rap dev so they upgrade to tokyo and run through now.yaml regression or whatever and then they need advice or or insight from you guys is that just an ongoing relationship is that how that functions yeah so what we've witnessed so far is you know we don't have the platform upgrades don't um have any negative consequences to us because we don't alter any sort of out-of-box behavior um you know we actually use the csdm classes that are there we're not using any sort of custom classes like that you know we're using the core components of integration hub um so you know there's nothing really custom you know because you're really running into issues right when you start customizing servicenow you know when the upgrades come in you don't have to revert then reapply your changes stuff like that we don't customize anything it's all code that's built on top of what's already there and we utilize you know a lot of out of box scripts yeah so you guys are basically your own scoped app i mean maybe not exactly it comes in as a scoped app and you're kind of self-contained exactly yep it is its own scopes app nice literally and and the only thing i want to add to that because of the variation of implementation so far and because we do it as a services engagement there's two benefits to this um one for that one if you put it in your organization above i did see your ends i'll give you a second but is um the the code after it's deployed belongs to your instance right so if you want to make changes or updates or whatever that's your prerogative can't resell it necessarily right because there's some other things going on but the code in your instance is your code right so if you want to take it to the next level or you want to do other cool stuff to it or less cool stuff to it that's for completely your prerogative um to john's point we haven't run into upgrade issues but if the csdm changes um i mean that would be if you if your own team can't solve it or your platform team can solve it and obviously we have services there but that would be just a services engagement because again once the code is in your instance it's in production it's yours to do with and that's one of the other reasons why we haven't looked at productizing it yet because there's too much variation um maybe if the world standardizes a little more across these things so maybe a few more years of digital uh a transformation you might be in a spot where it makes sense to make it a story but that's the consideration right cool yeah and uh i think bob you had your hand up so yeah sure you reiterated it it's part of the service's engagement but um i'm assuming the feel the particular fields in the yaml file those are flexible or are they kind of hard-coded like i see john's checking his head yes so i assume they are flexible okay uh yeah and then two my second question is more around the ocm factor um you're gonna you're gonna provide this emo file to a development team they they consume it but i'm assuming it's pretty standard like what's like them actually using this yaml um what what's the quick like is it a quick turnaround for them to learn and use um and i'm thinking at a scale perspective right not just one dev team but some of my engagements there's you know hundreds of dev teams right so kind of talk about the scale of it if you don't mind uh i'll take it off and johnny you'll fill in uh basically so the the the ease because it's a yaml file and adding annotations that are customer specific seems to take away a lot of challenges so far in our experience right so as long as the file is annotated as part of that deployment with values or references that make sense to the developer community um we've not run into any real ocm challenges on top of that it is tied to the standard devops community so we work when we implement this not with the not primarily with the itsm team i should say or the configuration management team or the second team whatever it's called but with your devops community or with the devops community so um and usually from uh from at least a leadership or remit leadership down so we have the people that drive the direction um typically have that quick communication have places where they share knowledge right over slack or in ocean or um some atlassian tool right somewhere they're keeping this data so so typically we find that because of the character the nature of devops there's not a lot of issue with getting this file deployed or getting developers to understand how the file should be used right between annotation in the file and context and knowledge references in their in their documentation tools it's not a guarantee but so far is that's what we've seen yep yeah and also if we are doing this on top of the actual devops product implementation too it's an added benefit incentive for developers to actually you know start using this because when we are doing this a lot of times these microservices don't exist currently inside of the cmdb right and what we do with you know the actual devops product implementations we are automatically creating changes through your ci cd pipelines and you know we have to have a ci attached to those changes the ci that's attached to those changes is actually usually the production environment of the said microservice which gets in there from the actual now.yaml so for them to actually use this you know new process of creating automated changes them not having to go into servicenow to log you know every deployment that they're doing it's an added incentive for them to come on to this process yeah thanks um something else i'm i'm just thinking out loud here uh around ephemeral ci's ephemeral resources right hey the server the service got spun up and i used it for a couple hours i'm just gonna you know decompose the whole service do you guys kind of like have a way to maintain like hey yeah we spun this up and then maintain a state right um like hey this is an operational state and then hey this has been in a i don't know off state or whatever whatever this state is like so as part of your yaml there's a there's a read and hey i'm going to insert records is there a way to kind of keep keep the life cycle of that service [Music] any any thoughts there there is a um there's a non-linear so that's so typically let's start there at this point so creation of the services and updating the data around it is that one direction what we find in terms of femoral workloads is can be flexible right so we can't really use um discovered information to drive the status of the of the the specific application service belonging to an soc component or microservice because a microservice could be operationally dormant while it's still in use because it's in its function it's only going to work two weeks a year type of thing right there's only a demand for two weeks away there's so there'll be a definition but there'll be zero resources potentially um you'll probably have services but it kind of depends on the tagging strategy so um so we we can't really use discovered data and to decide what the state is currently it's um it's kind of based on aging out so if the repo maybe the triggers are typically if the repo gets get closed out or decommissioned or the file disappears those are triggers that we could then use to change the state of the sclc component but it's really on the services definition so the sdlc and the application service where that's relevant not necessarily tied to ephemeral workloads or cloud resources in general yeah that's fair thanks for the comments i think we said we have four more minutes i don't know if there's any any other questions or concerns i think we uh um anybody have ideas maybe that's something that is a closing question everybody who thinks that some of it even if it's nothing not our yard like evil solution but something that they picked up they go i'm gonna try and work on that in the next couple weeks try and see if i can tinker something around nope okay i think we're i think we're done we've run out of questions so yeah thank you yeah thank you for the participation it will too and thanks for everybody for the questions it was really good i like the interactivity of the question so awesome thank you yeah thanks as always to all of our attendees for keeping things lively and interesting this is uh for for both mike and myself this is like our best day at work every month just being able to uh you know share experiences lessons learned find out about cool new stuff like now.yaml um as always we will uh send out a a wrap up which includes uh invite to our to our next session uh next month on the 25th of august um [Music] yeah if there's uh no additional questions uh please do fill out the exit poll on your way out and have a great rest of your week and wrap dev guys thank you so much this has been super awesome and again to reach out um either you know if you're interested in finding more out about now.yaml uh anthony posted the the two direct emails or you can always work with your your servicenow account team to pursue it further thank you mike for having us awesome thank you thanks everybody