SDN Magazine Archives - SDN - Software Development Network

How Generative AI is Revolutionizing Data Platforms with Microsoft Fabric and Azure OpenAI Service

Artikel uit SDN Magazine 148 In today’s data-driven world, businesses use data to transform and achieve a competitive advantage digitally. As we reach a new era defined by artificial intelligence, this data becomes even more crucial. You can use and create everyday AI experiences that change how employees spend their time using generative AI and language modelling technologies. However, …

GraphQL voor .NET Developers

Artikel uit SDN Magazine 148 Binnen .NET oplossingen wordt voor het maken van webservices heel vaak gebruik gemaakt van WebAPI. Toch is dit niet de enige manier. In eerdere edities van het SDN-magazine heb ik al laten zien hoe gRPC hier ook voor kan worden gebruikt. Binnen het .NET ecosysteem zijn er nog andere mogelijkheden. Een van die mogelijkheid is …

The FAST and the Fluent: A Blazor story

Artikel uit SDN Magazine 148 Het lijkt bijna een titel van een film uit de populaire reeks maar dat is het natuurlijk niet. Wel hebben we ook hier een aantal interessante hoofdrolspelers. En die verdienen allemaal een nadere introductie. Zoals ze dat in films altijd doen, in volgorde van opkomst: FAST Simpel gezegd is FAST is een collectie van technologieën …

