Laten we beginnen bij het begin: wat zijn Azure Container Apps? Een nieuwe resource, nét een jaar oud, binnen Azure. Vóór die tijd was het lange tijd slechts een preview. En verder: wat doen Azure Container Apps? Wat is het concept? Wat kan je er als ontwikkelaar mee? Kubernetes without the hassle, zeggen we ook wel. Natuurlijk met een knipoog, maar in dit blog leggen we uit hoe Container Apps – als abstractie bovenop Kubernetes – het leven van Developers een stukje makkelijker maakt.

Door Stefan Vasilev

Azure Container Apps: Why, how, what?

Nee. We zeggen niet dat Azure Container Apps “beter” zijn dan Kubernetes. Sterker nog, je kunt het niet met elkaar vergelijken. Azure Container Apps is namelijk een abstractie bovenop Kubernetes en is dus allesbehalve een vervanging ervan. Het doel van Container Apps is om het gebruiksgemak van Kubernetes te verbeteren voor ontwikkelaars. Er zijn heel veel organisaties die microservices op Kubernetes hosten. Het gebruik van Kubernetes kan vrij complex zijn voor ontwikkelaars die er nog weinig ervaring mee hebben. Daar komt Container Apps uit voort: een tussenlaag die de abstractie voor je weghaalt zodat je je meer kan focussen op het ontwikkelen van applicaties.

Concepten van Azure Container Apps

Azure Container Apps Environment

Om Azure Container Apps verder uit te werken, duiken we in de verschillende “lagen” ervan. Het eerste concept is namelijk de Azure Container Apps Environment. Dat is niet anders dan een soort privénetwerk om al je Container Apps in te laten draaien. Als een soort schil om al je Container Apps heen. Hier stel je ook de algemene configuratie in voor al je Azure Container Apps. Je beheert hier bijvoorbeeld de gedeelde filestorage tussen alle applicaties. De configuratie voor Dapr die de Apps kunnen gebruiken (bijvoorbeeld Azure Keyvault en Azure Service Bus).

Keda

Doordat de Azure Container Apps een abstractie-laag bovenop een Kubernetes platform vormt, heeft het ook een aantal limitaties. Voor scaling gebruikt het Keda (Kubernetes Event-Driven Autoscaling). Een open-source voor – het zal je verbazen – autoscaling. Je kan op allerlei manieren je applicaties autoscalen, maar wat is het precies? Draaiende apps krijgen bezoekers en als er veel bezoekers tegelijkertijd gebruikmaken van de app, wordt deze trager om aan alle verzoeken te voldoen. Dan heb je twee keuzes. Je kunt gaan upscalen: je memory of de CPU (Central Processing Unit) omhooggooien. Of je draait meerdere instanties naast elkaar en gaat outscalen. Met behulp van Keda kan je dit bepalen, aan de hand van allerlei verschillende events die je zelf gemakkelijk kan configureren. Het biedt ook standaard ondersteuning aan voor het gebruik van Dapr die als side cart naast je microservice draait.

Dapr

Dapr is een open-source runtime die het bouwen van microservices vereenvoudigt door het bieden van taalonafhankelijke service-to-service communicatie, state management, event-driven architecturen, secrets management en observability. Waardoor het gemakkelijker wordt om schaalbare en krachtige microservices te ontwikkelen en implementeren. Voor het verkeer binnen je Azure Container Apps gebruikt het standaard Envoy. Je kan bijvoorbeeld geen gebruikmaken van nginx, al zou je dat liever doen.

Envoy

Envoy is een open-source edge- en service proxy die geavanceerde netwerkfunctionaliteiten biedt, zoals load balancing en service discovery voor moderne microservices-architecturen. Het fungeert als een betrouwbare laag tussen clients en services en kan worden ingezet in verschillende omgevingen. Zoals Kubernetes en Cloudplatforms. Om zó het netwerkverkeer tussen services te optimaliseren.

Azure Log Analytics

Naast dat het standaard Keda en Dapr gebruikt, moet je ook Azure Log Analytics koppelen aan je Azure Container Environment. Azure Log Analytics is een Cloudservice van Microsoft Azure die loggegevens van verschillende bronnen verzamelt, analyseert en visualiseert om inzichten te bieden voor het bewaken, beheren en optimaliseren van je systemen.

Azure Container Apps

Als we een stapje dieper gaan, dan komen we uit bij de Azure Container Apps zelf. Niets anders dan microservices: losstaande services. Als voorbeeld gebruiken we de situatie waarin we één webapp en drie losstaande API’s hebben draaien. Bijvoorbeeld een applicatie die dient als een simpele ticket app waar je als consument tickets op kunt kopen wanneer deze beschikbaar worden gesteld door de event service.

Image

Elke Container App is gekoppeld aan een Docker Image. Dit is de code van de applicatie die je draait. Er zijn twee belangrijke punten voor het draaien van Container Apps: je hebt dus een Docker Image nodig én het moet op Linux draaien. In dit geval staat de Image in Azure Container Registry.

Allemaal leuk en aardig, maar hoe houd je die webapp draaiende?

