Azure App Hosting with Patrick Huber

Patrick Huber, a principal architect at Microsoft, specializes in helping customers in the retail space with their architecture and solutions for business applications on Microsoft Azure. He explains that solution architects can specialize in specific areas of Azure, such as data and AI, infrastructure, or app innovation. When working with a customer, Patrick starts by understanding their needs through architecture design sessions. He emphasizes the importance of separating the "art of the possible" from the actual business case and recommends using the highest level of abstraction that meets the business need. Considerations for decision-making include the team's skill level and experience, as well as cost and technology preferences. Patrick also mentions that he sometimes provides multiple architectures for customers to choose from, taking into account their requirements and cost considerations. The decision-making process involves gathering requirements, capturing the current state Hey guys, welcome to Road to Cloud podcast, your guide to grand strategy, imaginative solutions and creative implementations. I'm your host Elmir and in today's episode we'll talk to Patrick Huber, who is currently a principal architect at Microsoft, but his skills range from influencing business strategies to writing code to solve customer use cases with Microsoft Azure. And that's what we're going to focus on today. So let's dive in with Patrick. Patrick, welcome. Want to tell us a little bit about yourself? Sure. Thanks for having me. Yeah, I'm a cloud solution architect at Microsoft. You know, we work on with customers specifically in the retail space, their architectures and solutions to deliver business applications. So yeah, we'll do design all the way through delivery depending on the needs that they have. That sounds really interesting. So I'm assuming you specialize in Azure platform as a service offerings and you guide your customer teams to the best fit. Is that right? Yeah. So there's three segments that any architect can fit in. So we're overall broken up by the industry and then within each industry further broken up into three categories of data and AI, infrastructure and app innovation. Those are the three biggest. There's also security and power platform, modern work, that kind of thing. So, you know, when you talk to a solution architect, they might not be someone who is overall all of Azure, right? They might specialize within a particular area of Azure. That doesn't mean we don't have cross-disciplinary knowledge. But for the most part, you know, think of us like big T's where we're very broad in Azure, but we go very deep in one specific area. And that area for me is application development and innovation, which includes a lot of the services and platforms that we have. That's cool. So would you be able to walk us through how you decide what a best fit for a customer might be that you're trying to help with Azure? Sure. Yeah. Typically you start with scoping. We call them architecture design sessions or ADSs. The idea is that you have to understand what the customer needs before you can recommend a solution. And the point of the architecture design session is to sit down with the customer and walk through their business cases. You know, this process is taught by the Microsoft Technology Center as an actual skill you can develop. And we do like mock interviews and things like that to learn how to do the architecture design session. But in sort of a nutshell, what you're doing is taking down capabilities, business requirements, things that the customers need in a conversational form. Like, you know, tell me about the application you're trying to build. And you can take a snapshot of their existing architecture. So really you're trying to understand what their needs are to begin with? Yes. Yeah. Like, what do you want? What do you need? What's the use case? You're trying to tease out things like, you know, we heard AI is cool. Like, make some recommendations for us as a customer to utilize AI. Well, that doesn't help me solve a business problem for you, right? That's more of like I need to know the art of the possible. So we're trying to separate art of the possible from what do you need from Azure applications or platform in order to make your business money, right? Like, that's really what we're trying to get down to is what is the business case for this application that you're trying to build? All right. So let's say we've nailed down the requirements. What other considerations go into the decision making? Do you have to look at the skill level of the team experience, maturity and that sort of stuff? You can ask those questions and sometimes they will give you guidance as to what you can produce. A lot of times when you come into an architecture, it's very rare that you'll have a customer who's going in blind. They generally have an idea about what they ultimately want from an architectural solution. You can utilize some of the feedback from the architecture design session to influence that architecture. But as an example, I've had customers that come to the table and say, hey, we've got this existing dockerized, containerized application running on Solaris VMs that we want to migrate to Kubernetes. Can you, based off the feedback we gave you, produce a solution that utilizes Kubernetes? We want to use Kubernetes. We've hired for it. We're ready to operationalize around Kubernetes, produce an architecture like that. So that would be more like a cloud-native type of architecture on top of Azure versus something that is more, and I say cloud-native as in CNCF, Cloud Native Compute Foundation, where you're using a lot of open-source technologies that are abstract versus something that's more specific like, okay, well, instead of Kubernetes, maybe you want to use, you know, you don't need a container, let's say, and maybe you're just interested in executing code. I often tell people, you know, use the highest level of abstraction that meets the business need because that will exclude a lot of things that aren't necessary. Like, do you really need to be managing virtual machines and virtual machine images and software patching? Or can you get what you need out of Azure functions or something higher up in the abstraction chain? So that's how you basically, through consulting, demonstrate your technical expertise and you try to, based on the customer need, guide them toward the correct or best fit for what you think might be the best. Yeah. And sometimes, too, what I'll do is produce extra work, but I might produce two architectures for them. So a lot of times you'll hear things like we don't want to be locked into a particular architecture or we have standardized on X technology. So you're trying to take those things as requirements into the design that you produce. But speaking to the art of the possible might be like, hey, you know, you can develop it like this. It's going to cost this much money. Or you could do it the Azure native way and it's going to be 10 times cheaper. Right. And like that ROI is important, right? Right. Yeah. Yeah. So a lot of times people don't think about what's the operational cost of the solution that I've produced. They just think I want to use this technology and I'm willing to pay whatever price is necessary to do that. And so I'm trying to navigate that space and produce a solution. Some customers don't care about cost as much as others. They just want to learn and produce an architecture that works. And some are very cost conscious. Some are very technology conscious and they want to use a particular platform and some don't. It's just kind of navigating that space and trying to figure out what would be best for them. Right. Like, you know, it would power platform be a better fit here than doing an Azure native solution, those kinds of things. Right. So you want to walk us through maybe a decision-making process that you take when you create an architecture based on the inputs or based on the input requirements? Yeah. So the first thing I'll often do when I'm – so in the ADS, we tend to not recommend a solution right away. Like, the whole goal of the architecture design session, the ADS, is to gather the requirements, capture the use case, capture the current state architecture. And then often what I'll tell a customer after that is, like, you know, give me a couple days to produce an architecture for you based off of this. So I'll have in my mind roughly what the solution will be based off of the feedback from the architecture design session. But one thing I often point to customers is the architecture decision tree that Microsoft produces and is in our documentation. So I think you have a link to that that people can look at in the show notes. Yeah. I'll share the link which shows all the different offerings for how you can host your application code. But before we go into this and what struck me, what you just said is you don't, you know, really recommend an architecture right away. I'm assuming it's an iterative process because just from experience, you might get requirements, but it might not be the complete list of requirements. And sometimes customers don't really have a full picture of what they need, really. Yeah. Or if they don't know that they want something until they see it first. So recently I had a customer who's very heavy into AKS, Azure Kubernetes Service, specifically for ML, machine learning workloads. Hot topic. Hot topic. Yeah. This is more like traditional image classification and stuff. Like it's the AI that's not as cool as the AI that everyone's talking about, the generative AI stuff. This is more of like statistical classification and looking at images, looking for cancer images, things like that. So they're using AKS as an inference platform, which means that they're evaluating model or executing models on the platform versus training them. So just execution is called inference in the ML space. So the, you know, basically AKS exposes an HTTP endpoint that is called and produces the model results that what they put in, but then they get inputs out or output that. So one of the things I was like, okay, well, they're using a lot of Kubernetes here. We have an option to put this non-machine learning component into Kubernetes as a, like Azure function using KEDA. KEDA is Kubernetes event-driven autoscaler. And basically what it allows you to do is execute Azure function like code, if not actually Azure functions on Kubernetes using events from anywhere, but specifically we support events from Azure. So somebody drops something in a service bus and you pick it up and you execute on it like you would if you were using Azure functions runtime. After a few iterations with them, kind of discovered that, hey, you know, it's kind of trying to put this thing on Kubernetes just because they're using it, but it might not be the best place for it, right? So we pulled that out into functions runtime, right? So they're able to create a app service plan and put functions runtime on top of that and do the same function without having to worry about using KEDA underneath. And it was just one use case didn't really make sense to put that one use case on there just because. So it's like that kind of revision where you're like, okay, I'd rather have this here. Or what about this use case? You know, another thing that we're talking about with them is using queues to do ingestion and how to do blue-green deployments, A-B testing, that kind of thing. You know, they're concerned that, you know, being able to test a new version of their application is more difficult when using queues. So we're kind of like navigating that space a little bit as an example. And those are examples of iteration where they see something, they have another question, you might need to update certain things, right? You've captured the big picture, but there's little tweaks to it along the way. And you have to think about the sort of like Azure development or iterative – sorry, Agile development where you are iterating, right? Very quick, iterate, build something, try it out, see how it fails, see how it succeeds. Small incremental changes based on information that you're receiving, yeah. Correct, yeah. That's cool. So we talked about understanding your customer needs and architecting, but how do you actually convince your customer that your solution is a good thing or a good fit based on the requirements that they gave you? Obviously it's an iterative, collaborative process, but at the end of the day you're presenting a solution to the customer. Trust is a big part of it. You know, they trust that we have done this several times and understand how to produce solutions on Azure. Often they're coming to us for our expertise, and we have produced multiple, multiple solutions across multiple, multiple customers. And we have the ability to tap product teams and tap other cloud solution architects and pull best practices, get feedback. There's a lot of information that we can use. We've read a lot of the documentation and understand how to navigate the documentation. We've read reference architectures, we've produced reference architectures, and those have been battle tested by other customers. So you're not just saying like, hey, why do I trust you as a cloud solution architect? How do I trust your entire network of cloud solution architects, right? And that's something that you can't really get from the outside. Like there are some like MVPs and things like that, that could produce architectures for Azure partners, things like that. And they do a lot of times, but they don't have the same, well, some of them do, input directly from product teams. But they don't have the same resources, right? That you do. Right. Yeah. So you're basically saying like, this is the industry way of doing this. And then hopefully, partners and Microsoft would all agree on the way to produce it. You're not creating something novel a lot of times, I guess is what I'm trying to say. Like you're utilizing existing patterns and reference architectures and reference implementations that are out there. And you can point to that stuff and say like, here's why I made this decision in your architecture because of this particular article that has best practices, or here's the security baseline for AKS is what we recommend for everybody, right? Gotcha. So you're demonstrating your technical expertise based, or I mean, backed by all the resources you have access to. Correct. Yeah. Cool. What, as we wind down, would you say the key points should be to take away, start working with a customer, you want to point them to a platform as a service solution, be it Azure App Services or Functions or Kubernetes or VMs. What would you say the key points would be to take away from this? I mean, the biggest thing that I think is important from just the solution architecture side is work with the solution architect. A lot of times we find that we will be excluded from things or not advised on stuff. We might do an architecture and then communication kind of drops at that point. It's better to have a collaborative type of workflow where small tweaks and iterations can be made and things that change can be upped in order to produce the best solution. If there's a point where communication drops and we don't really get a lot of feedback, but the solution continues to iterate and then ultimately something bad happens once it goes to production, it's very difficult to catch that stuff early. So that would be my biggest, if you're a customer, that's the biggest thing is keep open channels of communication with your sales group or the solution architect that's working on your application in order to make sure you catch a lot of that stuff ahead of time. But in general, all the reference architectures that exist, hit the Azure Architecture Center, it's a really good one. Find out best practices from reading the documentation. We often joke that a lot of what we do is just listening and sending links to documentation, but the documentation is really good. We update it when we need to. I've created numerous pull requests against the documentation and customers can do the same. If you do something wrong, fix it, and then you're helping everybody. Awesome. Well, thank you for that insight and telling us about your experience. Can you tell us what the best place would be to get in touch with you? Probably LinkedIn. I don't really, I mean, I have a GitHub for work, but all the other stuff I do in GitHub is probably just personal, playing around with different types of code and things like that. But you can drop my LinkedIn content information. All right. LinkedIn, Patrick Huber, Microsoft CSA. Thank you so much.