Tien te overwegen cloud resource tags

Het toekennen van resourcetags bij gebruik van public cloud services, is een absolute best practice. Maar waarom is dit eigenlijk belangrijk en wat zijn nu goede en veel gebruikte tags? In dit artikel tien tag-suggesties om zeker te overwegen zijn bij uw public cloud platform -implementatie.

Public cloud-platformen als Amazon Web Services (AWS) en Microsoft Azure bieden de mogelijkheid om tags toe te voegen aan resources zoals compute instances (servers), managed databases of loadbalancers. Een tag is eigenlijk een stukje metadata bestaande uit één of meerdere key’s en  ‘value pairs’ die aan een resource worden toegekend om een resource op basis van die metadata later makkelijker te kunnen identificeren. Bijvoorbeeld key: ‘application owner met value: ‘Jeroen Jacobs’. Op public platformen zijn tags erg belangrijk om het overzicht te houden en de kosten te beheersen. 

Ontstaan van een taggingsbehoefte

Vrijwel elke organisatie herkent wel het probleem dat binnen hun virtualisatieomgeving een aantal virtual machines draaien waarvan eigenlijk niemand precies weet wat die bepaalde virtuele machines doen, van wie ze zijn en of dat ze überhaupt nog gebruikt worden. Kortom het life cycle management is een probleem. Tijdens migratie- en decommisioning-projecten is dan vaak uitzetten en toepassen van het piepsysteem de enige remedie om er vanaf te komen. Toch zie je wel dat it-afdelingen in de loop der tijd oplossingen hebben bedacht zoals gebruik gaan maken van servernaam naamgevingsconventies en het invullen van bijvoorbeeld het annotation veld in VMware. Eigenlijk kunnen we dit een premature vorm van tagging noemen zoals we dat vandaag de dag op public cloud-platformen kennen.

Het niet goed beheersen van het resource life cycle probleem is op public platformen nog veel pijnlijker dan op een eigen omgeving. Op public platformen kost elke resource immers direct geld. Mede hierdoor kennen resources op public clouds meestal ook nog een veel kortere levenscyclus dan traditioneel.

Tagging strategie op public cloud

Amazon Web Services biedt momenteel de mogelijkheid om tot vijftig tags toe te voegen aan een resource, een key van 128 en een value van 256 tekens. Azure biedt de mogelijkheid om vijftien tags te gebruiken met een tag name van 512 en een value van 256 tekens. Voldoende om metadata in kwijt te kunnen. En heb je aan vijftien tags niet genoeg dat wordt vaak met een scheidingsteken meerdere waardes in één veld gecombineerd. Bijvoorbeeld: ‘Waarde1 /// Waarde2 /// Waarde3’.

Vanuit praktijkervaring zien we eigenlijk drie toepassingsgebieden waaronder we tags eigenlijk kunnen indelen. Tags voor business en cost allocation, tags voor automation en tags voor security/compliancy. Hieronder volgen onze tien tag suggesties die zeker het overwegen waard zijn bij de gemiddelde public cloud implementatie.

Business tags

Business tags worden primair gebruikt voor het identificeren van verantwoordelijke/eigenaar en voor doorbelasting of inzichtelijkheid in kosten.

#1 Application: De application tag geeft de naam van de applicatie zoals bijvoorbeeld: ” SAPBW-7.4′ of ‘Intranet. Deze tag is handig om op te sorteren in kostenrapportages om de applicatie footprint te identificeren of om de applicatie samenhang/architectuur te overzien.

#2 ApplicationOwner: De application owner kan ook een afdeling of combinatie zijn en dient om te identificeren wie aanspreekbaar is voor het verbruik en context van de resource. Een voorbeeld van een gecombineerde key value hierbij kan zijn key: ‘department/owner/email’, value: ‘cloudcompetencecenter /// JeroenJacobs /// jeroen@oblcc.com‘.

#3 CostCenter: (of project): Regelmatig is de het migreren naar cloud services ook een moment waarop organisaties interne doorbelasting nog eens kritisch bekijken. Door de verbruiker van de resources direct te belasten voor de kosten wordt er vaak kosten-effectiever met resources omgegaan.