De basis is duidelijk: het draait uiteindelijk allemaal om de Azure Container Apps binnen je Azure Container App Environment. Stel, je stapt in een Azure Container App, dan zie je heel veel verschillende configuraties. Een paar belangrijke configuraties om je microservice draaiende te krijgen en houden, zijn:

• Ingress. Een Environment heeft zijn eigen private netwerk, maar daar kan je niet zomaar bij. Om je draaiende apps te kunnen benaderen via publiekelijke netwerk zou je Ingress moeten instellen op je Azure Container App. Via Ingress kan je de traffic bepalen naar je app. Zijn dat bijvoorbeeld alleen apps binnen je Azure Container Environment of erbuiten, en wie van het publieke netwerk mag jouw container benaderen? Misschien alleen specifieke IP’s of alle traffic.
• Revisie management. Elke Image is gekoppeld aan een versie binnen je Container App. Een versie bestaat uit je Image versie, omgevingsvariabelen, Ingress configuratie, revisiemode, etc. Wijziging aan één van deze configuraties zorgt voor een nieuwe revisie. Hier komen we nog op terug!
• Scaling. Je wil dat je microservice robuuster wordt en zich kan aanpassen aan de hoeveelheid vraag die hij krijgt. Je kan ervoor kiezen dat te allen tijde een instantie beschikbaar is als er een verzoek wordt gedaan naar je service. Maar je kan er ook voor kiezen om alle instanties af te sluiten als er een tijd lang geen vraag naar was. Dit kan je veel kosten besparen, maar heeft als nadeel dat de eerste keer dat er weer een verzoek gemaakt wordt, je service een zogeheten ‘koude start’ nodig heeft om op te starten. Als snelheid belangrijk is, wil je dat niet.

Elke Container App kan één of meerdere revisies hebben. Je kan ervoor kiezen dat de laatste revisie altijd de leidende versie is of je kan meerdere revisies gebruiken voor verschillende doeleinden:

• A/B Testing. Je kan bijvoorbeeld twee revisies hebben en ervoor kiezen dat 50% van je requests naar versie A gaat, en 50% naar versie B. Hiermee kan je bijvoorbeeld nieuwe features testen. Of bijvoorbeeld een nieuw design van je website testen en kijken hoe daarop wordt gereageerd door je bezoekers aan de hand van bepaalde metrieken.
• Blue/Green deployment. Revisies kan je ook gebruiken om een zogeheten Blue/Green deployment uit te voeren, waarbij je naast je draaiende versie een nieuwe opspint en het verkeer er in één keer ernaartoe verwijst om je service up te graden. Dit kan je ook in fasen doen. Bijvoorbeeld: elke 10 minuten gaat er 10% van het verkeer naar de nieuwe versie en kan je daarmee snel terug naar de oude versie als er iets misgaat in de nieuwe versie.

Voor- en nadelen van Azure Container Apps

Voor het gemak sommen we nog even de voor- en nadelen van Azure Container Apps, ten opzichte van Kubernetes Service, voor je op:

Voordelen

• Makkelijk te beheren
• Sneller op te zetten
• Kán goedkoper zijn (zoals bij het gebruik van 0-scaling)
• Je hebt weinig kennis nodig van Kubernetes
• Biedt geïntegreerde ondersteuning voor de open-source tool Dapr

Nadelen

• Is gebonden aan Microsoft en gebruikt daardoor standaard Keda, Dapr en Envoy
• Log Analytics is verplicht om op te zetten
• Je hebt geen volledige controle, zoals geen toegang tot je Kubernetes API welke door Microsoft wordt beheerd
• Is alleen op Linux – en dus niet op Windows – Images te gebruiken

Azure Container Apps vs. Azure Kubernetes Service

De fervent ontwikkelaar of kenner van Kubernetes zal nu wel een tijdje denken: je hebt het over Azure Container Apps, maar hoe zit het met Azure Kubernetes Service? En inderdaad, daar hebben we het nog niet over gehad. Azure Container Apps is een abstractie boven op Kubernetes, waardoor er dus veel voor je wordt gedaan. Maar als je toch scenario’s hebt waar je specifiek wil configureren, meer in controle wil zijn én toegang wil tot de Kubernetes API, is Azure Container Apps niet de oplossing. Als je liever niét bezig wil zijn met het beheren van het Kubernetes platform, of de mensen er niet voor hebt, dan is Azure Container Apps wél een interessante keuze aangezien je makkelijker je platform opzet. En daardoor meer kan focussen op het ontwikkelen van je services. Vervangt de een het ander? Nee, dat zeker niet.

Over de auteur: 

Stefan is een onmisbare Cloud Consultant binnen ons team met zijn brede kennis in eigenlijk, tsja, praktisch alles wat met Azure te maken heeft. Zo wist hij zelfs de niet-developers binnen Innvolve enthousiast te krijgen over Container Apps tijdens de Community Talks. Meer weten over Kubernetes of Container Apps, gewoon even sparren of graag een keer een Community Talk bijwonen? Mag altijd!