seemed appropriate to hold the first you know beers with engineers session on a st patrick's day it just means that you know my first choice for beer for for this session is gonna have to be guinness so which could be worse and of course with a name like gallagher i have to have a an irish pub mug so that's a requirement for today all right so we'll go ahead and get the get the party started here um welcome to the first installment of the cloud native beers with engineers we're really really excited about this series and really looking forward to connecting with everybody to really talk about and understand where you are in your cloud native journey today and how you're utilizing servicenow to help kind of manage and drive that cloud native journey and how we can continue to drive that and and help enable the capabilities within servicenow to help you continue to move forward along that journey so just really quickly we'll start off with just a real high level agenda and a couple of uh housekeeping items and then we'll kind of dive into uh the the main meet for the day so uh first of all we're gonna talk about why are we here what are we doing we talked a little bit about that we'll dig in more um we'll introduce will and myself talk about our backgrounds a bit and why this is important to us then we'll go into our tech deep dive session for this month which is around building a containerized mid server and deploying it into kubernetes infrastructure and then we'll just open it up for some questions and answers right let's do a little workshopping you know let's talk about um where you guys are at and what you're working on and if you're having any challenges or any questions that you may have around this you know this is the time and the place to do it so a really key thing here um is we'll we'll just talk a high level why are we here right so it's it's really to bring together and build a community of servicenow customers who are at a similar place in their cloud native journey and then talk about how you're using servicenow to manage your cloud native technology portfolio all right and when we mean cloud native technology that's really the the cloud native computing foundation's definition of cloud native technology right this we will at some point probably get into some um you know serverless function conversations and micro services specifically um you know today we're really focusing heavily on um containerization and containerization of the mid server itself so with that i'll kick off kind of the introductions of who we are and and why we're here talking about it so myself mike gallagher um i am an architect in the commercial space in the um the technology workflows business unit here um my background of 25 plus years in technology i tell everybody you know if it's if it you know runs ones and zeros i've probably had a hand in it at some point right i've done everything from software development to database administration to you know managing ops for a cloud provider here in denver to vmware tam prior to coming here servicenow so i i love technology i tell everybody i have an invisible propeller right and i love using technology to to solve business problems a little bit of a side note uh i am heavily invested in training brazilian jiu jitsu uh and playing board games with my family those are my those are my big kind of side passions will why don't you introduce yourself hi my name's will i've been with servicenow for about a year before that most recently i worked for six years with servicenow customer where i did a lot of a lot of cloudy things and automated a lot of cloud things using servicenow i worked in one form of technology the other for over two decades um and in my spare time i enjoy hanging out with my family and um playing recreational hockey awesome all right so also really quickly before we jump into the deep dive i'll end the poll and kind of share the results right so this is wonderful right because we have a great mixture of folks who are hey we're looking at kubernetes right now we're learning a lot about kubernetes we're actively implementing things and also you know we have customers who are you know kind of looking into uh you know kubernetes as an organization and also doing some experimentation so this is this is perfect right this is exactly where we want to be we want to have folks who have a kind of a mishmash of that experience and can help talk through uh where they're at in the journey for today and tomorrow and and help us really help you get better along that journey so you know who we are you know what the goal of the series is right now let's let's dive into the tech deep dive right so so today we're we're going to be focusing in on deploying and building a containerized mid right this is something uh that at least for me has been kind of a pet project since day one when i started at servicenow right kind of the first thing i did when i looked at it mid server i was like man i wonder if we could run that in a container right and and now starting in rome uh we now provide a docker file for building out a container image of the mid server and um and now you know in our in my blog post that i put out last month i've talked a bit about how to how to use that how to publish it into a container registry and get it in that's a bit what we'll work through today and then will just posted a blog post earlier today about how to put it into a ci cd pipeline and have that automated build process because will's all about automate all the things right now let's take the next step and automate everything so let's talk about why you would want to do this in the first place right so we don't at servicenow provide a a pre-built container image right we provide the docker file that says here's how you go and build a a docker container of the mid server but we don't provide the pre-built image there's a couple of reasons for that if we if we provided the pre-built image we would have to put it out in a container repository and make it publicly available and that's yet another sort of management overhead on our part but the other reason why we don't do that is this middle bullet point here many customers are very restrictive around hey you can't deploy stuff from any old container registry on the planet into our production kubernetes infrastructure right so in a lot of cases a lot of customers were saying hey we're going to have to go and build this ourselves and put our own container registry anyway so why why should we go through the extra effort and then the other reason why to do the build right is to really ultimately putting it in a container and deploying that container inside of your kubernetes infrastructure gives you the ability to discover your kubernetes infrastructure with a very close proximity between um [Music] the kubernetes api that we're using to to enumerate all the resources in the kubernetes cluster and also it its long term will dramatically simplify the authorization and authentication process between the mid server discovery process and the kubernetes cluster it's generally kind of a best practice that way then you also don't have to expose your api endpoint to external traffic for us to do discovery because the mid server is living inside of the kubernetes cluster itself so um thanks for jumping in on the chat i forgot a couple of quick things you know feel free to use a q a if you have questions feel free to drop questions and chat um if you want to you can raise your hand we can have you come off mute and ask questions one quick important thing is this is really your time so don't hesitate to dig in and ask questions at any point so so let's talk about the process how do we go about building out this container and deploying it into kubernetes cluster right so at a really high level you build and publish the container image which i'll show i'll show that process here generally the recommended methodology is to then build a namespace dedicated to the the the servicenow components so that way we can keep it all in that one kind of logical container then we build a secret that enables the mid server to [Music] to you know much more securely access the username and password that are being utilized for the mid server to log into your servicenow instance and then we configure a deployment manifest which is you know yaml file for deploying the container into the kubernetes cluster and then we actually deploy the mid server and go through and validate that it's all there so i'll actually kind of walk through that process right now and show you what that looks like and and then we'll go from there so let me switch over to start off with if you're not familiar so will posted a link in the chat but definitely please go and look at the servicenow community both will and i post blog articles on there fairly regularly and there's a lot of great content in there as well so definitely make sure you're checking in on that on a regular basis so here is my new san diego instance that i'm deploying my mid server into this is a nice new ui if you haven't seen that yet it's quite nice so you'll see there's no mid servers deployed here yet today so what i'll do is i'll go switch over to my my terminal my command line terminal and what i'll do is i have in this directory i have downloaded the the docker file that we have provided from servicenow and if you want to get that link from the platform you just go look for downloads mid server downloads you'll see here's the linux docker recipe 64-bit i just copy that url here go back here and wget that that url i won't re-download it and spend a bunch of time but that's what we did i downloaded that here and then i use the azure acr which is their container registry capability so i use the i've installed the azure command line toolkit here and then i say build the image i want the image to be called the kate's mid kubernetes mid right and i want it to be published into the registry called kubernetes mid and i want you to use the documents in the local folder in order to build that sorry i forgot to explain a step you have to unzip that file first once you unzip the file then you'll have the fully populated directory in order to do the build so now if i hit that we won't sit through the entire process we can kind of look at and talk about a few things as it's going but what that does is that takes all of the information that's provided in the docker file about here's where to go get the various components in order to do this build here are all the things and it's going to actually push it up into the azure container registry and it does the build on azure's compute stack it doesn't i'm not doing any of the build locally here for a couple of reasons one some customers don't have access to docker desktop or the ability to like run docker to do builds locally on their machine so i wanted to have something that's a little more kind of enterprise ready and use the azure container registry the other piece is this enables me to really do the build and the push kind of all in one command line all in one go so while that's going on there in the background i will show you the yaml file that i use in order to actually do this deployment so it's pretty straightforward in one file what i'm doing is i'm building out the servicenow namespace and then i'm deploying that mid server into that service now namespace and i'm telling it hey go and get this image that i just built right use and this tag here this latest is saying hey go get the most recently built version of that container and i'll show you on my azure portal where to get that right so you go to the azure container registry which is i've got this is actually sorry this is the resource group that i've built and then inside of this resource group i have this kate's mid container registry and then from there each image that you build on azure side of the house is called a repository right so i've got this kate's mid repository here and then here is the latest tag that i've built and then this is the url that you use to access that that built and published image once it's been pushed out into the registry so let's go and check and see it's probably complete by now so what it's done is it's pushed everything up into the container registry and now it's going through and now it's actually downloading the additional components that are needed to be layered in on top of that container in order to get it built and up and running so i already have one out there right now so let's just go ahead and deploy this existing one and then we can jump over the cicd pipeline in the interest of time so if my container excuse me if my kubernetes cluster wasn't already configured to connect to that container registry i would have to run this command here to say hey i'm going to i'm going to update my kubernetes cluster called kate's auto scale that lives in the kubernetes mid testing resource group and then i want to attach it to a container registry and this is the container registry name that i would use i've already run this for my kubernetes cluster and that takes about five to ten minutes so i'm not going to run this now live while everybody's watching so but if if you don't already have that done you'll need to provide that connectivity so that your kubernetes cluster can pull stuff out of that container registry but since that's already been completed i'm going to go ahead and apply that gamma file and what that's going to do is that's actually going to go out and create the namespace if it's not already there and then it'll deploy the mid server there's a step in the middle where i have to create a secret to provide at the password but i'm not going to do that with everyone there because online now because it actually shows the password clear text when i build that secret so i'm not going to share that as of today that being said it has now created that deployment and then we'll go and see so i have built that and put it into the servicenow deployment it is currently in a container creating process which means that it's actually um it's actually trying to pull the container from the image registry so it's okay it's it's pulled it it took about 24 seconds and now let's it's up it's running and let's go back to my instance and go find oops actually let's go to history really quick mid servers so now it's up it's up it's deployed and if we want to if we wanted to actually go and run discovery with this containerized mid server we'd have to go in there and we would have to go and validate that mid server to make that as a viable option any questions about that comments thoughts q a is all clear all right sounds good so what i'll do um is i'll i'll stop sharing and now let's go into uh phase two which is let's uh let's do the extra credit let's put it into a ci cd pipeline and and see how that works so we'll won't you talk about that and then i'll stop sharing you can walk through the process so um when mike's article and community came out i immediately jumped over there and started you know following his instructions and i kind of had two thoughts as i was going through the process one was this is really not too difficult it's pretty straightforward pretty cool but then shortly thereafter i thought to myself well do i want to do this a few times you know a few times a week or maybe a few times a day if i'm really actively testing something not so much um so you know a a great way to automate repetitive build type activities is ci cd and so i've actually successfully put this process that mike outlines in in his blog article through a couple different standard ci cd patterns the first one i played with was jenkins then i moved over to use um the amazon product which is their whole code suite of tools code commit code build code deploy and what i found is that this process really fits into any ci cd toolset with minimal heavy lifting where i finally settled was in azure because in my experience if you've got to set up one mid server it's going to be a windows box just because everybody's got some windows out there that they need to either discovery discover or automate or both and that requires power shell and today if you want to do powershell things you've got to have a windows knit windows on kubernetes is um it it's got some unique character traits and so the easiest way to do that today is in azure because you know it's microsoft so azure has a very slick implementation of ci cd which integrates quite readily with both their kubernetes solution as well as github which is also owned by microsoft and i like storing my code on github so that kind of already gave me a leg up in terms of automating things so let me go ahead and show you what that looks like that's not the right screen i see adl mid images you see a um terminal window yep okay perfect yeah zoom's a little interesting with sharing it's got the banner over on my other monitor so i kind of picked up with the process mic outlined right after we download that zip archive from our instance and then unzip it so i'm in the directory that results when you unpack that zip file and so then what i did was i just turned that into a git repo and pushed it over to a project in github then i created a brief yaml file which is used by the azure devops pipelines it basically tells azure azure devops what steps to perform to to build your image and it's it's pretty abbreviated um we tell it that we're going to use a windows 2019 image as the basis that's basically going to be the engine on which your build steps execute and so similar to the need to have secrets stored within kubernetes so that when your mid server spins up it can authenticate to your instance i needed to create some similar constructs within my devops pipeline so that the build process could authenticate into the azure container repository to be able to push that image up when it was done building so in order to do that i just use the built-in capability of azure devops to store variables so i created a little group named docker vars and it's just key key value pairs i've got my azure service principle identification that's in plain text and then the things i don't want to be visible are stored as secret type values and then i just plugged those in to my build instructions as needed so for example this step here authenticates the build process into the azure container registry and then i've got docker secrets stored in there as well just because i wanted to make this somewhat general purpose and sometimes there are images which need to pull components from docker hub so i just wanted to have that ability in my back pocket if i needed to pop it in there in the case of building the the windows mid image it pulls everything from the microsoft container repository so by doing this what it provides a couple things one is it it essentially makes your mid server configuration resident completely in code so an example of that would be in some cases we need to you know our documentation covers ways to tweak your mid server configuration sometimes depending on the workload that's on a mid server you need to increase the java memory for example and for a traditional mid server that's accomplished by modifying the wrapper override file and on a traditional server it's easy i'll albeit tedious you log into the server you go to the appropriate directory you edit the file and then you balance your mid service when you're decoupling the mid service from an actual running server and you're running it as a container you have to have a little more control and forethought into how you do that because you can't just log into a container necessarily so the way i did that was just navigating into the code so what i'm looking at now is part of the payload that's delivered by our docker recipe that's downloaded off your instance and so one of the files that it executes is uninstall in this case i'm still on the windows image so it's running an install powershell script and then when i looked at that install powershell script i can see that it's already got a line where it's modifying the wrapper params that are going into the mid server config and so all i did was i i just added my own line to tweak the java memory and so now because this image is being built as part of the ci cd pipeline all it takes to have that take effect is i just push this code up to github which then kicks off a build that will look like this so this is just a build that ran especially with windows the build does take uh you know takes a few minutes so i'm going to kind of do this cooking show style and show you what it looks like rather than have us all sit and watch kind of watch the equivalent of paint dry and so this is an example output of all the steps that are performed by the pipeline and they're invoked automatically as soon as my modification to that java settings is committed through you know if you're if you're talking about an enterprise environment generally you know code changes go through a standard review process and the code gets merged into the git repository at that point it would automatically kick off a pipeline excuse me similar to this run through all the steps and then report success or failure at the end and then one of the great things about kubernetes is it's got resilience built into its dna so instead of having to kind of log into a windows server and bounce a service all you have to do to balance your mid server is just you just delete it and then the mid server will reinstantiate and if the image has changed in the meantime it'll just pull that image down by default and immediately launch and then you'll see it show up in your instance once it comes back online another benefit to incorporating this into the cicd pipeline is as you may have experienced when you upgrade your instances or when your instances are patched they that comes with it a new mid uh you know new mid install payload and traditionally what will happen is when you start up a mid server and it calls up to an instance which is higher patch level it'll automatically upgrade so if you have kind of a static container image which is not at the same patch level as your instance then every time one of those starts up it's going to take a little time to perform that upgrade process during which it's not really usable as a mid server so if if the desire is to leverage this to provide a more elastic mid server infrastructure say spin up a bunch of mid servers to do discovery during you know a particular window and then decommission them shut them down when the discovery is over that startup delay which they would incur as part of doing that auto upgrade could potentially you know that could be impactful that that could be sub-optimal for the use case and so by putting this into a ci cd pipeline it gives you the ability to just up just update the image kind of behind the scenes automatically such that when you bounce your mid servers or when you spin up new mid servers the patch levels just come up in sync automatically you don't have that that startup delay occurring um i think that about covers the ci cd stuff as as mike mentioned there is a blog article out there i put the link in chat and um would welcome you know any any feedback on that any further questions or uh you know lessons lessons learned that that you folks encounter as you kind of start taking advantage of this new capability excellent so let's uh let's shift gears and at this point i'll go through and make sure everybody has the ability to unmute um because really the next the next phase here is for us to work through kind of q a and workshops um and and any questions that you guys might have or might want to dig into right um do not hesitate to uh come off a mute we'll just make sure everyone can i'll just go through and give everyone the ability okay so questions thoughts comments anything that you'd like to share up to this point even unrelated to just the mid server build hey i'm uh jim mackley here on the server in the cloud build you ever try to incorporate like a third-party vault system like cyber arc or hashicorp how would that work or did you even try to play with that during your exercise there i actually did when i did the um when i did both the jenkins and the amazon code build approach i stored the secrets in um in the aws secrets manager okay and so really all i had to do was just slightly modify the you know modify the little build script so that it pulls you know makes the appropriate api call or cli runs the appropriate cli command to pull the secret in and then pull it into an environment variable i mean that's the other nice thing about um leveraging some of these build services is because the build infrastructure is ephemeral you don't have the same concern like say you're doing a traditional jenkins build right it's a traditional kind of static jenkins server or even a jenkins you know agent that's out there running on a more permanent server you've always got that nagging concern right that somebody could if somebody pops that server they could observe you know they could they could watch for process listings or interrogate the environment and potentially get secrets out of something while it's running whereas you know using these build infrastructures where it's essentially containers under the covers that it's using those are very locked down nobody could log into those to like see what's going on so storing you know a secret briefly as an environment variable as part of a build pipeline is much less of the um much less of a concern if you're doing it on a server that would otherwise be you know open to ssh or rdp even if it's only to support personnel so i don't want to make it yeah i'm answering the right question you can plug it into um you know all these tools really are coming through with really good apis and it's really um it's it's been quite refreshing how easily you can drop something like this into into one of those tool sets and from there on it's like lights out you you commit your change and then you just look for that green check mark to show you the build is completed versus having to go through a bunch of manual steps yeah that was my question are we talking about injecting the jar file for the credential resolver for the mid server to be able to connect into one of those um credential repositories is that what the question was oh double muted yeah that's exactly what it is okay i have not played with that um that being said though i don't believe that would be terribly difficult right that would just need to be another layer in the in the docker file where it would pull in that credential resolver and configure it on the mid server okay that's that's correct the docker file um so in the example i gave where i updated the um the java memory settings that was they they already provided a hook to do that in the in the kind of out of the box powershell you know install powershell script but because we provide a docker file if you do have additional tweaks that you would normally do on a standalone server pretty much any command that you would normally run manually you can encapsulate into that docker file and it actually just does that as part of building it so that you'll end up with a container image that has you know the the appropriately updated jar file if need be okay great thank you yeah so like here's here's the docker file itself right you'll notice it's just got some commands in here that says like hey you know run run this apt get right or copy this thing from that thing so i could easily see adding a section in here that just says you know kind of at the tail end here right you know run w get and pull down that that credential resolver jar file and put it in the appropriate spot i i have to admit i'm not super well versed on where that jar file goes but you know i can easily see it hey pull it down drop it into the right place and get it ready to go from the mid server perspective and then it would be right there as part of your ci cd pipeline okay thank you yep no problem great question thank you jim oh darshan says you also need the cyber arc agent in the container interesting so yeah i mean again if it's you know in whatever form that agent takes if it's a tar archive or if it's a standard you know if you're talking linux if it's like an rpm or a dev or ap um you know an apt as long as it's available to your build pipeline you can incorporate that in the docker file if um it does get a little more involved if you need to set up in ingress network ingress yeah so you know by by default outbound packets are generally not an issue you know you saw my correct if i'm wrong you don't have to do anything special with your cluster to allow that outbound mid server connectivity right to your just yeah whereas if you need if that agent needs to accept inbound connections which i'm not i'm not familiar with that piece of the cyber arc architecture so i don't know whether that's the case or not if it's outbound then other than putting the um you know putting the agent out there and ensuring that it's set to start up as needed as part of the docker file would be all you need if it does need to listen for you know some centralized cyber arc you know server to kind of reach into it then that deployment yaml file that mike went over might have to get updated to actually include like a service or an ingress that forwards basically it would that just forwards that traffic from an external port that the cluster the kubernetes cluster hosts to the the mid container which will be listening on kind of an internal network on uh you know kind of a random ephemeral port number and but other than that it's you know that's it's really it's what kubernetes is built to do honestly it's just on the ingress side it is you know by default it's kind of secure out of the box so it doesn't open any ports you have to specifically identify what ports you want to allow to come into you know each container or each uh each pod in kubernetes parliaments yeah and i was just looking here okay perfect thanks patrick please check the chat we're gonna in about the next uh about the next five minutes or so we'll we're gonna kick off another poll so please make sure you you respond because um we're gonna randomly select somebody in that poll to donate a hundred dollars to the charity of their choice so i'm just looking at the the cyberark install documents now and it looks to me like it's an rpm right that you could just kind of download and install on that container image and and then configure it and get it up and running seems seems reasonable just needs to be just need to add these commands into the into the docker file in order to ensure that that portion of it gets pulled in and built out so other questions is anybody let me ask you is anybody doing discovery of their kubernetes infrastructure today i know i think jim you and i have talked about it in the past right yeah we're at private cloud right now but hope to um to go to public soon yep and we're seeing a lot of that so one of the things sorry go ahead again okay i work for jim um so we're discovering uh labels currently on the pods and services who knows there's a way we could also discover the annotations so i was just doing some work in the kubernetes pattern today and i did notice that it is querying annotations but the specific thing i was looking at wasn't that so i didn't really follow you know follow the thread i will make a note to check on that it does i know it's querying them but i didn't i i don't know what it actually does with them after it pulls them in via the pattern so it pulls a 10 but it's not populating those in the cmdb key value table so looking at the pattern it seems like it is being collected but it is not being parsed and collect or populated in the key value tape yep i've made a note to check on that um one thing i did notice is that sometimes the kubernetes pattern needs a couple tweaks to get optimal behavior uh for example in a lot of my test environments i noticed that out of the box they would not come up discovering uh yaml files so there's an extension that's part of the kubernetes cluster pattern that pulls down deployments demon sets staple sets and services in yaml form and stores them in the tracked config file table in your cmdb which is really i think it's really useful because it lets you hold two iterations on that yaml payload side by side and see exactly where they changed and for whatever reason sometimes that extension is not enabled when you first start using the kubernetes pattern so it just doesn't you know just so i just turned that on and then all of a sudden getting all this valuable insight into how the yaml content is changing on my cluster in those four areas and then i've also played with extending that and it's actually fairly straightforward to extend that to other kubernetes objects which are of interest um so because of that i if if you're not seeing annotations come in it could just be we need a little to dig into that and it could just be something that's not some step that's not turned on by default or some something of that nature that we need to uh that we need to tweak i would say it's definitely worth making sure you're up to date with the latest star release of patterns because especially in the kubernetes area i've noticed that they've made some significant improvements like with the naming of the uh of those track ammo files just you know from one dot release to another so it's definitely worth making sure that you check the store periodically and see what the latest version of the patterns app is for um for pulling in your your kubernetes cluster stuff but i will check on that and follow up with my findings all right not another question there um so is there is there a better uh clean up procedure or is there any recommendation of a cleanup procedure by cleanup you mean um when stuff gets down like a pod like if a pod goes away correct um so what i saw was that pods that disappeared were getting cleaned up when i would rerun the schedule i did have some isolated instances where that wasn't happening which i attributed at the time to the fact that i'm running all kinds of different versions of the pattern because i'm doing a lot of testing i'm in a lab environment primarily as opposed to a more you know stable production or even even a real you know robust dev environment so if you're seeing are you seeing just nothing ever getting cleaned up right now or is it just that you okay yeah nothing's getting cleaned up for docker containers and pretty much everything right and even the ones the new pods that got populated or containers that got populated had no status as well and there so that was kind of a little shocking for me um what do you do you know what version of the patterns you're currently running that's fine if you want to follow up with uh with an email our emails are in the uh slide deck which will get sent out if it hasn't already gone out um yeah let me know what version then i can kind of dig into that a little more like i said i have seen that but when i went to kind of a pristine instance put the latest patterns down there and then ran deleted pods and then re-ran the discovery my experience was those things were getting cleaned up so if you're having cleanup issues and you're at the latest um the latest patterns then that we may just need to open a support ticket because my understanding is it should be cleaning up you know when it discovers a pattern i mean when it discovers a cluster if there are pods that are associated with that cluster in cmdb and they're no longer on the cluster those pods and then the kind of cascading down you know down to the container a container image that stuff should be getting cleaned up yeah agreed and i think that's the standard behavior out of the box now right but i think well actually let me uh just amend i don't think they get deleted they get marked as uh whatever it is offline or um you know retired or whatever yeah we generally don't delete things like that they i think they might get marked as exited but that's also we were not seeing that all of them were marked exited so and we are at the latest pattern i upgraded it to whatever the dot eight seven latest one eight seven okay yeah i'll do some more testing on mine and i'll i'll kind of specifically spell out what i'm seeing and then we can compare notes and determine just to determine whether you're seeing something different or if what you're seeing matches what i'm seeing but that's you know leaving gaps for you and then we can take it from there sure sounds good thanks yeah great questions folks we've got some more time here anybody else have questions anything that they'd like us to cover really quickly okay side note for me was this the first time any anybody has seen the uh the san diego ui mike do we need another poll right we should have um another kind of fun one that i've been working on here let me show you this really quickly um since we're all here yeah yeah john it's kind of it's it it's a pretty big departure from where we've been i'm i'm very excited about kind of the future here um one of the things that i've been playing with i just installed this so there's not a lot of data yet but is the new cloud operations workspace so this is a a newer kind of streamlined workspace to give you you know kind of a snapshot of what's going on across discovery so you can kind of jump in on you know here's your here's your cloud discovery pieces here's all your various schedules and you know what errors they're running and those kinds of things um i'm really excited to see this kind of take shape and grow because there's a lot of um the new ui has a lot of value i think so it's gonna smooth things out for a lot of folks okay so um we have five minutes left one other thing i did want to quickly kind of talk about is where we're going next month so next month you know to today we talked about hey here's here's how you can build out a containerized mid server but now as of san diego there's a new capability to automatically deploy and configure mid servers uh from kind of an a a like a template essentially so you will be able to say hey here's the yaml file for deploying mid servers in my kubernetes environment and then you'll be able to say hey i need five mid servers go and it'll go and deploy them all and it'll get things up and validated using the um the mutual certificate validation which i'm also really excited about so in between now and then we'll have a bit of a blog post to kind of talk about that and show how that works but we'll also do some deep dive on it next month as well you'll also be getting a a poll here after the meeting closes to say hey what are the other things that you'd like us to dive into right are there other topics that you'd like us to kind of like pick apart and get into and then we can go dig in there and see what is most interesting for everybody else we've got about five minutes left will did you have anything else that you wanted to add before we close out um i just had a follow-up question on the the san diego stuff if i remember correctly the one of the kind of the big benefits to the template-based mid deployment is you can actually with that you can have the mid automatically validate is that accurate that's correct right it uses the it uses the tls based mutual authentication between the mid server and the servicenow instance so as a result it comes up automatically validated there are some caveats to that you know you won't be able to do configuration of the capabilities once it's up you have to sort of define those capabilities at first and then um and then if you need to change those capabilities you'll need to deploy again and and retweet it thanks jim much appreciated excellent well we'll give you guys four minutes back in your day have a phenomenal st patrick's day everyone make sure you go enjoy a frosty beverage and we really really are looking forward to seeing everyone here next month for the next session we'll get invites out for that here shortly please you know drag anybody and everyone who you think that this would be valuable for we really want to make this as much of a a cooperative community as possible excellent thanks everyone don't hesitate to reach out if you have questions and uh we'll talk to you all soon thanks mike