Posted by Mike Racine
Why ITOps should 💘 Azure DevOps (AND WHY YOU PROBABLY DON’T)
Manually creating and updating resources in Azure is how most of us learn to do it. Usually first in the portal, then the Azure CLI, but still by hand and prone to mistakes and inconsistency. In this episode of KnowOps, Dana shows us a beautiful way to make creating and modifying resources consistent, repeatable, and tracked with Azure ARM templates and Azure DevOps.
You know what sometimes frustrates me when I hear about this, we have to shift left and that developers really need to be in charge of operations, and that's what DevOps is, and it can be farther from the truth. The whole point of what DevOps is supposed to be is developers and operations getting together to release better quality software in less time. And you know, from an ITOps perspective, it's surprising me how many people feel threatened as they hear about DevOps, when they really should be embracing this, and quite frankly as administrators, we really could learn from some of the processes that developers are using on an ongoing basis. Things like source control, and you know, really the everything is code, we should really be able to deploy our infrastructure as code, and our configuration as code, and find better ways to automate this stuff so we really truly can have a reproducible and effective Cloud environments, that meets everyone's needs. Now, in Azure, we have a wicked set of tools that can help with this, and I think it's ITOps responsibility, us as administrators to really learn how to use them. So, I wanna show you something called Azure DevOps, and how you can use it in your ITOps to really master the Microsoft Cloud.
Dana Epp here, welcome to the channel designed for inspiring Azure administrators like you and me who wanna know ops, and well, master the Microsoft Cloud. I'm so happy to have you here, thanks for coming by.
Now, when I'm talking about Azure DevOps, I wanna take a step back to talk about the purpose of what DevOps should really be and how we can lever this in Azure as administrators. You know, when I think about it, there're really is two things in Azure as administrators that we need to be really good at. One is being able to detect and control configuration drift, cause it is so easy through the Azure CLI, or through the portal to have team members to make changes without us understanding what's going on which could positively or negatively impact our Cloud environments.
The second thing would be about idempotents, or the ability to make sure that things can be built out, rolled out, managed the same way each and every time, and I think that that's a skill that not a lot of people are always following up on, and learning and improving. So, you think about it for a second. You can very easily just go into the Azures portal, go into the marketplace, select some resources and spin em up. You can do that. And maybe it'll take you weeks to tweak it and set it up and get it where you need to, but then what happens when the engineering groups says, "hey, I need a dev environment to test some changes". Can you really afford to take two or three weeks to trying to roll that or how about worse yet, when the developers build out an environment, and then you're responsible for rolling that into production and you don't understand the decisions and the reasons why they do it.
Some developers are amazing at understanding operations, but a lot aren't and so they don't think about the production considerations we need to think about for monitoring and managing, and the whole idea of SRE and site reliability engendering, and making sure we can keep these systems up and running. So the idea of using idempotency, is the ability to say, I can create that environment very, very quickly to match exactly what's in the other one. Obviously configured for the environment we need to accomplish. So, this is where things like infrastructure as code, configuration as code and even documentation as code, can be very powerful. The ability to be able to via script, to be able to deploy an environment.
Now, in many other episodes I've showed you how to use things like the Azure CLI to make it much easier to codify or execute, and manage resources, and you can very easily create scrips to do that. And in fact, you'll actually hear a lot of people out there saying, you really should be doing it through scripts like that, but I don't think that's actually the case. What you really wanna be doing is being able to template an architect in a way so that you can describe what your environment is, and then allow the Cloud's system, the platform itself to be able to take advantage of getting that deployed and configured for you. And this is where things like arm templates can be so powerful. Azure resource manager is the backplane of pretty much every management task you do. So it doesn't matter if you're doing it through the portal, if you're doing it through the CLI, or if you're doing it through restful means, at the end of the day it's gonna through the arm backplane for management.
So things like ARM templates can really be helpful here, but the reality is, when you wanna use things like arm templates, how do you consistently manage and monitor that? Well that's the power of being able to use things like, Azure DevOps to create a pipeline that will allow you to deploy exactly the way you want to each and every time. And in many cases, it's done in a way so it's frictionless. So nobody has to actually touch it. This is where idempotency can really help, because now we can know if we run this process, in this way, we can make these changes exactly the way we want to. As an example, you can make a configuration change to a JSON file or to a configuration file, and when you check that in, that can automatically execute a pipeline that could run that arm template to update those resources in Azure, exactly the way you want to. So now those changes are documented through source control. The execution of that change is actually tracked through the pipelines logs, and ultimately when that gets deployed out into the infrastructure, there's a set of log items in the activity history that allows you to be able to know what happened when and by who. And that is a very empowerful part.
The other reason this is interesting is that, it allows us to start re thinking what mean time to recovery really means. Honestly in the Cloud environment where it's so easy to make changes, I'm really not thinking we should be focusing on repairing items when we can just redeploy. In many cases it can be much faster to do a redeploy than a repair, in an environment where we may or may not be able to completely control it. Now hey, maybe you're using resource locks correctly, you're using the our back system correctly to be able to track this thing, but things happen, people get involved, the more that you can automate this, the stronger it's gonna be.
The last thing I'd talk about, would be about thinking about how you plum this out. When you're using Azure DevOps and you're using things like the CICD pipelines, you can very easily configure service principle, to be able to deploy to production environments. This allows you to scrip the whole idea of removing a resource lock, applying these changes and then reapplying it without a human being involved, or even better, you can then start using the workflow approval processes built right into Azure DevOps, so that when changes need to occur, there can be a two person approval process, or a release management process, that would help you to be able to make sure that everyone knows what's going on, when it's going on and making sure the right approvals are in place, so that environments change only when they're supposed to.
This is what's really interesting. So I encourage you to go check out Azure DevOps. Go to dev.azure.com. You can sign up, get a free account that'll allow you and up to five people in your team to be able to access the system, try it out and see it for yourself.
I think if we embrace Azure DevOps for things like infrastructure as code, and configuration as code and even documentation as code. We as administrators can start following a lot of the best practices that developers have been following for years, that can help to be able to build and deploy in a safer, more resilient manner. And, I think Azure DevOps gives us that, with things like Azure repost for our source control, for our configuration files and any of our arm templates, or any other kind of configuration we might have for infrastructure as code. The fact that those check-ins can actually be documented, so we know exactly what's going on, that's allowing us to use code as documentation, which is very powerful, and of course, the whole configuration, in the Azure pipelines, when were doing a CICD, we can actually set up a configuration, so that it configures resources as it's being deployed, or updated in a way so that developers don't ever need to know those configurations and in many ways for a security perspective, they don't have access to that.
Using properly locked down service principles, we can ensure that through Azure DevOps we can deploy to production, while still allowing developers to have the control they need in the actual build out of the software that they're building. Hope that makes sense. And I really hope that this made sense for you, and that you'll go give it a try. Let me know by hitting the like button, and if you haven't yet, smash the subscribe button so you can be notified as I release new videos each week. Until then, thanks for watching. We'll see you in the next episode.
With Azure DevOps, in many cases it can be much faster to do a redeploy than a repair. #knowops @auditwolf