hi my name is mike gallagher and i'm an advisory solution consultant on the it transformation team here at servicenow and i want to talk to you a little bit today about the application lifecycle on azure kubernetes service so what we're seeing in the marketplace is a significant amount of friction between central i.t teams who operate in a more traditional operational model and devops teams that are looking to uh move and to mode to modes of operation and and much more kind of modern and agile and what what's going on is the central i.t teams really need to be able to manage the infrastructure components and to be able to provide governance and visibility into the infrastructure components of the services that are providing value to the organization and what we're seeing is on the development side that's causing a significant amount of pain in the process because of those governance and controls we're seeing very very long times to be able to deploy changes into the infrastructure and to be able to create the value that they need to and iterate quickly so what i'm going to show today is a bit of a melding of those two worlds that really gives the central it teams the ability to deploy and manage an azure kubernetes service cluster with governance and then allow development teams to consume those resources in a more agile fashion while still adhering to some governance policies and still enabling the visibility of the entire technology portfolio wherever that technology portfolio may sit what you're seeing on the screen right now is our cloud portal within the cloud provisioning and governance service so i'm showing you an arm template that can be used this can be published into the service catalog and and users and development teams can utilize this arm template in order to deploy an azure kubernetes service cluster that they can begin to consume and the great thing about that is it allows us as central i.t teams to provide governance around how that's deployed where that's deployed what resources are utilized and and then ultimately allow folks to consume that in a modern operational manner so i'm not going to actually click through this because i already have a kubernetes service deployed which is here so i have this kubernetes service cluster that is deployed and you can see within within azure are some great tool sets to look at what the various workloads are that are running the services and ingresses and the various namespaces but it doesn't provide that central viewpoint on the entire technology portfolio within an organization which is really what discovery and service mapping are intended to do for organizations so what we need to do is we need to hybridize that and bring this more modern information into the cmdb in order to be able to map out these more ephemeral resources and understand the value that they're providing to the organization and provide governance and management around them while still enabling this more modern iterative application development so to that end i have built this azure devops project called modern ops that is connected to that azure kubernetes service that i have deployed and within this project i've built some repositories that contains all of the yaml file manifests for all of the applications that are deployed within that azure kubernetes service and i've also built some pipelines that when these are updated the pipeline triggers and will go and deploy the manifests in order to update the applications that are currently running on the azure kubernetes service so if i choose to i can come in here and you can see that this is the manifest for the front end deployment and this currently has this replica set to three which means that it's going to be running three pods for this service and i can actually change that and scale it up to be four or five pods and once i do that my pipeline will trigger and it will tell kubernetes to go and deploy more of those pods and scale it out so let's do that now so we'll edit this and we'll we'll set this to five replicas and we'll go ahead and commit that and scale to five replicas i'm gonna be good and provide some commit notes here and what that's going to do is that's going to trigger my pipeline and you can see that it was triggered just now but while that runs i'll show you a bit about the kubernetes service on the platform itself so we've got this dashboard overview that shows some information about the kubernetes service that is being gathered by the discovery process and we'll talk a little bit about discovery schedules but for now i want to show you uh that service as it's actually showed within uh the platform itself so this is what we call the operator workspace and it shows all the services that we've defined within the platform so i can show you the service details for this itx next gen app which is the this is a tag based service which is built based on the labels within kubernetes to automatically build the service and here are all the cis and i can actually show you the service map and that will map out all of the different kubernetes resources that make up this service based on the kubernetes labels so you can see we've got the we've got the front-end service here itself and you we have one two three front-end pods that are utilized to provide access to that service so what we've i just got an email saying that my pipeline was completed and we can go here and look at the status of the pipeline we can show that it was completed and all stages were successful so now what we can do is we will see the standard process for discovery is that we do a nightly discovery of most things but because kubernetes generally utilizes ephemeral resources we need to use what's called event-driven discovery that runs on a regular basis and it looks at all of the events that have occurred on the kubernetes platform and actually updates the cmdv based on those events that are occurring so the way i've got this set up you'll see i've got a discovery schedule here that runs daily that just ensures we have a good solid understanding of the the entire kubernetes infrastructure on a nightly basis and then i have this events schedule that runs every two minutes and pulls the events for the last couple of minutes and updates the cmdb with that information and then after that it updates the tag-based service mapping to ensure that we can see all of those resources that need to be mapped together based on the kubernetes labels that have been applied to them so let's go and look at the tag based application itself for itx next gen so we'll come in here and you can see that we've actually got this set as a somewhat critical business service and it's currently in operational status and what i'm going to do and rather than allowing the service to be recalculated on the normal schedule i'm going to manually recalculate that service and now when i go and view the map the service has now actually been updated so we've got the front end service here and we've got the pod one here and pi two there pod three there pot four there pod five there and you can see all the details of the service and everything that's been updated and gathered by the discovery process and now that we have all of those services mapped we can manage it just like any other traditional service that we already manage within the platform we can look at the details of the service and we can look at the related cis in the exactly the same way and these will be regularly updated in a near real-time basis based on that tag-based service mapping and the event-driven discovery we can manage it with change management processes just like we do with the rest of the services so this is a great melding of the the more mode two style of deploying code and deploying infrastructure while still enabling the visibility and governance in the standard common operating model that we're all using today so this has been a very high level overview of the application life cycle of an azure kubernetes service i really appreciate your time today and have a great day