Het schalen van Azure App Service door Twan Koot(vrijdagstraat 18 1335LS Almere, 0621483292, twan.koot@ordina.nl) BIO: Mijn naam is Twan Koot, 30 jaar oud, en ik ben werkzaam als Principal Expert op het gebied van Microsoft Azure bij Ordina. Ik ben gespecialiseerd in het optimaliseren van applicatie performance in de cloud en het terugdringen van kosten. Naast mijn rol als Principal Expert, vervul ik ook de functie van Codesmith bij Ordina. Dit houdt in dat ik regelmatig optreed als internationaal spreker op diverse podia om mijn kennis en ervaringen te delen. Intro Maak kennis met Azure App Service, een juweeltje in de Azure-servicecatalogus dat snel een van mijn favorieten is geworden. Dit krachtige platform stelt je in staat om naadloos je lift-and-shift applicaties over te zetten van een virtuele machine naar een zeer gepolijste, semi-cloud-native app. Onder de vele indrukwekkende functies biedt Azure App Service zowel verticale als horizontale automatische schalingsmogelijkheden. Dit betekent dat je indien nodig rekencapaciteit op aanvraag kunt benutten of kosten kunt besparen tijdens periodes van inactiviteit. Maar hoe zet je deze automatische schalingsfunctionaliteit eigenlijk op? Welke metrics, instellingen en strategieën zijn essentieel voor een succesvolle implementatie? Laten we duiken in de wereld van Azure App Service auto-scaling. Basisprincipes van schalen Schalen is een cruciaal aspect van het beheren van computing power in een cloudomgeving, en er zijn twee primaire opties om te overwegen: horizontaal schalen en verticaal schalen. Horizontaal schalen houdt in dat er compute units, zoals VM’s of containers, van dezelfde grootte of type worden toegevoegd of verwijderd om wisselende workloads aan te kunnen. Een eenvoudig voorbeeld is het inzetten van nieuwe instanties van een app naast bestaande exemplaren of deze naar behoefte te verwijderen. Deze aanpak biedt een flexibelere en kosteneffectievere manier om schommelingen in de vraag op te vangen. Aan de andere kant richt verticaal schalen zich op het vergroten van de rekenkracht van een enkele node of VM. Een veelvoorkomend voorbeeld is het vergroten van de vCPU-cores op een VM of pod om de verwerkingscapaciteit te vergroten. Deze methode kan met name nuttig zijn wanneer specifieke componenten binnen een applicatie meer resources nodig hebben om optimaal te presteren. Zowel horizontale als verticale schaalopties voorzien in verschillende behoeften en scenario’s, waardoor het essentieel is om hun unieke voordelen en beperkingen te begrijpen om je cloudomgeving effectief te optimaliseren. Schalingsopties Azure App Service biedt drie verschillende schaalconfiguraties om te gebruiken voor diverse scenario’s. Elk van deze opties kan je helpen jouw omgeving te optimaliseren voor prestaties, kosten en betrouwbaarheid. 1. Handmatig schalen: Deze optie is ideaal voor testdoeleinden of de initiële opzet van de omgeving. Het is echter niet aan te bevelen voor productieomgevingen, omdat het handmatige interventie vereist om resources aan te passen, wat tijdrovend kan zijn en vatbaar is voor menselijke fouten. 2. Gepland schalen: Met deze methode is het mogelijk vaste data of tijden in te stellen voor het in- of uitschalen, waardoor het een handige en laagdrempelige oplossing is voor veel organisaties. Door te profiteren van voorspelbare gebruikspatronen, kan gepland schalen leiden tot zowel prestatieverbeteringen als kostenvermindering. Een goed voorbeeld is het terugschalen van de infrastructuur tijdens de nachtelijke uren of in het weekend wanneer het gebruik doorgaans lager is. Deze benadering zorgt ervoor dat resources efficiënt worden toegewezen en tegelijkertijd optimale prestaties worden gehandhaafd tijdens piekuren. 3. Automatisch schalen: De laatste optie is automatisch schalen, dat het schalingsproces automatiseert op basis van metrics of events. Door automatisch schalen in uw omgeving op te nemen, kunt u het meeste uit de Azure omgeving halen door efficiënt hoge piekmomenten te bedienen en tegelijkertijd een kosteneffectieve opstelling te behouden. Deze dynamische methode past resources in realtime aan om aan de eisen van uw applicatie te voldoen, en maximaliseert zowel prestaties als kostenefficiëntie. Bij het configureren van Azure App Service is het essentieel om de juiste schaalinstelling te kiezen op basis van specifieke behoeften en gebruikspatronen. USE RED Als je automatisch schalen op basis van metrics en events wilt implementeren, is het belangrijk om te beginnen met de juiste basis. Ten eerste, concentreer op het verticaal schalen door de juiste instantiegrootte te selecteren. De reden hiervoor is dat het wijzigen van de size van een app-instance een herstart vereist, wat de beschikbaarheid kan beïnvloeden. Om de juiste size te bepalen kun je de volgende stappen volgen: Load Testing: Begin met het testen van de applicatie onder verschillende belastingen om de prestaties en resourcebehoeften te begrijpen. Hierdoor krijg je waardevolle informatie over hoe de app zich gedraagt onder verschillende omstandigheden en kan je onderdelen identificeren die geoptimaliseerd moeten worden. Optimalisatie: Analyseer de resultaten van de load testing en voer indien nodig optimalisaties uit om de prestaties en efficiëntie van de applicatie te verbeteren. Denk bijvoorbeeld aan het verfijnen van de code, het optimaliseren van databasequery’s of het benutten van caching-technieken. Selecteer een geschikte grootte: Kies op basis van de testen en optimalisatie-aanpassingen een geschikte instantiegrootte voor de app. Je kan bijvoorbeeld kiezen voor een P1V3-instantie. Onthoud dat het over het algemeen raadzaam is om te kiezen voor de kleinst mogelijke sizing, omdat dit meer controle biedt bij het schalen en grotere kostenbesparingen kan opleveren in vergelijking met het altijd vertrouwen op grotere VM’s. Door deze stappen te volgen, wordt er een solide basis gelegd voor het automatisch schalen op basis van metrics en events. Om automatische schaling regels effectief te implementeren binnen Azure, is het belangrijk om een applicatie te monitoren met de juiste aanpak. Twee populaire monitoringmethodologieën kunnen helpen bij het opzetten van schaalregels voor het op- en afschalen, waarbij het laatste cruciaal is voor het verminderen van kosten. De eerste methodologie is USE, wat staat voor Utilization (benutting), Saturation (verzadiging) en Errors (fouten). Utilization (U): het deel van de resource dat wordt gebruikt, dus 100% benutting betekent dat er geen werk meer kan worden geaccepteerd; Saturation (S): de mate waarin een hardware resource extra werk heeft dat het niet kan verwerken, waardoor een wachtrij ontstaat voor deze resource; Errors (E): het aantal foutevents; Hoewel de USE-methodologie een waardevol startpunt biedt voor automatische schaalregels door middel van resource-monitoring, is het misschien niet de meest effectieve aanpak voor het optimaliseren van kosten en gebruikerservaring. Door te concentreren op gebruikersgerichte metrics, kunnen efficiëntere regels ingesteld worden die beter aansluiten bij de werkelijke behoeften van gebruikers. Hoewel infrastructuurmetrics belangrijk zijn om problemen zoals “out-of-memory” fouten te detecteren , sluit een gebruikersgerichte benadering beter aan bij het uiteindelijke doel van het bieden van een optimale gebruikerservaring. Een gewaagde uitspraak om dit perspectief te benadrukken is: “Ik vind het niet erg om 100% CPU- of geheugengebruik te hebben, zolang gebruikers er niet door worden beïnvloed; ik gebruik alles waarvoor ik heb betaald!” Door gebruikerservaringsmetrics te prioriteren, kan je betere beslissingen nemen over wanneer op- of af te schalen, zodat resources efficiënt worden toegewezen en tegelijkertijd een hoogwaardige ervaring voor de gebruikers wordt gegarandeerd. Een goede manier om dit soort metrics toe te passen, is door de RED-methodologie te gebruiken die voortkomt uit Google’s SRE-aanpak. RED is afgeleid van de Four Golden Signals, wat ook een goede manier is om elk op metrics gebaseerd systeem op te bouwen. Snelheid (R): Het aantal verzoeken per seconde. Fouten (E): Het aantal mislukte verzoeken. Duur (D): De tijd die nodig is om een verzoek te verwerken. In mijn optiek is duur een zeer effectieve metric kan zijn voor schaalbeslissingen, voornamelijk omdat het nauw verbonden is met de gebruikerservaring. Uitsluitend vertrouwen op foutgebaseerde metrics, zoals HTTP 503, kan reactief zijn in plaats van proactief, omdat het te laat kan zijn om het probleem met schalen op te lossen tegen de tijd dat de fout optreedt. Op dezelfde manier kan het gebruik van snelheidsgebaseerde metrics uitgebreide prestatietests vereisen om het exacte punt te bepalen waarop de gebruikerservaring verslechtert. Duur, aan de andere kant, is een intuïtievere en proactievere metric die u in staat stelt om een consistent performance voor elke gebruiker te handhaven. Door u te concentreren op responstijden, kunt u ervoor zorgen dat extra capaciteit precies wordt gebruikt wanneer dat nodig is. Bovendien is duur een metric die gemakkelijk te begrijpen is voor zowel technische als niet-technische teamleden, waardoor het eenvoudiger wordt om te communiceren en verwachtingen vast te stellen. Door vragen te stellen als “Hoe lang zou een gebruiker moeten wachten op een reactie?”, kunt u duidelijke doelen stellen en beter geïnformeerde beslissingen nemen over wanneer op- of af te schalen, wat uiteindelijk leidt tot een betere gebruikerservaring. Hoe meer zielen, hoe meer vreugd Voor een robuuste en proactieve schaalimplementatie is het belangrijk om responstijd te combineren met andere relevante metrics en inzichten uit loadtesten. Deze benadering stelt ontwikkelteams in staat om prestatiepieken of -degradatie nauwkeuriger te voorspellen, waardoor effectievere schaalbeslissingen mogelijk zijn. Aangezien het opstarten van nieuwe instanties tijd kost (van enkele seconden tot minuten), is het kunnen voorspellen van aankomende werklastpieken essentieel om optimale prestaties te behouden. Evenzo is het belangrijk om rekening te houden met het afschalen op basis van meerdere metrics om mogelijke prestatievermindering te voorkomen. Terwijl een korte periode van lage responstijd bijvoorbeeld kan suggereren dat bronnen kunnen worden verkleind, kan het totale aantal verzoeken per minuut aangeven dat prestatieproblemen waarschijnlijk zijn als het verkeer toeneemt. In dergelijke gevallen kan het verstandig zijn om extra instanties langer te behouden om mogelijke verkeerspieken op te vangen. Door een uitgebreide benadering te hanteren die rekening houdt met meerdere metrics en inzichten uit prestatietests, kunt u een effectievere schaalimplementatie creëren die optimale prestaties en gebruikerservaring garandeert en tegelijkertijd kosteneffectief blijft. Conclusie Azure App Service is uitgegroeid tot een krachtig platform dat organisaties in staat stelt om hun applicaties efficiënt naar de cloud over te brengen, terwijl het schaalbaarheid, kosteneffectiviteit en prestatie optimalisatie biedt. Om optimaal gebruik te maken van de automatische schalingsmogelijkheden, is het cruciaal om de verschillende schalingsopties en configuraties te begrijpen, evenals de metrics en strategieën. Door te concentreren op zowel infrastructuur- als gebruikersgerichte metrics, kunnen ontwikkelteams robuustere en proactieve schaalimplementaties creëren die inspelen op de werkelijke behoeften van gebruikers en tegelijkertijd optimale prestaties behouden. Het implementeren van automatische schaling met Azure App Service vereist een solide basis van horizontale schaling en de juiste instantiegrootte, evenals een goed doordachte schalingsregels die is afgestemd op de behoeften en gebruikerspatronen van de organisatie. Door zorgvuldig de balans te vinden tussen prestaties, kosten en betrouwbaarheid in de cloudomgeving, kunnen organisaties ervoor zorgen dat ze de voordelen van Azure App Service kunnen maximaliseren.

