Hello , good morning , good afternoon wherever you are . Welcome to Microsoft Community Insight Podcast , where we share insights from community experts to stay up to date in Microsoft . I'm Nicholas and I'll be your host today . In this episode , we will dive into Azure Cloud Architecture for high availability and low latency .
That's a long one , and before we get started , I want to remind you to follow us on social media so you never miss an episode , to help us reach more amazing people like yourselves , and today we have a special guest called Florian Linz . Can you please introduce yourself please ?
Sure , thanks . Yeah , I'm Florian . I'm working as a solution architect , as a freelance consultant . I help my clients to make their cloud architecture better and more stable , and so this is why , as well as this , topic of cloud architecture for high availability and low latency came in place .
And yeah , today I want to talk with you about this topic and yeah , let's see how we go further .
Okay , so as a freelancer , what kind of projects have you been involved with for your clients ?
Well , it's various projects so it depends highly on the customer , but at the end , as I told , I'm working as an Azure consultant , so it's basically always any relation to Azure .
One project is , for example , currently creating an Azure landing zone for a customer , or they already created this landing zone concept and now my part is to bring some subscriptions into the landing zone , help them to architect the whole subscription and the resources . And other projects are some less architecting and more programming .
So I'm I started as a programmer a lot years ago and , yeah , now I'm more architecting but still programming , and in such such a projects I work as well as a programmer and then just doing doing programming stuff .
Yeah , is that ? Is it your own ? Is it just yourself in that project Do ? You have any colleagues , if it's a bigger project .
It depends . I was on one project . It was only myself . It was quite okay , but at the end it's a little bit lonely when you work all day long only for yourself . Maybe there's a project manager where you give some information and that's it . And most of the time I'm working in projects with multiple people , but honestly I'm as an external one .
I don't work in the company , but I work with people from the company and , yeah , helping these people to get the best out of it .
Yeah , it's similar like a contractor really , you're not officially employed , but you're employed by them , the client . So in today's theme we're discussing high availability and low latency . So can you give us some use cases in your project that you've worked on that have high availability ?
Yeah , I mean basically high availability is or at least in Azure there are multiple concepts of high availability . I mean there is for sure the high availability Everyone knows of the gear redundancy , globally high availability .
So basically , um , before all the cloud stuff , when you have a on-premise server and you run it in for example you in uk or me in germany um , then it's for sure , when this server is not running anymore , we have a problem , because then our , our solution is not working .
And then with gear redundancy we can just add one server to our server farm , for example in the USA , and then we have some kind of high availability . So that means when , for example , in Germany , my server goes down , there's still a replication off in the USA .
So everything's working fine , more or less , but then the traffic goes to the USA instead of Germany . Everything's working fine , more or less , but yeah , then the traffic goes to the USA instead of Germany and this is it . But in Azure we have not only this gear redundancy , we have as well zone redundancy and local redundancy .
And this means , for example , that in Azure we have , when you have some , for example , a storage account , you can choose . You can choose local redundancy , um , zone redundancy and gear redundancy . Uh , I just don't talk about read only access , but this is we have and basically gear redundancy as I told , it's globally replicated .
Then we have zone redundancy , which means when I select , for example , example , west Europe I guess West Europe , the region is in the Netherlands Amsterdam region Then this means that in this region there are multiple data centers from Azure and this resource is replicated through these centers , which means when one center , for example , has an outage or something else
, there are two other centers which are still running , hopefully , and then it's regional redundant and then it's local redundancy , which means there is only one data center and inside these data centers I have multiple instances . I guess it's all the time three . Inside this data center , I have multiple instances , I guess it's all the time three .
And yeah , basically this is one server rack and when one server rack goes down , then there are two other ones . But when the whole data center goes down because of an outage , for example , yeah , then with local redundancy I don't have any running instances , okay .
Is there any particular resources that you would recommend ? Like to do load redundancy , because I know you can do like app gateway , traffic manager or , if you have like , scale yeah , I mean , this depends on on your needs .
Um , there is a quite good um , yeah , quite good description on Microsoft Learn , but basically , when you have a website , for example for low latency , you can use Azure Front Door . So it's a content delivery network and basically , by using this , you have all the advantages of a content delivery network .
It's quite fast and , yeah , when you work with Azure , I mean , it's quite easy to use Azure Front Door .
Okay and yeah , when you work with azure , I mean , it's quite easy to use azure photo . Okay , so which which one do you use often to to replicate , like whether it's like if it were like a vm , like a architecture ? Which one would you recommend ? Would you recommend for high availability ?
I mean at the end . I mean there are four . It's Azure Front Door , azure App Gateway , api Gateway , I don't know . There are four instances you can use and basically , it highly depends on your requirements . So , basically , most of the time , I'm using Azure Front Door instances you can use and basically , it highly depends on your requirements .
Um , so , basically , um , most of the time I'm using azure front door , um , this is is a . On the one hand , it's because it's a content delivery network and for websites , which is most of the time what I'm , what I develop or what , uh , what is in my infrastructure .
Um , this is more or less the best solution and , furthermore , in azure fronto you have um the web application firewall , so you have some basic security , um sql injection , um or to to check if there's a sql injection , your requests , and this is yeah , basically out of the box from azure front door , which is when I have a web application .
Most of the time I'm using Azure Front Door when it's global redundancy .
Okay , so that's it . I'm curious to know , since you have freelance , do you use infrastructure code like Bicep Terraform ?
Yeah , sure .
You're like architecture .
Yeah , I was in a project and I really like it that there was a project manager and he told all the time we want to automate everything and we don't want to do anything manually , because otherwise you do it , for example , in the development environment , and then after some time you don't know what did you do ? Why is production not working whatever ?
And so we started with infrastructure as code , and for me most of the time it's either arm templates or bicep . Um , yeah , depends a little on on what I what I'm doing . Um , but terraform . Honestly , I don't really work with terraform .
For me there's some kind of abstraction I do not really like , because at the end , I'm an Azure architect , I work in Azure . I don't want to go to Google Cloud Platform or AWS , for example . So for me , terraform . The advantages of Terraform are not that big and the disadvantages are quite bigger , so I do not use it .
Yeah , otherwise you could go into Bicep because they're fully Microsoft itself . So , aside from , I know monitoring is a key aspect of high availability . What other metrics are you used to monitor high availability and low latency ?
Basically as well . It highly depends . But , for example , what I know is when you have high availability , or at least you want to have a high available system , you have always the problem at least you want to have a high-availability system you have always the problem that there's a requirement that there is no downtime allowed .
I would say so you have SLA , for example , that 99.99% , you guarantee that your software is working , for example , and then you want to have high availability in your system .
And when you want to have , yeah , high availability in your system , and when you want to have this , you need to have a look to , for example , azure resources and have a look as well to the slas from microsoft . So , for example , cosmos db , I think it's 99.999 percent . Uh , no , it's 4 nines , so 99.99% .
And when you want 5 nines , for example , you'll need to go to a higher available solution or use a different SKU . So , basically , this is one metric , for example , that when you have some kind of service level agreement that you need to check the agreements from Microsoft or other resources you are using .
MARTIN SPLITTINGER OK , yeah , yeah , because I think I myself use just built-in Azure Monitor metrics to monitor the resource , whether it's traffic manager , app gateway , and just create some alerts and new things . Yeah , I think before you mentioned , you got some slides , marissa . I have some slides .
Yeah , I have some slides .
Yeah , we can show it if you want . Yeah , because we got quite a few viewers .
Yeah give me a second .
I see you got cloud light .
Yeah , there's a lightning inside the cloud , so it's all . Honestly , it should be some kind of Azure serverless Because it's probably like a function .
Yeah , it's like a function .
Yeah , exactly this is the idea .
Function in the cloud .
So , present .
Yeah , if you share your screen , I can just put it up on your screen here .
Yeah , I share my screen .
Yeah .
Perfect , yeah , so basically , exactly um . One interesting um fact I found in the internet is from google , and google found out some years ago that when your loading time increases , that as well your bounce rate is increasing . And from zero to one second , for example , uh , it's , yeah , not really measurable that , yeah , there is a bounce rate .
So , for sure , when you are , when we have , for example , 900 milliseconds loading time , it's not as good as when you have , for example , 300 , but up to one second it's more or less okay . But from one to three seconds it's on as well , it's already increasing and it's more or less okay .
But from one to three seconds it's on as well , it's already increasing and it's highly increasing when you have a loading time more than three seconds .
Sorry , what's bounce rate ?
Okay , bounce rate is the number of people who leave the site . So you go to the site . It's loading one second , two seconds . Okay , it takes too much seconds , I close it , I don't care about it's , it's too long .
So this is a bounce rate and , for example , when you have , I don't know , in general , you have three people who leaves the page because it's too slow , when the load time is up to oh , yeah , it's one to three seconds , then the bounce rate increases by 32 , which means when , in general , you have , for example , three people , um , going back from from your
site when it's too too slow , then when it's more than one second and up to three seconds , it's not three , it's four . And when you have , for example , now , 100 or 300 people leaving your page , then it's 100 000 people more , only because your page is too slow . And this could be one thing .
When you have , for example , this is not directly something with high availability , but something with low latency we go , um , yeah , maybe afterwards as well , um , but yeah , this is some interesting page , I think , and some some some information I got from google , yeah , which is quite impressive , I guess .
For example , as well , when you have a page , a webshop , for example , where you get money from . So it's a different idea when you have I , I don't know just a web page to show some information or a blog , for example , it's not nice , but it's okay , I guess .
But when it's a page like Amazon , yeah , this is money which you lose because only you have a slow web page . And , as I already told Amazon , yeah , for Amazon , we have , for example , the following I got the information I , I guess , three weeks ago um , this numbers is for are from 2014 and I guess 2018 or 19 .
There are newer numbers , um , which means that amazon goes down and loses 66 000 per minute , and I guess they were down half an hour , which means they lost more or less five million dollars or something around . Um , yeah , which is a quite high number , a high number for sure .
And here we come to the topic of high availability , because , at the end , amazon is a web page where you can , yeah , shop , go shopping and buy stuff . You pay more or less on amazoncom , and when the page is not available , you or Amazon lose money . And here's the same like with low latency .
When you have a blog , maybe high availability is nice , but it's not really recommended or maybe the advantages of high availability is not really for you when you have a blog , but when you get money from your website , maybe it's a more more required um solution . You want to . You want to have that . Yeah , you have high availability , um .
So basically , these are two facts . I found um which I think , based on the requirements and the solution you want to create , high availability and low latency could be something for you . And basically , when we have a look , what does it mean ? Low latency ?
Low latency means we have , for example , as I told you at the beginning , we have , for example , a web page it doesn't matter if it's hosted an app service plan in a vm .
However , when there is a server in germany , for example , and the customer from the usa talks to my page I have hosted in germany , then there is around 200 to 300 milliseconds of latency , just because the whole traffic needs to go from the USA under the Atlantic Ocean to Germany and back , and this is 200 to 300 milliseconds .
We just lose because there is no server close to our customer as well . A block , not a problem . Amazon , for example , should create instances quite near to their customers Because at the end bounce rate as well 300 milliseconds , then you only have 700 left . When you have a server close to the customer , maybe there's a latency of 50 , maybe 100 milliseconds .
Then you have a little bit more time to load the data . So for high availability we have , for example , the following you have , as I told as well in the beginning , we have multiple instances around the world . And what happened now ?
When a customer from CSA wants to go to our website , thensa wants to go to our website , then yeah , he wants to go to the website .
The website is not available , so he will get data from the instance from germany , for example , then for sure , we have the problem of higher latency , but at the end maybe it's better to have a higher latency but still get data instead of having low latency and when this low latency server is not available , we just don't get any data .
So maybe , or we have this wonderful world where everything is working with high availability , so available system and low latency , because the server is near to the customer . And in the not so nice world we have , yeah , not not available system , but then a higher , higher latency , but we still have data yes , sorry .
so what happens if you have like one zone and one data center near you and you can't go elsewhere because data sovereignty ? If you're in a public sector , what option would you choose ? Would you choose like backup and stuff with scaling , because you can still use high availability and just like between two other resources in one zone in a way ?
So in one zone basically , yeah , one zone is spent . I don't have the correct numbers , but some hundred kilometers I would say . So it's quite near to the other center , so this is not a problem . I guess the bigger problem is really when you have yeah data centers around the world , then it's maybe a bigger problem .
Okay , and these are all the data centers that you worked on .
No this is just a picture . I wrote some data centers At the end . Most of the time as well , it's highly dependent on the requirements .
For example , when you create a solution and you have some numbers from your company and the company say , hey , we have 50% of our customers live in USA , 20% live in Europe , I don't know , 30% in Australia , maybe it's based on these numbers , you can create your solution and , honestly , then you don't need to 30% in Australia .
Maybe it's based on these numbers , you can create your solution and honestly , then you don't need to have a solution in South America , for example , but for sure you can as well add these regions , for example , as a backup , because maybe when you add in Mexico one data center , maybe it's not called very often because in best case all the US instances are
working . But when the US instances are not working , maybe the Mexico instance is working and then you have to back up to Mexico , which is , I guess , quite nearer than Europe . So this is not a problem then to have the lower latency for Mexico and this could be a solution .
But here at the end it depends on the requirements and the numbers from your company yeah , even if it's like financial company , like trading they want .
It's like zero latency , not point something , so that when you have can only do it like whether it's through on data . It just depends on the client itself really .
Yeah , yeah , basically I have some . Now we can go to the serverless topic , but I guess this is not a good idea .
Maybe some other time , but yeah , at the end the talk is a presentation I held on conferences and in this talk I go further into the topic of why serverless could be a good solution for such a high availability , global , redundant high availability system . Because of the payments you need to pay , so the cost of your solution .
When you have VMs , it's basically no matter how much traffic there is on the virtual machine , you need to pay for it . In serverless you pay only for the request and I take some numbers and ideas and I guess it's a quite good presentation , but I guess for today it's quite too long .
So would you recommend serverless instead of like past service , instead of like a vm itself , because vm is just on primaries , it costs quite a lot . So you need people can have an option to move serverless or a pass like using app service container access .
Yeah , for me , for example I mean , I'm a serverless enthusiast , I would say so I really like using serverless . I have a YouTube channel about serverless and for me it's a quite nice and good solution . But , as well , here the requirements are highly dependent . So when you have , for example , or the advantage of serverless , you pay only for the requests .
You do so . In best case , one request I guess 1 million requests costs you $4 . And I don't know best case with 1 million requests you get $10 . So you make a profit . In such a case it's not a problem as well when you have when the load on your system is not predictable .
In such a case as well , serverless could be a better solution because of the automatic scalability . You don't need to have a lot of the infrastructure etc . You can just focus on programming , doing your job and that's it .
There are some advantages but honestly , there are as well disadvantages and , for example , one disadvantage when you have a look to serverless , for example , you have the Azure function , you host it , you can host it all over the world , in every region , and it costs you exactly the same as , or every request costs the exact same when you have it only in one
region or in 100 regions , for example . So this is quite nice , but on the other hand , you need a Cosmos DB . The Cosmos DB needs to be globally replicated . Maybe you need as well multiple write regions , because otherwise you have the latency later on in the database .
And these are some disadvantages you need to have in mind because , for example , with a VM , you have the disadvantage of it's not so scalable . You pay before or you pay a fixed number , but in the vm , for example , you can host your application , you can host the database and you don't have any problems or smaller problems .
Basically , with um , yeah , having as well a database instance , for sure , then you need maybe some , some logic to replicate all the data , but at the end you have , yeah , you have the advantage at the disadvantage of , disadvantage of um , yeah , take care of the whole infrastructure with all the pros and cons .
Yeah , plus , serverless is quite cheaper compared to cost , compared to VM itself . It would save you quite a lot of money as well . How would companies optimize cost for high viability ? So how would people scale it ?
Like you mentioned serverless and so Cosmos DB you just mentioned as well , if someone wanted to do like FinOps in high scale , high availability , like architecture , how would people , someone optimize costs as low as possible ?
I would pay to someone , optimized cost , as low as possible . Yeah , at the beginning , what I always see as a consultant when I go to a new project , most of the cases are , first of all , over-provisioning .
So you have , for example , an Azure Function app and you guess , okay , it's fine , they're using serverless Azure Functions , they have in mind some kind of serverless first mindset . And then you go to the serverless Azure function app and you see premium plan and you think , oh God , so they pay thousands of zeros per month . And okay , wow .
And then you think , okay , it's fine , let's go to the request . And then you see , for example , two thousand requests per month and then I guess , okay , they pay more or less one zero per request . This is not a good solution .
I would say , um , and in such a case , for me it's always like don't over provision , start small , think of what you really need and maybe , um , yeah , have a , have a , some kind of plan b , when plan a is working or it's going further and it's gotten bigger , that you then exactly know what you need to do to get these new numbers as well .
So , basically , you start with a consumption plan , or I guess it's called flex consumption plan . Now Azure introduced it in preview , but in general it's a better consumption plan . So it's an idea of pay-as-you-go in an Azure Function environment and with this flex consumption plan you have the advantages of VNet integration .
I guess cold starts are more or less reduced .
So I guess starting in a company or an enterprise environment , starting with a flex consumption plan , is , for me , I would say , the best starting point , because at the end you can go to premium plans whatever after some time , or you start with Azure container apps , so basically a Docker container which runs serverless , pay as you go , and when you don't want
to do true bundled serverless , you can just use your own Kubernetes cluster . So this is as well a quite good solution .
Okay , brilliant . As this episode is coming to an end , is there any last-minute resources or tips you would recommend other people to learn or be aware of when they want to learn more about availability and the latency ?
At the end . Yeah , microsoft Architecture Center is a quite good learning platform , I would say , where you can see architecture styles and learn from them .
I told you at the beginning I used it sometime , but it's some time ago now as well , but honestly , this is a quite good solution to find different architecture styles , found solutions and , at the end , for sure , learn from these solutions for your own work . Basically , architecture center . That's all done .
In a way , you need to keep monitor and scale , scale , know when to scale , in order to minimize costs as well . Okay , so , so , as is there any ? Are you going to any events ? Tech events ? So , if sorry , are you going to any events ? Tech events ?
Yeah , now in October I don't have the correct numbers in mind there is a serverless architecture conference in Berlin where I have a talk exactly about this topic and this presentation where I go deeper into the topic with Azure Fronto as well Azure Functions , cosmos DB and make a small demo of how we can use this solution .
I go deeper into the topic with Azure Frontal as well Azure Functions , cosmos DB and make a small demo of how we can use this solution for high availability and low latency . And then there are a lot more conferences , I guess , for this year .
Where is Okay ? Is that in person ? I take it that conference you're going to .
It's in person , yeah , right , okay , when is it , sir ? End of october , I guess 23rd , 24th , I don't know exactly that's brilliant , okay .
Is there any last minute like tips that you want to advise people or resource that you want aside from architecture center , or any tips that people want to be aware of when designing a low-light , high availability architect ? Oh , good question . Uh , any like challenges or any ?
Any pointers would you recommend , like someone that's to be aware of , whether it's like some challenge that you've made in your journey ?
yeah , one big topic . Um , when you , when you have low latency on your web page or web application , so it doesn't mean that your database is low latency .
So when you make a high availability , low latency system , have a look to your database as well , because when you have your database only in one region , then it's nice that your web application is low latency , but then the call is not from the customer goes to the web page , but from the web page to the servers going through the Atlantic Ocean that you don't
have , yeah , win anything . So have in mind database is important as well .
Okay , All right , okay , so thanks for joining this episode , florian , so in a few weeks you're going to be on the music Spotify and be live with O2 Media , so thanks , thanks for joining this episode . Bye , thank you for joining this episode Bye , thank you , bye-bye .