Nyheder
25 juli 2018

Kunder vil ikke betale for meget: Sådan gennemskuer konsulent container-forbrug i skyen

Et af de forhold, der gør kunder glade for drift i skyen, er det helt detaljerede billede af resurseforbruget, som teknologien stiller til rådighed. Muligheden for kun at betale for den load, man udsætter skyen for.

Et af de forhold, der gør kunder glade for drift i skyen, er det helt detaljerede billede af resurseforbruget, som teknologien stiller til rådighed. Muligheden for kun at betale for den load, man udsætter skyen for.

Det betyder blandt andet, at man kan anvende en meget finkornet afregning for de enkelte tjenesters forbrug, og det kan være vigtigt i store firmaer, hvor man afregner internt afdelinger imellem.

På den måde slipper afdeling A for at betale for afdeling B's tjeneste, forklarer cloud-konsulent Rene Løhde:

»Så hvis markedsføringsafdelingen køber en database, så er det den, der betaler for databasen,« lyder et eksempel fra Rene Løhde.

Men det er ikke sådan lige at afregne så detaljeret, når driften går fra virtuelle instanser til containere, hvor en række hosts driver et større antal containere.

»Hvis man for eksempel har fire hosts, og man spreder sine 25 docker-containere henover dem, så er dine containere opdelt i for eksempel frontend og backend til en eller to applikationer, men du får ingen information om applikationerne ud fra din cloud-leverandør. Du kan bare se, at du bruger fire hosts, men ikke hvordan belastningen fordeler sig på 25 projekter. Så hvad gør man, når man skal afregne?«

Docker og Kubernetes kan ikke levere forbruget

Når driften går fra virtuelle instanser til containere, skal der nye boller på suppen for at afregne resurseforbrug. Den klarer cloud-konsulent René Løhde med metatags. Illustration: René Løhde

Det er ikke et fiktivt problem for Rene Løhde, for det er det, kunderne vil have.

»Jeg har en helt konkret problemstilling med en kunde, som vil have det, som de er vant til i cloud, altså at de får præcis afregning, så de kan sende regningen tilbage til den forretningsenhed, der bruger en given tjeneste.«

Systemer som containersoftwaren Docker og udrulningssoftware som Kubernetes, der dog ikke benyttes i forbindelse med Rene Løhdes kunde, kan ikke af sig selv afregne resurseforbruget.

»Men når nu man er i Devops-verdenen, så kan man tillægge metadata. Så vi 'metatagger' containerne, så vi kan se, hvilke projekter, der tilhører hver enkel container.«

Metadata redder dagen

Tags er bare metadata. Kunden har i dette tilfælde foreslået tre tags: Det første tag udpeger projektet, der skal betales for. Det andet tag fortæller hvilket slags miljø, der er tale om: udvikling, test eller produktion. Det tredje tag bestemmer, hvor containeren er udrullet fra, som for eksempel fra integrationsserveren Jenkins, og så videre.

»Du skal have to ting, som du sammenholder: Du skal have tags ud af systemet, og det gør vi via et REST-api. Så trækker vi den øjeblikkelige situation, der fortæller, hvor mange containere der er lige nu, og hvilket projekt, hver enkelt container tilhører. «

Det sammenholdes med et 'dump' - et øjeblikkeligt snapshot af resurseforbruget fra Amazons virtuelle instanser. Én måneds forbrug er omkring en million rækker og tyve kolonner i kommasepareret format, i Rene Løhdes konkrete tilfælde.

Man kan hive det regneark ud og forholde sig til hver resurse, for hver enkel Amazon-resurse har et id. Dette id kan så udpege en bestemt Docker-host.

»Så henter vi metadata på den fra vores eget proprietære api og siger: Denne Docker-host tilhører denne cluster og der er fire host og 25 noder. På de 25 er der tre projekter - dette projekt skal betale 60 procent af omkostningerne, og de to sidste skal betale 20 procent hver.«

Rene Løhde har ikke været i stand til at finde et stykke middleware, der lige kan opfylde den opgave.

Er der så et open source-projekt på vej?

»Det må jeg snakke med kunden om. Det tror jeg faktisk godt, de kunne tænke sig,« slutter Rene Løhde.

Læs mere >>

FacebookTwitterLinkedinMailPrint

Også interessant

Arrangør
  
Partner