Tilbage til bloggen

Egress-fælden: den cloud-post ingen budgetterer med

Du budgetterede for compute. Du budgetterede for storage. Så landede fakturaen, og der var en post, du aldrig havde modelleret: dataoverførsel. Egress. Gebyret du betaler for at læse dine egne data ud af skyen igen.

Det er sjældent det tal, der springer i øjnene. Det er det, der lister sig op, mens du ikke kigger, og som så en måned udgør en tredjedel af regningen, uden at nogen kan sige præcis hvorfor.

Hvad egress egentlig er, og hvorfor det prissættes sådan

Egress er udgående data: bytes der forlader en zone, en region eller udbyderens netværk helt. Indgående er som regel gratis. Udgående måles pr. gigabyte, og taksten stables i lag — på tværs af AZ’er, på tværs af regioner, ud på internettet — hver med sin egen pris.

At lagre data er billigt og bliver billigere. At flytte dem er der, hvor marginen ligger. At tage betaling for egress gør to ting for en hyperscaler på én gang: det trykker penge på trafik, der koster dem næsten ingenting, og det hæver prisen på nogensinde at forlade dem. De data, du lægger ind, er gratis at indlæse. At få dem ud igen, i stor skala, er det ikke. Den asymmetri er ikke et tilfælde. Det er forretningsmodellen.

Hvordan det forvrænger din arkitektur

Her er den del, der burde genere dig som ingeniør. Egress-priser holder op med at være en faktureringsdetalje og begynder at træffe designvalg for dig.

  • Du holder op med at flytte data. Det rene design siger kopiér dette datasæt hen, hvor compute er. Fakturaen siger lad være. Så du forvrider topologien for at holde bytes i ro, selv når det er det forkerte valg.
  • Du frygter multi-region. At replikere til en anden region for robusthedens skyld er præcis, hvad du bør gøre. Cross-region egress gør det til en tilbagevendende skat, så du taler dig selv fra det.
  • Du undgår den oplagte analytics-pipeline, fordi det koster mere at hive data hen til det værktøj, der burde bearbejde dem, end selve bearbejdningen.
  • Du ender låst inde. Når dine data først er store, er prisen for at trække dem ud for at evaluere en anden udbyder i sig selv en afskrækkelse. Egress-måleren er en voldgrav, og du står på den forkerte side af den.

Ingen af disse er korrekthedsbeslutninger. De er regnings-undgåelsesbeslutninger forklædt som arkitektur.

Mønstret bag regnings-chokket

Det ser altid ens ud. En lancering går godt. Et batch-job bliver mere snakkesaligt. En fejlkonfigureret klient prøver igen på tværs af en regionsgrænse. Et nyt dashboard poller et object store fra det forkerte sted. Trafik, der var en afrundingsfejl, bliver den dominerende omkostning, og det værste er, at du ikke kan forudsige det på forhånd — prislisten har så mange niveauer og grænser, at den eneste måde at lære tallet at kende er at få det på regningen. Du arkitekterer defensivt omkring en omkostning, du ikke kan modellere. Det er fælden.

Hvad vi gør i stedet

Vi mener, du bør arkitektere for korrekthed, ikke for fakturaen. Så vi fjernede håndtaget.

Der er ingen egress-betaling mellem Kaligon-ressourcer i samme region. Din VM der snakker med din block volume, dit object store, din database, en anden VM — den trafik er gratis. Flyt data hen, hvor compute er. Replikér inden for regionen for robusthedens skyld. Byg pipelinen på lærebogsmåden. De bytes, der løber mellem dine egne ressourcer, dukker ikke op på regningen.

Udgående trafik til internettet er en enkelt fast takst. Ét tal. Ingen cross-AZ-tillæg, ingen cross-region-niveaustige, ingen overraskende grænse, du snublede over kl. 02 om natten. Du kan læse den direkte på pricing-siden og lægge den ind i et regneark, før du bygger noget som helst.

Det passer til, hvordan resten af Kaligon prissættes: én fast pris pr. ressource, betaling pr. sekund med et månedligt loft, og et hårdt budget, der faktisk stopper forbruget. Ingen reserved-instance-gymnastik, ingen committed-use-rabatter du skal jagte. Og fordi dine data bliver i den region, du valgte, vandrer de ikke stille og roligt et dyrere sted hen at forlade.

Egress bør være et netværksanliggende, ikke en designbegrænsning. Arkitektér det rigtige. Lad fakturaen være kedelig.