#4 ExpirationDate: Expiration date is een erg krachtige tag. Bij het aanmaken van een resource wordt een datum opgegeven tot wanneer een resource beschikbaar moet blijven. Na het verstrijken van de datum kan dan contact worden opgenomen met de applicatie-eigenaar om te bespreken of de resource nog nodig is. Erg volwassen cloud it-organisaties gaan wellicht direct over tot het automatisch termineren van de resource na het passeren van de datum.

Automation

#5 EnvironmentTier: de ‘environment’ geeft weer of het een development-, test-, acceptatie- of productie-omgeving betreft. De ’tier’ of het web, compute of data/database betreft. Als voorbeeld: “DEV///WEB”. Dit type tag geeft niet alleen inzicht in de rol van de resource, maar is ook erg handig voor automation en compliancy checks. DEV//DB mag bijvoorbeeld alleen aanwezig zijn in een niet publiek subnet van het ‘development account’. Of de usecase om developers via een iam-policy automatisch toegang te geven tot resources met de DEV-value. Of wellicht om kosten te besparen door alle DEV tagged resources in de nacht uren automatisch uit te zetten en bijvoorbeeld niet te backupen.

#6 CIArating: confidentiality, Iitegrity, availability ratings worden in veel corporates toegepast. Aan de hand van een rating zoals bijvoorbeeld ‘333’ kunnen we audit checks doen, access toekennen of bijvoorbeeld encryptie of patch levels forceren.

#7 SupportWindow: het support window op een resources biedt bijvoorbeeld een cloud competence center direct inzicht in de mate van support die ze verlenen in geval van issues. Vanuit deze waarde kan bijvoorbeeld in geval van alert uit monitoring wel of niet een stand-by engineer getriggerd worden. ‘Standard5x8’ of ‘Premium7x24’.

#8 BackUp: In de praktijk variaties gezien om met de tag backup met value Y/N het backupproces middels Lambda-scripts te automatiseren. Maar ook om een backupwindow aan te geven. Variaties hierop die het beheer makkelijker en beter automatiseerbaar maken zijn bijvoorbeeld patch en of maintenancewindow.

#9 StatefullStateless: Horizontaal of vertaal schalen van een virtual machine kan vanuit beheer-oogpunt prettig zijn om te weten. Het bepaalt namelijk hoe je naar performance issues moet kijken en hoe je met het termineren van instances omgaat.

#10 Remark: is best te vergelijken met het vertrouwde annotatie veld in VMware. Soms is een korte ongestructureerde notitie of krabbel alsnog gewoon heel handig.

Succesfactoren

Tagging lijkt een fantastisch middel voor vele uitdagingen, maar vereist wel consistente toepassing voor succes. Wordt dit niet gedaan dan zitten we zo weer in de oude vertrouwde situatie. Hieronder enkele tips voor succesvol gebruik.

Sla niet door in het aantal tags: Ondanks dat sommige liever kiezen voor te veel dan te weinig tags, geloven wij in fit for purpose. Elke tag moet een duidelijk zijn en waarde leveren, anders heeft het geen langdurig bestaan en kost het alleen maar tijd.

Consistente naamgeving: Zowel de key als de value moeten consistent worden ingevuld. Development moet bijvoorbeeld altijd de value ‘DEV’ hebben en niet de ene keer ‘Development’ dan ‘development’ en dan weer ‘Dev’ heten.

Tags afdwingen: Amazon Web Services biedt bijvoorbeeld tools om gebruik van tags af te dwingen. Denk aan bijvoorbeeld config rules die identificeren als een resource niet getagged is. Of een AWS Lambda-script wat onjuist getagde resources termineert. Een andere optie is om in de CI/CD pipeline, uitgaande van uitsluitend provisioning via Infra as code, bepaalde checks in te bakken alvorens geprovisioned wordt.

Tot slot

Ga je van start met AWS or Azure, denk dan vooraf goed na over je taggingstrategie. Schroom niet om te starten met een beperkte set en later uit te breiden. Eerst experimenteren wat je met tagging kan en hoe je dat in de organisatie en het beheer gaat inzetten, is ook een goed vertrekpunt. Verlies in ieder geval niet uit het oog dat resources zonder tags voorkomen zouden moeten worden, alleen al om niet weer in de oude valkuilen van onbekende resources te belanden.