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

Kunder vil have præcis, forbrugsbestemt afregning i skyen - også når loaden går fra instanser til containere. Sådan løser cloud-konsulenten problemet.

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (6)
Tobias Tobiasen

Hej,
Jeg rådgiver mine kunder til at have et docker cluster til hvert projekt. På den måde er det let at udregne hvad prisen er.
Det giver også mange andre fordele. En løbsk process i et projekt kan ikke påvirke andre projekter. Man kan opgradere når det passer ind i projektets plan og skal ikke opgradere "det store cluster" i big bang.

Faktisk er det bedst hvis hvert projekt har hele sin egen infrastruktur med load balancere, netværk, docker cluster og databaser. Så kan man måle den præcise pris inklusiv alt infrastruktur og har vandtætte skotter mellem forskellige projekter så en perifer service ikke trækker vigtige services ned ved et uheld.

Alt dette er blevet langt lettere med AWS Fargate hvor docker er blevet serverless.

Tobias Tobiasen

I de docker systemer jeg har erfaring med er det ikke let at styre præcist hvor de forskellige dockere kører. Nogle gange ender en docker helt alene på den host den kører på. Med den omtalte regnemodel vil den docker så ikke blive urimmelig dyrt for det projekt?
Så hvis en docker kører sammen med 5 andre en uge og alene uge efter vil det så blive 5 gange dyrere for projektet?

Sune Marcher

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?«

Hvor kunne det være dejligt hvis man, i stedet for en teknisk løsning, lige tog et par skridt tilbage og overvejede om intern afregning, siloer, og kassetænkning er det rigtige – eller om man skulle prøve at restrukturere på en måde, der var til virksomhedens samlede bedste.

Troels Tolstrup

Åh jeg bliver så træt når man læser om hvor mange kræfter der bliver brugt på at løse mærkelige problemer.

Så man er sikkert gået fra at have nogle monster servere der kørte alt muligt mærkeligt software der er irriterende at drifte, til at have nogle monster servere der kører alle mulige mærkelige containere der er irriterende at drifte.

Man kunne også have haft en bunke separate setups der hver havde et projekt, som nu var nemt at drifte, skalere, klone, teste disaster recovery på, etc. Det ville så også virke med tagging out of the box, og vil gøre det meget nemmere at isolere projekterne fra hinanden, både med hensyn til adgang og performance.

Hans Nielsen

Som jeg husker det,
Så blev nogle af de først kommercielle regnemaskiner brugt til behandling og beregning af Telefon tariffer i USA. Der var flere 100 om ikke 1000 forskellige tariffer og afregningsmetoder, og det hele var meget lidt gennemsigtigt både for kunder, med også for AT & T.
- Lidt lige som Billetpriser og typer på offentlig trafik i Danmark nu om dage.

At digitalisere det gjorde det ikke nemmere, det blev bare muligheden at øge komplexitet Som kilde skat i Danmark er vokset til, ja noget som der skal store og mange computer til at holde styr på.

Så træder man et skridt tilbage, og så på hele. Og fandt ud af at det var billigere og nemmere på alle måder også for kunden, bare at operere med 3 forskellige takster. Local (som i hele new york), Resten af staten og hele landet. Det gav i sidste ende en øget indtjening, samt besparelser for både kunde og telefonselskaberne.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder