Containers à la carte in Azure
De afgelopen jaren heeft de adaptatie en de volwassenheid van containerization, met Docker als bekendste voorbeeld, binnen onze discipline een flinke vlucht genomen. Daarbij heeft de tweede de eerste in de hand gewerkt.
Containerization, het toepassen van containers voor het omsluiten van een applicatie heeft als voordeel dat alle afhankelijke componenten die benodigd zijn voor de applicatie in het container image aanwezig zijn. Het gaat hierbij om de applicatie maar ook bijvoorbeeld de bibliotheken, applicatie instellingen en de applicatie-runtime. De applicatie wordt op een manier verpakt zodat er geen afhankelijkheden zijn met de omgeving waar de container uitgevoerd zal worden. Deze ontkoppeling en de standaardisering van het container image formaat zorgt ervoor dat het container image toe te passen is onafhankelijk van de eigenschappen van de onderliggende infrastructuur.
Alle gerespecteerde Public Cloud providers, zoals AWS, Microsoft Azure en Google Cloud, leveren momenteel een productie-waardige ‘managed container service’ oplossing. Een eigenschap van deze PaaS diensten is dat ze het beheer van de achterliggende techniek rond compute, geheugen en opslag verbergen voor de gebruiker van de dienst.
In deze blog ga ik in op drie verschillende mogelijkheden van het toepassen van containers binnen het Microsoft Azure Public Cloud platform.
Managed Kubernetes (aka Azure AKS), CI/CD en IaC
Momenteel dragen we met een team van Profit4Cloud bij een klant bij aan een project waarbij we een processing-pipeline voor het verwerken (transformeren) van eigenschappen van producten migreren naar Microsoft Azure.
Deze pipeline verwerkt momenteel dagelijks miljoenen producten.
Een van de eisen aan deze Cloud architectuur is de mogelijkheid om de verwerkingscapaciteit van deze pipelines te kunnen vergroten naar gelang de behoefte (schaalbaarheid).
De processing-pipeline bestaat uit een aantal in serie gekoppelde verwerkingseenheden waarbij elke eenheid functioneel een specifieke verantwoordelijkheid heeft.
Om de huidige doorvoersnelheid te kunnen realiseren en voor de toekomst de gewenste schaalbaarheid te realiseren zonder daarbij een architectuur wijziging of herimplementatie door te moeten voeren hebben we gekozen voor het toepassen van het Azure managed Kubernetes (container orchestration platform) AKS. De verwerkingseenheden zijn geïmplementeerd als .NET core applicaties en worden uitgevoerd als Docker container images. Voor het bouwen en uitrollen van de verwerkingseenheden en onderliggende infrastructuur (definities uitgedrukt in ARM templates (IaC)) maken we gebruik van CI/CD build en release pipelines binnen Azure DevOps (eerder bekend als VSTS).
De verwerkingseenheden wisselen via de Azure ServiceBus berichten met elkaar uit. Het aantal nog te verwerken berichten bepaald hoeveel verwerkingseenheden simultaan actief moeten zijn (up- en downscaling op basis van ServiceBus topic subscription depth). Hiermee zorgen we ervoor dat er continu voldoende verwerkingscapaciteit aanwezig is.
Naast een productieomgeving heeft de klant beschikking over een acceptatieomgeving. Alle applicatie en infrastructuur wijzigingen gaan (middels CI/CD) naar de acceptatieomgeving waarna ze formeel (handmatig) goedgekeurd dienen te worden voordat ze automatisch doorgezet worden naar productie. Daarnaast kan men op basis van behoefte parallel meerdere OT-omgevingen uitrollen waarbij de complete infrastructuur en applicatie deployment van een omgeving automatisch voorzien wordt.
Het hierboven beschreven project en de bijbehorende architectuur keuzes en implementatie is qua effort en complexiteit volledig te verantwoorden op basis van de door de klant gestelde eisen en wensen. Dit wil echter niet zeggen dat men bij de keuze voor containerization binnen Azure altijd direct gedwongen wordt een AKS-cluster met bijbehorende infrastructuur uit te rollen.
Azure FunctionApp service
Een Azure FunctionApp (FaaS) maakt het mogelijk om functionaliteiten ‘serverless’ uit te voeren binnen een geïsoleerde context. Een FunctionApp kan geconfigureerd worden zodat de functionaliteit actief wordt op basis van triggers. Een trigger kan b.v. een HTTP-request zijn (vanaf het internet), een bericht op de ServiceBus of upload van een bestand in een Azure StorageAccount.
Naast de mogelijkheid om een applicatie op basis van C# (C#-script), JavaScript (node) of F# uit te voeren binnen een FunctionApp bestaat sinds versie 2 van de Azure FunctionApp de mogelijk om een Docker image te gebruiken als functionele container.
Het voordeel hiervan is dat het Docker image dat gebruikt kan worden om binnen AKS uitgevoerd te worden in een POD nu ook gebruikt kan worden om een FunctionApp van functionaliteit te voorzien en andersom. Men kan dus beginnen met het hosten van serverless functionaliteiten binnen Azure door gebruik te maken van een Docker image zonder daar meteen een AKS-cluster voor te voorzien. Mocht het door groei of om andere redenen verantwoord zijn om een AKS-cluster in te regelen dan kunnen de functionaliteiten d.m.v de Docker images direct op het AKS-cluster uitgevoerd gaan worden. Door de porteerbaarheid van een Docker image is het tevens mogelijk om het Docker image in AWS of een on-premise container orchestration omgeving te draaien mocht daarvoor gekozen worden.
Daarnaast is het overigens ook mogelijk om een Azure FunctionApp in een docker image te executeren.
Azure Container Instance service
Een andere light-weight optie om een container-image te hosten is door gebruik te maken van de Azure Container Instance PaaS dienst. Tevens een serverless dienst waarbij met minimale effort en afhankelijkheden een Docker image vanuit de prive of publieke image registry in de cloud tot leven gewekt kan worden.
Er bestaat de mogelijkheid om direct een publiek IP-adres aan de instantie te koppelen zodat de functionaliteit direct benaderbaar is. Deze dienst heeft niet de schaalbaarheids-kwaliteiten van AKS, maar heeft wel een zeer transparant en voorspelbaar afrekenmodel.
Wat, wanneer, waarom
Bovenstaande 3 opties om container-based functionaliteiten te hosten hebben allen hun eigen specifieke kwaliteiten, voordelen en nadelen. Welke keuze wanneer het beste aansluit bij de behoefte is natuurlijk probleemdomein afhankelijk. Door echter consequent gebruik te maken van containers bestaat de mogelijkheid om met minimale effort te switchen tussen verschillende container platforms en zelfs cloud omgevingen.
Mocht u naar aanleiding van bovenstaande behoefte hebben aan meer informatie over dit onderwerp, heeft u behoefte aan begeleiding bij de keuze van ‘de juiste cloud’ of zoekt u informatie m.b.t cloud development in het algemeen, neem dan gerust contact met ons op.