Application development op Microsoft Azure | Deel 1

Heb je simpelweg de code en runtime verplaatst van een Virtual Machine naar een App Service, of ben je bezig geweest met de herontwikkeling en re-factoring van delen van je code om het beter geschikt te maken voor Microsoft Azure?

 

Mogelijkheden voor integraties binnen Azure

Wat we bedoelen met "Azure echt gebruiken" is ook het stukje integreren met andere technologieën en gebruik maken van de kracht van de cloud?   

Laten we het volgende scenario eens bekijken: 

Cloud Adventures is een softwarebedrijf dat een webwinkel aanbiedt aan haar klanten. Hun oplossing is een MVC applicatie gebouwd in .Net die gebruik maakt van een SQL database voor het opslaan van orders. Daarnaast hebben ze een aantal klant-specifieke aanpassingen lokaal opgeslagen (op de webserver). Hun oplossing bevat code die verschillende lagen en diensten levert om toegang tot de database en lokale opslag mogelijk te maken, en daarbovenop hebben ze een API endpoint toegevoegd voor hun klanten waarmee ze een lijst van orders en de orderstatus kunnen opvragen. Klanten kunnen deze API gebruiken om te integreren met hun CRM systeem.  

Een paar zaken springen in het oog. We kunnen snel concluderen dat Cloud Adventures veel functionaliteit in één oplossing heeft gebouwd. Je hoort vaak de term "monoliet" om zo'n configuratie te beschrijven. Dit is meestal het resultaat van twee dingen:  

1. Het bedrijf begon met een of twee ontwikkelaars die met een geweldig idee kwamen, en ze bouwden het gewoon (er is geen betere manier om te beginnen!). Zodra het product succesvoller werd, en de markt er klaar voor was, werden er functies toegevoegd. En die functies werden toegevoegd totdat Cloud Adventures erachter kwam dat het behoorlijk wat overzicht vergt om deze ene oplossing die alles biedt te onderhouden. Om nog maar niet te spreken van het feit dat het updaten van een stukje code betekent dat de hele applicatie opnieuw moet worden opgebouwd en getest.
   
   
2. Dan hebben we nog de beperkingen van Virtual Machines. Er is geen native technologie om de opslag weg te onttrekken van de Virtuele Machine; je bent gebonden aan het gebruik van de lokale schijf of aangesloten opslag.   

Dus, los van het feit dat het een natuurlijk proces is waarbij bijna iedereen op een gegeven moment eindigt met een monolith, gaven we onze ontwikkelaars ook niet de mogelijkheid om het anders te doen! Je zou kunnen stellen dat je verschillende websites/services kunt hosten op een lokale webserver. En dat is waar. Maar is een ontwikkelaar zich er in het algemeen van bewust dat je dit kunt doen? Willen we een ontwikkelaar wel belasten met die infrastructuurkennis? Onwaarschijnlijk.  

 

Wat is het alternatief voor een monolith aanpak? 

Ten eerste kun je nog steeds een monoliet bouwen op Microsoft Azure. Je kunt gemakkelijk alles in een enkele App Service stoppen en het schalen tot je tegen de grenzen van die technologie aanloopt. Dat is het moment waarop innovatie in de infrastructuur niet langer kan worden gebruikt om de oplossing en de prestaties ervan te verbeteren. Als je op dat punt komt, is het zeker tijd om naar de code zelf te kijken.  

We moeten begrijpen dat technologie op zichzelf dit niet zal oplossen. De mentaliteit van ontwikkelaars moet veranderen; als je gewend bent om monolithische oplossingen te bouwen, kan dit gewoon een gevolg zijn van de wet van Conway: 

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” 
— Melvin E. Conway 

Dat wil niet zeggen dat het makkelijk op te lossen is, maar ik raad aan om hierover te lezen zodat je kan gebruiken wat er waarom gebeurt. 

 

Azure optimaal benutten

Goed, terug naar de technologie. Laten we zeggen dat Cloud Adventures hun oplossing verplaatst heeft om op App Services in Microsoft Azure te draaien. Alle software wordt in die ene App Service gestopt. Dezelfde oplossing als in een virtuele machine, alleen een andere technologie om het op te hosten. Dat betekent dat we nog steeds hetzelfde monolithische scenario hebben. Ze ervaren dezelfde uitdaging als voorheen: het is moeilijk te onderhouden, moeilijk om overzicht te houden, en het aanraken van een stukje code kan gevolgen hebben voor de rest. Ze maken niet écht gebruik van Microsoft Azure. 

Hoe lossen we dat op? Nou ... Microsoft Azure biedt een heleboel verschillende technologieën, ieder met zijn eigen use case. We kunnen storage accounts gebruiken voor het opslaan van bestanden en gebruik maken van de kracht van een Content Delivery Network (CDN), we kunnen een Azure Redis Cache gebruiken om de gebruikerssessie caching uit te voeren. En we kunnen Azure Functions en API Management gebruiken om de API die Cloud Adventures heeft gebouwd om order statussen te verstrekken, uit te voeren en te tonen. Dat zijn een heleboel technologieën in één zin, en je hoeft ze niet allemaal te onthouden, omdat je misschien verschillende nodig hebt voor jouw gebruikssituatie.  