Artikel uit SDN Magazine 147 Maak kennis met Azure App Service, een juweeltje in de Azure-servicecatalogus dat snel een van mijn favorieten is geworden. Dit krachtige platform stelt je in staat om naadloos je lift-and-shift applicaties over te zetten van een virtuele machine naar een zeer gepolijste, semi-cloud-native app. Onder de vele indrukwekkende functies biedt Azure App Service zowel verticale …

Van Dev naar DevOps.

Artikel uit SDN Magazine 147 Door een collega werd ik gevraagd om een te schrijven met DevOps als topic en daarin te reflecteren op mijn ervaringen. De afgelopen tien tot vijftien jaar heb ik aan een aantal organisaties richting gegeven en zelf ook deelgenomen in de verandering van Dev naar DevOps. Daarnaast ben ik in mijn huidige rol, waarbij …

Hacking video games with C# – Frank van der Stam

Artikel uit SDN Magazine 147 Like many of us in the tech industry, I have enjoyed playing games from a young age. Sometimes I would want to do things in games that you were not really supposed to do. I would use open source tools and trainers to do this, but was clueless as to how any of those tools …

Bias in AI creeps in faster than you might think.

Artikel uit SDN 147 The future is AI. Artificial intelligence (AI) is revolutionizing the way we live and work, from powering virtual assistants and self-driving cars to aiding medical diagnoses and detecting fraud. With the rising popularity of what AI can do for you there has been a surge of new tools like ChatGPT or AI Builder within the …

5 manieren om bij te blijven als Software Ontwikkelaar

Artikel uit SDN 147 We weten allemaal hoe het is. Overal om ons heen zien we nieuwe programmeertalen, nieuwe frameworks en libraries opduiken, die allemaal op een nieuwe en spannende manier een probleem proberen op te lossen dat veel mensen irriteert. Goede ontwikkelingen zijn dat! Maar helaas kunnen deze snelle ontwikkelingen je ook het gevoel geven dat wanneer je …

Will ChatGPT replace developers?

Artikel uit SDN 147 Artificial Intelligence models Let’s start with a short recap of what ChatGPT is. Built by OpenAI, which is backed by Microsoft, it’s a model which in itself is the output of the GPT-3.5 algorithm (GPT-4 as of March 2023). Put in layman’s terms; these models are the result complex algorithms which (kind of) resemble the neural networks in our …

SDN Magazine 153

E-mailadres
Ik wil graag de SDN nieuwsbrief ontvangen