 Live from Orlando, Florida, it's theCUBE. Covering Microsoft Ignite. Brought to you by Cohesity and theCUBE's ecosystem partners. Welcome back everyone to theCUBE's live coverage of Microsoft Ignite here in Orlando, Florida. I'm your host, Rebecca Knight, along with my co-host, Stu Miniman. We're joined by Stephen Morowski. He is the lead CloudOps advocate at Microsoft. Thank you so much for coming on theCUBE. My pleasure, I'm very excited to be here. It's already starting to be a great show and I just, I love talking about all this technology stuff. Well, you've come to the right place, Stephen. So, we've got to talk about your shirt, we've got to talk about what you do. So, your mission as a CloudOps advocate is to win the hearts and minds of customers and to secure the future of the Microsoft platform. There's a lot of hype around DevOps. You're wearing the shirt, you're making it look very cool, I got to tell you. But, I mean, talk about the hype and then talk about the reality of DevOps and CloudOps. Sure, right, we've been hearing the DevOps hype now for at least the last five years, pretty strongly. It's been a thing for the last 10 years or so. But there's more, there's a reason for the hype, right? There are patterns and practices that have kind of fallen out of the DevOps workspace that correlate very strongly to high performance IT organizations, right? And, you know, you'll hear it called DevOps, you'll hear it called high performance IT, now we're starting to hear more, you'll hear it called Site Reliability Engineering. At the end of the day, you can call it a lot of different things, you can go to a lot of different conferences and focus on a lot of different stuff. But it boils down to a set of patterns and behaviors that really lead to I can deliver things more quickly, I can deliver them with a stronger degree of success. And because I have confidence in the artifacts, I have confidence in my test suite, right? One of the things we don't talk a lot about is the testing that's required when it comes to DevOps. We all talk about continuous delivery and shipping thousands of times a day and using source control and refactoring and all the fun stuff. But what we often miss, and if you read the state of DevOps report, Puppet Labs used to put this out, now it's the DORA, the DevOps Research and Assessment. They publish a survey and they've done it over the last, you know, Dr. Nicole Forsgren has been the primary researcher since like 2014 on this. And one of the things that you see consistently is that there's these buckets of performers. There's the low performers, the medium performers, the high performers. And one of the things is when you move from low to medium, you start seeing some more impact in your time to recover. You spend more time manually remediating things because we're starting to learn to build quality in. You know, was it Harold for, or Harold Dodge, Harold Dodge said that you can't inspect quality into a product, right? So we can't deploy something and then go run through a checklist and then make sure it's good. Because then we're starting completely from scratch with no basis for improving that performance. When we start talking about DevOps workflows where we're starting everything's in source control, there's a consistent automated process that goes through. If something goes wrong, we find something wrong in it, we can make a change in that process. So there is, there's a lot of hype, but there's a lot of substance at the core of things. All right, so one of the things that sometimes people get tangled up in when you talk about this whole DevOps things is there are, there's certain tooling that's often involved, but we know it's not usually the technology or the tool where we get stuck. It's really, it's about how we think about things. There's the culture and DevOps very much culture is at the center of it, but you work for Microsoft. And Azure has a lot of tools, so maybe explain first how those things go together. The tooling that Microsoft provides and the methodology and the culture of DevOps. So tooling is both unimportant and super important. Right, right, there's a, there's a, you can do DevOps, you can do all of the high performance IT stuff with whatever tool chain you want to. How hard it is depends on the tooling, right? So certain tool chains and certain sets of workflows lend themselves better to, to DevOps work, to kind of a DevOps environment, right? And it becomes easier to collaborate and perform and work together across organizations when we have single sources of truth that everybody can go look at. When there's a, when there's a consistent process that everybody has visibility into, right? And now I'm saying like everybody has access, everybody has visibility. These types of, of process that are enforced by tools, right? Lead to changing our culture. The tools reinforce the cultural changes that we want to have. In order for them to be effective, we have to, we have to open up things, open up communication, right? Source control is, I keep coming back to source control because it's, it's a critically core component to this whole thing. The, back to the state of DevOps report, right? It is more important for IT operations to use source control than for developers. And it's critically important for developers. Now, source control, we may think, oh, okay, it's like this undo button that I have for all the things that I want to check in. But it's more than that. It's a communication tool. Because as we get things into source control, they become visible to other members of our team, other members of teams that depend on our things. And so we can share. And I have to collaborate with you. If I want to make some changes and you want to make some changes, we need to go together and figure out how we're going to work together to get our changes to work and not conflict and not wait until they're conflict in production. So I'm hearing that this is really about bringing discipline to the process. And I'm interested in what you said about the whole, the single sources of truth, particularly in this backdrop of alternative facts and fake news. And this idea where there's a lot of skepticism about what is the truth. So in terms of the cultural shift to get everyone on this page and thinking this way, how do you get everyone on the same page of the single source of truth? Well, one of the ways that this happens, right? You don't start big bang, everyone's doing this, right? You're starting with individual teams. And you're starting with not even necessarily individual teams themselves, but individual business goals, right? One of the things that we're constantly fighting when we talk about this with customers or with community members is we have different teams with different alignments because they have different metrics, they have different organizational goals. And we forget that the true organizational goal comes back to delivering business results for our company, right? And so if we start with that, we start with that end in mind and we work back what process we need to get there, that's where we start seeing, okay, I need some ops love in here. I need developers here. How do we get the work between them? Well, we stick it in source control. Then we put a process in front of that so it consistently moves on to the next environments and we start looking for places to remove manual intervention. Initially, we're going to keep it all, right? We're going to start out with, we're doing everything the same way, but we're going to add one little element of, we're going to work together better. Now we're going to start with source control and we're going to start with a basic pipeline. And we look then for places where we can step back and now, hey, this thing that we're doing in a manual fashion, let's put some automated tests around it so we can validate this thing without a person having to go look. All right, Stephen, you mentioned SRE. So first of all, what you get for those of our audience that doesn't know site reliability engineering, what it is, and we're going to have one of the Microsoft SREs out there. But I'm curious, we talk about DevOps. I hear talk about teams, you talk about culture and change. And when I first heard about SREs, it was like, oh, well, the SREs at Google, the SREs at Microsoft and the like. So is this a new job function? You didn't, you know, people often fought against like, you know, do you throw DevOps in your title or things like that? So, you know, give us the compare contrast definitional of SRE and sure, you know, how that fits. Definitely, right? So, so just to be clear, there are a lot of definitions of site reliability engineering out there and there's a lot of like, oh, hey, DevOps was cool, site reliability was cool. Let's just stick that on a title and we're just hiring systems administrators. The way we look at site reliability engineering and this is an evolving thing. This is an evolving thing. And you're going to, when you talk, when you talk with Jared, you'll hear a little bit more. But one of the ideas here is at the same time DevOps was kind of forming, there are practices at Facebook, at Google, at a couple of other large scale companies were forming around this concept that became site reliability engineering. And the idea was that we could take software development practices and apply them to managing infrastructure. And by focusing on reliability and scalability and resilience, right? In building the platforms that our development teams can then consume in a non-demand fashion, kind of like cloud, right? Then we provide a more stable environment for them to work on. We have better access to shared metrics tooling. And what that then enabled was a lot of these same high performance IT type behaviors. We're starting with software development methodologies. So we're talking about testing. We're talking about getting things in source control. We're talking about automation to do the same steps every single time. And so when you talk about it, it sounds very much like the things that the DevOps folks are talking about. Site reliability engineering tends to be a little more prescriptive and tends to speak a little more towards a traditional IT operations audience. Like, oh, well, I think this sounds a lot more like the things I can get my hands around because it's talking about managing infrastructure where DevOps tends to focus very absentric. But we can't lose sight of is at the end of the day, the things that deliver business value for our organization are the applications that we deliver. The platforms are an implementation detail, an important implementation detail, but an implementation detail. And so we need to kind of as an IT community, remember our goal isn't to run our infrastructure well, it's to get the applications delivered. You see when site reliability engineering and DevOps kind of come alongside and you see this actually in the VSTS or now I have to mentally do the regex now all the time, Azure DevOps services or Azure DevOps, right? You see that in that offering, the teams that build it run it, but they also have an SRE org that helps and that's who one of the folks you're going to talk to, but they help maintain the shared infrastructure that these teams use. So there's like 40 or so different dev teams working on Azure DevOps, all the different areas, they're maintaining the application level stuff, but we also have to maintain those shared services and that's kind of where the SRE team is focused. And this is the first year, before the cameras are rolling, you were talking about how this is the first year where you actually have a little bit of content around customer success and site reliability. Yeah, it's great. There's an SRE tag now in the session catalog and we've got four specific sessions around site reliability engineering and then a handful of others, kind of DevOps success stories with Azure and some customers. We have some stuff around PowerShell Core, which is cross-platform awesome and in my favorite area in Cloud Shell. So I don't know if you guys have talked about Cloud Shell at all before, but in the Azure portal, you have a command line shell and I'm a command line guy at heart. PowerShell is my background. Then I went and worked over at Chef and fell in love with a bunch of Ruby tooling as well and I have access to a bunch of that in Azure all the time from my browser. Great. Well, Steven, thank you so much for coming on theCUBE. It's really a lot of fun talking to you. Oh, it's been my pleasure. Thank you so much. I'm Rebecca Knight for Stu Miniman. We will have more from theCUBE's live coverage of Microsoft Ignite coming up just after this.