Het laat daarentegen wel zien dat er technologieën binnen Azure zijn die je kunt gebruiken om die logica weg te filteren van je primaire oplossing (de Cloud Adventures webshop in dit geval).  

Als oplettende lezer zou je kunnen denken: "Dit klinkt bekend," en je hebt gelijk. We hebben onlangs een artikel gepubliceerd over App Modernization: App Modernization, buzzword, of echt verhaal? dat dit proces en de mindset beschrijft.

Laten we het eens hebben over hoe je dit voor elkaar krijgt. Moet je van 0 naar 60 binnen een paar seconden? Absoluut niet. Dit zijn projecten die tijd kosten en een gefaseerde aanpak vereisen. Het gaat allemaal om afgebakende stukjes.  

Voor Cloud Adventures zou dat betekenen dat we gaan kijken naar het gebruik van Storage Accounts voor de opslag van het maatwerk per klant dat nu lokaal op de App Service wordt gehost. We gaan de opslag ophalen bij App Service. 

 

Interactie met Azure Services

Dus, we gaan met verschillende technologieën in Azure werken. 

Storage Accounts

Er zijn meerdere manieren om dit te doen. Je belangrijkste twee opties zijn:  

1. Interactie met storage accounts met behulp van de Azure REST API's
2. Met behulp van de Blob storage SDK's zoals geleverd en onderhouden door Microsoft

Alles in Microsoft Azure kan worden gedaan met behulp van de Azure Resource Managers REST API's. Dit vereist echter dat je meerdere API calls doet naar de endpoints voor opslag accounts, wat resulteert in heel wat code en het omgaan met HTTP Clients, JSON responses, en complexe authenticatie in code. Niet iets waar je elke dag mee bezig wilt zijn. 

SDK in Azure 

Dan hebben we de SDKs. Er zijn er een heleboel voor verschillende talen en verschillende Azure technologieën. SDK's kunnen hier gevonden worden: Download Azure SDKs and Tools | Microsoft Azure. De meeste worden onderhouden als open-source projecten; als je iets mist, stel dan een verbetering voor! Wat maakt de SDK's zo krachtig? Omdat bijna alles wat je nodig hebt er in zit. Als we kijken naar het gebruik van Blob opslag, met gebruik van de SDK, kost het maar liefst 7 regels .Net code om een bestand naar blob opslag te schrijven. Als we dat zouden doen met behulp van de REST API's direct, zou het veel meer dan zeven regels code kosten.  

Betekent dit dat REST API's uit den boze zijn? Zeker niet. Soms moet je iets doen dat niet wordt ondersteund door de SDK; de REST API's zijn je alternatief. 

 

Wat heeft dit Cloud Adventures gebracht? 

Door de Azure Storage SDK te integreren, heeft Cloud Adventures de opslag van klant-specifieke configuratie losgekoppeld van blob storage. Dit resulteerde in meerdere voordelen: 

• Opslag neemt geen ruimte en resources in op de App Service 
• De SDK's vereisen minder code om het werk gedaan te krijgen, het is efficiënter 
• Cloud Adventures kunnen nu gebruik maken van extra Storage Account-functies, zoals het inschakelen van een Content Delivery Network om de caching van gegevens uit te voeren 
• Maatwerk voor de klant kan nu worden gescheiden en beveiligd in verschillende blob containers 

En dan hebben we het nog niet eens gehad over de financiële impact. Met alleen het weglaten van storage zou dat in de meeste gevallen minimaal zijn, maar als je deze mindset omarmt en doorzet door meer delen van je oplossing te moderniseren en verschillende technologieën te integreren voor verschillende taken, kun je efficiënt zijn in de manier waarop je omgeving wordt geprijsd. We hebben die uitgebreide App Service niet meer nodig.

 

Wrap-up: Azure draait om bit-sized pieces

We hebben gezien dat het zeker interessant is om Microsoft Azure te gebruiken, maar het gaat niet van de ene op de andere dag. Het gaat allemaal om de hapklare brokken, maar het zal gemakkelijker komen dan verwacht als je er eenmaal aan begint. In het tweede deel van dit artikel gaan we aan de slag met de Cloud Adventures use case en geven we visuals en code voorbeelden over hoe een oplossing van 0 naar 60 zou gaan!  

 

Application Insights: deep dive

Wil je meer inzichten in de applicaties van Azure? Meld je dan aan voor onze workshop: Application Insights ontdek hoe jij beter in controle kan zijn. 

Dit is het eerste artikel in de reeks 'Application Development,' het tweede artikel volgt snel.