Building Azure That Survives the Real World — with Mike Martin [MVP]

Hello everyone and welcome back to the M65 as M podcast. Azure Architation is easy when you. Yeah, when everything works, then interesting question starts when dependencies fail, regions become unavailable, assumptions turn out to be a wrong coast rise. And teams grow, we probably haven't changed and somebody everybody asked. Why did we design it this way? Mike Markin has spent almost three decades in IT across development, infrastructure, architecture, system design, leadership coaching, training and community work with deep experience across Microsoft Azure and particular focus on architecture and resistance. This is, yeah, we are, I make it short, we explore how the world, rather than walking through in middle Azure services. This interview is focused on architecture judgment, how we make better decision, how we design, tell you what architecture is really wrong and how the role of Azure architecture is changing. Yeah, Mike, you are being working in IT for 30 years. That's amazing when you look back, when you look back, where are the major turning points that shape the way you're thinking about technology? Yeah, first of all, it's like showing age, right? Well, the stuff you're really old. Yeah, 30 years, I started, professionally, I started in 96, 97. I started my career as a visual basic developer, by the way. Visual basic, yeah. Yeah, yeah. I have learned, in a, a new view was about it. So I was basically designing software, all really with distributed software and the price based, visual basic, so like, common, complex and deep come in all these things and transactions, sir, and all the cool things that we had at the time. At today, my main business is mostly now Azure and in between, I did a lot of things and you asked me what changed over these 30 years. Well, the one thing that is a constant is that all the problems keep reappearing. There's always things like DNS, there's always things like IP changes, there's always things like, like, dependencies that get broken, there's always these things. But the biggest change I think is the way that we move from a single application into a more complex architecture. So we used to have client server, we used to have distributed, compute where we had middle tiers and multiple tiers and then we had layers and then we came up with these new concepts of, let's move it into the cloud and do some hybrid. And then before we knew it, we had all these things like Kubernetes and microservices and all these things. I think the biggest change there is the way that we're looking at software, naming it for the better because we humans are kind of, you know, most happy spot if you can overcomplexify things. And I see that a lot nowadays because I see designs of applications, I go like, or solutions, I go like, oh my god, what have they built it now? There's a lot of a lot of varsity things that are thinking that they need to be like Dr. Frank and Stein in that they also need to create a monster instead of creating a solution. So that's basically that. But I think that is the thing that I see most in the change is the way we have all these technologies and we tend to complexify a lot of things and we cannot keep it simple anymore. Even when it's a simple solution, we cannot keep it simple anymore. And I think that is the biggest change and I think that will change for the better over the next course of say next 15 to 20 years, especially not with the coming of all these things that we now at hand like AI because, you know, developers don't need to know anymore what they're doing, they're just five coded and they go ahead and push it to production, right? So there's that. So yeah, that's, I think that's, I think that is the biggest change that I've seen over the course of 30 years that we still have the same problems. We just made them more complex to deeper into to do to detangle basically. That's that's what it comes down to. I see on your link the profile you are as you take. And that is a bit hard, but the king can almost, it can mean almost everything. What do the architecture mean to you and how, yeah, what the person's, the person's of architecture and technology or technical stuff that you do? What do, what's the real, what's the architecture? Okay, so I was very lucky to be on the very first basis of Azure. I started in the early days. So when Azure was still red dog, while it was still a little, a little puppy, I was there at the PDC. I was there when Ray O'Z announced that we're going to have a cloud. And I saw the first portal and actually have been actively playing around or building with it since 2009 since the first installments. So 2009 was really playing and having a sample size somewhere and things like that. And portals were like nonexistent. The first portal was one button remembered well. And then we had that silver lighting, then we had that silver lighting, which nobody remembers apparently. And that thing evolved. And with the evolving part of Azure complexity also came, I come from a developer back round, but I also have an infrastructure background. I came in from Windows 2,000 networking into, and also some Unix networking system monitoring. And Azure for me, it all came together. And this is where I found my interest. I didn't want to build a search as just writing code, but I wanted to make sure that the solutions could be existing, the way cloud was intended to be scalable and resilient at every level. And for me, architecture is about knowing which pieces go together, which pieces to avoid, which pieces are necessary and which pieces are not. And building something beautiful out of it, which is not complex, which makes it easy to maintain, and which makes it also as cloud native as possible without referring to cloud native. Because cloud native has just a connotation, it has to be Kubernetes, it has to be that. News flash, you don't always need Kubernetes, you don't always need containers. There's a lot of native services that you can just use and make them all work together. But for me, architecture is more about design a full solution. It's not about one single application, you need to be able to cope with integrations, you need to be able to cope with everything surrounding that solution, like monitoring security, it all comes together. And that's for me is the architectural part. And there's some annoyance when I look at certain other architics, and I'm not saying that they are bad, who are they doing. But typically most of the architics that I'm seeing today are being architated from a way that they were building architectures in a data center. VDIP-based, VLamb based, VDNS based, VR-based, VR-based, VR-based, VR-based, VR-based, VR-based, network oriented, which is always the best way. You should look at data flows, you should look at identity flows, you should look at security flows, you should look at how compute needs to be distributed. What are the capabilities that you need? These things. And it typically start designing wrong in my eyes. Okay? Does that sound like, does it sound like bragging or like me being uptight? No, it's just, I've seen things that do that work, and I try to make sure that people don't make the same mistakes that other people made. That's for me architics. But I have so many questions about the deep dive a little bit in our, we have the Kubernetes. It's such a cool service. We have to use function, the Kubernetes app service container service box. I think for normal business guys, we don't have a plan, what we use when, what should the, should we discuss first as not technical guys? What will your solution need to be doing, first of all? And with that, I mean, will it be an internal or an external application? How many users does it have? Does it need to scale? Does it need to be resilient? Is it something long lift, short lift? Is it something which is impacting a lot of users? And also is it impacting users worldwide? Even if you're using an internal application, it still could be that you have, let's say, a sub, a subsidiary in, in, in, in, in the United States, you have a subsidiary in, in, in, in, in, in, in, in, somewhere in Europe, and they all need to work together. Look at the way that those requirements need to be built up and typically that's a business approach. What compliance do we need to uphold? What's our rock time? As a lace, as a lose, our deals, our bureaus? And those are things that can be defined even without an architecture. There's a requirements that you need to set, and you need to take a look at it. The second thing is, how can we live with an application if you pull the plug on it? What will happen? Who will be responsible, but also who will be impacted and will they start yelling at you when you do pull the plug? And there's a, there's a, there's a brother from another mother, as I like to call him. He's called Derek Martin and he has a great series of, of sessions that he does when he goes to conferences. The one whose session is, is about resilience and his first rule of thumb, and I also live by that is never take a dependency on a single region. Always make a design for multiple regions. So that way you always have a plan B and even a plan C or a plan D because anything can happen. Yeah. A region can go down or you want to deploy quickly into another region. Capacity can go down. It's, it's a given. I mean, we have to fight it. Capacity issues are existing in any cloud, not on Microsoft cloud in any cloud. Although with Microsoft, it's more visible apparently than down, for instance, with AWS or Google, although they have the same capacity issues that just don't want to admit it. Yeah. The reason why is because of the, of the growth of everything, which is AI, which is taking more power and the traditional data centers cannot follow anymore with all the power that they need. So they cannot expand their data centers anymore because of the powers capacity to give you an idea. One of the reasons why, why Microsoft in Western Europe cannot deploy anymore is typically because there's a lot of power there because the Netherlands have power issue. And that's the same everywhere. So and everybody's working, working their, their butts off to actually make it work and seeing that there's enough capacity. But it's, it's actually the, the, the, the, the, the victims of their own success. Yeah. And when we never planned on, on that kind of a success, although we have been growing all these, this cloud business over the last 10 years, like him, muslims, I mean, we see year over year growth in most of the cloud providers for about 30%, which is huge, right? So, and that brings us to do, if you need to start designing, what are the questions that you need to be asking your business? Without the questions that you need to be asking also, not only your business, maybe also your users or even your developers in your, in your system managers, how do, how do they want to cope with it? Do they want to do it 24/7 support? Do they want to do a full high NCICD and they want to be bothered anymore with deployments on Friday evening? These kind of things. Those are the questions that you need to be asking. And that's also our signature. If you're moving to the cloud, what kind of art do you need to follow? You know, there's eight alt, right? And one of them is we platform you, so have re-hosting, but also do we need to move it to the cloud? Can we know just like, put it into the, into the grave for us and just retire it? It's all these things that you need to be asking yourself. Yeah. I think some people are not really family with these, I think, bospers at your IPO. I think at your, it's really famous for my daughter. She's here for years. How long can I stay online? At your, I don't know. It's more for the, how would you explain this in? For a deep dive, how will you explain this? So RTN, right? Was that the question? Yeah. So yeah, I'm going to wait for a second. So because I heard the fire trick or what is it? Nambless? I don't know. No, but if we talk about RTN, so we have a recovery time objective and we have a recovery point of jitter. So how much, how fast do you want to get online? RTO. How do you want to get back online? And I know my data loss is acceptable. That's RPO. So these are the points that you need to define. So if you have an accessible, an acceptable loss of four hours for your business because it's, it's not about or the management, but it's more about monitoring of something and it's not really needed that, that is real time data. It can actually move along without having that. Then it's fine. But if it's something critical, let's say, for first responders, the fire trick came, came in as an example. Then an RTO, which is really fast, is necessary, like five minutes, ten minutes, these kind of things. But these are design decisions that will also help you ground and build your solution with, because that's an necessity for resilient application too. We only think about the architecture decisions. What's a really famous topic in what most you can, you can write it or say a little bit about this identity, network, data architecture, region surgery, platform engineer decisions, ten design, what, what, what, what did you think? To me, architecture is, is all about those because if you do, if you're building a solution, you need all of them. But it depends on what kind of an architect you are and there's multiple levels. I see myself as a solution slash enterprise architect because I also need them taking, taking to account integrations that are there. Dependencies that you have on extended systems or auxiliary systems like, let's say, for instance, you need to integrate within a, within a AP system. That doesn't mean that you need to be running it, but you need to know that if your system goes down, it might be a dependency on SAP, which will bring down the SAP flow, which will probably break down your invoicing or your order management or whatever kind of part that you that you're relying on that. So that's an important thing. But it also comes down to, I'm going to give you an example. If you, let's say, for instance, I'm going to give a real live example of something that I see every single year. It's taxes. So we have to, you have to push our taxes into, yeah, I don't know, you're in Germany, right? Or are you in Switzerland? And they are in Germany. I'm going to come back. Let's put that down. Okay. So I don't know how you do it in Germany, but each year we need to fill out our taxes on a certain site and we, and they have all that data. But everybody typically waits to the last few days and then the system breaks because there's not enough scale, there's not enough space, there's, there's timeouts because of things being troubled. I know it. So that's a typical use case of, of, of how a cloud application should work. And one of the things that always fails is our Belgian government has a, it's own identity system. It's an EID and you need to like, jacket your EID cart into a car, and, and, and, and that always gets worked. Especially on the, and it doesn't, and it doesn't always work because it always gives you timeouts and then, and then you need to update it and does work and then, and it fails again. And then once you get in, the token doesn't get recognized on the site and there's always something. Now, there's a small company, and there's a small company, which is now expanding out throughout Europe, a company which I'm really proud of. It's called It's Me and they build a, a digital identity based upon a phone verification and I mean numbers and they use the identity of your EID or your banking account because a banking account is a validated identity, a determinator. And they can really scale. So they don't, you don't need to validate against the state anymore. They do the validation for you, but they really scale and their application is existing into a, into a cloud building solution, in a, to a cloud build solution, which can on each of the levels of the application can scale and fail independently. So their backend will not be troubled by the front end and so on. Bringing that back then to the texting, once you authenticate, you feel again that the state's application is, is terrible because then you press the submit, there's a process being filed, but it's in real time. They don't do the a sync part and that's the thing. You need to be looking into how many of my features can I build a sync? How many of my features do I need in real time? It's all these design decisions and that's an application part, but also your, with that application part, you also need to design of the infrastructure behind it because a front end can easily, if you press a button multiple times and it does it immediately respond, will it break your front end? Right? But also, if you press it once and it keeps rolling, keeps doing pulse to the backend, that's a bad design decision because it's waiting for the backend. It should be loosely coupled and should be just pushing something into a queue and event source or whatever and making sure that it comes back like that. That way each of your layers of your application will be able to fail and scale independently and making sure that your application is resilient. After that, multiple regions and you have a full resilient application, but most of the applications, especially with the state, are not built that way. Why? Because we're running it in our own data center. It needs to be, it needs to be in our country. Germans are really good at that, by the way. Yeah. And I get that. You want to stay sovereign and you want to make sure that you have your data under control. But then you don't need to be starting to pretend that you're doing cloud applications. Then you're just doing hosting of these applications yourself and that's not the way you should be looking at it. If you're talking about applications which are being run in Europe, everything in Europe is valid as a landing zone for European applications. And sometimes you have these exceptions like in France, medical data and it's a stay in France in Germany. There's also certain data that needs to be in Germany. Belgium is just the same thing. We only have one type of application that needs to be on Belgium soil, especially in the cloud, but also in a data center that is gambling data because police need to be able to jack out the discs to see where there's white color crime involved and where there's fraud involved. So it's all these things that come to play. And when we were designing, a lot of developers don't think that way. They think about, "I want to make it beautiful and want to make it like technical and all display with that technology and do it by that." But if you then push it to production at scale, you see things break because they never thought of these things at scale. They never came into contact with things like distributed computing or event sourcing for that matter. So today we have a lot of tools that can help us with that. Think about tooling like Dapper, think about tooling like Radius, think about tooling like Aspire, which allows us to actually instantiate certain things in more instances, more pots, more services that can roll with those resilience factors. So that's basically what it comes down to. Yeah, I lose by on your LinkedIn and other profiles around the net and something you are really work on or your famous for is recent architecture. And I have some questions about the recent architecture. What is the difference between a variable? What is the variable and what is the difference? Yeah, it's a real. What did you think? So how available and resilient they go hand in hand and still they exist separately. So I always compare resilient with look at a tropical island. And what's typical for a tropical island is always palm trees at the beach and a palm tree is a remarkable thing. A palm tree is like you see them hanging over the water and they like high and they always go in bending in a bending shape. Now let's imagine that you are on that island in a tropical storm. El Nino for instance, passes there. What happens is all those palm trees when wind arises, all those palm trees they typically hit the floor. And they stay at the floor while the wind is there while the storm is still happening. At a certain point in time the storm stops and what happens is you see palm trees arise again like very naturally. Like you come back up. You can imagine it like in cartoons. That's resilience. It doesn't break. The palm tree stays a palm tree. And afterwards you can still see that a palm tree didn't or almost didn't suffer any damage. Right? High available means that it will break but you have a secondary palm tree that will take over its place but it's on another spot. So you still have, let's say that we just replant that palm tree afterwards. That's high available. Does it mean that it will be resilience? No, because there is a difference there. But resilience will also make sure that it will not go down but also there is no issue with regions that it will also be able to cope with the load that it will be able to cope with the scale that it will be able to cope with any mechanisms that happen underneath. That it can actually function while there is application errors and so on and so on. But available just means that we can ping it and that we can still have a available somehow. And if there is an issue we can just fail over. That's the biggest difference. I like this. I often hear one phrase. It's, yeah, it's, it's, it's highly available. I heard so often. I used to statement a little bit dangerous and where does Microsoft responsible end and where does the customer respond the begin from your perspective. So there is indeed the false premise that cloud is high available and high resilient. Now high resilience, that's a given. I mean, you have all these opportunities and all these solutions to make it out of the box resilient as possible. And think about how you can deploy Vm in multiple zones, for instance, or any compute for that matter. Think about storage accounts. A storage account has automatically underneath the hood three copies within a data center. And it will pass on on different, on different parts of the stamp to make sure that data can be consistently written to that stamp, to that data stamp. So Microsoft does some work, but that doesn't mean that your application will be fully resilient or fully high available because there's still some design patterns that you need to adhere to. And if you don't deploy your Vm, if you choose not to deploy your Vm in multiple zones, it will not happen. It will just be deployed in one zone or in multiple regions for that matter or in multi zone or regional regions and so on and so on. So these are design decisions. They come with some challenges, typically it's costs and also operations because you need to monitor them in a different way. But they also can help you speed up. And as I said earlier, where does the responsibility of Microsoft and well, once you start deploying, you choose to deploy only one in one region. Yeah, the break Microsoft will not be held responsible for your application to move, unless you say, of course, I want an auto failover, let's say with my Cosmos DB to another region because I designed it that way or where I have a read only copy there for that matter. These are things that you can have in your own control because you designed them that way. But out of the box, a lot of these services are not being enabled by a checkbox out of the box. You need to choose that yourself. And some some services do have that. They do an underneath under the layer scaling or they do an under the layer high available thing. Mostly if they're built upon upon containers, you will actually see that that they will have the Kubernetes lifecycle and needed. So these things do exist, but there's still a lot of decisions that you need to take your own. And you need to have some certain design patterns in fact in in mind like the circuit break if for instance, if you have a circuit break it does. Then if one service goes down, that doesn't mean that your entire solution need to be going down. Those were the examples that I already gave earlier in the discussion. So it's these things that you need to keep in mind. And luckily Microsoft has good guidance there. It's called it's called the bellar should take the framework where you can have design patterns and you can have all these design patterns like singleton circuit break or you cannot imagine how many they are, but they're all like well explained. And if you then combine with things like cloud adoption framework, you can actually build up on a full resilient application. Is that sufficient? No, you also need to be having some experience in how to do these things because documentation is one thing, but you also need to be monitoring that in a correct way. You also need to make sure that you understand what you're doing. Following documentation is not enough. You also need to think about these things and what happens if. And then there's an additional part because we can be prepared for that and we can build like that. Microsoft can offer us that, but are we sure now? And then there's one thing to do that's testing these things, right? And then you start doing like a what will happen? Will my resilience break if I put a lot of stress on it? If I put a lot of load on it and you can do things like playwright service, testing or Azure load testing. But what if something else happens? What if a region goes down? Well, you cannot just yak away the service. Then you go looking at things like Azure Chaos Studio and do fault injections, home production, on staging, whatever, whatever works for you. And use these as fire drills. Use these as exercises. Make sure that these things can work for you. And this is how resilience is being built up. It's not just one thing that you need to keep in mind of. It's the some of all fears that you need to combine. And bring in that to a single solution in one single architecture. So, so my, so home like let me more of 11 do it here. And I pay for the Azure SRA for the service level agreement. So I think I pay a lot of money for it. What? What's my misunderstanding about the SAs? So the service, the service level, the service agreement that you have with Microsoft is more about the support that you have. Preemptive or reactive, right? So they can do proactive support like, hey, they're going to go over with you over research, for instance. So you're going to see what the incident reports look like. How you can report that. But they will also go with you over your solution and take a look at, wow, what you built here, you should, and they're going to give the same advice like I do. But then it's grounded from their art. So it's actually hard evidence that they're going to give you and you're going to give you some reports and some assessments. And typically this comes with things like unify or support contracts where you can actually sign them all. So are they useful? Yes, the certain level they are useful. You always need them if you get good architics and you have a lot of credits and you have a lot of money also. You can just design these things as well. Use things like advise to have you well informed about the things that there are, but also take a look at service retirements, service updates and so on and so on because they also play. Microsoft actually, with their service agreement, they actually do this exactly, they do preemptive calls, they do proactive calls saying, hey, look, these things will happen. Maybe it's time to move into V next. Maybe it's time to start designing this. And by the way, you have a year and a half now to do that because in the year and a half, this will change. So this is where that kind of support comes from and where that kind of a service level is coming from at Microsoft. So it's not like that they are going to do a full switching. There will be a support when there's when there's when shit hits the fan basically and because they are being there for severity a severity, be severity, see, we'll have dedicated support people on that. Yes, that's true. But they will not guarantee you that they will monitor your service and put it up 24/7. That's your responsibility. But they will help you try to maintain that, like supporting you in that in that operation. I think in a little bit of we have the tailing of the guys, they have the energy or the RPO and we have as a side, I think there are more people, I call it the business reality. So how often do companies claim they need a zero downtime with, yeah, understanding what the requirements really cost? We're talking about the 9-0. That's always funny to see. I actually had it once, a partner coming up, I was working at Microsoft and a partner coming up and I, we need an Isla of 100%. And then we're like, good luck with that. You will never have an Isla of 100%. Not even at Microsoft. Not even if you're doing it yourself, you will never have 100%. Because the Isla is the product of all the Isla is of the different services that you have. Some services have 99.9, other services have 99.99, a couple of services are reaching up to five nines. But if you then have five nines, time, three nines, you only will end up with four nines. So that narrows down your Isla time and that narrows down your up time, your 100%. Is that a bad thing? No. But people need to be aware of their selling their service at 100% is a lay. They will shoot themselves in the photo already before they even sell it. [BLANK_AUDIO] Yeah, we have these are dudes, they say 100% are online and we have the outside, they have these SLA's, the service, that would be mean. What, Mike did you think about and can we reach the 100% really? Never, that's the biggest joke ever. People going up with that that you can have 100% isla, good luck with that because you always have component which is less than that isla. Don't forget that your isla is always calculated to the products of all these isla is combined. It's funny when I was murking at Microsoft at one partner, we were actually requested at a certain point in time. Yeah, we want a service which is, we want to build our service 100% isla up time towards our customers. You know, and like, good luck with that because if you're running on Azure, the highest capable service that you can have at, at, as a lay is 99.99, so five nines, that's the highest that you can reach. And you're like, oh, really? So combined that with an additional service, let's say 99.99, you're all of a sudden are back to three nines and so on and so on and they were, they were like really surprised. So it's a false premise that you can have 100% up time that's never given. But you want to make sure that you can be as close as possible and that you have mitigations and fallback scenarios to avoid that, let's say, 0.0, X percent. So to make sure that you don't fail, that you don't have a downtime, that you don't have to do a failover and it does failover, just make sure that you stay calm. And you have that plan B checked that it works, that you tested it before and then we're hoping that everything comes back up in no time, right? Because it's not only like moving into another region or like putting that, that backup plan or that as a lay plan and the interaction, but it's also going back to the normal situation afterwards because that's also something that a lot of people don't realize that if something breaks and if something fails, at a certain point in time, you need to head back over to the normal situation because your backup situation can never be your normal situation. Unless you can really say it's 100% on par on each side, that's also something that you can do, but then you're going to start paying a lot of money, for instance, right? And a lot of service will help you with that. Think about things like service buzz that will now copy cues into one region into another or high resilient and are available. Think about new service like Azure resilience manager. Think about new services like not all new services. Think about Azure site recovery. Think about Cosmos DB. All these services have these capabilities to quickly fail over into another region or into another zone for that matter and making sure that your service stays up and running. But 100% forget about that. That will never fly that will never happen. Yeah, for me, it's a, I never have, one time, one time, but it was Microsoft Teams Failure, something deployed, Microsoft something and I cannot use Teams, and it's really my most use tool. But when I think on the Azure services, for me is, it's, it's near zero-dalt time. That's what Microsoft aims to do too. Yeah, exactly. I mean, and we, Microsoft is being very helpful with globally deployed services. Think about, Intra, think about helping you with traffic management, thinking about front or service that they also use because they came from their own stables and they productized it afterwards. Front or for instance, it's been existing for over so many years. It was first used in service like OneNote, Sky for Business, but also Halo for instance. As a front, as an entry point. So that way it worked at scale, but it also worked for resilient because you know, you don't want to like piss off 150,000 gamers when they're doing a dead match in Halo for instance, right? You don't want to, you don't want to see that happen. Do you have claims going on? So that's something you try to avoid at all costs. And with the knowledge that they have of managing their own services, they now deliver services that can be up to 100% or at least five, nine's availability. But again, as I stated, you can get as close as possible, but it's always a sum of all fears. If you have multiple services at 99.9, well, it will never reach even two nines behind the coma. I think over three years, we have downtime for over 30 seconds. I think all my clients come in the 30 seconds, but in our sound, no joke. And we have talk about the IPO and the IPO and the business. And I think a little bit about it. Sorry for those because I'm only one person company and from you, nearly, yeah, I don't care. But what point do is another nine of the labels to stop making financial sentence when you talk to your clients as architecture and how did you see it? Is it the nine, nine, nine, nine, nine, nine, nine, nine, nine, nine, nine, nine, nine, nine, or I think, I say, let's have a present. It's good. I don't know. How did you see it? It depends on the business use case and it also depends on the way that they're looking at a customer management internally or externally because it's not always of external facing applications. If your sauce company, it becomes more important. If it's internal tooling or internal sites or internal applications, you can cure less because there's always something that breaks internally. To give you an idea, if a holiday application form internally for your company doesn't work for a couple of hours, that's an issue. It can be bypassed. I mean, if you manage it, it says go by mail, you fill it out tomorrow and so good. But if you have an order fulfillment system, for instance, where you are the next, let's say, Amazon or you are the next AliExpress or sheen, that's a different story because every minute that you have downtime brings you, breaks your bank, right? The costs are high. So you need to see for yourself what a financial impact will be of a non-resilient or a non-high available application. The resilience in the available applications here then become really something important because high available is one thing. That's bad luck in the cost of your bank. But if your application is not resilient, you always have some issues like tropling or whatever. Customers will stay away. That's even worse because if you have, let's say, for instance, that you are building the next Amazon and every click that you do to buy a product. And every click that you do to buy a product takes about five minutes to store it and then you see that your basket is empty, your shopping basket is empty. You know, people will stay away from this site and they will no longer be shopping on your site. They will go look and look somewhere else, even if you are cheaper than that because they cannot be guaranteed that their shopping basket will not be emptied every single time. And they try to buy it is my money paid, yes or no, will I get my stuff that I ordered? It's all these things that come to play. And this also comes with credibility of a brand, a key credibility of a platform. And certainly a front end. It's also the API that you're using. It's also about a trockling there. On the other hand, you should also foresee the bypass on that because it doesn't always work in the direction of, ah, your customers need to be resilient for your customers. It also needs to be resilient for you. What happens if somebody tries to attack you and if you'll bring you down, right? That's also something that the denial of all that service is a reality, right? You see a lot of SMS or SMS attacks because SMS OTP is a very nice thing to do and if you'll break your bank, right? Because every single SMS that you send out will cost you money and it will not cost the attacker's money. Is that a good design pattern? No, you try to do it in a different way. So it's all these little things that come to play. If you have an API which is constantly being troubled and it will also trouble then your application that is actually like a, a details attack that you have on your, on your API, even it was not intended like that. So it's also a protection mechanism. So it works in both directions. You want to make sure that you're protected, but also your customers are protected. It's not only about customer UX and experience. It's also about protecting the platform and making sure that everything is there. So as you can see, our shit actually is more than just of the parts that are moving. It's also protecting the parts encapsulating them, making sure they're safe, warm, well-nurtured, well monitored. Actually, you can see in our shit texture as a baby, right? It needs to grow. It needs to make sure that it gets warm and godly. It needs to be fed right on time. It needs to be provided and all in all primary necessities. That's a thing. And application of solutions are just the same thing. You need to nurture them. You need to monitor them. You need to feed them. You need to make sure that they're safe. So that's basically what comes out. Yeah. Or this was really cool, but I think what's about we like to get nearly the 100% and there's, I think it's not really new, but Microsoft allowed the multi-region architecture. For me, movie region, Asica sounds like. Yeah. It's the best result I can get. When multi-asica actually got a little bit wrong is the cost, is the data consensus, the agency is, so I don't know, application design, I don't know, I ask you, Mike. So we were talking about multi-regency. There's a couple of approaches that you can have. I do you do a failover or you do a full active active, just like you would do in the boss in the data center where you have two servers and you have an active server. Or you switch on the other server only when you need it. It depends on the choices that you have. But again, comes down to the RTO, RPO, that discussion, SLA, resiliency, that part. Designing these are indeed more complex because you need to make sure what will I do with my data? How will I design that? Because, all right, I have now, for instance, I have an application which needs to stay on European soil. Okay, fine. I will take multiple European regions. But I also have customers in the United States. Let's say, for instance, for some reason, an entire region goes down on the internet because somebody broke a main DNS or somebody broke an on the C cable which brought down the entire region. So there's no more USAID or no more South America, no India or whatever. Yeah, now we need to start looking into another multi-region design. Can we go cross-boundary? Can we move data? Can we are we allowed to? Right? So these are questions that you should ask yourself. There is a good set of design patterns which Microsoft calls mission critical. And there's a full design set on that. There's actually, I think there's even an A-K-Aid on the miss on that, I don't know, by hard, I think it's mission critical. I can look it up. But there's a full design spec on that which actually allows you to add it through to allow should take it framework. And specifically for those scenarios you get additional things like multi-region but also multi-data, center multi-region, what with the data, how should I approach these, what are the patterns behind it, what are design areas that are after it. We have indeed the data platform, we have the networking connectivity because, in typically you also start speaking about multi-outbreaks with the A-Kamon express routes. You have multiple hub spots, hub spoke designs on that level but you need to design multiple regions that way. You need to have a circuit breaker on networking level, you need to have a circuit breaker on the in-s level, you need to have a circuit breaker on public endpoints. The security will be different because you need to monitor on different levels. You also need to make sure that your security is being able to move on to another side so that means that you need to have a multiple log analytics workspace available for that failovers on these. So it's all these things that come to play. Rishing critical gets you there. There's a full design methodology behind that and specifically on reliability that you're going to design it with resiliency into that. There's a design for zero downtime deployments making sure that you can just deploy in a snap without interfering with all the other stuff. Then we talk about infrastructure, code, CI/CD pipelines that can also be warmed up very quickly so that way you're there, and immediately, and that your design is actually basically stateless and that you can just push it from one side to another. It's all these things that come to play. It's actually pretty cool from an architecture point of view because there are so many gears involved that it's actually very nice to see but it also comes with a surgical complexity that people need to be able to grasp it in a really correct way. That's the biggest issue, typically with mission critical. But there's design patterns to that as such. It's a really interesting question, Microsoft and all these other vendors deliver design patterns for how secure stuff. When I'm a hacker, I can look at these guys or these patterns, not secure. So this is my tech part. And I think a little bit about ROM somewhere or what I see is ROM somewhere. It's cool. I can talk a long time about it. But what really, what Microsoft really have an issue is the identity, the complexity, I say, hey, I'm Mercopeaters. I started with this a while ago. Hey, I am from the University. Can you give me the name for the professor that I call him and I get online every? What was Microsoft or the Azure do in this compromised? You mean like social engineering? Why is there more like? It's actually a good one. Microsoft has the security response center and they're actively monitoring a lot of things. If identity gets compromised at scale, they will probably know it before you know it. And again, there's a lot of things that you need to put up play to the responsibility also comes in your hand, right? Microsoft does a lot of work when it comes down to threat management and they have a threat intelligence center, which is looking actively at hacker groups and in all these ransomware groups. But it also depends on the design that you have. I am, for instance, I hate VMs just because of that reason. A VM is a liability because you still have to patch it yourself. Somebody can log into it. You typically cannot see it that somebody logged into it unless you are monitoring in a correct way, but even that the noise is getting lost in the bigger noise of the entire solution. So you don't always see that. So your first defense becomes your identity, but a lot of people just come in with a local user on a server where there's still a portal. And so people can just enter it. And before you know, they just confirm the entire VM, the entire network and so on and so on. Microsoft will be able to help you or assist you in his kind of attacks, but a lot of responsibility also lies on your hands. Are you monitoring correctly? The things installed like conditional access, do you have multifactor authentication? It's not for a no reason that Microsoft enforces now MFA on intra identity that it forces you to use pass keys on all your identity systems nowadays, just like any other security vendor or any other identity vendor for that matter. So it's all these things that come to play. Microsoft has the security response center, also the threat intelligence center. And they try to work with large customers on that level, but a lot of responsibility still ends up on your lap because you still need to have a good insight on what has been deployed. Microsoft can only just do as much stay, stay at the late look. We have found the CV in this software. We have packages that are gone rogue. We have a we have fixed an issue on the Azure port over tokens can get stolen. For instance, not saying that it is a fact, but these things happen, right? Everybody's guilty about because you building software, there's always liabilities and there's always dependencies. If you're building something at scale, anybody is vulnerable to it, where it's a cloud vendor, whether it's an AI vendor, whether it's a gaming industry part, there's always something which is vulnerable that nobody discovered yet. And there's always an entry point. And these companies can just do as much as that. They have no 100% guarantee that they will give you 100% safety. It's just like within the delay, they give you as much safety as possible. But it comes with a grain of salt. Ask within anybody as within anything else. Awesome. I think a little about, yeah, normally I have a rapid fire round. I ask your short questions or ask a question. And you give a short answer. Okay, I try to. It's just okay when it's longer. We have. I have a lot of time. Perfect. So, human needs is for application with three microservices, which one? So come again, sorry? My Kubernetes for applications with three microservices. With three microservices. A user, no, or should you or should you not? You get through everything you are on single island and you have only. It's just free microservices. Then Kubernetes is a little bit too bloated for that. I would say no, don't go for that and just run it as a function or run it as an app service. It's going to be cheaper too. Yeah, you still a little bit out of the transmission. Okay, I understand. I come from you, Cryatman, 99.99. 99.99. Is there ever a way of it? But we're choosing what the region cost. What's your answer? Good question. Repeat it? So a company has 99. 99.99, you can make it a long time. Available, but they refuse to pay for the multi-region. What's your answer? Yeah, that part doesn't get. I would say good luck. I love it. At that base, back up has never been restored. MNCS previously. Good luck. You should always test mistakes. If you called, no, no, no, no, no, my favorite question. Safial Dalia called you and said, Mike, A, all cool. I give you all the responsibilities and the money to develop something you like, which feature will it be? A feature or a service? You are free. I love it. Oh, I would say one of my web dreams is still to have a full graphical designer to design architecture, like a real designing in a graphical way your Azure architecture and that you also can immediately deploy the applications that you need for that. That would be cool. So think of a visual like, but then specifically for Azure, plugging in things and making it simple and stupid, but also based upon well architecture. And actually come to think of it, shouldn't be that hard to build nowadays with AI, right? Yeah. Yeah, yeah, this AI stuff. What did you think about Kubernetes for applications with our or should we use Microsoft, Microsoft? What's your own stuff, Mike? It really depends on the scale that you need, but also the complexity because Kubernetes is like steep learning curve. And if you have never done it, stay away from it. If you just want to focus on the applications and please go with container services or just app services and run it as a container there, I mean, depending on the use case, I would say. Mike, this was also awesome experience. I think, yeah, we have learned so much about Azure and applications and we are not believe it. I think I believe, but we believe of the percent of available time. Thank you so much. It's more a great interview with you. Yeah, it was great to make her. Thank you for having me. It was, it was my pleasure. It was also funny that we talked about resilience and that my internet went down during the discussions. That made it even made it more more powerful. Yeah, that's a thing. So that made it even more sarcastic and ironic, right? So that's a lot of fun. No, thank you for having me and yeah, I'm looking forward when this thing comes online. Thank you. [ Music ]