Create: DevOps

hey everybody welcome to create devops my name is jay gordon thank you so much for being part of this today i really appreciate it um we've got a great setup today uh hey marcus hey jay how's it going yeah um i'm really glad to have you marcus i'm going to see you a little later all right hey stephen how are you today doing all right doing all right and how about yourself jay great good you know thanks i'm doing all right you know i i'm really glad that we're here and we're able to talk to everybody about these these big ideas around devops so uh why don't we bring up what we're gonna be taking a look at just to get started so we can go ahead and set up the day so welcome to ms create devops oh it is great to be here i'm really looking forward to the lineup that we have today yeah i am too and we're going to go over all that right now we're going to bring up this so let's take a look at what we've got going on today sound good sounds good so obviously it's me it's steven uh i'm here out of brooklyn new york steven where are you coming from today i am just outside of milwaukee wisconsin ah very very cool well you know i'm a cloud advocate here at microsoft i uh i spend a lot of my time talking about infrastructure devops and i really appreciate everybody coming today and being part um steven why don't you tell everybody a little bit about yourself yeah so i am also a cloud advocate i am a principal cloud advocate and right now i'm on the cloud native team focusing on all sorts of fun cloud native stuff but i have a broad background in the devops space having spent time in in both dev and operational roles and i'm really looking forward to the content that we have today because i can't imagine something that is more transformative for an organization than when they embrace devops absolutely so why don't we go ahead and talk a little bit about today's agenda um so today we have an outstanding group of speakers from the devops community over the next few hours we'll have discussions about important subjects to ensure your success in implementing devops for your organization stephen would you like to give us a rundown of who's joining us today yeah i'll get us started here so we've got a great keynote opener from martin woodward from github followed by april edwards from microsoft who's going to talk about the importance of automation then we've got yeah we've also got donovan brown who's going to probably one of the heroes of devops here at microsoft uh and he'll be giving us a conversation about some cloud native after that we'll welcome kat cosgrove of palumi on a chat about security's impact to devops a very important topic then europe leading a panel on observability with quintessence acts of pagerduty alex hidalgo of nobe 9 april edwards and um and april edwards from microsoft yep and then we'll wrap up all of our talks by hearing uh from quintessence uh once again uh in our closing keynote about the changes in devops now that the practice is over a decade old oh man i feel old yeah i understand uh so let's talk a little bit also the fact that we're going to be having a workshop too yes so after these wonderful talks stick around for a workshop where we tie a lot of these concepts together and we get together and deploy a bicep template via github actions now we'll create a key vault to store some secrets and see it all come together as we build an ever and azure whatever azure kubernetes service cluster you can start prepping yourself now by heading over to the repository and using the template to get started you can start there at aka dot ms slash devops slash aks bicep to get started but we're going to spend plenty of time there at the end towards the end so absolutely we've got about a good uh amount of time to spend working through our really great uh what i think is a great workshop uh that you can follow along and and if if you know want to you could always go back to the youtube video that we're going to have here that you can always scroll back and forth and see specific stuff if you missed it uh and and to follow along with today's event make sure you add at microsoft create and at learn tv on twitter if you're adding to the conversation please please please tag your posts with hashtag ms create you can use this qr code to get to the twitter feed directly steve you want to tell us a little bit about our code of conduct today yes yep so just a reminder for everyone right we do have a code of conduct for the event if you have any issues please let one of our moderators know or head over to aka dot ms slash create devops for full contact details and when you complete today's workshop you'll be able to be eligible to receive these special azure hero badges these are blockchain based and a rare digital collectible i know everybody's really into those nowadays uh you can go to aka dot ms slash azure.heroes for a full description so these are unique and these are uh for completing today's workshop and another great part stephen is this plan of flag campaign or except they plan a tree excuse me plant a tree to fight climate change campaign yes definitely so if you complete if you stick around and complete that workshop with us we'll plant a tree in your name i think that's pretty cool yeah me too i really uh i really think that it's important that we consider the the environment and have a a green uh contribution to this uh world so we're going to make sure that you uh get a tree in your name uh you'll get a digital sticker uh to those who complete the workshop at the end of the event um really really great stuff um i want to thank suzanne for uh putting that together for us um thank you so much suzanne we really appreciate all the hard work you've done to get this all together all right so so stephen i think it's now good yeah i was gonna say i think i think we're uh we need to get moving along here we've got uh i think we just need to level set real quick on devops and then we can get to martin i'm really looking forward to talking to martin so uh yeah i think he's gonna he's got some good stuff to share with us so let's get started then we'll we'll start by defining exactly what devops is at least the way microsoft interprets it and i think this quote by donovan really puts it nicely devops is the union of people process and products to enable continuous delivery of value to your end users yep uh pretty much sums it up all right and it it's not a myth right there there are real business impacts there are impacts to your technical team and there's impacts to your business and we see that born out year over year uh through this through the work that dora's done through other studies that have happened through the mckinsey enterprise devops study so really i mean what does this all mean jay well i it boils down to that devops implementation helps organizations grow by placing a greater focus on delivering value eliminating waste streamlining the internal feedback loop and always improving our products so by utilizing devops methods we will deliver our software faster which will lead to happier customers great so we've identified these five big pillars of our devops success and so we've shaped today's program around them we have culture automation cloud native security and observability but i think we're really ready to get started hearing from our first from our speakers now so let's bring out our first presenter and now that we've kind of outlined the event and we've set a baseline on what devops means let's dig deeper into the devops experience with one of my favorite humans martin woodward well i primarily come from an operations background martin comes from a developer background and that sets us up well to have this devops culture conversation and talk about breaking down the walls between developer and operators so welcome martin thanks for having me am i the culture then is that what it is i just saw you had this in is this my culture order is that is that who i am yeah your culture oh my goodness me there we go first time i've ever been described as that that's for sure all right so martin you know how would you personally define devops and what do you think that feels like in action yeah i mean obviously donovan's definition is great about bringing people processes and products together it's important to emphasize it's not about products you know quite often devops is what the vendor's trying to sell you sort of thing but it's not it you know it's about the culture it's about the processes it's about supporting the people and people first as donovan has it because it's that's always the hardest part um get the culture right get the organization right and then create processes to support those people and the product side the technology side is kind of easier really you know you can get products from everywhere you get products from microsoft you get products from github you get products all around and technology all around it's the people and the processes to support those people it's always the hardest um patrick dubois actually kind of summed it up well for me um uh he was saying that devops is whatever you do to bridge the friction created by silos and all the rest is just engineering and i really like that it's kind of like a more pithy explanation of it you know what i mean it's whatever it takes to break down these silos and and to get things moving and focusing on your customers the way i describe it to a lot of my teams is like if it hurts do it again if it hurts just get better at it until it stops hurting and keep like does it still hurt you know keep punching yourself in the head okay i'm gonna get better at it until it stops hurting and i'm gonna have appropriate safeguards and that's that's um that's what you are that's not what devops feels like as a team you didn't ask me that as well it doesn't feel like continuously punching yourself in the head but uh yeah well some days well maybe yeah i mean you know when you feel like doing it when you're when you're on course sometimes that's for sure um for me it's all about the customer focus i don't know if that's um you know the same in a lot of the places that you've been working at but um having that like strong passionate focus on the customer and that's what you're doing it for you delivering value for your end users you know doing it iteratively doing continuously improving but making sure you develop a safe place for all of your teams to experiment and try things um so you know that's incredibly important and that also means you want to be investing in kind of automation to make quick iterations because you want to be iterating quickly make that safe it's no good just shipping things really quickly if you break things really quickly you know you'll be able to need to be able to do it safe you need to be in a safe place both um culturally in terms of you know sort of psychological safety but also safe places in terms of you know automated protections from from doing the stupid things that we always do especially when it's three in the morning and all that sort of stuff um and doesn't some of that kind of fall out from from that customer focus right like we don't want to ship our customers things that don't work right and so having had being able to deploy safely having engineers who are happy who are not burned out from being on call they tend to deliver better things for our customers so so that customer focus you asked it you know if i if that was kind of things i saw as well and most definitely because a lot of these other things fall out from wanting to do the right thing for our customer yeah and it's it's it's very easy to you know say isn't it it's very easy to say oh yeah we're going to be customer focused and we're going to do this but it's actually constantly working on breaking down down those silos and doing it in an iterative way is the key i think don't try and ball the ocean at once don't try and develop everything because you're never going to get there so just try do a little bit and then look use data you be you know like look and see it measure if you've if you've done something if you made improvements and then move on oftentimes when i have that conversation with teams you know how are we going to measure if we've got better or not and you get like a uh and that's a great question because it's like why are we here what are we doing like what is what does success look like and by focusing on those things continuously and thinking it really helps you sort of develop and have a sort of more high performing team i think yeah and you know does does capturing some of that data and keeping that focus on the customer experience help break down some of the silos because you have to now you have to talk to some other people because you don't control the whole customer experience or you know is is there a way that you you know try to to share some of that expertise across your across your teams or systems yeah i mean that you know the classic one is like you know you and me you have more of an ops background i have more more of a dev background and quite often when i go into a company and they're that they're like just starting to sort of think about devops they'll go well i've got like three dbas and 300 developers you know does that mean i need a dba per team does that mean i need an sre and an ops person per feature group per agile team and obviously you know you you can't have like infinite numbers of people you can't do that you can't you know it would be great but no and so you have to figure out ways that you can kind of share that expertise amongst your team you're never going to have enough people so how can we build processes how can we build practices in place that allow the individuals on the team who have expertise to share it with the rest of their team but the whole organization and that's not just ops and dev you know that's like designers how do you create a design system that allows your developers allows everybody on the team to do stuff that doesn't look really ugly and is consistent and is you know consistent across the board how do you make sure your technical writers are able to help influence the documentation and make sure that it's written in an understandable way by humans without having like 10 tech writers per team you know and it is all that sort of stuff and figuring out how to scale that's definitely one of the challenges and kind of one of the ways you've got to think about everything you do how can i maximize and i have a finite number of keystrokes in my fingers i have a finite number of breaths in my body how can i maximize those to to have bigger impact by helping everybody on the team learn the things i know and work in a safe way and use my expertise to make it safe for them to do deployments so martin we've only got a few more minutes left yeah what's one piece of advice that you would give to the folks at home who really want to start with devops oh i think for me it's you know obviously like listen to the talks today uh and like pick one thing what one thing are you gonna pick from today that you're going to use and take back into your team next week and you're going to use it and you're going to try and improve that one thing just a little bit it's that whole you know do it do something that hurts until it stops hurting so what are you going to take from today what are you going to learn and like apply just a little bit off don't fix everything just improve it just a tiny little bit and if you improve a tiny little thing once a week you build the muscles of improvements you build the ability to be able to change things and you get better at change and you get better at improving and and improving the engineering systems and all those incremental improvements really start to add up do one a week and you you know you just start to pay down technical debt and then start to move on and have an amazing engineering system that you're proud of and that people want to work in and that your team could be productive in awesome i i i love that i love that focus on kind of iteratively improving and you know in the concept of literally iteratively improving let's bring jay back and iteratively improve our group here well you know i i hope i'm an improvement so far um you know that was really great guys i really enjoyed listening to what your take is on devops culture and i always believe this martin and you can probably agree with the sentiment that if you're going to implement change in an organization you better wear a helmet because you're going to run into some walls yeah well you're just going to keep punching yourself in the head repeatedly you know but yeah you definitely have to you have to make it a safe place for people to do that you have to it has to be both psychologically safe and also safe in terms of processes to like make sure people can't accidentally cut the fingers off or whatever you know absolutely it can be a painful journey but it's a worthwhile journey and that's one of the things that has come up in a number of conversations uh right is like hey we're doing the step-ups thing but it hurts yeah some of these things are going to hurt because we're changing the way we behaved very very cool so stephen that that was a great way to get started i think martin you know what martin's one of the best people that i know who really advocates about devops i actually remember upon the azure devops product uh launch you know him spending so much time out there and getting that information into people's hands i remember he had a push to deploy physical button that i really really liked it was a an iot device that you hit it it went ahead and kicked off the deployment through azure devops so uh we've got another speaker coming up in just a minute uh steven i want everybody to remember that uh their participation is huge so there's the chat where you can leave comments uh it's native in your things like youtube or you can use the learn tv chat all of that you can go ahead put in your questions your comments uh keep your eyes open we've got moderators we've got people to take care of all that when you send in your your questions and we'll try to get to as many of them as possible definitely please ask your questions you got your people here to answer them so coming up next who do we have we have april edwards and april edwards you know what i am so thankful that you're here today you are one of my teammates we're on the same team together we spend a lot of time uh learning about devops and and really selling uh how important it is so how are you today i'm doing great jay i'm doing great how are you i'm so glad to be here this is great you know i'm i'm doing well um let's take a look at what you're going to be talking about today really quick i know we've got a quick description that we're going to be implementing uh automated process that leads to devops success so uh we're going to go ahead and give you a chance to talk about automation on azure um i think that you've got a lot of great information for us today and i'm going to kind of let you take the lead no i'll i'll see where we go and maybe ask some questions along the way sounds good so we're going to talk about automation on azure and martin woodward just said it you know pick something that hurts and start there and before we start we're going to talk about you know why automation is important and what we can do to automate so you know we defined what devops is right and you know it is it is the combination of people process and products and that technology thing to deliver this value and we want to deliver value you know we want to bring people together and we want to have common shared goals and that's really important and we need to increase the collaboration and and you know when you have different backgrounds in an organization that can be really tough to do you know martin has that developer background and um steven has that operational background and same with you and i like we have very different backgrounds right so we work together you and i you know in our organizations to execute these things and technology is a big part of that but it's it's driving that value of whatever we're doing but we need to be able to enable our team to do more and be more effective and we need to facilitate experimentation in our organizations and that's crucial and we need to focus on automation and you know it's a it's a hard thing knowing where to start but we go why is this important because you know i'm an operational person i don't want to change but we need to make these changes because your competition's already doing it and you know forget everything else forget all the stats about you know increased velocity and all these things those are really important but human error a lot of the outages that you and i have seen and probably created ourselves has been down to our own error so i want to talk about the people side of it a little bit you know people is the hardest part of devops we're asking people to make a cultural change now when you have an ops team and a development team and any other teams in an organization and they're trying to make changes traditionally we worked in silos and we blame that other side of the team and that's difficult because you know we we need to be able to work effectively but what we found just on the other side and we just toss things over the fence to each other and that doesn't go well that's not driving the same value together so we need to look at okay our process a little bit um you know we have kind of four phases in our process and and when martin and steven and yourself were talking about devops this is crucial because we want to continuously reiterate our process now and that starts with the planning phase we want to do everything early and often and we want to fail fast so when we talk about automation if it doesn't work we need to find something that works better or another way to do things and we're in that planning phase we need to look at some of the tooling whether we're using something like azure boards or github issues etc and plan what our work's going to be we need to then develop our work whether you're an operations or a developer yes operations you need to do some development work and when we start talking about some things we're going to talk about in a minute you'll understand why and you may use tooling like visual studio visual studio code or github code spaces whatever your tool of choice is to develop and then we deliver that code and then we want to operationalize whatever it is we're delivering and that's crucial to have this full cycle so when martin and steven were talking about the process and we talk about devops and we're going to start automating things we want everything in this process to be fully automated when and where possible but if we make one change today and like martin said one change per week we can start building on top of our process so i want us to focus on tooling over tasks now jay with an operational background when you were taught to automate something how did that make you feel you know what automation to me really made me feel like we were taking uh the manual work out of our hands and really placing it into uh in a way in another basket we were still working on how to actually create automation we were testing it um making sure that every single time we had notifications that said this deployment occurred and it gave me a little bit of safety and i think that's awesome but i think we see a lot of people that are really afraid of automation and i think we need to let the think of the tooling side of it where we need to let our machines do the repetitive tasks while our humans are building the tools to solve the problems and we're being more proactive right and there's a massive value when we start to automate things and i'm going to quote one of my favorite humans jeffrey snover and he said this and and this is so true from when i've engaged with operational teams across the world and development teams as well you know nothing is more important than automation because productivity equals career security so when people are in maybe an operational role we see it a lot where we're afraid to automate something because it takes something out of our hands out of that control but that allows us to do something more proactive we look at all these issues in our organization so we have automation to the rescue so we talked about that process before and we're going to start looking at how we can automate our builds and do things early and often so we do building of our code and we start testing our code and then we start deploying it and you go hold on a second that's great for developers but i'm in operations so i want to talk about infrastructure's code a bit because it is part of devops and when we start talking about this whole process we start automating these things and are into what we're deploying we're kind of referring to what we call continuous integration and continuous delivery and there's lots of tooling out there that can help us i want to talk about infrastructure's code because jay both you and i love infrastructure infrastructure's code it's kind of at the heart of what we do right yes and there's so many different options out there nowadays you know i i remember coming into it and you know it was pretty much chef and puppet and those were or and there was like cf engine and things like that that came as well i worked i grew up in a powershell world um i say grew up i mean in the kind of the automation side of my career it was all powershell for me that's where i learned automation i started automating things in exchange in sharepoint and through windows server many many years ago um and i didn't think of it this way and it took some time but infrastructure is code at this point um and when we start looking at tooling like infrastructure as code to start automating the beginning process and this is great because this is something you can do on premise you can do it in azure multiple cloud and we start looking at different practices and this is where the tooling side comes into play but this is also the people change and i know jay you and i can attest we have to change a lot to embrace these processes right we have to start putting our code in source repository and code source repository so maybe we're using github or azure repos um then we have to start looking at the lifecycle of our code and this has a lot of benefits because we start not just hoarding our code to ourselves and then you know something going awry when we go on vacation but we start collaborating with our teammates so that breaks down those barriers so we start collaborating with our other operational folk our developers our dbas our pms whomever else is involved in that project so we increase our collaboration then we start versioning our code you know think of it you know the old days where we kind of save a file and go you know you'd have like file hyphen one and different versions you'd put it into like your little file server when we start using you know source code repositories we start using better practices where we version it and we can also have governance around it and we have full traceability and this means we can also have our code as reproducible and very scalable and that's what customers want they don't want to just go deploy a virtual machine and be done with it so the types of tooling with infrastructure code is vast and people go where do we start there's tons of options so the first few at the top are cloud native excuse me are azure native so we have arm templates but jay you and i have both used right now there's bicep yep and i love bicep i was not a fan of arm but you could go into the azure portal deploy something export an arm template and get started like it was a really good azure native way to get started bicep the overlay on top of arm is so much easier to learn so much more readable um and it's gaining huge amounts of popularity and then you can do stuff in the azure cli and with powershell um now powershell is cross-platform it's just not in windows anymore which i think makes it even cooler and then we have the other tools like terraform which is multi-cloud so again for those of you working in kind of this hybrid environment um you know whether you're going azure aws or gcp i want you to use azure but you can use terraform you know you also have tools like palumi that allow you to take the code knowledge you already have you know maybe you code in c sharp or go or type script pololumi allows you to do that and then write your tests in code um and then like you mentioned jay like chef that's a lot of what we got started with and you have puppet and ansible again multi-cloud state management of your environment so this is kind of an end-to-end solution where we have this full cycle where we plan um in azure boards as a you know an engineer and i'm using the term engineer to talk about our our role effectively then we write our code in visual studio visual studio code accessing an azure repo we deploy that code to something and then we wrap around that operational side with some kind of monitoring like azure application insights now if everyone stays tuned for the next talk we're going to hear from my colleague donovan brown where he's going to talk about a step further where he's going to go cloud native and that full life cycle so before we go any further i love doing a demo jay so are you ready i love me a demo i love me a demo why don't you bring it on up cool so i'm gonna work in powershell because i love working in powershell um i've already pre-authenticated into the azure cli but what i've done here is i've told azure i want to deploy an azure static web app so i want to go full end to end fully automated solution so instead of going into the portal we are going to touch the portal but we're not going to deploy via the portal we're going to use some you know very light infrastructures code i'm going to connect this into my i've told my code where my github repo is sitting what branch where i want to deploy the static web app to and the name of my static web app so if you can see the name at the top create devops i'm sorry that's the resource group um it'll be swa hyphen create devops now when i run this code it's going to go connect to my azure portal it's already authenticated through with active directory and it's successfully deployed my static web app so i'm going to go over to the azure portal and in the portal here i can see in my resource group i have a new static web app it's deployed much much faster than if i do it from the portal it also outputs a url for us now this url is randomized we can put in a custom dns name absolutely that's fine but it spits that out on the creation of our static web app now after it's created the url we can click on it and we can see that our static web app is live but there is nothing running in it so okay we need to put some code in it if we go back to our portal we can see that it sees our main branch it sees our github repository and it sees the action and it's creating a workflow so if i click on this edit workflow what it's doing is creating a whole workflow for us now this is awesome so what we have here is a full ci cd pipeline so that is as soon as i initiate my code it's going to execute this workflow for us using a github action so it's writing all the ammo for us right yes because when we talk about where do we start what do we do like sometimes it's hard to know where to get started and that's why i love azure static web apps because as we deploy it into in from our github repository it gives us this yaml file so we have ci cd out of the box so in this yml file it's going to say on any push of our code to our main branch or maybe even a pull request it's going to run a couple jobs it's actually running two jobs first it's doing a build and deploy job it's building our code it's going to push that code out to our azure static web app and you can see here on lines 25 and 26 it already kind of encodes our secrets for us so it doesn't expose anything it has that security built in automatically so i don't have to think about it so i want to actually go see this workflow run so we didn't have any code into our website i can see it build and deploy our code it's still running it's running through that exact workflow that i just showed you so that's pretty cool so now that it's completed successfully i can go up to our static web app i can go ahead and refresh the screen boom we have a working website how cool is that yeah that's so great so let me ask you a question about this um do you think i should keep my infrastructure code the same repository as my application code so like if i'm creating a bicep template or something like that so i personally and you know this is best practice your infrastructure has dependencies on your uh your application code most often than not right so they should be in the in the same repository they should be in a different file structure as such so they're maybe not next to each other and they can be easily identified you can put different ci pipelines to them and you can cause different triggers but they should be in the same repository so you can do dependencies in your workflows and your branching policies but yes i've always put my source code next to my infrastructure's code so in this instance um i could have deployed this with an azure bicep file i could have used arm i could use terraform i chose the azure cli just for a bit of visibility but i could have this even more automated down the road and i'd absolutely put this into another folder within the same repository yeah that makes a lot of sense because we want to make sure that we are we're checking in everything we're looking at everything we're not giving ourselves multiple pipelines because we we can create like say sub modules of a pipeline um but you know we don't necessarily need to have it in two completely separate pipelines and you know donovan who uh we'll be seeing next was someone who kind of told me about how this is just a really really cool thing to do is to think about how you're deploying all of your infrastructure not just bits and pieces and then your application deploy absolutely and that's super critical and i want to go ahead and show you a little bit of an easter egg that's built in this static web app so if i go back to my static web app i can go into my code now my code is seeing the same repository i can create another folder i am going to change my code on my main branch now when i go into this file here this is my website file so you know there can be debate on how this is done but for just ease of display today i want to go ahead and change this website on the fly so we've just deployed our website i'm going to go ahead and put in welcome to create devops and i'm going to go ahead and commit my code but i'm not going to commit it to my main branch because that's bad developer practices i'm going to get a pull request and create a new branch which i can do within github i can also do that for my favorite ide and when it creates the pull request it's going to run through our code again because we have to remember those two triggers we saw in our ci cd pipeline are going on pull requests or any change to main and we can see here with change to website it says number 16. now number 16 is the number of our pull requests so hang on a minute because that's going to come back to us in a second and we're going to show how that flows through in the process so because i've opened this pull request i've made changes to our code we can go ahead and build and deploy our code again it's going to run through that exact same pipeline again this is all out of the box so it's going to run through our code do all this cool stuff so we've created an azure static web app we've deployed our code to our web app without having to touch any quote infrastructure it's all been automated end to end we could go a little bit further and automate the infrastructure's code piece but for now we're going to get the website up so when yeah so but here's an easter egg now this is a special feature that is built explicitly into github when you deploy an azure static web app so thinking of another developer best practice we don't want to touch production do we j no we want to make sure that we have some sort of uh place to go in stage exactly so in github we can see here it creates a staging site when i open this pull request so it create we can see it's here it's ready it does this automatically and it's built in feature so if i click on this link here it's going to open up our new version of our website very cool so april we've only got about two minutes left or so and i just wanted to say thank you so much uh we we've really learned a ton in just a short amount of time and if people want to be able to reach out to you to talk more about this right below you can see that we've got april's twitter right there so that you can go ahead reach out to her and ask any additional questions uh we've got lots and lots of information also in the chat uh we'll answer your questions we've got some great ones that have come in um but anything uh april i want to just wrap up by asking you this um how how did you uh really feel uh when devops first became kind of like a part of what you do just in like 30 seconds i had this idea that we could do things better like our processes could be improved and i didn't realize there was a word for it that that was how new i was to it so when i actually learned it was a thing and there were stats and there was like a process and the whole school thought and like hard facts behind it that really excited me and that's why i became i went from an upside to a developer side in my career and that's why i became just enthralled with devops how it works how we can do everything better awesome well thank you so much april and you know what we've got next uh we've got a session and we're going to be talking about cloud native services and how we can deploy applications uh with those cloud native services and and we've been really lucky we've got donovan brown with us today um really a great producer or i say a producer of content he always comes with some of the most concise and uh really thoughtful uh presentations and today is no different so stephen's gonna be in the chat answering any of your questions but we're going to learn a little bit about uh how helm uh can work with your deployments when you're creating your containers and say something like kubernetes to really simplify it so we're going to be talking about templates we're going to be talking about cloud native services and how they all can kind of come together to help you do your deployments so we're going to get started on that in just a second and i just want to remind you that you can send your questions in the native chat window if you're using uh youtube we're happy to get your questions there and also all on learn tv so aka dot ms slash learn tv make sure you're tagging your questions on twitter with hashtag ms create and uh more than anything let's just keep things rolling so we're going to go over to donovan right now hey everyone i'm donovan brown today we're going to be talking about how adopting a micro service architecture will impact development and deployment no matter what industry we are in writing software has common patterns we reduce costs by only using the resources we need and scaling out when additional resources are required applications are being broken down into units of functionality each exposed as a service we want to focus on adding business value and not managing infrastructure so we leverage serverless platforms and use devops best practices and the number of programming languages seems to never stop growing and we should use the best language for the task at hand on the surface micro service development seems simple it's a micro or small service not a giant scary monolith however there are limited tools and run times to support distributed development and many of the frameworks are tightly coupled to a language or development stack a typical microservice might look like this several small purpose-built services all talking to each other some of the services also talk to external resources that store state or ingest events getting an application like this up and running and keeping it running has proven to be challenging to address these challenges the cloud native community has developed dapper and helm dapper is a set of building blocks to ease distributed application development and helm helps package and distribute these applications when deploying to kubernetes the goals of dapper are to take years of experience and best practices and make them easy to use from any language and on any stack it is driven by standards and provides a consistent portable and open api that can be extended and used in any cloud and on the edge the goals of helm are to manage the complexity of kubernetes deployments by supporting easy updates rollbacks and sharing with a great templating feature both dapper and helm are community driven and completely vendor neutral before we can deploy an app with helm we have to build it so let's first focus on dapper at its core dapper is a set of building blocks including service to service invocation state management pub sub bindings and secret management with the support for actor model and observability out of the box we can use as much or as little as we like if we have already solved service to service invocation but need help with state management we can just use the state management building block or if we are starting from scratch we can use it all allowing us to focus on adding business value any language that can send an http or grpc request can use these building blocks not only can applications that leverage dapper use any language they can be run on any infrastructure dapper is implemented using a common side card pattern where a second process runs alongside our main application the main application uses http or grpc to call into the dapper sidecar to take advantage of the desired building block here is an example application with two services a and b notice each of them also has the dapper sidecar when service a wants to call service b dapper does all the hard work of discovering where service b is and securing the communication between the services this slide also shows the plugability of the component model without having to change our code we can change where state is stored where events are published where secrets are stored and even where telemetry is sent when developing locally we can use a redis container and swap that out when we move to our cloud platform of choice let's use services service invocation and observability as example dapper building blocks when one service wants to call another service it must know the address port and number of instances of that service running the service could be running anywhere with a post request we can ask dapper to invoke the new order method on service a and dapper takes care of the rest observability gives us tracing across all the services in our application with dapper we can configure what we want to see and where the telemetry is sent this slide shows the same information visualized from application insights and zipkin as a developer we don't have to write any special code by running our application with dapper we get this for free what i'd like to do now is a demo showing how to get started with dapper first i want to show you the docs site at docs.dapper.io so you know how to get started simply click getting started and then click install the dapper cli this page will show you instructions for installing on mac os windows and linux now that you know how to get started let's see some code i'm going to switch over to visual studio code where i'm inside an empty folder to get started we're going to create a new web api using the.net new command what's cool is we can dapperize an application without changing a single line of code we can start to use dapper immediately by running our application with dapper with this command we are giving the service a name telling dapper what port the app runs on what port we want to access dapper on and how to start our application dapper will build and start our application and then launch the sidecar and wire everything up switching to a web browser we can still access the application on port 5000 this allows us to incrementally adopt dapper because all existing clients can still access the application on its original port the real power starts when we have a client that uses dapper to access the service if we access the service via dapper the results are the same but notice we are now using dapper on port 3500 this will never change even if we change the address of the backing service or the number of instances this is saying hey dapper we need you to do something for us we don't know the address of the other application we don't know where it is on the network we don't even know how many instances there are but we know its name is my app and we need you to go invoke the weather forecast method dapper locates my app and securely calls the weather forecast method for us but wait there's more because we're using dapper we are getting observability for free switching over to zipkin we can query all the telemetry dapper was automatically collecting for us we can see when calls were made how long they took and what services were involved we can drill in and see detailed information without dapper we would have to write code to get this information this information is invaluable when you need to debug a problem and we get it for free by just running our application with dapper now i'm going to stop the application and return to the slides to discuss more building blocks that was just a quick look at getting started with dapper there is a lot more that dapper can do but i want to switch over to helm and discuss deployment once you have dapperized your application it is time to deploy it helm allows you to organize and parameterize all the ammo needed to deploy your application this makes it great for adding to ci cd pipelines a helm chart is a specific folder structure that defines the details values and templates to be used to deploy your application they can be stored in source control with your application or stored and downloaded from a registry one of the benefits of microservices is that they can be deployed individually without disturbing the entire system with helm you can create a chart for each individual service and deploy them when ready you can also define dependencies between charts this enables you to create a main chart that might deploy the entire solution in cases of disaster recovery or standing up temporary test environments let's switch over and see helm in action and see how to use it with dapper and github actions let's see just how quickly we can create and install a helm chart and learn how to deploy it in a ci cd pipeline to get started use the helm create command and provide a name for the chart helm will create a folder with that name and populate it with a default chart before we dive into the details of the chart let's install it to install a chart use the helm install command provide a name for the release and the location of the chart this will install the chart and display information on how to use the installed application i will copy the commands now but before i execute them i will run the helm list command this will return the releases in the cluster and there is the release we just installed i will paste the commands i copied earlier once the commands are complete i can browse to port 8080 and see the application running instead of creating a chart you can download pre-packaged charts and install those the same way but to use helm to install your own applications this is typically the way you will begin now that we have a working chart we can take a closer look and understand how we would update these files to deploy our own services first let's review charts.yaml this file defines the name description and version of the chart also in the root folder is the values.yaml file that holds any default values you want to use in the yaml files in the templates folder the files in the templates folder will look familiar to anyone that has deployed code using coop ctl before helm places all the yaml files in the templates folder and allows you to define placeholders that can be overwritten with values from the values.yaml file or user provided values from the command line you would copy the yaml files that define your application into this folder and parameterize any values you will need to provide during installation to learn more about creating helm charts you can visit my youtube channel with a basic understanding of a helm chart let's see how to use it in a ci cd pipeline the helm chart can be checked into source control alongside the application it deploys these files can then be used in your ci cd pipeline to deploy your application into kubernetes here's an example yaml file that uses github actions to use dapper and helm you need to install the clis onto the runner both dapper and helm have official github actions in the github marketplace with the clis installed the pipeline can now issue commands to both dapper and helm i also take the chart and i update any dependencies and store the chart as an artifact of this stage of my pipeline during the deployment stage the chart is downloaded and helm is used to upgrade the chart to the kubernetes cluster hope i have piqued your interest in dapper and helm these are two great tools to help you as you start to develop microservice applications be sure and visit dapper.io and helm.sh for more information you can also reach out to me on twitter where i share lots of information about technology and answer questions and visit my youtube channel where i dive deeper on both tools i want to thank you for spending this time with me i look forward to seeing what you build oh man it's all it's always great seeing donovan and i love how he always takes the things he's working on and finds a way to get i'm into a ci cd pipeline yeah you know um what did uh damien our our former teammate once say and a member of that league is like friends don't let friends right click to deploy so yep always so uh all right click some friends on my friends right click publish yep yeah and and so we're always trying to uh put as much automation in our process as possible uh so i i got a question for you steven uh that came from the uh the audiences what would you say is a defining feature of a cloud native service yeah so um that's it's actually really good question and in the in the docs we actually have a full a full doc kind of explaining about what cloud native is so to condense it down into what is um kind of what is most you know uh or a short description of what cloud native is um to me it comes down to it really embraces the cloud model right that it takes advantage of past services it can take advan it takes advantage of uh some of the portability concepts that we have uh easy easy to update different parts of your application infrastructure um you know you can go down the whole 12 factor route there's there's a lot of there's a lot of different nuance that you can have to it but to me it's it's really an application that embraces that um this embraces the essence of cloud and the idea that what's what what infrastructure is there now might not be there later and uh and so we need to make sure that we account for that in our application architecture absolutely and and somebody else wants to know and i i think i can start uh picking away at this one too is they want to know if they can migrate to these cloud services or should they rebuild their application and i think that really depends on one your your level of skill around that cloud native application um and and secondly what your your capability of your your development team is um you don't necessarily need to rebuild but you may have to do some refactoring about how applications uh connect to one another if you're going into like a micro service environment and that's what's great about something like dapper is dapper helps move you forward with using the uh that type of environment and and when you're also talking about cloud native services you're also talking about uh pieces like auto scaling uh using uh integrated services within these platforms as a service like an aks or or even an app service you you want to be able to consider how they'll all work together and um and and of course put that all into your pipeline uh so i think that you don't necessarily need to uh move directly to you can take off bits and pieces you can walk slowly before you start running with using them yeah and the azure devops story is actually a really good example of how do i take a legacy style application that was box software that was sold on premises and how do i convert that into a cloud service and a lot of the core is was that kind of central monolithic app and then they started peeling out microservices as they needed to evolve them right so you don't have to do it all at once either it's not an all or nothing choice absolutely you know you can take this in a in bite-size chunks and and in keeping with the capacity that your team has and grow your experience as you do these little bits of work speaking of bite-sized chunks we've got to take another bite out of our session and and head to our next speaker uh someone that i think is just wonderful uh someone that i'm i'm really lucky i've become friendly with over the years and and just you know ace all across the board it's cat cosgrove from palumi hey kat why don't you come on in hello good morning afternoon it's morning here welcome well kat um i know we've got a lot to talk about uh when it comes to security the importance of security and uh i i really just wanted to start by saying thanks for being part of this today yeah happy to uh thanks for for having me um it's uh i don't think i've ever been in an official microsoft thing before so that's pretty cool um well you're here and that's all that matters so cat um i know you've got some stuff to show us oh and some stuff crashing i can fix that while i talk sure uh i know you've got some stuff to show us today um i i believe you got a little mini presentation in my right i do great uh we'll be bringing that up in just a second uh but first and foremost kat uh i i know you're from palumi and automation just like we've been talking about is a big part of that yes uh i don't like having to um do a lot of things manually if there is a conceivable way to automate something out of my personal responsibility i i think that is um that is my my job to automate myself out of uh menial tasks it's uh one because i don't want to do these things over and over again it's boring uh and two i say this in like virtually every talk i give some of them more than once but humans are actually really really bad at repetitive tasks it turns out it's extremely easy for a human to have a bad day or make a mistake or forget something and also we're super super slow compared to a computer with automation you can like iterate on uh the testing or whatever involved in making sure that an automated task is completed uh successfully and correctly in a consistent reproducible way with people you can't really iterate on that we're we're unpredictable and there's nothing you can do to prevent somebody from having a bad day like that's that's not something you can you can plan for so i think it's always uh it's always safer to automate things where you can and also it makes your employees happier when they don't have to sure anything over and over again and and so i think we're going to talk a little bit about security and how actually security fits into that story because as you're moving along in your develop software development release cycle you don't necessarily want to think about security as a secondary thought correct yeah you you don't it should be a primary thought the whole time uh i i have a rant in my talk so you'll you'll get to hear me kind of ramble about that a little bit um i i have even called the talk a rant so i guess i'll just go for it yeah so let's hear what you have to say cat i i am i am thrilled to hear you rant it's something that i've always enjoyed oh i know you list you love listening to me not shut up um i i cannot help but run my mouth so um hopefully this is entertaining for all of the people watching who i assume are on like twitter and linkedin and everywhere else that all stream this but absolutely yeah okay i will uh go a ranting then so y'all today i'm gonna rant about devops i am also gonna rant about buzzwords just like a little bit and i'm gonna rant about security and maybe a little bit about the future uh but before i start here's a photo of me with my cat uh her name is espresso and she may or may not show up while i'm talking she's actually in my lap right now uh that's the best way to keep her quiet i will not apologize for it if she yells because this is her house and we're in her living room right now uh if you want to get a hold of me later um that's pretty easy to do uh i am on twitter at dixie3flatline and uh jay will be watching in the chat to forward on any questions comments complaints compliments on my excellent sense of personal style or my bad 182 t-shirt that you may have um anyway uh let's go so first i want to talk about the title of this session it involves the term uh shift left this is not a term i like partially because it sounds like a buzzword and i'm kind of allergic to those partially because i don't think that's actually what we want to do with security we we throw this term around like security only exists at like the far end of the software development life cycle and nobody ever thinks about it until then and like we now want to pick up the entire concept of security and drop it earlier in the software development life cycle um but i i don't agree i don't think that's what we actually want to do i don't think that's what we're actually doing what we want to do is distribute it throughout the software development life cycle first i want to make sure that everybody is on the same page here uh this is a devops thing so i know that i can probably assume that you all know what that means but to err on the side of safety this is the definition of devops that i'm gonna run with for the rest of this talk devops is the term for the union of the development team and the it operations team through the use of a specific set of practices and tool chains with the ultimate goal of shortening the software development life cycle and delivering more high quality software okay uh i'm defining that because i would rather not guess that everybody watching this is already an expert so in order for devops to work it requires tools and a culture shift it's not something that you can just say you're gonna do this is a well established fact it's still the topic of a lot of really long conference talks about devops even though devops has been a thing for about a decade now i'm not going to go into this a ton because much more qualified people than me give outstanding talks on this very subject and you should absolutely go listen to them probably somebody else has done it today but to give context within the scope of this specific talk devops may mean changing the way you write software your code needs to be written in a way that's more modular and that makes it easier for other people to maintain it because ultimately people are the ones maintaining your code it matters and you need to merge with source often and pull from main often make much smaller changes every single time run building unit tests with every single commit if you can and that process has to be automated nobody is doing that manually nobody wants to do that manually that's like that's an enormous potential problem if an entire team does this you end up with conflicts less often problems are discovered way earlier so hopefully you can fix them immediately the idea here is that nobody exists in a silo anymore at least developers don't and operations teams don't everyone is like doing devops to some degree at this point and this is a cultural shift that can take some getting used to but you're going to be more efficient and you're going to be less stressed out and we've mostly handled this with developers and operations teams we're still kind of having some growing pains though so you might be asking cat where is security in this equation the answer is it should be everywhere it's not but it should be your developers should care about security your ops teams should care about security your security team which should still exist because distributing security across your entire sdlc doesn't mean like you don't have a dedicated security team anymore obviously they will still care about security devops is about efficiency and we have tools now to bring security into the rest of your devops pipeline uh like there's more vulnerability detection and security automation tools out there then i really know what to do with or care to enumerate here it depends on what kind of application you're building and where you're deploying it is it cloud native or not there is some kind of tool for you really there there are a lot of them and you should probably be using a couple of them but that doesn't eliminate the need for a security team and it isn't picking up the entire concept of application security and moving it leftwards towards the devs it's supplemental this allows your developers and your ops people to help your security team by distributing the workload and catching some problems earlier so you might be thinking what about devsecops the introduction of the idea of shifting security left gave birth to this term devsecops uh some people that i deeply love and respect use this term uh to be clear but to me it's unnecessary i i am not really a fan of it so earlier in this talk i defined devops right i said devops is the term for the union of the development team and the ita operations team through the use of a specific set of practices and tool chains with the ultimate goal of shortening the software development life cycle and delivering more high quality software fewer security issues and incidents is part of delivering more high quality software it just it is security is not a late stage addendum to devops it's belonged there the whole time it's natural we should we should have always been doing this instead of kind of just getting around to it now and putting a buzzword on it so if security is a natural part of devops and everyone has to do devops to some degree to make the whole thing work doesn't that mean we all have to do security i i think yes and that's not shifting left that's distributing it everyone involved in the development of a piece of software has obligations to the user and the users expect to not have their personal information exposed or their devices hijacked or whatever we're all doing security here some of us just don't know it yet and i'm not saying that all of the developers on a team have to become security experts overnight or all of your ops people have to become security experts overnight i'm saying that there are some best practices that exist for your stack for your tool chain for your environment and if we want to make this work better if we want to make this easier if we want to make these things uh more commonly automated then it's important that everybody on your team is aware of security best practices specific to their role and again this isn't replacing a security team this is just shifting some of their load throughout the rest of the sdlc it's not picking up security and dropping it at the beginning it's handing some of that work off some of the work that's easier to automate for using code scanning or vulnerability detection or if you're in cloud native some kind of like container tooling to make sure that there's nothing nefarious going on inside of your containers there are there are things you can do to make this easier on the part of your ops team it's best practices around networking and like cluster permissions and on and on and on these should never be falling to like a single employee or a single team we should we should all be doing this or it's not devops we're just doing devops but keeping security in a silo that that sucks that's not very helpful or efficient and it's not what we wanted when we decided devops was the thing at devops days 10 years ago so uh that's the end of my rant if you have any questions for me i can take some of them now if you would like to get a hold of me later you can do that on twitter at dixie3flatline i do answer questions there you can also try emailing me cat paloomy.com but i'm going to warn you i do not answer my emails with any degree of urgency so expect that to be like way slower than um then i will i will do my best not to email you i don't want to get more more email into your bot email box i'm sure that there's lots and lots of things in your inbox that you will get to eventually and and of course uh twitter handles are right here on the bottom of our little chat or windows so you can head over there um so i got a question for you cat um i want to talk for a second about the tooling around security is there tooling to best ensure i'm implementing uh the best possible strategy for security and say like my older apps uh i don't think that there is any one tool that exists that makes sure that they're you're in a best case scenario security wise for like all applications it's like security best practices are an it depends situation and so i i don't think it's really possible to build a tool that um covers all of the bases for all of the different ways you could build an application um all the different languages you could use all of the different places you could deploy it i so i don't i don't think there's a one size fits all um certainly there are tools you can use to try to to mitigate some problems uh yeah i know like oasp is a big tool for for scanning code and um there's a number of different uh open source projects and obviously paid projects that you can implement as part of that strategy to in to shift left if you will and i know yeah you hate that term but uh yeah i think about it there are things you can use to like kind of get there but uh you should never actually assume that your application is is secure um because you can't predict the future you you can't predict what an attacker is going to do you can't predict what vulnerabilities will be discovered and disclosed later on i know espresso she's mad um but we can we can certainly try there are vulnerability detection and code scanning tools both free and open source that will help you out um which ones i recommend depends on like how you're building an application frankly that's uh it there are so many of them that uh honestly i would just be googling it for a specific situation it's it's really outrageous how many of these tools there are now and that there are big like uh services that can be implemented as well like one of the things that a lot of people uh rely on are web application firewalls waff to be able to sit in front of your application to add just another uh level of secured uh because ultimately your security posture in your organization it needs to be strengthened and the way that you do that is by utilizing the tools that are out there and also by by considering it at the beginning of the process so one of the great things that i know people do is they implement testing practices that include security yeah that they're doing audits uh and not just audits for compliance reasons but because they care enough about their application and code to to run audits regularly yeah and if you're using some kind of like vulnerability detection tool um some kind of code scanning tool that should be included in your ci so like if if a problem is detected the build should be bounced like that's that is automating something something easy out of your hands so that you don't have to worry about it your security team doesn't have to worry about it ops team doesn't have to worry about it it gets bounced back to the devs and they address whatever vulnerability was found which is usually just like an outdated dependency or something so you just bump the version of the of the dependency if there is a fixed version or you reassess whether or not like that particular vulnerability is one that you want to freak out about and hold up a build over but yeah there's there are ways to build this into your pipeline so that you don't really have to think about it and it's just one less thing on your actual security team's plate to like have to to deal with absolutely and so you know kat i i want to just wrap up this little session here with the you and i um i i know that uh we've covered a lot of stuff but i i wanted to ask you because you know you're doing a lot of really cool stuff over there at palumi i know you just had a conference am i right where you um can you talk just a second about what you did and people if they want to watch the recordings where they can go yeah sure so um palumi uh hosted the cloud engineering summit yesterday which was a free virtual conference for cloud engineers all about engineering for the cloud this was not to be clear a like paloomy specific conference we were just organizing it um so there were people talking about you know cloud formation and terraform and whatever else there too but i was the host for the build track uh we had a lot of really incredible speakers including uh we had chris nova talking about infrastructure as software uh her talk was incredible we had liz fong jones on my track talking about what open telemetry is uh we had heidi waterhouse talking about accessibility uh and it was just it was it was incredible all of the talks are um already online free on uh youtube so if you just go to cloudengineeringsummit.com you can get to the talks from there but they're all free and there to view online we also had we had emily freeman in like kelsey high water i'm actually i don't know how we managed to put together a lineup that good well it's it sounds really really solid i know your yourself and and maddie stratton over there at palumi are doing a lot of great work to help everybody kind of automate their their infrastructure and really get the right stuff done uh that that takes that manual work out of your entire process with minimal effort yeah absolutely so cat i want to say thank you so much um no no problem you know it's it's great to always get a chance to talk with you um and i really look forward to seeing what you're up to next yeah any place we should keep our eyes open at um if i do something spicy it'll always end up on my twitter account fair enough well thanks kat thank you very much for being here today all right well that was cat cosgrove over from palumi um just a wonderful person to speak with and we also got to hear from espresso the cat who had a lot to say but i don't think was overwhelming uh we just got the right amount of information from espresso and so coming up next uh we've got a really great panel and and the next one of the pillars that we kind of wanted to shadow out today uh that we feel will set you up for devops success is observability and so observability kind of differs from traditional monitoring and and we've put so much time and effort when it comes to ops into monitoring but as applications grow as environments change we need to think about different ways to keep an eye on what is going to potentially happen in our infrastructure and so i've got three great people to be part of this it's alex hidalgo who is director of sre over at nobi 9 we've got quintessence who's a developer advocate with pagerduty well i know i'm too familiar with pagerduty uh everybody is yes and uh we're gonna bring back april uh april who is a part of uh our our microsoft uh infrastructure and devops team uh where we we talk a lot about these concepts and so i wanted to first start out and and give everybody just a chance to briefly introduce themselves at least alex and and quintessence uh alex why don't you give me uh the quick executive summary yeah uh hi everyone my name is alex dalgo i'm the director of site reliability engineering at noble9 and author of the slow book i've been a site reliability engineer for 12 years now i believe and uh it's really kind of you know a profession that really lines up with my personality um and over that time my primary interests have really always been incident command and observability uh so i'm very happy to be here today awesome thank you so much alex and i i really do appreciate you being here and uh quintessence is next hi quintessence thank you so much for being part of this executive summary as well executive summary so i am currently a developer advocate at pagerduty i got here by way of a very circuitous path and tech that included tech support in a hardware lab database administration cloud engineering uh infrastructure engineering and whatever as i just kind of meandered my way for about a decade through throughout um located near niagara falls so if y'all ever want to take a nice trip out and and see something really cool we do have an amazing waterfall you might have heard of it and uh i know you've been involved in the devops days community uh taking part in uh devops days buffalo being part of that that team of people that uh really bring that event together and serving that western new york area and and now because of virtual conferences of the world well we did last week at a drive-in wow wow we figured that it started as a joke but then it was like in our january meeting to plan for october vaccines weren't out right and we're like how do we commit to a venue without committing to a venue was the problem to solve and then it was like oh if there's a vaccine or masking or loose requirements or strict requirements we can have people in their car out of their car whatever like actually this might be a joke like we might actually do an in-person conference at a drive-in that'll allow us to have as much flexibility around lockdown non-lockdown procedures as as an event than you possibly could and it went super well also seeing talks on a drive-in screen was really cool awesome i love it uh and then april i want to bring you back just for a second and just say welcome back to the show um i i really appreciate you you coming back here and being part of this panel and i'm actually gonna ask you this question first and uh we'll get into uh taking questions also from our audience if you'd like to use the chat windows that you've got your different services we want to hear what you might want to know but we've got a couple questions ready to go and so the first one i am going to ask and i'll ask you first april is how do you differentiate observability from what is traditionally known as monitoring and i t systems so when we think of monitoring and i spoke a bit about it as well it's in that kind of final phase of deployment right we're monitoring around something i feel like observability is the full end-to-end process so it's not just the monitoring piece but it's how do we track things throughout and have that visual ability throughout so i spoke about a little bit before when i talked about azure boards and the planning tool like we have uh full visibility within the organization what we're doing we have automation built in so we know what's happening and that might be hooking into microsoft teams or whatever chat tools slack etc we use in our organizations um and having that ability of what's going in the whole process and not just the monitoring that's the quote infrastructure and app movement but also the whole process that's in the devops cycle so that's everything end to end in my demo for those of you that tuned in we could track uh the pull request number to what we're doing and you can take that even further by hooking github you know into email notifications into like a chat ops thing where you have it notify a team's channel so for me that observability is in the full end and process in devops not just the monitoring wrap around absolutely and so uh alex i know you've had uh i probably one of the the beginning introductions of sre to the world at your time uh i believe it was at google and and really uh understanding how the process of observability fits in and and so i i i ask you how do you kind of differentiate it from say you know the old style of you know uh putting in nagios or something like that to keep you uh abreast of what's going on yeah i mean the first thing is that one i'm a nerd uh and this means i really kind of love the original definitions of a lot of these things right the concept of of observability existed way before microservices uh it's part of control theory which is you know a way to think about complex systems and you know and we don't forget super in depth there but the point is the original definition i think actually so really holds and monitoring gives you things that you know to look for no knowns or even known unknowns but what really makes observability different is the concept of emergent behavior uh emergent behavior or emergence is is the idea that uh you cannot possibly understand uh the performance or the uh traits that will be exhibited by a complex system until the many components of that system are actually interacting and so monitoring generally means that you have a developer writing the code says i'm going to export this metric all right i'm going to send this time series out i'm going to log this log line i'm going to use this framework to ensure that these 500 metrics are all being emitted from my service and that's awesome and important i actually don't think observability replaces monitoring in any way whatsoever you need all that data but proper observability means having the systems in place having the data available to you in order to explore and locates those emergent behaviors the ones that your developers cannot think about ahead of time the ones that your developers cannot say oh i'm going to add this log line i'm going to add this metric i'm going to export this to our system right these these uh manners in which complex systems and the components of them interact with each other you can never know what they are and observability means being able to track what those potential issues are great um in quintessence i'd love to get your take on this as well i know that pagerduty it's a it's a big part of of that process because you're letting people know when these events happen and so i'm curious about how you differentiate observability from monitoring so it really goes back to a bit of what alex said where if you take a step back and say what is observability and he mentioned control theory briefly and i'm also going to mention it briefly but very specifically we talk about the outputs of a system so when we talk about observability we talk about a highly complex system usually these days right and so you can't really know the state of the the system linearly from a tiny little app you need to actually know what it's outputting in order to know what state it's in so that's observability and if we look at what observability is typically supported i hate pillars it's that whole allergic to buzzword thing but we'll go with it so you have metrics events logs and traces right and if we shift over to monitoring what is monitoring what do you fundamentally monitor normally you're monitoring maybe metrics and also logs right so when you think about it like that monitoring is kind of a subset of observability in the sense that in order to have monitoring function you have to have a system that's at least partially observable but having only monitoring configured by itself does not mean that your system is observable per the previous which is can you actually deduce the state your system's in from monitoring a loan using only metrics and or logs no right you haven't you haven't implemented enough and so i feel like they're less like different than one is a superset of the other awesome i i'm thankful like we we i think have a good kind of groundwork for what we're going to continue to talk about by understanding kind of that that difference and you know um there's been a a term used so far uh complex systems and i really uh think about how complex systems fail the paper by dr richard cook and if if you haven't read it i really recommend it that really made me think a lot more about the implementation of sre in general because i think that complexity begets failure it's it's just a part of how things work in this world and so um because you brought up that term first alex i'm gonna ask you what points of data do you believe have the most relevance in regards to understanding a complex system i mean that's a difficult question and i think it's because complex systems are almost by definition unique i don't think there necessarily is a list you can check off of saying oh i have a complex system here therefore i need to be watching a b c d uh because every situation is going to be different um how these complex systems are composed what their components look like how those behave how they've been introduced what order they've they've been introduced in are all going to really kind of change uh uh what is most important perhaps to be looking at for any system uh unique in and of itself that said i do think that you can kind of identify a subset of things that you need to be looking out for because generally speaking complex systems exist in order to uh they have a goal in mind right we designed them in order to execute a task we as humans design them to do something for us and uh knowing what that output is supposed to be right this kind of goes to what to what quintessence was saying right like the original definitions involved what can you infer about the internals of a system by its outputs uh the best starting place you can have even though you can't have a perfect road map you can't say oh i need this uh the closest you can get i think is to say okay the system was designed to do x and therefore the output should hopefully look like why and that's a great place to start great great so i'll i'll defer next to april um what do you believe are some important data points in a complex system i think they're called complex systems for a reason um and in my career when i worked with engineering uh prior to joining advocacy a lot of my role was breaking down complex systems so um you know just like alex said what is it supposed to output what is it trying to do and how do we get there um and a lot of the times you know it's it's breaking that system down and that's been a hard task and it depends if you're looking to transform it or what you're trying to do with it why are you breaking down why do you need to figure out what it's doing and is it doing what's supposed to um a lot of complex systems that you know most people out there have is because we've built something and it's grown organically over time and we didn't think about how we're going to scale something so i think it's it is such a hard thing to measure and each complex system that i've worked with has always been different and we've had to have different points in which to measure it from and how it works and we have to break it down so for us in the engineering side when i was in the engineering side of microsoft like we really had to break those down and find those and each system was different um it could be very code heavy it could be very infrastructure heavy um each was so different and a lot of times they didn't have quote monitoring around it we didn't have observability around it we knew it didn't x didn't produce y uh or didn't do why it was supposed to and it kind of limped along so we need to figure out why gotcha and and so uh quintessence i'll ask you the same thing um you know what data points do you think are important to kind of track uh in a complex system so it does kind of go back to systems aren't complex so you're not going to be able to have a checklist of data points however complex systems are not unique to i.t it's something that we borrowed you know mathematically speaking from gestures vaguely right when we're you know when you're in certain levels of mathematics you do a lot of modeling around species and populations for complex systems and and whatever and all this is to tie into the fact that there is kind of a definition for like qualifying criteria for what a complex system is and you have numerosity disorder diversity feedback and non-equilibrium and when you're thinking what data points do i need if you understand those four to five depending on how you separate them out points you can start to say what data am i outputting that tells me these different criteria so i can see how complex my system is so like numerosity is how many things do i have microservices dependencies whatever whatever you define thing as and then you have diversity how many different things do i have do i have a dozen microservices and five libraries whatever and as you go down the list what is equilibrium and non-equilibrium state and this goes into like you know monitoring percentiles and exceeds the soap of the question a little bit but when you start to think of how i understand what a complex system is and you start funneling data back up in now you can start asking questions to tell you what type of data you should be focusing on um so less prescriptive then please check your you know inbound traffic but but it does tell you if if you do need to check for that like where it falls under when you're trying to figure out your complexity you really need you also need to check randomness and that is how chaotic is your system um and that chaos experience is great for that but and you just led into my next question you're welcome you know so you mentioned chaos and and chaos engineering has become a really uh big another buzzword if you will um and and it's actually become a great way of finding problems and using observability before the problems actually impact production and so i i'll ask you quintessence how do you feel that testing in production fits in to this whole kind of observing observability as opposed to just standard monitoring uh i'll say what everyone else probably also says you're always testing a production whether you mean to be or not i feel like i have to say it someone else will so i beat you both to it sorry um intentional testing and production uh mostly you need to make sure you're doing a lot of pre-work because even when you talk to talk about like chaos experiments or things that can be done to kind of give you more reactive outputs to check for than you thought to the whole no no no unknown a non-unknown problem where you you start to know what to track but then you need something to tell you what else you're not tracking you don't want to just start running chaos experiments in production um without running them endeavor staging first so a lot of the testing and production when you're doing it intentionally kind of goes through this planned phasing of even though they're smaller but hopefully mirrored versions of production you roughly know the radius of impact of everything and that is to say you don't want to be in a situation where you think you're testing something that's confined to us east we're just going to use aws why not us east and then all of a sudden it's creeping up in apj over here you're just like i didn't think these were talking to each other and now i can't shut it down i can't shut down the experiment because i didn't plan it out yeah so uh april how do you think testing and production fits into the observability story well i think contestants summed it up well um you're always testing production and i think this is where it's important to have like for like systems um you know we've seen a lot of customers that are like oh yeah we found this thing in production but dev test or staging looked completely different than the production environment and i'm like well you're not testing in production you're actually testing something live that your end users are seeing so you really have to think about how are you testing it you know you want to test any small you know you want to either use feature flags or use different environments that are like for like and how you can replicate that and i think we see a lot of people that don't have that setup and will test and aren't actually then just scared to do things in production and that is difficult because they're not getting that feedback mechanism but those that are willing to test in quote production or something that's like for like they're getting that feedback earlier and they're having that identical system and i think that's really key to getting that feedback and addressing it because i think also when we talk about these big complex systems if we're then doing these things you know three months past or six months past we don't know how to fix them so this has to be done incrementally if we are doing that in in a direct production environment great great and alex i'll give you a chance to kind of give your thoughts on testing and production as well yeah so i i think it fits into the observability story because uh they both kind of have the same aim they they they they also the same goal an observable system you build more observability into your systems again to go back to uh uh uh identifying emergent behaviors things that you hadn't thought of ahead of time things that you hadn't already planned for and that's what testing the production that's what chaos engineering that's what experimentation gets you as well it exposes new ways that your components may interact and new failure modes for those components and your complex system overall and you know if you don't have observability you may not even be able to notice those things uh something may break and you have no clue why so you're running experiment x and thing y happens if you don't have proper observability you learn nothing from it right you do know that x causes y but you don't know why x causes y absolutely absolutely very very cool and so you know we we've covered a couple things and and uh i i will ask you alex to kind of bounce off that someone wanted to know uh does chaos engineering is is it even considered a part of observability uh are they related and i i personally think they are i think that you know reducing failure improving reliability of complex systems is is kind of one in hand uh with the other yeah i mean i think they relate in the way i just kind of mentioned right like uh you need proper observability otherwise your chaos engineering work is not not gonna be very useful or at least not as useful as it possibly could be um i don't necessarily consider chaos engineering or continuous verification uh is a is a recent term to encompass this part of this that that i really like i don't know if it's necessarily part of observability um but uh you can't do one well without the other sure absolutely uh well you know i i've got about uh i guess maybe one or two questions left and i'm going to ask a lightning round here around uh tooling uh so quintester's what type of tools can help best uh identify problems uh before they impact end users so it's really it's less about very specific tools like useless vendor etc and more about again understanding what you're trying to gather so when we go back to like metrics events logging and tracing choose a tool that does one or more of these things well and by well understand what you're outputting and know how unique you are and how normal you are to everybody else so that you can say okay does am i an edge case and does this vendor like meet that need or do i very specifically need to use this specific person because we're doing something wonky for whatever reason wonky highly technical term right um so when you're looking at just make sure that you're supporting all of those and the reason it's it's good to balance tool explosion with what you're putting into the tool is because you don't want to do the tab thing where you're like data crawling through your system and you have like five tabs open and you're like this correlates to this and this correlates to this um so having it reasonably consolidated and accessible to the whole team and by that i mean don't just make it so infrequency and for things and front-end can see front-end things because they'll need to talk to each other right so everybody kind of needs access to the same level of data for the most part unless there's like a secure reason to not do that um yeah that's really why with it so alex i'll ask you i know that you know as a person involved in sre you implementing this type of tooling to actually keep an eye on the observability and health of your applications is big um what do you think is an important tool that people can implement math just understanding that that there are models that have been created uh decades sometimes centuries ago um to better understand what data you're actually collecting it's very easy to extract a bunch of telemetry from your systems uh well not always easy sometimes that is difficult but uh you know but then you have all these numbers and you have all this data you have all those telemetry and what do you do with it and just having a basic understanding of basic statistics you know uh regressions uh you know correlation analysis uh even something a little higher level like using service level objectives right uh uh something that kind of uh provides you a summary overview of things as as opposed to just having you know tens of thousands of time series you know like that you don't know what to do with um you know i've i've learned more math uh post-college than i ever did in college you know like at this point and you know i'm certainly not an expert because i use programming languages to actually do the math for me but i think it's very important to at least understand what kind of models exist what kind of formulae you have available to you to better understand what's actually going on great great um april what do you what tools do you think can best help people out and again i think specific tooling is there there's so many out there and you have to find the tool that's best fit for what you're trying to do and i think my biggest piece of advice to organizations and people out there use the same tooling across the different groups in your org i've worked with different organizations that use like 16 different tools like which one should we use or how do you do it in this tool and like why are using 16 different tools i'm like oh we let each group pick their tooling so there's no continuity so the data they're collecting is just data and it's not going anywhere um and i think it's really important to look at the data know how to you know what you're looking at so you have a baseline so whatever it is you are trying to improve upon you need a baseline bit of data you know how to improve it and where it's going that gives you a starting point but i think getting in in similar working tools across your different teams is really critical and then doing something with that data and there are so many tools out there um and again quintessence said it you have to kind of make a list of what does your organization need what do they need to what they need to get out of it what kind of things are they looking at um and you have to find the tool that's best fit for the organization but you have to use it and use it properly great so we've only got about you know four minutes left or so um and so i wanted to ask each of you in in just succinctly as as what you would give as far as advice to somebody who's implementing observability and um april i'll let you kind of kick that one off no pressure um my advice is find the right tool that's that's right for for you and your teams uh implement it early start gathering metrics use that data um and and you know again we say in devops fail fast start using it find what works find what doesn't uh and move forward great um quintessence would you like to kind of give your your take on this i'm going to echo what alex actually said about using math the idea a really easy example low hanging fruit is percentiles right know what the numbers mean so if you say oh i'm using averages that means you're in your good state 50 of time if your slo is 99 it doesn't help you so knowing the math for why you're making the decisions to watch what you're watching and gather what you're gathering will really help you both in terms of what things you're going to be outputting from your system and thus drive what decisions you make about what it's getting put into absolutely alex so last i i'll ask you to kind of give us that same quick answer yeah i mean i have a lot of opinions here because i've been on pretty observability focused teams for last six or seven years my career eight maybe even um so i wanna answer from a business perspective uh these systems are expensive and are likely going to be your busiest if you're not using a vendor right if like if you're building something in-house because everything else everything else you run has to talk to those systems and has to send them data so i don't care how huge and important your primary web app is the observability tools behind it your logging systems your metric systems your tracing systems you know like your production event change logging systems whatever they may be they're going to be busier they're going to be more difficult to maintain than your primary you know profit driving you know web application so that's the right resources in both money and humans well thank you mr slo i do really appreciate that answer um i think we've had a great time having this conversation um i'm gonna start getting ready to say goodbye to uh two of our speakers one of them is gonna stick around uh but alex where can people get in touch with you on the internet uh find me on twitter uh i use it too much probably uh but you can find me at aedalgo sre and uh go check out what we're doing at noble9 at nobl9.com very very cool and april i know you've got the devops lab and lots of other things going on i know that that's coming back in a couple of weeks any other way people can reach you on the internet yeah uh everyone can follow the devops lab on twitter uh we have a youtube channel feel free to reach out to me uh via twitter or linkedin uh if you send me an email it will go down a black hole well i guess you and cat have a lot of things in common as far as your emails are concerned and so i will say uh goodbye to april goodbye to alex thank you both so much uh for joining myself and quintessence here i think that uh i really enjoyed this conversation and the conversation will continue um we are getting through this we are so deep into this whole create devops thing quintessence and uh we've got a great keynote that's going to close up the the talks portion of today that you're going to be doing with uh my my buddy stephen uh talking about beyond the scope of development and operations and i know you know devops itself it's it's over a decade old yeah you know and there have been so many changes to not just the process but the tooling and the culture has moved ahead as well hey steven hey that was a wonderful panel and and i'm looking forward to seeing uh kind of uh hearing a little bit more from note because yeah i i'm i'm old you can see that and so i've been around for a whole lot of this devops uh the evolution of devops and kind of where it's gone over the past 10 years and how it matched a lot of what my career looked like and so i i just i love the space i i love hearing more about it so i can't wait to hear i can't wait to hear what you have to say yeah so let me go ahead and share my screen here let's see what it's gonna let me do there it is all right hopefully yeah all right okay and so i'm gonna be talking today at devstar asterisk ops and i'm talking a little bit about going beyond the scope of development and operations and in order to get started kind of keeping an alignment with what cat did i want to talk about what devops is very succinctly and not just you know presume age age or not so devops started to coalesce around 2008 trying to solve the problem of siloed workflows the most famous and like storyboarded form of this is the phoenix project if you're newer to devops and you're new enough that you don't know what the before world was like i recommend taking a look at the book because that's the thing that everyone really references when when they start to talk about how friction full things can get but what was ultimately being solved for was communication issues you had a dev team building you know the mobile apps and the back ends and the front end and it was vaulting over to operations that had to push things live and do other attacks around the supporting infra and this faulty behavior caused a lot of friction people didn't communicate well and because their backgrounds were disparate and by that i mean dev didn't really know why or how operations did what they did and vice versa they couldn't really contextualize what they sent over or think ahead and say what would this team need for me and again vice versa ops couldn't offer that back now as much as there is a certain beauty to working in a temporary silo you can see how when you scale it out it's a problem temporary silo you get focus time permanent silo you get groups that can't talk to each other and that's not great it causes all that lack of understanding what i would like to do is roll back and it looks like oh no it's still there okay roll back for a minute and talk about what devops is kind of more abstractly so before we talk about devenops kind of being that union point between development and operations and if you ever look up a devops diagram you'll see this very familiar-ish infinity diagram with the dove side and the upside and then the union in the middle is where everyone's focusing on those handoffs and that mutual understanding when we talk about that though we're really talking about project management pipelining automation observability continuous feedback and collaboration these are things that devops was designed to solve for but if we start to go back to what i was gonna i'm really gonna focus on for the next little bit here is about neither dev nor ops right kat talked about it a little bit earlier with devsecops where people like to talk about integrating security into the workflow and i have things to say about that but i'm also going to talk about data science for a hot second and explain why i chose these two things so first of all why we're not talking about neither dev more operations and starting with security security has always had an important role in the release of software it's not like security suddenly appeared when devsecops started to gain traction what did start to gain traction was a formalized way to integrate them in the process and again when you're looking at a devsecops diagram which this is not i'll get to this in a second you're looking at devops remember it's an infinity diagram with a dev side and the op side when you look at a devsecops diagram a very simple one it just wraps security around the whole infinity shape and that's all it does when we tie that in with this idea of a secure development life cycle we can see more to what what cat was talking about with regards to integration you're integrating security you're not just appending you know an affinity and then another plus shape over here you're really wrapping it around you're putting it over the whole process i'm using this as a prescriptive example to try and show kind of what that means instead of just hand waving that it wraps the whole cycle and when you look at the secure software development life cycle you can see the familiar pieces running along the top pipelining and automation and runtime and everything and underneath that you can see very prescriptive examples of what security can do at those phases which is why you're not just shifting left in the sense that you do something at the beginning and then stop you're doing something at the beginning and then continuing to do different some things across the whole life cycle and i want to start with this because again going back to devops we remember what this looks like we can see that security is doing all these things security has its own project management it may or may not be agile as we associate it with either diver operations but they have to manage projects in order to get this accomplished they're doing pipelines some of these tests are put into pipelines some of them are not some of them are automated and some of them are not you have to have observability and monitoring to make sure that you don't have a secure incident and so on and so forth and you can see that this runs very parallel and some of this gets a little intuitive so the reason i'm talking about beyond dev and ops for dev astrix ops is that there are more parallels between the different disciplines than just dev and ops than the name maybe implies i'm pivoting for a minute let's talk about data science and the reason i'm talking about data science is to choose a technical discipline that we do in fact interact with but that doesn't have a uh unless a buzz word lovingly attached to it it's not devsecops right or when you look at network engineering i think there's net devops or devnet ops or something like that there are other terms that devops that gets concat with devops for other teams but data science isn't really one however when you start to research data science as an outsider you'll realize a few things just like people in devon ops they spend a lot of time getting requirements and planning their work which starts to feel very familiar and in their case they also spend a lot of time figuring out what data to gather to meet those requirements and how to clean it and to really kind of dive a little bit into what i mean by that since i'm intentionally choosing a less familiar group let's say they're working on a salary survey so i mean that's i think well understood outside of you know just we all make salaries right you need to know what questions to ask and you need to know how clearly to ask them or else you're going to run into situations like people putting things in the wrong currency or people assuming that you're doing things in a salary versus an hourly or an hourly versus a salary and then you don't know what data you're converting so there's a lot of cleaning that's involved because more likely than not you're still going to get some errors in the data for these reasons and possibly others people might enter 80 instead of 80 000 in some currency they might enter the wrong currency right if they don't know you're trying to level set across something if you're not limiting a survey to a specific geography it could look like the max and min values for a certain role are very broad but that might actually not be true in practicality because some countries have nationalized health care some don't some are compensating for that some aren't and you know we keep going down this list and this is just for something as relatively simple as a salary survey but when you think about it development operations and other groups are working with data science more and more because every time there's a product released with machine learning or ai ops you're involving a data science team and when you're working with them now they're taking some of the experience that dev and ops have with regards to how to train the same data sets except instead of salaries now we're talking about maybe something about observability maybe we're talking about metrics and metrics behavior and going back to questions that were asked in the panel you know we have people who are saying how do you know that something's going to be production impacting well you start to learn and learn for a machine is a very different thing than for a human but you start to identify these precursor behaviors in your environment so that you get notified on them before you get notified about outage hopefully right and this is all stuff that falls under the purview of data science now you might be thinking to yourself that's great and you might be wondering why i'm talking about it quite this way and the reason i'm talking about this is because both of these groups have been typically viewed as kind of outside of the dev and ops workflows but we work with them right security maybe more directly and then we go right into the data science where there's on the one side in security there's a normalization for security now but in data science there's less so but it's becoming more and more the reason we want to be able to abstract away what devops is and how we implement it is so that we can avoid the friction that we've had between dive and ops and then between devops and security when we start to go into other groups like data science and we can say this is how we're similar and how we're different and if we start making that skill very flexible we should be able to integrate with anyone even librarians which is why i just love this image i just i do but the idea know how your workflows can integrate with the others and with that i am throwing up if you want to see the slide deck it is on the link that's on the page and i'm available for questions here i'm also available on twitter all that info is on the slide there oh very very cool quintessence i i love the how you start out with like kind of like the you know the dev star ops uh back when i worked at stack overflow uh with uh tom lemoncelli yeah he would always say starops right because it was always like trying to figure out how it you know development operations have to work work together but how do we also work with the other parts of our organization and so i i love i love hearing um your thoughts on on that as well uh we did have a couple questions come in and let's see so we have um that where do you see the future of devops going uh everything is code i feel like these are slightly different things so we have devops which is the cultural practice of integrating workflows and then the code movement which is solving a very separate set of problems so when you're talking about things as code most normally things as code is really mostly translating to infrastructure as code or infrastructure as software um i would say that these are separate things that are both happening and we we use devops because it's what works for us very loosely defined as development operations in other i.t adjacent disciplines and then insofar as code as we hit scale we had a very specific set of problems that we did not have before so i know when i was doing for example dba work we didn't have much with regards to to things as code and there was a lot of wysiwyg and you would set things for the networking or whatever and then you would have to document what you set because there wasn't a way at the time to interact with it and then we had code and now you can do things like terraform and you can write up what the settings are and now and now you have something that's documented and version controlled and at least you have that but now as complexity continues to move forward now you need conditionals and some on all sorts of other things so that you can have a common set of of requirements that are going through am i in production or staging or where am i and make different decisions like that um so everything is code is really more of a complexity problem and devops or dev asterix ops is really more of a how do we as i t professionals with distinct disciplines work with each other okay wonderful so we have just a couple of minutes left and we've got one other good question i think here do we think that sre will make devops irrelevant again slightly different things slightly different things so so devops is about getting two different group groups to work together sre is a specific set of codified practices what sorry oh yeah i i i love that i get to lob these questions at somebody else instead of them coming to me for a change so oh i get you i get you yeah so site reliability engineering is really a codified set of practices for for how you run things highly technical term in production that's that's really the goal how to run something how to keep it running um devops is still focused on the cultural aspects so sre might be fundamentally people with for example an infrastructure background but those infrastructure people working with the mobile developers would be devops right and then them actually running the mobile site or or whatever would be sre right yep so they're not going to make each other irrelevant they're just going to keep running in parallel yeah i think with what what some people find um conflicting maybe because these two things have evolved around the same period of time and there's there's overlap in the perceived you know coverage of them but yeah devops definitely leans more heavily into the culture of how do the how do teams work together where sre is it tends to be a much more focused uh a much more focused and prescriptive way of approaching approaching operations uh you know as you described so with that thank you so much for for all you've shared with us today uh both in the panel and and the closing keynote um let's bring jay on back here and um we have one more thing for everybody and that's coming up yet we have our workshop so you've stuck around [Music] yep you stuck around you did the hard work go ahead stephen stephen you're breaking up a little so i'm just gonna so now we've got coming up next a workshop and let's bring that up there you thank you very much uh it's a hands-on workshop that we're going to be doing that's about deploying bicep templates with github actions we april touched on what bicep is briefly and marcus is actually going to give us some more detail on how there's been an evolution around arm templates and how they've changed uh azure resource manager templates uh hey marcus how are you today hey jay doing great great do you want to give us a little intro like executive summary of who you are what you do yeah sure so uh hi everybody my name is marcus felling i'm a pm from microsoft's developer division i've been helping with bicep recently which i'm excited to tell you all about great great so um you know i i think the next big thing that we're going to do is uh start working on our our workshop and and to get started with our workshop um i know we've got some slides stephen um has has got up here and and so this workshop today is going to be focused on how we can uh get our apps deployed um and and do that securely and do that automate with an automated process utilizing github actions uh and and bicep templates uh so we're gonna remind you all that there's there's tons to do here um and if you don't necessarily have the time to do it all right now this is recorded and it's well documented we'll show you the repo in just a second um so why don't we jump into it what do you say stephen sounds good and just to remind everybody that um if you're participating and sharing information out on twitter or your other social channels of choice don't forget to tag microsoft create learn tv and tag your stuff with a hashtag all right so uh we still are under the same code of conduct as we were for the rest for the previous event but jay why don't you run us down our agenda here sure so we've got a couple things that we're going to be doing today first we're going to be reviewing the components of our um our total workshop we're going to be talking about how to configure our dependencies we're going to secure it all with key vault and then we're eventually going to deploy our app to azure kubernetes service and so there are a few prerequisites steve that we need everybody to make sure that they've done if you want to go ahead and move us forward um the the uh prerequisites are an ssh public key uh we'll show you pretty quickly how to make one uh we're going to ask you to use the template uses a is an interesting term that they use but uh you're going to use the template make sure that you've signed up for azure and get your 200 free credit and then eventually you're going to clone the application locally i'm going to be using visual studio code or you can use the azure cloud shell to do a lot of the things that we're doing today and so um if you move forward we'll just remind you you could sign up for azure you can go to aka.ms cda free azure um that way you sign up next we want to remind you that there is a bicep and uh i should call it the aks bicep workshop uh that you can go to the repository right now and uh what you want to do is you see that green button you're going to want to click that green button and and what you'll be able to do is use the template when you use the template it's going to create a copy for yourself it's not necessarily like forking it it's just going to create a template and if you move forward you'll see it it'll create a new repository for aks bicep workshop or whatever you decide to name your uh your repo and and we're going to be creating uh a demo application that is pretty regularly available uh within azure it's just a simple voting application uh it's using redis on the back right back end and i believe it uses a dotnet api that is front-ended by some javascript and so um rather than uh waste time i think it's time we get into the big idea uh marcus has got some information for us um why don't you kick us off marcus and answer the question of what is bicep yeah let's do it um if i could get those slides back up on the screen this is not the right screen uh if we could share stephen my slides all right all right there we go all right so let's start out with uh you know just describe describing what exactly azure bicep is so um it's a domain specific language for deploying azure resources declaratively so you can also think of it as the next generation of arm templates which you've you've worked with in the past you know come with the burden of working with with json right so bicep has a simpler syntax compared to the arm template json with none of the json noise so it's really aimed at simplifying that authoring experience a good analogy for understanding the relationship between bicep and arm would be similar to the relationship between typescript and javascript where typescript is bicep and javascript is arm so bicep transpiles down to standard arm template json files which means the arm json is effectively being treated as an intermediate language all this work is being done in open source fashion out on github it's been open source pretty much since day one we wanted to get the community involved as soon as possible to really help shape the future of the product so bicep has a really readable and writable syntax similar to arm templates and terraform bicep is a declarative language where you say what you want and then azure kind of just makes it so opposed to imperative approaches such as the azure cli or powershell that would require you to tell azure how to do things kind of procedurally so with bicep you know you don't need to worry about the complexities of the how with modules you can break your bicep code into manageable chunks this is a way better experience compared to linked templates and arm templates if you've used that in the past modules are super easy to consume bicep has a first class authoring experience which i'll demo here shortly uh it has features like rich type safety validation intellisense and a number of other features that i'll highlight bicep also offers a decompile command so you can take any arm template and it'll convert it into bicep code for you you know that way if you've invested in arm templates over the years you're not starting from scratch if you want to start using bicep today so these are some of the reasons to choose bicep over other declarative tools i have a blog post that goes into more detail on each of these with the link at the bottom of the slide there with tools like terraform there's there's potential for a delay between new azure resources being released and them being available to to use and consume with bicep new resources are supported immediately and there's no need to wait for them to be added to the provider with bicep the state is managed by azure so there's no need to manage state files like in terraform azure really is the state you can query it at any time when deploying a bicep template there is pre-flight validation on the entire template so you can fail fast resource manager checks the template before starting the deployment to make sure the deployment will succeed and because of that you know your deployment is less likely to stop in a half half-finished state bunch of really great tooling the vs code extension like i mentioned there's integration with the azure cli and azure powershell we have the bicep playground you can use to experiment with bicep without needing to install anything the azure cli integration is really slick you don't even need to download and install bicep it'll download and install it on the fly when you issue a bicep command and then the last note on this slide it's fully supported by microsoft support plans so i know uh you have a little something to show us as far as how uh everything is demoed yep if i could get my screen sharing up there we go all right so i'll just um you know highlight some of the features the vs code extension has to offer that really makes authoring bicep code a first class experience so we can start out by searching the marketplace for the bicep extension here i already have it installed if i didn't have it installed then i start authoring a dot bicep extension file it'll vs code will suggest that i install it so now that i have this installed i can start in my zero dot bicep file and the first feature i'll highlight is is snippets so say i want an aks cluster i can start typing aks and you'll see there's a snippet available so i'll click enter and then i can tab through this and set these properties and you'll see on on these properties i'm getting some pretty cool intellisense here so i don't need to guess and go look at the docs to see what i would want set i can also hover over all the properties and get a description of what they mean so pretty cool this gets me up and running pretty quickly so i don't need to start from scratch there's a ton of resources that have snippets there's a long list here you can even go and contribute your own snippet by going to our github repo right at the r at the root of the repo there's a contribution guide with instructions on how to do so so pretty cool stuff here similarly we have scaffolding so if i define a resource type here like an alert rule i can use a feature called required properties and this will look at the resource types uh swagger api spec and and it will tell me all of the properties that are required so i can get up and running very quickly all right here i have a bicep template as you can see it's getting pretty long this is the first time i've looked at this template i'm going to right click on this and use the visualizer that way i can get a good visual representation of all the resources i'm creating in this template as well as the dependencies between them it's a pretty cool stuff and then next up i have uh the linter so this is going to inspect my code as i'm typing and catch a customizable set of authoring best practices for me so as you can see i have a bunch of squigglies that indicate i have some linter rule violations i have the option to set certain rules as warnings errors or disable them all together i can configure all of this so if we start at the top here i hover i get a description on this winter rule violation it's telling me i shouldn't hard code a password you know that's probably a good idea i'm going to check this into source control i wouldn't want to do that i'm going to use the quick fix which most linter rules have here and that'll clean it up for me next up i have a parameter that's declared but it's not actually used anywhere so again i'm going to clean that up as well kind of work my way down here i have two more warnings left if i hover over this it's telling me i don't really need to use string interpolation it's not necessary i can just reference this parameter name directly i might not know what that means so again i'll use the quick fix to help me out there and then the last one down here i'm using the concat function for my automation job schedule name again you know string interpolation is preferred for this one it's a little bit cleaner syntax use the quick fix and show you what that looks like all right cool so i have this template all fixed up looks like my warnings are all gone so the last step i'm going to take is right-click build so this will run the bicep build command for me so i don't need to craft a command at the the command line and it will ensure that the transpilation process is successful all right and that's all i have for my demo so i'll hand it back to you jay that was that was really cool marcus um i i hadn't actually seen the visualizer uh before so um i like that do we lose uh do we lose j possibly we can go back to the slides and um so until jay gets back i can continue on we can talk a little bit about github actions now um github actions are going to be one of we've talked a little bit about them throughout the day here but we're going to really take advantage of these things as part of this workshop now github actions it's not just ci cd it's world class ci cd but it's not just ci cd it's automation for any workflow that we want to do around things that happen in our project on github right so right we can comment on an issue we could use it when somebody forks our repo or even just on the regular schedule there's dozens of different events that we can use to trigger workflows now this in addition to all of that it is really good for ci cds so we can deploy things almost anywhere now jay did you want to pick up or you want me to continue rolling on here with sure we actually can go ahead and start really getting into the demo so uh marcus is gonna stick around um and help us if we need a round bicep but uh why don't we bring up my screen and let's just jump into it because uh we've got you know only so much time left and i want to go over what exactly uh we're doing here and so we're going to be using azure kubernetes service as well and aks is a hosted kubernetes service a key vault it's another great service you can get full descriptions in the repo you can see uh key vault per text cryptographic keys certs and secrets and so what we're going to do is is create a few of these put them all together and then utilize a bicep template to actually kick off the creation of our infrastructure and then after we and you can see here on the left side just make it a little bigger for you we've got all these uh parameters that are actually going to be called from a parameters file that we would normally use with arm but as you can see the syntax within this bicep template if you've used a arm template before you can see it's a little bit simplified so we have things like we're creating our os um and specifying what disk size there is uh we're giving a username we're also giving an rss an sshrsa public key and if you haven't created a public key yet it really is as simple as running this command sss h key gen minus m uh m t rsa minus b 4096 and it'll actually encrypt an ssh key uh in 4096 bits and then eventually allow you to save it i've already got an rss an rsa ssh key created i don't need to do that so as i mentioned before uh what we've done is we've used the template this uh aks bicep template and i've gone ahead and i've created my own uh and that is just called aks bicep create and uh that that's gonna allow me to utilize github actions so that we can actually run our deployment so i'm just going to scroll down and show you we've we've gone ahead we've taken care of our ssh public key and we used the template uh we've signed up for azure and then what i've done is i've cloned the repo here in uh vs code so you can see everything that was in our repository on github is here that includes our deployment workflow for github actions so you can see that on the right side our deployment file is just some yaml that specifies what we're going to do and how we're going to do it and we've got some environment variables here that we need to go ahead and set and to do that what we're going to do is one we're going to need a resource group a resource group is where we put our stuff uh for azure and so uh i'm gonna just set some variables to do so i'm gonna set my location as east u.s and then i'm going to give a name to the resource group that i'm going to create and in this case it's going to be aks bicep create i'd ask you to please create yours using a unique name because you're going to actually use this as the naming convention for your your actual kubernetes cluster that we're going to create so i've gone ahead over there i've set that um that environment variable uh and what i love about vs code steven right here is this integrated terminal it really makes it easy to work with so uh now we're just gonna create the research group in the shell and what i really recommend you do uh just create uh yourself a scratch file don't commit it to your repo just open up a a scratch file because you're gonna need it along the way and so what i'm gonna do here is uh create the group that we're going to be working with to store all of our resources in uh within azure so it's a z group create and using the azure cli you could also if you'd like to do it within the portal and it's just a matter of like create new resource group next next last and eventually you've got a resource group that's been created um you can see up here in this little tab i've got i've already created my resource group and there we go and one of the things you'll see here is um the the subscription information um that the resource group here and this is all kind of necessary because we need to create what's called a service principle and stephen you want to just give them a succinct explanation of what a service principle is yeah a service principle is is an identity in our azure active directory that we can assign rights to it's not a person the uh the credential is meant can be managed by the azure runtime um uh or um or we can we can uh kind of rotate that on our own schedule but it's just it's a non-person identity that we can use to connect to or let services connect to each other yep so it's it's an authentication piece yep that's it yeah uh so what we're going to be doing here is actually uh creating this uh service principle which is uh just going to be some yaml that's going to be or i should say some json that's output so i've gone ahead and i just copied this particular uh command right here uh i just replaced my app uh and my subscription id and my resource group with what we kind of just came up with to create our resource group and what's great is when you run these commands uh you get the output right here and you can just kind of copy and paste that right into here and so i'm going to create this service principle and what that's going to do and and the reason i say it's important to have some scratch pad set up is what we're going to get is this output of json that's essentially our um our credentials that's going to help us connect uh so don't worry by the time i'm finished you won't be able to use any of this uh so i'm not necessarily gonna have to worry about security that much but you know as we kept saying worry about security the whole way and so um i know that we we mentioned earlier that we can in in one of the sessions before the github actions allows you to actually create some environment variables within uh to have some secrets and that's going to be able to call these environment variables along the way so we have here in our workflow you can see secrets.azure.rg we actually need to create that in order for us to be able to use that so i'm going to open up a new browser and then what we're going to do uh just sorry about that i need to just bring that over here so what i need to do is uh follow this procedure of creating these uh three environment variables so we have three that are needed as your credentials as your rg and as your subscription um and and that those are pretty simple to set up and i'm going to show you how to do now so uh what we'll do is click the triple dot we'll go to settings for our repository we'll go here to secrets we've got all these different types of settings for our repository but we're going to go to this one secrets and within secrets excuse me we you see now we can set up action secrets and as it says secrets are an environment variable that are encrypted so we can put this uh encrypted information that we need to have as our environment variables right in here so what we're going to do is click new repository secret we'll create one first for our azure credentials and those are just the service principle in total that we created before so we'll go back to our scratch pop file we'll just copy our service principle and then we'll just paste it in here and click add secret all right then we need to create uh one for our azure resource group because we're just going to be using our resource group as the naming convention uh for our um our cluster and some other portions of the deployment so this is just to kind of simplify uh for today because we're doing a a quick uh demo and so we're going to just be using aks bicep create as our resource group environment variable and then finally our azure subscription id and uh what you can do if you didn't already see it came in our terminal when we created our uh our service principal and our resource group so we just click over there pop this last variable in and what we'll see is we can go and grab our subscription id it's it's always going to be in one of these pieces of json that you uh out get from when you create something so when i created my group i got my subscription id there you can also get your scription uh subscription id right here in the portal i've got mine hidden but what we can do is just copy this and if you don't have something handy in your shell terminal you can do an az account show and that will get you uh the basic information about what you're logged in with and what subscription you're connected so we've gone ahead and we've added our secrets and the next part stephen i know uh you're gonna show us a little bit about is creating a key vault so that we can store some uh important portions of our our our deployment method yeah so we why don't we switch over to steven's screen for a second please yeah so if we start in the azure portal just got a quick little uh walk through here we'll only take us a moment so we can create a key vault resource i mean outside a resource group i can click create i like to search for uh using this using the search here to find what i'm looking for because there's so many different types of things we can create find key vault click create now we could also do this through cli we could do this for bicep um there's really not a whole lot other than giving it a name that we absolutely have to provide to get something up and running now key vaults names need to be unique and we'll hit review create it's going to validate make sure everything can be applied correctly hit create and in very short order we'll have a key vault that's ready to go once we have that key vault ready to go we are set to start adding in adding in the secrets that we want to protect we can start providing access control as to who and what can retrieve those secrets and as to who how we can take advantage of those secrets if we can use them for deployments and things like that i think jay is going to walk us through that part as we set some of the secrets for this demo up in a key vault that jay's got running yep and so let's bring back my screen and what we'll see is i've got my key vault created um it's right in my resource group uh you can go and see at the bottom just click aks bicep it's just the name of my key vault for today and we've got this section here in settings that says secrets so we're going to go into secrets and we need to create uh some parameterized uh secrets so that we can actually access them securely throughout the deployment process and so we've got a parameters file right here and let me just make sure word wrap is or i'll make this a little bigger so you can see these parameter files all have a reference to the keyboard and what we need to do is specify uh the subscription id we have already got that we need to specify the resource group and then the name of the key vault so what i've done is i've just copied that line and i'm going to just paste it into those sections and then we're going to create these parameters that we're going to actually use for or i should say the parameter names we're going to create them as secrets so that we can access them along the way so i'm just going to paste these into the three sections that you can see are in the parameters we've got three parameters here that uh we're going to be setting up as secrets so the first one is this ssh rsa pri public key uh that's gonna make it so the kubernetes clusters that we create if we wanna ssh into them uh into the individual uh nodes and and check what's going on if there's something we can so i'm gonna click generate import uh and the the actual name is going to be uh what the parameter is and um that's ssh rsa public key so i'll just copy that i'll paste it in here and then in here we need to give the value and so we mentioned that we had our public key that we created and the easiest way to kind of grab that if you're using say a unix-based system wsl window is on windows or you can use this mac you can just type cat ssh and then my key name is idrsa.pub and so there's this neat little tool that you can use within a mac it's called pb copy and that's going to actually copy my entire ssh key into my buffer and i can just paste it here into value and um if you would like to you can set an activation date an expiration date so if you have credentials that are only supposed to last a certain amount of time for compliance reasons you can do that here so we'll click create uh the next one we need to create is the service principal client id and so we'll go ahead and we'll click generate import we'll go to name we'll put that in here service principal client id and then we'll get the value from the service principle that we created earlier and that i believe is app id right stephen yes so what we're going to do is just pop in our application id that came along the way when we created our service principle same process click create great and then uh let's create our last parameter that we need and it's the service principle client secret and so that's going to be just the same process of clicking generate import service principle client secret go back to our secrets file or i should set our scratch file grab the password right here pop it into value create and so now we've got these three secrets that have been created successfully that are in azure and can be accessed along the way in our parameter spa so i'm going to go ahead and save that parameters file and now it's going to be part of my source control so we we've got through the part where we've set up our secrets uh we we've created our connection from azure to github so that we can actually run all this uh and have it access so if you need to see how to create a key vault that we just used you can go here in the actual workshop notes you'll see there's a create key vault process we give you instructions how to do it through the portal but you can also do it through azcli or you can use powershell either way and then uh obviously we just went through how to store your credentials the secrets so those are the service principle information that we set up you can get an example of what everything will look like here and then what we did was we updated our azuredeploy.parameters.json file that's this one right here where we actually gave reference to the key vault the resource group uh and our our subscription id and so we did that for the three different parameters we created so sshr is a public key service principle client id and then the service principle secret all right so finally the last part is we're going to just take a look is the the manifests this is the actual file that is called from our bicep template during our deployment or i should say our workflow file it's called from here and we'll talk about our workflow file now our workflow file goes through a series of things that eventually will be run by github actions to do our deployment and as you can see what we've done is we said when a push occurs to at the the repository uh we're going to start one setting our environment variables two we're going to uh specify that we're going to be using azure arm and we're going to build and deploy our application on an ubuntu ubuntu server uh we're going to check out our code that we're going to be using we're going to log into azure and you can see we've got this uh secrets environment variable that we refer to and and that's going to be the actual connection between our credential or i should say our github actions and azure once we're done with that initial connection and we're logged in then we're going to deploy our bicep file and we'll take a quick look at our bicep template in a second we'll set the target uh azure kubernetes service cluster and so that's our azure credentials where uh to get logged in our our cluster name that we are going to create which is just in this case it's just using the name of our resource group and then we we specify what resource group we're going to create our cluster in and uh it's the same environment variable you can see we've got them all here they're just referring back to the secrets that we've created uh and then finally what we're going to do is we're going to use uh coupe ctl to run and apply a manifest that we have here in the deployment file i should say in the manifest directory and a deployment.yaml and that's going to give the instructions to uh what kind of cluster we're going to set up so we're going to create a three node uh kubernetes cluster uh we're going to create the application which has got the back end our back end uh actual image and you can see it's just a public uh redis image uh eventually we get down and we're gonna create our front end and uh same situation uh we're going and we're creating it from a container that's already available in this case uh the azure vote front which is the front end and you can see we've got our resources specifi specified for how much cpu we need memory this is outside of the actual um aks cluster uh specs these are just the the actual amount of specs we're using within our aks and i'll show you how we're going to actually create our aks with bicep uh and i know i'm going through fast because we only got a little bit of time left uh and then the last part of our uh deployment yaml uh for our actions file is creating a service that is essentially a load balancer that forwards our application to port 80 right here all right so we we've got all that ready to go um and and it's all being like uh kicked off by our bicep template the actual infrastructure that we're meeting and uh within here uh we we've got some stuff and so marcus i wanted to just ask you uh can you just give us a quick rundown of like what's going on right in this section around the resource creation yeah so here we're using the resource keyword we're giving it kind of what's called a symbolic name you can think of it like an alias which is where we have aks and then we're referencing the the provider which is microsoft.container service and then we're referencing the resource type which is managed clusters um and and then there's an api version to go along with that and there's also intellisense offered for that so if that looks really super confusing the intellisense can kind of guide you through and so um yeah and then on line 39 um you know we're giving it a name um and we're for that name we're referencing a parameter unique cluster name uh then we're giving it a location which is the region that it will be deployed to and then there's a bunch of properties um that are defined down below i don't know if i need to go through each one no no yeah if we could just go to the top really quick um we can see a whole bunch of parameters um and there's that at symbol um before them which are called decorators so in this case we're setting a lot of descriptions which is just metadata to describe what those parameters are actually doing so so they make it a lot more readable so i can understand what those parameters do great so we've got an understanding now of our bicep template uh we've got our manifest file that is going to be doing our deployment to kubernetes and then we've got our github actions workflow and so to kick off this github actions workflow you can see source control uh the change that we only really needed to make was to our parameters so uh you can see right here um what we typically would want to do and and we're not going to today and i know it's bad as we typically want to create a new branch and then commit this uh change to our new branch and then have it go through a process of uh review from one of our peers make sure everything looks right and then go through the merging process but because today uh we only have limited time we're going to go ahead and push directly to mat the main branch so i'm going to click here in vs code uh on the source control tab the plus that's gonna stage our changes and then what i'm going to do is go ahead and click commit all it's going to ask me for a commit message and in this case i'll just say params and deploy and then i click sync changes and so once those are synced back to github let's make this nice and big so we can all see once this is back to github we're now going to have an action kicked off and deployed and it's already started so we can see here in github actions and that's right here in the actions tab of our repository params and deploy if i click that oh it failed why did it fail ah there's something wrong with my credentials well i'm gonna go ahead and pivot to one i've already got created uh thank you very much for living with sometimes you you do it you do it live and it it acts funny uh so let's go ahead and go over here uh yeah uh this happens like i said when you do it you do it live sometimes let me go into it here we go aks bicep template actions all right well we'll go through this and uh and i'll find a working one uh stephen do you want to talk about uh what goes on here in a failed version yeah so um actually i'm going to just check i might have a working one here uh let's see nope i did not uh kick mine off locally all right so what we've got going on in just a second i i know i have one that's working so so what we have going on is um make this a little bigger so i can see your screen um we start with setting up the job right so the the actions runner is going to pull down some information from the you know from the job dispatcher and set up environment variables it's going to gather some information about the running about the runner environment it's going to download any of the actions that it needs to run your workflow and then we start running then we start one of the most common first steps that we see is a checkout and that's going to clone your repository and make sure we're check that we've checked out the current version what depending on what's kicked off the build if it's a pull request it's going to check out the code for that specific pull request if we're running off of a branch it's going to pull whatever the head of that branch is i got to work in one here for us oh awesome right there we go and oh and so once we have that working uh that checkout of our current branch that we're that we're working on we can move into the azure login right and and that's where we were bumping into a credential problem before but this makes sure that we're connected to azure and jay did you want to pick up and continue or you want me to keep sure rolling through and so then it goes through the deployment process and that deployment process will go ahead it will run the azure arm deploy pro or the azure arm deploy action within our workflow file and our action actually says we're going to specify our subscription id our resource group our template the parameters file uh the cluster name the resource group that it exists in the name space within kubernetes and uh our app name uh eventually it's going to complete that it's going to uh run the kube config so uh our crew ctl process can happen and what it'll do is it will go ahead and apply to that vodap prod namespace the manifest that we have and so you can see namespace created so jay um just one thing i want to mention about the the uh context set sure that's taking advantage of uh of some of the overlap with uh the azure kubernetes service and the azure cli and you and uses that to set up your cube cuddle command which is a completely separate command uh to be authenticated to you okay uh okay i lost stephen first oh got you back oh sorry i was just saying that the easy uh that the uh the set context step uses the easy cli to get the context information for your kubernetes cluster so you don't have to worry about setting up any of that authentication that's all handled on the azure side for you and then makes it available to your coupe cuddle command to then go and set uh and set up what you need to in the next steps yep so we're going to go ahead and see we've got this kubernetes cluster that's up and running i've got one that i already created and what we need to do is actually log into it and so what we can do uh is click the name uh we'll we'll see right here the resource group name all the other information i need to go ahead and get the credentials and so i'm just gonna bring up a new terminal make it larger so you can see the process of going into crew cuddle uh and running the command so what i will do is go back to our template and you're gonna see at the bottom i've got this cube cuddle command uh that is is first by our our get credentials process and so this is just an azure cli command for the aks uh service we're going to give it our name which is just aks bicep that's the name of our resource group excuse me the name of our actual cluster then we'll give the name of our resource group that is aks bicep i think you're missing a dash between resource and group oh yeah oh yeah there we go preparing from thank you and so then what we'll do is it will log into azure oh go under aks bicep was not found let's double check the name uh and like i said it's always great when you do it live okay so it's called vote app prod uh because i did this earlier so i'm just gonna change the name thank you all for being patient like i said at the live workshop these things happen uh and so i've got some kube configs already installed on my local machine so i'm just going to overwrite it and i've merged that into my coop config and what i can do now is get my name spaces and services and so we'll get all the services that are available and that's where our load balancer ip can be found here in azure vote front so we can just copy our ip address and here's our application and so i could take that ip i can create a dns name for it um whatever else we need to do so that that's the gist of this that is a run through and i know it was a little frantic but we only had so much time to do it um definitely oh i think we i think we lost jay again um why don't we pop back to the slide deck and uh and we've got some follow-on resources for everybody here yep uh sorry about that you know oh my computer uh rage quit on me uh all right um so we we've got some closing resources steven why don't you kind of kick us off on what's next yeah so um so now we've gotten through the workshop uh we can if you want to follow and find some more things about devops we've got the devops resource center you can find that at aka.ms all dash things dash devops and there are there's stuff about process there's stuff about our transformation there's stuff about source control agile all the things that you care about devops great place to get started learning absolutely uh and uh of course if you'd like to also get certified uh getting started devops that's an aks link right there uh designing and implementing devops solutions another uh great one right there that you can use uh that there's so much that you can learn through free learning uh with microsoft uh so you can get on your road to being certified um and i think steven is that it oh yeah yep so yeah there's lots of other free learning resources on microsoft learn including and i saw this come up actually in one of the comments there is a great learning path on bicep uh actually there's several learning paths on bicep at microsoft learn so if you want to get hands-on with bicep from how bicep works to how you use it in the cicd environment you're going to find resources on microsoft learn for that uh marcus any any final words anything you want to share with anybody before we have to wrap up for today uh no yeah like stephen said go check out the microsoft learn modules and bicep it's a great way to get started um we can post some more links in chat as well to some of the follow-up comments here but yeah that's all i got um and so you know that that kind of closes out this portion our little workshop that we've done like i said uh thank you for being patient with us uh when you do it live uh especially all this virtual stuff you you kind of you go through it uh and and that that's what it is but i'm glad we got through it we showed you how to get all the different components created uh and now we're ready to kind of learn more and so one of the things i want you to remem remember about this workshop is that these were just real basic getting started things that includes this bicep um that bicep template was very very basic and so you've done all this you've worked through the process and now congratulations you've earned the builder azure hero badger so why don't you go ahead take out your phone take a screenshot maybe so you can get back to it and uh scan that qr code you can get your azure hero badger badge uh as as a builder you've gone ahead you've built something with azure so go ahead and and click that now and then um also you'll want to be able to go and make sure that your tree has been uh um planted and get your uh your your sticker and certification because you've completed this and on your behalf we have planned a tree because we find that uh we want to get more and more carbon negative get towards net zero if you will so that we can protect our environment protect this earth because we all have to live here you know awesome so we're getting close to the end and i just wanted to say thank you to everybody uh thank you marcus for for being part of this um you really made a uh a a lot of help come from uh or i should say you really helped me get a lot more information on bicep and uh and i really appreciate your time yeah and um one last thank you so we've had a great panel speakers we've had we had a great workshop um but jay you and suzanne did a lot of the legwork to set all this up to bring everybody together so thank you for giving us this great event helping people who are interested in devops find their way forward and you know and then we got this awesome hands-on opportunity to try out a number of these great capabilities so thank you both yeah um thanks i appreciate that suzanne chen was just absolutely instrumental in making this all happen and she literally did it from the other side of the planet from where we are uh you and i are in the us she's over i believe in china and so we're talking about a huge time difference and she came out to make sure that we were all accommodated and and that that was really big um there's one person i want to thank um more than anybody and that's my buddy abel uh who i miss very much abel really laid the groundwork for a lot of the things that you say saw here today um he worked really hard to get people to understand why devops is important and and i learned a lot from him and i really do miss him um if you don't know we lost him a few months ago unfortunately to illness and um it's been tough but his legacy lives on through people who don't want to accept the defaults that don't want to right click to deploy that want to do all the things they want to automate everything and they want to make everything lean and agile and he really set that up for a lot of us and i know stephen you really appreciated the man and um we all miss you we all miss you um and i'm sorry to make it all kind of low there but i i really thought it was important to to remind everybody of just how important able was to all of us here at microsoft and across the devops community most definitely and i think we are now to about to our time so thank you so much and yeah yeah and if uh you you want to keep the conversation going uh go on to uh the azure devops blog you can just google azure devops blog where we have uh tons of information we've got the weekly roundup of uh news that you can find about what's going on in the azure devops community if you write something that's really interesting we will uh make sure you're added uh and and have your name your content in that digest so that everybody can see it but uh that that's that's really it for me uh steve thank you so much to all of our speakers thank you so much to ryan our producer thank you very very much you did a great job um to everybody thank you so much have a great rest of your day and week and take care of each other

Channel: Azure DevOps

Views: 1,553

Keywords:

Id: O7DaTpzFsj4

Length: 179min 11sec (10751 seconds)

Published: Thu Oct 21 2021