AzureSUCCESS
AzureSUCCESS
Well-Architected Framework
Pump up your cloud with the five pillars of architectural excellence: Cost Optimization, Operational Excellence, Performance Efficiency, Reliability, and Security; a more than toothy mouthful made palatable by a pair of Microsoft's top thought leaders: David Stanford and Jason Roberts.
BIO: David Stanford is a Principal PM on the patterns and practices team in Developer Relations. He has spent the last eight years working in the cloud helping customers build successful workloads across a variety of different industries.
BIO: Jason Roberts is a PM Manager with the patterns & practices team in Developer Relations. He has worked in the cloud migration and cloud native development space for the last 5 years, primarily in driving data-center oriented enterprises to cloud-native globally-distributed solutions.
LINKS: The Microsoft Azure Well-Architected Framework; Azure Well-Architected Review; Azure Architecture Center; Recommended naming and tagging practices
CREDITS: Louis Berman (Host); David Stanford & Jason Roberts (Guests); Dan Phillipson / PremiumBeat (Music); Anne Lamb (Intro/Outro); East Coast Studio (Editing)
MORE: visit https://azure-success.com for additional episodes, plus transcripts, and more ways to listen to the show. As to your comments and suggestions, please feel free to email your host, Louis Berman, at lberman@microsoft.com
It's really hard to go out and speak to every delivery team, every workload owner, every person who owns a thing that operates in your system. Whereas if you can make utilizing this model a part of the way your teams do work, everyone can self manage that to some degree. And I think that's a huge benefit of what this tool makes available to the entire organization. You're listening to Azure success, the podcast by and for Azure professionals. Listen in, and you'll be sure to speak to your customers March into the cloud. And now your host, Lois Berman.
Speaker 2:Hello, and welcome to another episode of Asher success. The podcast buying for Azure professionals. I'm very pleased today to have, well, this is the first time on this podcast. I've ever had two guests. I have David Stanford, a PPM on the Microsoft Azure, well architected framework team and Jason Roberts, a PPM manager. We'll ask them what that means a little later on, but you know, it's going to be interesting show all around today. I am in my office in Pennsylvania and it's starting to biblical rain with lots and lots of lots of thunder, which is hilarious when you're trying to record a podcast. But in either case I'm very pleased to have David and Jason. Hey guys, why don't you say hi and introduce yourselves a little bit. Hello everyone. My name's David Lewis shared with you already. I've been on this team for probably two and a half years now. You know, the important thing to say about David is he has lots of dinosaurs in his yard. That real dinosaurs they're skeletons actually, and they're plastic. So, you know, not like my paleontologist running laws, but, but apparently he's overrun with them. Maybe we'll get him to talk about that a little bit. So, so Jason, what about you? I'm Jason Roberts. I've been with the team for about a year and a half at this point, and I've been doing cloud migration building stuff for probably the last five years, but I'm excited to be here to chat with you. Excellent. Well, so it turns out that your notice about your product was like one of those kismet moments, right? Is like we'll talk in a second, what it's about. But you know, very often as a cloud solutions architect, that's what I do at Microsoft. I'm casting about, for some solution to solve one thing, you know, I don't know, databasing or some solution to solve, you know, networking or particular type. And I turned out, I was really casting about for just all sorts of architectural goodness and understanding what well architected was for one of my clients. And then bang, I get a notice from you guys. So I was very, very pleased to learn about this. So tell me what is the well architected framework and we're going to have to come up with a smaller name. I'm really bad about that. So the will architecture framework is really intended to help the field and our customers and our partners take a workload that they have, or that they want to build
Speaker 1:And optimize it against the five pillars in the well architected framework that we talk about. So the five pillars are reliability, cost optimization, security, operational excellence, and performance efficiency. So as you kind of work through a particular workload, you're going to have a set of business requirements that you need to meet to actually make that workload effective. And then along with those business requirements, you have, you're going to have functional requirements that you have to take into consideration. So for example, you may need to optimize for reliability, for mission critical workload, but cost still matters to the business. So this is really intended to help you kind of balance between those two competing priorities and help you find the best way to optimize that work.
Speaker 2:Excellent. And so who would be a target for this who would use it, who would benefit?
Speaker 1:So there's a variety of folks who could or should be using this. The primary audience that our content and assessment and learning modules are really for is for solutions architects and then workload owners. So workload owner could be anyone from a developer to an essay to potentially even like an ITBM
Speaker 2:And ITBM and essay. What's an essay. What's an ITBM.
Speaker 1:Oh, great question. So NSA is solutions architect, and then I, I, TDM is an it decision
Speaker 2:By the way, just for, you know, I'm a cloud solutions architect, but we are anti acronyms here was black popped up. We refuse to use them. Wow. That was a lot of thunder. This is going to be in a very interesting podcast. Okay. So you have this framework where can people even start playing around with it? Can you quote off the actual place? They can download this and remember it's a radio, we need something exact,
Speaker 1:We can, I can do that. And we even have an AKA shortlink so super easy to fall, aka.ms. Slash forward slash slash architecture and then slash framework.
Speaker 2:Oh, I think even I could remember that. That's excellent.
Speaker 1:It's pretty straightforward. And then there's one other to call out and that's our assessment, which kind of helps you assess your workload it's question and answer format and that's aka.ms. Ford slash architecture forward slash review.
Speaker 2:Got it. Is it a wizard like experience or is it just a bunch of questions?
Speaker 1:So today it's very question and answer focused. We're looking at ways to make it also be wizardly.
Speaker 2:Excellent. Excellent. And have people started to be using, this is brand new, right? Am I correct? Your you've announced it sorta, but you haven't announced it very widely and you're going to be announcing it any days, isn't it?
Speaker 1:Yeah. It's been announced. So we announced it at inspire. We had, we had a blog post, but we're absolutely still iterating and building out functionality and features in both the platform and set of content we have. Oh, go ahead, Jason. I was going to say, and I know we talked about a review as well for the assessment. And as, as you had mentioned, whether it's wizard or question and answer that aspect of it is still kind of in a preview mode. So we do expect to see some changes in the near term, in that part of the experience, particularly, that's a great caveat. I just wanted to follow up on your, you started asking a question about what people were saying. We actually just had a cool quote come through yesterday. So I have that top of mind, this is what they said. I'll say that going through this with the customer led to some really great discussions and insights into their environment, processes and procedures that will help us build trust and identify the best solution.
Speaker 2:Excellent. So, you know, I'm not a wizard, I can't predict things, but I bet my editor going to put that at the beginning of this podcast, just saying,
Speaker 1:Yeah, it's a pretty great quote. I was really, I was really pleased when it came through.
Speaker 2:Yes, exactly. So I'm very interested in this sort of stuff, because as it turns out, Azure is in business like usual, right? It is the way we approach modern application development or should, in my opinion, is different than perhaps we've all grown up working on prem, working with monolithic apps or apps that have relatively few moving parts that a more modern Azure app has dozens of parts. In many cases, we'll interlocking today. I showed a very simple example of how to use cosmos DB with blazer as your functions, app service and storage. Right. And you know it Oh, and it had signal on it, right? The point is once upon a time, that would have been like a crazy thing. Oh my God, you did all these pieces. And now this was something I whipped together in a couple of hours to do a demo for a couple of folks. So understanding architecture is near and dear to my heart. And I think really important. Can I ask an architecture question? I mean, you guys are not just prescriptive. I assume you've looked at good architectures and what have you, can you tell me some things that have come up with some learnings that you've had from this, or some, some things that are revealed through the framework.
Speaker 1:And it's actually interesting. I know earlier you said you were poking around looking for an answer and this just came across your page. This is a new aspect of kind of a larger body of work that has the Azure architecture center, which has been the home for a bunch of best practice type stuff. We have some conceptual things in there just to think about when you're building in the cloud and distributed systems in general, we have some great design patterns that people should look to utilize when building systems with dependencies like this, but in terms of like those, and those are really about learning how to be better at doing this kind of work, they are somewhat prescriptive, but it really still leaves a lot of the interpretation to the user to know whether it's an appropriate case this or that. But as we go through these assessments, some of the things that we really have learned or seen is often, unfortunately reliability in particular is one of those things that people tend to not prioritize until they have their first event. And then they have to go back. And it's really, a lot of times you'll just throw a larger whatever at it, depending on what happened to fail. But really, if you want to get the benefit of being in the cloud, there usually are some architecture designs to be made. Do you put this thing behind load balancers? How are you addressing your scaling for this? We didn't realize that this was a constraint to begin with. We didn't know that compound SLA was a thing. And we weren't looking across the stack to determine these. It's like, well, we thought it was pretty good. So we just shipped it. And that really is often how these conversations start. And it's a really, really meaningful thing that the assessments will help bring up so that someone can learn it before they have to have that, that event that has downtime that has a material impact for them.
Speaker 2:It turns out that programming and developing and deploying for the cloud is rather involved, right? Does this help people get a handle and start in it? Or is this a really for experienced programmers, coders?
Speaker 1:It people, whoever I would say that it addresses both audiences for someone who's new to the environment, it helps them know what questions they should be asking. In many cases, they haven't been through this before. They're not deeply involved in understanding what these trade offs, they, they don't understand what using your computing resources like a utility means to them. And by guiding you through this, these concepts will be introduced to them and they'll be able to be thoughtful about them. And then the flip side of it is for very advanced people, even if you're great at this, there are a lot of things to continue to remember. And so by being able to use this over time, you can make sure you didn't forget anything but B if you use it like quarter over quarter, month, over month, depending on the criticality of the workload, you can continually improve those workloads to be better. And you may have business goals that may move. You may have dependencies that may change. And so continuously using this to make sure you're tuning your workloads to meet your needs really is something that regardless of your expertise would be, would be valuable to you. Got it.
Speaker 2:And just so I'm clear about this, this isn't a one and done, right? This is now going to be another one of themes developed at Microsoft and expanded upon, right? So architecture isn't done. And I think you guys are just at the beginning of this journey, really, even though it's building upon things that exist, is that right? Yep.
Speaker 1:That's absolutely right. It's ultimately, you're never really done with your workload and how it's architected things change both underneath you. And as you move forward, new services are introduced that could potentially decrease your costs, new methodologies or our services even, or built out that could improve your reliability or your operational posture. So if you just stop after the first review, you're not going to be able to take advantage of all the changes that are coming both in the platform itself and in the industry and how folks are thinking about things.
Speaker 2:So this sounds great. And like I said, this was something that I was looking for personally. So I was very pleased by, but I'm a customer. Why should I really care? You know, I mean, there's, there's so much, it's so complicated. Anyway. Why is this for me,
Speaker 1:Complication that you pointed out there is actually one of the key reasons to do this. It's really hard to go out and speak to every delivery team, every workload owner, every person who owns a thing that operates in your system. Whereas if you can make utilizing this model a part of the way your teams do work, everyone can self manage that to some degree. And then you can use the central tools to find the outliers. You'll always be looking at your budgets. You'll always know, assuming you're using tagging and things like that, which parts are spending a ton of money. And then you can go have more tailored conversations. But if everyone is doing the things to keep their house in order, and to meet their business requirements, you can do that in parallel. And I think that's a huge benefit of what this tool makes available to the entire organization, rather than the few people that you might have a direct touch point.
Speaker 2:Speaking of tagging, which I think is really, really important. Can I tell you a funny story from yesterday? So I am doing a session with a working workshop session with a group of people who are pretty new to Azure. And so we're, we're doing great. We're moving technology, we're setting up services and stuff. Then we get to the point of setting up tags and you know, where I borked entirely it wasn't physically setting up tags or just explaining how they worked or anything. It was being semantic in the right way to say what tags should be, what would be useful? You know, it is, should it be division should, should it be use, should it, should it be cost factor? I don't know what it's possible. Tags would be turns out that I have the same problem, by the way, with naming resources. Firstly, it's technically hard in Azure since use different characters, naming a storage account versus a web server versus a network versus everything. But the point is I find sometimes these little details of how to even approach and think about stuff going. So I don't know if you address tagging and semantics and figuring out naming and stuff like that, but that'd be a great thing. It turns out it punches way above it.
Speaker 1:Yeah. I, I completely agree. Tagging is one of those things I think people take for granted initially, or they don't bring enough structure to the plan for it. And then if you don't have that, it's really hard to search. It's really hard to aggregate. You don't get all the value out of it. Part of what we do as the patterns or practices team, they Azure architecture center, which I had mentioned the well architected framework where we're talking about now, we also produced the cloud adoption framework inside that is focused a little bit more on kind of how the organization approaches it. And so some of the more central concerns are included there that does have some content on how to identify a naming strategy, what your organization should set as mandatory tags on resources. And I do believe we also have some content on which services required like the actual naming requirements in there as well. But by all means I would recommend looking through the cloud adoption framework for the best practices as well. Excellent. And if I may give myself an, a promo or a tag or something, I don't know what a recent episode on the podcast was with Jake Mark actually, who I said, Jacob calf, super superstars in cloud adoption framework, superstar. And so everything is all in the same vein. So this is really, really great. So I'm gonna bring it home, but Jason, it seems to me with it pouring rain and thundering around here that you had a sort of similar experience, ranger shows up in the wrong place for you. It's like you've lived in Seattle for 15, 20 years. I think you said you visited a bunch of times and never rained and you didn't really know it rained in Seattle or something like that. Is that right? Yeah. The first few years I was out doing summer adventure trips when I was younger. And so I biked across the country one summer, I did a bike trip from here to Vancouver and then down to San Francisco on one Oh one. So I visited like three years in a row and I never saw a drop of rain. And I was like, there's beautiful mountains. There's green, there's beautiful water. This is awesome. And then I looked for jobs here and I got a job. I moved out in February and I had a very, very different experience at that point. Well, I don't know if you know, listeners can hear it is it must be like that. It's pounding fender right now. It's cracking me up. So anyway, there's one more big set of questions I want to ask you. And you know, so this, this podcast more than anything else is for Azure sellers, people who are selling Azure, either in a commercial sense as Microsoft employees, but more importantly, people who want to influence people who they work with to say, Hey, Azure is the right thing to do. So how do you sell the I'm looking at my notes? Cause I swear, I can't say this in one mouthful, the Microsoft Azure, well architected framework to your colleagues. So we're actually working pretty closely with the field and with, with a variety of teams to integrate this into the sales process, naturally you actually don't have to sell it necessarily is really intended to help you help your customers. I mean, for example, we talked about the five pillars at the beginning of the call today and really nobody is an expert in all of them. So as you go through the well architected review and framework, it gives you a consistent way to talk about those pillars and get information to really help you sell Azure. You don't need to go in and sell the framework to the customer so much as use it to drive your discussions. Got it. So, well, this is great. I want you to just, each of you leave me with one favorite thing you really like about the framework and my ups, by the way, just, just blinked. So, so say it fast cause I may run out of power. Sure thing. My favorite thing about the framework is really facilitating those consistent conversations with customers and really empowering the customers to dig into those things themselves. Excellent. And Jason, yeah, I was going to take a slightly different approach to it, but I think the theme is the same. At the end of the day, this is a tool that helps those customers and organizations be effective in this way and moving to the cloud. And uh, you know, people talk about the democratization of information and things like that. More people, more individual developers have more power than they did before and helping them make choices that they know are more optimal, that they can do their job better, that they can make better choices. I think our mission is to, you know, help every person and organization in the planet achieve more. And I think this is like a great example of how we can do that, make that population just more effective at their job. Excellent. Well, this has been great. I've been talking with David Stanford and Jason Roberts about the Microsoft Azure, well architected framework, something that I'm starting to use and I very much recommend that you guys do too. Thank you so much, gentlemen. Thank you for having us. Thank you.
Speaker 3:You've been listening to Azure success, the podcast by and for Azure professionals, you can visit our website, asher-success.com for show notes, helpful links and other episodes, but also to leave your questions, comments and suggestions. Thank you for listening.